From Anders at Arnholm.se Sat Dec 1 05:58:45 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Sat Dec 1 05:58:59 2007 Subject: [sldev] Heads up - we're working on CMake In-Reply-To: <1196466679.3426.24.camel@localhost> References: <474DD454.3090005@lindenlab.com> <47506C8A.3060103@watson.ibm.com> <4750704B.3050204@lindenlab.com> <47507C0B.60501@wsu.edu> <47507D0F.6050203@lindenlab.com> <475083CC.7020609@wsu.edu> <4750858E.1080001@lindenlab.com> <1196466679.3426.24.camel@localhost> Message-ID: <20071201135845.GI2111@arnholm.se> On Fri, Nov 30, 2007 at 05:51:19PM -0600, Callum Lerwick wrote: > > On Fri, 2007-11-30 at 13:50 -0800, Bryan O'Sullivan wrote: > > John Hurliman wrote: > > > > > Wouldn't it have been faster to attach those files to your reply e-mail > > > instead of writing the previous sentence then? > > > > When I try to share some useful information, I'm not too pleased to get > > snarky, unhelpful comebacks like this. > > Yes, I'm a bit surprised this thread is getting so much venom. I think > it's just the general frustration with the current segregated > development process bubbling to the surface, that we're all feeling on > the outside. I don't care id it's cmake, gmake, automake, or what ever, what i care about is that the stuff that LL compiles actually is possible to compile. That have not so far been the situation on the windlight branch and that is bad. The two development worlds are to far from each other. This leads to stress, frustration's and misunderstandings, and also Nicholaz put some light on how the talk it totally different. IN a OS environment one are and frank sometimes harsh when telling once mind about a matter. It's been like this in most communities with long traditions, people like Linus and RMS at the front of two of the bigger project. Or Theo in OpenBSD are not directly know to be "polite" and politically correct. On the other side with in most companies communications must be very careful, your don't say anything that could piss off people. It's a sure death sentence. Personally i would be really happy if Linden Labs could open up and embrace a more morten (if the is a good word I'm not sure) and open development style. Some details are there but LL still have a long way to go. being out in big companies for the last 12 years i now understand where LL are, I was confused but the open source embracment, but it's only haft the truth. But now it's time to get a patched 18.5.3. viewer out again. More gui changes that didn't give much possitive. -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071201/937160f0/attachment.pgp From me at hamncheeseomlet.com Sat Dec 1 08:37:09 2007 From: me at hamncheeseomlet.com (Hamncheese) Date: Sat Dec 1 08:37:28 2007 Subject: [OT] Rant (was Re: [sldev] Heads up - we're working on CMake) In-Reply-To: <20071201135845.GI2111@arnholm.se> References: <474DD454.3090005@lindenlab.com> <47506C8A.3060103@watson.ibm.com><4750704B.3050204@lindenlab.com> <47507C0B.60501@wsu.edu><47507D0F.6050203@lindenlab.com> <475083CC.7020609@wsu.edu><4750858E.1080001@lindenlab.com><1196466679.3426.24.camel@localhost> <20071201135845.GI2111@arnholm.se> Message-ID: <32A1F6CA24C646EBA22EC67553D2A084@DreamStream> I don't think it reasonable for LL to tip toe around but then have to allow the community to frank and harsh. However it's evident to me that everyone needs thicker skin starting with LL developers. I think my thoughts on this topic are summed up by Dave Worthington's story in his opening sentence in the Nov 15th issue of SD Times http://www2.sdtimes.com/pdf/SDTimesBackIssues/sdtimes186.pdf. He states: "One of the pitfalls of being open is that one has to be willing to accept criticism, sometimes savage and unsparing." While he was talking about Microsoft's foray into open source licensing, I think there are enough similarities (at least right now) between LL and MS that everyone should read it. I'm not sure what anyone at LL is thinking when they come across as defensive and protective. Everyone is on this list for a reason and is a tiny subset of the larger SL community that obviously thinks that they have something to contribute to the betterment of their own (and shock of all shocks) other's SL experience. Yes, some are "sometimes savage and unsparing" but I have to think that comes from frustration. I don't know anyone here that has a personal vendetta against LL (well ok maybe one but I digress). I think a really great exercise for LL would be to obtain everyone's real life resume's and see that the community collectively has greater and more diverse experience than their brightest developers will ever be or have. BTW that is not a criticism of anyone of any sort at LL and if that statement offends anyone then read my second sentence about thicker skin. It's simply a factor of the economy of scale. So LL can either tap into that diverse experience or use the list to report status. Really as the architect it is their choice as I pointed out in my last email. However, I hate trying to guess what it is going to be. In the last case of reporting status the developer is obviously confused as well as to his role. It boils down to this for me: If LL doesn't like what the community is saying, they should figure out with is wrong and fix it. Cheers, Jon ----- Original Message ----- From: "Anders Arnholm" To: "Callum Lerwick" Cc: Sent: Saturday, December 01, 2007 8:58 AM Subject: Re: [sldev] Heads up - we're working on CMake > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dale at daleglass.net Sat Dec 1 09:16:14 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Dec 1 09:16:25 2007 Subject: [sldev] Is it possible to increase the network timeout? Message-ID: <200712011816.20281.dale@daleglass.net> Debugging the viewer is a bit of a pain when it redmaps if spend a while examining things in the debugger. Any way to increase the amount of time the viewer can be non-responsive? The time it takes to get back in is also annoying. Any chance it could be eliminated or at least reduced on a test grid? -------------- 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/20071201/2634bbf0/attachment-0001.pgp From dzonatas at dzonux.net Sat Dec 1 09:21:02 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Dec 1 09:21:10 2007 Subject: [OT] Rant (was Re: [sldev] Heads up - we're working on CMake) In-Reply-To: <32A1F6CA24C646EBA22EC67553D2A084@DreamStream> References: <474DD454.3090005@lindenlab.com> <47506C8A.3060103@watson.ibm.com><4750704B.3050204@lindenlab.com> <47507C0B.60501@wsu.edu><47507D0F.6050203@lindenlab.com> <475083CC.7020609@wsu.edu><4750858E.1080001@lindenlab.com><1196466679.3426.24.camel@localhost> <20071201135845.GI2111@arnholm.se> <32A1F6CA24C646EBA22EC67553D2A084@DreamStream> Message-ID: <475197FE.5060903@dzonux.net> Very true. If anyone hasn't seen the movie "Shooter," I suggest they do. It is really good movie on the notion it plays out. Metaphorically, one could compare the movie that open source development. Without any spoilers, it portrays a bit about politics and the law that is of quite interest. The end of the movie surely suggested the movie was to be taken more metaphorically than to suggest or relate to any conspiracy, which would be only of mere coincidence. Here... it made me think of SL's T.O.S. where there is virtual land under such T.O.S. and what goes on "the outside" (mmmm, perhaps in RL.) It also made me think of the recent blog post also: http://blog.secondlife.com/2007/11/30/second-life-viewer-susceptible-to-quicktime-security-flaw/ And, the weights used to justify changes in and out of LL -- changes that are "sometimes savage and unsparing" (not just the criticism). The movie put a typical, commonly found, political game and put it in plain English. Hamncheese wrote: > I don't think it reasonable for LL to tip toe around but then have to > allow the community to frank and harsh. However it's evident to me > that everyone needs thicker skin starting with LL developers. I think > my thoughts on this topic are summed up by Dave Worthington's story in > his opening sentence in the Nov 15th issue of SD Times > http://www2.sdtimes.com/pdf/SDTimesBackIssues/sdtimes186.pdf. He states: > > "One of the pitfalls of being > open is that one has to be willing > to accept criticism, sometimes > savage and unsparing." > > While he was talking about Microsoft's foray into open source > licensing, I think there are enough similarities (at least right now) > between LL and MS that everyone should read it. > > I'm not sure what anyone at LL is thinking when they come across as > defensive and protective. Everyone is on this list for a reason and is > a tiny subset of the larger SL community that obviously thinks that > they have something to contribute to the betterment of their own (and > shock of all shocks) other's SL experience. Yes, some are "sometimes > savage and unsparing" but I have to think that comes from frustration. > I don't know anyone here that has a personal vendetta against LL (well > ok maybe one but I digress). > > I think a really great exercise for LL would be to obtain everyone's > real life resume's and see that the community collectively has greater > and more diverse experience than their brightest developers will ever > be or have. BTW that is not a criticism of anyone of any sort at LL > and if that statement offends anyone then read my second sentence > about thicker skin. It's simply a factor of the economy of scale. So > LL can either tap into that diverse experience or use the list to > report status. Really as the architect it is their choice as I pointed > out in my last email. However, I hate trying to guess what it is going > to be. In the last case of reporting status the developer is obviously > confused as well as to his role. > > It boils down to this for me: If LL doesn't like what the community is > saying, they should figure out with is wrong and fix it. > > Cheers, > > Jon > > > ----- Original Message ----- From: "Anders Arnholm" > To: "Callum Lerwick" > Cc: > Sent: Saturday, December 01, 2007 8:58 AM > Subject: Re: [sldev] Heads up - we're working on CMake > > >> _______________________________________________ >> 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 dzonatas at dzonux.net Sat Dec 1 11:30:51 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Dec 1 11:30:39 2007 Subject: [sldev] [ANN] Open Source Meeting In-Reply-To: <473CDAF3.1020401@dzonux.net> References: <473CDAC2.6070307@dzonux.net> <473CDAF3.1020401@dzonux.net> Message-ID: <4751B66B.70807@dzonux.net> At our last meeting, we talked about the overhead between public and external jira tracking. http://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-10-29 I went ahead and commented likewise on integration of the trackers: https://jira.secondlife.com/browse/WEB-89 Please make any further comments there as raised at the meeting. --- Remember that the next Open Source Meeting is on Thurdays, Dec 6th at 2pm! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Add items of discussion to the list! (psst! it's a wiki!) From matthew.dowd at hotmail.co.uk Sun Dec 2 03:33:34 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Dec 2 03:33:37 2007 Subject: [sldev] Region UUIDs and Region Handles In-Reply-To: <4751B66B.70807@dzonux.net> References: <473CDAC2.6070307@dzonux.net> <473CDAF3.1020401@dzonux.net> <4751B66B.70807@dzonux.net> Message-ID: Hi, is there an easy way to convert a region UUID to a region handle? I've tried to look for this in the code but it isn't obvious! Matthew _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml From alissa_sabre at yahoo.co.jp Sun Dec 2 05:07:04 2007 From: alissa_sabre at yahoo.co.jp (alissa_sabre@yahoo.co.jp) Date: Sun Dec 2 05:07:20 2007 Subject: [sldev] Heads up - we're working on CMake In-Reply-To: <474F2CA2.9010002@lindenlab.com> References: <474DD454.3090005@lindenlab.com> <1ds9dY5ds4f14ei4dxiGGdL.alissa_sabre@yahoo.co.jp> <474F2CA2.9010002@lindenlab.com> Message-ID: <74esdds7G74dz4G15dx4L1.alissa_sabre@yahoo.co.jp> It is unfortunate to see that this discussion ends up with a flamewar between Lindens and open source developers. > Our current source release process is painful and > messy, I have no objection to this point. > and I don't want to derail getting a basic cmake build going by > simultaneously wrestling with that. I have no objection to this point either. What I was suggesting in my previous mail is simply disclose whatever you have. I don't expect we get a working copy. I guess you have started with the cmake for the LL internal source tree and it doesn't work with the open source version of the source tree. That's totally fine for me, as I wrote: > > Why you don't disclose the current work-in-progress? Honestly, I don't fully understand your points against this question. However, based on the messages sent to the sldev list regarding this issue, I have a feeling that if you distributed you current copies of cmakelists.txt as-is at the first place, the sldev list was filled with just another set of flamers. I have a feeling that Lindens are not active making their intermediate work open because they fear open source developers complains. (Of course I'm wrong on this point.) So, you may be right. Please keep developing your cmake adaptation project by yourself, until it becomes perfect. It is sorrow to see we (Lindens and open soruce developers) can't collaborate even on a small project like this. I'm not exactly sure what's wrong. Alissa -------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/ From alissa_sabre at yahoo.co.jp Sun Dec 2 05:30:40 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun Dec 2 05:31:01 2007 Subject: [sldev] Running SL on 16-bit color setting In-Reply-To: <20071130053733.D2DB141B2C7@stupor.lindenlab.com> References: Message-ID: <8se44dtzds4ds5L0ikwoe.alissa_sabre@yahoo.co.jp> > Second Life requires True Color (32-bit) to run in a window. Please go to > Control Panels -> Display -> Settings and set the screen to 32-bit color. > Alternately, if you choose to run fullscreen, Second Life will automatically > adjust the screen each time it runs. > ---- > The alternate way is not applicable, because detecting display setting runs > prior to detecting window mode (fullscreen or window). Good point. I filled a JIRA issue VWR-3595. > So my question is 'Does viewer has any 32-bit color dependent code?'. > If yes, 'Where can I find it?' and 'How can I make it support lower setting > like 16-bit?' I don't know the answers to any of the three questions. Alissa Sabre -------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/ From kamilion at gmail.com Sun Dec 2 06:11:20 2007 From: kamilion at gmail.com (Kamilion) Date: Sun Dec 2 06:11:23 2007 Subject: [sldev] [VWR] Multi-select Users in Group IM and Near Me UserList, Right Click Menu, Create Conference Message-ID: Today, I was chatting in Scripters of Second Life. The Group Owners and Administrators dislike when conversation falls off topic or people treat the Group IM Session as an IRC channel. The most user friendly way to address this with the minimum amount of coding and effort, in my opinion, would be the following: Background: In the 1.18.X Voice-Enabled Viewers, one can click the << button and open a List of users either nearby users in the Near Me tab, or a Group Instant Message tab. #1: Allow a single user to be right clicked on, display a menu similar to right clicking on an object in inventory. #1-1: Menu Entry: View User Profile #1-2: Menu Entry: Instant Message #1-3: Menu Entry: Offer Teleport #1-4: Menu Entry: Offer Calling Card #1-5: Menu Entry: Offer Friendship (Should only show up when a single user is selected to prevent mass-friend add spam.) #1-5: Menu Entry: Mute/Unmute Chat #1-6: Menu Entry: Mute/Unmute Voice #1-7: Menu Entry: Start Conference Chat #2: Allow multiple users to be Shift-block / Ctrl-individual selected in the user list. #2-1: Menu Entry: Start Conference Chat #2-2: Menu Entry: Offer Calling Card #2-3: Menu Entry: View User Profiles (Create a single window with multiple profiles in tabs, like multi-selecting two calling cards in inventory, right clicking, and selecting Open.) #2-4: Menu Entry: Offer Teleport The main request here is adding a way to Conference with other users in the group. Alternatively, there needs to be a mechanism to add more users into an existing Conference... If there is one, I haven't found it. If you can think of a simpler way to implement this, comment on https://jira.secondlife.com/browse/VWR-3596 -- Kamilion Schnook From gigstaggart at gmail.com Sun Dec 2 10:59:57 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Dec 2 10:59:09 2007 Subject: [sldev] Running SL on 16-bit color setting In-Reply-To: References: Message-ID: <475300AD.8080501@gmail.com> Bok-yeon Lee wrote: > So my question is 'Does viewer has any 32-bit color dependent code?'. The picking render probably depends on 32 bit... you may have to rewrite the picking code to make it work with 16 bit. -Jason From dale at daleglass.net Sun Dec 2 12:59:17 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Dec 2 12:59:28 2007 Subject: [sldev] Questions on the particle system Message-ID: <200712022159.22637.dale@daleglass.net> I started messing with particles a bit, after getting rather frustrated when trying to take screenshots with particle effects. I modified LLViewerPartSim::updateSimulation() to sort particle sources by distance. This for some reason didn't do what I expected (rendering nearby sources and not far away ones), but at least it got rid of the sputtering. The exact problem is: Sorting works alright. If I sort then only render the first 5, I see only the nearest 5 work. But the particle limit seems to be equally spread among all active effects. I also added two new settings: RenderMaxPartSourcesCount and RenderMaxPartDistance. The first one is mostly for testing, the second is the maximum distance a source can be from the camera for the effect to be made. This is intended in part as an anti-griefing measure: with this it's possible to silence those huge particle effects while keeping the nearby ones. Now questions. What is LLViewerPartGroup and what is done at the end of LLViewerPartSim::updateSimulation()? Why does the particle limit work by keeping a counter that gets incremented in constructors and decremented in destructors instead of just setting it to 0 on each start of frame and counting what's actually getting rendered? Why do invisible effects still count towards the particle limit? Here's what I'm intending to achieve, unless there's some reason why this is undesirable: * Particle sources are sorted by distance (done) * No sputtering, particle effects when running into the limit reduce the count smoothly. (done) * Nearest sources have priority. If you zoom on something, it's pretty much guaranteed to take most or all of the particle quota. * If particles aren't being emitted, then it doesn't count towards the limit * When the particle limit approaches, effects are throttled gradually (so particles don't instantly vanish at some cutoff point unless you use the distance limit) How does this sound? -------------- 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/20071202/9e11ee2b/attachment.pgp From secret.argent at gmail.com Sun Dec 2 13:17:41 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Dec 2 13:17:52 2007 Subject: [sldev] Questions on the particle system In-Reply-To: <200712022159.22637.dale@daleglass.net> References: <200712022159.22637.dale@daleglass.net> Message-ID: <195ED6D3-8D7F-41D3-8669-80696AD2C7C1@gmail.com> On 02-Dec-2007, at 14:59, Dale Glass wrote: > Why does the particle limit work by keeping a counter that gets > incremented > in constructors and decremented in destructors instead of just > setting it > to 0 on each start of frame and counting what's actually getting > rendered? > > Why do invisible effects still count towards the particle limit? I think that the key point here may be to remember that particles not being rendered still need to be tracked, so that (for example) the smoke from the campfire behind you blows past you. The other thing to consider is that it's probably smarter to sort particle systems by the area they cover, so that a nearby but small system isn't given priority over a system that's further away. The last-but-one Windlight release got that wrong, and that's why particle systems were screwed up. They seem to have largely fixed most of the particle systems problems in the latest Windlight. Before spending a lot of time on this, you probably need to see if the problem you're trying to solve is still a problem, and... if you want it in your own viewer without Windlight... whether you can't just lift the code from there. Also, note that both Nicholaz and I have spent a lot of time digging into this already. From blakar at gmail.com Sun Dec 2 13:46:03 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Dec 2 13:46:05 2007 Subject: [sldev] Questions on the particle system In-Reply-To: <200712022159.22637.dale@daleglass.net> References: <200712022159.22637.dale@daleglass.net> Message-ID: <7992d0d60712021346x3799c9bam4f3de1503fdcefce@mail.gmail.com> Dale, what version of the source tree did you start against? If it isn't the latest windlight branch I suggest you go check out at least VWR-418 and VWR-983 first. My particle patches for VWR-418 and VWR-983 are in latest windlight though you need the info from VWR-3403 too because there was an issue during the merge (latest windlight binary is corrected but I haven't seen source yet). You can just lift the related files from the windlight branch and put it in another one (mind VWR-3403). There's one additional particle patch in there (VWR-2164) but apart from that files are pretty much identical to 1.18.3.2 (I used a diff against my personal 1.18.3.2 branch to find the issue of VWR-3403). LL adapted my patches to their liking but functionally they did not change them as such I can help you find improvements on the latest version. Argent already replied on the particle count stuff. If it needs to be tracked you need to count it. As such it's important to limit at spawn and not afterwards. My patches have done that by implementing a dynamic throttling mechanism. The primary basis is particle viewability. As such a source spawning larger particles may get priority over one that is spawning smaller invisible particles near you. It may not be agressive enough to everyones liking but it offer a huge improvement over the old code. On the anti-griefing part the new code has some stuff too as the high throttling levels will cut in the amount of live particles a single source can want simultaneously. A source may for example try to get thousands of live particles by spawning a few at a time but giving them long lives. The new code will punish such sources by limiting the amount of particles they will get. Dirk aka Blakar Ogre On Dec 2, 2007 9:59 PM, Dale Glass wrote: > I started messing with particles a bit, after getting rather frustrated > when trying to take screenshots with particle effects. > > I modified LLViewerPartSim::updateSimulation() to sort particle sources by > distance. This for some reason didn't do what I expected (rendering nearby > sources and not far away ones), but at least it got rid of the sputtering. > > The exact problem is: Sorting works alright. If I sort then only render the > first 5, I see only the nearest 5 work. But the particle limit seems to be > equally spread among all active effects. > > I also added two new settings: RenderMaxPartSourcesCount and > RenderMaxPartDistance. The first one is mostly for testing, the second is > the maximum distance a source can be from the camera for the effect to be > made. This is intended in part as an anti-griefing measure: with this it's > possible to silence those huge particle effects while keeping the nearby > ones. > > Now questions. > > What is LLViewerPartGroup and what is done at the end of > LLViewerPartSim::updateSimulation()? > > Why does the particle limit work by keeping a counter that gets incremented > in constructors and decremented in destructors instead of just setting it > to 0 on each start of frame and counting what's actually getting rendered? > > Why do invisible effects still count towards the particle limit? > > > Here's what I'm intending to achieve, unless there's some reason why this > is undesirable: > > * Particle sources are sorted by distance (done) > * No sputtering, particle effects when running into the limit reduce the > count smoothly. (done) > * Nearest sources have priority. If you zoom on something, it's pretty much > guaranteed to take most or all of the particle quota. > * If particles aren't being emitted, then it doesn't count towards the > limit > * When the particle limit approaches, effects are throttled gradually (so > particles don't instantly vanish at some cutoff point unless you use the > distance limit) > > > How does this sound? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From dale at daleglass.net Sun Dec 2 13:53:19 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Dec 2 13:53:31 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: <195ED6D3-8D7F-41D3-8669-80696AD2C7C1@gmail.com> References: <200712022159.22637.dale@daleglass.net> <195ED6D3-8D7F-41D3-8669-80696AD2C7C1@gmail.com> Message-ID: <200712022253.26056.dale@daleglass.net> On Sunday 02 December 2007 22:17:41 Argent Stonecutter wrote: > I think that the key point here may be to remember that particles not > being rendered still need to be tracked, so that (for example) the > smoke from the campfire behind you blows past you. That makes sense, but IMO it doesn't make sense to limit it. Tracking particles off-screen can't be that much work. It's rendering what involves a performance hit. My understanding of "particle limit" is that if set to say, 4096 that means maximum 4096 *on the screen* > The other thing to > consider is that it's probably smarter to sort particle systems by > the area they cover, so that a nearby but small system isn't given > priority over a system that's further away. Why? It's actually pretty much the reverse of my sense of priorities. If I'm looking at something that's near, like say, a candle, I want to see the candle in its all full detail glory. Whatever is going on far away is far less interesting. > Before spending a lot of time on this, you probably need to see if > the problem you're trying to solve is still a problem, and... if you > want it in your own viewer without Windlight... whether you can't > just lift the code from there. Also, note that both Nicholaz and I > have spent a lot of time digging into this already. Hmm, will have to take a better look, but I still get the feeling of that I'll end up writing something as it seems we disagree on the specifics. Guess one way to see the best way to handle it is to compare what it's going to end up looking like :-) -------------- 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/20071202/44e0f9ae/attachment.pgp From dale at daleglass.net Sun Dec 2 14:26:55 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Dec 2 14:27:06 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: <7992d0d60712021346x3799c9bam4f3de1503fdcefce@mail.gmail.com> References: <200712022159.22637.dale@daleglass.net> <7992d0d60712021346x3799c9bam4f3de1503fdcefce@mail.gmail.com> Message-ID: <200712022327.00135.dale@daleglass.net> On Sunday 02 December 2007 22:46:03 Dirk Moerenhout wrote: > Dale, > > what version of the source tree did you start against? If it isn't the > latest windlight branch I suggest you go check out at least VWR-418 > and VWR-983 first. I was working against 1.18.4 (kinda old, yeah) > My particle patches for VWR-418 and VWR-983 are in latest windlight > though you need the info from VWR-3403 too because there was an issue > during the merge (latest windlight binary is corrected but I haven't > seen source yet). You can just lift the related files from the > windlight branch and put it in another one (mind VWR-3403). There's > one additional particle patch in there (VWR-2164) but apart from that > files are pretty much identical to 1.18.3.2 (I used a diff against my > personal 1.18.3.2 branch to find the issue of VWR-3403). I just tried Windlight. I seems to share the same annoying behavior. Meaning, that when running into the particle limit, things start to sputter. If you see a fountain, it doesn't shoot less water, it shoots the full amount for a frame, then nothing for several, and so on. It also has the same issue with limiting particles. I only see an effect that has about 2500 of them. I have a 4096 limit set, and seeing a lot less particles than should be in the full effect. > > Argent already replied on the particle count stuff. If it needs to be > tracked you need to count it. As such it's important to limit at spawn > and not afterwards. Why? > My patches have done that by implementing a > dynamic throttling mechanism. The primary basis is particle > viewability. As such a source spawning larger particles may get > priority over one that is spawning smaller invisible particles near > you. It may not be agressive enough to everyones liking but it offer a > huge improvement over the old code. I guess that I must be weird, but I disagree here. I find a huge smoke stack far away spewing lots of huge particles quite uninteresting. On the other hand I want to see a nearby candle, or tiny sparks from a magic wand I'm holding. If the particles aren't visible then IMO they effectively don't exist and shouldn't be counted towards the limit. > On the anti-griefing part the new code has some stuff too as the high > throttling levels will cut in the amount of live particles a single > source can want simultaneously. A source may for example try to get > thousands of live particles by spawning a few at a time but giving > them long lives. The new code will punish such sources by limiting the > amount of particles they will get. Not sure if that's going to be very effective as they can always use more prims. My limit is simply based on that particle griefing seldom happens right on your land, because if it was there you could remove it. So my approach is to simply add the possibility of killing all sources more than X meters away. Eventually I'm going to mute all particle emission from avatars who are banned on the parcel you're on (been planning this for a while, but got busy) -------------- 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/20071202/25623115/attachment.pgp From blakar at gmail.com Sun Dec 2 15:12:37 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Dec 2 15:12:38 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: <200712022253.26056.dale@daleglass.net> References: <200712022159.22637.dale@daleglass.net> <195ED6D3-8D7F-41D3-8669-80696AD2C7C1@gmail.com> <200712022253.26056.dale@daleglass.net> Message-ID: <7992d0d60712021512w3f744fbbvf132822ca6fab56e@mail.gmail.com> > That makes sense, but IMO it doesn't make sense to limit it. Tracking > particles off-screen can't be that much work. It's rendering what involves > a performance hit. My understanding of "particle limit" is that if set to > say, 4096 that means maximum 4096 *on the screen* In a system only limited by on screen particles you'd soon find out that tracking particles takes a lot more time than rendering them. Rendering 4096 particles is not a GPU intensive task. They are 2D sprites that always face the camera. I rarely see a scene that has less than 125K triangles in view so the easy to render particles aren't bogging down your GPU. Dirk aka Blakar Ogre From dale at daleglass.net Sun Dec 2 15:27:14 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Dec 2 15:27:25 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: <7992d0d60712021512w3f744fbbvf132822ca6fab56e@mail.gmail.com> References: <200712022159.22637.dale@daleglass.net> <200712022253.26056.dale@daleglass.net> <7992d0d60712021512w3f744fbbvf132822ca6fab56e@mail.gmail.com> Message-ID: <200712030027.19681.dale@daleglass.net> On Monday 03 December 2007 00:12:37 Dirk Moerenhout wrote: > In a system only limited by on screen particles you'd soon find out > that tracking particles takes a lot more time than rendering them. > Rendering 4096 particles is not a GPU intensive task. They are 2D > sprites that always face the camera. I rarely see a scene that has > less than 125K triangles in view so the easy to render particles > aren't bogging down your GPU. > > Dirk aka Blakar Ogre Sure, the geometry is not complicated. But I've seen a very noticeable drop in performance by increasing particle size. That seems to indicate that the fill rate is the problem. And I really don't see why tracking particle position has to take a lot of time. There isn't anything that complex there. If keeping track of particles even if they aren't rendered is a large enough burden then I'd just set two limits: on-screen rendering and a larger limit for overall tracking. -------------- 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/20071203/3ba80dad/attachment-0001.pgp From blakar at gmail.com Sun Dec 2 15:33:46 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Dec 2 15:33:48 2007 Subject: [sldev] Fwd: Questions on the particle system In-Reply-To: <7992d0d60712021532y1bf1de88j5268c4d49e625d89@mail.gmail.com> References: <200712022159.22637.dale@daleglass.net> <7992d0d60712021346x3799c9bam4f3de1503fdcefce@mail.gmail.com> <200712022327.00135.dale@daleglass.net> <7992d0d60712021532y1bf1de88j5268c4d49e625d89@mail.gmail.com> Message-ID: <7992d0d60712021533s640fc3dbi15e744901e2c6f1f@mail.gmail.com> Forgot to put list in copy and I guess others may be interested in particles too. ---------- Forwarded message ---------- From: Dirk Moerenhout Date: Dec 3, 2007 12:32 AM Subject: Re: Questions on the particle system To: Dale Glass > I just tried Windlight. I seems to share the same annoying behavior. > > Meaning, that when running into the particle limit, things start to > sputter. If you see a fountain, it doesn't shoot less water, it shoots the > full amount for a frame, then nothing for several, and so on. There's actually no code that is aimed at doing this so I find it rather odd. Feel free to send me landmarks for locations that exhibit this. All limits are based on chances so it should always be gradual, sources are never turned off and on. > It also has the same issue with limiting particles. I only see an effect > that has about 2500 of them. I have a 4096 limit set, and seeing a lot > less particles than should be in the full effect. Personally I believe any effect that has 2500 particles is written by somebody who isn't interested in writing interesting particle sources. Very few effects warrant 2500 live particles. I'd advise you to set your particle limit to 8192 though, there's little reason to keep it at 4096. > > Argent already replied on the particle count stuff. If it needs to be > > tracked you need to count it. As such it's important to limit at spawn > > and not afterwards. > Why? See my other reply. If you disagree I'd suggest you remove the current cap and create one for on screen particles. Then fire of a profiler and see what happens. > > My patches have done that by implementing a > > dynamic throttling mechanism. The primary basis is particle > > viewability. As such a source spawning larger particles may get > > priority over one that is spawning smaller invisible particles near > > you. It may not be agressive enough to everyones liking but it offer a > > huge improvement over the old code. > I guess that I must be weird, but I disagree here. I find a huge smoke > stack far away spewing lots of huge particles quite uninteresting. On the > other hand I want to see a nearby candle, or tiny sparks from a magic wand > I'm holding. In general, in testing I've found nearly no scene that is not rendered correctly when you have your limit set to 8192 particles (which if you ask me should be the default). Particles from a nearby candle or wand don't need a lot of particles anyway and are hence rarely throttled. Personally my aim is always to get a correctly rendered scene. Sure if there's many parcels near eachother with differing content this is not that interesting but many large scenes are only rendered correctly if the throttling is adapted to the cause. > If the particles aren't visible then IMO they effectively don't exist and > shouldn't be counted towards the limit. Unfortunately your CPU will disagree and there has already been done quite a bit of work trying to keep the CPU load of off screen particles low. The VWR-983 fixes for example would've been a lot more straight forward if it wasn't for concerns of CPU usage. > > On the anti-griefing part the new code has some stuff too as the high > > throttling levels will cut in the amount of live particles a single > > source can want simultaneously. A source may for example try to get > > thousands of live particles by spawning a few at a time but giving > > them long lives. The new code will punish such sources by limiting the > > amount of particles they will get. > > Not sure if that's going to be very effective as they can always use more > prims. My limit is simply based on that particle griefing seldom happens > right on your land, because if it was there you could remove it. I own only own 512m? and hence spend most of my time on other land. My goal was to see things others created in the way it looks best. As such I wanted to kill off the particle streams that are being abusive to their environment. Sure one could split prims but a lot of "griefing" isn't really meant to be bad, it's just caused by not well thought over sources. > So my approach is to simply add the possibility of killing all sources more > than X meters away. Eventually I'm going to mute all particle emission > from avatars who are banned on the parcel you're on (been planning this > for a while, but got busy) I can probably whip out a version that throttles on distance as soon as the dynamic threshold is forced to throttle viewable particles (it now first cuts away particles that are not in view and are unlikely to come in view, this irregardless of their distance as a source 20m away from you may be spawning stuff you won't ever see because you can't move close enough to it in time in order to see it). It would be an alternative to cutting in the amount of particles abusive sources can spawn. Dirk aka Blakar Ogre From blakar at gmail.com Sun Dec 2 15:39:04 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Dec 2 15:39:07 2007 Subject: [sldev] Running SL on 16-bit color setting In-Reply-To: References: <1196401038.3426.14.camel@localhost> <319E8B9F-1298-4B4F-96C9-FB06B3F35135@gmail.com> Message-ID: <7992d0d60712021539ne4a69d9qcebd35dc867086e1@mail.gmail.com> > As most people knows, SL uses OpenGL and supports OS X and Linux as well. > So, porting on mobile devices, that support OpenGL ES, is not so difficult. > Yes.. still has many issues to resolve, memory optimization is an example. > And 32-bit color dependent code is also one of the issues. I don't know OpenGL ES but how does it handle alpha blending? Images are stored in 32-bit but only 24 bits are used for color, remainder is alpha and is used within SL. I guess the first thing you'd need to consider would be how to convert all the content you receive to the proper format. Does OpenGL ES rendering 32-bit encoded images on a 16-bit display and if so, does it handle the alpha correctly? > In CE and mobile world, there're so many configurations, and possible > applications. I cannot explain all. So, please focus on my original question > - 'Where/how can I find. And how can I fix it?' I'm not a 3D-expert, so need > your help. I fear the answer is: become a 3D rendering expert. If alpha-blending and 16-bit vs 32-bit encoding have no meaning to you you'll be hard pressed to manage to implement a 16-bit SL version based on current code. Dirk aka Blakar Ogre From dale at daleglass.net Sun Dec 2 16:18:30 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Dec 2 16:18:42 2007 Subject: [sldev] Fwd: Questions on the particle system In-Reply-To: <7992d0d60712021533s640fc3dbi15e744901e2c6f1f@mail.gmail.com> References: <200712022159.22637.dale@daleglass.net> <7992d0d60712021532y1bf1de88j5268c4d49e625d89@mail.gmail.com> <7992d0d60712021533s640fc3dbi15e744901e2c6f1f@mail.gmail.com> Message-ID: <200712030118.35604.dale@daleglass.net> On Monday 03 December 2007 00:33:46 Dirk Moerenhout wrote: > > I just tried Windlight. I seems to share the same annoying behavior. > > > > Meaning, that when running into the particle limit, things start to > > sputter. If you see a fountain, it doesn't shoot less water, it shoots > > the full amount for a frame, then nothing for several, and so on. > > There's actually no code that is aimed at doing this so I find it > rather odd. Feel free to send me landmarks for locations that exhibit > this. All limits are based on chances so it should always be gradual, > sources are never turned off and on. windlight source, indra/newview/llviewerpartsim.cpp, line 852. Since it picks an arbitrary starting point, sometimes a particle system happens to be at the start of the list, and sometimes at the end, so sometimes it gets all its particles rendered, and sometimes doesn't To test this, take the script below. Make lots of copies so that things go well over the limit. This is best seen with small particles. Look at just one source, hiding all others from view. You'll notice how emission is very irregular. > > It also has the same issue with limiting particles. I only see an > > effect that has about 2500 of them. I have a 4096 limit set, and > > seeing a lot less particles than should be in the full effect. > > Personally I believe any effect that has 2500 particles is written by > somebody who isn't interested in writing interesting particle sources. > Very few effects warrant 2500 live particles. I'd advise you to set > your particle limit to 8192 though, there's little reason to keep it > at 4096. The particular amount isn't important. The thing here is that particles are supposed to be seen on screen. > > > > Argent already replied on the particle count stuff. If it needs to > > > be tracked you need to count it. As such it's important to limit at > > > spawn and not afterwards. > > > > Why? > > See my other reply. If you disagree I'd suggest you remove the current > cap and create one for on screen particles. Then fire of a profiler > and see what happens. Well of course more data to track takes more CPU time. But the rendering hit is very significant. In the latest windlight I just tested: 4x4 particles: 26 fps 0.1x0.1 particles: 47 fps no particles: 47 fps Here's a script: integer g_mode = 0; particles(vector size) { llParticleSystem( [ PSYS_PART_START_ALPHA, 1.0, PSYS_PART_END_ALPHA, 0.0, PSYS_PART_START_SCALE, size, PSYS_SRC_BURST_PART_COUNT,3, PSYS_SRC_BURST_RATE,0.1, PSYS_PART_MAX_AGE,9.0, PSYS_SRC_PATTERN,PSYS_SRC_PATTERN_ANGLE_CONE, PSYS_PART_FLAGS,PSYS_PART_INTERP_COLOR_MASK ] ); } default { touch_start(integer count) { if ( ++g_mode > 2 ) g_mode = 0; llOwnerSay("Mode: " + (string)g_mode); if ( g_mode == 0 ) llParticleSystem([]); if ( g_mode == 1 ) particles(<4.0, 4.0, 0.0>); if ( g_mode == 2 ) particles(<0.1, 0.1, 0.1>); } } I see a very large difference depending on particle system. Moving the camera away from the source when it's making the big ones also makes a very big difference. When it's making the small ones I can't notice anything significant. Also, with lots of emitters behind me, 0 vs 8192 particle limit makes no noticeable difference in framerate. > > If the particles aren't visible then IMO they effectively don't exist > > and shouldn't be counted towards the limit. > > Unfortunately your CPU will disagree and there has already been done > quite a bit of work trying to keep the CPU load of off screen > particles low. The VWR-983 fixes for example would've been a lot more > straight forward if it wasn't for concerns of CPU usage. My CPU seems to disagree far less than my video card does. Specs: Athlon 64 X2 5200+, GeForce 7900 GS What do you have? -------------- 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/20071203/d8d4e410/attachment.pgp From odysseus654 at gmail.com Sun Dec 2 17:32:01 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Sun Dec 2 17:32:05 2007 Subject: [sldev] Heads up - we're working on CMake In-Reply-To: <74esdds7G74dz4G15dx4L1.alissa_sabre@yahoo.co.jp> References: <474DD454.3090005@lindenlab.com> <1ds9dY5ds4f14ei4dxiGGdL.alissa_sabre@yahoo.co.jp> <474F2CA2.9010002@lindenlab.com> <74esdds7G74dz4G15dx4L1.alissa_sabre@yahoo.co.jp> Message-ID: <1674f6c70712021732q5bb13ee9u66b3d5338f7fefce@mail.gmail.com> I hate to wade into this thread that has been obviously running for much longer than it should have been (and doubt that this contribution will make much of a difference), but I must admit I feel a bit badly for Bryan that was so obviously jumped on by all these os coders out here. The original email sounded very much like one or two developers are working on their own on a CMake replacement for building the viewer and got a bit excited and decided to tell the community what they were doing. The only possible response I can see them taking is to be less likely to discuss their internal processes for fear of another response like this. I doubt that LL is waiting for this thing to be "perfect", if they waited for perfection before releasing something (1) nothing would ever be released (SL perfect? ever?), and (2) there would be no need to release it to be improved. I know that personally before I would release something as opensource I would make sure that I actually had something to provide (i.e. it actually compiled and did a basic job of what it was trying to do) otherwise there wouldn't be much purpose to throwing the code into the void. I don't get the impression that this CMake effort is up to this point, although there is (or was) some excitement that this would occur soon. With so many requests for the CMake scripts, I get the impression that a lot of people are dependent on these script in order to more easily build the viewer. Why is the entire opensource effort being tied to a developer working on something that is not the main development focus right now? If there was a strong need for these files, I'm sure that there would be half a dozen versions floating around that could be submitted or used in the interim, such an effort could probably help as it would show potential gotchas and issues that need to be dealt with before such a build process could be adopted. I mean heck we've even got the guy that wrote the program in here. There is a lot of criticism about how LL has been handling the opensource movement. A lot of it has value. I particularly don't like what I'm hearing about this auth method rewrite that seems to be going forward despite os feedback (I'm hoping that when it comes out it's not as bad as it sounds, but i'm not holding my breath). I'm hoping that the response here is more a reaction to any display of LL "holding back" code from the OS community than of this particular situation. The build script that is used after all isn't going to change the actual content of the .exe or cause it to behave any differently, it's a change in the process and procedures on how the build is constructed. I don't see any design or security issues here at all. I do see a lot of excitement here regarding the new build scripts, but a lot of it reminds me of a pop star getting mobbed by his/her fans and getting torn to shreds. Which confuses the heck out of me. What ever happened to the "patch or leave" attitude I was hearing before? It had plenty of negative connotations and its own toxicity, but at the moment it seems more healthy than this junk... On 12/2/07, alissa_sabre@yahoo.co.jp wrote: > > It is unfortunate to see that this discussion ends up with a flamewar > between Lindens and open source developers. > > > Our current source release process is painful and > > messy, > > I have no objection to this point. > > > and I don't want to derail getting a basic cmake build going by > > simultaneously wrestling with that. > > I have no objection to this point either. > > What I was suggesting in my previous mail is simply disclose whatever > you have. I don't expect we get a working copy. I guess you have > started with the cmake for the LL internal source tree and it doesn't > work with the open source version of the source tree. That's totally > fine for me, as I wrote: > > > > Why you don't disclose the current work-in-progress? > > Honestly, I don't fully understand your points against this question. > However, based on the messages sent to the sldev list regarding this > issue, I have a feeling that if you distributed you current copies of > cmakelists.txt as-is at the first place, the sldev list was filled > with just another set of flamers. I have a feeling that Lindens are > not active making their intermediate work open because they fear open > source developers complains. (Of course I'm wrong on this point.) > > So, you may be right. Please keep developing your cmake adaptation > project by yourself, until it becomes perfect. > > It is sorrow to see we (Lindens and open soruce developers) can't > collaborate even on a small project like this. I'm not exactly sure > what's wrong. > > Alissa > -------------------------------------- > New Design Yahoo! JAPAN 2008/01/01 > http://pr.mail.yahoo.co.jp/newdesign/ > _______________________________________________ > 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/20071202/2d032980/attachment-0001.htm From jessesa at gmail.com Sun Dec 2 18:37:55 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Sun Dec 2 18:37:58 2007 Subject: [sldev][META]LL using Streambase for fraud protection. Message-ID: May be of interest to others. Would imagine one of the tie-ins to this would be the authentication API. http://www.wired.com/gaming/virtualworlds/news/2007/11/mmo_cheats "Online Games Use Fraud Software to Combat Cheats By Emmet Cole 11.30.07 | 4:00 PM Cheaters in multiplayer online games beware: Game developers are turning to advanced financial fraud-detection software to keep you from crooking your way to online riches." etc, etc "The MMO developer BioWare has recently adopted StreamBase's technology, as has Second Life's Linden Lab and Avatar Reality, which is creating the MMO Blue Mars for launch in late 2008." etc etc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071202/90079b1b/attachment.htm From secret.argent at gmail.com Sun Dec 2 19:12:46 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Dec 2 19:12:50 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: <200712022253.26056.dale@daleglass.net> References: <200712022159.22637.dale@daleglass.net> <195ED6D3-8D7F-41D3-8669-80696AD2C7C1@gmail.com> <200712022253.26056.dale@daleglass.net> Message-ID: <6C711B3D-7589-4862-B342-09FFE14336AA@gmail.com> On 02-Dec-2007, at 15:53, Dale Glass wrote: > If I'm looking at something that's near, like say, a candle, I want > to see > the candle in its all full detail glory. Whatever is going on far > away is > far less interesting. If you can see details in the flame then the AREA it covers is large, so it's not a small particle system. From dale at daleglass.net Sun Dec 2 20:02:03 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Dec 2 20:02:35 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: <6C711B3D-7589-4862-B342-09FFE14336AA@gmail.com> References: <200712022159.22637.dale@daleglass.net> <200712022253.26056.dale@daleglass.net> <6C711B3D-7589-4862-B342-09FFE14336AA@gmail.com> Message-ID: <200712030502.15713.dale@daleglass.net> On Monday 03 December 2007 04:12:46 Argent Stonecutter wrote: > On 02-Dec-2007, at 15:53, Dale Glass wrote: > > If I'm looking at something that's near, like say, a candle, I want > > to see > > the candle in its all full detail glory. Whatever is going on far > > away is > > far less interesting. > > If you can see details in the flame then the AREA it covers is large, > so it's not a small particle system. I still think the area is the wrong approach. Things with large areas are usually uninteresting and don't lose that much from being toned down a bit. Take this for example: http://daleglass.net/images/screenshots/overkill.jpg That sort of thing is going to beat pretty much any nearby effect. And are you really going to miss a few particles in there? Besides, in the current codebase this is going to be counted even if it's happening somewhere out of your view. My benchmarks show that at least on my hardware, area is THE cause of the slowdown. The whole point of having a particle limit is to avoid making things down grind to a halt when too, and favouring things by area means consistently picking the worst framerate possible. Worse, IMO, this would encourage waste. Particles are great for small details. But this detail will inevitably lose to whatever happens to be around. So solution for that: More output, so that it's more likely to be shown. In fact I think that prioritizing *small* effects near the camera could be better. -------------- 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/20071203/0079f7ed/attachment.pgp From odysseus654 at gmail.com Sun Dec 2 21:42:17 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Sun Dec 2 21:42:19 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: <200712030502.15713.dale@daleglass.net> References: <200712022159.22637.dale@daleglass.net> <200712022253.26056.dale@daleglass.net> <6C711B3D-7589-4862-B342-09FFE14336AA@gmail.com> <200712030502.15713.dale@daleglass.net> Message-ID: <1674f6c70712022142iee5f70eia7d4bb33e2f44054@mail.gmail.com> Speaking as a random observer from the sidelines, it sounds like what we need or are developing is something like the psychoacoustic models that drive the heart of MP3 and make it work so well... On 12/2/07, Dale Glass wrote: > > On Monday 03 December 2007 04:12:46 Argent Stonecutter wrote: > > On 02-Dec-2007, at 15:53, Dale Glass wrote: > > > If I'm looking at something that's near, like say, a candle, I want > > > to see > > > the candle in its all full detail glory. Whatever is going on far > > > away is > > > far less interesting. > > > > If you can see details in the flame then the AREA it covers is large, > > so it's not a small particle system. > > I still think the area is the wrong approach. Things with large areas are > usually uninteresting and don't lose that much from being toned down a > bit. Take this for example: > > http://daleglass.net/images/screenshots/overkill.jpg > > That sort of thing is going to beat pretty much any nearby effect. And are > you really going to miss a few particles in there? > > Besides, in the current codebase this is going to be counted even if it's > happening somewhere out of your view. > > My benchmarks show that at least on my hardware, area is THE cause of the > slowdown. The whole point of having a particle limit is to avoid making > things down grind to a halt when too, and favouring things by area means > consistently picking the worst framerate possible. > > Worse, IMO, this would encourage waste. Particles are great for small > details. But this detail will inevitably lose to whatever happens to be > around. So solution for that: More output, so that it's more likely to be > shown. > > In fact I think that prioritizing *small* effects near the camera could be > better. > > _______________________________________________ > 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/20071202/cedf3335/attachment.htm From secret.argent at gmail.com Sun Dec 2 22:05:36 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun Dec 2 22:05:47 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: <200712030502.15713.dale@daleglass.net> References: <200712022159.22637.dale@daleglass.net> <200712022253.26056.dale@daleglass.net> <6C711B3D-7589-4862-B342-09FFE14336AA@gmail.com> <200712030502.15713.dale@daleglass.net> Message-ID: On 02-Dec-2007, at 22:02, Dale Glass wrote: > On Monday 03 December 2007 04:12:46 Argent Stonecutter wrote: >> On 02-Dec-2007, at 15:53, Dale Glass wrote: >>> If I'm looking at something that's near, like say, a candle, I want >>> to see >>> the candle in its all full detail glory. Whatever is going on far >>> away is >>> far less interesting. >> >> If you can see details in the flame then the AREA it covers is large, >> so it's not a small particle system. > > I still think the area is the wrong approach. Things with large > areas are > usually uninteresting and don't lose that much from being toned down a > bit. Most any particle system with a lot of particles in it doesn't lose much from being toned down a bit. My "Stunt Double", however, only has 30 particles in it (one particle per second, 30 second lifespan). > http://daleglass.net/images/screenshots/overkill.jpg That effect is at zero distance from the camera: you're inside it. > Besides, in the current codebase this is going to be counted even > if it's > happening somewhere out of your view. Which it should. > In fact I think that prioritizing *small* effects near the camera > could be > better. Don't forget that the dimensions of an effect fall off at the square of the distance. A flame system 1 meter from the camera that's 10cm across and 1m tall subtends the same area on your screen as a snowstorm 100 meters from the camera that's 30 meters by 30 meters. They would both get the same priority. From seg at haxxed.com Mon Dec 3 00:02:36 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 3 00:02:46 2007 Subject: [sldev] [VWR] Vectorization on i386? Message-ID: <1196668956.17392.30.camel@localhost> Okay, I've never ever seen vectorization work on any of my i386 machines. ->mHasSSE: 1 ->mHasSSE2: 1 ->mHasAltivec: 0 ->mCPUMhz: 2134 ->mCPUString: Intel(R) Celeron(R) CPU 2.13GHz 2007-12-03T07:50:25Z INFO: update_vector_performances: Vectorization : DISABLED 2007-12-03T07:50:25Z INFO: update_vector_performances: Vector Processor : COMPILER DEFAULT 2007-12-03T07:50:25Z INFO: update_vector_performances: Vectorized Skinning : DISABLED Its detecting the presence of SSE2, but it refuses to use it. I don't understand why. I have confirmed that it IS in fact compiling in the SSE code. I've hacked around trying to force it to use SSE with no success. The vector initialization code is a rats nest of indirection. It enables SSE2 just fine compiled for x86-64. I don't see any x86-64 specific #defines so I don't understand why that makes the difference. Note that I've never seen it work in the official builds either, so its not just 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/20071203/f2b686b7/attachment.pgp From strata at virtual.net Mon Dec 3 00:20:27 2007 From: strata at virtual.net (Strata R Chalup) Date: Mon Dec 3 00:20:39 2007 Subject: [sldev] Re: Questions on the particle system Message-ID: <20071203002027.AHU42147@m1.imap-partners.net> "Erik Anderson" wrote: > Speaking as a random observer from the sidelines, it sounds > like what we need or are developing is something like the > psychoacoustic models that drive the heart of MP3 and make > it work so well... I'm newly following the sldev list. If folks aren't already using formal modeling for the particle effects in question, there may be value in looking at the academic modeling of effects. It's a very mature effort that has done a lot of work on reducing computational overhead. Early examples are James Blinn's work on modeling naturalistic effects via particle simulation. I have drifted out of the SIGGRAPH community lo these many years, but still recall being blown away by the smoke, fire, and water effects he pioneered there in the mid-80's. And it's only gotten better since then. Szeliski and Tonnesen have been doing work on more efficient algorithms for some of these things, too. Someday, perhaps, we'll stop uploading static textures for various things and call an algorithm library instead-- there's a great cite for particle-based modeling of fabric draping at http://portal.acm.org/citation.cfm?id=133994.134037 for instance. cheers, Strata / Maybear From tofu.linden at lindenlab.com Mon Dec 3 02:40:51 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Mon Dec 3 02:41:01 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196668956.17392.30.camel@localhost> References: <1196668956.17392.30.camel@localhost> Message-ID: <4753DD33.2090201@lindenlab.com> Linux? I got this hackily working on i386 Linux but I decided not to spend more time on it for these reasons: * Only the builds from gcc 3.4 were deployable in the wild due to over-zealous processor-specific optimizations in later GCC versions (i.e. non-SSE2 CPUs would get SSE2 code elsewhere), making this fragile. * When it worked, it benchmarked at between ~4% slower and ~4% faster than the pure-C++ versions on a Core2Duo and Celeron-D, so it didn't seem worth pushing for on i386. (Hardware skinners totally nullify any gain anyway, so even on machines where this was faster in SSE2 than pure-C++, a reasonable GPU can be significantly faster still). I expect that you're getting effort-free SSE2 support on x86-64 because -msse2 (the pivotal GCC flag!) is a GCC default there. Callum Lerwick wrote: > Okay, I've never ever seen vectorization work on any of my i386 > machines. > > ->mHasSSE: 1 > ->mHasSSE2: 1 > ->mHasAltivec: 0 > ->mCPUMhz: 2134 > ->mCPUString: Intel(R) Celeron(R) CPU 2.13GHz > > 2007-12-03T07:50:25Z INFO: update_vector_performances: Vectorization : DISABLED > 2007-12-03T07:50:25Z INFO: update_vector_performances: Vector Processor : COMPILER DEFAULT > 2007-12-03T07:50:25Z INFO: update_vector_performances: Vectorized Skinning : DISABLED > > Its detecting the presence of SSE2, but it refuses to use it. I don't > understand why. I have confirmed that it IS in fact compiling in the SSE > code. I've hacked around trying to force it to use SSE with no success. > The vector initialization code is a rats nest of indirection. > > It enables SSE2 just fine compiled for x86-64. I don't see any x86-64 > specific #defines so I don't understand why that makes the difference. > > Note that I've never seen it work in the official builds either, so its > not just me. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From seg at haxxed.com Mon Dec 3 03:31:38 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 3 03:31:50 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <4753DD33.2090201@lindenlab.com> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> Message-ID: <1196681498.17392.45.camel@localhost> On Mon, 2007-12-03 at 10:40 +0000, Tofu Linden wrote: > Linux? > > I got this hackily working on i386 Linux but I decided not to spend more > time on it for these reasons: > > * Only the builds from gcc 3.4 were deployable in the wild due to > over-zealous processor-specific optimizations in later GCC versions > (i.e. non-SSE2 CPUs would get SSE2 code elsewhere), making this fragile. My testing so far has not turned up such a problem. It is and has been compiling in the SSE stuff for as long as it has been in there, actually. I just don't understand whats stopping it from being enabled. I've figured out I can go into the Debug Settings editor and force it on. Profiling and disassembly with oprofile proves there's SSE code there, and its being run. As is, I seem to be getting about 3% better performance according to the internal perf test. My goal here is to see about bringing that up... > * When it worked, it benchmarked at between ~4% slower and ~4% > faster than the pure-C++ versions on a Core2Duo and Celeron-D, so > it didn't seem worth pushing for on i386. (Hardware skinners totally > nullify any gain anyway, so even on machines where this was faster > in SSE2 than pure-C++, a reasonable GPU can be significantly faster > still). The open source r300 drivers don't support this yet. -------------- 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/20071203/01caf88d/attachment.pgp From tofu.linden at lindenlab.com Mon Dec 3 04:19:31 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Mon Dec 3 04:19:44 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196681498.17392.45.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> Message-ID: <4753F453.7050705@lindenlab.com> Callum Lerwick wrote: > On Mon, 2007-12-03 at 10:40 +0000, Tofu Linden wrote: >> Linux? >> >> I got this hackily working on i386 Linux but I decided not to spend more >> time on it for these reasons: >> >> * Only the builds from gcc 3.4 were deployable in the wild due to >> over-zealous processor-specific optimizations in later GCC versions >> (i.e. non-SSE2 CPUs would get SSE2 code elsewhere), making this fragile. > > My testing so far has not turned up such a problem. It is and has been > compiling in the SSE stuff for as long as it has been in there, > actually. What testing? I thought you said you couldn't get this enabled on i386? Which part of the problem are you failing to reproduce? -tofu From dzonatas at dzonux.net Mon Dec 3 06:26:08 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Dec 3 06:25:57 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196668956.17392.30.camel@localhost> References: <1196668956.17392.30.camel@localhost> Message-ID: <47541200.5010908@dzonux.net> What is it you are trying to do and on what OS? The vectorization status you showed only provides indicators if particular vector-processor enabled routines are being called. There is only one set right now, and they are the avatar skinning for GPU's that don't have hardware skinning. If your GPU has skinning, those routines will not be enabled. Callum Lerwick wrote: > Okay, I've never ever seen vectorization work on any of my i386 > machines. > > ->mHasSSE: 1 > ->mHasSSE2: 1 > ->mHasAltivec: 0 > ->mCPUMhz: 2134 > ->mCPUString: Intel(R) Celeron(R) CPU 2.13GHz > > 2007-12-03T07:50:25Z INFO: update_vector_performances: Vectorization : DISABLED > 2007-12-03T07:50:25Z INFO: update_vector_performances: Vector Processor : COMPILER DEFAULT > 2007-12-03T07:50:25Z INFO: update_vector_performances: Vectorized Skinning : DISABLED > > Its detecting the presence of SSE2, but it refuses to use it. I don't > understand why. I have confirmed that it IS in fact compiling in the SSE > code. I've hacked around trying to force it to use SSE with no success. > The vector initialization code is a rats nest of indirection. > > It enables SSE2 just fine compiled for x86-64. I don't see any x86-64 > specific #defines so I don't understand why that makes the difference. > > Note that I've never seen it work in the official builds either, so its > not just me. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20071203/3d38adf7/attachment.htm From mitch at mckenzie.ws Mon Dec 3 06:35:51 2007 From: mitch at mckenzie.ws (Mitch McKenzie) Date: Mon Dec 3 06:35:56 2007 Subject: [sldev] Latest SL / Quicktime issue in the news... In-Reply-To: <1196681498.17392.45.camel@localhost> Message-ID: <4E5BF7A072614E7FA38BD42346F08121@halfassed2> Perhaps someone on this list would take a stab at explaining how this issue is an Apple issue and not a Second Life issue? Why would we expect Apple to understand the cash transfer system of SL in order to defeat this bug? As I understand it, this is an RTSP issue. Yet, before anyone can access my Linden account, they have to go through the LL servers do they not? So claiming this is solely a client side issue seems really odd to me as also the claim that "we are waiting on Apple to fix it", is really a goofy idea as well. As near as I can tell, the hacker is really just sending malicious code instead of an actual stream, this coode is somehow accessing the client and allowing lindens to be transferred without prior permission. What am I missing here? From mitch at mckenzie.ws Mon Dec 3 06:41:16 2007 From: mitch at mckenzie.ws (Mitch McKenzie) Date: Mon Dec 3 06:41:29 2007 Subject: [sldev] Latest SL / Quicktime issue in the news... In-Reply-To: <4E5BF7A072614E7FA38BD42346F08121@halfassed2> Message-ID: Sorry for the double posting, thought I pasted this link in last note.. http://www.mercurynews.com/business/ci_7609295?nclick_check=1 -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Mitch McKenzie Sent: Monday, December 03, 2007 8:36 AM To: sldev@lists.secondlife.com Subject: [sldev] Latest SL / Quicktime issue in the news... Perhaps someone on this list would take a stab at explaining how this issue is an Apple issue and not a Second Life issue? Why would we expect Apple to understand the cash transfer system of SL in order to defeat this bug? As I understand it, this is an RTSP issue. Yet, before anyone can access my Linden account, they have to go through the LL servers do they not? So claiming this is solely a client side issue seems really odd to me as also the claim that "we are waiting on Apple to fix it", is really a goofy idea as well. As near as I can tell, the hacker is really just sending malicious code instead of an actual stream, this coode is somehow accessing the client and allowing lindens to be transferred without prior permission. What am I missing here? _______________________________________________ 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 Dec 3 06:48:42 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Dec 3 06:48:48 2007 Subject: [sldev] Latest SL / Quicktime issue in the news... In-Reply-To: <4E5BF7A072614E7FA38BD42346F08121@halfassed2> References: <4E5BF7A072614E7FA38BD42346F08121@halfassed2> Message-ID: <5D434946-D23F-48A1-82B9-792AA61181DB@gmail.com> On 03-Dec-2007, at 08:35, Mitch McKenzie wrote: > Perhaps someone on this list would take a stab at explaining how this > issue is an Apple issue and not a Second Life issue? The attack involves using a bug in Quicktime to inject software (actual binary machine code) into the copy of Quicktime running on your computer and trick Quicktime into running it. Once they are running their code on your computer they are "you" as far as your computer is concerned. They can do anything on your computer that you can, including patching the copy of Second Life running on your computer and sending commands from your logged in account as if you were making them. There is nothing Linden Labs can do about this other than disabling Quicktime streaming (and that is what I believe they should have done). From me at hamncheeseomlet.com Mon Dec 3 07:01:51 2007 From: me at hamncheeseomlet.com (Hamncheese) Date: Mon Dec 3 07:02:18 2007 Subject: [sldev] Latest SL / Quicktime issue in the news... In-Reply-To: <4E5BF7A072614E7FA38BD42346F08121@halfassed2> References: <4E5BF7A072614E7FA38BD42346F08121@halfassed2> Message-ID: <2E5A5E2E764A420F9E586E5BBF79431D@DreamStream> Just curious here because I'm a security newbie :): How'd you get from "may allow an attacker to crash or exploit the Second Life viewer" (from the blog) to "allowing lindens to be transferred without prior permission"? Am I missing some non public knowledge? Also have you seen this?: http://www.symantec.com/enterprise/security_response/weblog/2007/12/exploit_for_apple_quicktime_vu.html Symantec obviously thinks its Apple's problem as well. ----- Original Message ----- From: "Mitch McKenzie" To: Sent: Monday, December 03, 2007 9:35 AM Subject: [sldev] Latest SL / Quicktime issue in the news... > > > Perhaps someone on this list would take a stab at explaining how this > issue is an Apple issue and not a Second Life issue? Why would we expect > Apple to understand the cash transfer system of SL in order to defeat > this bug? As I understand it, this is an RTSP issue. Yet, before anyone > can access my Linden account, they have to go through the LL servers do > they not? So claiming this is solely a client side issue seems really > odd to me as also the claim that "we are waiting on Apple to fix it", is > really a goofy idea as well. As near as I can tell, the hacker is really > just sending malicious code instead of an actual stream, this coode is > somehow accessing the client and allowing lindens to be transferred > without prior permission. What am I missing here? > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dale at daleglass.net Mon Dec 3 07:48:06 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Dec 3 07:48:17 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: References: <200712022159.22637.dale@daleglass.net> <200712022253.26056.dale@daleglass.net> <6C711B3D-7589-4862-B342-09FFE14336AA@gmail.com> <200712030502.15713.dale@daleglass.net> Message-ID: <20071203154806.GA31525@bruno.sbruno> On Mon, Dec 03, 2007 at 12:05:36AM -0600, Argent Stonecutter wrote: > >I still think the area is the wrong approach. Things with large > >areas are > >usually uninteresting and don't lose that much from being toned down a > >bit. > > Most any particle system with a lot of particles in it doesn't lose > much from being toned down a bit. > > My "Stunt Double", however, only has 30 particles in it (one particle > per second, 30 second lifespan). Precisely why I think it shouldn't be prioritized by area. If you calculate by area, lots_of_particles * fairly_large_size adds up to a lot more than one big particle. Your effect, if it shows 1 particle on a given frame, is tiny as far as I'm concerned compared to the screenshot. > That effect is at zero distance from the camera: you're inside it. No, because I currently calculate based on the distance to the emitter. Distance is not zero unless it's right in front of my camera. > > >Besides, in the current codebase this is going to be counted even > >if it's > >happening somewhere out of your view. > > Which it should. I still haven't managed to get an explanation of *why*. I did benchmarks. The time spent tracking off-screen particles seems insignificant, unless I'm missing something. -------------- 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/20071203/3bddbfa4/attachment.pgp From tateru.nino at gmail.com Mon Dec 3 07:59:13 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Dec 3 08:02:53 2007 Subject: [sldev] Latest SL / Quicktime issue in the news... In-Reply-To: References: Message-ID: <475427D1.4060709@gmail.com> It's a fairly standard sort of buffer-overrun/code-injection exploit as I understand it - which means they can fool quicktime into running arbitrary code (provided at the time of the attack) or leverage that to repurpose whatever software Quicktime is running as a component of (I expect your web-browser could well be 'maliciously repurposed' by a carefully constructed quicktime stream as well). At present, so far as we are aware, the only proof-of-concept exploit exists to use the bug in quicktime to repurpose the SL viewer while the SL viewer is utilizing quicktime as a component. Short version: If you are including third-party software as an integral part of your thread-of-execution, it's security problems become your security problems. Any of that help? Mitch McKenzie wrote: > Sorry for the double posting, thought I pasted this link in last note.. > > http://www.mercurynews.com/business/ci_7609295?nclick_check=1 > > > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Mitch McKenzie > Sent: Monday, December 03, 2007 8:36 AM > To: sldev@lists.secondlife.com > Subject: [sldev] Latest SL / Quicktime issue in the news... > > > > Perhaps someone on this list would take a stab at explaining how this > issue is an Apple issue and not a Second Life issue? Why would we expect > Apple to understand the cash transfer system of SL in order to defeat > this bug? As I understand it, this is an RTSP issue. Yet, before anyone > can access my Linden account, they have to go through the LL servers do > they not? So claiming this is solely a client side issue seems really > odd to me as also the claim that "we are waiting on Apple to fix it", is > really a goofy idea as well. As near as I can tell, the hacker is really > just sending malicious code instead of an actual stream, this coode is > somehow accessing the client and allowing lindens to be transferred > without prior permission. What am I missing here? > > _______________________________________________ > 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 dzonatas at dzonux.net Mon Dec 3 09:04:03 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Dec 3 09:03:51 2007 Subject: [sldev] Heads up - we're working on CMake (and more) In-Reply-To: <1674f6c70712021732q5bb13ee9u66b3d5338f7fefce@mail.gmail.com> References: <474DD454.3090005@lindenlab.com> <1ds9dY5ds4f14ei4dxiGGdL.alissa_sabre@yahoo.co.jp> <474F2CA2.9010002@lindenlab.com> <74esdds7G74dz4G15dx4L1.alissa_sabre@yahoo.co.jp> <1674f6c70712021732q5bb13ee9u66b3d5338f7fefce@mail.gmail.com> Message-ID: <47543703.1030400@dzonux.net> Erik Anderson wrote: > With so many requests for the CMake scripts, I get the impression that > a lot of people are dependent on these script in order to more easily > build the viewer. Why is the entire opensource effort being tied to a > developer working on something that is not the main development focus > right now? If there was a strong need for these files, I'm sure that > there would be half a dozen versions floating around that could be > submitted or used in the interim, such an effort could probably help > as it would show potential gotchas and issues that need to be dealt > with before such a build process could be adopted. I mean heck we've > even got the guy that wrote the program in here. I mentioned to Hoffman that it would be a blessing for SCons, CMake, and Ant developers to collaborate. Such collaboration surely solve the issues when/if it happens. Each has a very powerful aspect to add to the build process. For now, we can do use two or more to get the job done where it matches every bodies needs. Ant is nice for its easy IDE integration. It is mainly suited for Java, however. Any non-java work involves custom ant tasks. However, such ant tasks could be simply a task to keep file lists up to date from the IDE. Then the actual builder can vary. CMake is good to create project files specific to an IDE. It also has some installation procedures that can be used; however, a package like InstallJammer is even more robust then CMake's installer. CMake requires C++ for more in depth customization, so there is some worry there that not everything can be done with just langauge CMake uses. CMake doesn't actually do the build process, as it is only as good as the builders provided with the system for which it create project files to use. SCons is the more programmatic builder. I get the gist that people generally don't like SCons because of the need to understand the programmability of it. In regards to CMake, however, the effort becomes similar to work out any in depth customization to CMake. In comparison, CMake presents a Makefile-like script, and many are use to that feel. SCons, with python being an intrinsic environment, means that any in-depth customization is easily portable to any system that supports python. SCons has a bit of a learning curve to understand the dependencies, but SCons has by far the best dependency tree than any other builder I've seen. SCons is also very smart with what it knows to build with signature checks. The database it uses can easily be shared across the network for distributed builds. SCons can also be made to call CMake to use the power features of CMake. As for LL and the jumpy bit, I say people need to think a bit more positive. When developers invest a lot of time to their work for reasons they believe was the right investment, they hate to see it tossed aside or push to the street for no reason -- or at least for no reason being stated. It pisses people off one way or another. The obvious solution is to collaborate more. I understand if people are skeptical that collaboration is not so easy. I truly see employees of LL truly try to collaborate and integrate with the open source community or at least in the principles and philosophy of open source, but I can't say every employee does such. That is true for other businesses than just LL. Hell, I remember when I had to take on my own action of procurement and the responsibility for such action just to get the Internet into the (very big) business I worked at before 1995, the Internet boom. I used to access all the powerful tools that people collaborated on together. If you remember, most businesses despised the Internet before 1995. Things have change big time very quickly. With the dot com explosion, it was like a sudden "likeness." -- Power to Change the Void From phoenix at secondlife.com Mon Dec 3 09:10:14 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Dec 3 09:10:31 2007 Subject: [sldev] VWR-1475 stalled? (OpenJPEG lossy patch) In-Reply-To: <1195854943.14235.21.camel@localhost> References: <1195854943.14235.21.camel@localhost> Message-ID: I checked on the QA pipeline, and this was merged into a branch that is the current 'maintenance' branch. That branch is not yet locked, and will probably be locked as soon as the previous maintenance branch is merged. I don't have an exact timeframe, but this will probably be merged into the release candidate by the end of the year. On 2007-11-23, at 13:55, Callum Lerwick wrote: > VWR-1475 still hasn't been merged near as I can tell. I uploaded a new > version that uses the new "reversible" flag. This gets rid of the > hidden > preference hack and should be mergeable as-is now. Please do so. :) -------------- 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/20071203/1fe0ae38/PGP.pgp From phoenix at secondlife.com Mon Dec 3 09:20:18 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Dec 3 09:20:43 2007 Subject: [sldev] Is it possible to increase the network timeout? In-Reply-To: <200712011816.20281.dale@daleglass.net> References: <200712011816.20281.dale@daleglass.net> Message-ID: <7222822A-EF2D-4CC3-B154-5FB973C9FADA@secondlife.com> It certainly is problematic to debug the viewer and stay connected. The downside of this is that it leads to login problems when you actually crash and try to get back in before the sim has disconnected you. It can also lead to an awkward social situation when there are dead avatars hanging out for a minute or two. If the message system had per-circuit timeouts, I could add a capability to request a longer timeout. Up for looking into adding variable circuit timeout duration? On 2007-12-01, at 09:16, Dale Glass wrote: > Debugging the viewer is a bit of a pain when it redmaps if spend a > while > examining things in the debugger. > > Any way to increase the amount of time the viewer can be non- > responsive? > > The time it takes to get back in is also annoying. Any chance it > could be > eliminated or at least reduced on a test grid? > -------------- 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/20071203/0f79c6a2/PGP.pgp From robin.cornelius at gmail.com Mon Dec 3 10:44:11 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Dec 3 10:40:22 2007 Subject: [sldev] Running SL on 16-bit color setting In-Reply-To: <7992d0d60712021539ne4a69d9qcebd35dc867086e1@mail.gmail.com> References: <1196401038.3426.14.camel@localhost> <319E8B9F-1298-4B4F-96C9-FB06B3F35135@gmail.com> <7992d0d60712021539ne4a69d9qcebd35dc867086e1@mail.gmail.com> Message-ID: <47544E7B.6040205@gmail.com> Dirk Moerenhout wrote: >> As most people knows, SL uses OpenGL and supports OS X and Linux as well. >> So, porting on mobile devices, that support OpenGL ES, is not so difficult. >> Yes.. still has many issues to resolve, memory optimization is an example. >> And 32-bit color dependent code is also one of the issues. > > I don't know OpenGL ES but how does it handle alpha blending? Images > are stored in 32-bit but only 24 bits are used for color, remainder is > alpha and is used within SL. I guess the first thing you'd need to > consider would be how to convert all the content you receive to the > proper format. Does OpenGL ES rendering 32-bit encoded images on a > 16-bit display and if so, does it handle the alpha correctly? > OpenGL ES 1.1 seems to support 32but ARGB. Some random info and tutorials aimed at a Sony platform, but hey might be handy;- http://developer.sonyericsson.com/site/global/newsandevents/latestnews/newsoct06/p_3dhardwareaccgraphics_opengles_uiq3phones.jsp Robin -------------- 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/20071203/0a45bfb5/signature.pgp From secret.argent at gmail.com Mon Dec 3 10:52:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Dec 3 10:52:28 2007 Subject: [sldev] Re: Questions on the particle system In-Reply-To: <20071203154806.GA31525@bruno.sbruno> References: <200712022159.22637.dale@daleglass.net> <200712022253.26056.dale@daleglass.net> <6C711B3D-7589-4862-B342-09FFE14336AA@gmail.com> <200712030502.15713.dale@daleglass.net> <20071203154806.GA31525@bruno.sbruno> Message-ID: <259E6815-ED1F-45E2-9709-AA8EBC4B406F@gmail.com> On 03-Dec-2007, at 09:48, Dale Glass wrote: > Precisely why I think it shouldn't be prioritized by area. If you > calculate by area, lots_of_particles * fairly_large_size adds up to a > lot more than one big particle. AH. Miscommunication. We're not talking about the same area. I'm talking about the angle subtended by the entire particle system, the area it covers on the screen. At a first approximation that would be done by finding the greatest of the velocity times the lifetime or the emitter radius, adding the major axis of the particle, squaring, and dividing by distance squared. I'm not sure the number of particles even needs to be involved here. >> That effect is at zero distance from the camera: you're inside it. > No, because I currently calculate based on the distance to the > emitter. Yeh, I grok that. I'm suggesting that's not necessarily the right approach. If you're inside the particle system it should be given the same priority whether the emitter's 5 meters or 1 meter away. From tlang303 at gmail.com Mon Dec 3 10:56:25 2007 From: tlang303 at gmail.com (Tobias Lang) Date: Mon Dec 3 10:56:29 2007 Subject: [sldev] How to get rid of the console window? Message-ID: <66bc8ec50712031056o24290b50gbba1d795c668f915@mail.gmail.com> Hi, When I am using my compiled client, I always have a windows-console with debug information appearing along my SL window. This is nice for debugging, but how can I get it of it for normal use? I tried different "secondlife setup build.bat" settings but it doesn't seem to have an influence on this? I have the impression that not every SL code release has an appearing console. How can I control this? Thanks, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071203/d5b5f4e6/attachment.htm From rdw at lindenlab.com Mon Dec 3 11:10:06 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Dec 3 11:12:48 2007 Subject: [sldev] Latest SL / Quicktime issue in the news... In-Reply-To: <2E5A5E2E764A420F9E586E5BBF79431D@DreamStream> References: <4E5BF7A072614E7FA38BD42346F08121@halfassed2> <2E5A5E2E764A420F9E586E5BBF79431D@DreamStream> Message-ID: <4754548E.7000007@lindenlab.com> The Slashdot article regrettably told the story of some sort of SL-specific exploit, instead of recognizing that the QT bug allows pretty much any exploit. http://games.slashdot.org/article.pl?sid=07/12/02/0640203 -RYaN Hamncheese wrote: > Just curious here because I'm a security newbie :): How'd you get from > "may allow an attacker to crash or exploit the Second Life viewer" (from > the blog) to "allowing lindens to be transferred without prior > permission"? Am I missing some non public knowledge? Also have you seen > this?: > http://www.symantec.com/enterprise/security_response/weblog/2007/12/exploit_for_apple_quicktime_vu.html > > > Symantec obviously thinks its Apple's problem as well. > > > ----- Original Message ----- From: "Mitch McKenzie" > To: > Sent: Monday, December 03, 2007 9:35 AM > Subject: [sldev] Latest SL / Quicktime issue in the news... > > >> >> >> Perhaps someone on this list would take a stab at explaining how this >> issue is an Apple issue and not a Second Life issue? Why would we expect >> Apple to understand the cash transfer system of SL in order to defeat >> this bug? As I understand it, this is an RTSP issue. Yet, before anyone >> can access my Linden account, they have to go through the LL servers do >> they not? So claiming this is solely a client side issue seems really >> odd to me as also the claim that "we are waiting on Apple to fix it", is >> really a goofy idea as well. As near as I can tell, the hacker is really >> just sending malicious code instead of an actual stream, this coode is >> somehow accessing the client and allowing lindens to be transferred >> without prior permission. What am I missing here? >> >> _______________________________________________ >> 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 seg at haxxed.com Mon Dec 3 12:02:23 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 3 12:02:34 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <4753F453.7050705@lindenlab.com> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> Message-ID: <1196712143.17392.86.camel@localhost> On Mon, 2007-12-03 at 12:19 +0000, Tofu Linden wrote: > > My testing so far has not turned up such a problem. It is and has been > > compiling in the SSE stuff for as long as it has been in there, > > actually. > > What testing? I thought you said you couldn't get this enabled on i386? > Which part of the problem are you failing to reproduce? The viewer runs, and always has run on my Athlon T-bird just fine. And I've run it on my dual PII 333 system. If it were leaking SSE code into places it shouldn't, I would have run into it by now. Dur, I just realized what the difference is. viewer.cpp does not have an _sse tag, so SConstruct does NOT compile it with SSE enabled on i386, which means llv4math.h does NOT set LL_VECTORIZE, which means the bit of code in there than enables SSE when available is NOT compiled in. I hope you realize all the rest of the vector stuff is either not wrapped in LL_VECTORIZE, such as llviewerjointmesh.cpp where the performance test is, or has _sse/_sse2/_vec tags and thus IS getting compiled: linden.patched/indra/newview/llviewerjointmesh_sse2.cpp:#if LL_VECTORIZE linden.patched/indra/newview/viewer.cpp:#if LL_VECTORIZE linden.patched/indra/newview/llviewerjointmesh_sse.cpp:#if LL_VECTORIZE So we (or at least I, I have not disassembled an LL build yet) have in fact been compiling in the SSE code *all along*, and have only been missing the little bit of code that enables it at runtime when available. This is a one liner: --- linden.orig/indra/newview/viewer.cpp 2007-12-03 03:53:00.000000000 -0600 +++ linden.patched/indra/newview/viewer.cpp 2007-12-03 13:12:08.000000000 -0600 @@ -4808,7 +4808,7 @@ gHandleKeysAsync = gSavedSettings.getBOOL("AsyncKeyboard"); LLHoverView::sShowHoverTips = gSavedSettings.getBOOL("ShowHoverTips"); -#if LL_VECTORIZE +#if 1 || LL_VECTORIZE if (gSysCPU.hasAltivec()) { gSavedSettings.setBOOL("VectorizeEnable", TRUE ); Bam, hello SSE: 2007-12-03T19:33:44Z INFO: update_vector_performances: Vectorization : ENABLED 2007-12-03T19:33:44Z INFO: update_vector_performances: Vector Processor : SSE2 2007-12-03T19:33:44Z INFO: update_vector_performances: Vectorized Skinning : DISABLED 2007-12-03T19:36:53Z INFO: updateGeometry: run averages (1/10) vectorize off 1.18422% : vectorize type 2 1.23795% : performance boost 7.59775% And it still runs on the T-bird. Looks like Fedora users are getting SSE. :) -------------- 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/20071203/474077f1/attachment.pgp From seg at haxxed.com Mon Dec 3 12:03:52 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 3 12:04:03 2007 Subject: [sldev] Latest SL / Quicktime issue in the news... In-Reply-To: <4E5BF7A072614E7FA38BD42346F08121@halfassed2> References: <4E5BF7A072614E7FA38BD42346F08121@halfassed2> Message-ID: <1196712232.17392.87.camel@localhost> Please don't hijack threads. -------------- 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/20071203/8440d42a/attachment.pgp From tofu.linden at lindenlab.com Mon Dec 3 12:13:52 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Mon Dec 3 12:14:04 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196712143.17392.86.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> Message-ID: <47546380.5070401@lindenlab.com> Callum Lerwick wrote: >> What testing? I thought you said you couldn't get this enabled on i386? >> Which part of the problem are you failing to reproduce? > > The viewer runs, and always has run on my Athlon T-bird just fine. And > I've run it on my dual PII 333 system. If it were leaking SSE code into > places it shouldn't, I would have run into it by now. It must be a bad brain day for me, because I still don't understand; the viewer runs and has always run on the Athlon because SSE code isn't enabled on i386 builds by default (and we happen to prefer GCC 3.4 for now which doesn't leak SSE code), which I thought was the whole point of this thread. From dzonatas at dzonux.net Mon Dec 3 13:49:37 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Dec 3 13:49:20 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196712143.17392.86.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> Message-ID: <475479F1.40501@dzonux.net> Callum Lerwick wrote: > -#if LL_VECTORIZE > +#if 1 || LL_VECTORIZE > Good work! One should just erase those lines of the #if-n-#endif hack that shows such horrible lack of trust -- erase it completely -- especially the one marked with the negative sign. =) -- Power to Change the Void From robin.cornelius at gmail.com Mon Dec 3 13:53:08 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Dec 3 13:53:15 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <47546380.5070401@lindenlab.com> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> Message-ID: On Dec 3, 2007 8:13 PM, Tofu Linden wrote: > Callum Lerwick wrote: > >> What testing? I thought you said you couldn't get this enabled on i386? > >> Which part of the problem are you failing to reproduce? > > > > The viewer runs, and always has run on my Athlon T-bird just fine. And > > I've run it on my dual PII 333 system. If it were leaking SSE code into > > places it shouldn't, I would have run into it by now. > > It must be a bad brain day for me, because I still don't understand; > the viewer runs and has always run on the Athlon because SSE code isn't > enabled on i386 builds by default (and we happen to prefer GCC 3.4 for > now which doesn't leak SSE code), which I thought was the whole point > of this thread. I think Callum's point is the SSE code is all there in the binary, its only the initial test in viewer.cpp that is hidden in a #define. As this test works on the linux cpu string anyway it might just as well be tested. Right i'm going to upset the Debian users now too! Robin From seg at haxxed.com Mon Dec 3 14:07:18 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 3 14:07:40 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <47546380.5070401@lindenlab.com> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> Message-ID: <1196719638.18776.4.camel@localhost> On Mon, 2007-12-03 at 20:13 +0000, Tofu Linden wrote: > Callum Lerwick wrote: > >> What testing? I thought you said you couldn't get this enabled on i386? > >> Which part of the problem are you failing to reproduce? > > > > The viewer runs, and always has run on my Athlon T-bird just fine. And > > I've run it on my dual PII 333 system. If it were leaking SSE code into > > places it shouldn't, I would have run into it by now. > > It must be a bad brain day for me, because I still don't understand; > the viewer runs and has always run on the Athlon because SSE code isn't > enabled on i386 builds by default (and we happen to prefer GCC 3.4 for > now which doesn't leak SSE code), which I thought was the whole point > of this thread. You seem confused about what I mean when I say "enabled". The whole point of this thread is the SSE code is *there*, its getting compiled into the viewer. Compiling the SSE code is *not* disabled under gcc. Only under MSVC. The comments in llv4math.h and llviewerjointmesh_sse2.cpp indicate this is the intention. SSE is not compiled at all on "Windows". Though this would be another case of saying "Windows" when you really mean MSVC... By "enabled" in this thread I mean enabling the SSE code at *runtime*. That is the problem. Which is what I have fixed. I'm not sure what you're meaning by "not enabled", if you're saying its "not enabled" as in "not compiled in at all", you're wrong. :) I'm compiling with Fedora 8's gcc 4.1.2, and I've never run in to any SSE leakage problems. -------------- 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/20071203/7635b355/attachment.pgp From monkowsk at watson.ibm.com Mon Dec 3 14:30:43 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Dec 3 14:30:56 2007 Subject: [sldev] Heads up - we're working on CMake In-Reply-To: <1674f6c70712021732q5bb13ee9u66b3d5338f7fefce@mail.gmail.com> References: <474DD454.3090005@lindenlab.com> <1ds9dY5ds4f14ei4dxiGGdL.alissa_sabre@yahoo.co.jp> <474F2CA2.9010002@lindenlab.com> <74esdds7G74dz4G15dx4L1.alissa_sabre@yahoo.co.jp> <1674f6c70712021732q5bb13ee9u66b3d5338f7fefce@mail.gmail.com> Message-ID: <47548393.10508@watson.ibm.com> Erik Anderson wrote: > I know that personally before I would > release something as opensource I would make sure that I actually had > something to provide ( i.e. it actually compiled and did a basic job of > what it was trying to do) otherwise there wouldn't be much purpose to > throwing the code into the void. I don't get the impression that this > CMake effort is up to this point, although there is (or was) some > excitement that this would occur soon. As the bard said, "Aye, there's the rub." SL open source compiles on VS2003. I have VS6, VS2005 Express, and I could get VS2008 Express if I dared. I, too, am used to having open source actually compile. It only compiles on the one I (and I imagine many other developers) don't have. You say "patch or leave." I would love to patch. I can't even compile without hacking the project files for every new release. After doing it a few times, you just get tired of it. Yes, I am excited that CMake will make my life easier. Yes, I am excited that Bryan is working on it. And grateful, too. But it's just ever so tantilizingly out of reach. Frustration. Yep, that's what I'd call it. Mike From seg at haxxed.com Mon Dec 3 14:36:50 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 3 14:37:01 2007 Subject: [sldev] Running SL on 16-bit color setting In-Reply-To: <475300AD.8080501@gmail.com> References: <475300AD.8080501@gmail.com> Message-ID: <1196721410.18776.14.camel@localhost> On Sun, 2007-12-02 at 13:59 -0500, Jason Giglio wrote: > Bok-yeon Lee wrote: > > So my question is 'Does viewer has any 32-bit color dependent code?'. > > The picking render probably depends on 32 bit... you may have to rewrite > the picking code to make it work with 16 bit. I'm scared to ask, but how does the picking code work? Is it using stencils? I know on the TNT2, you only got a hardware stencil if you were in 32-bit color. The hardware did not support stencils in 16-bit color. The TNT2 of course is completely obsolete and I have no idea how much this limitation still applies to newer hardware. As 32-bit has been the norm for some time now, I suspect manufacturers aren't bothering to implement advanced features in 16-bit color. 16-bit color also tends to come with a reduced accuracy z-buffer as well. Which can result in ugly rendering errors. I guess the thing to do is hack the viewer to start up in 16-bit color, and see what breaks. :) -------------- 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/20071203/5f090020/attachment.pgp From dzonatas at dzonux.net Mon Dec 3 14:40:38 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Dec 3 14:40:23 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196719638.18776.4.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> Message-ID: <475485E6.2040708@dzonux.net> Callum Lerwick wrote: > You seem confused about what I mean when I say "enabled". The whole > point of this thread is the SSE code is *there*, its getting compiled > into the viewer. Compiling the SSE code is *not* disabled under gcc. > Only under MSVC. The comments in llv4math.h and > llviewerjointmesh_sse2.cpp indicate this is the intention. SSE is not > compiled at all on "Windows". Though this would be another case of > saying "Windows" when you really mean MSVC... > > By "enabled" in this thread I mean enabling the SSE code at *runtime*. There is a way to enable this into the runtime on MSVC. It's true that MSVC leaks SSE, but it is also true that it can be isolated. For some reason, there is a patch to isolated it, but it never has been applied. It has actually been tested many times, so it works -- even on the machines that it doesn't allow SL to run on when not isolated. The only worry is that the implementation used STL strings to aid in isolation, but the STL strings need to be replaced with C strings to make it work on Vista. (don't ask why) There is also another patch that speeds up the avatar skinning by up to an additional 10% just by untangling a few headers and a couple of in-line code moves. It is found with code related to the llpolyskeletaldistortion patch: https://jira.secondlife.com/browse/VWR-1812 ..."This is too complicated and fragile for us to take, I'm afraid." ? *shrugs* ? -- Power to Change the Void From seg at haxxed.com Mon Dec 3 15:05:23 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 3 15:05:34 2007 Subject: [sldev] Heads up - we're working on CMake In-Reply-To: <1674f6c70712021732q5bb13ee9u66b3d5338f7fefce@mail.gmail.com> References: <474DD454.3090005@lindenlab.com> <1ds9dY5ds4f14ei4dxiGGdL.alissa_sabre@yahoo.co.jp> <474F2CA2.9010002@lindenlab.com> <74esdds7G74dz4G15dx4L1.alissa_sabre@yahoo.co.jp> <1674f6c70712021732q5bb13ee9u66b3d5338f7fefce@mail.gmail.com> Message-ID: <1196723123.18776.18.camel@localhost> On Sun, 2007-12-02 at 17:32 -0800, Erik Anderson wrote: > I do see a lot of excitement here regarding the new build scripts, but > a lot of it reminds me of a pop star getting mobbed by his/her fans > and getting torn to shreds. Which confuses the heck out of me. What > ever happened to the "patch or leave" attitude I was hearing before? > It had plenty of negative connotations and its own toxicity, but at > the moment it seems more healthy than this junk... We all wrote our patches and getting them merged has turned out to be a long painful process? -------------- 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/20071203/0e3a4a3d/attachment.pgp From seg at haxxed.com Mon Dec 3 15:20:19 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 3 15:20:36 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <475485E6.2040708@dzonux.net> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> <475485E6.2040708@dzonux.net> Message-ID: <1196724020.18776.26.camel@localhost> On Mon, 2007-12-03 at 14:40 -0800, Dzonatas wrote: > There is also another patch that speeds up the avatar skinning by up > to > an additional 10% just by untangling a few headers and a couple of > in-line code moves. It is found with code related to the > llpolyskeletaldistortion patch: Could you maybe just untangle the basic optimizations from everything else? The inlining of getter functions is a no-brainer. It looks like LL is not going to take a giant ball of patches. I can't really blame them. You're going to have to spoonfeed it to them a bit at a time. Small, focused patches. -------------- 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/20071203/3be94476/attachment.pgp From dzonatas at dzonux.net Mon Dec 3 15:49:12 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Dec 3 15:49:22 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196724020.18776.26.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> <475485E6.2040708@dzonux.net> <1196724020.18776.26.camel@localhost> Message-ID: <475495F8.8050507@dzonux.net> Callum Lerwick wrote: > On Mon, 2007-12-03 at 14:40 -0800, Dzonatas wrote: > >> There is also another patch that speeds up the avatar skinning by up >> to >> an additional 10% just by untangling a few headers and a couple of >> in-line code moves. It is found with code related to the >> llpolyskeletaldistortion patch: >> > > Could you maybe just untangle the basic optimizations from everything > else? The inlining of getter functions is a no-brainer. > Mmhmm > It looks like LL is not going to take a giant ball of patches. I can't > really blame them. You're going to have to spoonfeed it to them a bit at > a time. Small, focused patches. > We know that leads to patching blindly. We don't get to see the internal branch to see how it actually got applied. At that point, there is no way for us to guarantee any further patches applied to an internal branch do work as intended. The sandbox branch (external svn) has been intended to help solve that. It doesn't provide the best means to do bulk patches and merges, but at least we all get to see what we collaborate on together. I'm surprised there isn't an external svn branch to help add CMake to the build. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071203/54b69050/attachment.htm From gigstaggart at gmail.com Mon Dec 3 16:19:27 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Dec 3 16:18:37 2007 Subject: [sldev] Running SL on 16-bit color setting In-Reply-To: <1196721410.18776.14.camel@localhost> References: <475300AD.8080501@gmail.com> <1196721410.18776.14.camel@localhost> Message-ID: <47549D0F.1020106@gmail.com> Callum Lerwick wrote: > On Sun, 2007-12-02 at 13:59 -0500, Jason Giglio wrote: >> Bok-yeon Lee wrote: >>> So my question is 'Does viewer has any 32-bit color dependent code?'. >> The picking render probably depends on 32 bit... you may have to rewrite >> the picking code to make it work with 16 bit. > > I'm scared to ask, but how does the picking code work? Is it using > stencils? It's using several different methods, depending on what kind of picking you are doing. One uses a picking buffer (that yes, would probably break on non-32-bit), the other uses a traced ray collision. My camera patch really cleans up this traced ray collision code so that it's accurate, it's being munged all the hell right now in the name of second guessing where the user meant to click. -Jason From seg at haxxed.com Mon Dec 3 22:09:22 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 3 22:09:35 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196719638.18776.4.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> Message-ID: <1196748563.20211.4.camel@localhost> On Mon, 2007-12-03 at 16:07 -0600, Callum Lerwick wrote: > By "enabled" in this thread I mean enabling the SSE code at *runtime*. > That is the problem. Which is what I have fixed. I'm not sure what > you're meaning by "not enabled", if you're saying its "not enabled" as > in "not compiled in at all", you're wrong. :) Ooooh wait, more "dur" info. The preprocessor logic in llv4math.h looks like this: #if LL_GNUC && __GNUC__ >= 4 && __SSE__ #define LL_VECTORIZE 1 So, since LL is clinging to gcc 3, SSE *is* in fact disabled in LL builds. But all of us compiling with gcc 4 have been getting SSE. :) -------------- 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/20071204/21901050/attachment.pgp From gigstaggart at gmail.com Mon Dec 3 23:39:20 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Dec 3 23:38:27 2007 Subject: [sldev] www.sljirastats.com launched! Message-ID: <47550428.6000401@gmail.com> Rob called a while back for someone to compile periodic stats on Jira. I took this idea and kinda ran with it, and http://www.sljirastats.com/ was born. Features: * Advanced Jira Search, faster (I hope!) and more powerful than the built in Jira search. The UI still needs some work, but it's pretty easy to construct very detailed queries. * Natural language date parser: Try "created" "is greater than" "two weeks ago" for example. * Save and share searches. Here's an example, this search is for unimported Open Patches: http://www.sljirastats.com/jira_search.php?search=27 To make your own shared searches, just click the "save search" button and you'll get a permalink in your address bar. * Statistics: As the site name implies, it does statistics too. :) At a glance Top 5 issues: Hot Issues This Week, by comments Hot Issues Today, by comments Most Hated Bugs Most Wanted Features Top Commenters Top Bug Reporters Graphs: Fixed Internally Open Bugs Open Patches Jira Participants (total) Updated Issues (per day) I'll be adding and removing statistics over the next few weeks as I refine the site. -Jason From alexander.treptow at zweitgeist.com Tue Dec 4 00:14:56 2007 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Tue Dec 4 00:15:15 2007 Subject: [sldev] How to get rid of the console window? Message-ID: <47550C80.40407@zweitgeist.com> Maybe this helps you. This part of code is in the main function in viewer.cpp next to line 1635 // pop up debug console if necessary #if LL_WINDOWS if (gUseConsole && gSavedSettings.getBOOL("ShowConsoleWindow")) { create_console(); } #endif gUseConsole is initialy set next to line 548. But you can also use the precompiler to edit this to: #if LL_WINDOWS && RELEASE_FOR_DOWNLOAD if (gUseConsole && gSavedSettings.getBOOL("ShowConsoleWindow")) { create_console(); } #endif this should only show the console window for release no opt greets, Alex From tateru.nino at gmail.com Tue Dec 4 00:29:17 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Dec 4 00:32:17 2007 Subject: [sldev] Is it possible to increase the network timeout? In-Reply-To: <7222822A-EF2D-4CC3-B154-5FB973C9FADA@secondlife.com> References: <200712011816.20281.dale@daleglass.net> <7222822A-EF2D-4CC3-B154-5FB973C9FADA@secondlife.com> Message-ID: <47550FDD.7090708@gmail.com> Phoenix wrote: > It certainly is problematic to debug the viewer and stay connected. > The downside of this is that it leads to login problems when you > actually crash and try to get back in before the sim has disconnected > you. It can also lead to an awkward social situation when there are > dead avatars hanging out for a minute or two. We get all those already. > > If the message system had per-circuit timeouts, I could add a > capability to request a longer timeout. Up for looking into adding > variable circuit timeout duration? > > > On 2007-12-01, at 09:16, Dale Glass wrote: >> Debugging the viewer is a bit of a pain when it redmaps if spend a >> while >> examining things in the debugger. >> >> Any way to increase the amount of time the viewer can be non-responsive? >> >> The time it takes to get back in is also annoying. Any chance it >> could be >> eliminated or at least reduced on a test grid? >> > ------------------------------------------------------------------------ > > _______________________________________________ > 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 dzonatas at dzonux.net Tue Dec 4 02:50:38 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 4 02:52:36 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196748563.20211.4.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> <1196748563.20211.4.camel@localhost> Message-ID: <475530FE.5030603@dzonux.net> Callum Lerwick wrote: > On Mon, 2007-12-03 at 16:07 -0600, Callum Lerwick wrote: > >> By "enabled" in this thread I mean enabling the SSE code at *runtime*. >> That is the problem. Which is what I have fixed. I'm not sure what >> you're meaning by "not enabled", if you're saying its "not enabled" as >> in "not compiled in at all", you're wrong. :) >> > > Ooooh wait, more "dur" info. The preprocessor logic in llv4math.h looks > like this: > > #if LL_GNUC && __GNUC__ >= 4 && __SSE__ > #define LL_VECTORIZE 1 > > So, since LL is clinging to gcc 3, SSE *is* in fact disabled in LL > builds. But all of us compiling with gcc 4 have been getting SSE. :) > Yep. GCC 3 and 4 handle the default vector type differently. We could probably put GCC 3.3+, but it would need a few test runs to make sure it still works the same. I believe we dropped all the GCC 4 specific code which was added originally to easily support the AltiVec. LL_VECTORIZE is boolean on to enable the vector code at compile-time. It should not have been used to include or exclude truth about processors for run-time. We need to trust the run-time detection or fix it if it is obviously wrong. The posted plan is to move the viewer to be more modular, and the run-time detection needs to be the truth for what are the best modules to use. There was a backwords step taken here. (Hence, C++ should not use #if-defs in static cpp implementation files unless it is for debug purposes, but there still is C style found here due to the Coding Style) For example, this kind of code is preferred: class gCompiler { bool getVectorize() { return( LL_VECTORIZE ); } } Dead-store and Dead-code removal will optimize away code like this: if( gCompiler.getVectorize() ) { doVectorizationStep(); } else { doNormalStep(); } Would that make less 'Dur'? It is more readable, only one branch is actually compiled, and there is the extra type check. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/0b505166/attachment-0001.htm From me at hamncheeseomlet.com Tue Dec 4 04:26:02 2007 From: me at hamncheeseomlet.com (Hamncheese) Date: Tue Dec 4 04:27:13 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47550428.6000401@gmail.com> References: <47550428.6000401@gmail.com> Message-ID: Nice work Jason. ----- Original Message ----- From: "Jason Giglio" To: "sldev" ; "Torley" Sent: Tuesday, December 04, 2007 2:39 AM Subject: [sldev] www.sljirastats.com launched! > Rob called a while back for someone to compile periodic stats on Jira. > > I took this idea and kinda ran with it, and http://www.sljirastats.com/ > was born. > > > Features: > > * Advanced Jira Search, faster (I hope!) and more powerful than the > built in Jira search. The UI still needs some work, but it's pretty > easy to construct very detailed queries. > > * Natural language date parser: > Try "created" "is greater than" "two weeks ago" for example. > > * Save and share searches. > Here's an example, this search is for unimported Open Patches: > http://www.sljirastats.com/jira_search.php?search=27 > > To make your own shared searches, just click the "save search" button > and you'll get a permalink in your address bar. > > > * Statistics: > As the site name implies, it does statistics too. :) > > At a glance Top 5 issues: > > Hot Issues This Week, by comments > Hot Issues Today, by comments > Most Hated Bugs > Most Wanted Features > Top Commenters > Top Bug Reporters > > Graphs: > Fixed Internally > Open Bugs > Open Patches > Jira Participants (total) > Updated Issues (per day) > > I'll be adding and removing statistics over the next few weeks as I > refine the site. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From tlang303 at gmail.com Tue Dec 4 06:24:25 2007 From: tlang303 at gmail.com (Tobias Lang) Date: Tue Dec 4 06:24:27 2007 Subject: [sldev] How to get rid of the console window? In-Reply-To: <47550C80.40407@zweitgeist.com> References: <47550C80.40407@zweitgeist.com> Message-ID: <66bc8ec50712040624w433f352aw9d10923326be96d2@mail.gmail.com> Great! That's explains it! Thanks. On Dec 4, 2007 3:14 AM, alexander treptow wrote: > Maybe this helps you. This part of code is in the main function in > viewer.cpp next to line 1635 > > // pop up debug console if necessary > #if LL_WINDOWS > if (gUseConsole && gSavedSettings.getBOOL("ShowConsoleWindow")) > { > create_console(); > } > #endif > > gUseConsole is initialy set next to line 548. > > But you can also use the precompiler to edit this to: > #if LL_WINDOWS && RELEASE_FOR_DOWNLOAD > if (gUseConsole && gSavedSettings.getBOOL("ShowConsoleWindow")) > { > create_console(); > } > #endif > > this should only show the console window for release no opt > > greets, > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/d5b12d87/attachment.htm From candide.lemay at gmail.com Tue Dec 4 06:31:09 2007 From: candide.lemay at gmail.com (Candide LeMay) Date: Tue Dec 4 06:31:12 2007 Subject: [sldev] Windlight 74642 sources? Message-ID: Hi, any ETA on releasing the latest windlight sources? From tulla at lindenlab.com Tue Dec 4 08:58:31 2007 From: tulla at lindenlab.com (Eric M. Tulla (BigPapi)) Date: Tue Dec 4 08:58:39 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: References: Message-ID: <47558737.9060200@lindenlab.com> We forgot to do take the extra manual steps. We'll be doing so shortly. Candide LeMay wrote: > Hi, > > any ETA on releasing the latest windlight sources? > _______________________________________________ > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Quidquid latine dictum sit, altum sonatur." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eric M. Tulla Graphics Programmer Linden Lab 1 Broadway Street, 14th Floor Cambridge, MA 02142 From monkowsk at watson.ibm.com Tue Dec 4 09:01:57 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Dec 4 09:02:12 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47550428.6000401@gmail.com> References: <47550428.6000401@gmail.com> Message-ID: <47558805.5@watson.ibm.com> > Top Bug Reporters > Reported Name > 70 Gigs Taggart > 70 Nicholaz Beresford > 60 Torley Linden > 55 Alissa Sabre > 48 Lex Neva I guess that makes you the top dog. :-) I like the tables on the left of the home page. The daily plots on the right don't do much for me. I meant to suggest this earlier, but I forgot. :-( Would it be difficult to show a table similar to a flipped accounts receivable ageing? In this case, the columns would be states, such as opened, closed duplicate, fixed internally, fixed, etc.. The rows would be the ageing: 0-1 week, 1-2 weeks, 2-3 weeks, 3-4 weeks, 0-1 month, 1-2 months, 2-3 months, 0-1 quarter, 1-2 quarters, 2-3 quarters, 3-4 quarters, 0-1 year, 1-2 years, 2-3 years, longer. Each item would be the number of issues that have been in that state for that amount of time. Does anyone else think this would be useful? Mike From phoenix at secondlife.com Tue Dec 4 09:06:43 2007 From: phoenix at secondlife.com (Phoenix) Date: Tue Dec 4 09:06:57 2007 Subject: [sldev] Is it possible to increase the network timeout? In-Reply-To: <47550FDD.7090708@gmail.com> References: <200712011816.20281.dale@daleglass.net> <7222822A-EF2D-4CC3-B154-5FB973C9FADA@secondlife.com> <47550FDD.7090708@gmail.com> Message-ID: On 2007-12-04, at 00:29, Tateru Nino wrote: > Phoenix wrote: >> It certainly is problematic to debug the viewer and stay connected. >> The downside of this is that it leads to login problems when you >> actually crash and try to get back in before the sim has disconnected >> you. It can also lead to an awkward social situation when there are >> dead avatars hanging out for a minute or two. > We get all those already. Are arguing for more? I think I have missed the point of your post. -------------- 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/20071204/8d344fc3/PGP.pgp From jhurliman at wsu.edu Tue Dec 4 09:28:00 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Dec 4 09:28:21 2007 Subject: [sldev] Is it possible to increase the network timeout? In-Reply-To: <200712011816.20281.dale@daleglass.net> References: <200712011816.20281.dale@daleglass.net> Message-ID: <47558E20.1010103@wsu.edu> Dale Glass wrote: > Debugging the viewer is a bit of a pain when it redmaps if spend a while > examining things in the debugger. > > Any way to increase the amount of time the viewer can be non-responsive? > > The time it takes to get back in is also annoying. Any chance it could be > eliminated or at least reduced on a test grid? > It might be possible to add buttons for sending AgentPause and AgentResume packets. John From tao.takashi at googlemail.com Tue Dec 4 09:34:35 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Dec 4 09:34:38 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: References: <47550428.6000401@gmail.com> Message-ID: <23bbb49e0712040934j593b8be1qdfb286bed65ce0db@mail.gmail.com> indeed, cool work! :-) -- Tao On Dec 4, 2007 1:26 PM, Hamncheese wrote: > Nice work Jason. > > ----- Original Message ----- > From: "Jason Giglio" > To: "sldev" ; "Torley" > Sent: Tuesday, December 04, 2007 2:39 AM > Subject: [sldev] www.sljirastats.com launched! > > > > Rob called a while back for someone to compile periodic stats on Jira. > > > > I took this idea and kinda ran with it, and http://www.sljirastats.com/ > > was born. > > > > > > Features: > > > > * Advanced Jira Search, faster (I hope!) and more powerful than the > > built in Jira search. The UI still needs some work, but it's pretty > > easy to construct very detailed queries. > > > > * Natural language date parser: > > Try "created" "is greater than" "two weeks ago" for example. > > > > * Save and share searches. > > Here's an example, this search is for unimported Open Patches: > > http://www.sljirastats.com/jira_search.php?search=27 > > > > To make your own shared searches, just click the "save search" button > > and you'll get a permalink in your address bar. > > > > > > * Statistics: > > As the site name implies, it does statistics too. :) > > > > At a glance Top 5 issues: > > > > Hot Issues This Week, by comments > > Hot Issues Today, by comments > > Most Hated Bugs > > Most Wanted Features > > Top Commenters > > Top Bug Reporters > > > > Graphs: > > Fixed Internally > > Open Bugs > > Open Patches > > Jira Participants (total) > > Updated Issues (per day) > > > > I'll be adding and removing statistics over the next few weeks as I > > refine the site. > > > > -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 > -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/c4823bf6/attachment-0001.htm From rdw at lindenlab.com Tue Dec 4 09:39:16 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Dec 4 09:39:24 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47550428.6000401@gmail.com> References: <47550428.6000401@gmail.com> Message-ID: <475590C4.1010304@lindenlab.com> This looks really useful, and just poking around the main page I've discovered a bunch of stuff I hadn't seen before. Also, it's, uh, much faster than the actual JIRA. >:-) I salute you, sir! -RYaN Jason Giglio wrote: > Rob called a while back for someone to compile periodic stats on Jira. > > I took this idea and kinda ran with it, and > http://www.sljirastats.com/ was born. > > > Features: > > * Advanced Jira Search, faster (I hope!) and more powerful than the > built in Jira search. The UI still needs some work, but it's pretty > easy to construct very detailed queries. > > * Natural language date parser: > Try "created" "is greater than" "two weeks ago" for example. > > * Save and share searches. > Here's an example, this search is for unimported Open Patches: > http://www.sljirastats.com/jira_search.php?search=27 > > To make your own shared searches, just click the "save search" button > and you'll get a permalink in your address bar. > > > * Statistics: > As the site name implies, it does statistics too. :) > > At a glance Top 5 issues: > > Hot Issues This Week, by comments > Hot Issues Today, by comments > Most Hated Bugs > Most Wanted Features > Top Commenters > Top Bug Reporters > > Graphs: > Fixed Internally > Open Bugs > Open Patches > Jira Participants (total) > Updated Issues (per day) > > I'll be adding and removing statistics over the next few weeks as I > refine the site. > > -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 Tue Dec 4 09:38:10 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Dec 4 09:41:25 2007 Subject: [sldev] Is it possible to increase the network timeout? In-Reply-To: References: <200712011816.20281.dale@daleglass.net> <7222822A-EF2D-4CC3-B154-5FB973C9FADA@secondlife.com> <47550FDD.7090708@gmail.com> Message-ID: <47559082.50800@gmail.com> Phoenix wrote: > On 2007-12-04, at 00:29, Tateru Nino wrote: >> Phoenix wrote: >>> It certainly is problematic to debug the viewer and stay connected. >>> The downside of this is that it leads to login problems when you >>> actually crash and try to get back in before the sim has disconnected >>> you. It can also lead to an awkward social situation when there are >>> dead avatars hanging out for a minute or two. >> We get all those already. > > > Are arguing for more? I think I have missed the point of your post. > > More that - many of them seem to be _caused_ by overly aggressive timeouts on circuits. Having a circuit timeout is a not uncommon problem while you're executing the login process or taking snapshots or generally doing this or that around the grid that might be momentarily machine intensive. -- Tateru Nino http://dwellonit.blogspot.com/ From odysseus654 at gmail.com Tue Dec 4 10:18:33 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Tue Dec 4 10:18:36 2007 Subject: [sldev] Is it possible to increase the network timeout? In-Reply-To: <47559082.50800@gmail.com> References: <200712011816.20281.dale@daleglass.net> <7222822A-EF2D-4CC3-B154-5FB973C9FADA@secondlife.com> <47550FDD.7090708@gmail.com> <47559082.50800@gmail.com> Message-ID: <1674f6c70712041018x4571752em9f60c2aa2b4bb05a@mail.gmail.com> Also note that on minimum RAM configuration I would often redmap while swapping, taking the Dore tram was absolutely deadly... On Dec 4, 2007 9:38 AM, Tateru Nino wrote: > > > Phoenix wrote: > > On 2007-12-04, at 00:29, Tateru Nino wrote: > >> Phoenix wrote: > >>> It certainly is problematic to debug the viewer and stay connected. > >>> The downside of this is that it leads to login problems when you > >>> actually crash and try to get back in before the sim has disconnected > >>> you. It can also lead to an awkward social situation when there are > >>> dead avatars hanging out for a minute or two. > >> We get all those already. > > > > > > Are arguing for more? I think I have missed the point of your post. > > > > > More that - many of them seem to be _caused_ by overly aggressive > timeouts on circuits. > Having a circuit timeout is a not uncommon problem while you're > executing the login process or taking snapshots or generally doing this > or that around the grid that might be momentarily machine intensive. > > -- > Tateru Nino > http://dwellonit.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/20071204/e91c091a/attachment.htm From monkowsk at watson.ibm.com Tue Dec 4 10:32:13 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Dec 4 10:32:27 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47558805.5@watson.ibm.com> References: <47550428.6000401@gmail.com> <47558805.5@watson.ibm.com> Message-ID: <47559D2D.2060705@watson.ibm.com> Mike Monkowski wrote: > Would it be difficult to show a table similar to a flipped accounts > receivable ageing? In this case, the columns would be states, such as > opened, closed duplicate, fixed internally, fixed, etc.. The rows would > be the ageing: 0-1 week, 1-2 weeks, 2-3 weeks, 3-4 weeks, 0-1 month, > 1-2 months, 2-3 months, 0-1 quarter, 1-2 quarters, 2-3 quarters, 3-4 > quarters, 0-1 year, 1-2 years, 2-3 years, longer. > > Each item would be the number of issues that have been in that state for > that amount of time. Thinking about it again, instead of "the number of issues that have been in that state for that amount of time" it would probably be better to have the number of issues created within that time span that are currently in that state. A sort of "where are they now" summary. Mike From q at lindenlab.com Tue Dec 4 10:36:42 2007 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Tue Dec 4 10:36:58 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <475590C4.1010304@lindenlab.com> References: <47550428.6000401@gmail.com> <475590C4.1010304@lindenlab.com> Message-ID: <47559E3A.1040307@lindenlab.com> Nice work. Is this done by direct query to the database, or did you have to spider it and duplicate the data? If the latter, what's the update strategy? Q Ryan Williams (Which) wrote: > This looks really useful, and just poking around the main page I've > discovered a bunch of stuff I hadn't seen before. Also, it's, uh, much > faster than the actual JIRA. >:-) > > I salute you, sir! > > -RYaN > > Jason Giglio wrote: > >> Rob called a while back for someone to compile periodic stats on Jira. >> >> I took this idea and kinda ran with it, and >> http://www.sljirastats.com/ was born. >> >> >> Features: >> >> * Advanced Jira Search, faster (I hope!) and more powerful than the >> built in Jira search. The UI still needs some work, but it's pretty >> easy to construct very detailed queries. >> >> * Natural language date parser: >> Try "created" "is greater than" "two weeks ago" for example. >> >> * Save and share searches. >> Here's an example, this search is for unimported Open Patches: >> http://www.sljirastats.com/jira_search.php?search=27 >> >> To make your own shared searches, just click the "save search" button >> and you'll get a permalink in your address bar. >> >> >> * Statistics: >> As the site name implies, it does statistics too. :) >> >> At a glance Top 5 issues: >> >> Hot Issues This Week, by comments >> Hot Issues Today, by comments >> Most Hated Bugs >> Most Wanted Features >> Top Commenters >> Top Bug Reporters >> >> Graphs: >> Fixed Internally >> Open Bugs >> Open Patches >> Jira Participants (total) >> Updated Issues (per day) >> >> I'll be adding and removing statistics over the next few weeks as I >> refine the site. >> >> -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 > From sly_squash at hotmail.com Tue Dec 4 10:55:19 2007 From: sly_squash at hotmail.com (Joshy Squashy) Date: Tue Dec 4 10:55:28 2007 Subject: [sldev] [HELP] VS 2008? Message-ID: Visual Studio 2008 is out, and Microsoft is actually offering 90 day trials for the professional version at http://msdn2.microsoft.com/en-us/vstudio/products/aa700831.aspx I was wondering if there was any interest in somebody possibly updating the wiki for compiling with the new development environment. I was also wondering if there were any plans for Linden Labs to switch to using 2005 or 2008 now that they are two versions behind. ~Squash Otoro _________________________________________________________________ Share life as it happens with the new Windows Live.Download today it's FREE! http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_sharelife_112007 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/06b0879f/attachment.htm From robla at lindenlab.com Tue Dec 4 11:02:00 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Dec 4 11:02:45 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47550428.6000401@gmail.com> References: <47550428.6000401@gmail.com> Message-ID: <4755A428.8000200@lindenlab.com> I've said my piece many times on IRC, but what the heck, I'll reiterate here. This is very, very cool. Here's an example of the type of information that would be really handy to gather (from my original call for stats): > Here are the numbers: for the 7 day period between Oct 24 and Oct 30 > (inclusive), you all have filed 87 issues. Of those, here's the breakdown: > > * 65 unresolved, not imported (to LL's issue tracker) > * 8 unresolved, but imported > * 13 resolved have been resolved as "fixed" or "fixed internally" > * 1 resolved as "misfiled" > > Additionally, there are a total of 2387 unresolved issues, of which only > 542 have corresponding issue ids in our internal database. As discussed on IRC, this is kinda tough to figure out the right way to represent. There are three rolling window graphs that would be useful, I think: 1. Rolling totals for the past week (ending one week ago) 2. Rolling totals for one week period one month ago 3. Rolling totals for one week period three months ago The periods are rather arbitrary, but each graph tells us something. Graph #1 tells us how many issues are resolved in a timely manner, and whether we're getting better/worse. Graph #2 tells us how well we're doing at being moderately responsive, and whether we're getting better or worse. Graph #3 tells us how well we're doing at being minimally responsive, and whether we're getting better or worse. Note that Graph #3 is not strictly historic. It describes the *current* state of issues that were created three months ago. Anyway, that's a lot of work, but would be useful for anyone making a case that Linden Lab is getting better or worse at handling issues in JIRA. Rob On 12/3/07 11:39 PM, Jason Giglio wrote: > Rob called a while back for someone to compile periodic stats on Jira. > > I took this idea and kinda ran with it, and > http://www.sljirastats.com/ was born. > > > Features: > > * Advanced Jira Search, faster (I hope!) and more powerful than the > built in Jira search. The UI still needs some work, but it's pretty > easy to construct very detailed queries. > > * Natural language date parser: > Try "created" "is greater than" "two weeks ago" for example. > > * Save and share searches. > Here's an example, this search is for unimported Open Patches: > http://www.sljirastats.com/jira_search.php?search=27 > > To make your own shared searches, just click the "save search" button > and you'll get a permalink in your address bar. > > > * Statistics: > As the site name implies, it does statistics too. :) > > At a glance Top 5 issues: > > Hot Issues This Week, by comments > Hot Issues Today, by comments > Most Hated Bugs > Most Wanted Features > Top Commenters > Top Bug Reporters > > Graphs: > Fixed Internally > Open Bugs > Open Patches > Jira Participants (total) > Updated Issues (per day) > > I'll be adding and removing statistics over the next few weeks as I > refine the site. > > -Jason > _______________________________________________ > 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/20071204/0368419d/signature-0001.pgp From kelly at lindenlab.com Tue Dec 4 11:15:19 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Dec 4 11:15:30 2007 Subject: [sldev] [HELP] VS 2008? In-Reply-To: References: Message-ID: <4755A747.6070903@lindenlab.com> Internally the big blocker for anything past VS 2003 are the libs for our extremely out dated current version of Havok. We don't really want to require 2 different versions of VS to develop on windows (servers vs clients), especially with Havok4 so close. I've heard rumors that at least some of the Windlight team regularly use VS 2005 already, since they rarely (if ever) need to work on the server code for their project. If I were to hazard a guess, a full switch to 2005 will probably happen sometime relatively soon after Havok4 is completed and released. Depending on how long that takes, and how long until the switch actually happens, 2008 may be a possibility. I personally am a bit hesitant about being on the bleeding edge there and would rather wait until the bugs which will undoubtedly be found by general use are found and fixed. If you want to help the havok4 testing, jump on the beta grid when it is back up. :D - Kelly Joshy Squashy wrote: > Visual Studio 2008 is out, and Microsoft is actually offering 90 day > trials for the professional version at > http://msdn2.microsoft.com/en-us/vstudio/products/aa700831.aspx > > I was wondering if there was any interest in somebody possibly > updating the wiki for compiling with the new development environment. > I was also wondering if there were any plans for Linden Labs to switch > to using 2005 or 2008 now that they are two versions behind. > > ~Squash Otoro > > ------------------------------------------------------------------------ > Share life as it happens with the new Windows Live. Share 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/20071204/15261f61/attachment.htm From seg at haxxed.com Tue Dec 4 11:18:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Dec 4 11:18:24 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <475530FE.5030603@dzonux.net> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> <1196748563.20211.4.camel@localhost> <475530FE.5030603@dzonux.net> Message-ID: <1196795889.21792.15.camel@localhost> On Tue, 2007-12-04 at 02:50 -0800, Dzonatas wrote: > There was a backwords step taken here. (Hence, C++ should not use > #if-defs in static cpp implementation files unless it is for debug > purposes, but there still is C style found here due to the Coding > Style) Actually the Linux kernel has an "unwritten" rule that preprocessor logic is not allowed in .c files: http://www.linuxjournal.com/article/5780 And this is a good read, it articulates a major beef I have with the slviewer codebase much better than I can: http://www.chris-lott.org/resources/cstyle/ifdefs.pdf slviewer violates these guidelines like a large prim-breasted Aventity vixen in a mature sim. -------------- 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/20071204/9662c252/attachment.pgp From monkowsk at watson.ibm.com Tue Dec 4 11:22:27 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Dec 4 11:22:34 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47550428.6000401@gmail.com> References: <47550428.6000401@gmail.com> Message-ID: <4755A8F3.1030305@watson.ibm.com> Jason Giglio wrote: > At a glance Top 5 issues: > > Hot Issues This Week, by comments > Hot Issues Today, by comments > Most Hated Bugs > Most Wanted Features > Top Commenters > Top Bug Reporters I was looking through the "Most Hated Bugs" and "Most Wanted Features" and found them really interesting. But I wanted to keep going down the lists. How about a "more" link that displays the top 50 or so for the chosen list. Yeah, I know. It's the curse of competence. You do something well and people want even more. :-) Mike From seg at haxxed.com Tue Dec 4 11:24:09 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Dec 4 11:24:19 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <475495F8.8050507@dzonux.net> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> <475485E6.2040708@dzonux.net> <1196724020.18776.26.camel@localhost> <475495F8.8050507@dzonux.net> Message-ID: <1196796249.21792.19.camel@localhost> On Mon, 2007-12-03 at 15:49 -0800, Dzonatas wrote: > We know that leads to patching blindly. We don't get to see the > internal branch to see how it actually got applied. At that point, > there is no way for us to guarantee any further patches applied to an > internal branch do work as intended. So basically no one on the "outside" is ever going to be able to get large invasive changes merged until LL opens up their SCM. :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/20071204/58246170/attachment.pgp From gigstaggart at gmail.com Tue Dec 4 11:30:20 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Dec 4 11:29:25 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <4755A8F3.1030305@watson.ibm.com> References: <47550428.6000401@gmail.com> <4755A8F3.1030305@watson.ibm.com> Message-ID: <4755AACC.4030802@gmail.com> Mike Monkowski wrote: > Yeah, I know. It's the curse of competence. You do something well and > people want even more. :-) That's good feedback. There's so many ways I could go with this, It's good to know what people actually want to see. -Jason From gigstaggart at gmail.com Tue Dec 4 11:30:59 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Dec 4 11:30:04 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47559E3A.1040307@lindenlab.com> References: <47550428.6000401@gmail.com> <475590C4.1010304@lindenlab.com> <47559E3A.1040307@lindenlab.com> Message-ID: <4755AAF3.500@gmail.com> Kent Quirk (Q Linden) wrote: > Nice work. Is this done by direct query to the database, or did you have to spider it and duplicate the data? > > If the latter, what's the update strategy? > > Q > It pulls the last 2 hours of updated issues every hour. It doesn't technically need this much overlap, but I wanted to give it plenty of overlap in case the previous import took a really long time (or timed out). Thanks, -Jason From tulla at lindenlab.com Tue Dec 4 11:29:49 2007 From: tulla at lindenlab.com (Eric M. Tulla (BigPapi)) Date: Tue Dec 4 11:31:21 2007 Subject: [sldev] [HELP] VS 2008? In-Reply-To: <4755A747.6070903@lindenlab.com> References: <4755A747.6070903@lindenlab.com> Message-ID: <4755AAAD.6090008@lindenlab.com> That's correct. The WindLight team is almost exclusively is using VS2005 for Windows dev work. The better intellisense and STL foo in VS2005 made it a no brainer for us, since effectively all of our work is viewer side. Kelly Linden wrote: > Internally the big blocker for anything past VS 2003 are the libs for > our extremely out dated current version of Havok. We don't really > want to require 2 different versions of VS to develop on windows > (servers vs clients), especially with Havok4 so close. I've heard > rumors that at least some of the Windlight team regularly use VS 2005 > already, since they rarely (if ever) need to work on the server code > for their project. > > If I were to hazard a guess, a full switch to 2005 will probably > happen sometime relatively soon after Havok4 is completed and > released. Depending on how long that takes, and how long until the > switch actually happens, 2008 may be a possibility. I personally am a > bit hesitant about being on the bleeding edge there and would rather > wait until the bugs which will undoubtedly be found by general use are > found and fixed. > > If you want to help the havok4 testing, jump on the beta grid when it > is back up. :D > > - Kelly > > > Joshy Squashy wrote: >> Visual Studio 2008 is out, and Microsoft is actually offering 90 day >> trials for the professional version at >> http://msdn2.microsoft.com/en-us/vstudio/products/aa700831.aspx >> >> I was wondering if there was any interest in somebody possibly >> updating the wiki for compiling with the new development >> environment. I was also wondering if there were any plans for Linden >> Labs to switch to using 2005 or 2008 now that they are two versions >> behind. >> >> ~Squash Otoro >> >> ------------------------------------------------------------------------ >> Share life as it happens with the new Windows Live. Share now! >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 Tue Dec 4 12:23:31 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 4 12:25:35 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196796249.21792.19.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> <475485E6.2040708@dzonux.net> <1196724020.18776.26.camel@localhost> <475495F8.8050507@dzonux.net> <1196796249.21792.19.camel@localhost> Message-ID: <4755B743.3000900@dzonux.net> Callum Lerwick wrote: > So basically no one on the "outside" is ever going to be able to get > large invasive changes merged until LL opens up their SCM. :P > Of course that kind of firewall is a good thing -- but at what cost? Invasive -- or final stablization? http://kerneltrap.org/node/3513 Hmm... I tend to think of the external svn as a vetting place -- something that "outside" hasn't really had. -- Power to Change the Void From seg at haxxed.com Tue Dec 4 12:36:40 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Dec 4 12:36:51 2007 Subject: [sldev] [HELP] VS 2008? In-Reply-To: <4755A747.6070903@lindenlab.com> References: <4755A747.6070903@lindenlab.com> Message-ID: <1196800601.21792.45.camel@localhost> On Tue, 2007-12-04 at 11:15 -0800, Kelly Linden wrote: > Internally the big blocker for anything past VS 2003 are the libs for > our extremely out dated current version of Havok. We don't really > want to require 2 different versions of VS to develop on windows > (servers vs clients), especially with Havok4 so close. I've heard > rumors that at least some of the Windlight team regularly use VS 2005 > already, since they rarely (if ever) need to work on the server code > for their project. Do we need a quick reference "Why LL should drop all proprietary deps" wiki page or something? :) Open source means you're never held back by ABI incompatibilities. Example: Being stuck with VS2003 due to havok. Open source means you're not held hostage by vendor bugs. Examples: The Quicktime security hole. fmod streaming ogg does not work on Linux or OSX. Open source means you're not SOL when vendors EOL a product. Example: fmod 3 is EOLed and is thus never going to get fixed. Open source means you're portable. Example: fmod is not available for x86-64 or SPARC or Solaris or etc etc... I can't find solid info on KDU. Am I to understand LL has a source license for it? (And incidentally, if so does than mean LL developers that have seen KDU source are now "tainted" and might get in trouble if they work on OpenJPEG? Fun...) And Gigs Taggart made a very interesting case at a recent open source meeting: Gigs Taggart: Rob: also we really need to commit to getting rid of proprietary deps, I know that has cost me business Gigs Taggart: Rob: people come to me, ask for custom viewer work, when they find out they are going to need a proprietary license for any realistic use, they back out From http://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-11-29 -------------- 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/20071204/57c5cb50/attachment.pgp From kelly at lindenlab.com Tue Dec 4 12:47:39 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Dec 4 12:47:50 2007 Subject: [sldev] [HELP] VS 2008? In-Reply-To: <1196800601.21792.45.camel@localhost> References: <4755A747.6070903@lindenlab.com> <1196800601.21792.45.camel@localhost> Message-ID: <4755BCEB.4030801@lindenlab.com> Callum Lerwick wrote: > On Tue, 2007-12-04 at 11:15 -0800, Kelly Linden wrote: > >> Internally the big blocker for anything past VS 2003 are the libs for >> our extremely out dated current version of Havok. We don't really >> want to require 2 different versions of VS to develop on windows >> (servers vs clients), especially with Havok4 so close. I've heard >> rumors that at least some of the Windlight team regularly use VS 2005 >> already, since they rarely (if ever) need to work on the server code >> for their project. >> > > Do we need a quick reference "Why LL should drop all proprietary deps" > wiki page or something? :) > > Open source means you're never held back by ABI incompatibilities. > Example: Being stuck with VS2003 due to havok. > > Open source means you're not held hostage by vendor bugs. Examples: The > Quicktime security hole. fmod streaming ogg does not work on Linux or > OSX. > > Open source means you're not SOL when vendors EOL a product. Example: > fmod 3 is EOLed and is thus never going to get fixed. > > Open source means you're portable. Example: fmod is not available for > x86-64 or SPARC or Solaris or etc etc... I can't find solid info on KDU. > Am I to understand LL has a source license for it? (And incidentally, if > so does than mean LL developers that have seen KDU source are now > "tainted" and might get in trouble if they work on OpenJPEG? Fun...) > > And Gigs Taggart made a very interesting case at a recent open source > meeting: > > Gigs Taggart: Rob: also we really need to commit to getting rid of > proprietary deps, I know that has cost me business > Gigs Taggart: Rob: people come to me, ask for custom viewer work, when > they find out they are going to need a proprietary license for any > realistic use, they back out > > From http://wiki.secondlife.com/wiki/Open_Source_Meeting/2007-11-29 > > ------------------------------------------------------------------------ I would rather this not get derailed into a debate on the merits of various dependencies. Yes, there are very good reasons to choose open source deps, there are also reasons to choose closed source deps some times or to continue to use the libraries we already use. This was a specific question about the version of VS we use (note that this dependency problem in this case is only effecting you if you run a closed source OS and develop with closed source dev tools ....). I provided some insight into why we use the version we use so that the OS community would have a better idea when it might change. I think the debate on using OS deps has happened, and I'm sure it will happen again. It deserves it's own thread though. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/d8ed417e/attachment.htm From seg at haxxed.com Tue Dec 4 13:09:44 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Dec 4 13:09:55 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <4755B743.3000900@dzonux.net> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> <475485E6.2040708@dzonux.net> <1196724020.18776.26.camel@localhost> <475495F8.8050507@dzonux.net> <1196796249.21792.19.camel@localhost> <4755B743.3000900@dzonux.net> Message-ID: <1196802584.21792.49.camel@localhost> On Tue, 2007-12-04 at 12:23 -0800, Dzonatas wrote: > Callum Lerwick wrote: > > So basically no one on the "outside" is ever going to be able to get > > large invasive changes merged until LL opens up their SCM. :P > > > > Of course that kind of firewall is a good thing -- but at what cost? > > Invasive -- or final stablization? > > http://kerneltrap.org/node/3513 > > Hmm... > > I tend to think of the external svn as a vetting place -- something that > "outside" hasn't really had. I think this video of Linus Torvalds talking about git just became relevant: http://www.youtube.com/watch?v=4XpnKHJAok8 Phooey on SVN. :) -------------- 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/20071204/3fa3770c/attachment.pgp From torley at lindenlab.com Tue Dec 4 13:48:47 2007 From: torley at lindenlab.com (Torley) Date: Tue Dec 4 13:48:51 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <4755A428.8000200@lindenlab.com> References: <47550428.6000401@gmail.com> <4755A428.8000200@lindenlab.com> Message-ID: <82ab8c1a0712041348g4b5ab4b9vb3e6253fea54cc18@mail.gmail.com> I am really, *really* enjoying sljirastats.com so far and am going to share it with more Lindens (I already shared the link at our Resident Experience meeting earlier today, and there was much elation). This increased visibility can easily be used in tandem with triages and other times when we need a clearer view of what's going on in the system, including trends (I'm hoping those charts will become more useful over time). I'm glad you brought Rob's inspiration to life (and Second Life, hehe) ? GREAT work Gigs/Jason. AWESOMETASTIC. *bookmarks sljirastats so I can keep checking what's new* On Dec 4, 2007 11:02 AM, Rob Lanphier wrote: > I've said my piece many times on IRC, but what the heck, I'll reiterate > here. This is very, very cool. > > Here's an example of the type of information that would be really handy > to gather (from my original call for stats): > > Here are the numbers: for the 7 day period between Oct 24 and Oct 30 > > (inclusive), you all have filed 87 issues. Of those, here's the > breakdown: > > > > * 65 unresolved, not imported (to LL's issue tracker) > > * 8 unresolved, but imported > > * 13 resolved have been resolved as "fixed" or "fixed internally" > > * 1 resolved as "misfiled" > > > > Additionally, there are a total of 2387 unresolved issues, of which only > > 542 have corresponding issue ids in our internal database. > > As discussed on IRC, this is kinda tough to figure out the right way to > represent. > > There are three rolling window graphs that would be useful, I think: > > 1. Rolling totals for the past week (ending one week ago) > 2. Rolling totals for one week period one month ago > 3. Rolling totals for one week period three months ago > > The periods are rather arbitrary, but each graph tells us something. > Graph #1 tells us how many issues are resolved in a timely manner, and > whether we're getting better/worse. Graph #2 tells us how well we're > doing at being moderately responsive, and whether we're getting better > or worse. Graph #3 tells us how well we're doing at being minimally > responsive, and whether we're getting better or worse. > > Note that Graph #3 is not strictly historic. It describes the *current* > state of issues that were created three months ago. > > Anyway, that's a lot of work, but would be useful for anyone making a > case that Linden Lab is getting better or worse at handling issues in > JIRA. > > Rob > > > On 12/3/07 11:39 PM, Jason Giglio wrote: > > Rob called a while back for someone to compile periodic stats on Jira. > > > > I took this idea and kinda ran with it, and > > http://www.sljirastats.com/ was born. > > > > > > Features: > > > > * Advanced Jira Search, faster (I hope!) and more powerful than the > > built in Jira search. The UI still needs some work, but it's pretty > > easy to construct very detailed queries. > > > > * Natural language date parser: > > Try "created" "is greater than" "two weeks ago" for example. > > > > * Save and share searches. > > Here's an example, this search is for unimported Open Patches: > > http://www.sljirastats.com/jira_search.php?search=27 > > > > To make your own shared searches, just click the "save search" button > > and you'll get a permalink in your address bar. > > > > > > * Statistics: > > As the site name implies, it does statistics too. :) > > > > At a glance Top 5 issues: > > > > Hot Issues This Week, by comments > > Hot Issues Today, by comments > > Most Hated Bugs > > Most Wanted Features > > Top Commenters > > Top Bug Reporters > > > > Graphs: > > Fixed Internally > > Open Bugs > > Open Patches > > Jira Participants (total) > > Updated Issues (per day) > > > > I'll be adding and removing statistics over the next few weeks as I > > refine the site. > > > > -Jason > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- Torley -=- http://torley.com -=- http://blog.secondlife.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/27f2b51d/attachment-0001.htm From sl at phoca.com Tue Dec 4 13:52:03 2007 From: sl at phoca.com (SL - Farallon Greyskin) Date: Tue Dec 4 13:52:21 2007 Subject: [sldev] [HELP] VS 2008? In-Reply-To: <1196800601.21792.45.camel@localhost> References: <4755A747.6070903@lindenlab.com> <1196800601.21792.45.camel@localhost> Message-ID: Way to hijack a thread two days after yelling at someone else about not hijacking threads. Please keep the editorials off the list or at least in their own threads and properly marked as such. ----- Original Message ----- From: "Callum Lerwick" To: Sent: Tuesday, December 04, 2007 12:36 PM Subject: Re: [sldev] [HELP] VS 2008? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From seg at haxxed.com Tue Dec 4 14:16:57 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Dec 4 14:17:09 2007 Subject: [sldev] [HELP] VS 2008? In-Reply-To: References: <4755A747.6070903@lindenlab.com> <1196800601.21792.45.camel@localhost> Message-ID: <1196806618.21792.58.camel@localhost> On Tue, 2007-12-04 at 13:52 -0800, SL - Farallon Greyskin wrote: > Way to hijack a thread two days after yelling at someone else about not > hijacking threads. Its not a hijack because it was a related, though tangental reply. I even quoted it. A hijack is when you pick a random message in a random thread and hit reply, in an attempt to post a new message, but the user is unaware that the mail client quietly maintains references in the SMTP headers if you this. My intention was even to move this to a Wiki page. I'm not a wiki person so I don't know where it should go... -------------- 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/20071204/2be4ea09/attachment.pgp From seg at haxxed.com Tue Dec 4 14:32:30 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Dec 4 14:32:39 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196681498.17392.45.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> Message-ID: <1196807550.21792.67.camel@localhost> On Mon, 2007-12-03 at 05:31 -0600, Callum Lerwick wrote: > > * When it worked, it benchmarked at between ~4% slower and ~4% > > faster than the pure-C++ versions on a Core2Duo and Celeron-D, so > > it didn't seem worth pushing for on i386. (Hardware skinners totally > > nullify any gain anyway, so even on machines where this was faster > > in SSE2 than pure-C++, a reasonable GPU can be significantly faster > > still). > > The open source r300 drivers don't support this yet. Oh, and ATI seems to have completely broken shaders, at least with older cards, in the latest fglrx. And don't think older versions will work on F7/F8. I filed a bug: http://jira.secondlife.com/browse/VWR-3429 I can't even enable hardware skinning on standard viewers, which used to work fine, so its not even a windlight specific bug. fglrx is just plain b0rked, as usual. ;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/20071204/b90b125d/attachment.pgp From torley at lindenlab.com Tue Dec 4 14:36:22 2007 From: torley at lindenlab.com (Torley) Date: Tue Dec 4 14:36:26 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <82ab8c1a0712041348g4b5ab4b9vb3e6253fea54cc18@mail.gmail.com> References: <47550428.6000401@gmail.com> <4755A428.8000200@lindenlab.com> <82ab8c1a0712041348g4b5ab4b9vb3e6253fea54cc18@mail.gmail.com> Message-ID: <82ab8c1a0712041436i79a6597y3fd7d46e6e9c9483@mail.gmail.com> I have a feature request for SlJiraStats.com already, please! Is it possible to show the # of unique voters and commenters? I'm curious how many have never reported an issue but interacted in another meaningful way. Thanx. =^_^= On Dec 4, 2007 1:48 PM, Torley wrote: > I am really, *really* enjoying sljirastats.com so far and am going to > share it with more Lindens (I already shared the link at our Resident > Experience meeting earlier today, and there was much elation). This > increased visibility can easily be used in tandem with triages and other > times when we need a clearer view of what's going on in the system, > including trends (I'm hoping those charts will become more useful over > time). > > I'm glad you brought Rob's inspiration to life (and Second Life, hehe) ? > GREAT work Gigs/Jason. AWESOMETASTIC. > > *bookmarks sljirastats so I can keep checking what's new* > > > > On Dec 4, 2007 11:02 AM, Rob Lanphier wrote: > > > I've said my piece many times on IRC, but what the heck, I'll reiterate > > here. This is very, very cool. > > > > Here's an example of the type of information that would be really handy > > to gather (from my original call for stats): > > > Here are the numbers: for the 7 day period between Oct 24 and Oct 30 > > > (inclusive), you all have filed 87 issues. Of those, here's the > > breakdown: > > > > > > * 65 unresolved, not imported (to LL's issue tracker) > > > * 8 unresolved, but imported > > > * 13 resolved have been resolved as "fixed" or "fixed internally" > > > * 1 resolved as "misfiled" > > > > > > Additionally, there are a total of 2387 unresolved issues, of which > > only > > > 542 have corresponding issue ids in our internal database. > > > > As discussed on IRC, this is kinda tough to figure out the right way to > > represent. > > > > There are three rolling window graphs that would be useful, I think: > > > > 1. Rolling totals for the past week (ending one week ago) > > 2. Rolling totals for one week period one month ago > > 3. Rolling totals for one week period three months ago > > > > The periods are rather arbitrary, but each graph tells us something. > > Graph #1 tells us how many issues are resolved in a timely manner, and > > whether we're getting better/worse. Graph #2 tells us how well we're > > doing at being moderately responsive, and whether we're getting better > > or worse. Graph #3 tells us how well we're doing at being minimally > > responsive, and whether we're getting better or worse. > > > > Note that Graph #3 is not strictly historic. It describes the *current* > > state of issues that were created three months ago. > > > > Anyway, that's a lot of work, but would be useful for anyone making a > > case that Linden Lab is getting better or worse at handling issues in > > JIRA. > > > > Rob > > > > > > On 12/3/07 11:39 PM, Jason Giglio wrote: > > > Rob called a while back for someone to compile periodic stats on Jira. > > > > > > I took this idea and kinda ran with it, and > > > http://www.sljirastats.com/ was born. > > > > > > > > > Features: > > > > > > * Advanced Jira Search, faster (I hope!) and more powerful than the > > > built in Jira search. The UI still needs some work, but it's pretty > > > easy to construct very detailed queries. > > > > > > * Natural language date parser: > > > Try "created" "is greater than" "two weeks ago" for example. > > > > > > * Save and share searches. > > > Here's an example, this search is for unimported Open Patches: > > > http://www.sljirastats.com/jira_search.php?search=27 > > > > > > To make your own shared searches, just click the "save search" button > > > and you'll get a permalink in your address bar. > > > > > > > > > * Statistics: > > > As the site name implies, it does statistics too. :) > > > > > > At a glance Top 5 issues: > > > > > > Hot Issues This Week, by comments > > > Hot Issues Today, by comments > > > Most Hated Bugs > > > Most Wanted Features > > > Top Commenters > > > Top Bug Reporters > > > > > > Graphs: > > > Fixed Internally > > > Open Bugs > > > Open Patches > > > Jira Participants (total) > > > Updated Issues (per day) > > > > > > I'll be adding and removing statistics over the next few weeks as I > > > refine the site. > > > > > > -Jason > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > -- > Torley -=- http://torley.com -=- http://blog.secondlife.com -- Torley -=- http://torley.com -=- http://blog.secondlife.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/d671f428/attachment.htm From monkowsk at watson.ibm.com Tue Dec 4 14:37:07 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Dec 4 14:37:35 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47559D2D.2060705@watson.ibm.com> References: <47550428.6000401@gmail.com> <47558805.5@watson.ibm.com> <47559D2D.2060705@watson.ibm.com> Message-ID: <4755D693.1060303@watson.ibm.com> Mike Monkowski wrote: >> Would it be difficult to show a table similar to a flipped accounts >> receivable ageing? In this case, the columns would be states, such as >> opened, closed duplicate, fixed internally, fixed, etc.. The rows >> would be the ageing: 0-1 week, 1-2 weeks, 2-3 weeks, 3-4 weeks, 0-1 >> month, 1-2 months, 2-3 months, 0-1 quarter, 1-2 quarters, 2-3 >> quarters, 3-4 quarters, 0-1 year, 1-2 years, 2-3 years, longer. >> >> Each item would be the number of issues that have been in that state >> for that amount of time. > > > Thinking about it again, instead of "the number of issues that have been > in that state for that amount of time" it would probably be better to > have the number of issues created within that time span that are > currently in that state. A sort of "where are they now" summary. Or if using relative bins is difficult, absolute bins would be almost as good: week of Dec 2, week of Nov 25, week of Nov 18, week of Nov 11, month of December, month of November, month of October, month of September, Month of August, Month of July, 2007, 2006, 2005, older. Probably wouldn't want quarters in this case. It would be easier to do incremental updates by looking at state changes. That is, if it's easy to get state changes. Mike From bos at lindenlab.com Tue Dec 4 15:38:35 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Dec 4 15:38:43 2007 Subject: [sldev] [VWR] Vectorization on i386? In-Reply-To: <1196795889.21792.15.camel@localhost> References: <1196668956.17392.30.camel@localhost> <4753DD33.2090201@lindenlab.com> <1196681498.17392.45.camel@localhost> <4753F453.7050705@lindenlab.com> <1196712143.17392.86.camel@localhost> <47546380.5070401@lindenlab.com> <1196719638.18776.4.camel@localhost> <1196748563.20211.4.camel@localhost> <475530FE.5030603@dzonux.net> <1196795889.21792.15.camel@localhost> Message-ID: <4755E4FB.7020607@lindenlab.com> Callum Lerwick wrote: > And this is a good read, it articulates a major beef I have with the > slviewer codebase much better than I can: > > http://www.chris-lott.org/resources/cstyle/ifdefs.pdf > > slviewer violates these guidelines like a large prim-breasted Aventity > vixen in a mature sim. The nice thing about cleaning up ifdefs is that it's a self-contained kind of work, with few dependencies and not enormous scope for conflicts. It's the sort of work that's well suited to a long series of patches from interested open source constributors, in fact. Back in October, we requested feedback about the Viewer Authentication project with a broad set of unfocused goals, which masked the main drive for the project: Code consolidation of authentication for future anti-fraud efforts. As I'm sure you've noticed by now, the upcoming 1.18.6 release candidate has the implementation of this new system. Much of the ensued debate centered around the relative security of the old xml-rpc based approach versus the new approach of using HTML. We *weren't* necessarily trying to make the mechanism itself more secure (we believe both mechanisms are secure), but rather, we want to give ourselves greater flexibility to use new security mechanisms already being successfully employed by banks, credit-card companies, and other service providers that need rigorous security regimes. By moving to standard HTTPS plus HTML, we get the benefit of being able to integrate new security systems without creating a lot of custom code. We realize that the way that we went about this was a little clumsy. We have a lot of conflicting priorities to balance; we're working on the part of the system that is necessarily shrouded in the most secrecy (since we are trying to keep the bad guys out). Though we fully expect Second Life to become more open over time, there will always need to be secrets. We are, after all, not planning on publishing the root password for our systems any time soon. The process of making Second Life more open will take time, and will probably (unfortunately) be filled with awkward moments like this one where we figure out how to work together with you all. Please bear with us, we're trying to learn the best way to do this. Thanks, Tess From tao.takashi at googlemail.com Tue Dec 4 16:05:54 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Dec 4 16:05:57 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4755E705.6090703@lindenlab.com> References: <4755E705.6090703@lindenlab.com> Message-ID: <23bbb49e0712041605v1673ba3cqf824b68d4751e830@mail.gmail.com> Hi! On Dec 5, 2007 12:47 AM, Tess Chu wrote: > Back in October, we requested feedback about the Viewer Authentication > project with a broad set of unfocused goals, which masked the main drive > for the project: Code consolidation of authentication for future > anti-fraud efforts. As I'm sure you've noticed by now, the upcoming > 1.18.6 release candidate has the implementation of this new system. I did not as I did not have a look yet but after the discussion I think it was clearer what you actually wanted. .... > secrets. We are, after all, not planning on publishing the root password for our systems any time soon. Ok, not anytime soon means not this year I guess but what about next year? I think this would again attract a whole different crowd to Second Life ;-) The process of making Second Life more open will take time, and will > probably (unfortunately) be filled with awkward moments like this one > where we figure out how to work together with you all. Please bear with > us, we're trying to learn the best way to do this. Well, in general I think you are on a good way, at least you are trying (as I see it). Of course it would be great in the end if most communication about technical things would go on on a public mailing list. There might always be specific things about a particular implementation (if we talk about the moment when we maybe have various more or less connected grid sometime in the far future) but I hope general communication will then happen like any other open source project. As for what you are doing there, how much would this actually affect the SLGAWG stuff? Is this specific to what LL is doing or a more general problem. If it's the latter then of course it's hard to keep secret. now to bed.. :-) Cheers, Tao PS: I started experimenting with doing the login the new ways. I also created some sort of basic caps server for testing purposes. You can find all this here: http://pysecondlife.googlecode.com/svn/trunk/ It's not working yet though and the protocol is not fixed anyway so it's more of an experiment to play with that stuff and get a feel for it. At least retrieving and proxying a caps was working. I also will add some docs for it on how to get it to run. But first it needs to run ;-) -- taotakashi@gmail.com http://taotakashi.wordpress.com http://worldofsl.com RL: Christian Scholz, cs@comlounge.net http://mrtopf.de http://comlounge.net http://comlounge.tv http://mrtopf.tv http://dev.comlounge.net IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071205/b23a1225/attachment.htm From jessesa at gmail.com Tue Dec 4 16:08:45 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Tue Dec 4 16:08:48 2007 Subject: [sldev][META]LL to start using Streambase to combat fraud Message-ID: May be of interest to others. Pattern recognition software has a multitude of uses including most importantly fraud protection. Due to the sensitive nature of security, we may not get much feedback on this. But I would imagine that it could allay some of the recent concerns dealing with our logins to 3rd party viewers. One such scenario would be an (undefined) flurry of users logging in from the same IP address etc. Same as you will recieve a phone call from your CC company if you forget to tell them you are going on vacation and charges start appearing from Alcapulco........ http://www.wired.com/gaming/virtualworlds/news/2007/11/mmo_cheats "Online Games Use Fraud Software to Combat Cheats By Emmet Cole 11.30.07 | 4:00 PM Cheaters in multiplayer online games beware: Game developers are turning to advanced financial fraud-detection software to keep you from crooking your way to online riches." etc, etc "The MMO developer BioWare has recently adopted StreamBase's technology, as has Second Life's Linden Lab and Avatar Reality, which is creating the MMO Blue Mars for launch in late 2008." etc etc Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/49158c30/attachment.htm From gigstaggart at gmail.com Tue Dec 4 16:12:13 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Dec 4 16:11:17 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4755E705.6090703@lindenlab.com> References: <4755E705.6090703@lindenlab.com> Message-ID: <4755ECDD.8090909@gmail.com> Tess Chu wrote: > part of the system that is necessarily shrouded in the most secrecy > (since we are trying to keep the bad guys out). Though we fully expect If a security system relies on secret algorithms to be effective, it's worthless. -Jason From jessesa at gmail.com Tue Dec 4 16:25:07 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Tue Dec 4 16:25:11 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4755E705.6090703@lindenlab.com> References: <4755E705.6090703@lindenlab.com> Message-ID: On 12/4/07, Tess Chu wrote: > > We > *weren't* necessarily trying to make the mechanism itself more secure > (we believe both mechanisms are secure), but rather, we want to give > ourselves greater flexibility to use new security mechanisms already > being successfully employed by banks, credit-card companies, and other > service providers that need rigorous security regimes. By moving to > standard HTTPS plus HTML, we get the benefit of being able to integrate > new security systems without creating a lot of custom code. > > We realize that the way that we went about this was a little clumsy. We > have a lot of conflicting priorities to balance; we're working on the > part of the system that is necessarily shrouded in the most secrecy > (since we are trying to keep the bad guys out). Though we fully expect > Second Life to become more open over time, there will always need to be > secrets. We are, after all, not planning on publishing the root > password for our systems any time soon. > > The process of making Second Life more open will take time, and will > probably (unfortunately) be filled with awkward moments like this one > where we figure out how to work together with you all. Please bear with > us, we're trying to learn the best way to do this. > > Thanks, > Tess Thank you Tess for replying. I made a botched attempt to post about this on Sunday, just tried again and after I posted your mesage was here. Hopefully it won't appear twice but here goes: "LL to start using Streambase to combat fraud" "May be of interest to others. Pattern recognition software has a multitude of uses including most importantly fraud protection. Due to the sensitive nature of security, we may not get much feedback on this. But I would imagine that it could allay some of the recent concerns dealing with our logins to 3rd party viewers. One such scenario would be an (undefined) flurry of users logging in from the same IP address etc. Same as you will recieve a phone call from your CC company if you forget to tell them you are going on vacation and charges start appearing from Alcapulco........ http://www.wired.com/gaming/virtualworlds/news/2007/11/mmo_cheats "Online Games Use Fraud Software to Combat Cheats By Emmet Cole 11.30.07 | 4:00 PM Cheaters in multiplayer online games beware: Game developers are turning to advanced financial fraud-detection software to keep you from crooking your way to online riches." etc, etc "The MMO developer BioWare has recently adopted StreamBase's technology, as has Second Life's Linden Lab and Avatar Reality, which is creating the MMO Blue Mars for launch in late 2008." etc etc Jesse Barnett" _______________________________________________ > 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/20071204/1694a975/attachment.htm From tateru.nino at gmail.com Tue Dec 4 16:23:15 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Dec 4 16:26:32 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4755ECDD.8090909@gmail.com> References: <4755E705.6090703@lindenlab.com> <4755ECDD.8090909@gmail.com> Message-ID: <4755EF73.70800@gmail.com> Jason Giglio wrote: > Tess Chu wrote: >> part of the system that is necessarily shrouded in the most secrecy >> (since we are trying to keep the bad guys out). Though we fully expect > > If a security system relies on secret algorithms to be effective, it's > worthless. I'd have to go with Jason here. It _does_ sound like you're preaching security-through-obscurity. Please, please, please, please correct us if we misinterpreted what you meant. I'd also love to hear that the bit being kept secret isn't "This is a part of the streambase integration" - I mean, that's all over the news, but hasn't been mentioned here. -- Tateru Nino http://dwellonit.blogspot.com/ From dzonatas at dzonux.net Tue Dec 4 17:21:10 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 4 17:23:25 2007 Subject: [sldev] [HELP] VS 2008? -- The Cat is out of the bag! In-Reply-To: <4755BCEB.4030801@lindenlab.com> References: <4755A747.6070903@lindenlab.com> <1196800601.21792.45.camel@localhost> <4755BCEB.4030801@lindenlab.com> Message-ID: <4755FD06.3010404@dzonux.net> Kelly Linden wrote: >> >> ------------------------------------------------------------------------ > I would rather this not get derailed into a debate on the merits of > various dependencies. Yes, there are very good reasons to choose open > source deps, there are also reasons to choose closed source deps some > times or to continue to use the libraries we already use. This was a > specific question about the version of VS we use (note that this > dependency problem in this case is only effecting you if you run a > closed source OS and develop with closed source dev tools ....). I > provided some insight into why we use the version we use so that the > OS community would have a better idea when it might change. I think > the debate on using OS deps has happened, and I'm sure it will happen > again. It deserves it's own thread though. It's a bit uncalled-for to say this was "derailed". Some of us have just found other ways to say things without showing an exploit that would break terms. Unexpectedly, it has been published: http://slashdot.org/article.pl?sid=07/12/04/1331246 It includes STL and a few other factors. I sent details to the internal security list a months ago. There are very valid reasons to research dependencies and make a well thought-out choice about Visual Studio (& Windows target version). -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/b9007395/attachment-0001.htm From phoenix at secondlife.com Tue Dec 4 17:26:40 2007 From: phoenix at secondlife.com (Phoenix) Date: Tue Dec 4 17:26:55 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4755EF73.70800@gmail.com> References: <4755E705.6090703@lindenlab.com> <4755ECDD.8090909@gmail.com> <4755EF73.70800@gmail.com> Message-ID: <52A5D110-6957-443B-A5A4-99D18B79D493@secondlife.com> On 2007-12-04, at 16:23, Tateru Nino wrote: > Jason Giglio wrote: >> Tess Chu wrote: >>> part of the system that is necessarily shrouded in the most secrecy >>> (since we are trying to keep the bad guys out). Though we fully >>> expect >> >> If a security system relies on secret algorithms to be effective, >> it's >> worthless. > I'd have to go with Jason here. It _does_ sound like you're preaching > security-through-obscurity. Please, please, please, please correct > us if > we misinterpreted what you meant. > > I'd also love to hear that the bit being kept secret isn't "This is a > part of the streambase integration" - I mean, that's all over the > news, > but hasn't been mentioned here. > The quote is pretty unfair. To add some context: On 12/4/07, Tess Chu wrote: > (since we are trying to keep the bad guys out). Though we fully expect > Second Life to become more open over time, there will always need to be > secrets. We are, after all, not planning on publishing the root > password for our systems any time soon. I admit it freely -- if we give out a password, the system can be compromised. We are not employing any kind of homespun security system. -------------- 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/20071204/293a0db8/PGP.pgp From secret.argent at gmail.com Tue Dec 4 17:49:37 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Dec 4 17:49:47 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4755ECDD.8090909@gmail.com> References: <4755E705.6090703@lindenlab.com> <4755ECDD.8090909@gmail.com> Message-ID: <1E17D61E-37EC-4A9D-A6E5-F44EC84D37B0@gmail.com> On 04-Dec-2007, at 18:12, Jason Giglio wrote: > Tess Chu wrote: >> part of the system that is necessarily shrouded in the most >> secrecy (since we are trying to keep the bad guys out). Though we >> fully expect > > If a security system relies on secret algorithms to be effective, > it's worthless. It's not a security system. Like Tess said, this isn't about security. This is about a lot of words that people mix up with security. Like evidence, and investigation, and forensics, and stuff like that. From jessesa at gmail.com Tue Dec 4 18:35:09 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Tue Dec 4 18:35:12 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <1E17D61E-37EC-4A9D-A6E5-F44EC84D37B0@gmail.com> References: <4755E705.6090703@lindenlab.com> <4755ECDD.8090909@gmail.com> <1E17D61E-37EC-4A9D-A6E5-F44EC84D37B0@gmail.com> Message-ID: On 12/4/07, Argent Stonecutter wrote: > > > It's not a security system. > > Like Tess said, this isn't about security. > > This is about a lot of words that people mix up with security. Like > evidence, and investigation, and forensics, and stuff like that. > > _______________________________________________ Billion dollar credit card companies would disagree with that assessment. And there is a similiarity between credit card with number and security code in back and our username and password. Imagine how long a credit card company could stay in buisiness without a complete system of security in place. A system that among other things, employs pattern recognition. It is actually much easier to get someone's credit card number as opposed to our username/password. I use my company credit card on websites everyday to make purchases. In fact 8 of us have credit cards and use them on the web, stores, gas etc. It is a rare occurence for there to be a disputed charge even running about $20K of charges a month. Most of us don't think twice about handing over the little piece of plastic on it worth several thousand dollars. But we are extremely worried about 3rd party viewers possibly getting access to a few thousand $L. Think it needs perspective. Yes it and other targets are of some concern and that is why you need to try to build a system to cover the vulnerabilites you are aware of and of course fix any new vulnerabilities. I haven't ever disputed the fact that we have multiple vulnerabilities and that this nees to be fixed. Having to provide our info to login to Jira, Wiki, Viewer, Forums etc is one. The only dispute I have is making sure we don't loose some of the choices we have now, such as being able to log into multiple accounts at the same time. Hopefully someone is working on that too. Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071204/18e568b7/attachment.htm From tateru.nino at gmail.com Tue Dec 4 21:34:59 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Dec 4 21:38:20 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <52A5D110-6957-443B-A5A4-99D18B79D493@secondlife.com> References: <4755E705.6090703@lindenlab.com> <4755ECDD.8090909@gmail.com> <4755EF73.70800@gmail.com> <52A5D110-6957-443B-A5A4-99D18B79D493@secondlife.com> Message-ID: <47563883.9030307@gmail.com> Phoenix wrote: > On 2007-12-04, at 16:23, Tateru Nino wrote: >> Jason Giglio wrote: >>> Tess Chu wrote: >>>> part of the system that is necessarily shrouded in the most secrecy >>>> (since we are trying to keep the bad guys out). Though we fully >>>> expect >>> >>> If a security system relies on secret algorithms to be effective, it's >>> worthless. >> I'd have to go with Jason here. It _does_ sound like you're preaching >> security-through-obscurity. Please, please, please, please correct us if >> we misinterpreted what you meant. >> >> I'd also love to hear that the bit being kept secret isn't "This is a >> part of the streambase integration" - I mean, that's all over the news, >> but hasn't been mentioned here. >> > > The quote is pretty unfair. To add some context: > > On 12/4/07, Tess Chu wrote: > > (since we are trying to keep the bad guys out). Though we fully expect > > Second Life to become more open over time, there will always need to be > > secrets. We are, after all, not planning on publishing the root > > password for our systems any time soon. > > I admit it freely -- if we give out a password, the system can be > compromised. We are not employing any kind of homespun security system. > My misunderstanding - issues like passwords and keys I thought were implicit. Apologies to Tess - it looked a whole lot to some of us like she(?) was talking about goals, policies, procedures and algorithms. It'd be pretty silly for us to assume that administrative credentials were a matter for discussion. -- Tateru Nino http://dwellonit.blogspot.com/ From tateru.nino at gmail.com Tue Dec 4 23:58:02 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Dec 5 00:01:03 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4755E705.6090703@lindenlab.com> References: <4755E705.6090703@lindenlab.com> Message-ID: <47565A0A.3020806@gmail.com> Tess Chu wrote: > Back in October, we requested feedback about the Viewer Authentication > project with a broad set of unfocused goals, which masked the main > drive for the project: Code consolidation of authentication for future > anti-fraud efforts. As I'm sure you've noticed by now, the upcoming > 1.18.6 release candidate has the implementation of this new system. One final thought - the subject line says "Today's RC". Which release candidate would that be, exactly? -- Tateru Nino http://dwellonit.blogspot.com/ From Anders at Arnholm.se Wed Dec 5 02:54:58 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Dec 5 02:55:15 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4755E705.6090703@lindenlab.com> References: <4755E705.6090703@lindenlab.com> Message-ID: <20071205105458.GC28695@arnholm.se> On Tue, Dec 04, 2007 at 03:47:17PM -0800, Tess Chu wrote: > Back in October, we requested feedback about the Viewer Authentication > project with a broad set of unfocused goals, which masked the main drive > for the project: Code consolidation of authentication for future anti-fraud > efforts. As I'm sure you've noticed by now, the upcoming 1.18.6 release > candidate has the implementation of this new system. So far it sound good... > Much of the ensued debate centered around the relative security of the old > xml-rpc based approach versus the new approach of using HTML. We *weren't* > necessarily trying to make the mechanism itself more secure (we believe > both mechanisms are secure), but rather, we want to give ourselves greater The main problem have always been that it's outside the viewer, and involve a new i.m.h.o. stupid way of starting the viewer and giving information to the viewer. It's this small technical problem that many have trouble with, moving stuff into an other domain adding stuff that is hard and how to solve the big obvious problems this we have not see answers on yet. It's makes good reason to believe that big problems still exist and other goals have taken priority over the issues I believe it more important. > get the benefit of being able to integrate new security systems without > creating a lot of custom code. And lost very much flexibility, needed in the future. > The process of making Second Life more open will take time, and will > probably (unfortunately) be filled with awkward moments like this one where > we figure out how to work together with you all. Please bear with us, > we're trying to learn the best way to do this. I hope we can continue to work and understand each other (I happen to work at the moment in a department ding this kind of work for many government agencies in the world.) Our approach in details are very different, we are bot scared of the little extra work if it add more to the security, we can't afford to take the small error way in we have to make the extra mile. / Balp -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071205/e9ea940a/attachment.pgp From alissa_sabre at yahoo.co.jp Wed Dec 5 03:09:33 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Dec 5 03:48:57 2007 Subject: [sldev] [HELP] VS 2008? In-Reply-To: <4755BCEB.4030801@lindenlab.com> References: <4755BCEB.4030801@lindenlab.com> Message-ID: <94ds6ds9ds412J4s5oc76.alissa_sabre@yahoo.co.jp> Two points: First, on the Linden's plan to switch to VS2005, I believe Microsoft will soon stop distributing VS2005 and replace their free express downloads and sales stocks on the market with VS2008. Ater that switching, it will be almost impossible for new developers to get their copies of VS2005 (as it is to get VS2003 now!) So, Lindens, if you are planning to switch the Visual Studio version, please choose VS2008 as the target. (Assuming the switching will take place before the VS201x to come out.) Second, on the use of no open-source libraries, I don't simply dislike no open-source libraries (Sorry for a tripple negatives... I can't express my idea other than this way in my limited English skill...), but I hate any of the following: - I need some manual modification to projects before I can compile each release of a Windows version of SL viewer. - Lindens modify the source for distribution after their QA. - Open source viewer doesn't match the Linden's official build in their components. If Lindens' explanation that they are caused by their use of some proprietary third party libraries in the viewer and/or the server and are inevitalble is true, my position will be against no open-source libraries. Lindens, you are wasting both Linden employees' and open source developers' time by making our collaboration difficult, IMHO. Alissa -------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/ From gigstaggart at gmail.com Tue Dec 4 15:42:09 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Dec 5 03:53:30 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <82ab8c1a0712041436i79a6597y3fd7d46e6e9c9483@mail.gmail.com> References: <47550428.6000401@gmail.com> <4755A428.8000200@lindenlab.com> <82ab8c1a0712041348g4b5ab4b9vb3e6253fea54cc18@mail.gmail.com> <82ab8c1a0712041436i79a6597y3fd7d46e6e9c9483@mail.gmail.com> Message-ID: <4755E5D1.6050100@gmail.com> Torley wrote: > I have a feature request for SlJiraStats.com already, please! > > Is it possible to show the # of unique voters and commenters? I'm > curious how many have never reported an issue but interacted in another > meaningful way. > > Thanx. =^_^= Mmm, can't get voters, unfortunately, but I can get comment authors. I think I'll merge the "Jira participation" section into a 5 line (left side) box with various participation stats. Thanks for the input. Jason From Anders at Arnholm.se Wed Dec 5 04:12:03 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed Dec 5 04:12:19 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <47558737.9060200@lindenlab.com> References: <47558737.9060200@lindenlab.com> Message-ID: <20071205121203.GE28695@arnholm.se> On Tue, Dec 04, 2007 at 11:58:31AM -0500, Eric M. Tulla (BigPapi) wrote: When can we expect to see 1.18.5.74965's code? Before 1.18.6? > We forgot to do take the extra manual steps. We'll be doing so shortly. -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071205/3450896f/attachment.pgp From robla at lindenlab.com Wed Dec 5 07:34:11 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Dec 5 07:34:35 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <20071205121203.GE28695@arnholm.se> References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> Message-ID: <4756C4F3.3080008@lindenlab.com> I've checked in the source at svn.secondlife.com. You can run a checkout from here: https://svn.secondlife.com/svn/linden/branches/2007/windlight12/ Rob On 12/5/07 4:12 AM, Anders Arnholm wrote: > On Tue, Dec 04, 2007 at 11:58:31AM -0500, Eric M. Tulla (BigPapi) wrote: > > When can we expect to see 1.18.5.74965's code? Before 1.18.6? > > >> We forgot to do take the extra manual steps. We'll be doing so shortly. >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20071205/f7bf3cec/signature.pgp From secret.argent at gmail.com Wed Dec 5 08:04:03 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 5 08:04:32 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: References: <4755E705.6090703@lindenlab.com> <4755ECDD.8090909@gmail.com> <1E17D61E-37EC-4A9D-A6E5-F44EC84D37B0@gmail.com> Message-ID: <01046EEF-8CA1-4472-96CD-2D746E463D6D@gmail.com> On 04-Dec-2007, at 20:35, Jesse Barnett wrote: >> It's not a security system. >> Like Tess said, this isn't about security. >> This is about a lot of words that people mix up with security. Like >> evidence, and investigation, and forensics, and stuff like that. > Billion dollar credit card companies would disagree with that > assessment. I don't think so. Credit card companies do not actually apply a huge amount of direct effort to security. Your credit card and number contain no security features beyond a simple documented (thus reproducible) checksum. If they were to make their cards foolproof with embedded biometric sensors, encrypted certificates, and temper- resistant storage... they would get so much pushback from their customers. Instead they apply the effort to fraud investigation, and tools to improve fraud investigation, and gathering evidence to detect fraud, and so on. From gigstaggart at gmail.com Tue Dec 4 11:27:24 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Dec 5 09:01:21 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47559D2D.2060705@watson.ibm.com> References: <47550428.6000401@gmail.com> <47558805.5@watson.ibm.com> <47559D2D.2060705@watson.ibm.com> Message-ID: <4755AA1C.5030403@gmail.com> Yes, the next set of stats I want to add will be rolling windows like that. Thanks for the idea on how to present it, there was some question presentation there. Mike Monkowski wrote: > Mike Monkowski wrote: >> Would it be difficult to show a table similar to a flipped accounts >> receivable ageing? In this case, the columns would be states, such as >> opened, closed duplicate, fixed internally, fixed, etc.. The rows >> would be the ageing: 0-1 week, 1-2 weeks, 2-3 weeks, 3-4 weeks, 0-1 >> month, 1-2 months, 2-3 months, 0-1 quarter, 1-2 quarters, 2-3 >> quarters, 3-4 quarters, 0-1 year, 1-2 years, 2-3 years, longer. >> >> Each item would be the number of issues that have been in that state >> for that amount of time. > > Thinking about it again, instead of "the number of issues that have been > in that state for that amount of time" it would probably be better to > have the number of issues created within that time span that are > currently in that state. A sort of "where are they now" summary. > > Mike > From tateru.nino at gmail.com Wed Dec 5 08:53:20 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Dec 5 09:02:43 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <01046EEF-8CA1-4472-96CD-2D746E463D6D@gmail.com> References: <4755E705.6090703@lindenlab.com> <4755ECDD.8090909@gmail.com> <1E17D61E-37EC-4A9D-A6E5-F44EC84D37B0@gmail.com> <01046EEF-8CA1-4472-96CD-2D746E463D6D@gmail.com> Message-ID: <4756D780.3020208@gmail.com> Argent Stonecutter wrote: > On 04-Dec-2007, at 20:35, Jesse Barnett wrote: >>> It's not a security system. > >>> Like Tess said, this isn't about security. > >>> This is about a lot of words that people mix up with security. Like >>> evidence, and investigation, and forensics, and stuff like that. > >> Billion dollar credit card companies would disagree with that >> assessment. > > I don't think so. Credit card companies do not actually apply a huge > amount of direct effort to security. Your credit card and number > contain no security features beyond a simple documented (thus > reproducible) checksum. If they were to make their cards foolproof > with embedded biometric sensors, encrypted certificates, and > temper-resistant storage... they would get so much pushback from their > customers. Instead they apply the effort to fraud investigation, and > tools to improve fraud investigation, and gathering evidence to detect > fraud, and so on. > Having worked in the banking industry, yes - banks and card companies work to limit costs due to fraud. That is, costs to themselves - costs to the customer are generally a very distant secondary concern. Money, therefore goes into fraud detection systems, rather than things like card and account security. Card security is primarily a marketing operation - basically, there's usually only the appearance of enough of it to avoid driving customers away. -- Tateru Nino http://dwellonit.blogspot.com/ From sldev at free.fr Wed Dec 5 13:23:00 2007 From: sldev at free.fr (Henri Beauchamp) Date: Wed Dec 5 13:23:06 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <4756C4F3.3080008@lindenlab.com> References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> Message-ID: <20071205222300.304cf923.sldev@free.fr> On Wed, 05 Dec 2007 07:34:11 -0800, Rob Lanphier wrote: > I've checked in the source at svn.secondlife.com. You can run a > checkout from here: > https://svn.secondlife.com/svn/linden/branches/2007/windlight12/ > > Rob I tried to compile the SVN sources, using the libraries package of the previous windlight version (available on the Wiki), but I got: /usr/src/SL/build/usr/src/SL/indra/i686-linux-client-releasefordownload/newview/llwebbrowserctrl.o: In function `LLWebBrowserCtrl::set404RedirectUrl(std::basic_string, std::allocator >)': llwebbrowserctrl.cpp:(.text+0x2ef4): undefined reference to `LLMozLib::set404RedirectUrl(int, std::basic_string, std::allocator >)' collect2: ld returned 1 exit status scons: *** [newview/secondlife-i686-bin-globalsyms] Error 1 So, I guess the mozlib library changed... Could we please get the full sources and packages (libraries and artwork) on the Wiki ? Thanks in advance, Henri. From seg at haxxed.com Wed Dec 5 13:50:06 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Dec 5 13:50:18 2007 Subject: [sldev] [VWR] The OpenJPEG lossless decode bug Message-ID: <1196891406.21792.129.camel@localhost> Okay, after finally getting into a position where I can rapidly test changes, and after being nagged by Gigs Taggart, I finally sat down and resolved to fix that damn lossless decode bug. Following the hint given on VWR-2404, I traced backwards from LLImageJ2COJ::decodeImpl(), looking for where the compressed data was coming from. After stumbling around a twisty maze of badly abstracted code, with the help of Dale's doxygen run, (http://doc.daleglass.net/) I found LLImageJ2C::calcDataSizeJ2C() Yes, it is making assumptions about the compression ratio. So I tried this: --- linden.orig/indra/llimage/llimagej2c.cpp 2007-11-07 20:18:06.000000000 -0600 +++ linden.patched/indra/llimage/llimagej2c.cpp 2007-12-05 13:14:53.000000000 -0600 @@ -310,7 +310,7 @@ //static S32 LLImageJ2C::calcDataSizeJ2C(S32 w, S32 h, S32 comp, S32 discard_level, F32 rate) { - if (rate <= 0.f) rate = .125f; + if (rate <= 0.f) rate = 0.5f; while (discard_level > 0) { if (w < 1 || h < 1) Success! (sorta) I no longer see corrupted textures. Right now I am staring at a perfect ant, in the SW corner of Hippotropolis. Unfortunately, its not a complete fix. Some lossy textures seem to get stalled during download, in particular, the map textures. I suspect my hack is messing up the way priority is being calculated, which is complex and uncommented. It seems if I sit and stare at the map for a looooooong time, (~5min) it will eventually load at full res. So it's probably is the same bug as VWR-2404, the viewer is not downloading textures fully, then hands them off to OpenJPEG and it barfs. I'm wondering why KDU doesn't have as much a problem, this bug seems to be in common code. At the risk of feeding the hostility that has been running rampant on the list lately, note that in VWR-2404 Qarl completely ignores my albeit not strongly worded request for what the fix was. This would be an example of "the wall" that has been driving us nuts. The fix has been tied up in QA hell for two months, meanwhile I can't do my own QA and confirm if it fixes the problem with OpenJPEG. -------------- 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/20071205/2806ebf8/attachment.pgp From gigstaggart at gmail.com Wed Dec 5 13:54:07 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Dec 5 13:53:08 2007 Subject: [sldev] [VWR] The OpenJPEG lossless decode bug In-Reply-To: <1196891406.21792.129.camel@localhost> References: <1196891406.21792.129.camel@localhost> Message-ID: <47571DFF.8090904@gmail.com> Callum Lerwick wrote: > Success! (sorta) I no longer see corrupted textures. Right now I am > staring at a perfect ant, in the SW corner of Hippotropolis. Woot! This, along with the speed up changes that are coming in the new OpenJPEG release should put us very close to dropping KDU. -Jason From jhurliman at wsu.edu Wed Dec 5 15:31:52 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Dec 5 15:32:01 2007 Subject: [sldev] Viewer Auth + Automated Login (was RE: More about viewer auth in today's RC) In-Reply-To: <4755E705.6090703@lindenlab.com> References: <4755E705.6090703@lindenlab.com> Message-ID: <475734E8.3060002@wsu.edu> Tess Chu wrote: > Back in October, we requested feedback about the Viewer Authentication > project with a broad set of unfocused goals, which masked the main > drive for the project: Code consolidation of authentication for future > anti-fraud efforts. As I'm sure you've noticed by now, the upcoming > 1.18.6 release candidate has the implementation of this new system. > > Much of the ensued debate centered around the relative security of the > old xml-rpc based approach versus the new approach of using HTML. We > *weren't* necessarily trying to make the mechanism itself more secure > (we believe both mechanisms are secure), but rather, we want to give > ourselves greater flexibility to use new security mechanisms already > being successfully employed by banks, credit-card companies, and other > service providers that need rigorous security regimes. By moving to > standard HTTPS plus HTML, we get the benefit of being able to > integrate new security systems without creating a lot of custom code. > > We realize that the way that we went about this was a little clumsy. > We have a lot of conflicting priorities to balance; we're working on > the part of the system that is necessarily shrouded in the most > secrecy (since we are trying to keep the bad guys out). Though we > fully expect Second Life to become more open over time, there will > always need to be secrets. We are, after all, not planning on > publishing the root password for our systems any time soon. > > The process of making Second Life more open will take time, and will > probably (unfortunately) be filled with awkward moments like this one > where we figure out how to work together with you all. Please bear > with us, we're trying to learn the best way to do this. > > Thanks, > Tess I've been in favor of the new web authentication system, but under the assumption that we would have a new login method to replace the current one before it became a mandatory system (and thus locking out automated processes like bots, who are not very good at scraping HTML forms that can dynamically change for "WebLoginKey"s). Is there any word on progress or a timeline for the new automated login system that doesn't involve HTML scraping? John From robla at lindenlab.com Wed Dec 5 15:52:50 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Dec 5 15:53:02 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <20071205222300.304cf923.sldev@free.fr> References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> Message-ID: <475739D2.6020407@lindenlab.com> I've skipped forward to FL-1.18.5.74965 (released last night): https://wiki.secondlife.com/wiki/Source_downloads#ver_FL-1.18.5.74965 With respect to llmozlib, that's a separate download. It has changed fairly recently (2007-11-21), but the source is here: https://wiki.secondlife.com/wiki/Source_downloads#Support_library_source Rob On 12/5/07 1:23 PM, Henri Beauchamp wrote: > On Wed, 05 Dec 2007 07:34:11 -0800, Rob Lanphier wrote: > > >> I've checked in the source at svn.secondlife.com. You can run a >> checkout from here: >> https://svn.secondlife.com/svn/linden/branches/2007/windlight12/ >> >> Rob >> > > I tried to compile the SVN sources, using the libraries package of the previous windlight version (available on the Wiki), but I got: > > /usr/src/SL/build/usr/src/SL/indra/i686-linux-client-releasefordownload/newview/llwebbrowserctrl.o: In function `LLWebBrowserCtrl::set404RedirectUrl(std::basic_string, std::allocator >)': > llwebbrowserctrl.cpp:(.text+0x2ef4): undefined reference to `LLMozLib::set404RedirectUrl(int, std::basic_string, std::allocator >)' > collect2: ld returned 1 exit status > scons: *** [newview/secondlife-i686-bin-globalsyms] Error 1 > > So, I guess the mozlib library changed... > > Could we please get the full sources and packages (libraries and artwork) on the Wiki ? > > Thanks in advance, > > Henri. > _______________________________________________ > 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/20071205/271a63b4/signature.pgp From gigstaggart at gmail.com Tue Dec 4 21:30:57 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Dec 5 21:23:33 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <4755A8F3.1030305@watson.ibm.com> References: <47550428.6000401@gmail.com> <4755A8F3.1030305@watson.ibm.com> Message-ID: <47563791.8060507@gmail.com> Mike Monkowski wrote: > I was looking through the "Most Hated Bugs" and "Most Wanted Features" > and found them really interesting. But I wanted to keep going down the > lists. How about a "more" link that displays the top 50 or so for the > chosen list. I was able to add this to the most hated and most wanted using the search persistence/sharing functionality. Most of the other top 5 lists use "group by" aggregate clauses which the query builder can't make, so it may take me a little longer before I figure out how to allow drilling down on those.... I could just make a custom page with "Top 50 lists" or something like that, if you think people want it.. From rdw at lindenlab.com Thu Dec 6 00:25:42 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Thu Dec 6 00:25:44 2007 Subject: [sldev] Certified HTTP Project Update Dec 6 Message-ID: <4757B206.8020104@lindenlab.com> I'm going to be ambitious and say that I think we'll be done with Certified HTTP by the end of this week. The caveat is that when I say "done" I mean that there's a ton more work to be done, but we can start using it as the basis for something else. Speaking of... We're starting to design the escrow. See the umbrella task at: http://jira.secondlife.com/browse/CHTTP-14 And the initial design skeleton here: http://wiki.secondlife.com/wiki/Certified_HTTP_Escrow Major accomplishments from the past week include: - oplog versioning, which is an attempt to deal with code changes in a live system - we resolved all the debates we were having on chttpdev and implemented the results with cold hard code -RYaN From tofu.linden at lindenlab.com Thu Dec 6 04:21:08 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Dec 6 04:21:16 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <475739D2.6020407@lindenlab.com> References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> <475739D2.6020407@lindenlab.com> Message-ID: <4757E934.60103@lindenlab.com> Rob Lanphier wrote: > With respect to llmozlib, that's a separate download. It has changed > fairly recently (2007-11-21), but the source is here: > https://wiki.secondlife.com/wiki/Source_downloads#Support_library_source And FYI - work is underway to move us to the 'trunk' version of LLMozLib as found at ubrowser.com. This means that we'll be using a regular version of an esoteric (but great) library, instead of an obscure fork of an esoteric library which has been a bit of a silly situation! -Tofu From sldev at free.fr Thu Dec 6 04:28:44 2007 From: sldev at free.fr (Henri Beauchamp) Date: Thu Dec 6 04:28:46 2007 Subject: [sldev] 1.18.6.0RC sources ? Message-ID: <20071206132844.2bbbcdff.sldev@free.fr> Could we get the sources, libraries and artwork packages made available on the Wiki for v1.18.6.0RC, please ? From monkowsk at watson.ibm.com Thu Dec 6 07:58:40 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Dec 6 07:58:48 2007 Subject: [sldev] www.sljirastats.com launched! In-Reply-To: <47563791.8060507@gmail.com> References: <47550428.6000401@gmail.com> <4755A8F3.1030305@watson.ibm.com> <47563791.8060507@gmail.com> Message-ID: <47581C30.8020005@watson.ibm.com> Jason, I saw your changes. Awesome. I could spend too much time reading those lists. :-) Those were the only two that I was interested in. I see these as a good place for some open source developer (or Linden Lab developer :-) to look for things to do first. Mike Jason Giglio wrote: > Mike Monkowski wrote: > >> I was looking through the "Most Hated Bugs" and "Most Wanted Features" >> and found them really interesting. But I wanted to keep going down >> the lists. How about a "more" link that displays the top 50 or so for >> the chosen list. > > > I was able to add this to the most hated and most wanted using the > search persistence/sharing functionality. > > Most of the other top 5 lists use "group by" aggregate clauses which the > query builder can't make, so it may take me a little longer before I > figure out how to allow drilling down on those.... > > I could just make a custom page with "Top 50 lists" or something like > that, if you think people want it.. > > From lenglish5 at cox.net Thu Dec 6 10:53:19 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Dec 6 10:53:21 2007 Subject: [sldev] 1.18.6.0RC sources ? In-Reply-To: <20071206132844.2bbbcdff.sldev@free.fr> References: <20071206132844.2bbbcdff.sldev@free.fr> Message-ID: <4758451F.2090107@cox.net> Henri Beauchamp wrote: > Could we get the sources, libraries and artwork packages made > available on the Wiki for v1.18.6.0RC, please ? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > Yes please. It is hard to document the login procedure for AWG when we don't have any source for it. Old login method still works, but I need to update that page: https://wiki.secondlife.com/wiki/AW_Groupies#Documenting_current_protocols Lawson From monkowsk at watson.ibm.com Thu Dec 6 11:16:41 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Dec 6 11:20:37 2007 Subject: llmozlib in the 1.18.5.3 library package too was: [sldev] Windlight 74642 sources? In-Reply-To: <475739D2.6020407@lindenlab.com> References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> <475739D2.6020407@lindenlab.com> Message-ID: <47584A99.2040500@watson.ibm.com> Rob, I believe Henri was referring to the compiled llmozlib. I have found that the 1.18.5.3 libraries package also has the old llmozlib for VS2005 (VC8) in both the lib_debug and lib_release directories. The VS2003 libraries appear to have changed, but I don't know if they're fully up to date. Because I'm using the VC8 libs, I get link messages (actually two, not just one) with the 1.18.5.3 libs. I think one of them is the same as the one below. I was able to get it to link by setting LL_LIBXUL_ENABLE=0 and modifying llcommon\llpreprocessor.h to honor that setting for Windows. I'm using SCons scripts provided by Dzonatas Sol for the compile and link. MUCH nicer than hacking the project files. Don't have to wait for CMake either. I think he's going to put some documentation on the Wiki about the procedure. Mike Rob Lanphier wrote: > I've skipped forward to FL-1.18.5.74965 (released last night): > https://wiki.secondlife.com/wiki/Source_downloads#ver_FL-1.18.5.74965 > > With respect to llmozlib, that's a separate download. It has changed > fairly recently (2007-11-21), but the source is here: > https://wiki.secondlife.com/wiki/Source_downloads#Support_library_source > > Rob ... >>I tried to compile the SVN sources, using the libraries package of the previous windlight version (available on the Wiki), but I got: >> >>/usr/src/SL/build/usr/src/SL/indra/i686-linux-client-releasefordownload/newview/llwebbrowserctrl.o: In function `LLWebBrowserCtrl::set404RedirectUrl(std::basic_string, std::allocator >)': >>llwebbrowserctrl.cpp:(.text+0x2ef4): undefined reference to `LLMozLib::set404RedirectUrl(int, std::basic_string, std::allocator >)' >>collect2: ld returned 1 exit status >>scons: *** [newview/secondlife-i686-bin-globalsyms] Error 1 >> >>So, I guess the mozlib library changed... >> >>Could we please get the full sources and packages (libraries and artwork) on the Wiki ? From lenglish5 at cox.net Thu Dec 6 16:10:16 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Dec 6 16:10:18 2007 Subject: [sldev] 1.18.6.0RC sources ? In-Reply-To: <4758451F.2090107@cox.net> References: <20071206132844.2bbbcdff.sldev@free.fr> <4758451F.2090107@cox.net> Message-ID: <47588F68.2020900@cox.net> Lawson English wrote: > Henri Beauchamp wrote: >> Could we get the sources, libraries and artwork packages made >> available on the Wiki for v1.18.6.0RC, please ? >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > Yes please. It is hard to document the login procedure for AWG when we > don't have any source for it. > > Old login method still works, but I need to update that page: > > https://wiki.secondlife.com/wiki/AW_Groupies#Documenting_current_protocols > > Eh, for the curious, Eddy Stryker/jhurliman told me what to do: do webpage login. Replace the "password", md5_password key/value pair in the login lxmlrpc call with "web_login_key" and the UUID from the output of that login, and do the same xmlrpc call as before. The webpage login is part of the https://wiki.secondlife.com/wiki/Example_protocol_code Lawson From anthony at lindenlab.com Thu Dec 6 16:39:54 2007 From: anthony at lindenlab.com (anthony@lindenlab.com) Date: Thu Dec 6 16:40:01 2007 Subject: [sldev] Source release for 1.18.6.0 Message-ID: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com> Hello everyone, Delayed a little, but worth the wait? 1.18.6.0 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.0 Release note information here: http://blog.secondlife.com/2007/12/05/new-release-candidate-viewer-1186-rc0-available-today/ Checksums: 104c282529c3d248cd69b1f439abbf4f slviewer-darwin-libs-RC-1.18.6.0.tar.gz 3719a83ce01fed1bac29ececb4993398 slviewer-linux-libs-RC-1.18.6.0.tar.gz 2533e7143d94ce19645e559dda7cb3de slviewer-src-RC-1.18.6.0.tar.gz adf2b8860e1e7358b1aca2e8aca94b42 slviewer-artwork-RC-1.18.6.0.zip 6ad050f187a9772c826c5199c7a607dc slviewer-src-RC-1.18.6.0.zip 49173ed5fedf8471bfc6239b9e8c6c00 slviewer-win32-libs-RC-1.18.6.0.zip SVN checkout: will be posted by Rob. Enjoy. -Anthony From anthony at lindenlab.com Thu Dec 6 17:14:58 2007 From: anthony at lindenlab.com (anthony@lindenlab.com) Date: Thu Dec 6 17:15:07 2007 Subject: [sldev] Source release of release branch 20071206a In-Reply-To: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com> References: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com> Message-ID: <1987.24.6.233.189.1196990098.squirrel@mail.lindenlab.com> Hello everyone, Haven't had these in a while, but following up the delayed RC viewer source, is a snapshot of release. Release has a couple changes merged in today that go beyond the release candidate merge. So if you're curious, take a peak. 20071206a source release available here: https://wiki.secondlife.com/wiki/Source_downloads#2007-Dec-06 Checksums: 0467efc87b369f7d0b208caa5c7812a5 slviewer-darwin-libs-20071206a.tar.gz 5628cf8cdad22077673cc285d38d03c7 slviewer-linux-libs-20071206a.tar.gz 841a2df36fe6578c412b59c6686b6284 slviewer-src-20071206a.tar.gz a8a31faf1d13b0ef963b5788ecface8f slviewer-artwork-20071206a.zip 0a8f60f2e6f780fc0a905f792566ff34 slviewer-src-20071206a.zip dd1540a62ae2cb64696f4c9fa8f618ab slviewer-win32-libs-20071206a.zip SVN checkout: will be posted by Rob. Enjoy. -Anthony From tess at lindenlab.com Thu Dec 6 17:25:17 2007 From: tess at lindenlab.com (Tess Chu) Date: Thu Dec 6 17:25:32 2007 Subject: [sldev] Viewer Auth + Automated Login (was RE: More about viewer auth in today's RC) In-Reply-To: <475734E8.3060002@wsu.edu> References: <4755E705.6090703@lindenlab.com> <475734E8.3060002@wsu.edu> Message-ID: <4758A0FD.8070205@lindenlab.com> We have not begun working on this yet, but it is on our list. We are currently swamped with usability bugs, working out login page cacheability, and we also have enabling proxying on our list. I'll check back in as soon as I have a more specific date for this feature. Tess > I've been in favor of the new web authentication system, but under the > assumption that we would have a new login method to replace the > current one before it became a mandatory system (and thus locking out > automated processes like bots, who are not very good at scraping HTML > forms that can dynamically change for "WebLoginKey"s). Is there any > word on progress or a timeline for the new automated login system that > doesn't involve HTML scraping? > > John > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From robla at lindenlab.com Thu Dec 6 17:41:15 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Dec 6 17:41:28 2007 Subject: [sldev] Source release for 1.18.6.0 In-Reply-To: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com> References: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com> Message-ID: <4758A4BB.6020807@lindenlab.com> Good news: Soft is diligently working on getting the build issues sorted out in the exported code, so that we know this compiles out of the box for at least one developer. Bad news: he wasn't able to get this work done before Anthony posted this source code. Good news: he's heads down on fixing this. I'll let him report when he's made progress. So, unless you're really determined, you'll probably want to hold off until he gets done before trying to build this code. Rob On 12/6/07 4:39 PM, anthony@lindenlab.com wrote: > Hello everyone, > > Delayed a little, but worth the wait? > > 1.18.6.0 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.0 > > Release note information here: > http://blog.secondlife.com/2007/12/05/new-release-candidate-viewer-1186-rc0-available-today/ > > Checksums: > > 104c282529c3d248cd69b1f439abbf4f slviewer-darwin-libs-RC-1.18.6.0.tar.gz > 3719a83ce01fed1bac29ececb4993398 slviewer-linux-libs-RC-1.18.6.0.tar.gz > 2533e7143d94ce19645e559dda7cb3de slviewer-src-RC-1.18.6.0.tar.gz > adf2b8860e1e7358b1aca2e8aca94b42 slviewer-artwork-RC-1.18.6.0.zip > 6ad050f187a9772c826c5199c7a607dc slviewer-src-RC-1.18.6.0.zip > 49173ed5fedf8471bfc6239b9e8c6c00 slviewer-win32-libs-RC-1.18.6.0.zip > > SVN checkout: will be posted by Rob. > > Enjoy. > -Anthony > > _______________________________________________ > 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/20071206/c04e5b4a/signature.pgp From ed.sykes at sheridanc.on.ca Thu Dec 6 18:09:08 2007 From: ed.sykes at sheridanc.on.ca (Ed Sykes) Date: Thu Dec 6 18:08:57 2007 Subject: [sldev] Help in compiling source in VS2003 please Message-ID: <000c01c83876$27117110$6401a8c0@t> Hi, I'm interested in compiling SL Viewer (version 1.18.5.3) using VS 2003 and am having some problems. I have followed the directions: "Compiling the viewer (MSVS2003)" https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 verbatim at least 4 times and am getting the following errors: test error PRJ0019: A tool returned an error code from "Performing Post-Build Event..." c:\linden\indra\llwindow\lldxhardware.cpp(43): fatal error C1083: Cannot open include file: 'dxdiag.h': No such file or directory c:\linden\indra\llmedia\llmediaimplquicktime.h(46): fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory c:\linden\indra\llmedia\llmediaimplquicktime.h(46): fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory c:\linden\indra\llmedia\llmediaimplquicktime.h(46): fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory c:\linden\indra\newview\viewer.cpp(264): fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory c:\linden\indra\newview\llstartup.cpp(179): fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory win_crash_logger fatal error LNK1181: cannot open input file '\linden\indra\lib_releasenoopt\i686-win32\llwindow.lib' If anyone can point me in the right direction I would DEEPLY APPRECIATE it !!! Thanks in advance, Ed Sykes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071206/1800f7b5/attachment.htm From lenglish5 at cox.net Thu Dec 6 18:08:59 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Dec 6 18:09:01 2007 Subject: [sldev] Source release for 1.18.6.0 In-Reply-To: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com> References: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com> Message-ID: <4758AB3B.2020901@cox.net> anthony@lindenlab.com wrote: > Hello everyone, > > Delayed a little, but worth the wait? > > 1.18.6.0 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.0 > > Release note information here: > http://blog.secondlife.com/2007/12/05/new-release-candidate-viewer-1186-rc0-available-today/ > > Checksums: > > 104c282529c3d248cd69b1f439abbf4f slviewer-darwin-libs-RC-1.18.6.0.tar.gz > 3719a83ce01fed1bac29ececb4993398 slviewer-linux-libs-RC-1.18.6.0.tar.gz > 2533e7143d94ce19645e559dda7cb3de slviewer-src-RC-1.18.6.0.tar.gz > adf2b8860e1e7358b1aca2e8aca94b42 slviewer-artwork-RC-1.18.6.0.zip > 6ad050f187a9772c826c5199c7a607dc slviewer-src-RC-1.18.6.0.zip > 49173ed5fedf8471bfc6239b9e8c6c00 slviewer-win32-libs-RC-1.18.6.0.zip > > SVN checkout: will be posted by Rob. > > > Great, thanks. Lawson From soft at lindenlab.com Thu Dec 6 18:23:19 2007 From: soft at lindenlab.com (Soft) Date: Thu Dec 6 18:23:21 2007 Subject: [sldev] Source release for 1.18.6.0 In-Reply-To: <4758A4BB.6020807@lindenlab.com> References: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com> <4758A4BB.6020807@lindenlab.com> Message-ID: On 12/6/07, Rob Lanphier wrote: > Good news: Soft is diligently working on getting the build issues > sorted out in the exported code, so that we know this compiles out of > the box for at least one developer. > > Bad news: he wasn't able to get this work done before Anthony posted > this source code. > > Good news: he's heads down on fixing this. I'll let him report when > he's made progress. > > So, unless you're really determined, you'll probably want to hold off > until he gets done before trying to build this code. If anyone wants to grab the Windows source and try compiling, I'd be curious if the existing source works for you. I'm having a really odd time with llviewerapp.cpp. When building the headers, it seems to be pulling in unwanted Quicktime defines for check() and verify(), but I can't yet figure out how they're getting there, or why it's different on the public source drop. From soft at lindenlab.com Thu Dec 6 19:29:47 2007 From: soft at lindenlab.com (Soft) Date: Thu Dec 6 19:29:50 2007 Subject: [sldev] Help in compiling source in VS2003 please In-Reply-To: <000c01c83876$27117110$6401a8c0@t> References: <000c01c83876$27117110$6401a8c0@t> Message-ID: On 12/6/07, Ed Sykes wrote: > > I'm interested in compiling SL Viewer (version 1.18.5.3) > using VS 2003 and am having some problems. > > I have followed the directions: > "Compiling the viewer (MSVS2003)" > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 > > verbatim at least 4 times and am getting the following errors: > > test error PRJ0019: A tool returned an error code from "Performing > Post-Build Event..." > c:\linden\indra\llwindow\lldxhardware.cpp(43): fatal error > C1083: Cannot open include file: 'dxdiag.h': No such file or directory > c:\linden\indra\llmedia\llmediaimplquicktime.h(46): fatal > error C1083: Cannot open include file: 'MacTypes.h': No such file or > directory Hi, Ed. At the very least, it looks like you need to do the DirectX and QuickTime steps in the wiki doc you link. From ed.sykes at sheridanc.on.ca Thu Dec 6 19:43:33 2007 From: ed.sykes at sheridanc.on.ca (Ed Sykes) Date: Thu Dec 6 19:43:21 2007 Subject: [sldev] Help in compiling source in VS2003 please References: <000c01c83876$27117110$6401a8c0@t> Message-ID: <001201c83883$575d1b50$6401a8c0@t> Dear Soft, Thanks for your message. I *finally* corrected these problems. You were right. Now, it compiles and builds the .exe (newview_noopt.exe) However, when I try to run it, I get: a Fatal Error Dialog box: "ERROR: LLAlertDialog::parseAlerts: Problem reading UI Alerts file: alerts.xml" When I press OK it crashes... If you could assist I would be extremely happy!! (I think I am soooo close :) Thanks for your help! Cheers, Ed ----- Original Message ----- From: "Soft" To: "Ed Sykes" Cc: Sent: Thursday, December 06, 2007 10:29 PM Subject: Re: [sldev] Help in compiling source in VS2003 please > On 12/6/07, Ed Sykes wrote: >> >> I'm interested in compiling SL Viewer (version 1.18.5.3) >> using VS 2003 and am having some problems. >> >> I have followed the directions: >> "Compiling the viewer (MSVS2003)" >> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 >> >> verbatim at least 4 times and am getting the following errors: >> >> test error PRJ0019: A tool returned an error code from "Performing >> Post-Build Event..." >> c:\linden\indra\llwindow\lldxhardware.cpp(43): fatal error >> C1083: Cannot open include file: 'dxdiag.h': No such file or directory >> c:\linden\indra\llmedia\llmediaimplquicktime.h(46): fatal >> error C1083: Cannot open include file: 'MacTypes.h': No such file or >> directory > > Hi, Ed. At the very least, it looks like you need to do the DirectX > and QuickTime steps in the wiki doc you link. From soft at lindenlab.com Thu Dec 6 19:54:33 2007 From: soft at lindenlab.com (Soft) Date: Thu Dec 6 19:54:35 2007 Subject: [sldev] Help in compiling source in VS2003 please In-Reply-To: <001201c83883$575d1b50$6401a8c0@t> References: <000c01c83876$27117110$6401a8c0@t> <001201c83883$575d1b50$6401a8c0@t> Message-ID: On 12/6/07, Ed Sykes wrote: > Dear Soft, > > Thanks for your message. > I *finally* corrected these problems. You were right. > Now, it compiles and builds the .exe (newview_noopt.exe) > However, when I try to run it, I get: > a Fatal Error Dialog box: > "ERROR: LLAlertDialog::parseAlerts: Problem reading UI Alerts file: > alerts.xml" > When I press OK it crashes... > > If you could assist I would be extremely happy!! (I think I am soooo close > :) You probably need to unzip the artwork file still. Make sure it overlaps the same directories as your library and source files did. If that's not it, make sure you're launching from the proper directory (easiest way is to run it from inside VS instead of running the exe manually) From Anders at Arnholm.se Thu Dec 6 21:33:02 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Thu Dec 6 21:33:44 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4755E705.6090703@lindenlab.com> References: <4755E705.6090703@lindenlab.com> Message-ID: <20071207053302.GF28695@arnholm.se> On Tue, Dec 04, 2007 at 03:47:17PM -0800, Tess Chu wrote: > Much of the ensued debate centered around the relative security of the old > xml-rpc based approach versus the new approach of using HTML. We *weren't* > necessarily trying to make the mechanism itself more secure (we believe Much of this because you, (meaning the lindens) described the method as: web (IE/Safari/firefox) -> viewer Not as it is: viewer -> super speical http/html (+something?) brower lookalike thing -> info to viewer The issues and compatibility problems ate totally different the problem domain is totally different. Now we can wounder what the heck is needed from the viewer to work? CSS? JavaScript? Image rendering? This browser is apparently able to save into, and have a button for it in the webpage, what does that mean? What is the protocol used to steer the special viewer... A descriptions, some code maybe descriptions and specifications here probably much more important that code. / Balp -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071207/fd80bdf9/attachment.pgp From lenglish5 at cox.net Thu Dec 6 22:30:08 2007 From: lenglish5 at cox.net (Lawson English) Date: Thu Dec 6 22:30:10 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <20071207053302.GF28695@arnholm.se> References: <4755E705.6090703@lindenlab.com> <20071207053302.GF28695@arnholm.se> Message-ID: <4758E870.4080701@cox.net> Anders Arnholm wrote: > On Tue, Dec 04, 2007 at 03:47:17PM -0800, Tess Chu wrote: > > >> Much of the ensued debate centered around the relative security of the old >> xml-rpc based approach versus the new approach of using HTML. We *weren't* >> necessarily trying to make the mechanism itself more secure (we believe >> > > There are apparently 2 different ways to go: 1) viewer(browser) => webpage => url+UUID (cap) => viewer or 2) 3rd part browser => webpage => url + UUID (cap) => viewer that cap retrieved from the webpage replaces the password that used to be input directly into the viewer, so the xmlrpc call remains identical except the key/value pair: 'web_login_key': UUID replaces the key/value pair: 'password': '$1$' + MD5_endcoded_password Python scripts to handle the login are found here though you gotta replace the key/value pairs in the source yourself for the xml-rpc call because I'm lazy: https://wiki.secondlife.com/wiki/Example_protocol_code Lawson > Much of this because you, (meaning the lindens) described the method as: > > web (IE/Safari/firefox) -> viewer > > Not as it is: > > viewer -> super speical http/html (+something?) brower lookalike thing > -> info to viewer > > The issues and compatibility problems ate totally different the problem > domain is totally different. Now we can wounder what the heck is needed > from the viewer to work? CSS? JavaScript? Image rendering? This browser is > apparently able to save into, and have a button for it in the > webpage, what does that mean? What is the protocol used to steer the > special viewer... A descriptions, some code maybe descriptions and > specifications here probably much more important that code. > > / Balp > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From alexander.treptow at zweitgeist.com Fri Dec 7 00:05:42 2007 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Fri Dec 7 00:05:58 2007 Subject: [sldev] Help in compiling source in VS2003 please Message-ID: <4758FED6.3030300@zweitgeist.com> You either need the QuickTime-SDK or disable Quicktime https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#QuickTime_removal This will fix the Errors on MacTypes.h I dont know what you need for the dxdiag.h maybe its the directx sdk. Greets, Alex From george.williams at gmail.com Fri Dec 7 00:23:09 2007 From: george.williams at gmail.com (George Williams) Date: Fri Dec 7 00:23:12 2007 Subject: [sldev] playing a movie on a texture Message-ID: <85e6f7f00712070023g5ca751e9ud4a38b1647a071ef@mail.gmail.com> Hi, I am hoping someone can point me in the right direction here, I apologize in advance if this is not the correct forum or if I'm being a bonehead. I would like to play a movie on a polygon in second life. Is this possible with the existing player? If not, I would like to add it. Do you have suggestions on where I should start modifying the player to make this happen? ( So you know, I have downloaded, compiled the latest viewer, and have successfully made minor changes. So, I am past this particular hurdle. ) Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071207/af19c26c/attachment.htm From kamilion at gmail.com Fri Dec 7 00:29:17 2007 From: kamilion at gmail.com (Kamilion) Date: Fri Dec 7 00:29:24 2007 Subject: [sldev] playing a movie on a texture In-Reply-To: <85e6f7f00712070023g5ca751e9ud4a38b1647a071ef@mail.gmail.com> References: <85e6f7f00712070023g5ca751e9ud4a38b1647a071ef@mail.gmail.com> Message-ID: Set your land's media texture to a quicktime stream. About land -> Media tab, set a texture to replace with video, set a URL. Enable quicktime on windows or gstreamer on linux. Click play button in SL. On Dec 7, 2007 12:23 AM, George Williams wrote: > Hi, > > I am hoping someone can point me in the right direction here, I apologize in > advance if this is not the correct forum or if I'm being a bonehead. > > I would like to play a movie on a polygon in second life. Is this possible > with the existing player? > > If not, I would like to add it. Do you have suggestions on where I should > start modifying the player to make this happen? > > ( So you know, I have downloaded, compiled the latest viewer, and have > successfully made minor changes. So, I am past this particular hurdle. ) > > Thank you! > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From robin.cornelius at gmail.com Fri Dec 7 02:02:18 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 7 02:02:23 2007 Subject: [sldev] [VWR] The OpenJPEG lossless decode bug In-Reply-To: <1196891406.21792.129.camel@localhost> References: <1196891406.21792.129.camel@localhost> Message-ID: On Dec 5, 2007 9:50 PM, Callum Lerwick wrote: > --- linden.orig/indra/llimage/llimagej2c.cpp 2007-11-07 20:18:06.000000000 -0600 > +++ linden.patched/indra/llimage/llimagej2c.cpp 2007-12-05 13:14:53.000000000 -0600 > @@ -310,7 +310,7 @@ > //static > S32 LLImageJ2C::calcDataSizeJ2C(S32 w, S32 h, S32 comp, S32 discard_level, F32 rate) > { > - if (rate <= 0.f) rate = .125f; > + if (rate <= 0.f) rate = 0.5f; > while (discard_level > 0) > { > if (w < 1 || h < 1) > > Success! (sorta) I no longer see corrupted textures. Right now I am > staring at a perfect ant, in the SW corner of Hippotropolis. Cool, many thanks, nice work. Forgive me for being very stupid, but what effect does this now have on the previous patch of :- + if(gSavedSettings.getBOOL("OpenJPEGEncodeLossless")){ + parameters.tcp_numlayers = 1; + parameters.tcp_rates[0] = 0.0f; + }else{ + parameters.tcp_numlayers = 6; + parameters.tcp_rates[0] = 1280.0f; + parameters.tcp_rates[1] = 640.0f; + parameters.tcp_rates[2] = 320.0f; + parameters.tcp_rates[3] = 160.0f; + parameters.tcp_rates[4] = 80.0f; + parameters.tcp_rates[5] = 40.0f; + parameters.irreversible = 1; + if(raw_image.getComponents() >= 3){ + parameters.tcp_mct = 1; + } + } I can't remember what the purpose of this was, is it still needed now? Or can you just leave it applied but use the "OpenJPEGEncodeLossless" to turn on/off lossless and have success? Thanks for helping someone having a stupid day :-) Robin From candide.lemay at gmail.com Fri Dec 7 03:08:32 2007 From: candide.lemay at gmail.com (Candide LeMay) Date: Fri Dec 7 03:08:35 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <4757E934.60103@lindenlab.com> References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> <475739D2.6020407@lindenlab.com> <4757E934.60103@lindenlab.com> Message-ID: There's a new windlight release, again with no source drop. Guys ... if you insist on mandatory windlight client updates, publish the source code too! I've just managed to compile 74965 yesterday and it's useless already. candide From nicholaz at blueflash.cc Fri Dec 7 03:19:33 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Dec 7 03:19:41 2007 Subject: [sldev] build errors in 1.18.6.0 (was: Source release for 1.18.6.0) Message-ID: <47592C45.8070800@blueflash.cc> >> If anyone wants to grab the Windows source and try compiling, I'd be curious if the existing source works for you. I'm having a really odd time with llviewerapp.cpp. When building the headers, it seems to be pulling in unwanted Quicktime defines for check() and verify(), but I can't yet figure out how they're getting there, or why it's different on the public source drop. << Fails with conflicts on quicktime AssertMacros.h in pipeline.h The quicktime stuff most likely comes through the quicktime part in llappviewer.cpp (around line 120). There are already a couple of files other (like llfilepicker.h, dirpicker..h moviemaker.h) with this problem. They have a few lines saying "// AssertMacros.h does bad things. #undef ..." So for a quick fix a chunk like // AssertMacros.h does bad things. #undef verify #undef check #undef require needs to go into pipeline.h and folderview.h Moving the quicktime includes to the bottom may also help. The better solution would be of course to rename the methods to something like verifyPipeline or checkItems Nick From Anders at Arnholm.se Fri Dec 7 05:47:51 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Fri Dec 7 05:48:11 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <4758E870.4080701@cox.net> References: <4755E705.6090703@lindenlab.com> <20071207053302.GF28695@arnholm.se> <4758E870.4080701@cox.net> Message-ID: <20071207134751.GG28695@arnholm.se> On Thu, Dec 06, 2007 at 11:30:08PM -0700, Lawson English wrote: > Anders Arnholm wrote: > 1) viewer(browser) => webpage => url+UUID (cap) => viewer > or > 2) 3rd part browser => webpage => url + UUID (cap) => viewer One think i don't know and to be honest can't find any info about is what is needed to get the webpage working, HTML4, XHTML, CSS, JavaScript. However my main fucus is understanding HOW TEH F**K to get the (NOW AGAIN OUTDATED) WindLight source to compile.... -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071207/91f237c3/attachment.pgp From alissa_sabre at yahoo.co.jp Thu Dec 6 15:28:33 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Dec 7 05:48:39 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <475739D2.6020407@lindenlab.com> References: <475739D2.6020407@lindenlab.com> Message-ID: <74dsbeb4ndodsL1nJ4Gehi8a.alissa_sabre@yahoo.co.jp> > With respect to llmozlib, that's a separate download. It has changed > fairly recently (2007-11-21), What? Let me make sure the point. Are you saying that you have changed the way you distribute the llmozlib binary? Does it mean the future prebuilt third-party library bundle to be released after 2007-11-21 doesn not include llmozlib binary and open source developer need to download it separately? # I'm not criticising. I'm just asking... -------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/ From robin.cornelius at gmail.com Fri Dec 7 06:02:41 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 7 06:02:45 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <74dsbeb4ndodsL1nJ4Gehi8a.alissa_sabre@yahoo.co.jp> References: <475739D2.6020407@lindenlab.com> <74dsbeb4ndodsL1nJ4Gehi8a.alissa_sabre@yahoo.co.jp> Message-ID: On Dec 6, 2007 11:28 PM, Alissa Sabre wrote: > > With respect to llmozlib, that's a separate download. It has changed > > fairly recently (2007-11-21), > > What? Let me make sure the point. > > Are you saying that you have changed the way you distribute the > llmozlib binary? Does it mean the future prebuilt third-party library > bundle to be released after 2007-11-21 doesn not include llmozlib > binary and open source developer need to download it separately? > > # I'm not criticising. I'm just asking... (i think) That was just referring to the llmozlib source, llmozlib in linden builds is hard welded to the binary, plus has all the xpcom/xul baggage. I think i am still the only one shipping a dynamic library version of llmozlib without baggage and i really hope this is the way things can end up. Tofu seemed to suggest world domination plans for llmozlib so hopefully this will become a true separate project at ubrowser.com and i presume they will just ship a compiled llmozlib as they do for all existing libraries now but one could if they so wished go to ubrowser and compile it themselves. In fact hijacking the thread completely. Would it be worth :- 1) creating a dynamic llmozlib regardless of if in needs its own xpcom/xul or uses xul runner This would allow versions to be upgraded seperatly to the viewer. As logged on JIRA already this I have done both with xulrunner and with my own xpcom/xul baggage. 2) Can we runtime detect llmozlib instead of linking and change ALL of the #ifdef LL_LIBXUL_ENABLED to a runtime flag that is set TRUE is llmozlib.so/dll is detected?? Robin From robin.cornelius at gmail.com Fri Dec 7 06:05:10 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 7 06:05:13 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <20071207134751.GG28695@arnholm.se> References: <4755E705.6090703@lindenlab.com> <20071207053302.GF28695@arnholm.se> <4758E870.4080701@cox.net> <20071207134751.GG28695@arnholm.se> Message-ID: On Dec 7, 2007 1:47 PM, Anders Arnholm wrote: > On Thu, Dec 06, 2007 at 11:30:08PM -0700, Lawson English wrote: > > Anders Arnholm wrote: > > 1) viewer(browser) => webpage => url+UUID (cap) => viewer > > or > > 2) 3rd part browser => webpage => url + UUID (cap) => viewer > > One think i don't know and to be honest can't find any info about is > what is needed to get the webpage working, HTML4, XHTML, CSS, > JavaScript. However my main fucus is understanding HOW TEH F**K to get > the (NOW AGAIN OUTDATED) WindLight source to compile.... > Come and join the party :- http://jira.secondlife.com/browse/VWR-3721 If you have any other Windlight reports, file them and we can link them together. Where have you got stuck compiling now? Robin From Dana.Fagerstrom at Sun.COM Fri Dec 7 06:13:34 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Fri Dec 7 06:13:49 2007 Subject: [sldev] [vwr] SDL strangeness with 1.18.5.3 and where the hell is glh Message-ID: <4759550E.3050006@sun.com> This note is mostly intended to Linux folks. Is anyone else noticing any strange anomalies with 1.18.5.3? I got a clean and happy build of this version on OpenSolaris but when I ran the same build on Solaris 10, I get: WARNING: createContext: window creation failure. SDL: X11 driver not configured with OpenGL I'm baffled at what is causing this. 1.18.4.x runs fine on Solaris 10 and none of the libraries, SConstruct, or my Solaris-related patches changed between releases. I'm therefore totally baffled. Thanks, D From robin.cornelius at gmail.com Fri Dec 7 06:16:38 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 7 06:16:44 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <4757E934.60103@lindenlab.com> References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> <475739D2.6020407@lindenlab.com> <4757E934.60103@lindenlab.com> Message-ID: On Dec 6, 2007 12:21 PM, Tofu Linden wrote: > Rob Lanphier wrote: > > With respect to llmozlib, that's a separate download. It has changed > > fairly recently (2007-11-21), but the source is here: > > https://wiki.secondlife.com/wiki/Source_downloads#Support_library_source > > And FYI - work is underway to move us to the 'trunk' version of > LLMozLib as found at ubrowser.com. This means that we'll be using a > regular version of an esoteric (but great) library, instead of > an obscure fork of an esoteric library which has been a bit of a > silly situation! Are we going to get a separate public facing SVN for llmozlib?? that may help a lot. You could either do that yourselves or just chuck it on sourceforge or something, providing you don't go off on one internally adding things it should be good for everyone. I though the version on ubrowser was now out of date and the version on your source download page was the most upto date (public) release? There seems to be some external to secondlife interest in mozlib as well so this is very positive. Are you going to inlist any opensource help with this, the ubrowser site looks like a project that died in 2006 and whist you have been working internally on it and releasing with the viewer source code this is a confusion situation. Robin Robin From Dana.Fagerstrom at Sun.COM Fri Dec 7 06:39:45 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Fri Dec 7 06:40:14 2007 Subject: [Fwd: [sldev] [vwr] SDL strangeness with 1.18.5.3 and where the hell is glh] Message-ID: <47595B31.5070608@sun.com> Whoops... Forgot to remove the bit about glh from the subject line. Since I mentioned it, does anyone know where the glh sources are? I found libglh but that doesn't look exactly the same. At least I hope it isn't because it doesn't look like libglh is giving Linux much focus and the library itself is mostly x86 assembler - something that severely impacts SL portability. D -------- Original Message -------- Subject: [sldev] [vwr] SDL strangeness with 1.18.5.3 and where the hell is glh Date: Fri, 07 Dec 2007 09:13:34 -0500 From: Dana Fagerstrom To: sldev@lists.secondlife.com This note is mostly intended to Linux folks. Is anyone else noticing any strange anomalies with 1.18.5.3? I got a clean and happy build of this version on OpenSolaris but when I ran the same build on Solaris 10, I get: WARNING: createContext: window creation failure. SDL: X11 driver not configured with OpenGL I'm baffled at what is causing this. 1.18.4.x runs fine on Solaris 10 and none of the libraries, SConstruct, or my Solaris-related patches changed between releases. I'm therefore totally baffled. Thanks, D _______________________________________________ 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 robin.cornelius at gmail.com Fri Dec 7 06:48:24 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 7 06:48:27 2007 Subject: [Fwd: [sldev] [vwr] SDL strangeness with 1.18.5.3 and where the hell is glh] In-Reply-To: <47595B31.5070608@sun.com> References: <47595B31.5070608@sun.com> Message-ID: On Dec 7, 2007 2:39 PM, Dana Fagerstrom wrote: > > Whoops... Forgot to remove the bit about glh from the subject line. > > Since I mentioned it, does anyone know where the glh sources are? I > found libglh but that doesn't look exactly the same. At least I hope it > isn't because it doesn't look like libglh is giving Linux much focus and > the library itself is mostly x86 assembler - something that severely > impacts SL portability. > Its not a lib rather a load of helper headers files for openGL. Look on http://jira.secondlife.com/browse/VWR-3415 there is a link on there to one version I found a link to a download page on nvidias site .... try http://developer.nvidia.com/attach/8196 also known as "nvparse" and thats nvparse.zip on that link. Robin From Dana.Fagerstrom at Sun.COM Fri Dec 7 07:20:31 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Fri Dec 7 07:20:39 2007 Subject: [Fwd: [sldev] [vwr] SDL strangeness with 1.18.5.3 and where the hell is glh] In-Reply-To: References: <47595B31.5070608@sun.com> Message-ID: <475964BF.70905@sun.com> Excellent! Thanks, D Robin Cornelius wrote: > On Dec 7, 2007 2:39 PM, Dana Fagerstrom wrote: >> Whoops... Forgot to remove the bit about glh from the subject line. >> >> Since I mentioned it, does anyone know where the glh sources are? I >> found libglh but that doesn't look exactly the same. At least I hope it >> isn't because it doesn't look like libglh is giving Linux much focus and >> the library itself is mostly x86 assembler - something that severely >> impacts SL portability. >> > > Its not a lib rather a load of helper headers files for openGL. > > Look on http://jira.secondlife.com/browse/VWR-3415 there is a link on > there to one version > > I found a link to a download page on nvidias site .... try > http://developer.nvidia.com/attach/8196 also known as "nvparse" and > thats nvparse.zip on that link. > > Robin > _______________________________________________ > 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 monkowsk at watson.ibm.com Fri Dec 7 08:12:39 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Dec 7 08:12:51 2007 Subject: llmozlib was: [sldev] Windlight 74642 sources? In-Reply-To: References: <475739D2.6020407@lindenlab.com> <74dsbeb4ndodsL1nJ4Gehi8a.alissa_sabre@yahoo.co.jp> Message-ID: <475970F7.7000003@watson.ibm.com> I can verify that the RC 1.18.6.0 library bundle does include llmozlib. The 1.18.5.3 Windows library bundle contains an out of date VS2005 version of llmozlib (llmozlib_vc80.lib, both lib_release and lib_debug vesions) so I used the one in the RC 1.18.6.0 bundle and it works fine. A dynamic llmozlib may have benefits, but this is an example where the version could not have been upgraded separately from the viewer, since new function calls were added. Having it statically linked means you find the problems at build time rather than at run time and you can always be sure that your customer is using the right version. Mike Robin Cornelius wrote: > On Dec 6, 2007 11:28 PM, Alissa Sabre wrote: > >>>With respect to llmozlib, that's a separate download. It has changed >>>fairly recently (2007-11-21), >> >>What? Let me make sure the point. >> >>Are you saying that you have changed the way you distribute the >>llmozlib binary? Does it mean the future prebuilt third-party library >>bundle to be released after 2007-11-21 doesn not include llmozlib >>binary and open source developer need to download it separately? >> >># I'm not criticising. I'm just asking... > > > (i think) That was just referring to the llmozlib source, llmozlib in > linden builds is hard welded to the binary, plus has all the xpcom/xul > baggage. I think i am still the only one shipping a dynamic library > version of llmozlib without baggage and i really hope this is the way > things can end up. > > Tofu seemed to suggest world domination plans for llmozlib so > hopefully this will become a true separate project at ubrowser.com and > i presume they will just ship a compiled llmozlib as they do for all > existing libraries now but one could if they so wished go to ubrowser > and compile it themselves. > > In fact hijacking the thread completely. Would it be worth :- > > 1) creating a dynamic llmozlib regardless of if in needs its own > xpcom/xul or uses xul runner > This would allow versions to be upgraded seperatly to the viewer. As > logged on JIRA already this I have done both with xulrunner and with > my own xpcom/xul baggage. > > 2) Can we runtime detect llmozlib instead of linking and change ALL of > the #ifdef LL_LIBXUL_ENABLED to a runtime flag that is set TRUE is > llmozlib.so/dll is detected?? > > Robin > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nikki at cf-estates.com Fri Dec 7 08:15:34 2007 From: nikki at cf-estates.com (nikki@cf-estates.com) Date: Fri Dec 7 08:16:32 2007 Subject: [sldev] 18.6.0 build errors VS2005 Message-ID: <20071207081534.4ja29rl9vogcco0k@66.152.166.10> Did anyone that successfully compiled 18.6.0 encounter and resolve these errors? 2>llappviewer.cpp 2>f:\slclient\18_6_0\linden\indra\newview\llfolderview.h(215) : error C2208: 'S32' : no members defined using this type 2>f:\slclient\18_6_0\linden\indra\newview\pipeline.h(173) : warning C4003: not enough actual parameters for macro 'verify' 2>f:\slclient\18_6_0\linden\indra\newview\pipeline.h(173) : error C2059: syntax error : 'do' 2>f:\slclient\18_6_0\linden\indra\newview\pipeline.h(173) : error C2334: unexpected token(s) preceding '{'; skipping apparent function body 2>f:\slclient\18_6_0\linden\indra\newview\pipeline.h(173) : error C2059: syntax error : 'while' 2>f:\slclient\18_6_0\linden\indra\newview\pipeline.h(173) : error C2238: unexpected token(s) preceding ';' From soft at lindenlab.com Fri Dec 7 08:49:13 2007 From: soft at lindenlab.com (Soft) Date: Fri Dec 7 08:49:16 2007 Subject: [sldev] 18.6.0 build errors VS2005 In-Reply-To: <20071207081534.4ja29rl9vogcco0k@66.152.166.10> References: <20071207081534.4ja29rl9vogcco0k@66.152.166.10> Message-ID: On 12/7/07, nikki@cf-estates.com wrote: > Did anyone that successfully compiled 18.6.0 encounter and resolve > these errors? > > 2>llappviewer.cpp > 2>f:\slclient\18_6_0\linden\indra\newview\llfolderview.h(215) : error > C2208: 'S32' : no members defined using this type A fix is coming From lenglish5 at cox.net Fri Dec 7 09:13:35 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Dec 7 09:13:38 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <20071207134751.GG28695@arnholm.se> References: <4755E705.6090703@lindenlab.com> <20071207053302.GF28695@arnholm.se> <4758E870.4080701@cox.net> <20071207134751.GG28695@arnholm.se> Message-ID: <47597F3F.2010404@cox.net> Anders Arnholm wrote: > On Thu, Dec 06, 2007 at 11:30:08PM -0700, Lawson English wrote: > >> Anders Arnholm wrote: >> 1) viewer(browser) => webpage => url+UUID (cap) => viewer >> or >> 2) 3rd part browser => webpage => url + UUID (cap) => viewer >> > > One think i don't know and to be honest can't find any info about is > what is needed to get the webpage working, HTML4, XHTML, CSS, > JavaScript. However my main fucus is understanding HOW TEH F**K to get > the (NOW AGAIN OUTDATED) WindLight source to compile.... > > Well, the source code I pointed to was in Python. https://wiki.secondlife.com/wiki/Example_protocol_code to summarize https POST: to "secure-web14.secondlife.com". path: "/inworld/go.php" headers: "Content-type"= "application/x-www-form-urlencoded"="Accept="text/plain" body: 'username' ='Firstname', 'lastname' = 'Lastname', 'password' = 'password secret psst!', 'continuation' = '','grid' ='agni', 'location' = 'home', The response will be a dictionary that includes the web_login_key, firstname, lastname,location... So use those values (which you used to get via the dialog box in the viewer) in the xmlprc call you normally do for login but substitute the web_login_key key/value pair for the password/"1$1" + md5_encrypted_password key/value pair. The response to the xmlrpc call will be the same as before. https://wiki.secondlife.com/wiki/Current_login_protocols From secret.argent at gmail.com Fri Dec 7 09:26:58 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Dec 7 09:27:28 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> <475739D2.6020407@lindenlab.com> <4757E934.60103@lindenlab.com> Message-ID: <166F005A-D287-4F8F-AF81-893C2F5E3944@gmail.com> The mandatory updates also make it impossible to compare different versions of Windlight. Can we have a sliding window of one version between mandatory updates? From jhurliman at wsu.edu Fri Dec 7 10:14:41 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Dec 7 10:14:48 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <20071207134751.GG28695@arnholm.se> References: <4755E705.6090703@lindenlab.com> <20071207053302.GF28695@arnholm.se> <4758E870.4080701@cox.net> <20071207134751.GG28695@arnholm.se> Message-ID: <47598D91.1020801@wsu.edu> Anders Arnholm wrote: > On Thu, Dec 06, 2007 at 11:30:08PM -0700, Lawson English wrote: > >> Anders Arnholm wrote: >> 1) viewer(browser) => webpage => url+UUID (cap) => viewer >> or >> 2) 3rd part browser => webpage => url + UUID (cap) => viewer >> > > One think i don't know and to be honest can't find any info about is > what is needed to get the webpage working, HTML4, XHTML, CSS, > JavaScript. However my main fucus is understanding HOW TEH F**K to get > the (NOW AGAIN OUTDATED) WindLight source to compile.... > You need to be able to POST using HTTP/1.1, so telnet will do. When the multi-phase authentication comes where more authentication steps could be returned instead of the Location header right away the requirements might change, but there also might be an additional LLSD interface to the system at that point so it is just speculation right now. John From anthony at lindenlab.com Fri Dec 7 10:14:42 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Fri Dec 7 10:15:20 2007 Subject: [sldev] Source release for 1.18.6.0 In-Reply-To: References: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com> <4758A4BB.6020807@lindenlab.com> Message-ID: <47598D92.3030503@lindenlab.com> Soft was able to resolve the issue with the source drop. The files have been updated, so report any errors as new ones. The release snapshot will be updated as well later today, or next week. Soft wrote: > On 12/6/07, Rob Lanphier wrote: > >> Good news: Soft is diligently working on getting the build issues >> sorted out in the exported code, so that we know this compiles out of >> the box for at least one developer. >> >> Bad news: he wasn't able to get this work done before Anthony posted >> this source code. >> >> Good news: he's heads down on fixing this. I'll let him report when >> he's made progress. >> >> So, unless you're really determined, you'll probably want to hold off >> until he gets done before trying to build this code. >> > > If anyone wants to grab the Windows source and try compiling, I'd be > curious if the existing source works for you. I'm having a really odd > time with llviewerapp.cpp. When building the headers, it seems to be > pulling in unwanted Quicktime defines for check() and verify(), but I > can't yet figure out how they're getting there, or why it's different > on the public source drop. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From labrat.hb at gmail.com Fri Dec 7 10:26:08 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Dec 7 10:26:11 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: <166F005A-D287-4F8F-AF81-893C2F5E3944@gmail.com> References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> <475739D2.6020407@lindenlab.com> <4757E934.60103@lindenlab.com> <166F005A-D287-4F8F-AF81-893C2F5E3944@gmail.com> Message-ID: I'm fairly certain that you can change the channel in your own compiled windlight version to bypass the mandatory update check On Dec 7, 2007 9:26 AM, Argent Stonecutter wrote: > The mandatory updates also make it impossible to compare different > versions of Windlight. Can we have a sliding window of one version > between mandatory updates? > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Fri Dec 7 10:34:43 2007 From: soft at lindenlab.com (Soft) Date: Fri Dec 7 10:34:45 2007 Subject: [sldev] Re: build errors in 1.18.6.0 (was: Source release for 1.18.6.0) In-Reply-To: <47592C45.8070800@blueflash.cc> References: <47592C45.8070800@blueflash.cc> Message-ID: On 12/7/07, Nicholaz Beresford wrote: > > >> If anyone wants to grab the Windows source and try compiling, I'd be > curious if the existing source works for you. I'm having a really odd > time with llviewerapp.cpp. When building the headers, it seems to be > pulling in unwanted Quicktime defines for check() and verify(), but I > can't yet figure out how they're getting there, or why it's different > on the public source drop. << > > Fails with conflicts on quicktime AssertMacros.h in pipeline.h > > The quicktime stuff most likely comes through the quicktime part > in llappviewer.cpp (around line 120). > > There are already a couple of files other (like llfilepicker.h, > dirpicker..h moviemaker.h) with this problem. They have a few > lines saying "// AssertMacros.h does bad things. #undef ..." I didn't catch those. That explains why it wasn't failing consistently, which had me confounded. > Moving the quicktime includes to the bottom may also help. That's exactly what I did. Thanks much, Nicholaz > The better solution would be of course to rename the methods to > something like verifyPipeline or checkItems The better solution would be for devs not to excrete such common labels as preprocessor defines. At the very least, anything exported by QT's headers deserves a qt prefix. Grr. From blakar at gmail.com Fri Dec 7 10:46:45 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Fri Dec 7 10:46:54 2007 Subject: [sldev] Windlight 74642 sources? In-Reply-To: References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> <475739D2.6020407@lindenlab.com> <4757E934.60103@lindenlab.com> <166F005A-D287-4F8F-AF81-893C2F5E3944@gmail.com> Message-ID: <7992d0d60712071046k80d311va3458529f4cbb4ec@mail.gmail.com> I did it last time and it works just fine. The only change I was interested in (VWR-3403) was something I had done myself already anyway. Dirk aka Blakar Ogre On Dec 7, 2007 7:26 PM, Harold Brown wrote: > I'm fairly certain that you can change the channel in your own > compiled windlight version to bypass the mandatory update check > > > On Dec 7, 2007 9:26 AM, Argent Stonecutter wrote: > > The mandatory updates also make it impossible to compare different > > versions of Windlight. Can we have a sliding window of one version > > between mandatory updates? > > > > > > _______________________________________________ > > 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 robin.cornelius at gmail.com Fri Dec 7 13:32:09 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 7 13:27:47 2007 Subject: [sldev] [VWR] gstreamer video errors Message-ID: <4759BBD9.7030707@gmail.com> Hi everyone, anybody got any clue about gstreamer on linux. I'm getting the following warning/error int the log:- (gecko:28079): GLib-GObject-WARNING **: specified class size for type `GstSLVideo' is smaller than the parent type's `GstVideoSink' class size (gecko:28079): GStreamer-CRITICAL **: gst_element_register: assertion `g_type_is_a (type, GST_TYPE_ELEMENT)' failed (gecko:28079): GLib-GObject-WARNING **: specified class size for type `GstSLVideo' is smaller than the parent type's `GstVideoSink' class size 2007-12-07T21:21:40Z WARNING: init: Could not instantiate private-slvideo element. 2007-12-07T21:21:40Z INFO: convertImageAndLoadUrl: MEDIA> unable to load http://www.americafree.tv/unicast_mov/AmericaFreeTVClassics.mov Just wonder if this rings any bells with anyone? I'm on 1.18.6.0 Debian AMD64 build. Robin -------------- 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/20071207/75afc4ba/signature.pgp From seg at haxxed.com Fri Dec 7 13:55:18 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Dec 7 13:55:29 2007 Subject: llmozlib was: [sldev] Windlight 74642 sources? In-Reply-To: <475970F7.7000003@watson.ibm.com> References: <475739D2.6020407@lindenlab.com> <74dsbeb4ndodsL1nJ4Gehi8a.alissa_sabre@yahoo.co.jp> <475970F7.7000003@watson.ibm.com> Message-ID: <1197064518.29345.1.camel@localhost> On Fri, 2007-12-07 at 11:12 -0500, Mike Monkowski wrote: > A dynamic llmozlib may have benefits, but this is an example where the > version could not have been upgraded separately from the viewer, since > new function calls were added. Having it statically linked means you > find the problems at build time rather than at run time and you can > always be sure that your customer is using the right version. This is why we have soversions. -------------- 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/20071207/076bcbc9/attachment.pgp From annagulaev at gmail.com Fri Dec 7 14:05:12 2007 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri Dec 7 14:05:16 2007 Subject: [sldev] Region UUIDs and Region Handles In-Reply-To: References: <473CDAC2.6070307@dzonux.net> <473CDAF3.1020401@dzonux.net> <4751B66B.70807@dzonux.net> Message-ID: Send a RegionHandleRequest and wait for a RegionIDAndHandleReply. On 12/2/07, Matthew Dowd wrote: > > > Hi, > > is there an easy way to convert a region UUID to a region handle? I've > tried to look for this in the code but it isn't obvious! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071207/874e9809/attachment.htm From robin.cornelius at gmail.com Fri Dec 7 14:24:07 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 7 14:20:13 2007 Subject: llmozlib was: [sldev] Windlight 74642 sources? In-Reply-To: <1197064518.29345.1.camel@localhost> References: <475739D2.6020407@lindenlab.com> <74dsbeb4ndodsL1nJ4Gehi8a.alissa_sabre@yahoo.co.jp> <475970F7.7000003@watson.ibm.com> <1197064518.29345.1.camel@localhost> Message-ID: <4759C807.90204@gmail.com> Callum Lerwick wrote: > On Fri, 2007-12-07 at 11:12 -0500, Mike Monkowski wrote: >> A dynamic llmozlib may have benefits, but this is an example where the >> version could not have been upgraded separately from the viewer, since >> new function calls were added. Having it statically linked means you >> find the problems at build time rather than at run time and you can >> always be sure that your customer is using the right version. > > This is why we have soversions. > Don't forget this is not so common in the world of windows. The unix so name has been used for quite a while but with .dlls you are sometimes lucky to get any indication of what is going on. I have seen efforts at so names with things like MFC42.DLL but most don't seem to bother. But i agree sonames really are important and do stop this problem if the library authors respect the rules. Robin -------------- 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/20071207/8d6aaca6/signature.pgp From annagulaev at gmail.com Fri Dec 7 14:26:59 2007 From: annagulaev at gmail.com (Anna Gulaev) Date: Fri Dec 7 14:27:02 2007 Subject: [sldev] z-coord of avatars in remote region Message-ID: I'd like to get the z-coord of all avatars in a remote region. I can apparently get the x & y coordinates by requesting map info. The z-coord is offered up in fine detail for avatars within my draw distance and in coarse detail for avatars within range of my minimap. I do not see a way to request this info. Is there a way? In particular, I'd like to receive the coarse data that gets stored in mMapAvatars, but this is only gathered for regions in the mActiveRegionList, and the only region other than the local region that get added to the active region list happen as a result of an EnableSimulator message, handled by process_enable_simulator. As far as I can tell. I see no way to request that message. As far as I can tell it's offered to me based on my location. Is there a way to get the coarse (or fine) coordinates of avatars in a remote region? I don't need IDs, I just need coordinates. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071207/06e2519a/attachment.htm From Dana.Fagerstrom at Sun.COM Fri Dec 7 17:08:53 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Fri Dec 7 17:09:01 2007 Subject: [sldev] Re: [vwr] SDL strangeness with 1.18.5.3 and where the hell is glh In-Reply-To: <4759550E.3050006@sun.com> References: <4759550E.3050006@sun.com> Message-ID: <4759EEA5.30207@sun.com> Found the problem... It was a bad build of the SDL library. Sorry for the extra noise. D > This note is mostly intended to Linux folks. > > Is anyone else noticing any strange anomalies with 1.18.5.3? > > I got a clean and happy build of this version on OpenSolaris but when I > ran the same build on Solaris 10, I get: > > WARNING: createContext: window creation failure. SDL: X11 driver not > configured with OpenGL > > I'm baffled at what is causing this. 1.18.4.x runs fine on Solaris 10 > and none of the libraries, SConstruct, or my Solaris-related patches > changed between releases. I'm therefore totally baffled. From tess at lindenlab.com Fri Dec 7 17:32:27 2007 From: tess at lindenlab.com (Tess Chu) Date: Fri Dec 7 17:32:49 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <47597F3F.2010404@cox.net> References: <4755E705.6090703@lindenlab.com> <20071207053302.GF28695@arnholm.se> <4758E870.4080701@cox.net> <20071207134751.GG28695@arnholm.se> <47597F3F.2010404@cox.net> Message-ID: <4759F42B.40507@lindenlab.com> Here's some additional information: Currently, the login form lives here: https://secondlife.com/app/login/index.php?show_login_form=True This URL can be set on the client in an xml file: skins/xui/en-us/panel_login.xml I just created this Jira task to add a client option to set this URL: http://jira.secondlife.com/browse/VWR-3741 "-loginpage option to client" This feature will be useful for folks using OpenSim who would have a separate authentication page. Clients of OpenSim would just need to set -loginpage and -loginuri to connect. [ Show ? ] Tess Chu - 2007/Dec/07 03:36 PM Here it is: skins/xui/en-us/panel_login.xml Also, I've been asked to clarify: *We will not change this form without notice to sldev. *Thanks, Tess Lawson English wrote: > Anders Arnholm wrote: >> On Thu, Dec 06, 2007 at 11:30:08PM -0700, Lawson English wrote: >> >>> Anders Arnholm wrote: >>> 1) viewer(browser) => webpage => url+UUID (cap) => viewer >>> or >>> 2) 3rd part browser => webpage => url + UUID (cap) => viewer >>> >> >> One think i don't know and to be honest can't find any info about is >> what is needed to get the webpage working, HTML4, XHTML, CSS, >> JavaScript. However my main fucus is understanding HOW TEH F**K to get >> the (NOW AGAIN OUTDATED) WindLight source to compile.... >> >> > > > Well, the source code I pointed to was in Python. > https://wiki.secondlife.com/wiki/Example_protocol_code > > to summarize > > https POST: to "secure-web14.secondlife.com". > > path: "/inworld/go.php" > headers: "Content-type"= > "application/x-www-form-urlencoded"="Accept="text/plain" > body: 'username' ='Firstname', 'lastname' = 'Lastname', 'password' > = 'password secret psst!', > 'continuation' = '','grid' ='agni', 'location' = 'home', > > > The response will be a dictionary that includes the web_login_key, > firstname, lastname,location... > > So use those values (which you used to get via the dialog box in the > viewer) in the xmlprc call you normally do for login but substitute > the web_login_key key/value pair for the password/"1$1" + > md5_encrypted_password key/value pair. > > The response to the xmlrpc call will be the same as before. > > https://wiki.secondlife.com/wiki/Current_login_protocols > From Anders at Arnholm.se Sat Dec 8 01:31:52 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Sat Dec 8 01:32:09 2007 Subject: [sldev] More about viewer auth in today's RC In-Reply-To: <47598D91.1020801@wsu.edu> References: <4755E705.6090703@lindenlab.com> <20071207053302.GF28695@arnholm.se> <4758E870.4080701@cox.net> <20071207134751.GG28695@arnholm.se> <47598D91.1020801@wsu.edu> Message-ID: <20071208093152.GH28695@arnholm.se> On Fri, Dec 07, 2007 at 10:14:41AM -0800, John Hurliman wrote: > Anders Arnholm wrote: > change, but there also might be an additional LLSD interface to the system > at that point so it is just speculation right now. That authentications now is a "speculation" issue, is part of the problem. Authenitcations whet ever LL calls it is a security problem, now it's not open to verify it it good or bad, traditionally all system that are not open are in the bad area. I have so far not seen a single closed authenications systems that is good. Security by obscurity never works. / Balp -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071208/3d04437f/attachment.pgp From Anders at Arnholm.se Sat Dec 8 01:57:00 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Sat Dec 8 01:57:12 2007 Subject: [Fwd: [sldev] [vwr] SDL strangeness with 1.18.5.3 and where the hell is glh] In-Reply-To: References: <47595B31.5070608@sun.com> Message-ID: <20071208095700.GI28695@arnholm.se> On Fri, Dec 07, 2007 at 02:48:24PM +0000, Robin Cornelius wrote: > On Dec 7, 2007 2:39 PM, Dana Fagerstrom wrote: > Look on http://jira.secondlife.com/browse/VWR-3415 there is a link on > there to one version > I found a link to a download page on nvidias site .... try > http://developer.nvidia.com/attach/8196 also known as "nvparse" and > thats nvparse.zip on that link. I get core dumping from compiling what that, digging deeper.... / Balp -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071208/6d9efad5/attachment-0001.pgp From nicholaz at blueflash.cc Sat Dec 8 05:48:15 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Dec 8 05:48:21 2007 Subject: [sldev] [VWR] Debug Libcurl in 1.18.6.0 Message-ID: <475AA09F.7000007@blueflash.cc> I just got linker errors from the debug Libcurl in 1.18.6.0 (it seems to link to either the wrong compiler or with the wrong libraries (not using /MTd would be my guess)) Not a really problem for me as I have my own debug version here, just thought someone would like to know Nick From annagulaev at gmail.com Sat Dec 8 08:00:24 2007 From: annagulaev at gmail.com (Anna Gulaev) Date: Sat Dec 8 08:00:25 2007 Subject: [sldev] force a CoarseLocationUpdate? Message-ID: Is there a way to force a CoarseLocationUpdate for a distant sim? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071208/03de68b3/attachment.htm From seg at haxxed.com Sat Dec 8 21:48:18 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Dec 8 21:48:33 2007 Subject: [sldev] [VWR] gstreamer video errors In-Reply-To: <4759BBD9.7030707@gmail.com> References: <4759BBD9.7030707@gmail.com> Message-ID: <1197179298.29345.9.camel@localhost> On Fri, 2007-12-07 at 21:32 +0000, Robin Cornelius wrote: > Hi everyone, anybody got any clue about gstreamer on linux. I'm getting > the following warning/error int the log:- > > (gecko:28079): GLib-GObject-WARNING **: specified class size for type > `GstSLVideo' is smaller than the parent type's `GstVideoSink' class size > > (gecko:28079): GStreamer-CRITICAL **: gst_element_register: assertion > `g_type_is_a (type, GST_TYPE_ELEMENT)' failed > > (gecko:28079): GLib-GObject-WARNING **: specified class size for type > `GstSLVideo' is smaller than the parent type's `GstVideoSink' class size > 2007-12-07T21:21:40Z WARNING: init: Could not instantiate > private-slvideo element. > > 2007-12-07T21:21:40Z INFO: convertImageAndLoadUrl: MEDIA> unable to load > http://www.americafree.tv/unicast_mov/AmericaFreeTVClassics.mov > > Just wonder if this rings any bells with anyone? I'm on 1.18.6.0 Debian > AMD64 build. Looks like what I was getting after my attempt to fix gstreamer. Unpatched I actually get an error from glib, something about threads not being initialized and then it crashes. I tried putting in thread initialization, which resulted in errors like this, and then more thread initialization errors... Something's horribly wrong with gstreamer in standalone builds and hell if I know how to fix it. Really need to file a bug... It seems LL built Windlight viewer running on the same system works with gstreamer just fine. -------------- 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/20071208/57f2ae8e/attachment.pgp From robla at lindenlab.com Sat Dec 8 21:59:12 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sat Dec 8 21:59:23 2007 Subject: Windlight FL4 (75173) source available (Re: [sldev] Windlight 74642 sources?) In-Reply-To: References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> <475739D2.6020407@lindenlab.com> <4757E934.60103@lindenlab.com> Message-ID: <475B8430.2010209@lindenlab.com> On 12/7/07 3:08 AM, Candide LeMay wrote: > There's a new windlight release, again with no source drop. Guys ... > if you insist on mandatory windlight client updates, publish the > source code too! I've just managed to compile 74965 yesterday and it's > useless already. > Sorry for the inconvenience. As others on this thread pointed out, you can avoid this problem altogether by changing the channel in your build (changing LL_CHANNEL to something else in indra/llcommon/llversionviewer.h). Full guidelines are here: https://wiki.secondlife.com/wiki/Channel_and_Version_Requirements However, if you are interested in updating your source, a new version is available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_FL-1.18.5.75173 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/20071208/966d2036/signature.pgp From robin.cornelius at gmail.com Sun Dec 9 02:16:40 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun Dec 9 02:12:05 2007 Subject: [sldev] [VWR] gstreamer video errors In-Reply-To: <1197179298.29345.9.camel@localhost> References: <4759BBD9.7030707@gmail.com> <1197179298.29345.9.camel@localhost> Message-ID: <475BC088.8090305@gmail.com> Callum Lerwick wrote: > On Fri, 2007-12-07 at 21:32 +0000, Robin Cornelius wrote: >> Hi everyone, anybody got any clue about gstreamer on linux. I'm getting >> the following warning/error int the log:- >> >> (gecko:28079): GLib-GObject-WARNING **: specified class size for type >> `GstSLVideo' is smaller than the parent type's `GstVideoSink' class size > > Something's horribly wrong with gstreamer in standalone builds and hell > if I know how to fix it. Really need to file a bug... http://jira.secondlife.com/browse/VWR-3737 Regards Robin -------------- 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/20071209/2c03fcbe/signature.pgp From tofu.linden at lindenlab.com Sun Dec 9 04:47:48 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Sun Dec 9 04:47:57 2007 Subject: [sldev] [VWR] Debug Libcurl in 1.18.6.0 In-Reply-To: <475AA09F.7000007@blueflash.cc> References: <475AA09F.7000007@blueflash.cc> Message-ID: <475BE3F4.5070508@lindenlab.com> Thanks for the report - I believe that this was fixed internally and may be in a future 1.18.6 RC. Nicholaz Beresford wrote: > > I just got linker errors from the debug Libcurl in 1.18.6.0 > (it seems to link to either the wrong compiler or with the > wrong libraries (not using /MTd would be my guess)) > > Not a really problem for me as I have my own debug version > here, just thought someone would like to know From seg at haxxed.com Sun Dec 9 11:20:52 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Dec 9 11:21:05 2007 Subject: [sldev] [VWR] gstreamer video errors In-Reply-To: <1197179298.29345.9.camel@localhost> References: <4759BBD9.7030707@gmail.com> <1197179298.29345.9.camel@localhost> Message-ID: <1197228052.614.2.camel@localhost> On Sat, 2007-12-08 at 23:48 -0600, Callum Lerwick wrote: > Looks like what I was getting after my attempt to fix gstreamer. > Unpatched I actually get an error from glib, something about threads not > being initialized and then it crashes. I tried putting in thread > initialization, which resulted in errors like this, and then more thread > initialization errors... Hmmm never mind. I'm not seeing the threading crash with 1.18.5.3, and I'm getting the exact same error now. On i386 even. -------------- 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/20071209/3645ba99/attachment.pgp From seg at haxxed.com Sun Dec 9 13:10:46 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Dec 9 13:11:02 2007 Subject: [sldev] [VWR] The OpenJPEG lossless decode bug In-Reply-To: References: <1196891406.21792.129.camel@localhost> Message-ID: <1197234647.614.8.camel@localhost> On Fri, 2007-12-07 at 10:02 +0000, Robin Cornelius wrote: > Forgive me for being very stupid, but what effect does this now have > on the previous patch of :- > I can't remember what the purpose of this was, is it still needed now? > Or can you just leave it applied but use the "OpenJPEGEncodeLossless" > to turn on/off lossless and have success? Its something different. That patch makes OpenJPEG encode/upload lossy by default like KDU does. There's actually a new version of the patch on VWR-1475 that makes use of the new UI for lossless, which has been merged in to "fixed internally" limbo. -------------- 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/20071209/adb19c65/attachment.pgp From dmahalko at gmail.com Sun Dec 9 13:38:39 2007 From: dmahalko at gmail.com (Dale Mahalko) Date: Sun Dec 9 13:38:40 2007 Subject: [sldev] How to move objects from Havok4 Beta to main grid? Message-ID: Is there some way that I can back up machinery I build in the beta grid, so it isn't lost when the grid is wiped/rebuilt? I tend to build really complex machines with moving wheels, marbles, balances, pendulums, levels, gears, etc. While I would like to build test objects on the havok4 beta, after having my initial projects wiped from the first days of the test starting, the wipe really took the fun out of testing. At this point if I can't keep the projects I build then it really isn't worth bothering with stress-testing the engine, because a lot of work may be necessary to "set up" a test mechanism. To see it all wiped with no chance of saving.... Eh I will pass. There's much more to this than scripts, so copying out the scripts may be less than half the work involved in getting something working. Building a mock-up on the main grid and waiting a few weeks for the database to copy over to the beta will not work because the bounding boxes are different for havok 4 and something from the main grid may need extensive tweaking and adjusting to work under havok 4. I think I'm probably now going to sit on my hands until the havok 4 beta moves to sandboxes on the main grid. - Scalar Tardis / Dale Mahalko From lenglish5 at cox.net Sun Dec 9 15:07:25 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Dec 9 15:07:28 2007 Subject: [sldev] How to move objects from Havok4 Beta to main grid? In-Reply-To: References: Message-ID: <475C752D.7050908@cox.net> Dale Mahalko wrote: > Is there some way that I can back up machinery I build in the beta > grid, so it isn't lost when the grid is wiped/rebuilt? > Aren't there scripts taht can grab all the parameters of an object or objects and temp them to notecards and similar scripts that can take a notecard and reconstruct the original from that? Lawson From carjay at gmx.net Sun Dec 9 16:15:10 2007 From: carjay at gmx.net (Carsten Juttner) Date: Sun Dec 9 16:15:14 2007 Subject: [sldev] [PATCH] FMOD Ex support for the sl viewer Message-ID: <475C850E.1070501@gmx.net> Hi, since I wanted sl viewer sound to work for my Linux x86_64 system and did not know about the existing OpenAL patch I started porting the FMOD 3 library calls to FMOD (Ex) 4. The result works so far (including wind and internet streams) but needs some more fine tuning, especially seeing if the setup is working on all systems and I still saw some error messages due to using already freed/reused handles. I also have no idea if it works on any other system than Linux x86-64. Anyway, I've been using it for many days now on my system, got no segfaults (in the related code) and sound keeps working fine. The patch and a short description is at http://sl.mebsuta.de I'm not aiming at having this integrated into the official sources since I believe an open source solution would be more satisfying in the long run but hopefully until this is done it might make the experience more joyful to the group of 64 bit users (like me). Regards, Carsten From jhurliman at wsu.edu Sun Dec 9 17:25:16 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Dec 9 17:25:20 2007 Subject: [sldev] How to move objects from Havok4 Beta to main grid? In-Reply-To: References: Message-ID: <475C957C.7070507@wsu.edu> Dale Mahalko wrote: > Is there some way that I can back up machinery I build in the beta > grid, so it isn't lost when the grid is wiped/rebuilt? > > I tend to build really complex machines with moving wheels, marbles, > balances, pendulums, levels, gears, etc. While I would like to build > test objects on the havok4 beta, after having my initial projects > wiped from the first days of the test starting, the wipe really took > the fun out of testing. > > At this point if I can't keep the projects I build then it really > isn't worth bothering with stress-testing the engine, because a lot of > work may be necessary to "set up" a test mechanism. To see it all > wiped with no chance of saving.... Eh I will pass. There's much more > to this than scripts, so copying out the scripts may be less than half > the work involved in getting something working. > > Building a mock-up on the main grid and waiting a few weeks for the > database to copy over to the beta will not work because the bounding > boxes are different for havok 4 and something from the main grid may > need extensive tweaking and adjusting to work under havok 4. > > > I think I'm probably now going to sit on my hands until the havok 4 > beta moves to sandboxes on the main grid. > > - Scalar Tardis / Dale Mahalko If you are familiar with the libsecondlife TestClient program, export and import commands should do what you need. John From annagulaev at gmail.com Sun Dec 9 19:34:17 2007 From: annagulaev at gmail.com (Anna Gulaev) Date: Sun Dec 9 19:34:18 2007 Subject: [sldev] reducing network traffic Message-ID: Sitting with sound muted on a parcel that has no stream, 2000m above any objects, I'm still receiving about 10 kbps worth of AttachedSound messages. Any idea why? Is there a way to tell the sim I'm not interested? How about LayerData? Getting a lot of those, too. CoarseLocationUpdate? Don't need those without the minimap open, right? Any way to reduce the number of these that I receive? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071209/16b2bd9a/attachment.htm From kelly at lindenlab.com Sun Dec 9 19:45:02 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Sun Dec 9 19:45:10 2007 Subject: [sldev] How to move objects from Havok4 Beta to main grid? In-Reply-To: References: Message-ID: <475CB63E.3020400@lindenlab.com> Dale Mahalko wrote: > Is there some way that I can back up machinery I build in the beta > grid, so it isn't lost when the grid is wiped/rebuilt? > > I tend to build really complex machines with moving wheels, marbles, > balances, pendulums, levels, gears, etc. While I would like to build > test objects on the havok4 beta, after having my initial projects > wiped from the first days of the test starting, the wipe really took > the fun out of testing. > > At this point if I can't keep the projects I build then it really > isn't worth bothering with stress-testing the engine, because a lot of > work may be necessary to "set up" a test mechanism. To see it all > wiped with no chance of saving.... Eh I will pass. There's much more > to this than scripts, so copying out the scripts may be less than half > the work involved in getting something working. > > Building a mock-up on the main grid and waiting a few weeks for the > database to copy over to the beta will not work because the bounding > boxes are different for havok 4 and something from the main grid may > need extensive tweaking and adjusting to work under havok 4. > > > I think I'm probably now going to sit on my hands until the havok 4 > beta moves to sandboxes on the main grid. > > - Scalar Tardis / Dale Mahalko > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > Aside from the methods suggested by others there is no official way to move content from the Havok4 beta to the main Second Life. However, I think we should have some Havok4 beta sandboxes up really soon now. There was talk about getting them up as early as last week - since that didn't happen I won't speculate any further on when it will. :) As Sidewinder said in his post to the blog we are already running some Linden regions on Havok4 simulators. - Kelly From jhurliman at wsu.edu Sun Dec 9 21:34:16 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Dec 9 21:34:04 2007 Subject: [sldev] reducing network traffic In-Reply-To: References: Message-ID: <475CCFD8.3030506@wsu.edu> Anna Gulaev wrote: > Sitting with sound muted on a parcel that has no stream, 2000m above > any objects, I'm still receiving about 10 kbps worth of AttachedSound > messages. Any idea why? Is there a way to tell the sim I'm not interested? > > How about LayerData? Getting a lot of those, too. > > CoarseLocationUpdate? Don't need those without the minimap open, right? > > Any way to reduce the number of these that I receive? You can almost entirely suppress LayerData packets by sending another AgentThrottle packet with Land (or is it Terrain?) set to 0, if you want to see the world without any ground. On the rest of that, the answer is no unless you set Task to 0 which will pretty much choke off all nearby updates (like prims moving around). Even that probably won't stop the CoarseLocationUpdates though. John From alissa_sabre at yahoo.co.jp Mon Dec 10 05:50:07 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Mon Dec 10 05:50:17 2007 Subject: [sldev] Source release for 1.18.6.0 In-Reply-To: <4758A4BB.6020807@lindenlab.com> References: <4758A4BB.6020807@lindenlab.com> Message-ID: <74dssdz9s2rfY4ds4ds8ds4b.alissa_sabre@yahoo.co.jp> > Good news: Soft is diligently working on getting the build issues > sorted out in the exported code, so that we know this compiles out of > the box for at least one developer. Great! At last we can see a (sort of) QA on source distribution. Soft, you are the true succor for open source developers. Alissa -------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/ From markkicks at gmail.com Mon Dec 10 08:03:33 2007 From: markkicks at gmail.com (mark) Date: Mon Dec 10 08:03:37 2007 Subject: [sldev] eventlet segfaults in opensolaris Message-ID: <82fa9e310712100803j8a33605i8d76f0a2499cdd6f@mail.gmail.com> Hi, I am not able to get eventlet working in opensolaris. This is from python -v. How to fix this? I have a core dump, do you need it thanks mark python version 2.4.4 pool.execute(a, 1) import eventlet.kqueuehub # from eventlet/kqueuehub.py # wrote eventlet/kqueuehub.pyc dlopen("/opt/local/lib/python2.4/lib-dynload/select.so", 2); import select # dynamically loaded from /opt/local/lib/python2.4/lib-dynload/select.so import eventlet.pollhub # from eventlet/pollhub.py # wrote eventlet/pollhub.pyc import eventlet.runloop # from eventlet/runloop.py # wrote eventlet/runloop.pyc # /opt/local/lib/python2.4/bisect.pyc matches /opt/local/lib/python2.4/bisect.py import bisect # precompiled from /opt/local/lib/python2.4/bisect.pyc dlopen("/opt/local/lib/python2.4/lib-dynload/_bisect.so", 2); import _bisect # dynamically loaded from /opt/local/lib/python2.4/lib-dynload/_bisect.so import eventlet.timer # from eventlet/timer.py # wrote eventlet/timer.pyc Segmentation Fault (core dumped) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/5c9aad24/attachment-0001.htm From bos at lindenlab.com Mon Dec 10 08:54:38 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Dec 10 08:55:08 2007 Subject: [sldev] eventlet segfaults in opensolaris In-Reply-To: <82fa9e310712100803j8a33605i8d76f0a2499cdd6f@mail.gmail.com> References: <82fa9e310712100803j8a33605i8d76f0a2499cdd6f@mail.gmail.com> Message-ID: <475D6F4E.4060001@lindenlab.com> mark wrote: > I am not able to get eventlet working in opensolaris. This is from > python -v. > How to fix this? We're not Solaris users, so you'll have to do some investigating of the crash details yourself, I'm afraid. References: <82fa9e310712100803j8a33605i8d76f0a2499cdd6f@mail.gmail.com> <475D6F4E.4060001@lindenlab.com> Message-ID: <82fa9e310712100921j13e70910n21e6c860bb002029@mail.gmail.com> On Dec 10, 2007 8:54 AM, Bryan O'Sullivan wrote: > > I am not able to get eventlet working in opensolaris. This is from > > python -v. > > How to fix this? > We're not Solaris users, so you'll have to do some investigating of the > crash details yourself, I'm afraid. thanks for your reply, can you tell how i can look for or more details? is there a debug flag i can turn on or something like that? am not even able to find out where it is segfaulting thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/deb7d3c7/attachment.htm From monkowsk at watson.ibm.com Mon Dec 10 09:04:13 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Dec 10 09:30:20 2007 Subject: [sldev] JIRA Submit In-Reply-To: <4751B66B.70807@dzonux.net> References: <473CDAC2.6070307@dzonux.net> <473CDAF3.1020401@dzonux.net> <4751B66B.70807@dzonux.net> Message-ID: <475D718D.9050001@watson.ibm.com> I'm trying to create a new JIRA issue, but the Submit button doesn't seem to do anything. I also noticed there are no other JIRA issues created today. I was able to update another issue successfully, though. Is this a JIRA problem or am I doing something wrong? Mike SL:Mm Alder From xotmid at gmail.com Mon Dec 10 10:34:32 2007 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Dec 10 10:34:35 2007 Subject: [sldev] Can not find gl.h Message-ID: Hey all i am trying to compile and it cant find gl.h -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/99fe7016/attachment.htm From bos at lindenlab.com Mon Dec 10 10:38:46 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Dec 10 10:40:43 2007 Subject: [sldev] eventlet segfaults in opensolaris In-Reply-To: <82fa9e310712100921j13e70910n21e6c860bb002029@mail.gmail.com> References: <82fa9e310712100803j8a33605i8d76f0a2499cdd6f@mail.gmail.com> <475D6F4E.4060001@lindenlab.com> <82fa9e310712100921j13e70910n21e6c860bb002029@mail.gmail.com> Message-ID: <475D87B6.2090708@lindenlab.com> mark wrote: > can you tell how i can look for or more details? Try running the program under a debugger such as gdb. You should be able to get a backtrace out of wherever it's crashing. References: <473CDAC2.6070307@dzonux.net> <473CDAF3.1020401@dzonux.net> <4751B66B.70807@dzonux.net> <475D718D.9050001@watson.ibm.com> Message-ID: <475D8C56.4050509@watson.ibm.com> I was finally able to submit the issue: (VWR-3777) memory leak: LLVoiceVisualizer instances are immortal. I don't know why it didn't work before. This time I added the patch as an edit, but I don't know if that really made a difference or was just coincidental. Mike Mike Monkowski wrote: > I'm trying to create a new JIRA issue, but the Submit button doesn't > seem to do anything. I also noticed there are no other JIRA issues > created today. I was able to update another issue successfully, though. > Is this a JIRA problem or am I doing something wrong? > > Mike > SL:Mm Alder > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From markkicks at gmail.com Mon Dec 10 11:31:40 2007 From: markkicks at gmail.com (mark) Date: Mon Dec 10 11:31:42 2007 Subject: [sldev] eventlet stops running Message-ID: <82fa9e310712101131y4ce4c0d8x736b95e41e205f0@mail.gmail.com> am using eventlet and running a process.. and suddenly it stops running [which i can tell from logs and others] and when i go to the terminal in which started this process is running and i hit CTRL C, it starts running again.... do you know what is wrong? thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/8647bf81/attachment.htm From donovan at lindenlab.com Mon Dec 10 11:09:53 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Mon Dec 10 11:57:20 2007 Subject: [sldev] eventlet segfaults in opensolaris In-Reply-To: <82fa9e310712100803j8a33605i8d76f0a2499cdd6f@mail.gmail.com> References: <82fa9e310712100803j8a33605i8d76f0a2499cdd6f@mail.gmail.com> Message-ID: <48BD80B4-3ED9-403E-A1FF-B522F855EAC6@lindenlab.com> On Dec 10, 2007, at 8:03 AM, mark wrote: > Hi, > I am not able to get eventlet working in opensolaris. This is from > python -v. > How to fix this? I have a core dump, do you need it > thanks > mark You first might want to make sure that the greenlet module isn't what's causing the segfault. Please take a look at: http://codespeak.net/py/dist/greenlet.html See if you can get some of the simple examples working. Understanding the examples is great for understanding coroutines, too. If you installed greenlet from the cheese shop, the package is named greenlet, not py.magic greenlet. eg import greenlet instead of from py.magic import greenlet Good luck, and thanks! Donovan From dimentox at dimentox.com Mon Dec 10 12:13:21 2007 From: dimentox at dimentox.com (Dimentox) Date: Mon Dec 10 12:13:25 2007 Subject: [sldev] compile errors Message-ID: can i get some help here? Error 2 error C2784: 'bool std::operator ==(const std::deque<_Ty,_Alloc> &,const std::deque<_Ty,_Alloc> &)' : could not deduce template argument for 'const std::deque<_Ty,_Alloc> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 3 error C2784: 'bool std::operator ==(const std::basic_string<_Elem,_Traits,_Alloc> &,const _Elem *)' : could not deduce template argument for 'const std::basic_string<_Elem,_Traits,_Alloc> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 4 error C2784: 'bool std::operator ==(const _Elem *,const std::basic_string<_Elem,_Traits,_Alloc> &)' : could not deduce template argument for 'const _Elem *' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 5 error C2784: 'bool std::operator ==(const std::basic_string<_Elem,_Traits,_Alloc> &,const std::basic_string<_Elem,_Traits,_Alloc> &)' : could not deduce template argument for 'const std::basic_string<_Elem,_Traits,_Alloc> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 6 error C2784: 'bool std::operator ==(const std::vector<_Ty,_Alloc> &,const std::vector<_Ty,_Alloc> &)' : could not deduce template argument for 'const std::vector<_Ty,_Alloc> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 7 error C2784: 'bool std::operator ==(const std::_Tree<_Traits> &,const std::_Tree<_Traits> &)' : could not deduce template argument for 'const std::_Tree<_Traits> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 8 error C2784: 'bool std::operator ==(const std::list<_Ty,_Ax> &,const std::list<_Ty,_Ax> &)' : could not deduce template argument for 'const std::list<_Ty,_Ax> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 9 error C2784: 'bool std::operator ==(const std::istream_iterator<_Ty,_Elem,_Traits,_Diff> &,const std::istream_iterator<_Ty,_Elem,_Traits,_Diff> &)' : could not deduce template argument for 'const std::istream_iterator<_Ty,_Elem,_Traits,_Diff> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 10 error C2784: 'bool std::operator ==(const std::istreambuf_iterator<_Elem,_Traits> &,const std::istreambuf_iterator<_Elem,_Traits> &)' : could not deduce template argument for 'const std::istreambuf_iterator<_Elem,_Traits> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 11 error C2784: 'bool std::operator ==(const std::allocator<_Ty> &,const std::allocator<_Other> &) throw()' : could not deduce template argument for 'const std::allocator<_Ty> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 12 error C2784: 'bool std::operator ==(const std::reverse_iterator<_RanIt> &,const std::reverse_iterator<_RanIt2> &)' : could not deduce template argument for 'const std::reverse_iterator<_RanIt> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 13 error C2784: 'bool std::operator ==(const std::_Revranit<_RanIt,_Base> &,const std::_Revranit<_RanIt2,_Base2> &)' : could not deduce template argument for 'const std::_Revranit<_RanIt,_Base> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage Error 14 error C2784: 'bool std::operator ==(const std::pair<_Ty1,_Ty2> &,const std::pair<_Ty1,_Ty2> &)' : could not deduce template argument for 'const std::pair<_Ty1,_Ty2> &' from 'LLMessageThrottleEntry' C:\Program Files\Microsoft Visual Studio 9.0\VC\include\algorithm 406 llmessage -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/6fbac60d/attachment.htm From sly_squash at hotmail.com Mon Dec 10 12:16:22 2007 From: sly_squash at hotmail.com (Joshy Squashy) Date: Mon Dec 10 12:16:23 2007 Subject: [sldev] [VWR] Reflections/Mirrors? In-Reply-To: <20071210160338.32AF141B2A8@stupor.lindenlab.com> References: <20071210160338.32AF141B2A8@stupor.lindenlab.com> Message-ID: At a recent meeting, a colleague demonstrated his work integrating reflections into a certain game engine, and claimed that this is something that could not be done with Second Life. I wasn't so sure, as graphics are rendered on the client and the client is open-source, what's stopping someone from integrating such code into it? In any event, it seems that reflections have been a consideration of the lindens since at least January of 2007, since they were accessible in a "First Look" client from that time according to these videos: http://secondslog.blogspot.com/2007/01/first-look-into-mirror.html I do not see this option in the existing viewer, and when I hunt for mirrors that actually reflect on slboutique or go looking for them in world, they are strangely absent. Must I still go into debug mode and fiddle with those setting to make reflections possible? Has this "First Look" code made it into main viewer yet? ~Squash Otoro _________________________________________________________________ Your smile counts. The more smiles you share, the more we donate.? Join in. www.windowslive.com/smile?ocid=TXT_TAGLM_Wave2_oprsmilewlhmtagline -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/41b06307/attachment.htm From sly_squash at hotmail.com Mon Dec 10 12:41:14 2007 From: sly_squash at hotmail.com (Joshy Squashy) Date: Mon Dec 10 12:41:15 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: <20071210200011.062DD41B2A9@stupor.lindenlab.com> References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> Message-ID: OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source alpha Second Life server framework. It is extremely crippled, with limited scripting options and a large number of missing features; however, it is functional. The laboratory at my college has been doing research using synthetic worlds in education software projects and software engineering projects for some time. We have been following development of OpenSL for some time, as we are very excited with the possibilities of having access to the source code for both the client and server (particularly in situations when the SL server should also be some other type of server). Though OpenSL isn't much at the moment, we are approaching the point where we plan to try OpenSL servers for some very simple projects. However, some colleagues disagree that we should consider OpenSL, claiming they are reverse-engineering Second Life's message protocols and that having the potential for hosting "free" Second Life servers is a threat to Linden Labs so Linden Labs will either shut down OpenSL or release client versions that render OpenSL unusable. While I don't know Linden Labs opinion on the subject, I would think that such claims don't amount to much. Releasing a client version that renders OpenSL unusable can't really happen because the client is open source so it's a trivial matter to remove the code that prevents interoperability. However, shutting down OpenSL I see as conceivable but unlikely; the OpenSL server is so crippled that one would need very specific reasons as to why it would be desirable to use it, and Linden Labs hasn't taken action yet. I simply don't see Linden Labs as considering this to be a threat, particularly considering their substantial existing userbase and that my understanding is that they've been toying with the idea of releasing the server code outright themselves for some time already. Still, my colleagues and I would be very interested in hearing Linden Labs direction in dealing with those involved in developing 3rd party Second Life server frameworks. ~Squash Otoro _________________________________________________________________ Put your friends on the big screen with Windows Vista? + Windows Live?. http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_102007 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/896fcf62/attachment.htm From lenglish5 at cox.net Mon Dec 10 13:11:16 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Dec 10 13:11:19 2007 Subject: [sldev] [VWR] Reflections/Mirrors? In-Reply-To: References: <20071210160338.32AF141B2A8@stupor.lindenlab.com> Message-ID: <475DAB74.6050801@cox.net> Joshy Squashy wrote: > At a recent meeting, a colleague demonstrated his work integrating > reflections into a certain game engine, and claimed that this is > something that could not be done with Second Life. I wasn't so sure, > as graphics are rendered on the client and the client is open-source, > what's stopping someone from integrating such code into it? > > In any event, it seems that reflections have been a consideration of > the lindens since at least January of 2007, since they were accessible > in a "First Look" client from that time according to these videos: > http://secondslog.blogspot.com/2007/01/first-look-into-mirror.html > > I do not see this option in the existing viewer, and when I hunt for > mirrors that actually reflect on slboutique or go looking for them in > world, they are strangely absent. Must I still go into debug mode and > fiddle with those setting to make reflections possible? Has this > "First Look" code made it into main viewer yet? > > ~Squash Otoro Seems to me that the same code that gives reflections for water could be used for reflections for mirrors. I seem to recall that there are issues with mirrors facing each other though, so perhaps that potential griefing tool is why there's no mirrors in SL... Lawson From lenglish5 at cox.net Mon Dec 10 13:20:40 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Dec 10 13:20:43 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> Message-ID: <475DADA8.7050906@cox.net> Joshy Squashy wrote: > OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source > alpha Second Life server framework. It is extremely crippled, with > limited scripting options and a large number of missing features; > however, it is functional. > > The laboratory at my college has been doing research using synthetic > worlds in education software projects and software engineering > projects for some time. We have been following development of OpenSL > for some time, as we are very excited with the possibilities of having > access to the source code for both the client and server (particularly > in situations when the SL server should also be some other type of > server). > > Though OpenSL isn't much at the moment, we are approaching the point > where we plan to try OpenSL servers for some very simple projects. > However, some colleagues disagree that we should consider OpenSL, > claiming they are reverse-engineering Second Life's message protocols > and that having the potential for hosting "free" Second Life servers > is a threat to Linden Labs so Linden Labs will either shut down OpenSL > or release client versions that render OpenSL unusable. > > While I don't know Linden Labs opinion on the subject, I would think > that such claims don't amount to much. Releasing a client version > that renders OpenSL unusable can't really happen because the client is > open source so it's a trivial matter to remove the code that prevents > interoperability. However, shutting down OpenSL I see as conceivable > but unlikely; the OpenSL server is so crippled that one would need > very specific reasons as to why it would be desirable to use it, and > Linden Labs hasn't taken action yet. I simply don't see Linden Labs > as considering this to be a threat, particularly considering their > substantial existing userbase and that my understanding is that > they've been toying with the idea of releasing the server code > outright themselves for some time already. > > Still, my colleagues and I would be very interested in hearing Linden > Labs direction in dealing with those involved in developing 3rd party > Second Life server frameworks. > > ~Squash Otoro > > ------------------------------------------------------------------------ Not speaking for Linden Labs since I can't, but LL is working with OpenSim as part of the architectural working group https://wiki.secondlife.com/wiki/Architecture_Working_Group so I would say they are serious about their goal of open sourcing the servers andthat they don't see Open Sim, Open SL, etc., as a threat. Also, a shameless plug, you and your colleagues are cordially invited to attend the AW Groupies meetings ( Tuesdays, 9:30 AM SL time). IM Saijanai Kuhn, Tree Kyomoon or Zha Ewry for an invite since the meeting is held on a private IBM island. https://wiki.secondlife.com/wiki/AW_Groupies AW Groupies is an in-world group comprised of people wanting to help LL with the goals of the AWG. We also look past their 2-year plan to the design of the next generation of grids based on Second Life, with a long-term goal of interoperability with other possible virtual world architectures. Lawson English (Saijanai Kuhn) From monkowsk at watson.ibm.com Mon Dec 10 13:33:48 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Dec 10 13:33:59 2007 Subject: [sldev] compile errors In-Reply-To: References: Message-ID: <475DB0BC.1080908@watson.ibm.com> Dimentox wrote: > can i get some help here? Probably not. :-) Compiling the viewer with VS2005 is still a bit of a challenge. With VS2008 beta, you're really blazing a trail in unknown territory. Mike From dimentox at dimentox.com Mon Dec 10 13:55:59 2007 From: dimentox at dimentox.com (Dimentox) Date: Mon Dec 10 13:56:02 2007 Subject: [sldev] compile errors In-Reply-To: <475DB0BC.1080908@watson.ibm.com> References: <475DB0BC.1080908@watson.ibm.com> Message-ID: Actually its a bug in the vs stuff... and i am compileing on VS2008 release.. But what i did is i took the alg file from vc2005 but it dies on error from cmd On Dec 10, 2007 3:33 PM, Mike Monkowski wrote: > Dimentox wrote: > > can i get some help here? > > Probably not. :-) Compiling the viewer with VS2005 is still a bit of a > challenge. With VS2008 beta, you're really blazing a trail in unknown > territory. > > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/e6d15716/attachment.htm From rdw at lindenlab.com Mon Dec 10 13:56:14 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Mon Dec 10 13:59:08 2007 Subject: [sldev] eventlet stops running In-Reply-To: <82fa9e310712101131y4ce4c0d8x736b95e41e205f0@mail.gmail.com> References: <82fa9e310712101131y4ce4c0d8x736b95e41e205f0@mail.gmail.com> Message-ID: <475DB5FE.1080302@lindenlab.com> mark wrote: > am using eventlet and running a process.. and suddenly it stops running > [which i can tell from logs and others] > and when i go to the terminal in which started this process is running and i > hit CTRL C, it starts running again.... > do you know what is wrong? > thanks That's pretty weird. Try using strace to see what it's doing at the time of freeze: strace -p -RYaN From jhurliman at wsu.edu Mon Dec 10 14:01:41 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Dec 10 14:01:35 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> Message-ID: <475DB745.5030108@wsu.edu> Joshy Squashy wrote: > OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source > alpha Second Life server framework. It is extremely crippled, with > limited scripting options and a large number of missing features; > however, it is functional. I'm not sure where you read the acronym OpenSL but that is usually used to refer to the GPL licensed official viewer, the main topic of discussion on this list. opensimulator.org is generally called OpenSim and their IRC channel is #opensim on EFNet. Just clarifying any naming confusion. John From markkicks at gmail.com Mon Dec 10 14:45:44 2007 From: markkicks at gmail.com (mark) Date: Mon Dec 10 14:45:47 2007 Subject: [sldev] eventlet stops running In-Reply-To: <475DB5FE.1080302@lindenlab.com> References: <82fa9e310712101131y4ce4c0d8x736b95e41e205f0@mail.gmail.com> <475DB5FE.1080302@lindenlab.com> Message-ID: <82fa9e310712101445h27ebba47n705c23fcc82a423c@mail.gmail.com> On Dec 10, 2007 1:56 PM, Ryan Williams (Which) wrote: > mark wrote: > > am using eventlet and running a process.. and suddenly it stops running > > [which i can tell from logs and others] > > and when i go to the terminal in which started this process is running > and i > > hit CTRL C, it starts running again.... > > do you know what is wrong? > > thanks > That's pretty weird. Try using strace to see what it's doing at the > time of freeze: this is what i get from strace recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 recv(12, "", 4096, 0) = 0 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/c3698fd0/attachment.htm From annagulaev at gmail.com Mon Dec 10 17:13:26 2007 From: annagulaev at gmail.com (Anna Gulaev) Date: Mon Dec 10 17:13:33 2007 Subject: [sldev] reducing network traffic In-Reply-To: <475CCFD8.3030506@wsu.edu> References: <475CCFD8.3030506@wsu.edu> Message-ID: On 12/10/07, John Hurliman wrote: > > You can almost entirely suppress LayerData packets by sending another > AgentThrottle packet with Land (or is it Terrain?) set to 0, if you want > to see the world without any ground. Okay, I tried that and it didn't seem to do anything. Thinking I might have done something wrong, I simplified things by replaced this line... dp.packF32( mThrottles[i] * 1024.0f, "Throttle"); with these lines... if ( i==1) dp.packF32( 0. * 1024.0f, "Throttle"); else dp.packF32( mThrottles[i] * 1024.0f, "Throttle"); in LLViewerThrottleGroup::sendToSim(). It should now be incapable of sending an AgentUpdate with anything but zero for the Land throttle. Confirmed in my log that the AgentUpdate is being sent. Still, I receive LayerData packets. So I thought maybe it doesn't like zero and ignores it. Tried 1. Tried 5. Tried 10. Tried 100. No difference in the number of LayerData packets I receive. FWIW the number it wants to send before I override it is 87.7. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/0df99d4f/attachment.htm From donovan at lindenlab.com Mon Dec 10 17:16:33 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Mon Dec 10 17:18:18 2007 Subject: [sldev] eventlet stops running In-Reply-To: <82fa9e310712101445h27ebba47n705c23fcc82a423c@mail.gmail.com> References: <82fa9e310712101131y4ce4c0d8x736b95e41e205f0@mail.gmail.com> <475DB5FE.1080302@lindenlab.com> <82fa9e310712101445h27ebba47n705c23fcc82a423c@mail.gmail.com> Message-ID: Hmm, so it looks like it's getting into a loop calling recv and getting back 0 bytes (which means that the socket is closed, I think) Am I reading strace right? Do you have a minimal failing test? Is this easily reproducable? Donovan On Dec 10, 2007, at 2:45 PM, mark wrote: > On Dec 10, 2007 1:56 PM, Ryan Williams (Which) > wrote: > mark wrote: > > am using eventlet and running a process.. and suddenly it stops > running > > [which i can tell from logs and others] > > and when i go to the terminal in which started this process is > running and i > > hit CTRL C, it starts running again.... > > do you know what is wrong? > > thanks > That's pretty weird. Try using strace to see what it's doing at the > time of freeze: > > this is what i get from strace > > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > _______________________________________________ > 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/20071210/a9f2bdc6/attachment-0001.htm From markkicks at gmail.com Mon Dec 10 17:31:28 2007 From: markkicks at gmail.com (mark) Date: Mon Dec 10 17:31:31 2007 Subject: [sldev] eventlet stops running In-Reply-To: References: <82fa9e310712101131y4ce4c0d8x736b95e41e205f0@mail.gmail.com> <475DB5FE.1080302@lindenlab.com> <82fa9e310712101445h27ebba47n705c23fcc82a423c@mail.gmail.com> Message-ID: <82fa9e310712101731h6c407e2udbdf73e2fcf2ada8@mail.gmail.com> On Dec 10, 2007 5:16 PM, Donovan Preston wrote: > Hmm, so it looks like it's getting into a loop calling recv and getting > back 0 bytes (which means that the socket is closed, I think) > it should raise an error or something like that right? > > Am I reading strace right? > yes i think so! > Do you have a minimal failing test? Is this easily reproducable? > am trying to find out what produces this error.. am having strace going on this process... to see how it hits the problem. i have a max_size=6 for pool, so even if one goes into an infinite loop, it should not freeze and it should keep running right? > > Donovan > > On Dec 10, 2007, at 2:45 PM, mark wrote: > > On Dec 10, 2007 1:56 PM, Ryan Williams (Which) wrote: > > > mark wrote: > > > am using eventlet and running a process.. and suddenly it stops > > running > > > [which i can tell from logs and others] > > > and when i go to the terminal in which started this process is running > > and i > > > hit CTRL C, it starts running again.... > > > do you know what is wrong? > > > thanks > > That's pretty weird. Try using strace to see what it's doing at the > > time of freeze: > > > this is what i get from strace > > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > recv(12, "", 4096, 0) = 0 > _______________________________________________ > 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/20071210/8a9e189d/attachment.htm From annagulaev at gmail.com Mon Dec 10 17:39:14 2007 From: annagulaev at gmail.com (Anna Gulaev) Date: Mon Dec 10 17:39:17 2007 Subject: [sldev] reducing network traffic In-Reply-To: References: <475CCFD8.3030506@wsu.edu> Message-ID: Oh, but waitaminit. I also throttled wind and cloud, and...tada! No LayerData packets, and sitting in my grey box at 750m bandwidth is staying under 10kbps; usually under 5. Now just for giggles I'm going to fly around and see what the world looks like without ground... Thanks, John! On 12/10/07, Anna Gulaev wrote: > > On 12/10/07, John Hurliman wrote: > > > > You can almost entirely suppress LayerData packets by sending another > > AgentThrottle packet with Land (or is it Terrain?) set to 0, if you want > > to see the world without any ground. > > > Okay, I tried that and it didn't seem to do anything... > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/6a9b2636/attachment.htm From annagulaev at gmail.com Mon Dec 10 19:06:11 2007 From: annagulaev at gmail.com (Anna Gulaev) Date: Mon Dec 10 19:06:14 2007 Subject: [sldev] reducing network traffic In-Reply-To: References: <475CCFD8.3030506@wsu.edu> Message-ID: Ack. The AttachedSound messages are back. About 15 per second at 61 bytes each. Any way to throttle those? On 12/10/07, Anna Gulaev wrote: > > Oh, but waitaminit. I also throttled wind and cloud, and...tada! No > LayerData packets, and sitting in my grey box at 750m bandwidth is staying > under 10kbps; usually under 5. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071210/1cc502f3/attachment.htm From seg at haxxed.com Mon Dec 10 20:25:22 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 10 20:25:39 2007 Subject: [sldev] [VWR] Swap storm with 1.18.5.X In-Reply-To: <474C80FF.90002@gmail.com> References: <474C80FF.90002@gmail.com> Message-ID: <1197347122.1718.69.camel@localhost> On Tue, 2007-11-27 at 20:41 +0000, Robin Cornelius wrote: > Is anyone else testing the 1.18.5.X branch, i'm having loads of trouble > with basically a swap storm or the "eat all your memory and die" bug. > Its so bad It can force me to reset the system to recover. Argh. Okay, it's confirmed, seems this is ultimately OpenJPEG's fault after all. There was a bug introduced in svn465 that was visible in SL as uninitialized textures. This bug was fixed in svn483. This bug seemed to somehow trigger a leak... somewhere else. The leak was not in OpenJPEG as far as I could tell, which is why I didn't suspect it as much as I should have. I guess Mesa 7 somehow magnified this leak. So it appears it was a nasty interaction of things. The interaction between OpenJPEG's error reporting and what slviewer expects may need some work... Upgrade your OpenJPEG snapshots if you've got 'em... I guess the plan now is a new release possibly before christmas, they're working on integrating a Java wrapper: http://groups.google.com/group/openjpeg/browse_frm/thread/14811710e51a6343 -------------- 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/20071210/e9e27a24/attachment.pgp From xotmid at gmail.com Tue Dec 11 04:47:48 2007 From: xotmid at gmail.com (Brandon Husbands) Date: Tue Dec 11 04:47:53 2007 Subject: [SLDEV] Compile on visual studio 2008 Message-ID: Here is how i did it.. install vs.. Follow the setup on the wiki for the libs and 3rd party libs. download vs 2005 c++ express copy the algarythim file from VS 2005 to your vs 2008 dir... There is a known bug in it... and its being addressed next patch. so you have to use 2005's one. I had to unload test project.. I also had to remove all references to the Logitech LCG keyboard. (for some reason i did not have the lib). After that it compiles just fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/9b61a8f5/attachment.htm From dimentox at dimentox.com Tue Dec 11 04:48:29 2007 From: dimentox at dimentox.com (Dimentox) Date: Tue Dec 11 04:48:31 2007 Subject: [SLDEV] Compile on visual studio 2008 Message-ID: Here is how i did it.. install vs.. Follow the setup on the wiki for the libs and 3rd party libs. download vs 2005 c++ express copy the algarythim file from VS 2005 to your vs 2008 dir... There is a known bug in it... and its being addressed next patch. so you have to use 2005's one. I had to unload test project.. I also had to remove all references to the Logitech LCG keyboard. (for some reason i did not have the lib). After that it compiles just fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/40a402c0/attachment.htm From sean at dague.net Tue Dec 11 05:18:20 2007 From: sean at dague.net (Sean Dague) Date: Tue Dec 11 05:13:07 2007 Subject: [sldev] Re: [POLICY] OpenSL considered harmful? In-Reply-To: <475DB745.5030108@wsu.edu> References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> <475DB745.5030108@wsu.edu> Message-ID: <20071211131820.GH3469@dague.net> On Mon, Dec 10, 2007 at 02:01:41PM -0800, John Hurliman wrote: > Joshy Squashy wrote: >> OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source alpha >> Second Life server framework. It is extremely crippled, with limited >> scripting options and a large number of missing features; however, it is >> functional. > > I'm not sure where you read the acronym OpenSL but that is usually used to > refer to the GPL licensed official viewer, the main topic of discussion on > this list. opensimulator.org is generally called OpenSim and their IRC > channel is #opensim on EFNet. Just clarifying any naming confusion. Yes, OpenSim is the proper name for the server, not sure where you got OpenSL either. :) My suggestion is to follow Zero's office hours, and make up your own mind here: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours It's all logged, so everyone is on the record, and OpenSim comes up often enough. -Sean -- __________________________________________________________________ Sean Dague Mid-Hudson Valley sean at dague dot net Linux Users Group http://dague.net http://mhvlug.org There is no silver bullet. Plus, werewolves make better neighbors than zombies, and they tend to keep the vampire population down. __________________________________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071211/d1264156/attachment-0001.pgp From gwardell at gwsystems.co.il Tue Dec 11 06:19:14 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Tue Dec 11 06:19:25 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: <475DB745.5030108@wsu.edu> Message-ID: <005001c83c00$cf7a3b60$a400000a@gwsystems2.com> > I'm not sure where you read the acronym OpenSL but that is I see where that comes from. The logo in the upper left corner of the main page of the below reference web site. Gary > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of John Hurliman > Sent: Mon, December 10, 2007 5:02 PM > To: sldev@lists.secondlife.com > Subject: Re: [sldev] [POLICY] OpenSL considered harmful? > > > Joshy Squashy wrote: > > OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source > > alpha Second Life server framework. It is extremely crippled, with > > limited scripting options and a large number of missing features; > > however, it is functional. > > I'm not sure where you read the acronym OpenSL but that is > usually used > to refer to the GPL licensed official viewer, the main topic of > discussion on this list. opensimulator.org is generally > called OpenSim > and their IRC channel is #opensim on EFNet. Just clarifying > any naming > confusion. > > John > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From adam at gwala.net Tue Dec 11 06:29:34 2007 From: adam at gwala.net (Adam Frisby) Date: Tue Dec 11 06:30:40 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: <005001c83c00$cf7a3b60$a400000a@gwsystems2.com> References: <005001c83c00$cf7a3b60$a400000a@gwsystems2.com> Message-ID: <475E9ECE.8050302@gwala.net> Hrrm, that probably needs changing, since that has carried over from the old OpenSL svn repo which was on the same server (and using the same wiki) Adam Gary Wardell wrote: >>I'm not sure where you read the acronym OpenSL but that is > > > I see where that comes from. The logo in the upper left corner of the main page of the below reference web site. > > Gary > > >>-----Original Message----- >>From: sldev-bounces@lists.secondlife.com >>[mailto:sldev-bounces@lists.secondlife.com]On Behalf Of John Hurliman >>Sent: Mon, December 10, 2007 5:02 PM >>To: sldev@lists.secondlife.com >>Subject: Re: [sldev] [POLICY] OpenSL considered harmful? >> >> >>Joshy Squashy wrote: >> >>>OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source >>>alpha Second Life server framework. It is extremely crippled, with >>>limited scripting options and a large number of missing features; >>>however, it is functional. >> >>I'm not sure where you read the acronym OpenSL but that is >>usually used >>to refer to the GPL licensed official viewer, the main topic of >>discussion on this list. opensimulator.org is generally >>called OpenSim >>and their IRC channel is #opensim on EFNet. Just clarifying >>any naming >>confusion. >> >>John >>_______________________________________________ >>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 gwardell at gwsystems.co.il Tue Dec 11 06:35:49 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Tue Dec 11 06:36:00 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: <475E9ECE.8050302@gwala.net> Message-ID: <005301c83c03$20747290$a400000a@gwsystems2.com> Probably so, since the screen shot on the other side says Welcome to Open Sim. Maybe just change the "OpenSL" to "OpenSim" in the logo. I think the text would fit. Gary > -----Original Message----- > From: Adam Frisby [mailto:adam@gwala.net] > Sent: Tue, December 11, 2007 9:30 AM > To: Gary Wardell > Cc: 'John Hurliman'; sldev@lists.secondlife.com > Subject: Re: [sldev] [POLICY] OpenSL considered harmful? > > > Hrrm, that probably needs changing, since that has carried > over from the > old OpenSL svn repo which was on the same server (and using > the same wiki) > > Adam > > Gary Wardell wrote: > > >>I'm not sure where you read the acronym OpenSL but that is > > > > > > I see where that comes from. The logo in the upper left > corner of the main page of the below reference web site. > > > > Gary > > > > > >>-----Original Message----- > >>From: sldev-bounces@lists.secondlife.com > >>[mailto:sldev-bounces@lists.secondlife.com]On Behalf Of > John Hurliman > >>Sent: Mon, December 10, 2007 5:02 PM > >>To: sldev@lists.secondlife.com > >>Subject: Re: [sldev] [POLICY] OpenSL considered harmful? > >> > >> > >>Joshy Squashy wrote: > >> > >>>OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source > >>>alpha Second Life server framework. It is extremely > crippled, with > >>>limited scripting options and a large number of missing features; > >>>however, it is functional. > >> > >>I'm not sure where you read the acronym OpenSL but that is > >>usually used > >>to refer to the GPL licensed official viewer, the main topic of > >>discussion on this list. opensimulator.org is generally > >>called OpenSim > >>and their IRC channel is #opensim on EFNet. Just clarifying > >>any naming > >>confusion. > >> > >>John > >>_______________________________________________ > >>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 kelly at lindenlab.com Tue Dec 11 09:07:57 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Dec 11 09:09:28 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> Message-ID: <475EC3ED.2080602@lindenlab.com> Joshy Squashy wrote: > OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source > alpha Second Life server framework. It is extremely crippled, with > limited scripting options and a large number of missing features; > however, it is functional. > > The laboratory at my college has been doing research using synthetic > worlds in education software projects and software engineering > projects for some time. We have been following development of OpenSL > for some time, as we are very excited with the possibilities of having > access to the source code for both the client and server (particularly > in situations when the SL server should also be some other type of > server). > > Though OpenSL isn't much at the moment, we are approaching the point > where we plan to try OpenSL servers for some very simple projects. > However, some colleagues disagree that we should consider OpenSL, > claiming they are reverse-engineering Second Life's message protocols > and that having the potential for hosting "free" Second Life servers > is a threat to Linden Labs so Linden Labs will either shut down OpenSL > or release client versions that render OpenSL unusable. > > While I don't know Linden Labs opinion on the subject, I would think > that such claims don't amount to much. Releasing a client version > that renders OpenSL unusable can't really happen because the client is > open source so it's a trivial matter to remove the code that prevents > interoperability. However, shutting down OpenSL I see as conceivable > but unlikely; the OpenSL server is so crippled that one would need > very specific reasons as to why it would be desirable to use it, and > Linden Labs hasn't taken action yet. I simply don't see Linden Labs > as considering this to be a threat, particularly considering their > substantial existing userbase and that my understanding is that > they've been toying with the idea of releasing the server code > outright themselves for some time already. > > Still, my colleagues and I would be very interested in hearing Linden > Labs direction in dealing with those involved in developing 3rd party > Second Life server frameworks. > > ~Squash Otoro As others have pointed out, we are working with OpenSim (along with other people) in the AWG groups on standards of interoperability. From the wiki page: "AWG's mission is to develop the protocols that will open up the Second Life Grid from something operated solely by Linden Lab to where others can run parts of the grid." I think someone linked it already, but more info on AWG here: https://wiki.secondlife.com/wiki/Architecture_Working_Group I am sure the AWG group, and myself personally, would be interested in any reasoning for using OpenSim over SL - what you mean by "when the SL server should also be some other type of server" etc. Your requirements probably aren't entirely unique and I'm sure the group could benefit from hearing them. As for OpenSim specifically, we don't have the means to block access to them (due to the open source client as mentioned), nor do I think we have the desire to. I can't offer any official statement about OpenSim or our future interactions with them, but I think our work with AWG speaks clearly towards our intent. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/3738e6d4/attachment.htm From donovan at lindenlab.com Tue Dec 11 09:15:11 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Tue Dec 11 09:15:19 2007 Subject: [sldev] eventlet stops running In-Reply-To: <82fa9e310712101731h6c407e2udbdf73e2fcf2ada8@mail.gmail.com> References: <82fa9e310712101131y4ce4c0d8x736b95e41e205f0@mail.gmail.com> <475DB5FE.1080302@lindenlab.com> <82fa9e310712101445h27ebba47n705c23fcc82a423c@mail.gmail.com> <82fa9e310712101731h6c407e2udbdf73e2fcf2ada8@mail.gmail.com> Message-ID: On Dec 10, 2007, at 5:31 PM, mark wrote: > On Dec 10, 2007 5:16 PM, Donovan Preston > wrote: > Hmm, so it looks like it's getting into a loop calling recv and > getting back 0 bytes (which means that the socket is closed, I think) > it should raise an error or something like that right? Yes. I vaguely remember that maybe this is fixed in the beta-1 branch (as opposed to the trunk). Perhaps you could try it and see? If all else fails, please put api.spew() close to the point where the error occurs and try to see what your python code is doing at that point. Donovan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/88cd6316/attachment.htm From tao.takashi at googlemail.com Tue Dec 11 10:42:02 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Dec 11 10:42:06 2007 Subject: [sldev] [AWG]Login UML Diagram Message-ID: <23bbb49e0712111042u1a0c0397m41ddacf602b0825c@mail.gmail.com> Hi! just FYI: I created some UML diagram (or something similar ;-) ) for the login procedure. I will add some explanations later on but maybe it speaks for itself.. It's basically modeled after the office hour on Nov 27. You can find it here: http://www.flickr.com/photos/mrtopf/2100998735/ I write write a blog post about some stuff soon and I will later also put it on the wiki. I will also check in my code which goes alongside and can be found at http://code.google.com/p/pysecondlife (important are the two packages capsserver and loginserver as well as the client folder for testing. I will also add instructions on how to actually run it later (but probably not today. It mostly just says "ok" anyway ;-) ). Hope to see you later at Zero's office hour. cheers, Tao -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/9bb27aaf/attachment.htm From kamilion at gmail.com Tue Dec 11 10:48:59 2007 From: kamilion at gmail.com (Kamilion) Date: Tue Dec 11 10:49:05 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: <475EC3ED.2080602@lindenlab.com> References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> <475EC3ED.2080602@lindenlab.com> Message-ID: On Dec 11, 2007 9:07 AM, Kelly Linden wrote: > As others have pointed out, we are working with OpenSim (along with other > people) in the AWG groups on standards of interoperability. >From the wiki > page: > "AWG's mission is to develop the protocols that will open up the Second > Life Grid from something operated solely by Linden Lab to where others can > run parts of the grid." > I think someone linked it already, but more info on AWG here: > > https://wiki.secondlife.com/wiki/Architecture_Working_Group > > I am sure the AWG group, and myself personally, would be interested in any > reasoning for using OpenSim over SL - what you mean by "when the SL server > should also be some other type of server" etc. Your requirements probably > aren't entirely unique and I'm sure the group could benefit from hearing > them. I believe what he was implying was embedding or allowing another piece of software to interact with OpenSim. For instance, A router might have a simulator based on OpenSim embedded in it instead of a simple HTTP server. One would be able to use the SL protocol/viewer to toggle settings or change routing properties. Another use would be interacting with a home music server, moving a primset representing an album and it's songs into a space representing a playlist. Yet another use perhaps would be a simulator frontend to nagios[1] or splunk[2] keeping track of a group of servers as individual prims and representing their status by changing textures, colors or hovertext. There's plenty of other devices or chunks of software that could benefit from an embedded simulator. Anyone who's ever played the Megaman Battle Network[3] series[4] on the GBA/DS should know what I mean. Just about every device from ovens to traffic lights had it's own little 3D world embedded in it. Most of the problems stemmed from griefers using limited AI avatars/agents to infect these devices with viral properties. Sounds to me that's what Joshy Squashy might be working on. [1] http://www.nagios.org/ [2] http://www.splunk.com/ [3] http://en.wikipedia.org/wiki/Mega_Man_Battle_Network_(video_game) [4] http://en.wikipedia.org/wiki/Mega_Man_Battle_Network_(series) Slightly edited excerpt of [3] for background & quick reference: The player alternately controls two main characters, Lan Hikari and MegaMan.EXE. The former is human while the latter, MegaMan, is a computer program/avatar called a NetNavi (derived from Network Navigator) designed specifically to facilitate the user's (Lan's) interaction with the Net and other computerized devices. In the series, the Internet and the inner workings of computers are displayed as a material world which computer programs of all varieties, as personified in a humanoid form, can interact with. To advance through the game the player must navigate both the real world as Lan and the Net as MegaMan, each containing certain tasks that must be completed to allow advancement in the other. MegaMan.EXE is often contained in Lan's PET (PErsonal Terminal), however this may be connected to the Internet or a computer in a process called "jacking in" ("plugging in" in Japan), which allows MegaMan access to that device. At this point, the Navi is transferred to the respective device, rather than being duplicated. If the program is deleted while jacked in, the effect is rather permanent, unless a backup of the Navi has been made. However, for the player, deletion of MegaMan.EXE results in a game over in most circumstances. > As for OpenSim specifically, we don't have the means to block access to > them (due to the open source client as mentioned), nor do I think we have > the desire to. I can't offer any official statement about OpenSim or our > future interactions with them, but I think our work with AWG speaks clearly > towards our intent. > > - Kelly From kelly at lindenlab.com Tue Dec 11 10:58:05 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Tue Dec 11 10:58:43 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> <475EC3ED.2080602@lindenlab.com> Message-ID: <475EDDBD.8030904@lindenlab.com> Kamilion wrote: > On Dec 11, 2007 9:07 AM, Kelly Linden wrote: > >> As others have pointed out, we are working with OpenSim (along with other >> people) in the AWG groups on standards of interoperability. >From the wiki >> page: >> "AWG's mission is to develop the protocols that will open up the Second >> Life Grid from something operated solely by Linden Lab to where others can >> run parts of the grid." >> I think someone linked it already, but more info on AWG here: >> >> https://wiki.secondlife.com/wiki/Architecture_Working_Group >> >> I am sure the AWG group, and myself personally, would be interested in any >> reasoning for using OpenSim over SL - what you mean by "when the SL server >> should also be some other type of server" etc. Your requirements probably >> aren't entirely unique and I'm sure the group could benefit from hearing >> them. >> > > I believe what he was implying was embedding or allowing another piece > of software to interact with OpenSim. > For instance, A router might have a simulator based on OpenSim > embedded in it instead of a simple HTTP server. > One would be able to use the SL protocol/viewer to toggle settings or > change routing properties. > > Another use would be interacting with a home music server, moving a > primset representing an album and it's songs into a space representing > a playlist. > > Yet another use perhaps would be a simulator frontend to nagios[1] or > splunk[2] keeping track of a group of servers as individual prims and > representing their status by changing textures, colors or hovertext. > > There's plenty of other devices or chunks of software that could > benefit from an embedded simulator. > Anyone who's ever played the Megaman Battle Network[3] series[4] on > the GBA/DS should know what I mean. > Just about every device from ovens to traffic lights had it's own > little 3D world embedded in it. > Most of the problems stemmed from griefers using limited AI > avatars/agents to infect these devices with viral properties. > > Sounds to me that's what Joshy Squashy might be working on. > > [1] http://www.nagios.org/ > [2] http://www.splunk.com/ > [3] http://en.wikipedia.org/wiki/Mega_Man_Battle_Network_(video_game) > [4] http://en.wikipedia.org/wiki/Mega_Man_Battle_Network_(series) > > Slightly edited excerpt of [3] for background & quick reference: > The player alternately controls two main characters, Lan Hikari and > MegaMan.EXE. The former is human while the latter, MegaMan, is a > computer program/avatar called a NetNavi (derived from Network > Navigator) designed specifically to facilitate the user's (Lan's) > interaction with the Net and other computerized devices. In the > series, the Internet and the inner workings of computers are displayed > as a material world which computer programs of all varieties, as > personified in a humanoid form, can interact with. > > To advance through the game the player must navigate both the real > world as Lan and the Net as MegaMan, each containing certain tasks > that must be completed to allow advancement in the other. MegaMan.EXE > is often contained in Lan's PET (PErsonal Terminal), however this may > be connected to the Internet or a computer in a process called > "jacking in" ("plugging in" in Japan), which allows MegaMan access to > that device. At this point, the Navi is transferred to the respective > device, rather than being duplicated. If the program is deleted while > jacked in, the effect is rather permanent, unless a backup of the Navi > has been made. However, for the player, deletion of MegaMan.EXE > results in a game over in most circumstances. > > Sorry, I didn't mean to ask in general what he could have meant. I can think up dozens of scenarios myself, just as you have. Rather, I thought the AWG group would appreciate concrete examples from his requirements. What do they actually plan or hope to do? Do they really want to control router configs from a virtual 3d environment, or control their home media system? Aside from the AWG's interest, I personally am also interested in the specific scenarios. - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/301ec0c5/attachment.htm From dzonatas at dzonux.net Tue Dec 11 11:39:37 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 11 11:38:13 2007 Subject: [sldev] [ANN] Open Source Meeting: Dec 13th, 2pm (PST/SLT) Message-ID: <475EE779.5090000@dzonux.net> A reminder for everybody that the next Open Source Meeting is on December 13th at 2pm. Here is the link to the Agenda. http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Please add your items for discussion. -- Power to Change the Void From lenglish5 at cox.net Tue Dec 11 14:43:00 2007 From: lenglish5 at cox.net (Lawson English) Date: Tue Dec 11 14:43:03 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: <475EC3ED.2080602@lindenlab.com> References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> <475EC3ED.2080602@lindenlab.com> Message-ID: <475F1274.3030606@cox.net> Kelly Linden wrote: > Joshy Squashy wrote: >> OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source >> alpha Second Life server framework. It is extremely crippled, with >> limited scripting options and a large number of missing features; >> however, it is functional. >> >> The laboratory at my college has been doing research using synthetic >> worlds in education software projects and software engineering >> projects for some time. We have been following development of OpenSL >> for some time, as we are very excited with the possibilities of >> having access to the source code for both the client and server >> (particularly in situations when the SL server should also be some >> other type of server). >> >> Though OpenSL isn't much at the moment, we are approaching the point >> where we plan to try OpenSL servers for some very simple projects. >> However, some colleagues disagree that we should consider OpenSL, >> claiming they are reverse-engineering Second Life's message protocols >> and that having the potential for hosting "free" Second Life servers >> is a threat to Linden Labs so Linden Labs will either shut down >> OpenSL or release client versions that render OpenSL unusable. >> >> While I don't know Linden Labs opinion on the subject, I would think >> that such claims don't amount to much. Releasing a client version >> that renders OpenSL unusable can't really happen because the client >> is open source so it's a trivial matter to remove the code that >> prevents interoperability. However, shutting down OpenSL I see as >> conceivable but unlikely; the OpenSL server is so crippled that one >> would need very specific reasons as to why it would be desirable to >> use it, and Linden Labs hasn't taken action yet. I simply don't see >> Linden Labs as considering this to be a threat, particularly >> considering their substantial existing userbase and that my >> understanding is that they've been toying with the idea of releasing >> the server code outright themselves for some time already. >> >> Still, my colleagues and I would be very interested in hearing Linden >> Labs direction in dealing with those involved in developing 3rd party >> Second Life server frameworks. >> >> ~Squash Otoro > As others have pointed out, we are working with OpenSim (along with > other people) in the AWG groups on standards of interoperability. > >From the wiki page: > "AWG's mission is to develop the protocols that will open up the > Second Life Grid from something operated solely by Linden Lab to where > others can run parts of the grid." > I think someone linked it already, but more info on AWG here: > https://wiki.secondlife.com/wiki/Architecture_Working_Group > > I am sure the AWG group, and myself personally, would be interested in > any reasoning for using OpenSim over SL - what you mean by "when the > SL server should also be some other type of server" etc. Your > requirements probably aren't entirely unique and I'm sure the group > could benefit from hearing them. > > As for OpenSim specifically, we don't have the means to block access > to them (due to the open source client as mentioned), nor do I think > we have the desire to. I can't offer any official statement about > OpenSim or our future interactions with them, but I think our work > with AWG speaks clearly towards our intent. OpenSim and libsecondlife are already acknowledged as being alternate implementations of the [soon-to-be-open] grid. https://wiki.secondlife.com/wiki/AWG_Implementations As far as why people might want to use them goes... Well, the most obvious reason is simply immediacy. The issues with open sourcing the server code are apparently quite complex or so comments by various Lindens suggest, while OpenSim and the libsecondlife people are far more nimble organizations than Linden Lab, being smaller, and not driven by quarterly-profits so they can change what they are doing and where they are heading far faster and easier than LL Also, they can customize their own code far faster than the unreleased code from LL (obviously) and if the issues with the client source are anything to go by, customizing the server code will be exceedingly difficult, even impossible, past a certain point., It is quite literally easier to rewrite the client from scratch than to customize it in certain ways, and the same thing will no doubt be true of the server code as well so using OpenSim and libsl will be the method of choice for creating specialized software based on the SL platform for quite some time. The AW Groupies modular client project may eventually become an alternative on the client side, but we don't have any way of producing that on the server side without doing the reverse engineering thing, which OpenSim is already doing. Lawson From markkicks at gmail.com Tue Dec 11 14:43:56 2007 From: markkicks at gmail.com (mark) Date: Tue Dec 11 14:43:58 2007 Subject: [sldev] help with beta-1 Message-ID: <82fa9e310712111443y77154f99gfd80c4cc20bd4865@mail.gmail.com> i checked out beta-1 version, and I installed greenlet version 0.1 from easy_install, and i get this error, it freezes.. how to fix this? Traceback (most recent call last): File "/home/mark/work/main/animmes/eventlet/pollhub.py", line 170, in wait read(fileno) File "/home/mark/work/main/animmes/eventlet/api.py", line 146, in cb greenlib.switch(self, fd) File "/home/mark/work/main/animmes/eventlet/greenlib.py", line 310, in switch rval = other.switch(value, exc) File "/home/mark/work/main/animmes/eventlet/greenlib.py", line 287, in greenlet_body return cb(*args) File "/home/mark/work/main/animmes/eventlet/api.py", line 159, in _spawn_startup return cb(*args, **kw) File "/home/mark/work/main/animmes/eventlet/coros.py", line 113, in _main_loop api.get_hub().runloop.cancel_timers(api.getcurrent()) File "/home/mark/work/main/animmes/eventlet/runloop.py", line 218, in cancel_timers for timer in self.timers_by_greenlet[greenlet]: KeyError: greenlet version: greenlet.__file__ '/home/mark/.python-eggs/greenlet-0.1-py2.5-linux-i686.egg-tmp/greenlet.so' -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/762f2a3e/attachment.htm From donovan at lindenlab.com Tue Dec 11 15:46:10 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Tue Dec 11 15:47:39 2007 Subject: [sldev] help with beta-1 In-Reply-To: <82fa9e310712111443y77154f99gfd80c4cc20bd4865@mail.gmail.com> References: <82fa9e310712111443y77154f99gfd80c4cc20bd4865@mail.gmail.com> Message-ID: It does look like a genuine bug. Replace the line: On Dec 11, 2007, at 2:43 PM, mark wrote: > i checked out beta-1 version, and I installed greenlet version 0.1 > from easy_install, > and i get this error, it freezes.. > how to fix this? > File "/home/mark/work/main/animmes/eventlet/runloop.py", line 218, > in cancel_timers > for timer in self.timers_by_greenlet[greenlet]: With this: for timer in self.timers_by_greenlet.get(greenlet, ()): If this turns out to fix it, please open a JIRA issue and submit a patch. Thanks! Donovan From robin.cornelius at gmail.com Tue Dec 11 15:55:15 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Dec 11 15:50:10 2007 Subject: [sldev] [VWR] Cannot login under valgrind Message-ID: <475F2363.3080909@gmail.com> Hi Everyone. Since 1.18.6.0 it does not seem possible to login under valgrind. Everything seems to run ok but you never get to the login window last message was:- 2007-12-11T23:43:52Z INFO: login_show: Setting Servers 2007-12-11T23:43:52Z INFO: setStartupState: Startup state changing from 1 to 2 also tried with --autologin but no difference. Not sure whats changed but are there any timeouts that could trip and lockup in a loop because valgrind is making things run like treacle? I have managed to get in world before on the 1.18.5.X series with valgrind, so it appears to be something new. Regards Robin -------------- 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/20071211/4d4cf681/signature.pgp From sly_squash at hotmail.com Tue Dec 11 16:51:09 2007 From: sly_squash at hotmail.com (Joshy Squashy) Date: Tue Dec 11 16:51:13 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: <475EC3ED.2080602@lindenlab.com> References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> <475EC3ED.2080602@lindenlab.com> Message-ID: Thank you for your responses, Kelly Linden. Always nice to hear right from the source. :) Q: "What you mean by 'when the SL server should also be some other type of server' etc"A: Arbitrary server -- web, file, or other type of server. But a better answer might be to give a (albeit somewhat contrived) specific workflow I envision. I guess imagine a virtual file server. Using the open-source viewer and open-source viewer code, you could create a prims to represent viewer-uploaded files like personal videos, documents, and such. For example, I could create a prim shaped like a video cassette, texture with a label like a wedding dress, and upload a file "My Wedding Video.mov". When someone else sees the virtual video cassette, they could click it, and the custom server code would know to check the location where it stored the uploaded video and send it to the user. Or one could envision a virtual library where users create "book" prims, texture the prims like their corresponding books, upload the e-book to their custom OpenSim server via an interface in their custom Second Life viewer, and then we would host a virtual library of e-books. User's could login to the virtual library server and click the book they want to read, and the server would send the e-book, and perhaps then the custom client would have a built-in reader for opening the e-book. Again, it's a bit contrived, but I think you can begin to see some of the potential that comes along with having the Second Life server and another type of server be on the same box. ~Squash Otoro Date: Tue, 11 Dec 2007 09:07:57 -0800 From: kelly@lindenlab.com To: sly_squash@hotmail.com CC: sldev@lists.secondlife.com Subject: Re: [sldev] [POLICY] OpenSL considered harmful? Joshy Squashy wrote: OpenSL (http://opensimulator.org/wiki/Main_Page) is an open source alpha Second Life server framework. It is extremely crippled, with limited scripting options and a large number of missing features; however, it is functional. The laboratory at my college has been doing research using synthetic worlds in education software projects and software engineering projects for some time. We have been following development of OpenSL for some time, as we are very excited with the possibilities of having access to the source code for both the client and server (particularly in situations when the SL server should also be some other type of server). Though OpenSL isn't much at the moment, we are approaching the point where we plan to try OpenSL servers for some very simple projects. However, some colleagues disagree that we should consider OpenSL, claiming they are reverse-engineering Second Life's message protocols and that having the potential for hosting "free" Second Life servers is a threat to Linden Labs so Linden Labs will either shut down OpenSL or release client versions that render OpenSL unusable. While I don't know Linden Labs opinion on the subject, I would think that such claims don't amount to much. Releasing a client version that renders OpenSL unusable can't really happen because the client is open source so it's a trivial matter to remove the code that prevents interoperability. However, shutting down OpenSL I see as conceivable but unlikely; the OpenSL server is so crippled that one would need very specific reasons as to why it would be desirable to use it, and Linden Labs hasn't taken action yet. I simply don't see Linden Labs as considering this to be a threat, particularly considering their substantial existing userbase and that my understanding is that they've been toying with the idea of releasing the server code outright themselves for some time already. Still, my colleagues and I would be very interested in hearing Linden Labs direction in dealing with those involved in developing 3rd party Second Life server frameworks. ~Squash Otoro As others have pointed out, we are working with OpenSim (along with other people) in the AWG groups on standards of interoperability. >From the wiki page: "AWG's mission is to develop the protocols that will open up the Second Life Grid from something operated solely by Linden Lab to where others can run parts of the grid." I think someone linked it already, but more info on AWG here: https://wiki.secondlife.com/wiki/Architecture_Working_Group I am sure the AWG group, and myself personally, would be interested in any reasoning for using OpenSim over SL - what you mean by "when the SL server should also be some other type of server" etc. Your requirements probably aren't entirely unique and I'm sure the group could benefit from hearing them. As for OpenSim specifically, we don't have the means to block access to them (due to the open source client as mentioned), nor do I think we have the desire to. I can't offer any official statement about OpenSim or our future interactions with them, but I think our work with AWG speaks clearly towards our intent. - Kelly _________________________________________________________________ i?m is proud to present Cause Effect, a series about real people making a difference. http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/54045edb/attachment-0001.htm From dzonatas at dzonux.net Tue Dec 11 17:16:24 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 11 17:14:20 2007 Subject: [sldev] Compiling 1.18.6 with SCons on Windows (was: llzmozlib & Windlight) In-Reply-To: <47584A99.2040500@watson.ibm.com> References: <47558737.9060200@lindenlab.com> <20071205121203.GE28695@arnholm.se> <4756C4F3.3080008@lindenlab.com> <20071205222300.304cf923.sldev@free.fr> <475739D2.6020407@lindenlab.com> <47584A99.2040500@watson.ibm.com> Message-ID: <475F3668.4010605@dzonux.net> Mike Monkowski wrote: > I'm using SCons scripts provided by Dzonatas Sol for the compile > and link. MUCH nicer than hacking the project files. Don't have to > wait for CMake either. I think he's going to put some documentation > on the Wiki about the procedure. I have updated the sources and tested the build, and it builds clean with a single patch to 1.18.6: https://jira.secondlife.com/browse/VWR-3794 The wiki doc can be found at this link, for now, for how to compile with scons on windows: https://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Compiling_The_Viewer Much thanks to Mike for feedback he has given... very helpful. I look forward to integrate this version of llscons with cmake to build the project files. Let me know if there is anything else I for us to make this easier. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/95e06c12/attachment.htm From bos at lindenlab.com Tue Dec 11 17:13:55 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Dec 11 17:14:24 2007 Subject: [sldev] Recent OpenJPEG snapshots cause viewer death at startup Message-ID: <475F35D3.6010306@lindenlab.com> If you're trying to build the viewer from source without our prebuilt bits, please be aware of this: http://jira.secondlife.com/browse/VWR-3797 I'm working off the Fedora OpenJPEG package, which is about three weeks old. I think Callum Lerwick mentioned something about this in the past few days. References: <475F35D3.6010306@lindenlab.com> Message-ID: <1197426024.5470.8.camel@localhost> On Tue, 2007-12-11 at 17:13 -0800, Bryan O'Sullivan wrote: > If you're trying to build the viewer from source without our prebuilt > bits, please be aware of this: > > http://jira.secondlife.com/browse/VWR-3797 > > I'm working off the Fedora OpenJPEG package, which is about three weeks > old. I think Callum Lerwick mentioned something about this in the past > few days. Dupe. :) http://jira.secondlife.com/browse/VWR-3206 -------------- 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/20071211/84f1b40d/attachment.pgp From markkicks at gmail.com Tue Dec 11 22:08:32 2007 From: markkicks at gmail.com (mark) Date: Tue Dec 11 22:08:34 2007 Subject: [sldev] help with beta-1 In-Reply-To: References: <82fa9e310712111443y77154f99gfd80c4cc20bd4865@mail.gmail.com> Message-ID: <82fa9e310712112208x67b47f85u8d43ffd297f3a8f5@mail.gmail.com> On Dec 11, 2007 3:46 PM, Donovan Preston wrote: > It does look like a genuine bug. Replace the line: > On Dec 11, 2007, at 2:43 PM, mark wrote: > > > i checked out beta-1 version, and I installed greenlet version 0.1 > > from easy_install, > > and i get this error, it freezes.. > > how to fix this? > > > File "/home/mark/work/main/animmes/eventlet/runloop.py", line 218, > > in cancel_timers > > for timer in self.timers_by_greenlet[greenlet]: > > With this: > > for timer in self.timers_by_greenlet.get(greenlet, ()): > > If this turns out to fix it, please open a JIRA issue and submit a I get this error now: Traceback (most recent call last): File "/home/mark/work/main/animmes/eventlet/pollhub.py", line 170, in wait read(fileno) File "/home/mark/work/main/animmes/eventlet/api.py", line 146, in cb greenlib.switch(self, fd) File "/home/mark/work/main/animmes/eventlet/greenlib.py", line 310, in switch rval = other.switch(value, exc) File "/home/mark/work/main/animmes/eventlet/greenlib.py", line 287, in greenlet_body return cb(*args) File "/home/mark/work/main/animmes/eventlet/api.py", line 159, in _spawn_startup return cb(*args, **kw) File "/home/mark/work/main/animmes/eventlet/coros.py", line 113, in _main_loop api.get_hub().runloop.cancel_timers(api.getcurrent()) File "/home/mark/work/main/animmes/eventlet/runloop.py", line 224, in cancel_timers del self.timers_by_greenlet[greenlet] KeyError: Removing descriptor: 13 I tried to change this again like the fix you gave, but that gave another error, so that is not the right thing to do.. how to fix this? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071211/d9cde0ac/attachment.htm From seg at haxxed.com Tue Dec 11 22:36:20 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Dec 11 22:36:25 2007 Subject: [sldev] [VWR] Cannot login under valgrind In-Reply-To: <475F2363.3080909@gmail.com> References: <475F2363.3080909@gmail.com> Message-ID: <1197441380.5470.22.camel@localhost> On Tue, 2007-12-11 at 23:55 +0000, Robin Cornelius wrote: > Hi Everyone. > > Since 1.18.6.0 it does not seem possible to login under valgrind. > Everything seems to run ok but you never get to the login window last > message was:- > > 2007-12-11T23:43:52Z INFO: login_show: Setting Servers > 2007-12-11T23:43:52Z INFO: setStartupState: Startup state changing from > 1 to 2 > > also tried with --autologin but no difference. Not sure whats changed > but are there any timeouts that could trip and lockup in a loop because > valgrind is making things run like treacle? I have managed to get in > world before on the 1.18.5.X series with valgrind, so it appears to be > something new. Yeah valgrind slows the thing to a crawl which pretty much screws up everything. I can generally get logged in though, on a fast-ish machine. (Athlon 3000+) If you first disconnect on an empty sim/in the sky... Lately I've been having problems with the OpenGL drivers hanging/crashing, both fglrx and open source r300, so I haven't been able to get any decent valgrind runs lately, which... sucks. I've been getting a lot of crashes lately due to glibc detecting heap overruns again. Argh. -------------- 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/20071212/edf5102b/attachment.pgp From tateru.nino at gmail.com Wed Dec 12 07:34:28 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Dec 12 07:35:16 2007 Subject: [sldev] [POLICY] OpenSL considered harmful? In-Reply-To: References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> <475EC3ED.2080602@lindenlab.com> Message-ID: <475FFF84.5000209@gmail.com> There's certainly some equipment existing with text-based virtual world servers in them - telemetry units and the like. I had my hands on a few in the 90's. Fujitsu made them. Joshy Squashy wrote: > Thank you for your responses, Kelly Linden. Always nice to hear right > from the source. :) > > Q: "What you mean by 'when the SL server should also be some other > type of server' etc" > A: Arbitrary server -- web, file, or other type of server. But a > better answer might be to give a (albeit somewhat contrived) specific > workflow I envision. I guess imagine a virtual file server. Using > the open-source viewer and open-source viewer code, you could create a > prims to represent viewer-uploaded files like personal videos, > documents, and such. For example, I could create a prim shaped like a > video cassette, texture with a label like a wedding dress, and upload > a file "My Wedding Video.mov". When someone else sees the virtual > video cassette, they could click it, and the custom server code would > know to check the location where it stored the uploaded video and send > it to the user. > > Or one could envision a virtual library where users create "book" > prims, texture the prims like their corresponding books, upload the > e-book to their custom OpenSim server via an interface in their custom > Second Life viewer, and then we would host a virtual library of > e-books. User's could login to the virtual library server and click > the book they want to read, and the server would send the e-book, and > perhaps then the custom client would have a built-in reader for > opening the e-book. > > Again, it's a bit contrived, but I think you can begin to see some of > the potential that comes along with having the Second Life server and > another type of server be on the same box. > > ~Squash Otoro > > > > ------------------------------------------------------------------------ > Date: Tue, 11 Dec 2007 09:07:57 -0800 > From: kelly@lindenlab.com > To: sly_squash@hotmail.com > CC: sldev@lists.secondlife.com > Subject: Re: [sldev] [POLICY] OpenSL considered harmful? > > Joshy Squashy wrote: > > OpenSL (http://opensimulator.org/wiki/Main_Page) is an open > source alpha Second Life server framework. It is extremely > crippled, with limited scripting options and a large number of > missing features; however, it is functional. > > The laboratory at my college has been doing research using > synthetic worlds in education software projects and software > engineering projects for some time. We have been following > development of OpenSL for some time, as we are very excited > with the possibilities of having access to the source code for > both the client and server (particularly in situations when > the SL server should also be some other type of server). > > Though OpenSL isn't much at the moment, we are approaching the > point where we plan to try OpenSL servers for some very simple > projects. However, some colleagues disagree that we should > consider OpenSL, claiming they are reverse-engineering Second > Life's message protocols and that having the potential for > hosting "free" Second Life servers is a threat to Linden Labs > so Linden Labs will either shut down OpenSL or release client > versions that render OpenSL unusable. > > While I don't know Linden Labs opinion on the subject, I would > think that such claims don't amount to much. Releasing a > client version that renders OpenSL unusable can't really > happen because the client is open source so it's a trivial > matter to remove the code that prevents interoperability. > However, shutting down OpenSL I see as conceivable but > unlikely; the OpenSL server is so crippled that one would need > very specific reasons as to why it would be desirable to use > it, and Linden Labs hasn't taken action yet. I simply don't > see Linden Labs as considering this to be a threat, > particularly considering their substantial existing userbase > and that my understanding is that they've been toying with the > idea of releasing the server code outright themselves for some > time already. > > Still, my colleagues and I would be very interested in hearing > Linden Labs direction in dealing with those involved in > developing 3rd party Second Life server frameworks. > > ~Squash Otoro > > As others have pointed out, we are working with OpenSim (along > with other people) in the AWG groups on standards of > interoperability. >From the wiki page: > "AWG's mission is to develop the protocols that will open up the > Second Life Grid from something operated solely by Linden Lab to > where others can run parts of the grid." > I think someone linked it already, but more info on AWG here: > https://wiki.secondlife.com/wiki/Architecture_Working_Group > > I am sure the AWG group, and myself personally, would be > interested in any reasoning for using OpenSim over SL - what you > mean by "when the SL server should also be some other type of > server" etc. Your requirements probably aren't entirely unique > and I'm sure the group could benefit from hearing them. > > As for OpenSim specifically, we don't have the means to block > access to them (due to the open source client as mentioned), nor > do I think we have the desire to. I can't offer any official > statement about OpenSim or our future interactions with them, but > I think our work with AWG speaks clearly towards our intent. > > - Kelly > > > ------------------------------------------------------------------------ > i?m is proud to present Cause Effect, a series about real people > making a difference. Learn more > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Wed Dec 12 12:18:28 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Dec 12 12:13:14 2007 Subject: [sldev] [VWR] Cannot login under valgrind In-Reply-To: <1197441380.5470.22.camel@localhost> References: <475F2363.3080909@gmail.com> <1197441380.5470.22.camel@localhost> Message-ID: <47604214.2070000@gmail.com> Callum Lerwick wrote: > Lately I've been having problems with the OpenGL drivers > hanging/crashing, both fglrx and open source r300, so I haven't been > able to get any decent valgrind runs lately, which... sucks. I've been > getting a lot of crashes lately due to glibc detecting heap overruns > again. Argh. Hmm, i've been detecting random crashes in 1.18.6 but not been able to pin point anything. the backtraces are pretty useless (nothing in common with each other and if its heap corruption that prehapse could explain the randomness in the traces, hence my desire to run valgrind on the 1.18.6 code base Robin -------------- 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/20071212/0ad8d593/signature.pgp From sllists at boroon.dasgupta.ch Wed Dec 12 12:54:01 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Wed Dec 12 12:54:15 2007 Subject: OpenCroquet (was: Re: [sldev] [POLICY] OpenSL considered harmful?) In-Reply-To: References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> <475EC3ED.2080602@lindenlab.com> Message-ID: <47604A69.9010903@boroon.dasgupta.ch> Joshy Squashy schrieb: > Thank you for your responses, Kelly Linden. Always nice to hear right > from the source. :) > > Q: "What you mean by 'when the SL server should also be some other > type of server' etc" > A: Arbitrary server -- web, file, or other type of server. But a > better answer might be to give a (albeit somewhat contrived) specific > workflow I envision. I guess imagine a virtual file server. Using > the open-source viewer and open-source viewer code, you could create a > prims to represent viewer-uploaded files like personal videos, > documents, and such. For example, I could create a prim shaped like a > video cassette, texture with a label like a wedding dress, and upload > a file "My Wedding Video.mov". When someone else sees the virtual > video cassette, they could click it, and the custom server code would > know to check the location where it stored the uploaded video and send > it to the user. > > Or one could envision a virtual library where users create "book" > prims, texture the prims like their corresponding books, upload the > e-book to their custom OpenSim server via an interface in their custom > Second Life viewer, and then we would host a virtual library of > e-books. User's could login to the virtual library server and click > the book they want to read, and the server would send the e-book, and > perhaps then the custom client would have a built-in reader for > opening the e-book. Hi Joshy I might be wrong, but from what I read about OpenCroquet, it seems quite possible you can implement scenarios like these two within their concept, probably even without having to modify the software. See http://www.opencroquet.org/ Be aware, however, that Croquet is some quite different animal than are Second Life and OpenSim, so many SL-ish features like e.g. an inworld economy or a permission management system are missing. cheers Boroondas From odysseus654 at gmail.com Wed Dec 12 13:37:18 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Wed Dec 12 13:37:23 2007 Subject: OpenCroquet (was: Re: [sldev] [POLICY] OpenSL considered harmful?) In-Reply-To: <47604A69.9010903@boroon.dasgupta.ch> References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> <475EC3ED.2080602@lindenlab.com> <47604A69.9010903@boroon.dasgupta.ch> Message-ID: <1674f6c70712121337l5035b0a8gbba53585cdd95abb@mail.gmail.com> OpenCroquet looks on the surface to be *much* more flexible than SecondLife for custom software and worlds where you need more flexibility than the normal resident has in building. However, anyone going into Croquet expecting to create new builds like they can in SecondLife is going to run rather hard into a wall of "huh?"s. I am rather excited about the Croquet project and its potential, however unfortunately at this point it is more of a programmer's API than an end-user interface if you are moving beyond what the demo worlds provide. On Dec 12, 2007 12:54 PM, Boroondas Gupte wrote: > I might be wrong, but from what I read about OpenCroquet, it seems quite > possible you can implement scenarios like these two within their > concept, probably even without having to modify the software. See > http://www.opencroquet.org/ > > Be aware, however, that Croquet is some quite different animal than are > Second Life and OpenSim, so many SL-ish features like e.g. an inworld > economy or a permission management system are missing. > > cheers > Boroondas > _______________________________________________ > 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/20071212/457dc2eb/attachment.htm From lenglish5 at cox.net Wed Dec 12 16:44:18 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Dec 12 16:44:22 2007 Subject: [sldev] Re: OpenCroquet In-Reply-To: <1674f6c70712121337l5035b0a8gbba53585cdd95abb@mail.gmail.com> References: <20071210200011.062DD41B2A9@stupor.lindenlab.com> <475EC3ED.2080602@lindenlab.com> <47604A69.9010903@boroon.dasgupta.ch> <1674f6c70712121337l5035b0a8gbba53585cdd95abb@mail.gmail.com> Message-ID: <47608062.6020808@cox.net> Erik Anderson wrote: > OpenCroquet looks on the surface to be *much* more flexible than > SecondLife for custom software and worlds where you need more > flexibility than the normal resident has in building. However, anyone > going into Croquet expecting to create new builds like they can in > SecondLife is going to run rather hard into a wall of "huh?"s. I am > rather excited about the Croquet project and its potential, however > unfortunately at this point it is more of a programmer's API than an > end-user interface if you are moving beyond what the demo worlds provide. Last time I checked, it was virtually (sorry) impossible to log into a virtual world from a Mac via the internet unless it was the example internet server. On the other hand, if you're an educational researcher with a LAN, and bunches of PC's, its probably pretty cool to work with. Lawson From anthony at lindenlab.com Wed Dec 12 17:17:21 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Wed Dec 12 17:17:30 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.1 In-Reply-To: <474B55B5.2050704@lindenlab.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> Message-ID: <47608821.2030805@lindenlab.com> Hey everyone, Release Candidate day. Soft was gracious enough to do the double checking on making sure this builds from the open source, so any issues should be edge cases. RC-1.18.6.1 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.1 Release note information here: http://blog.secondlife.com/2007/12/12/updated-release-candidate-viewer-second-life-1186-rc1-available-today/ Checksums: 1c6c8f500ebdde81dcd653445eef16c5 slviewer-darwin-libs-RC-1.18.6.1.tar.gz 7a1b89d7e8bafc862a1e7a5694d82a18 slviewer-linux-libs-RC-1.18.6.1.tar.gz 9277c9681558287e6011dbaf2228ce7e slviewer-src-RC-1.18.6.1.tar.gz 755cfd46c37f8d65cbba59013c1e3928 slviewer-artwork-RC-1.18.6.1.zip 9b20402a8d706b4796159f782bc49932 slviewer-src-RC-1.18.6.1.zip f00136a06de0d21902bd25d192275e7e slviewer-win32-libs-RC-1.18.6.1.zip SVN checkout: will be posted by rob. Enjoy. -Anthony From soft at lindenlab.com Wed Dec 12 18:02:35 2007 From: soft at lindenlab.com (Soft) Date: Wed Dec 12 18:02:37 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.1 In-Reply-To: <47608821.2030805@lindenlab.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> Message-ID: On 12/12/07, Anthony Foster wrote: > Hey everyone, > > Release Candidate day. Soft was gracious enough to do the double > checking on making sure this builds from the open source, so any issues > should be edge cases. > > RC-1.18.6.1 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.1 > > Release note information here: > http://blog.secondlife.com/2007/12/12/updated-release-candidate-viewer-second-life-1186-rc1-available-today/ > > Checksums: > > 1c6c8f500ebdde81dcd653445eef16c5 slviewer-darwin-libs-RC-1.18.6.1.tar.gz > 7a1b89d7e8bafc862a1e7a5694d82a18 slviewer-linux-libs-RC-1.18.6.1.tar.gz > 9277c9681558287e6011dbaf2228ce7e slviewer-src-RC-1.18.6.1.tar.gz > 755cfd46c37f8d65cbba59013c1e3928 slviewer-artwork-RC-1.18.6.1.zip > 9b20402a8d706b4796159f782bc49932 slviewer-src-RC-1.18.6.1.zip > f00136a06de0d21902bd25d192275e7e slviewer-win32-libs-RC-1.18.6.1.zip > > > SVN checkout: will be posted by rob. For VS2003, XCode and 32-bit Linux: File a JIRA, then raise a stink if it doesn't build with our specified libraries, and I'll look into it or find someone who can. Please assume this going forward. This one's tested on all three again, and we'll nail other platforms/compilers after cmake. Would anyone be willing to own cleaning up each of the platforms' wiki building howtos? A lot of steps like copying DLLs around shouldn't be needed anymore. If you see steps you still have to do that seem silly, let me know that too. From xotmid at gmail.com Wed Dec 12 18:39:55 2007 From: xotmid at gmail.com (Brandon Husbands) Date: Wed Dec 12 18:40:00 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.1 In-Reply-To: References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> Message-ID: I successfully compiled on Xp using Visual Studio 2008 On Dec 12, 2007 8:02 PM, Soft wrote: > On 12/12/07, Anthony Foster wrote: > > Hey everyone, > > > > Release Candidate day. Soft was gracious enough to do the double > > checking on making sure this builds from the open source, so any issues > > should be edge cases. > > > > RC-1.18.6.1 source release available here: > > https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.1 > > > > Release note information here: > > > http://blog.secondlife.com/2007/12/12/updated-release-candidate-viewer-second-life-1186-rc1-available-today/ > > > > Checksums: > > > > 1c6c8f500ebdde81dcd653445eef16c5 > slviewer-darwin-libs-RC-1.18.6.1.tar.gz > > 7a1b89d7e8bafc862a1e7a5694d82a18 slviewer-linux-libs-RC-1.18.6.1.tar.gz > > 9277c9681558287e6011dbaf2228ce7e slviewer-src-RC-1.18.6.1.tar.gz > > 755cfd46c37f8d65cbba59013c1e3928 slviewer-artwork-RC-1.18.6.1.zip > > 9b20402a8d706b4796159f782bc49932 slviewer-src-RC-1.18.6.1.zip > > f00136a06de0d21902bd25d192275e7e slviewer-win32-libs-RC-1.18.6.1.zip > > > > > > SVN checkout: will be posted by rob. > > For VS2003, XCode and 32-bit Linux: File a JIRA, then raise a stink if > it doesn't build with our specified libraries, and I'll look into it > or find someone who can. Please assume this going forward. This one's > tested on all three again, and we'll nail other platforms/compilers > after cmake. > > Would anyone be willing to own cleaning up each of the platforms' wiki > building howtos? A lot of steps like copying DLLs around shouldn't be > needed anymore. If you see steps you still have to do that seem silly, > let me know that too. > _______________________________________________ > 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/20071212/7c3dccb4/attachment.htm From nikki at cf-estates.com Wed Dec 12 18:47:54 2007 From: nikki at cf-estates.com (nikki@cf-estates.com) Date: Wed Dec 12 18:48:58 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.1 In-Reply-To: References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> Message-ID: <20071212184754.nnvvjr1v4so0sk4g@66.152.166.10> Success on XP using VS2005 nice to see the conversion step is gone. However I still have to address this build error. 4>LINK : fatal error LNK1181: cannot open input file 'EZ_LCD_Wrapper_vc8.lib' The solution is to rename 'EZ_LCD_Wrapper_vc8.lib' to 'EZ_LCD_Wrapper_vc8.lib' but I think it meets Soft's criteria for a 'silly' step. Speaking of silly steps changing the startup object to 'newview' is another little step that needs done every time. Quoting Brandon Husbands : > I successfully compiled on Xp using Visual Studio 2008 > > On Dec 12, 2007 8:02 PM, Soft wrote: > >> On 12/12/07, Anthony Foster wrote: >> > Hey everyone, >> > >> > Release Candidate day. Soft was gracious enough to do the double >> > checking on making sure this builds from the open source, so any issues >> > should be edge cases. >> > >> > RC-1.18.6.1 source release available here: >> > https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.1 >> > >> > Release note information here: >> > >> http://blog.secondlife.com/2007/12/12/updated-release-candidate-viewer-second-life-1186-rc1-available-today/ >> > >> > Checksums: >> > >> > 1c6c8f500ebdde81dcd653445eef16c5 >> slviewer-darwin-libs-RC-1.18.6.1.tar.gz >> > 7a1b89d7e8bafc862a1e7a5694d82a18 slviewer-linux-libs-RC-1.18.6.1.tar.gz >> > 9277c9681558287e6011dbaf2228ce7e slviewer-src-RC-1.18.6.1.tar.gz >> > 755cfd46c37f8d65cbba59013c1e3928 slviewer-artwork-RC-1.18.6.1.zip >> > 9b20402a8d706b4796159f782bc49932 slviewer-src-RC-1.18.6.1.zip >> > f00136a06de0d21902bd25d192275e7e slviewer-win32-libs-RC-1.18.6.1.zip >> > >> > >> > SVN checkout: will be posted by rob. >> >> For VS2003, XCode and 32-bit Linux: File a JIRA, then raise a stink if >> it doesn't build with our specified libraries, and I'll look into it >> or find someone who can. Please assume this going forward. This one's >> tested on all three again, and we'll nail other platforms/compilers >> after cmake. >> >> Would anyone be willing to own cleaning up each of the platforms' wiki >> building howtos? A lot of steps like copying DLLs around shouldn't be >> needed anymore. If you see steps you still have to do that seem silly, >> let me know that too. >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > From soft at lindenlab.com Wed Dec 12 20:48:44 2007 From: soft at lindenlab.com (Soft) Date: Wed Dec 12 20:48:46 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.1 In-Reply-To: <20071212184754.nnvvjr1v4so0sk4g@66.152.166.10> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <20071212184754.nnvvjr1v4so0sk4g@66.152.166.10> Message-ID: On 12/12/07, nikki@cf-estates.com wrote: > > Speaking of silly steps changing the startup object to 'newview' is > another little step that needs done every time. Anyone know where the default project is set? AFAIK, it's a local setting. I'm not sure how to change the default without moving a project to the top of the project file, which VS will rearrange again later. From rdw at lindenlab.com Wed Dec 12 23:05:13 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Wed Dec 12 23:05:19 2007 Subject: [sldev] Certified HTTP (and Escrow!) Project Update Dec 12 Message-ID: <4760D9A9.3070007@lindenlab.com> Last week I declared that Certified HTTP would be done enough to start working on The Escrow, and it was! Here are some of the things we did for The Escrow in this past week: - Talked through some more use cases and decided that there were few enough exceptions to the "shuffle" model that we should go ahead with it. - Wrote up the first working version of the escrow, which even at this early stage succeeds in the face of multiple failures of every party in the transaction. - Wrote some sample escrow plugin resources: NoCopyObject and "Vics" (valueless inworld currency, get it?). This doesn't mean that development on Certified HTTP has stopped, quite the contrary in fact, as we've accomplished these tasks in the past week: - Fixed a rather tricky bug in saranwrap.py that was interfering with our database adapter. It turns out that even cooperatively-yielding coroutines can sometimes violate assumptions of sequentiality. - Added the beginnings of a monitoring/failure analysis framework that will eventually allow an operator to debug and undo failed transactions via a web application. In the coming week I'm expecting us to do a code cleanup pass, hew even more closely to the Certified HTTP spec in terms of client/server behavior, add Escrow tests that make many simultaneous transactions, give even more life to the monitoring infrastructure, and and add a few more example plugins so that we can do more interesting transactions. I'll be out on vacation starting the 19th, and I'll see you all back again on the 31st. -RYaN From nicholaz at blueflash.cc Thu Dec 13 01:04:41 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Dec 13 01:05:00 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.1 In-Reply-To: References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <20071212184754.nnvvjr1v4so0sk4g@66.152.166.10> Message-ID: <4760F5A9.1000706@blueflash.cc> Soft wrote: > On 12/12/07, nikki@cf-estates.com wrote: >> Speaking of silly steps changing the startup object to 'newview' is >> another little step that needs done every time. > > Anyone know where the default project is set? AFAIK, it's a local > setting. I'm not sure how to change the default without moving a > project to the top of the project file, which VS will rearrange again > later. That is local (as well as the debug command line arguments and similar). I would vote to keep it as it is because the efforts for the solution (if possible) will far outweight the benefit. But if you are at it, a minor nuisance for me which can be fixed is the missing "mv" statement in indra.y in the debug configration: - script-compile-fb - indra.y - properties - build step for debug needs an C:\cygwin\bin\mv.exe ytab.hpp ytab.h (like the release step) If you want to cleanup the project (not sure if it's worth bothering) with cmake coming, see the "Optional Steps" for VS2005 conversion, (https://wiki.secondlife.com/wiki/Converting_project_files_for_MSVS2005) they apply to VS2003 all the same (except the first). Nick From xotmid at gmail.com Thu Dec 13 05:50:10 2007 From: xotmid at gmail.com (Brandon Husbands) Date: Thu Dec 13 05:50:18 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.1 In-Reply-To: References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> Message-ID: On vs2008 i needed to Borrow the alg... file from vs 2005. Its a known bug which is being fixed next vs update. On Dec 12, 2007 8:39 PM, Brandon Husbands wrote: > I successfully compiled on Xp using Visual Studio 2008 > > > On Dec 12, 2007 8:02 PM, Soft wrote: > > > On 12/12/07, Anthony Foster wrote: > > > Hey everyone, > > > > > > Release Candidate day. Soft was gracious enough to do the double > > > checking on making sure this builds from the open source, so any > > issues > > > should be edge cases. > > > > > > RC-1.18.6.1 source release available here: > > > https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.1 > > > > > > Release note information here: > > > > > http://blog.secondlife.com/2007/12/12/updated-release-candidate-viewer-second-life-1186-rc1-available-today/ > > > > > > Checksums: > > > > > > 1c6c8f500ebdde81dcd653445eef16c5 > > slviewer-darwin-libs-RC-1.18.6.1.tar.gz > > > 7a1b89d7e8bafc862a1e7a5694d82a18 > > slviewer-linux-libs-RC-1.18.6.1.tar.gz > > > 9277c9681558287e6011dbaf2228ce7e slviewer-src-RC-1.18.6.1.tar.gz > > > 755cfd46c37f8d65cbba59013c1e3928 slviewer-artwork-RC-1.18.6.1.zip > > > 9b20402a8d706b4796159f782bc49932 slviewer-src-RC-1.18.6.1.zip > > > f00136a06de0d21902bd25d192275e7e slviewer-win32-libs-RC-1.18.6.1.zip > > > > > > > > > SVN checkout: will be posted by rob. > > > > For VS2003, XCode and 32-bit Linux: File a JIRA, then raise a stink if > > it doesn't build with our specified libraries, and I'll look into it > > or find someone who can. Please assume this going forward. This one's > > tested on all three again, and we'll nail other platforms/compilers > > after cmake. > > > > Would anyone be willing to own cleaning up each of the platforms' wiki > > building howtos? A lot of steps like copying DLLs around shouldn't be > > needed anymore. If you see steps you still have to do that seem silly, > > let me know that too. > > _______________________________________________ > > 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/20071213/682ade5f/attachment.htm From porsupah at ringtail.com Thu Dec 13 19:14:25 2007 From: porsupah at ringtail.com (Porsupah) Date: Thu Dec 13 19:14:54 2007 Subject: [sldev] QuickTime 7.3.1 out - RTSP bug fixed? Message-ID: <7CBC56EE-4B5E-4179-9E34-F97449EE45DB@ringtail.com> notes the particular fixes included. Pertinent to SL would appear to be this one: > CVE-ID: CVE-2007-6166 > > Available for: Mac OS X v10.3.9, Mac OS X v10.4.9 or later, Mac OS X > v10.5 or later, Windows Vista, XP SP2 > > Impact: Viewing a maliciously crafted RTSP movie may lead to an > unexpected application termination or arbitrary code execution > > Description: A buffer overflow exists in QuickTime's handling of > Real Time Streaming Protocol (RTSP) headers. By enticing a user to > view a maliciously crafted RTSP movie, an attacker may cause an > unexpected application termination or arbitrary code execution. This > update addresses the issue by ensuring that the destination buffer > is sized to contain the data. > If someone could verify this solves the recent QT-in-SL security issue, I'm sure we'd all be thankful. QT7.3.1 is now available via Software Update for OS X, or as a standalone installer for Panther, Tiger, Leopard, XP, and Vista from: -- Porsupah From alexander.treptow at zweitgeist.com Fri Dec 14 07:34:46 2007 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Fri Dec 14 07:35:02 2007 Subject: [sldev] Predefined animations Message-ID: <4762A296.5090907@zweitgeist.com> Hi, does anyone knows where to find the predefined animations, like walk, clap, cheer and so on? Are they in the viewer source or do i get them from server. If i only get them from server, how can i create my own predefined animations in C code or how can i run LSL code in the viewer without notifying the server. greets, Alex From robin.cornelius at gmail.com Fri Dec 14 07:47:20 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri Dec 14 07:47:28 2007 Subject: [sldev] Predefined animations In-Reply-To: <4762A296.5090907@zweitgeist.com> References: <4762A296.5090907@zweitgeist.com> Message-ID: On Dec 14, 2007 3:34 PM, alexander treptow wrote: > Hi, > does anyone knows where to find the predefined animations, like walk, > clap, cheer and so on? Are they in the viewer source or do i get them > from server. > They are assets on the server in the same way textures and sound files are. Some default assets are included in the artwork bundle. Not sure which ones but there is a good chance some default anims are there too which would save them being downloaded for every viewer. > If i only get them from server, how can i create my own predefined > animations in C code or how can i run LSL code in the viewer without > notifying the server. What do you want to do, are you attempting to test animations on real avatars before uploading? if so use the beta grid. Why do you not want to notify the server? You can't really create new predefined animations because if you hack that only you would see it. You can override any of the default animations in world with appropriate script and animations to hand. Robin From lenglish5 at cox.net Fri Dec 14 09:06:11 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Dec 14 09:06:13 2007 Subject: [sldev] Predefined animations In-Reply-To: References: <4762A296.5090907@zweitgeist.com> Message-ID: <4762B803.1060003@cox.net> Robin Cornelius wrote: > On Dec 14, 2007 3:34 PM, alexander treptow > wrote: > >> Hi, >> does anyone knows where to find the predefined animations, like walk, >> clap, cheer and so on? Are they in the viewer source or do i get them >> from server. >> >> > > They are assets on the server in the same way textures and sound files are. > > Some default assets are included in the artwork bundle. Not sure which > ones but there is a good chance some default anims are there too which > would save them being downloaded for every viewer. > > >> If i only get them from server, how can i create my own predefined >> animations in C code or how can i run LSL code in the viewer without >> notifying the server. >> > > What do you want to do, are you attempting to test animations on real > avatars before uploading? if so use the beta grid. Why do you not want > to notify the server? > > You can't really create new predefined animations because if you hack > that only you would see it. You can override any of the default > animations in world with appropriate script and animations to hand. > > > > Robin > In the long run, I can see a need for a hybrid quasi-in-world animation editor to complement the existing appearance editor (which also needs to be updated). In fact, I can see a long-term need for a quasi-in-world editing system to complement ALL current editing systems, including build, appearance, animation, etc. Such a system would use a private 3D world that would be merged with the "real" 3D scene graph in the viewer and allow client-side editing of any and all aspects of the system, from prims and sculpties to gestures and animation, even sound. The editing would be performed client-side at full speed with full manipulation and control mechanisms for a normal external editor for such data, and would not post the update to the normal sim server until the user was satisfied with the appearance/behavior of whatever he was manipulating to allow for the highest level of editing-control. Such a system is impossible to create using the current client, but that situation will hopefully change relatively soon, as the modular client project of the AW Groupies matures. https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft Lawson From tateru.nino at gmail.com Fri Dec 14 09:10:03 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Dec 14 09:10:48 2007 Subject: [sldev] Predefined animations In-Reply-To: <4762B803.1060003@cox.net> References: <4762A296.5090907@zweitgeist.com> <4762B803.1060003@cox.net> Message-ID: <4762B8EB.3020707@gmail.com> Lawson English wrote: > Robin Cornelius wrote: >> On Dec 14, 2007 3:34 PM, alexander treptow >> wrote: >> >>> Hi, >>> does anyone knows where to find the predefined animations, like walk, >>> clap, cheer and so on? Are they in the viewer source or do i get them >>> from server. >>> >>> >> >> They are assets on the server in the same way textures and sound >> files are. >> >> Some default assets are included in the artwork bundle. Not sure which >> ones but there is a good chance some default anims are there too which >> would save them being downloaded for every viewer. >> >> >>> If i only get them from server, how can i create my own predefined >>> animations in C code or how can i run LSL code in the viewer without >>> notifying the server. >>> >> >> What do you want to do, are you attempting to test animations on real >> avatars before uploading? if so use the beta grid. Why do you not want >> to notify the server? >> >> You can't really create new predefined animations because if you hack >> that only you would see it. You can override any of the default >> animations in world with appropriate script and animations to hand. >> >> >> >> Robin >> > In the long run, I can see a need for a hybrid quasi-in-world > animation editor to complement the existing appearance editor (which > also needs to be updated). > > In fact, I can see a long-term need for a quasi-in-world editing > system to complement ALL current editing systems, including build, > appearance, animation, etc. > > Such a system would use a private 3D world that would be merged with > the "real" 3D scene graph in the viewer and allow client-side editing > of any and all aspects of the system, from prims and sculpties to > gestures and animation, even sound. The editing would be performed > client-side at full speed with full manipulation and control > mechanisms for a normal external editor for such data, and would not > post the update to the normal sim server until the user was satisfied > with the appearance/behavior of whatever he was manipulating to allow > for the highest level of editing-control. > > Such a system is impossible to create using the current client, but > that situation will hopefully change relatively soon, as the modular > client project of the AW Groupies matures. > > https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft > > Lawson > Is there not already a hybrid quasi-in-world animation system getting comparatively close to completion, using Endorphin, et al? I think the major blocker on that is Havok. -- Tateru Nino http://dwellonit.blogspot.com/ From lenglish5 at cox.net Fri Dec 14 09:20:02 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Dec 14 09:20:05 2007 Subject: [sldev] Predefined animations In-Reply-To: <4762B8EB.3020707@gmail.com> References: <4762A296.5090907@zweitgeist.com> <4762B803.1060003@cox.net> <4762B8EB.3020707@gmail.com> Message-ID: <4762BB42.2050504@cox.net> Tateru Nino wrote: > Lawson English wrote: > >> Robin Cornelius wrote: >> >>> On Dec 14, 2007 3:34 PM, alexander treptow >>> wrote: >>> >>> >>>> Hi, >>>> does anyone knows where to find the predefined animations, like walk, >>>> clap, cheer and so on? Are they in the viewer source or do i get them >>>> from server. >>>> >>>> >>>> >>> They are assets on the server in the same way textures and sound >>> files are. >>> >>> Some default assets are included in the artwork bundle. Not sure which >>> ones but there is a good chance some default anims are there too which >>> would save them being downloaded for every viewer. >>> >>> >>> >>>> If i only get them from server, how can i create my own predefined >>>> animations in C code or how can i run LSL code in the viewer without >>>> notifying the server. >>>> >>>> >>> What do you want to do, are you attempting to test animations on real >>> avatars before uploading? if so use the beta grid. Why do you not want >>> to notify the server? >>> >>> You can't really create new predefined animations because if you hack >>> that only you would see it. You can override any of the default >>> animations in world with appropriate script and animations to hand. >>> >>> >>> >>> Robin >>> >>> >> In the long run, I can see a need for a hybrid quasi-in-world >> animation editor to complement the existing appearance editor (which >> also needs to be updated). >> >> In fact, I can see a long-term need for a quasi-in-world editing >> system to complement ALL current editing systems, including build, >> appearance, animation, etc. >> >> Such a system would use a private 3D world that would be merged with >> the "real" 3D scene graph in the viewer and allow client-side editing >> of any and all aspects of the system, from prims and sculpties to >> gestures and animation, even sound. The editing would be performed >> client-side at full speed with full manipulation and control >> mechanisms for a normal external editor for such data, and would not >> post the update to the normal sim server until the user was satisfied >> with the appearance/behavior of whatever he was manipulating to allow >> for the highest level of editing-control. >> >> Such a system is impossible to create using the current client, but >> that situation will hopefully change relatively soon, as the modular >> client project of the AW Groupies matures. >> >> https://wiki.secondlife.com/wiki/Multi-Process_Client_VAG_--_draft >> >> Lawson >> >> > Is there not already a hybrid quasi-in-world animation system getting > comparatively close to completion, using Endorphin, et al? I think the > major blocker on that is Havok. > > There might be, but I suspect content editors will find more utility once the client is properly factored (not that the modular client described at the URL above is likely to be the proper factoring for such a thing, just that the documentation and libraries associated with it might make designing/creating one or more build-oriented clients much easier). Lawson From donovan at lindenlab.com Fri Dec 14 10:56:18 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Fri Dec 14 10:56:29 2007 Subject: [sldev] help with beta-1 In-Reply-To: <82fa9e310712112208x67b47f85u8d43ffd297f3a8f5@mail.gmail.com> References: <82fa9e310712111443y77154f99gfd80c4cc20bd4865@mail.gmail.com> <82fa9e310712112208x67b47f85u8d43ffd297f3a8f5@mail.gmail.com> Message-ID: <44FEC70E-0A5F-4DFB-9692-35D3D209E53F@lindenlab.com> After some investigation, I discovered that this was a real bug. We never noticed before because every greenlet we started also had a timer started in it, because that's how eventlet.httpd works. The fix: http://svn.secondlife.com/trac/eventlet/changeset/71 Attached is a test file which will exhibit the bug in a revision before 71 but not exhibit bad behavior at revision 71. Donovan On Dec 11, 2007, at 10:08 PM, mark wrote: > On Dec 11, 2007 3:46 PM, Donovan Preston > wrote: > It does look like a genuine bug. Replace the line: > On Dec 11, 2007, at 2:43 PM, mark wrote: > > > i checked out beta-1 version, and I installed greenlet version 0.1 > > from easy_install, > > and i get this error, it freezes.. > > how to fix this? > > > File "/home/mark/work/main/animmes/eventlet/runloop.py", line 218, > > in cancel_timers > > for timer in self.timers_by_greenlet[greenlet]: > > With this: > > for timer in self.timers_by_greenlet.get(greenlet, ()): > > If this turns out to fix it, please open a JIRA issue and submit a > I get this error now: > > Traceback (most recent call last): > File "/home/mark/work/main/animmes/eventlet/pollhub.py", line 170, > in wait > read(fileno) > File "/home/mark/work/main/animmes/eventlet/api.py", line 146, in cb > greenlib.switch(self, fd) > File "/home/mark/work/main/animmes/eventlet/greenlib.py", line > 310, in switch > rval = other.switch(value, exc) > File "/home/mark/work/main/animmes/eventlet/greenlib.py", line > 287, in greenlet_body > return cb(*args) > File "/home/mark/work/main/animmes/eventlet/api.py", line 159, in > _spawn_startup > return cb(*args, **kw) > File "/home/mark/work/main/animmes/eventlet/coros.py", line 113, > in _main_loop > api.get_hub().runloop.cancel_timers(api.getcurrent()) > File "/home/mark/work/main/animmes/eventlet/runloop.py", line 224, > in cancel_timers > del self.timers_by_greenlet[greenlet] > KeyError: < greenlet.greenlet object at 0xb6dbad0> > Removing descriptor: 13 > > > I tried to change this again like the fix you gave, but that gave > another error, so that is not the right thing to do.. > how to fix this? -------------- next part -------------- Skipped content of type multipart/mixed From donovan at lindenlab.com Fri Dec 14 11:01:36 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Fri Dec 14 11:02:08 2007 Subject: [sldev] eventlet/mulib beta-1 are dead, now in trunk Message-ID: When we moved eventlet and mulib into the public svn repository, we branched a beta-1 branch which our internal repositories continued to track. However, this continued for several months, and trunk and beta-1 started to diverge. Since there were useful bug fixes in both, it was impossible to have a checkout that had all known bugfixes. I have now merged beta-1 of both eventlet and mulib back into the respective trunks. Along the way, some bugs were fixed. I also merged my mulib collaborative-editor branch into trunk, for anyone who has been following that development. Donovan From mark at identityserver.net Fri Dec 14 15:11:48 2007 From: mark at identityserver.net (Mark S Andrews) Date: Fri Dec 14 15:12:07 2007 Subject: [sldev] git repository for slviewer Message-ID: <1197673908.28308.29.camel@domino-laptop> I've setup a git repository from the svn and am looking for feedback before I settle on a final layout. I've moved quite a few branches around and renamed things to be more consistent and clearer (to me). You can grab a clone with: git clone git://dominodesigns.info/slviewer.git I wouldn't use it as a base for any development yet as depending on feedback I might end up regenerating it which would break references for pulling updates. It's static at the moment, though it is setup so I can update from svn and the final version will do that at set intervals. New svn branches will still need to be added manually. The git svn doesn't handle branches in sub directories very well. That's one of the reasons I took the opportunity to tidy things up a bit and did the entire layout by hand :) Main things that'll leap out as changed: All linden branches are under origin/svn/ */2007/* branches are generally shoved into the sandbox windlight12 is in as origin/svn/firstlook/windlight I treated vwr2972 as the minor revision so it's at end of branch names rather than beginning. Just noticed "origin/svn/branch/non-voice-1-17-0" should be "origin/svn/branch/1-17-0-non-voice" - I'll fix that, but feel free to point out other errors and dumb mistakes :) I wasn't sure where to put the other windlight branch so it ended up in sandbox.. The changes make things clearer to me, but I'm unsure whether with wider adoption it would just confuse matters when talking about svn branches. Let me know what you think! Mark, AKA Domino Marama From soft at lindenlab.com Sat Dec 15 11:26:20 2007 From: soft at lindenlab.com (Soft) Date: Sat Dec 15 11:26:24 2007 Subject: [sldev] Can not find gl.h In-Reply-To: References: Message-ID: On 12/10/07, Brandon Husbands wrote: > Hey all i am trying to compile and it cant find gl.h I'm assuming you're on Windows if you don't have that. Please see: https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2003%29 This and other compiling questions are answered there. There's a similar page for VS2005. From lenglish5 at cox.net Sun Dec 16 22:48:00 2007 From: lenglish5 at cox.net (Lawson English) Date: Sun Dec 16 22:48:03 2007 Subject: [sldev] quiet list Message-ID: <47661BA0.5090205@cox.net> List seems quiet today... (test) Lawson From seg at haxxed.com Sun Dec 16 23:13:49 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Dec 16 23:13:57 2007 Subject: [sldev] quiet list In-Reply-To: <47661BA0.5090205@cox.net> References: <47661BA0.5090205@cox.net> Message-ID: <1197875630.5869.10.camel@localhost> On Sun, 2007-12-16 at 23:48 -0700, Lawson English wrote: > List seems quiet today... (test) Its Sunday night, and we're nearing the biggest holiday in the western world. Of course its quiet... -------------- 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/20071217/07695571/attachment.pgp From alexander.treptow at zweitgeist.com Mon Dec 17 00:46:39 2007 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Mon Dec 17 00:46:51 2007 Subject: [sldev] Predefined animations In-Reply-To: References: <4762A296.5090907@zweitgeist.com> Message-ID: <4766376F.7040603@zweitgeist.com> Robin Cornelius schrieb: > On Dec 14, 2007 3:34 PM, alexander treptow > wrote: > >> Hi, >> does anyone knows where to find the predefined animations, like walk, >> clap, cheer and so on? Are they in the viewer source or do i get them >> from server. >> >> > > They are assets on the server in the same way textures and sound files are. > > Some default assets are included in the artwork bundle. Not sure which > ones but there is a good chance some default anims are there too which > would save them being downloaded for every viewer. > > >> If i only get them from server, how can i create my own predefined >> animations in C code or how can i run LSL code in the viewer without >> notifying the server. >> > > What do you want to do, are you attempting to test animations on real > avatars before uploading? if so use the beta grid. Why do you not want > to notify the server? > > You can't really create new predefined animations because if you hack > that only you would see it. You can override any of the default > animations in world with appropriate script and animations to hand. > > Thats not the answer i want to hear ^^ I want to generate animated gifs of the avatars without notifying the server, because the avatar shouldn't move and shouldn't get any movement data from the server. Its better to use the beta grid then? greets Alex From alexander.treptow at zweitgeist.com Mon Dec 17 01:10:31 2007 From: alexander.treptow at zweitgeist.com (alexander treptow) Date: Mon Dec 17 01:10:42 2007 Subject: [sldev] Predefined animations In-Reply-To: <002801c83e75$15deae30$6e00a8c0@eaurouge> References: <4762A296.5090907@zweitgeist.com> <002801c83e75$15deae30$6e00a8c0@eaurouge> Message-ID: <47663D07.3010306@zweitgeist.com> Sylvio Deutsch schrieb: > Hi Alex > > Look for Qavimator on the web, it?s a free software developed by SL > users specially to make animations (and poses). You can make them, > upload and use scripts to override the original animations. > > Much easier than working directly with the code. > Thanks i will try that out. Do you know if its possible to run generated animations locally in the viewer, without uploading it to the grid and using scripts to overwrite the default animations? because i dont wanna have any changes to my avatar. greets Alex From robin.cornelius at gmail.com Mon Dec 17 01:19:21 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Dec 17 01:19:24 2007 Subject: [sldev] Predefined animations In-Reply-To: <47663D07.3010306@zweitgeist.com> References: <4762A296.5090907@zweitgeist.com> <002801c83e75$15deae30$6e00a8c0@eaurouge> <47663D07.3010306@zweitgeist.com> Message-ID: On Dec 17, 2007 9:10 AM, alexander treptow wrote: > Sylvio Deutsch schrieb: > > Hi Alex > > > > Look for Qavimator on the web, it?s a free software developed by SL > > users specially to make animations (and poses). You can make them, > > upload and use scripts to override the original animations. > > > > Much easier than working directly with the code. > > > Thanks i will try that out. > Do you know if its possible to run generated animations locally in the > viewer, without uploading it to the grid and using scripts to overwrite > the default animations? because i dont wanna have any changes to my avatar. > If you use the beta grid all changes are beta grid only/temporarily and will not effect the main grid. Also uploading any animations will not cost you anything (but will only exist on the beta grid, you must pay to upload to main grid). If you really don't want to involve the Linden grid at all, run it in your own personal opensim server locally on your machine. Robin From monkowsk at watson.ibm.com Mon Dec 17 12:25:52 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Dec 17 12:26:17 2007 Subject: [sldev] [VWR] Are characters culled during rendering? Message-ID: <4766DB50.1040706@watson.ibm.com> If I go to the Client menu and disable all rendering other than Character, the frame rate seems to depend on the number of avatars on the sim, not the number of avatars in view. Does anyone familiar with the render pipeline know whether character meshes are culled based on visibility? And if so, is it based on the final polygons or on the bounding boxes for the characters? Mike From seg at haxxed.com Mon Dec 17 13:24:31 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 17 13:24:37 2007 Subject: [sldev] [VWR] Compiling 1.18.6.1, standalone build and no llmozlib Message-ID: <1197926671.18986.11.camel@localhost> Okay, so I'm trying to compile 1.18.6.1. Standalone build, and am I the only one compiling without llmozlib anymore? As usual it didn't compile out of the box. I had to hack it like so to get it to compile: --- linden.orig/indra/newview/llpanellogin.cpp 2007-12-12 18:10:06.000000000 -0600 +++ linden.patched/indra/newview/llpanellogin.cpp 2007-12-17 13:05:20.000000000 -0600 @@ -523,11 +523,11 @@ if( !gFocusMgr.getKeyboardFocus() ) { // Grab focus and move cursor to first enabled control - web_browser->setFocus(TRUE); + //web_browser->setFocus(TRUE); } // Make sure that focus always goes here (and use the latest sInstance that was just created) - gFocusMgr.setDefaultKeyboardFocus(web_browser); + //gFocusMgr.setDefaultKeyboardFocus(web_browser); } @@ -554,7 +554,7 @@ if (web_browser) { - web_browser->setAlwaysRefresh(refresh); + //web_browser->setAlwaysRefresh(refresh); } } @@ -669,7 +669,7 @@ #endif // navigate to the "real" page - web_browser->navigateTo( oStr.str() ); + //web_browser->navigateTo( oStr.str() ); } #if LL_LIBXUL_ENABLED Which may or may not have f-ed things up. It compiles, but then at runtime I just get a very snazzy looking "Unable to connect." icon, and no login screen. Is there some way to get the old login screen back, or am I doomed to an eternity of maintaining something that links to gecko? -------------- 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/20071217/6a0c3365/attachment.pgp From secret.argent at gmail.com Mon Dec 17 14:40:31 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Dec 17 14:40:29 2007 Subject: [sldev] [VWR] Compiling 1.18.6.1, standalone build and no llmozlib In-Reply-To: <1197926671.18986.11.camel@localhost> References: <1197926671.18986.11.camel@localhost> Message-ID: <24464F8D-43B5-4F40-9B5E-90FF4B9BA44A@gmail.com> Seems to me like you ought to make sure that web_browser is initialized == 0 and then making these changes... On 2007-12-17, at 15:24, Callum Lerwick wrote: > Okay, so I'm trying to compile 1.18.6.1. Standalone build, and am I > the > only one compiling without llmozlib anymore? > > As usual it didn't compile out of the box. I had to hack it like so to > get it to compile: > > --- linden.orig/indra/newview/llpanellogin.cpp 2007-12-12 > 18:10:06.000000000 -0600 > +++ linden.patched/indra/newview/llpanellogin.cpp 2007-12-17 > 13:05:20.000000000 -0600 > @@ -523,11 +523,11 @@ > > if( web_browser ) > { > if ( !gFocusMgr.getKeyboardFocus() ) > { > // Grab focus and move cursor to first enabled control > web_browser->setFocus(TRUE); > } > > // Make sure that focus always goes here (and use the > latest sInstance that was just created) > gFocusMgr.setDefaultKeyboardFocus(web_browser); > } > } > > > @@ -554,7 +554,7 @@ > > if (web_browser) > { > web_browser->setAlwaysRefresh(refresh); > } > } > > @@ -669,7 +669,7 @@ > #endif > > // navigate to the "real" page > if (web_browser) > { > web_browser->navigateTo( oStr.str() ); > } > } > > #if LL_LIBXUL_ENABLED > Then you'll probably find other places that depend on web_browser. What you may have to do is diff with the last normal release and see if the old code for the login panel has been torched, and pull it back in if needed. Then look at the form it's fetching with gecko and generating a submit of that form from the data in the old login panel. Better now than later. From gigstaggart at gmail.com Mon Dec 17 14:48:02 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Dec 17 14:47:29 2007 Subject: [sldev] [VWR] Are characters culled during rendering? In-Reply-To: <4766DB50.1040706@watson.ibm.com> References: <4766DB50.1040706@watson.ibm.com> Message-ID: <4766FCA2.704@gmail.com> Mike Monkowski wrote: > If I go to the Client menu and disable all rendering other than > Character, the frame rate seems to depend on the number of avatars on > the sim, not the number of avatars in view. Does anyone familiar with > the render pipeline know whether character meshes are culled based on > visibility? And if so, is it based on the final polygons or on the > bounding boxes for the characters? > This all changed drastically in Windlight, if you aren't in the Windlight client, you should start your test over. -Jason From robin.cornelius at gmail.com Mon Dec 17 15:02:56 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon Dec 17 14:57:16 2007 Subject: [sldev] [VWR] Compiling 1.18.6.1, standalone build and no llmozlib In-Reply-To: <1197926671.18986.11.camel@localhost> References: <1197926671.18986.11.camel@localhost> Message-ID: <47670020.9050801@gmail.com> Callum Lerwick wrote: > Okay, so I'm trying to compile 1.18.6.1. Standalone build, and am I the > only one compiling without llmozlib anymore? Looks like your one of the few left > > As usual it didn't compile out of the box. I had to hack it like so to > get it to compile: Yay nothing changes!, i spotted this one on JIRA earlier http://jira.secondlife.com/browse/VWR-3748 > > > Which may or may not have f-ed things up. It compiles, but then at > runtime I just get a very snazzy looking "Unable to connect." icon, and > no login screen. Is there some way to get the old login screen back, or > am I doomed to an eternity of maintaining something that links to gecko? > > Um your going to run into immediate trouble here. If you want the old login screen back you will need to do the following. Import the old llpanellogin.cpp/h as this is the driver for the old login XUI panel. You also need the OLD panel_login.xml. In fact i renamed the files and the class to llpanellegacylogin. This will no longer be initalised correctly so will now sigseg, the networks list is missing as its not defined in the way it was so llviewernetwork will probably need hacking as will llstartup and llappviewer to restore the old initialisation code. I've got to a point but llpanellogin (or in my case llpanellegacylogin.cpp is crashing on me and i can't see why yet. I would love to get the old login screen at least working, i can deal with the data after that myself. A simple hack with curl to post to a hardcoded address and retreive the webkey and you have the new *web* login working with the old xui login page. Robin -------------- 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/20071217/ca0cc2c3/signature.pgp From dzonatas at dzonux.net Mon Dec 17 18:28:40 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Dec 17 18:28:43 2007 Subject: [sldev] Texture cache problematic? Message-ID: <47673058.9050305@dzonux.net> Seems like something changed in the 1.18.5 branch. I know I'm not the only one, but textures just seem to stop rezzing after awhile. People are logging in and out and clearing cache many times a day. Maybe there is a related jira... maybe somebody has found a stepwise repro... it just happens over time. From seg at haxxed.com Mon Dec 17 18:33:51 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 17 18:33:53 2007 Subject: [sldev] [VWR] Compiling 1.18.6.1, standalone build and no llmozlib In-Reply-To: <47670020.9050801@gmail.com> References: <1197926671.18986.11.camel@localhost> <47670020.9050801@gmail.com> Message-ID: <1197945231.18986.29.camel@localhost> On Mon, 2007-12-17 at 23:02 +0000, Robin Cornelius wrote: > Yay nothing changes!, i spotted this one on JIRA earlier > http://jira.secondlife.com/browse/VWR-3748 I went looking for a bug but somehow I missed this one... I just tried that patch. I still don't get a login screen so I'm not sure what the point is. > > Which may or may not have f-ed things up. It compiles, but then at > > runtime I just get a very snazzy looking "Unable to connect." icon, and > > no login screen. Is there some way to get the old login screen back, or > > am I doomed to an eternity of maintaining something that links to gecko? > > Um your going to run into immediate trouble here. > > If you want the old login screen back you will need to do the following. [...] Shiiiiiiiiiiiiiiiiiiiit... Well my plan of ignoring the "new auth" flamewar until it swims up and bites me in the ass has been a resounding success. Before I waste a lot of time on it, 1.18.6 *does* work if you have llmozlib, right? -------------- 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/20071217/e6cd7294/attachment.pgp From gigstaggart at gmail.com Mon Dec 17 19:05:57 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Dec 17 19:05:24 2007 Subject: [sldev] The criminalization of open source Message-ID: <47673915.9040909@gmail.com> I was very disappointed with the Linden Lab response to VWR-1919. For background, James has committed code to remove the ability to get texture UUIDs from the client UI. This caving to the ignorant is tantamount to Firefox removing "Save Image As..." in order to "discourage infringement". It also serves to make open source less legitimate. No open source viewer build is going to cripple this functionality the way Linden Lab has. My point is made by this comment on the bug: "And here is a prime example of why open sourcing the client was a noble failure and exactly why secondlife needs to be closed to unauthorized clients". If Linden Lab is going to cater to the "we want a false sense of security" crowd, it damages the open source community. This is only the tip of the iceberg: 1. Hiding sculptie textures on the UI. 2. Hiding media URLs in the about land box. 3. Having "permissions" on textures in the first place. All these do is create an expectation of protection and a false sense of security. It turns "open source" into the "evil tool of hackers and scammers". The problem here isn't a technical one, it's that Linden Lab seems content allowing the expectation of the users to be unreasonable, and even going as far as supporting their fantasy world by hiding the truth from them. It was this same mismanagement of perceptions and false sense of security that lead to the big copybot outcry. Linden Lab could learn a lesson from that and stop creating these unreasonable expectations. Instead, from the resolution of VWR-1919, it's obvious that nothing was learned. -Jason From jhurliman at wsu.edu Mon Dec 17 19:22:09 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Dec 17 19:24:14 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47673915.9040909@gmail.com> References: <47673915.9040909@gmail.com> Message-ID: <47673CE1.1020703@wsu.edu> Jason Giglio wrote: > I was very disappointed with the Linden Lab response to VWR-1919. For > background, James has committed code to remove the ability to get > texture UUIDs from the client UI. > > This caving to the ignorant is tantamount to Firefox removing "Save > Image As..." in order to "discourage infringement". > > It also serves to make open source less legitimate. No open source > viewer build is going to cripple this functionality the way Linden Lab > has. > > My point is made by this comment on the bug: "And here is a prime > example of why open sourcing the client was a noble failure and > exactly why secondlife needs to be closed to unauthorized clients". > > If Linden Lab is going to cater to the "we want a false sense of > security" crowd, it damages the open source community. > > This is only the tip of the iceberg: > > 1. Hiding sculptie textures on the UI. > 2. Hiding media URLs in the about land box. > 3. Having "permissions" on textures in the first place. > > > All these do is create an expectation of protection and a false sense > of security. It turns "open source" into the "evil tool of hackers > and scammers". > > The problem here isn't a technical one, it's that Linden Lab seems > content allowing the expectation of the users to be unreasonable, and > even going as far as supporting their fantasy world by hiding the > truth from them. > > It was this same mismanagement of perceptions and false sense of > security that lead to the big copybot outcry. Linden Lab could learn > a lesson from that and stop creating these unreasonable expectations. > Instead, from the resolution of VWR-1919, it's obvious that nothing > was learned. > > -Jason Remember to vote on http://jira.secondlife.com/browse/VWR-3835 John From GordonWendt at gmail.com Mon Dec 17 19:51:48 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Dec 17 19:51:50 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47673CE1.1020703@wsu.edu> References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> Message-ID: <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> I agree, and that's why I've been arguing vehemently over this even with Torley against the panic mongering crowd pushing the issue. Unfortunately since they are trying to social engineering it to make it seem like a huge bug (they reversed my change to feature request) based on the fact that they would rather false security LL seems content to pander to their ilk. -G.W. On Dec 17, 2007 10:22 PM, John Hurliman wrote: > Jason Giglio wrote: > > I was very disappointed with the Linden Lab response to VWR-1919. For > > background, James has committed code to remove the ability to get > > texture UUIDs from the client UI. > > > > This caving to the ignorant is tantamount to Firefox removing "Save > > Image As..." in order to "discourage infringement". > > > > It also serves to make open source less legitimate. No open source > > viewer build is going to cripple this functionality the way Linden Lab > > has. > > > > My point is made by this comment on the bug: "And here is a prime > > example of why open sourcing the client was a noble failure and > > exactly why secondlife needs to be closed to unauthorized clients". > > > > If Linden Lab is going to cater to the "we want a false sense of > > security" crowd, it damages the open source community. > > > > This is only the tip of the iceberg: > > > > 1. Hiding sculptie textures on the UI. > > 2. Hiding media URLs in the about land box. > > 3. Having "permissions" on textures in the first place. > > > > > > All these do is create an expectation of protection and a false sense > > of security. It turns "open source" into the "evil tool of hackers > > and scammers". > > > > The problem here isn't a technical one, it's that Linden Lab seems > > content allowing the expectation of the users to be unreasonable, and > > even going as far as supporting their fantasy world by hiding the > > truth from them. > > > > It was this same mismanagement of perceptions and false sense of > > security that lead to the big copybot outcry. Linden Lab could learn > > a lesson from that and stop creating these unreasonable expectations. > > Instead, from the resolution of VWR-1919, it's obvious that nothing > > was learned. > > > > -Jason > > Remember to vote on http://jira.secondlife.com/browse/VWR-3835 > > John > > _______________________________________________ > 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/20071217/c061c3eb/attachment-0001.htm From lenglish5 at cox.net Mon Dec 17 20:05:19 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Dec 17 20:05:22 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> Message-ID: <476746FF.1030102@cox.net> Gordon Wendt wrote: > I agree, and that's why I've been arguing vehemently over this even > with Torley against the panic mongering crowd pushing the issue. > Unfortunately since they are trying to social engineering it to make > it seem like a huge bug (they reversed my change to feature request) > based on the fact that they would rather false security LL seems > content to pander to their ilk. > "The best we can hope for is to provide a way to allow content creators to express their intent to facilitate any legal actions they chose to bring." -- Zha Ewry Do you guys disagree with this concept? That regardless of the technical reality, there is something to be said for providing SOME level of inconvenience for people who wish to copy things outside the boundaries of the creator's intent? Lawson From jessesa at gmail.com Mon Dec 17 20:06:56 2007 From: jessesa at gmail.com (Jesse Barnett) Date: Mon Dec 17 20:06:58 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> Message-ID: Unfortunately Linden Labs DID learn from the Copy Bot fiasco. At first they did try to say that nothing was wrong with a copybot if used correctly. They learned that logic doesn't work as a tool to educate the ignorant masses. People still say shhhhh when you say the word GLIntercept and OMG if someone was to mention OGLE in the forums. Unfortunately the "we want a false sense of security crowd" is a very large, noisy crowd. Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071217/2e556b6a/attachment.htm From gigstaggart at gmail.com Mon Dec 17 20:15:20 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Dec 17 20:14:46 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <476746FF.1030102@cox.net> References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> <476746FF.1030102@cox.net> Message-ID: <47674958.8080707@gmail.com> Lawson English wrote: > "The best we can hope for is to provide a way to allow content creators > to express their intent to facilitate any legal actions they chose to > bring." -- Zha Ewry > > Do you guys disagree with this concept? That regardless of the technical > reality, there is something to be said for providing SOME level of > inconvenience for people who wish to copy things outside the boundaries > of the creator's intent? Please never quote me, if you are going to misinterpret my quote as badly as you just did Zha's. -Jason From gigstaggart at gmail.com Mon Dec 17 20:18:43 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Dec 17 20:18:10 2007 Subject: [sldev] The criminalization of open source In-Reply-To: References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> Message-ID: <47674A23.7050801@gmail.com> Jesse Barnett wrote: > Unfortunately Linden Labs DID learn from the Copy Bot > fiasco. At first they did try to say that nothing was wrong with a copybot if used correctly. > They learned that logic doesn't work as a tool > to educate the ignorant masses. People still say shhhhh when you say the > word GLIntercept and OMG if someone was to mention OGLE in the forums. > Unfortunately the "we want a false sense of security crowd" is a very > large, noisy crowd. The crowd who wanted to make SL into something like the Sims Online was large and noisy too. Their expectations were adjusted. People who are still in a "game" mindset might expect Linden Lab to "stop cheaters". I think that's where some of this comes from. Linden Lab has said in the past they aren't going to get into some silly arms race. They just need to stick to that and not waver, if they want this to be taken seriously as an open platform. -Jason From GordonWendt at gmail.com Mon Dec 17 20:28:04 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Dec 17 20:28:07 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47674A23.7050801@gmail.com> References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> <47674A23.7050801@gmail.com> Message-ID: <493033a70712172028s148f6f44kcab9fa00d1fdf0e3@mail.gmail.com> Well I'm glad I use the Nicholaz edition and although I can't speak for him I'll bet that he either won't implement something like this or if this becomes part of a required update he'll update the rest then revert this part. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071217/c1d71131/attachment.htm From secret.argent at gmail.com Mon Dec 17 20:39:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Dec 17 20:39:04 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47674A23.7050801@gmail.com> References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> <47674A23.7050801@gmail.com> Message-ID: <1EE73AA1-DE05-40B3-928F-4B4F7D312CE8@gmail.com> On 2007-12-17, at 22:18, Jason Giglio wrote: > People who are still in a "game" mindset might expect Linden Lab to > "stop cheaters". I think that's where some of this comes from. > Linden Lab has said in the past they aren't going to get into some > silly arms race. They just need to stick to that and not waver, > if they want this to be taken seriously as an open platform. And, in fact, they haven't gotten into a silly arms race. All they've done is maintain a more or less even level of inconvenience, to make sure that it's clear to someone bypassing the honor system permissions that they're going outside the honor system, which is about all they can do. If you poke the anthill you start getting bit by no-perm sculpty objects and people running copybot detectors that spam you 24/7. If you don't poke the anthill you don't get bit. The bites aren't more than an annoyance, but, damn, I for one can do without 'em. From gigstaggart at gmail.com Mon Dec 17 20:48:25 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Dec 17 20:47:52 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <1EE73AA1-DE05-40B3-928F-4B4F7D312CE8@gmail.com> References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> <47674A23.7050801@gmail.com> <1EE73AA1-DE05-40B3-928F-4B4F7D312CE8@gmail.com> Message-ID: <47675119.5070307@gmail.com> Argent Stonecutter wrote: > If you poke the anthill you start getting bit by no-perm sculpty objects > and people running copybot detectors that spam you 24/7. If you don't > poke the anthill you don't get bit. The bites aren't more than an > annoyance, but, damn, I for one can do without 'em. Those are two very good example of reactions caused by unrealistic expectations. The sculpty one was caused by the client hiding the texture when the object was no-mod; it should never hide the texture. The copybot one is obvious, people had a false expectation of protection, and were struggling to maintain that false security with even more false security. Just because people will buy snake oil doesn't mean it's ethical to sell it to them. -Jason From GordonWendt at gmail.com Mon Dec 17 20:55:01 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon Dec 17 20:55:03 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47675119.5070307@gmail.com> References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> <47674A23.7050801@gmail.com> <1EE73AA1-DE05-40B3-928F-4B4F7D312CE8@gmail.com> <47675119.5070307@gmail.com> Message-ID: <493033a70712172055j743f6a4y196276e8d5da1fe@mail.gmail.com> And yet there are several well known personalities in SL (This is one of those times I really wish I could name names) that seem to get off on selling this type of bullcrap to people though, and LL at best just sits by and lets them and at worse actually gives into the pressure and makes changes because they're loud, they're noisy, there are quite a few of them (proof that idiocy is contagious) and the lindens don't seem to have the time or the energy to actually check these claims out before implementing them, they just go by the numbers and how loud people are shouting. On Dec 17, 2007 11:48 PM, Jason Giglio wrote: > Just because people will buy snake oil doesn't mean it's ethical to sell > it to them. > > -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/20071217/f0fd05a7/attachment.htm From seg at haxxed.com Mon Dec 17 21:23:47 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 17 21:23:50 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47673915.9040909@gmail.com> References: <47673915.9040909@gmail.com> Message-ID: <1197955427.18986.44.camel@localhost> On Mon, 2007-12-17 at 22:05 -0500, Jason Giglio wrote: > I was very disappointed with the Linden Lab response to VWR-1919. For > background, James has committed code to remove the ability to get > texture UUIDs from the client UI. > > This caving to the ignorant is tantamount to Firefox removing "Save > Image As..." in order to "discourage infringement". +1 With you 100% on this. Its is a basic, fundamental law of the internet that if you don't want people to copy it, you DON'T PUT IT ON THE INTERNET. It astounds me that people can't seem to wrap their brains around the fact that SL is not exempt from this law. A million bazillion web sites seem to do just fine, even with all web browsers having a "save as" option. Why should slviewer be exempt from having "save as" too? Oh yeah, because of the toy economy. Making a living from selling object references in a game, is about as solid a business model as making a living off web advertisements was in the late 90s. Its going to come crashing down sooner or later. Enjoy it while you can. I'm sure this post will get me banned from Luskwood again, three months from now. Remember, all this Open Source stuff is really just a front for my evil plan to destroy Luskwood. -------------- 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/20071217/3c3e5666/attachment-0001.pgp From seg at haxxed.com Mon Dec 17 21:31:51 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 17 21:31:52 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47674A23.7050801@gmail.com> References: <47673915.9040909@gmail.com> <47673CE1.1020703@wsu.edu> <493033a70712171951u3c80c6b4u2d91a14b1c4de284@mail.gmail.com> <47674A23.7050801@gmail.com> Message-ID: <1197955911.18986.49.camel@localhost> On Mon, 2007-12-17 at 23:18 -0500, Jason Giglio wrote: > The crowd who wanted to make SL into something like the Sims Online was > large and noisy too. Their expectations were adjusted. I apparently wasn't around for this? Can you fill me in? I also haven't played Sims Online so the comparison means nothing to me... (Remember kids, Second Life is not a game. It is in fact Serious Business.) -------------- 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/20071217/60fdefb1/attachment.pgp From lenglish5 at cox.net Mon Dec 17 23:51:07 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Dec 17 23:51:12 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <1197955427.18986.44.camel@localhost> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> Message-ID: <47677BEB.5050706@cox.net> Callum Lerwick wrote: > On Mon, 2007-12-17 at 22:05 -0500, Jason Giglio wrote: > >> I was very disappointed with the Linden Lab response to VWR-1919. For >> background, James has committed code to remove the ability to get >> texture UUIDs from the client UI. >> >> This caving to the ignorant is tantamount to Firefox removing "Save >> Image As..." in order to "discourage infringement". >> > > +1 > > With you 100% on this. > > Its is a basic, fundamental law of the internet that if you don't want > people to copy it, you DON'T PUT IT ON THE INTERNET. It astounds me that > people can't seem to wrap their brains around the fact that SL is not > exempt from this law. A million bazillion web sites seem to do just > fine, even with all web browsers having a "save as" option. Why should > slviewer be exempt from having "save as" too? > > Oh yeah, because of the toy economy. Making a living from selling object > references in a game, is about as solid a business model as making a > living off web advertisements was in the late 90s. Its going to come > crashing down sooner or later. Enjoy it while you can. > > I'm sure this post will get me banned from Luskwood again, three months > from now. Remember, all this Open Source stuff is really just a front > for my evil plan to destroy Luskwood. > In fact, its no different than an artist or writer selling a CD or DVD with megabytes of copyrighted content. Are you saying that artists and writers shouldn't be allowed to sell eBooks or that games creators can't sue you if you rip textures from the game CD for resale? And, by extension, that DVD copying for resale isn't really a crime because the copying process is so cheap? Lawson From adam at gwala.net Tue Dec 18 00:13:53 2007 From: adam at gwala.net (Adam Frisby) Date: Tue Dec 18 00:14:06 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47677BEB.5050706@cox.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> Message-ID: <47678141.5050204@gwala.net> > In fact, its no different than an artist or writer selling a CD or DVD > with megabytes of copyrighted content. > > Are you saying that artists and writers shouldn't be allowed to sell > eBooks or that games creators can't sue you if you rip textures from the > game CD for resale? > > And, by extension, that DVD copying for resale isn't really a crime > because the copying process is so cheap? > > Lawson That's not what he's saying at all - and you know it. Stop being a smartass. This is about removing functionality for the sake of appeasement to a unrealistic ideal, which frankly is just stupid. Regards, Adam From tao.takashi at googlemail.com Tue Dec 18 00:26:53 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Dec 18 00:26:55 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47673915.9040909@gmail.com> References: <47673915.9040909@gmail.com> Message-ID: <23bbb49e0712180026w4dd4fd81h771566e7048c3eec@mail.gmail.com> On Dec 18, 2007 4:05 AM, Jason Giglio wrote: > I was very disappointed with the Linden Lab response to VWR-1919. For > background, James has committed code to remove the ability to get > texture UUIDs from the client UI. > > This caving to the ignorant is tantamount to Firefox removing "Save > Image As..." in order to "discourage infringement". +1 also from me. This really is just about generating a false sense for security. In the long run it is definitely better to educate the crowd about the potential problems of having data on the internet. I can understand content creators but removing this option is not a solution. It will just come back as boomerang when people ask how this could be copied. It will also weaken the open source movement and 3rd party browsers which might still have this enabled. Well, Jason said it all anyway.. -- Tao -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071218/5d9903ae/attachment.htm From ordinal.malaprop at fastmail.fm Tue Dec 18 00:49:25 2007 From: ordinal.malaprop at fastmail.fm (Ordinal Malaprop) Date: Tue Dec 18 00:49:33 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47678141.5050204@gwala.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> Message-ID: <1197967765.30098.1227154689@webmail.messagingengine.com> On Tue, 18 Dec 2007 16:13:53 +0800, "Adam Frisby" said: > > In fact, its no different than an artist or writer selling a CD or > > DVD with megabytes of copyrighted content. > > > > Are you saying that artists and writers shouldn't be allowed to sell > > eBooks or that games creators can't sue you if you rip textures from > > the game CD for resale? > > > > And, by extension, that DVD copying for resale isn't really a crime > > because the copying process is so cheap? > > > > Lawson > > That's not what he's saying at all - and you know it. Stop being a > smartass. > > This is about removing functionality for the sake of appeasement to a > unrealistic ideal, which frankly is just stupid. > > Regards, > > Adam > It isn't just about that though. When somebody says "if you don't want people to copy it, you DON'T PUT IT ON THE INTERNET" the implication of that is "these people should shut up", their goals have no validity, reinforced by the dismissive references to the "toy economy". It's either that or a tautology; clearly if you don't want people to copy something you should lock it in a box and bury it, certainly not put it on the internet. You know, they won't shut up, all the people concerned that they're wasting their time doing anything in SL if anybody can just rip them off, and LL will continue to listen to them, because (a) there are lots of them and (b) without content people don't come to SL or stay there - and that means skins, dresses, artwork, poofers and so on. Without the "toy economy" none of us would be here talking about it on this list. "This measure is silly and pointless" is very different from "the whole idea of protecting things on the net is silly and pointless (and so is what you do)". From seg at haxxed.com Tue Dec 18 01:32:38 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Dec 18 01:32:40 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <1197967765.30098.1227154689@webmail.messagingengine.com> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> <1197967765.30098.1227154689@webmail.messagingengine.com> Message-ID: <1197970358.18986.68.camel@localhost> On Tue, 2007-12-18 at 08:49 +0000, Ordinal Malaprop wrote: > (b) without content people don't come to SL or stay there - > and that means skins, dresses, artwork, poofers and so on. Without the > "toy economy" none of us would be here talking about it on this list. Am I the only one who goes on Second Life primarily to *socialize* *with* *people*, and not to buy shit? Its the dot com boom all over again, only virtual. The internet is not about mass marketing. Its about connecting people. Social networking. What was the internet's first killer app? It wasn't telnet, and it wasn't FTP. It was email. Second Life is not about virtual mass marketing, its about connecting people. Eventually the whole "get rich quick" fad will die, and "SL 2.0" will arise from its ashes, just like the web. And now I'm starting to sound like Dzonatas or something. :) -------------- 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/20071218/58d93fbb/attachment.pgp From secret.argent at gmail.com Tue Dec 18 01:33:26 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Dec 18 01:33:24 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <1197967765.30098.1227154689@webmail.messagingengine.com> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> <1197967765.30098.1227154689@webmail.messagingengine.com> Message-ID: <98C2B399-2EEE-46B3-9208-04742FED1203@gmail.com> Thanks, Ordinal. This is the key bit. On 2007-12-18, at 02:49, Ordinal Malaprop wrote: > Without the "toy economy" none of us would be here talking about it > on this list. Missing this point is just as bad as missing the original point about the ineffectiveness of DRM. From odysseus654 at gmail.com Tue Dec 18 01:41:59 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Tue Dec 18 01:42:03 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <1197967765.30098.1227154689@webmail.messagingengine.com> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> <1197967765.30098.1227154689@webmail.messagingengine.com> Message-ID: <1674f6c70712180141h46bb69d6tf9a8455ebf6cd042@mail.gmail.com> I'm not entirely certain that I really should be jumping in here, but... I don't really see anything wrong with them removing the UUID from the window title. Yes, it could potentially give people some people a point of "false security", but there are a lot of designers out there that know about GLIntercept and know that their products are not safe from those that want to rip them off. As a part of the whole CopyBot issue LL promised some meta-tags to determine the difference between copied textures and original textures, although I recognize that copying the UUID's doesn't help with this. I have also heard that CopyBot is still floating around on the grid in various places, albiet a lot more underground than before. And you know what? I'm not sure I care. I'm glad that for the most part that the very widely-distributed "information should be free" copybots were killed as the required viewer version got bumped, which raised the bar and limited the population to those with the ability to maintain the code through the viewer changes (and their friends). Sometime eventually I would like to see aspects of copybots come back (it would be nice for clothing stores to simultaneously model 12 changes of clothing on your avatar for instance) One thing to note is that a large part of the "security" in SL is done through the community. Copying a UUID off of a dialog box in an official build of SL is a lot different than sniffing the UUID off of the packetstream or using some other tool to extract it. If I see the UUID publicly available I would have absolutely no qualms on using it, but if it is made more difficult or it is made more obvious that the information is not something that I should be having, I'm gonna be a lot more careful in deciding to retrieve it. I still buy CD's even though I know that I can probably fairly easily and much more cheaply get a digitally perfect copy of every song on it. Am I stupid for choosing instead to buy the CD? Are people stupid for trying to sell it without putting big warning labels stating that the same songs are available on the Internet? The walls of this virtual world are very paper thin when you look at the pieces of wood holding up the back end, the very important yet ephermal concept of virtual asset ownership even more. Yet in many ways it is the glue that holds this world and its economy together. Yes, there are plenty of technical ways to poke holes in the system and yes it is important for people to know that those holes are possible. No, this should not prevent open source applications from existing and doing whatever the heck they think best (I consider Firefox to be a very secure browser and I'm certain that they have plenty of "hidden" attributes in their source code). The idea is more of stating "this is information that you should probably not seek". Whether the user decides to open the door despite that message is left to them. And FWIW I'm running the Nicholaz build :-P On Dec 18, 2007 12:49 AM, Ordinal Malaprop wrote: > > On Tue, 18 Dec 2007 16:13:53 +0800, "Adam Frisby" said: > > > In fact, its no different than an artist or writer selling a CD or > > > DVD with megabytes of copyrighted content. > > > > > > Are you saying that artists and writers shouldn't be allowed to sell > > > eBooks or that games creators can't sue you if you rip textures from > > > the game CD for resale? > > > > > > And, by extension, that DVD copying for resale isn't really a crime > > > because the copying process is so cheap? > > > > > > Lawson > > > > That's not what he's saying at all - and you know it. Stop being a > > smartass. > > > > This is about removing functionality for the sake of appeasement to a > > unrealistic ideal, which frankly is just stupid. > > > > Regards, > > > > Adam > > > > It isn't just about that though. When somebody says "if you don't want > people to copy it, you DON'T PUT IT ON THE INTERNET" the implication of > that is "these people should shut up", their goals have no validity, > reinforced by the dismissive references to the "toy economy". It's > either that or a tautology; clearly if you don't want people to copy > something you should lock it in a box and bury it, certainly not put it > on the internet. > > You know, they won't shut up, all the people concerned that they're > wasting their time doing anything in SL if anybody can just rip them > off, and LL will continue to listen to them, because (a) there are lots > of them and (b) without content people don't come to SL or stay there - > and that means skins, dresses, artwork, poofers and so on. Without the > "toy economy" none of us would be here talking about it on this list. > > "This measure is silly and pointless" is very different from "the whole > idea of protecting things on the net is silly and pointless (and so is > what you do)". > _______________________________________________ > 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/20071218/02d7862f/attachment-0001.htm From nicholaz at blueflash.cc Tue Dec 18 02:40:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Dec 18 02:40:27 2007 Subject: [sldev] [VWR] Compiling 1.18.6.1, standalone build and no llmozlib In-Reply-To: <1197945231.18986.29.camel@localhost> References: <1197926671.18986.11.camel@localhost> <47670020.9050801@gmail.com> <1197945231.18986.29.camel@localhost> Message-ID: <4767A392.9020808@blueflash.cc> Callum Lerwick wrote: >> If you want the old login screen back you will need to do the following. > [...] > > Shiiiiiiiiiiiiiiiiiiiit... > > Well my plan of ignoring the "new auth" flamewar until it swims up and > bites me in the ass has been a resounding success. > > Before I waste a lot of time on it, 1.18.6 *does* work if you have > llmozlib, right? Under Windows it does (dunno about *ix). I've given up building without mozlib because I figured the new login would require it and I didn't yet want to go into reversal mode (again undoing Linden changes) as long as 1.18.5 works. Nick From robin.cornelius at gmail.com Tue Dec 18 02:44:47 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Dec 18 02:44:50 2007 Subject: [sldev] [VWR] Compiling 1.18.6.1, standalone build and no llmozlib In-Reply-To: <1197945231.18986.29.camel@localhost> References: <1197926671.18986.11.camel@localhost> <47670020.9050801@gmail.com> <1197945231.18986.29.camel@localhost> Message-ID: On Dec 18, 2007 2:33 AM, Callum Lerwick wrote: > > Shiiiiiiiiiiiiiiiiiiiit... > > Well my plan of ignoring the "new auth" flamewar until it swims up and > bites me in the ass has been a resounding success. > > Before I waste a lot of time on it, 1.18.6 *does* work if you have > llmozlib, right? > Yea its ok for me on debian i386/amd64 and reports of PPC working. I know you cannot do a xulrunner build in fedora but i have a makefile that should pull a mozilla tree and build llmozlib against it. May need some tidying but it worked not that long ago. I can sent it if its helpful? From nicholaz at blueflash.cc Tue Dec 18 03:54:53 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Dec 18 03:55:08 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47673915.9040909@gmail.com> References: <47673915.9040909@gmail.com> Message-ID: <4767B50D.9010709@blueflash.cc> Actually, just for the record, I will not bother to undo that if the Lindens make that change. My focus has always been performance, stability and usability and I don't see where this change makes a difference in any those areas. It's merely a placeholder for something much bigger, and my life is just too short to enter the arena of political or religious issues in SL. Nick From robin.cornelius at gmail.com Tue Dec 18 04:29:25 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Dec 18 04:29:29 2007 Subject: [sldev] [VWR] Web login without llmozlib Message-ID: Hi Guys, I have been poking this for a week but Seg today reminded me of this earlier with his post. I now have some c code now that does the web logon via curl (which we already use in the viewer).llmozlib is not required I have the code working in a standalone app and I am planning to integrate directly into llstartup. I think its a useful fallback for non mozlib cases? Any thoughts? I can post it if anyone wants it, its *very* dirty ATM but its quite easy to integrate into llstartup.cpp if anyone wants to. The code returns the web key, and this can be stuffed directly into the required parameter for the xmlrpc request Best reagrds Robin From dale at daleglass.net Tue Dec 18 04:49:49 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Dec 18 04:49:59 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <4767B50D.9010709@blueflash.cc> References: <47673915.9040909@gmail.com> <4767B50D.9010709@blueflash.cc> Message-ID: <20071218124949.GA17912@bruno.sbruno> On Tue, Dec 18, 2007 at 12:54:53PM +0100, Nicholaz Beresford wrote: > > Actually, just for the record, I will not bother to undo that if > the Lindens make that change. My focus has always been performance, > stability and usability and I don't see where this change makes a > difference in any those areas. Heh, I was actually considering keeping it in mine. We have different niches here, if your is performance and stability, mine is advanced functionality. Since we're at it, does anybody NEED it back? For practical usage for some purpose, and not as a political statement I mean. > It's merely a placeholder for something much bigger, and my life > is just too short to enter the arena of political or religious > issues in SL. I'm not that interested in politics myself either. My philosophy is that if it's useful, it'd rather keep 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/20071218/e01cfb8c/attachment.pgp From Anders at Arnholm.se Tue Dec 18 05:18:58 2007 From: Anders at Arnholm.se (Anders Arnholm) Date: Tue Dec 18 05:19:18 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <20071218124949.GA17912@bruno.sbruno> References: <47673915.9040909@gmail.com> <4767B50D.9010709@blueflash.cc> <20071218124949.GA17912@bruno.sbruno> Message-ID: <20071218131858.GN28695@arnholm.se> On Tue, Dec 18, 2007 at 01:49:49PM +0100, Dale Glass wrote: > Since we're at it, does anybody NEED it back? For practical usage for > some purpose, and not as a political statement I mean. I used that feature now and then copy UUID for informations boards, not sure if all images that have been for this have had all the needed premissions. Unsing this and tip/info stuff supporting UUID saves a lot of work at the clubs compared to making sure all tip images one get is Copy/Mod/Transfer maybe, so that can be added to the tip/info equipment. / Balp -- o_ Anders Arnholm, HiQ - Consultant o/ /\ anders@arnholm.nu Phone : +46-703-160969 /|_, \\ http://anders.arnholm.nu/ http://www.hiq.se / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071218/7421ea03/attachment.pgp From robin.cornelius at gmail.com Tue Dec 18 05:29:24 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Dec 18 05:29:54 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: Message-ID: On Dec 18, 2007 12:29 PM, Robin Cornelius wrote: > I have the code working in a standalone app and I am planning to > integrate directly into llstartup. I think its a useful fallback for > non mozlib cases? Any thoughts? I can post it if anyone wants it, its > *very* dirty ATM but its quite easy to integrate into llstartup.cpp if > anyone wants to. http://www.byteme.org.uk/uploads/curltest.c Its quick and dirty but you get the key. Robin From sldev at free.fr Tue Dec 18 07:18:58 2007 From: sldev at free.fr (Henri Beauchamp) Date: Tue Dec 18 07:19:10 2007 Subject: [sldev] Sources for FL v1.18.6.75762, please ? Message-ID: <20071218161858.1f9c6d5e.sldev@free.fr> Hello, Could someone please make the FL v1.18.6.75762 sources available on the Wiki ? Thx. From GordonWendt at gmail.com Tue Dec 18 07:46:01 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Dec 18 07:46:12 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <4767B50D.9010709@blueflash.cc> References: <47673915.9040909@gmail.com> <4767B50D.9010709@blueflash.cc> Message-ID: <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> On Dec 18, 2007 6:54 AM, Nicholaz Beresford wrote: > > Actually, just for the record, I will not bother to undo that if > the Lindens make that change. My focus has always been performance, > stability and usability and I don't see where this change makes a > difference in any those areas. > > Nick > I'm really disappointed to hear that Nick considering how great your viewer is you'd just roll over on this, and this does have usability ramifications, if this is taken away from the client side what's next, I've always seen your client tweaks as fixing LL's foibles like the communicate window, you can't say you never get involved if your willing to revert that. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071218/b960eddf/attachment.htm From dzonatas at dzonux.net Tue Dec 18 08:24:51 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 18 08:24:52 2007 Subject: [sldev] [VWR] QA, CHTTP, Compiling 1.18.6.1, standalone build and no llmozlib (to CEO) In-Reply-To: <1197945231.18986.29.camel@localhost> References: <1197926671.18986.11.camel@localhost> <47670020.9050801@gmail.com> <1197945231.18986.29.camel@localhost> Message-ID: <4767F453.6050704@dzonux.net> Merry Christmas! Callum Lerwick wrote: > Before I waste a lot of time on it, 1.18.6 *does* work if you have > llmozlib, right? > https://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Compiling_The_Viewer Of course, that is currently setup just for Windows, and it wouldn't be hard to add GCC support back as before. =) Yes, it works with llmozlib. As for unit testing this, you ever wonder how CHTTP and SCons could work together for QA automation? It seems logical since both are written in python. Would it be to hard to setup a servelet that listens over chttp and makes sure programs compile and features work? It seemed LL was headed that direction whereby making QA easier until... well... *sigh* ... I understand, people don't want to lose their jobs and thus hate automation. I do understand. I learned very well simple little things that could automate a business larger than what LL is now out of existence. I've learned how I get blamed for that even if that wasn't my plan or in the plans at all. (business I was in was notorious for rapid job hires and fires to match disaster recovery needs) I've learned how such blame carries over the years and fucks up my background image (informal background checker love to make mud-slinging reports). I understand how some (well, more then some) employees rather push me to the street over sheer fear that someone like me might automate them out of their job. Alas, I'm practically on the street if it wasn't for some families and friends that realized how unfair I've been treated. I'm not just talking out my ass here (psst... look at the "criminalization of open source" thread). Do realize that there will continually be these QA issues with LL if LL keeps its current business model. It comes down to cost. It costs to wholesale switch like SCons to CMake, but it also costs to maintain either one. It costs even more to spend the time to reinvent the wheel. Somebody, however, tried to justify the time to do it, and that somebody gets is paid and gets to have a happy Christmas with their family. Now, you ask kinda implicitly if compiling without llmozlib is worth it? Good QA question. I'm sure Rosedale would like to know how simple it is to write the test case once and have that tested on each source release. =) At worst, it may take some time to test to test case (look at chttp), but the logic is simple given the tools that LL now uses and the expertise that LL has now. The word also got out that LL wants to hire 10x the amount of QA people. Obviously, it is worthwhile to consider that it is within budget to "test the test case" (to actually write it and automate it) and avoid the cost and agony of hiring and firing 10x the amount of QA people over time -- and the scars it leaves. -- Dz P.S. Callum, your question was at least worth my time to sincerely write this as a solution to the issues we continually face. -- Power to Change the Void From dale at daleglass.net Tue Dec 18 08:38:38 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Dec 18 08:38:44 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> References: <47673915.9040909@gmail.com> <4767B50D.9010709@blueflash.cc> <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> Message-ID: <20071218163838.GA4452@bruno.sbruno> On Tue, Dec 18, 2007 at 10:46:01AM -0500, Gordon Wendt wrote: > I'm really disappointed to hear that Nick considering how great your viewer > is you'd just roll over on this, and this does have usability ramifications, > if this is taken away from the client side what's next, I've always seen > your client tweaks as fixing LL's foibles like the communicate window, you > can't say you never get involved if your willing to revert that. I'm not Nicholaz, but... I don't consider this "rolling over". People simply have different priorities. His thing is performance and stablity, and mine is advanced features. I've been asked a few times if I'd merge Nicholaz's patches, and so far I refused, not because they're not cool, but because I prefer spending time on my own stuff. I do however ocasionally integrate something made by somebody else, like the stereoscopic patch, so long it's in line with my interests. I remember that some time ago Lecina Enigma had this plan to merge our changes in one viewer, but I haven't heard of that for quite some time. In any case, a merge after I update my viewer should have the result you want. Our patch sets should merge cleanly. -------------- 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/20071218/2a0cc9e7/attachment.pgp From secret.argent at gmail.com Tue Dec 18 08:43:55 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Dec 18 08:43:54 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <1197970358.18986.68.camel@localhost> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> <1197967765.30098.1227154689@webmail.messagingengine.com> <1197970358.18986.68.camel@localhost> Message-ID: <47B7BDA2-DC7A-4441-8395-85DC72509907@gmail.com> On 2007-12-18, at 03:32, Callum Lerwick wrote: > Am I the only one who goes on Second Life primarily to *socialize* > *with* *people*, and not to buy shit? What does it matter? It's the people "buying shit" that pay for the places you socialize. Without the people "buying shit" there wouldn't be a Second Life. Or an internet, for that matter, even if a boatload of the stuff people buy on the Internet is only protected by "honor system" DRM. And if you're there to socialize, what does the permissions system cost you? From me at hamncheeseomlet.com Tue Dec 18 08:44:18 2007 From: me at hamncheeseomlet.com (Hamncheese) Date: Tue Dec 18 08:45:00 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> References: <47673915.9040909@gmail.com> <4767B50D.9010709@blueflash.cc> <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> Message-ID: And your email is prime example why he didn't want to get involved although I don't speak for him. I find a quite a bit of irony in this whole discussion because some (not all please) of the very same people that are complaining about their work being ripped off in SL are using a jacked copy of PS, cranking away to jacked music, while they are downloading jacked movies or dvr their latest show so they don't have to watch commercials, zipping up their finished work using a non supported software (either refusing to support software through donations or reinstalling to get rid of nag screens). They want a better, faster and more stable viewer (Nicholaz, Dale's, OnRez, etc) for free not realizing that it takes as much work as creating "creative" content. Ok you get the idea, but no one cares about their own inconsistencies while they are screaming about the percieved threat to their particular income stream. "Irony is nothing more than hypocrisy dressed in a jester's outfit." From ken at electricsheepcompany.com Tue Dec 18 09:08:35 2007 From: ken at electricsheepcompany.com (Ken Railey) Date: Tue Dec 18 09:08:44 2007 Subject: [sldev] viewer crashlogs Message-ID: The crashlog reports are working again. This issue was a result of the EC2 images shifting around. -Ken From brad at lindenlab.com Tue Dec 18 09:10:32 2007 From: brad at lindenlab.com (Brad Kittenbrink) Date: Tue Dec 18 09:09:42 2007 Subject: [sldev] Sources for FL v1.18.6.75762, please ? In-Reply-To: <20071218161858.1f9c6d5e.sldev@free.fr> References: <20071218161858.1f9c6d5e.sldev@free.fr> Message-ID: <4767FF08.8050900@lindenlab.com> Henri Beauchamp wrote: > Hello, > > Could someone please make the FL v1.18.6.75762 sources available on the Wiki ? > > Thx. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > I will be doing this later today. Sorry about the delay. -Brad Linden From GordonWendt at gmail.com Tue Dec 18 09:56:58 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Dec 18 09:57:02 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <000001c8419e$902c7510$6a00a8c0@simplicityxp1> References: <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> <000001c8419e$902c7510$6a00a8c0@simplicityxp1> Message-ID: <493033a70712180956i69839dftddeb67a95f0bebc4@mail.gmail.com> He is a genius and has done more for the viewer than most lindens (even though that's not a very hard task it seems) and I totally understand and accept his position especially since it's his version of the viewer. Maybe this will be the change that makes me get off my butt and work on my own viewer version. On Dec 18, 2007 12:51 PM, Mitch McKenzie wrote: > Interesting debate, but definitely politics and religion, not much about > Dev going on.. I was once chastised for making the mistake of asking about > the QuickTime security breach on this thread.. Not sure why this political > discussion isn't being molested as well.. This is great blog material, not > sure why it's on this thread is all. Although, it is clear to me, that > Nicholaz is a genius for answering the way he did. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071218/c29382c2/attachment.htm From nicholaz at blueflash.cc Tue Dec 18 10:00:31 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Dec 18 10:00:36 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> References: <47673915.9040909@gmail.com> <4767B50D.9010709@blueflash.cc> <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> Message-ID: <47680ABF.2010103@blueflash.cc> Gordon Wendt wrote: > ... and this does have usability ramifications, if this is taken away > from the client side what's next, ... When the "what's next" comes, I'll make a new decision, which is what I have done with every change so far. But as far as I'm concerned, the practical impact of this particular change *right here right now* is zero. Don't get me wrong, I fully accept if others are coming to different conclusions, I'm merely balancing my time investment and priorities and preferences. Nick From GordonWendt at gmail.com Tue Dec 18 10:33:50 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Dec 18 10:33:52 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <476810A3.5000105@lindenlab.com> References: <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> <000001c8419e$902c7510$6a00a8c0@simplicityxp1> <493033a70712180956i69839dftddeb67a95f0bebc4@mail.gmail.com> <476810A3.5000105@lindenlab.com> Message-ID: <493033a70712181033u51d4ac5aj80a3727a9582773b@mail.gmail.com> Rob, I'm not saying LL hasn't done a lot but Nicholaz has admittedly beaten you guys to patching some pretty huge bugs, also please look at my work on the JIRA issues, as a mentor, and as a resident before you accuse me blindly about not wanting to be helpful. On Dec 18, 2007 1:25 PM, Rob Lanphier wrote: > Ummm, I'm all for giving Nicholaz props, but do you have to backhand us > in the process? If you really think so little of us, please leave this > mailing list, which we are operating for people that want to work *with* > us. > > Thanks > Rob > > On 12/18/07 9:56 AM, Gordon Wendt wrote: > > He is a genius and has done more for the viewer than most lindens > > (even though that's not a very hard task it seems) and I totally > > understand and accept his position especially since it's his version > > of the viewer. Maybe this will be the change that makes me get off my > > butt and work on my own viewer version. > > > > On Dec 18, 2007 12:51 PM, Mitch McKenzie > > wrote: > > > > Interesting debate, but definitely politics and religion, not much > > about Dev going on.. I was once chastised for making the mistake > > of asking about the QuickTime security breach on this thread.. Not > > sure why this political discussion isn't being molested as well.. > > This is great blog material, not sure why it's on this thread is > > all. Although, it is clear to me, that Nicholaz is a genius for > > answering the way he did. > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20071218/f97f867b/attachment.htm From GordonWendt at gmail.com Tue Dec 18 10:35:12 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Dec 18 10:35:14 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <493033a70712181033u51d4ac5aj80a3727a9582773b@mail.gmail.com> References: <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> <000001c8419e$902c7510$6a00a8c0@simplicityxp1> <493033a70712180956i69839dftddeb67a95f0bebc4@mail.gmail.com> <476810A3.5000105@lindenlab.com> <493033a70712181033u51d4ac5aj80a3727a9582773b@mail.gmail.com> Message-ID: <493033a70712181035w7d7b98ceo1ccc82d22b79e099@mail.gmail.com> And yes I realize that you originally posted that direct to me however since it's relevant to the current discusison I have put my reply to the list since your constant attacks of anyone who doesn't toe LL's party line on this list are constant and are quite relevant here. On Dec 18, 2007 1:33 PM, Gordon Wendt wrote: > Rob, I'm not saying LL hasn't done a lot but Nicholaz has admittedly > beaten you guys to patching some pretty huge bugs, also please look at my > work on the JIRA issues, as a mentor, and as a resident before you accuse me > blindly about not wanting to be helpful. > > > On Dec 18, 2007 1:25 PM, Rob Lanphier wrote: > > > Ummm, I'm all for giving Nicholaz props, but do you have to backhand us > > in the process? If you really think so little of us, please leave this > > mailing list, which we are operating for people that want to work *with* > > us. > > > > Thanks > > Rob > > > > On 12/18/07 9:56 AM, Gordon Wendt wrote: > > > He is a genius and has done more for the viewer than most lindens > > > (even though that's not a very hard task it seems) and I totally > > > understand and accept his position especially since it's his version > > > of the viewer. Maybe this will be the change that makes me get off my > > > butt and work on my own viewer version. > > > > > > On Dec 18, 2007 12:51 PM, Mitch McKenzie < mitch@mckenzie.ws > > > > wrote: > > > > > > Interesting debate, but definitely politics and religion, not much > > > > > about Dev going on.. I was once chastised for making the mistake > > > of asking about the QuickTime security breach on this thread.. Not > > > sure why this political discussion isn't being molested as well.. > > > This is great blog material, not sure why it's on this thread is > > > all. Although, it is clear to me, that Nicholaz is a genius for > > > answering the way he did. > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > 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/20071218/62e7c19f/attachment-0001.htm From GordonWendt at gmail.com Tue Dec 18 10:38:15 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue Dec 18 10:38:17 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <493033a70712181035w7d7b98ceo1ccc82d22b79e099@mail.gmail.com> References: <493033a70712180746h6d2be125t26c914fe7bb3819b@mail.gmail.com> <000001c8419e$902c7510$6a00a8c0@simplicityxp1> <493033a70712180956i69839dftddeb67a95f0bebc4@mail.gmail.com> <476810A3.5000105@lindenlab.com> <493033a70712181033u51d4ac5aj80a3727a9582773b@mail.gmail.com> <493033a70712181035w7d7b98ceo1ccc82d22b79e099@mail.gmail.com> Message-ID: <493033a70712181038k4d49c630o9f8e5e93adb554de@mail.gmail.com> My apologies for the third post but unfortunately mail doesn't have an edit posts button :) In response to your suggestion that I leave the list I would have unsubscribed some time ago if I didn't A) have a vested interest in keeping track in the development of SL and B) think I had something to add to the discussions here. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071218/2a20e8b5/attachment.htm From bos at lindenlab.com Tue Dec 18 11:12:24 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Dec 18 11:12:37 2007 Subject: [sldev] [VWR] Web login without llmozlib In-Reply-To: References: Message-ID: <47681B98.6080205@lindenlab.com> Robin Cornelius wrote: > Any thoughts? I can post it if anyone wants it, its > *very* dirty ATM but its quite easy to integrate into llstartup.cpp if > anyone wants to. I haven't looked at the code, but I'm definitely interested in this. If you whip it into shape, it will be great to have it incorporated into the regular viewer for people who don't want to link against llmozlib. References: Message-ID: Kudos Man! I'm definitely interested! Nick On 18.12.2007, at 14:29, Robin Cornelius wrote: > On Dec 18, 2007 12:29 PM, Robin Cornelius > wrote: > >> I have the code working in a standalone app and I am planning to >> integrate directly into llstartup. I think its a useful fallback for >> non mozlib cases? Any thoughts? I can post it if anyone wants it, its >> *very* dirty ATM but its quite easy to integrate into >> llstartup.cpp if >> anyone wants to. > > http://www.byteme.org.uk/uploads/curltest.c > > Its quick and dirty but you get the key. > > Robin > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From rdw at lindenlab.com Tue Dec 18 11:36:03 2007 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Tue Dec 18 11:36:36 2007 Subject: [sldev] [VWR] QA, CHTTP, Compiling 1.18.6.1, standalone build and no llmozlib (to CEO) In-Reply-To: <4767F453.6050704@dzonux.net> References: <1197926671.18986.11.camel@localhost> <47670020.9050801@gmail.com> <1197945231.18986.29.camel@localhost> <4767F453.6050704@dzonux.net> Message-ID: <47682123.6010007@lindenlab.com> Dzonatas wrote: > As for unit testing this, you ever wonder how CHTTP and SCons could work > together for QA automation? It seems logical since both are written in > python. Would it be to hard to setup a servelet that listens over chttp > and makes sure programs compile and features work? It seemed LL was > headed that direction whereby making QA easier until... well... *sigh* I think a simple web service would be sufficient. It's not like you have to have strongly-guaranteed exactly-once messaging semantics for automated builds. Also, don't limit Certified HTTP to being a "python-only" service -- it's just HTTP with some dingalings! The tricky part of build automation is not the initiation protocol, but rather the endpoint that does the build. I know that QA has many automatic builds set up already, and I believe more are in the works. -RYaN From seg at haxxed.com Tue Dec 18 12:54:46 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Dec 18 12:54:45 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <20071218124949.GA17912@bruno.sbruno> References: <47673915.9040909@gmail.com> <4767B50D.9010709@blueflash.cc> <20071218124949.GA17912@bruno.sbruno> Message-ID: <1198011286.18986.110.camel@localhost> On Tue, 2007-12-18 at 13:49 +0100, Dale Glass wrote: > Since we're at it, does anybody NEED it back? For practical usage for > some purpose, and not as a political statement I mean. > > > It's merely a placeholder for something much bigger, and my life > > is just too short to enter the arena of political or religious > > issues in SL. > I'm not that interested in politics myself either. My philosophy is that > if it's useful, it'd rather keep it. Meh. My viewer has had a patch to allow "Hacked Godmode" on the main grid for some time now. Which allows getting texture UUIDs of anything, and so much more... As a general beef I've been wanting to get off my chest, obfuscation just makes debugging difficult. If I'd just been able to select a broken texture and save it, I could have tested it in isolation and probably figured out the lossless texture bug way earlier. I went digging in to the LLImage classes, and it seems there's a ::save() method already implemented. At least for textures it seems "Save As" is just a simple (heh) matter of creating UI for it. The cache obfuscation also means I can't add my SL cache to my OpenJPEG test suite. I really want to be able to iterate over every texture in my cache, and decode them with OpenJPEG. This would allow an easy "real-world" test, for both bug finding with valgrind, and focusing optimization efforts. I don't suppose anyone has a "de-obfuscate the cache" patch already, so I don't duplicate effort? :) Also, I've used it in the interest of full disclosure. To have any chance of counteracting griefers, you have to know how their tools work. I intercepted a "bury prim". Want one? Here: Type: Sphere Path cut begin, end: 0, 0.75 Hollow: 94.9 Twist begin, end: -360, 360 Dimple begin, end: 0.028, 0.05 Size x,y,z: 1.637, 1.637, 2.519 I have not analyzed it to figure out which of those are important. But create that object, and set it physical. Let it go, and it will most likely bounce a few times then fly off the sim. If it comes in contact with any avatar, (Hint, move it on top of an avatar before "letting go"...) that avatar will be thoroughly buried or possibly orbited. I tested it on the beta grid. It seems Havok4 has neutralized this particular exploit. Hell I filled up an entire sim with them, didn't do anything. Didn't crash the sim either. Nice. :) -------------- 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/20071218/85063abe/attachment.pgp From jhurliman at wsu.edu Tue Dec 18 13:02:31 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Dec 18 13:00:36 2007 Subject: [sldev] Decoding the SL cache (Was RE: The criminalization of open source) In-Reply-To: <1198011286.18986.110.camel@localhost> References: <47673915.9040909@gmail.com> <4767B50D.9010709@blueflash.cc> <20071218124949.GA17912@bruno.sbruno> <1198011286.18986.110.camel@localhost> Message-ID: <47683567.7060001@wsu.edu> Callum Lerwick wrote: > I don't suppose anyone has a "de-obfuscate the cache" patch already, so > I don't duplicate effort? :) > It's been a long time since I've tried this code out, but see if it still works. http://www.libsecondlife.org/wiki/Slice John Hurliman From dzonatas at dzonux.net Tue Dec 18 13:20:07 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 18 13:20:07 2007 Subject: [sldev] [VWR] QA, CHTTP, Compiling 1.18.6.1, standalone build and no llmozlib (to CEO) In-Reply-To: <47682123.6010007@lindenlab.com> References: <1197926671.18986.11.camel@localhost> <47670020.9050801@gmail.com> <1197945231.18986.29.camel@localhost> <4767F453.6050704@dzonux.net> <47682123.6010007@lindenlab.com> Message-ID: <47683987.4080402@dzonux.net> Ryan Williams (Which) wrote: > I think a simple web service would be sufficient. It's not like you > have to have strongly-guaranteed exactly-once messaging semantics for > automated builds. Also, don't limit Certified HTTP to being a > "python-only" service -- it's just HTTP with some dingalings! That sounds like oversimplifying the build process to yesteryears technology. I'm not thinking just about python. I'm not thinking just about C++ or such. There are several layers involved here that can be combined. Some probably see Mono/C# as an attempt to do it. The argument was for a unified build. Some suggested the coolness of using a preferred C# IDE (like VS, etc) that can compile for scripts in-world. That only is the tip of the iceberg of what is possible. Nevertheless, it does not mean Mono or Python are the answer. If one wants to take the idea much further, there are steps that can be done now. Textures are one thing... but damn look at protecting programs and their data. No, simple web services are not enough. I guess QT was not enough of a lesson. Must have been a very stupid and foolish hoax if nothing learned. Programs (in-world scripts and source code for viewer and servers, etc) are assets, too. Keeping them centralized is also not enough. QA is going to go way beyond what you have demonstrated so far. -- Power to Change the Void From tess at lindenlab.com Tue Dec 18 13:35:36 2007 From: tess at lindenlab.com (Tess Chu) Date: Tue Dec 18 13:48:49 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: Message-ID: <47683D28.30803@lindenlab.com> Thanks Robin! It looks like the code uses curl to post the credentials and parses the response for the web login key. Patching this into llstartup for building without llmozlib will require a few more steps to work, namely putting back the interface for which the credentials are entered, or adding in command line options. Can this replace the web service we discussed in prior email threads? The tricky part here is what to do when login fails. Now that authentication is web based, when clients built with llmozlib sees a failure, the web code will do the logic to redirect to a different page asking for more information. i.e. when your password is wrong, it redirects back to the original splash page with an error message. Without llmozlib, the only valid response would be to error, message, and reset or exit. Please realize that maintaining the version of the client without llmozlib will incur more work if we add additional arguments to the prompt such as a SecureID, or if we implement more rigorous fraud detection, which will cause higher failure rates that will need a browser to see the error. Consolidating authentication to web was supposed to reduce the amount of viewer maintenance work. Tess Robin Cornelius wrote: > On Dec 18, 2007 12:29 PM, Robin Cornelius wrote: > > >> I have the code working in a standalone app and I am planning to >> integrate directly into llstartup. I think its a useful fallback for >> non mozlib cases? Any thoughts? I can post it if anyone wants it, its >> *very* dirty ATM but its quite easy to integrate into llstartup.cpp if >> anyone wants to. >> > > http://www.byteme.org.uk/uploads/curltest.c > > Its quick and dirty but you get the key. > > Robin > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From donovan at lindenlab.com Tue Dec 18 13:59:07 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Tue Dec 18 13:59:14 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <47683D28.30803@lindenlab.com> References: <47683D28.30803@lindenlab.com> Message-ID: <9933FC87-2461-4CE8-8A08-A5B266BCF5E5@lindenlab.com> On Dec 18, 2007, at 1:35 PM, Tess Chu wrote: > Thanks Robin! > > It looks like the code uses curl to post the credentials and parses > the response for the web login key. Patching this into llstartup > for building without llmozlib will require a few more steps to work, > namely putting back the interface for which the credentials are > entered, or adding in command line options. Can this replace the > web service we discussed in prior email threads? Cool Robin. We would like to apply a patch to the official viewer that uses this code when the -login Firstname Lastname password command line option is passed to the viewer. Then open source developers that don't link to llmozlib will be able to log in the viewer from the command line. I don't think this replaces a web service; I think go.php can be modified to take LLSD as input/output instead of multipart/mime form input and html output. This way the viewer can use the normal LLSD http client to implement Robin's patch, and helps with the eventual goal of allowing useful scripts to be written in pure llsdhttp. Donovan From secret.argent at gmail.com Tue Dec 18 14:01:59 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Dec 18 14:02:06 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <1198011286.18986.110.camel@localhost> References: <47673915.9040909@gmail.com> <4767B50D.9010709@blueflash.cc> <20071218124949.GA17912@bruno.sbruno> <1198011286.18986.110.camel@localhost> Message-ID: On 2007-12-18, at 14:54, Callum Lerwick wrote: > Also, I've used it in the interest of full disclosure. To have any > chance of counteracting griefers, you have to know how their tools > work. > I intercepted a "bury prim". Want one? Here: > > Type: Sphere > Path cut begin, end: 0, 0.75 > Hollow: 94.9 > Twist begin, end: -360, 360 > Dimple begin, end: 0.028, 0.05 > Size x,y,z: 1.637, 1.637, 2.519 We discovered that one a couple years ago. There's a bunch of variants, I believe they all have the 90%+ hollow and -360..360 twist. It doesn't kick off by itself, but a number of other parameters will do it... I have one that (IIRC, I can't get inworld now) is dimpled 0.49..0.51 and X>1, Y>1, and Z==0.01. Adding an llTargetOmega can also be useful. From nicholaz at blueflash.cc Tue Dec 18 14:08:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Dec 18 14:08:23 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <47683D28.30803@lindenlab.com> References: <47683D28.30803@lindenlab.com> Message-ID: On 18.12.2007, at 22:35, Tess Chu wrote: > The tricky part here is what to do when login fails. Now that > authentication is web based, when clients built with llmozlib sees > a failure, the web code will do the logic to redirect to a > different page asking for more information. i.e. when your > password is wrong, it redirects back to the original splash page > with an error message. Without llmozlib, the only valid response > would be to error, message, and reset or exit. It could store the result page locally as a file and launch a local web browser showing it, to give the user an idea what's happening. Nick From Dana.Fagerstrom at Sun.COM Tue Dec 18 14:37:20 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Tue Dec 18 14:37:24 2007 Subject: [sldev] [VWR] [llmozlib] - what version of mozilla/firefox? Message-ID: <47684BA0.7090506@sun.com> I've gotten successful builds with llmozlib but am still seeing way too many crashes from 1.18.6.1 at login time. They are all from the mozilla library. Can someone tell me what official version of Mozilla we should be pulling? Looks like 1.5.0.12 but I just want to be sure before I dive deeper into these crashes. And how about llmozlib. It looks like the code from the tarball, llmozlib-src-20071121.tar.gz is the latest. Correct? I'm only asking this because I found several references to different releases on the wiki and outside sources. Of course, having llmozlib embedded in the svn tree would have made life easier :) Thanks, D From callum at lindenlab.com Tue Dec 18 14:49:04 2007 From: callum at lindenlab.com (Callum Prentice) Date: Tue Dec 18 14:49:18 2007 Subject: [sldev] [VWR] [llmozlib] - what version of mozilla/firefox? In-Reply-To: <47684BA0.7090506@sun.com> References: <47684BA0.7090506@sun.com> Message-ID: <47684E60.3090700@lindenlab.com> What sort of crashes are you seeing Dana? Which platform are you using and which type of build are you using? (Debug/Release/Deployment/Development etc.) I apologize for the LLMozLib confusion - there is some work in progress to unify llmozlib and make the version we use in the client match the ones referred to elsewhere. No firm timescale but it shouldn't be too much longer. It is available via SVN - https://svn.secondlife.com/svn/llmozlib/trunk/ > I've gotten successful builds with llmozlib but am still seeing way too > many crashes from 1.18.6.1 at login time. They are all from the mozilla > library. Can someone tell me what official version of Mozilla we should > be pulling? Looks like 1.5.0.12 but I just want to be sure before I > dive deeper into these crashes. > > And how about llmozlib. It looks like the code from the tarball, > llmozlib-src-20071121.tar.gz is the latest. Correct? > > I'm only asking this because I found several references to different > releases on the wiki and outside sources. > > Of course, having llmozlib embedded in the svn tree would have made life > easier :) > > Thanks, > D > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Tue Dec 18 14:59:47 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 18 14:59:47 2007 Subject: [sldev] [VWR] QA, CHTTP, Compiling 1.18.6.1, standalone build and no llmozlib (to CEO) In-Reply-To: <47683987.4080402@dzonux.net> References: <1197926671.18986.11.camel@localhost> <47670020.9050801@gmail.com> <1197945231.18986.29.camel@localhost> <4767F453.6050704@dzonux.net> <47682123.6010007@lindenlab.com> <47683987.4080402@dzonux.net> Message-ID: <476850E3.2070009@dzonux.net> I do appreciate the reply. Maybe when LL employees have some spare time they can read this. Dzonatas wrote: > Textures are one thing... but damn look at protecting programs and > their data. No, simple web services are not enough. An example of how simple web services or how simple POSTs, GETs, and DELETEs, are not enough: https://wiki.secondlife.com/wiki/Project_Motivation The scary numbers. People want to create business on a platform like Second Life. Right now, Linden Lab publishes releases of source code. The QA on those releases are very limited to just making sure the server and viewer works as expected. When we plug in the scary numbers, we can see that there will be 60 million regions worth of programs running beyond the server and viewer itself. Times that by about 1000 active scripts for each region. What manpower is it going to take to make sure 60 billion scripts have been reliably QA'd? People want to make sure they can say their business is reliable. Right now, without automation, the is not enough people on earth to test every single script to make sure any update made does not have a disfunctional effect. Is Linden Lab brave enough to say that LL will continue to push updates every week and have business come back and ask if those updates have been QA'd with that business's scripts? Of course, LL alone doesn't even have to manpower to test all the scripts on the grid at this time. How can LL possible say they can guarantee such reliability? Impossible. That is where a line is drawn between being a funny virtual game and being a reliable platform. Automation, like this, can not be avoided. Jobs will be affected. We can only hope for the positive and make sure people can stay in a job status. That may make it obvious that the LL today won't be the same LL tomorrow. I think about these factors. I had full access to billions worth of U.S. dollars. (The job I let go before I hit bottom from losing my kids.) My work affected peoples jobs, but it did not fuck-up the banks and their economies that people rely upon every second. Second Life and your job is just a so-said "virtual" world that experiences downtime. Luckily, avatars don't need to eat, have shelter, or need recovery in case of a disaster. My job may have put 800 people on the street, but it did not put 50 billion dollars worth of jobs, food, banks, business, and millions of affected people on the street. Ironical, LL tries to informally hire me but tries to put me on the street to "do me a favor." It was pretty obvious when James asked me the stupid interview question about pennies on a sphere. LL is not in the business to put pennies on a sphere, so who cares what kind of answer was said. Very um.. bright! To this day, I'm still faced with the court saying I'm worth a lot (from the my work experience) and threatens to put me in jail if I don't make some fictional amount they came up with for what I'm worth. Does LL disagree with the court and says I'm worth the street? LL hasn't fully hired me as of yet beyond a currently non-paying CA. Ah! I'm haven't been just insanely talking my head on this list for the past months. I'm being threatened in different ways, and I don't have the answer to stop it. Keep in mind "scary" numbers. Am I worth some "scary" fictional amount? McDs and like jobs don't even pay enough to settle it.. I still get the threats. I'm tired, and I'm asking for a decent job that would settle the court. The court threatens me. Takes away things until I prove innocence (for which I'm not found guilty). I tell LL (and other business I've tried) what I can do. After so many turn downs, you think I could tell the court that I'm not worth that much they say. It is not that simple. I may be rusty at times, but I prove I can do that job and keep the right focus about it. Think the court will accept me telling them that business don't want to hire me? Nope, they either make me get any job or put me in jail. You wonder why I'm rusty -- time spent in jobs unrelated to my expertise. Hmm... we were talking about reliability and jobs. Ok, Court, you ask LL to hire me and find out why not. Ok, LL, you ask Court why I'm worth so much and tell them why you won't fully hire me cause you think I'm not worth it. You two battle it out. I'm tired, and I wanted to be with my kids and show them a real life. -- Power to Change the Void From Dana.Fagerstrom at Sun.COM Tue Dec 18 15:19:49 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Tue Dec 18 15:20:09 2007 Subject: [sldev] [VWR] [llmozlib] - what version of mozilla/firefox? In-Reply-To: <47684E60.3090700@lindenlab.com> References: <47684BA0.7090506@sun.com> <47684E60.3090700@lindenlab.com> Message-ID: <47685595.6080602@sun.com> Thanks Callum! My responses are inline below: > What sort of crashes are you seeing Dana? I've gotten a little closer. Some of the issues today were do to a bug in a script I wrote to copy the mozilla libraries and headers over into the linden build tree. Right now the viewer is complaining that it can't find /usr/libexec/gecko as it attempts to bring up the login page. You can see that in the attached run log. This, of course, looks like a build issue on my end because I'm using Solaris. What is frustrating is that there is no core file so it looks like my next best bet is using truss or DTrace to catch what's going wrong. > Which platform are you using and which type of build are you using? > (Debug/Release/Deployment/Development etc.) The platform is Solaris x86 using and I'm building using the release_client target. My plan is to offer up the Solaris version of the llmozlib build scripts and patches as soon as I get a stable SL build. > It is available via SVN - https://svn.secondlife.com/svn/llmozlib/trunk/ Excellent! I'll go grab a copy from svn and will see what changed. I also need to know what Mozilla branch you recommend. I'm sure the build scripts under the svn tree are all I need to reference :) Thanks, D (Whoops Babii) PS: For those who are interested, SL 1.18.5.3 is rock solid on Solaris. Not one crash and I have a slew of people inside the company using it. The only things missing is the m4a audio decoder for GStreamer (because faad is not license friendly) and we're still missing OpenAL audio streaming - something I have yet to look into... And of course voice but I've got company there with the Linux contingent. >> I've gotten successful builds with llmozlib but am still seeing way >> too many crashes from 1.18.6.1 at login time. They are all from the >> mozilla library. Can someone tell me what official version of Mozilla >> we should be pulling? Looks like 1.5.0.12 but I just want to be sure >> before I dive deeper into these crashes. >> >> And how about llmozlib. It looks like the code from the tarball, >> llmozlib-src-20071121.tar.gz is the latest. Correct? >> >> I'm only asking this because I found several references to different >> releases on the wiki and outside sources. >> >> Of course, having llmozlib embedded in the svn tree would have made >> life easier :) >> -------------- next part -------------- A non-text attachment was scrubbed... Name: sl-x86.log Type: text/x-log Size: 21961 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071218/e6ff85b5/sl-x86-0001.bin From matthew.dowd at hotmail.co.uk Tue Dec 18 15:27:42 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Dec 18 15:27:44 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <47683D28.30803@lindenlab.com> Message-ID: Does even need to store anything locally if what is returned is a proper HTTP redirect. In which case what is needed is for the client to open the redirected URL returned in the internal browser (if present) or else an external one. This is something which Argent and myself have been arguing for, for some time, and means that LL can implement all the anti fraud stuff but retaining the logon UI within the client. True, LL can suddenly change the UI to add SecureID or the like overnight, but a) we have assurances from LL that they won't change the parameters returned to the new authentication web CGI script without notice b) changing how people authenticate would need a long lead time (testing etc.) anyway so not to loose users Matthew BTW another observation on the new webform UI - my impression is that the webpage downloaded includes everything (splash screen, blog posts, status, etc. ) as well as the username/password boxes? As such, it makes it difficult for someone writing a third party viewer who wishes to customise this (e.g. adding third party browser specific blog posts, status, splash screen, etc.) which means those wanting such customisation will bypass the LL logon webform and use their own (or own UI). Wouldn't it have been better to keep the authentication part to a seperate dedicated web form? ---------------------------------------- > From: nicholaz@blueflash.cc > Subject: Re: [sldev] Re: [VWR] Web login without llmozlib > Date: Tue, 18 Dec 2007 23:08:19 +0100 > To: tess@lindenlab.com > CC: sldev@lists.secondlife.com > > > On 18.12.2007, at 22:35, Tess Chu wrote: >> The tricky part here is what to do when login fails. Now that >> authentication is web based, when clients built with llmozlib sees >> a failure, the web code will do the logic to redirect to a >> different page asking for more information. i.e. when your >> password is wrong, it redirects back to the original splash page >> with an error message. Without llmozlib, the only valid response >> would be to error, message, and reset or exit. > > It could store the result page locally as a file and launch a local > web browser showing it, to give the user an idea what's happening. > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml From callum at lindenlab.com Tue Dec 18 15:34:47 2007 From: callum at lindenlab.com (Callum Prentice) Date: Tue Dec 18 15:34:59 2007 Subject: [sldev] [VWR] [llmozlib] - what version of mozilla/firefox? In-Reply-To: <47685595.6080602@sun.com> References: <47684BA0.7090506@sun.com> <47684E60.3090700@lindenlab.com> <47685595.6080602@sun.com> Message-ID: <47685917.6000307@lindenlab.com> > I've gotten a little closer. Some of the issues today were do to a bug > in a script I wrote to copy the mozilla libraries and headers over into > the linden build tree. Right now the viewer is complaining that it can't > find /usr/libexec/gecko as it attempts to bring up the login page. You > can see that in the attached run log. This, of course, looks like a > build issue on my end because I'm using Solaris. What is frustrating is > that there is no core file so it looks like my next best bet is using > truss or DTrace to catch what's going wrong. I haven't seen that error before - my best guess would be a problem finding the profile dirs (the places it wants to find the runtime files and where is stores the user settings). >> Which platform are you using and which type of build are you using? >> (Debug/Release/Deployment/Development etc.) > > The platform is Solaris x86 using and I'm building using the > release_client target. My plan is to offer up the Solaris version of the > llmozlib build scripts and patches as soon as I get a stable SL build. Wow! That's superb - great job getting a Solaris build going. >> It is available via SVN - https://svn.secondlife.com/svn/llmozlib/trunk/ > > Excellent! I'll go grab a copy from svn and will see what changed. I > also need to know what Mozilla branch you recommend. I'm sure the build > scripts under the svn tree are all I need to reference :) The current version in the client wants 1.8.0.x (similar to Firefox 1.5.x). The newer version I mentioned earlier uses the more recent 1.8.1.x version of Gecko (like Firefox 2.0.x). Apart from having a single, unified source for everything, the big win is that we'll start getting security patches and updates again. From tess at lindenlab.com Tue Dec 18 15:59:49 2007 From: tess at lindenlab.com (Tess Chu) Date: Tue Dec 18 16:00:15 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <47683D28.30803@lindenlab.com> Message-ID: <47685EF5.4060506@lindenlab.com> > BTW another observation on the new webform UI - my impression is that the webpage downloaded includes everything (splash screen, blog posts, status, etc. ) as well as the username/password boxes? As such, it makes it difficult for someone writing a third party viewer who wishes to customise this (e.g. adding third party browser specific blog posts, status, splash screen, etc.) which means those wanting such customisation will bypass the LL logon webform and use their own (or own UI). Wouldn't it have been better to keep the authentication part to a seperate dedicated web form? > We have a framed solution ready for QA for clients like the OnRez viewer so that a provided CSS file will set a particular look and feel, and a provided URL can set a specific page for the top portion of the login page. That should solve the customization concerns here. Tess From robin.cornelius at gmail.com Tue Dec 18 17:04:28 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue Dec 18 17:03:41 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <9933FC87-2461-4CE8-8A08-A5B266BCF5E5@lindenlab.com> References: <47683D28.30803@lindenlab.com> <9933FC87-2461-4CE8-8A08-A5B266BCF5E5@lindenlab.com> Message-ID: <47686E1C.20101@gmail.com> Hi Again Patch now available, that allows login via web/curl when used with -autologin and -login first last password command line http://www.byteme.org.uk/uploads/curllogin.patch Should give people something to work with. Tested it and can login. Patch against 1.18.6.1 Best regards Robin From jhurliman at wsu.edu Tue Dec 18 17:54:54 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Dec 18 17:52:52 2007 Subject: [sldev] libprimrender Message-ID: <476879EE.1080803@wsu.edu> http://www.jhurliman.org/index.php/2007/libprimrender-preview/ -------------------------------------------------------------- "Just finished committing an early preview of libprimrender to the libsecondlife source tree. libprimrender takes libsecondlife primitive objects and creates 3D mesh data. The library only uses basic math and libsecondlife data types, so there is no platform or rendering library dependency. The code is released as a GPL v2 library written in C#, based on the official Second Life viewer source code (llvolume.cpp). The screenshot above shows sceneviewer (an old Second Life client written in C# using libsecondlife and XNA) using libprimrender to draw a twisted and sheared cube. The noise in the background is wireframe water left over from the original codebase. The source code can be browsed at: http://openmetaverse.org/svn/index.cgi/libsl/libprimrender/ Or checked out through SVN at: svn://openmetaverse.org/libsl/libprimrender/ This is an early preview, it does not calculate tangents/normals/binormals and there are likely still some bugs. If you spot any please use the libsecondlife Issue Tracker or post a comment here." John Hurliman From dzonatas at dzonux.net Tue Dec 18 18:29:40 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 18 18:29:40 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <1197955427.18986.44.camel@localhost> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> Message-ID: <47688214.1030200@dzonux.net> Callum Lerwick wrote: > Oh yeah, because of the toy economy. Bingo! If the money is not real, then the copyright issues are null and void too. Once somebody uploads their work to SL, it is worth nothing. There is no money to win out of lost damages where there is no value. Considering how LL claims the successful businesses of AC, the guy from the front room, and etc... it doesn't add up to just no value. Hypocritical. Embrace the inevitable -- the Linden has value. -- Power to Change the Void From dzonatas at dzonux.net Tue Dec 18 18:35:31 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 18 18:35:30 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47677BEB.5050706@cox.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> Message-ID: <47688373.1030600@dzonux.net> Lawson English wrote: > In fact, its no different than an artist or writer selling a CD or DVD > with megabytes of copyrighted content. > > Are you saying that artists and writers shouldn't be allowed to sell > eBooks or that games creators can't sue you if you rip textures from > the game CD for resale? > > And, by extension, that DVD copying for resale isn't really a crime > because the copying process is so cheap? > Your comparing a world of where there is value on the dollar to a world where there is no value on the dollar (by TOS). How can you possible do that? With no value to the Linden, no one is committing a crime over copyright. There is no value to the sale or trade. No damage done. Worst someone can do is a slap on the wrist and say "stop it." These are the facts. It does not represent my personal view. -- Power to Change the Void From dzonatas at dzonux.net Tue Dec 18 18:42:13 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 18 18:42:13 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47678141.5050204@gwala.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> Message-ID: <47688505.8080106@dzonux.net> Adam Frisby wrote: > That's not what he's saying at all - and you know it. Stop being a > smartass. > > This is about removing functionality for the sake of appeasement to a > unrealistic ideal, which frankly is just stupid. > There would be no need to remove it if there truly was no value to it. It is more then just about appeasement, as you seem to implicitly acknowledge the appeasement to the masses that feel there is something of value that needs to be protected. Another way to approach the issue, do we protect content and not Lindens? Lindens have no value (stated by TOS), just play money, so why bother to protect the amount, or currency, of lindens? However, those contents that are supposedly being protected by appeasement is being traded by something of no value. *scratches head* -- Power to Change the Void From nikki at cf-estates.com Tue Dec 18 18:42:20 2007 From: nikki at cf-estates.com (nikki@cf-estates.com) Date: Tue Dec 18 18:43:56 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47688373.1030600@dzonux.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> Message-ID: <20071218184220.d8r2nyoo80owgk0o@66.152.166.10> Quoting Dzonatas : > Lawson English wrote: >> In fact, its no different than an artist or writer selling a CD or >> DVD with megabytes of copyrighted content. >> >> Are you saying that artists and writers shouldn't be allowed to >> sell eBooks or that games creators can't sue you if you rip >> textures from the game CD for resale? >> >> And, by extension, that DVD copying for resale isn't really a crime >> because the copying process is so cheap? >> > > Your comparing a world of where there is value on the dollar to a world > where there is no value on the dollar (by TOS). How can you possible do > that? > > With no value to the Linden, no one is committing a crime over > copyright. There is no value to the sale or trade. No damage done. > Worst someone can do is a slap on the wrist and say "stop it." > > These are the facts. It does not represent my personal view. I can't find your facts. I've read the TOS many times and have reviewed it again I can't find anywhere the TOS says the Linden Dollar has no value, nor can I remember it ever saying such. Could you quote your source or are you repeating a rumor? From nikki at cf-estates.com Tue Dec 18 19:08:10 2007 From: nikki at cf-estates.com (nikki@cf-estates.com) Date: Tue Dec 18 19:08:03 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <476888F0.6050901@dzonux.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> <20071218184220.d8r2nyoo80owgk0o@66.152.166.10> <476888F0.6050901@dzonux.net> Message-ID: <20071218190810.4ovmmyy1sggk0o00@66.152.166.10> Quoting Dzonatas : > nikki@cf-estates.com wrote: >>> >>> These are the facts. It does not represent my personal view. >> >> I can't find your facts. I've read the TOS many times and have >> reviewed it again I can't find anywhere the TOS says the Linden >> Dollar has no value, nor can I remember it ever saying such. Could >> you quote your source or are you repeating a rumor? >> > It is not my facts, as it is what it gets compared to. > > Terms of Service section: > > *1.4 Second Life "currency" is a limited license right available for > purchase or free distribution at Linden Lab's discretion, and is not > redeemable for monetary value from Linden Lab.* > > http://secondlife.com/corporate/tos.php This section only states that Linden Lab will not give money for it. It does not state that the Linden has no value or in any way deny it's value it only makes it clear Linden Lab refuses to buy Lindens. The TOS stating the Linden is valueless is not fact. It is only a common misperception from a careless read or repeated rumors. There is no actual fact to the idea and it won't invalidate damages in court. > I say there is value, but that is not enough to prevent content trades > that can still be held as no value due to someone else's view of the > value, or no value, of the Linden Dollar. The TOS does not say the Linden has no value if a copyright violator wants to claim the Linden has no value that will carry about as much weight in determining damages as if he sneezed. Value isn't determined by the individual views of the defendant. From dzonatas at dzonux.net Tue Dec 18 19:19:03 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 18 19:19:02 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <98C2B399-2EEE-46B3-9208-04742FED1203@gmail.com> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> <1197967765.30098.1227154689@webmail.messagingengine.com> <98C2B399-2EEE-46B3-9208-04742FED1203@gmail.com> Message-ID: <47688DA7.2010104@dzonux.net> Argent Stonecutter wrote: > Thanks, Ordinal. This is the key bit. > > On 2007-12-18, at 02:49, Ordinal Malaprop wrote: >> Without the "toy economy" none of us would be here talking about it >> on this list. > > Missing this point is just as bad as missing the original point about > the ineffectiveness of DRM. > Common DRM is not mobile, but it may be mobile. It could be made part of scripts/programs put in-world and ran anywhere that DRM technology is supported. One could say that normal security augmentation that we need is a form a mobile DRM. It is not just about the DRM itself or its form... but, yes, its effectiveness. -- Power to Change the Void From lisa at tfpsoft.com Tue Dec 18 20:11:21 2007 From: lisa at tfpsoft.com (Lisa Carter) Date: Tue Dec 18 20:06:44 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47688373.1030600@dzonux.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> Message-ID: <017601c841f5$36dee770$a49cb650$@com> > With no value to the Linden, no one is committing a crime over > copyright. There is no value to the sale or trade. No damage done. > Worst someone can do is a slap on the wrist and say "stop it." > Ok, I really *don't* want to get dragged into any of the debates going on on this list (sigh) but in good conscience I feel I need to say this much before someone gets themselves in trouble from mis-information: You can still be sued for copyright violation even if you give something away for free, and even if the object has no resale value. This is called "statutory damages". The amounts awarded are typically in the range of $750 to $300,000 US. The US copyright office has a number of publications you can read here to educate yourself: http://www.copyright.gov/ International copyright law varies, but many of the principles are the same in the major nations. Whether or not the Linden dollar has any value is completely irrelevant to copyright law. -L From dzonatas at dzonux.net Tue Dec 18 20:30:26 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 18 20:30:24 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <20071218190810.4ovmmyy1sggk0o00@66.152.166.10> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> <20071218184220.d8r2nyoo80owgk0o@66.152.166.10> <476888F0.6050901@dzonux.net> <20071218190810.4ovmmyy1sggk0o00@66.152.166.10> Message-ID: <47689E62.4030403@dzonux.net> nikki@cf-estates.com wrote: > The TOS stating the Linden is valueless is not fact. It is only a > common misperception from a careless read or repeated rumors. There is > no actual fact to the idea and it won't invalidate damages in court. When you quoted me, you left out some bits of my e-mail, like this: "The TOS does not state that the Linden Dollar has value. The TOS does not prevent the Linden Dollar from having value. Who claims there is value?" And, also the bit about section 1.3 that says it is more about the respect of rights. DMCA and other copyright law can go so far. It is not foolproof -- especially where such law has no jurisdiction. -- Power to Change the Void From dzonatas at dzonux.net Tue Dec 18 20:49:59 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Dec 18 20:49:58 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <017601c841f5$36dee770$a49cb650$@com> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> <017601c841f5$36dee770$a49cb650$@com> Message-ID: <4768A2F7.3030405@dzonux.net> Lisa Carter wrote: > This is called "statutory damages". If there is a statue to match the claim of damage, then it is possible, and the value of the trade, or the content itself, doesn't matter. The enumeration of such statues are limited by practicality. It is not foolproof. The assertion is that one cannot claim damage on the act of one's own will in general. If one puts content up to be copied, that is one's own will for this example. On this principle, remember that the in-world Linden Dollar is a different license than, for example, than the U.S. Dollar. The value of the U.S. Dollar does not automatically grant permission to use content posted in-world. The assumption that copyright laws follow the license of the U.S. Dollar is obvious, and content in-world is not being traded with U.S. Dollars. The TOS does not establish any obvious exchange between the U.S. Dollar and Linden Dollar to justify a prescribed statutory damage amount. Perhaps, what I just said may be helpful to make it more foolproof if someone is in that motive. -- Power to Change the Void From nikki at cf-estates.com Tue Dec 18 21:03:53 2007 From: nikki at cf-estates.com (nikki@cf-estates.com) Date: Tue Dec 18 21:03:47 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47689E62.4030403@dzonux.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> <20071218184220.d8r2nyoo80owgk0o@66.152.166.10> <476888F0.6050901@dzonux.net> <20071218190810.4ovmmyy1sggk0o00@66.152.166.10> <47689E62.4030403@dzonux.net> Message-ID: <20071218210353.uh9yiy9k84s44ckc@66.152.166.10> Quoting Dzonatas : > nikki@cf-estates.com wrote: >> The TOS stating the Linden is valueless is not fact. It is only a >> common misperception from a careless read or repeated rumors. There >> is no actual fact to the idea and it won't invalidate damages in >> court. > > When you quoted me, you left out some bits of my e-mail, like this: I do try to keep replies down to what I'm addressing > "The TOS does not state that the Linden Dollar has value. The TOS does > not prevent the Linden Dollar from having value. Who claims there is > value?" I was addressing your clear and repeated claim the TOS states the L$ has no value would this statement be retreating from that claim? As far as the TOS not declaring a value it doesn't have to declare a value for a value to exist. The market determines value not Linden Lab or the defendant. > And, also the bit about section 1.3 that says it is more about the > respect of rights. That section is totally irrelevant to any discussion of whether the TOS declares the Linden valueless. > DMCA and other copyright law can go so far. It is not foolproof -- > especially where such law has no jurisdiction. The law lacks jurisdiction over copyright infringement in SL? From kamilion at gmail.com Tue Dec 18 21:25:06 2007 From: kamilion at gmail.com (Kamilion) Date: Tue Dec 18 21:25:14 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47689E62.4030403@dzonux.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> <20071218184220.d8r2nyoo80owgk0o@66.152.166.10> <476888F0.6050901@dzonux.net> <20071218190810.4ovmmyy1sggk0o00@66.152.166.10> <47689E62.4030403@dzonux.net> Message-ID: Replies in line. On Dec 18, 2007 4:49 AM, Dale Glass wrote: > On Tue, Dec 18, 2007 at 12:54:53PM +0100, Nicholaz Beresford wrote: > > > > Actually, just for the record, I will not bother to undo that if > > the Lindens make that change. My focus has always been performance, > > stability and usability and I don't see where this change makes a > > difference in any those areas. > Heh, I was actually considering keeping it in mine. > > We have different niches here, if your is performance and stability, > mine is advanced functionality. > > Since we're at it, does anybody NEED it back? For practical usage for > some purpose, and not as a political statement I mean. > > > It's merely a placeholder for something much bigger, and my life > > is just too short to enter the arena of political or religious > > issues in SL. > I'm not that interested in politics myself either. My philosophy is that > if it's useful, it'd rather keep it. Actually, I was using the View Admin Options -> Ctrl-Shift-Alt-T method today. My good friend and flatmate is a builder. I'm a scripter. That means my scripts operate on his builds nearly exclusively, since I suck at building. In the course of my scripting, I often need to check what face is displaying which texture. (and it's just icing on the cake that I get the texture size at the same time) In the course of my work, I ran across some objects said builder friend created, that I could not copy the textures with my primdumper script using llGetTexture or llGetPrimitiveParams([PRIM_TEXTURE, ALL_SIDES]). I ended up resorting to using the libsecondlife TestClient's export function to dump the prims out to an XML format so I could read them. Easy as pie, just read the libsl page, click Getting Started. In asking in the Scripter groups (Scripters of Second Life / Advanced Scripters of Second Life) I ran across the Admin/Shift-Ctrl-Alt-T. In doing so, I was able to compare the texture UUIDs while I could see them with the UUIDs I had on file. It's probably saving me about 3 days of time, considering I've got about 1600 prims to go through and each of them has at least 6 textures. I'll probably end up patching in jhurliman's piemenu Copy UUID to Clipboard to my local linux build. On Dec 18, 2007 1:41 AM, Erik Anderson wrote: > I have also heard that CopyBot is still floating around on the grid in > various places, albiet a lot more underground than before. And you know > what? I'm not sure I care. I'm glad that for the most part that the very > widely-distributed "information should be free" copybots were killed as the > required viewer version got bumped, which raised the bar and limited the > population to those with the ability to maintain the code through the viewer > changes (and their friends). Sometime eventually I would like to see > aspects of copybots come back (it would be nice for clothing stores to > simultaneously model 12 changes of clothing on your avatar for instance) Copybot's been dead and been dead for a long while. It only worked for about 3 weeks somewhere in the 1.16/1.17 series. LL shortly released an update, which at that time released a new UDP protocol map EVERY release. TestClient, which has been shipped with the libsecondlife SVN since the copybot days, has had the same prim export and import function that people maligned CopyBot for. However, many commits hit the SVN which have broken the exporter or importer at various times while the inventory code was being reworked. I am unsure if it's currently working, but there are specific revision numbers which have worked since 1.18 and still continue to do so. Your comment that it's 'gone underground' is completely false, as many many more people have used TestClient than had ever used CopyBot. The @#$%ing annoying copybot killers that attempt to IM anyone with !quit are COMPLETELY flawed, because even the 'good' copybot direct from libsl DID NOT RESPOND TO *OBJECTS* IMing !quit, only AGENTS. The 'bad' hacked copybot had completely removed the !quit command thus were completely immune. Copybot Killers are a waste of time and effort, and DO NOT WORK. End of story. Now, about this TOS arguement. If my memory isn't mistaken, doesn't the TOS grant LL a license to use and display any and all uploaded textures to ANYONE at any time? Under the following in the TOS: ---------- 3.2 You retain copyright and other intellectual property rights with respect to Content you create in Second Life, to the extent that you have such rights under applicable law. However, you must make certain representations and warranties, and provide certain license rights, forbearances and indemnification, to Linden Lab and to other users of Second Life. Notwithstanding the foregoing, you understand and agree that by submitting your Content to any area of the service, you automatically grant (and you represent and warrant that you have the right to grant) to Linden Lab: (a) a royalty-free, worldwide, fully paid-up, perpetual, irrevocable, non-exclusive right and license to (i) use, reproduce and distribute your Content within the Service as permitted by you through your interactions on the Service, and (ii) use and reproduce (and to authorize third parties to use and reproduce) any of your Content in any or all media for marketing and/or promotional purposes in connection with the Service, provided that in the event that your Content appears publicly in material under the control of Linden Lab, and you provide written notice to Linden Lab of your desire to discontinue the distribution of such Content in such material (with sufficient specificity to allow Linden Lab, in its sole discretion, to identify the relevant Content and materials), Linden Lab will make commercially reasonable efforts to cease its distribution of such Content following the receipt of such notice, although Linden Lab cannot provide any assurances regarding materials produced or distributed prior to the receipt of such notice; (b) the perpetual and irrevocable right to delete any or all of your Content from Linden Lab's servers and from the Service, whether intentionally or unintentionally, and for any reason or no reason, without any liability of any kind to you or any other party; and (c) a royalty- free, fully paid-up, perpetual, irrevocable, non-exclusive right and license to copy, analyze and use any of your Content as Linden Lab may deem necessary or desirable for purposes of debugging, testing and/or providing support services in connection with the Service. 3.4 Linden Lab licenses its textures and environmental content to you for your use in creating content in-world. During any period in which your Account is active and in good standing, Linden Lab gives you permission to create still and/or moving media, for use only within the virtual world environment of the Service ("in-world"), which use or include the "textures" and/or "environmental content" that are both (a) created or owned by Linden Lab and (b) displayed by Linden Lab in-world. ---------- If I'm not mistaken, with such a reciprocal license, does that not imply that we too may display and / or use any texture uploaded to the service? Considering that *we* as users are not actually transferring or displaying the textures, the LL servers are transferring the textures to us thus invoking their "royalty-free, worldwide, fully paid-up, perpetual, irrevocable, non-exclusive right and license" (I.E. Full-Perms) to "use, reproduce and distribute your Content within the Service as permitted by you through your interactions on the Service" (I.E. upload) clause? And my last comment on this... Earlier today, a discussion went on in Advanced Scripters of Second Life, where a nameless entity said: [2007/12/18 9:43] Kamilion Schnook: AWG is working on redefining the SL protocol for future & open use. [2007/12/18 9:43] Nameless Belligerent: Linden Labs is a private company [2007/12/18 9:44] Nameless Belligerent : Sounds like more copybot to me [2007/12/18 9:45] Kamilion Schnook: Oh noes, teh copybot is going to swipe MAH TEXTURES HALP HALP MAH HOURS OF PIRATED PHOTOSHOP WORK FROM GOOGLE IMAGE BASES... [2007/12/18 9:45] Nameless Belligerent: stealing textures is easy [2007/12/18 9:46] Nameless Belligerent: thats all we need, more open sourced protocol for people to hack and make illicit tools like copybot. Go for it! [2007/12/18 9:46] Enlightened Individual: You don't need copybot to do that, it's way, way easier. :P [2007/12/18 9:48] Kamilion Schnook: Gee, y'know, I've been here since we've had 30k residents... and the most #1 requested feature I've heard in those years is "Let me download my items to my harddrive so LL doesn't lose them / I don't lose them". LibSL comes through, and they're the bad guy, just because of a couple off-color coments in IRC from Baba. Sheesh. Anyway, I'm shutting up now. :/ [2007/12/18 9:48] Mini Moderator: heh [2007/12/18 9:48] Enlightened Individual: yeah, libSL is pretty much an unmitigated Good Thing for us. Don't rag on them. [2007/12/18 9:49] Enlightened Individual: people have got over the whole copying issue on the web years ago because it was built into the protocol from the start [2007/12/18 9:49] Enlightened Individual: and view source was hugely important for the spread of the web [2007/12/18 9:49] Nameless Belligerent: yeah right, libsl will ruin Sl. right of ownership is one of the thing SL residents depend on to survive. [2007/12/18 9:49] Nameless Belligerent: people make real money from this game [2007/12/18 9:49] Enlightened Individual: oh, right, and the web is worth nothing, huh? [2007/12/18 9:50] Enlightened Individual: I can copy and rehost IBM's website no problem [2007/12/18 9:50] Nameless Belligerent: it paid for my college tuition, if someone wants to take that from me for the simple right of open sourced well screw open sourced. [2007/12/18 9:53] Mini Moderator: STOP THE OFF-TOPIC DISCUSSION, sheash. ;) [2007/12/18 9:53] Nameless Belligerent: at least the way it has been [2007/12/18 9:54] Kamilion Schnook: Hm, let's see... Screw opensource... SL runs on linux servers using mysql databases, squid proxies, python glue, postfix mailer... Now I'm really going to STFU, sorry *Mini Moderator*. [2007/12/18 9:54] ToungeIn Cheek: ..but how can you have income if the hack was unproductive? :P [2007/12/18 9:54] Nameless Belligerent: If copybot comes back and people make perfect duplicates than how can many of us survive, I am a scripter but many of us are builders. [2007/12/18 9:54] Mini Moderator: No problem Kamilion. Great closing statement on that, [2007/12/18 9:54] Enlightened Individual is done too. *Nameless Belligerent* is clueless. Draw your own conclusions. -- Kami From adam at gwala.net Wed Dec 19 00:27:55 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Dec 19 00:28:15 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <20071218210353.uh9yiy9k84s44ckc@66.152.166.10> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> <20071218184220.d8r2nyoo80owgk0o@66.152.166.10> <476888F0.6050901@dzonux.net> <20071218190810.4ovmmyy1sggk0o00@66.152.166.10> <47689E62.4030403@dzonux.net> <20071218210353.uh9yiy9k84s44ckc@66.152.166.10> Message-ID: <4768D60B.2060701@gwala.net> nikki@cf-estates.com wrote: >> DMCA and other copyright law can go so far. It is not foolproof -- >> especially where such law has no jurisdiction. > > The law lacks jurisdiction over copyright infringement in SL? Just a quick note -- this can apply. While LL recognise and respond to foreign DMCA requests, they do not legally have to. If you are a resident of a country without a specialised recent copyright treaty with the US (eg, Australia has one of these), then you have to go the old route for reporting copyright infringement which usually involves lawyers. It only gets worse if your living in a country which is not a signatory to the Berne convention, in that case - you need to file the copyright in Linden Lab's jurisdiction. Regards, Adam From dzonatas at dzonux.net Wed Dec 19 00:29:53 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Dec 19 00:29:52 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <20071218210353.uh9yiy9k84s44ckc@66.152.166.10> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> <20071218184220.d8r2nyoo80owgk0o@66.152.166.10> <476888F0.6050901@dzonux.net> <20071218190810.4ovmmyy1sggk0o00@66.152.166.10> <47689E62.4030403@dzonux.net> <20071218210353.uh9yiy9k84s44ckc@66.152.166.10> Message-ID: <4768D681.3090802@dzonux.net> nikki@cf-estates.com wrote: > Quoting Dzonatas : > >> When you quoted me, you left out some bits of my e-mail, like this: > > I do try to keep replies down to what I'm addressing By first asking me directly off list and then quoting only part back on list? Ok. > >> "The TOS does not state that the Linden Dollar has value. The TOS does >> not prevent the Linden Dollar from having value. Who claims there is >> value?" > > I was addressing your clear and repeated claim the TOS states the L$ > has no value would this statement be retreating from that claim? That doesn't answer my question. I answered yours. > That section is totally irrelevant to any discussion of whether the > TOS declares the Linden valueless. Being it still refers to how to use the license, it is very much in discussion. Unless, you are suggesting that when you buy something with Lindens, with or without value, that you don't have to respect the rights of the content creators. =/ > >> DMCA and other copyright law can go so far. It is not foolproof -- >> especially where such law has no jurisdiction. > > The law lacks jurisdiction over copyright infringement in SL? The law of what country? -- Power to Change the Void From nikki at cf-estates.com Wed Dec 19 00:37:53 2007 From: nikki at cf-estates.com (Nikki Claymore) Date: Wed Dec 19 00:37:56 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <4768D681.3090802@dzonux.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> <20071218184220.d8r2nyoo80owgk0o@66.152.166.10> <476888F0.6050901@dzonux.net> <20071218190810.4ovmmyy1sggk0o00@66.152.166.10> <47689E62.4030403@dzonux.net> <20071218210353.uh9yiy9k84s44ckc@66.152.166.10> <4768D681.3090802@dzonux.net> Message-ID: <4768D861.5080009@cf-estates.com> Dzonatas wrote: > nikki@cf-estates.com wrote: >> Quoting Dzonatas : >> >>> When you quoted me, you left out some bits of my e-mail, like this: >> >> I do try to keep replies down to what I'm addressing > > By first asking me directly off list and then quoting only part back > on list? Ok. You might want to recompare those messages. I accidentally replied directly to you the first time then redirected the message verbatim to the list. >> That section is totally irrelevant to any discussion of whether the >> TOS declares the Linden valueless. > > Being it still refers to how to use the license, it is very much in > discussion. Unless, you are suggesting that when you buy something > with Lindens, with or without value, that you don't have to respect > the rights of the content creators. =/ I would suggest that the rights of the content creators have nothing to do with the form of compensation received whether its USD, EUR, Lindens or frozen turkey's. >>> DMCA and other copyright law can go so far. It is not foolproof -- >>> especially where such law has no jurisdiction. >> >> The law lacks jurisdiction over copyright infringement in SL? > The law of what country? That would depend on what court the suit is filed in wouldn't? Looks like Adam knows more about where filing would be needed than me. From matthew.dowd at hotmail.co.uk Wed Dec 19 02:57:51 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Dec 19 02:57:53 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <47685EF5.4060506@lindenlab.com> References: <47683D28.30803@lindenlab.com> <47685EF5.4060506@lindenlab.com> Message-ID: > We have a framed solution ready for QA for clients like the OnRez viewer > so that a provided CSS file will set a particular look and feel, and a > provided URL can set a specific page for the top portion of the login > page. That should solve the customization concerns here. How will the URL and CSS be provided? Is this something you have to request LL to manually add to their website? Or will it be provided as parameters to the URL to load the logon page? If the latter, will these parameters also work with the proposed logon via an external browser? Please, please, please tell me the answer to that last question is no, otherwise the possibilities for code/exploit injection are endless! Matthew _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml From adam at gwala.net Wed Dec 19 03:03:09 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Dec 19 03:03:26 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <47683D28.30803@lindenlab.com> <47685EF5.4060506@lindenlab.com> Message-ID: <4768FA6D.6060709@gwala.net> My guess would be it's a .CSS file included with the SL Viewer in the SL directory. Adam Matthew Dowd wrote: > > >>We have a framed solution ready for QA for clients like the OnRez viewer >>so that a provided CSS file will set a particular look and feel, and a >>provided URL can set a specific page for the top portion of the login >>page. That should solve the customization concerns here. > > > How will the URL and CSS be provided? Is this something you have to request LL to manually add to their website? Or will it be provided as parameters to the URL to load the logon page? > > If the latter, will these parameters also work with the proposed logon via an external browser? Please, please, please tell me the answer to that last question is no, otherwise the possibilities for code/exploit injection are endless! > > Matthew > _________________________________________________________________ > Who's friends with who and co-starred in what? > http://www.searchgamesbox.com/celebrityseparation.shtml_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From tao.takashi at googlemail.com Wed Dec 19 05:58:16 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Wed Dec 19 05:58:20 2007 Subject: [sldev] [AWG] Capabilities Message-ID: <23bbb49e0712190558s6bdef207jb9992af8a3bcf265@mail.gmail.com> Hi! Just FYI: I wrote a bit together about capabilities on my blog: http://mrtopf.de/blog/secondlife/slga-capabilities-explained-technical/ Feel free to correct me there. cheers, Tao -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/eabb83d2/attachment.htm From soft at lindenlab.com Wed Dec 19 06:02:30 2007 From: soft at lindenlab.com (Soft) Date: Wed Dec 19 06:02:33 2007 Subject: [sldev] Thursday 2pm Open Source Meeting - Agenda Message-ID: If you have something you'd like to cover Thursday at the 2pm open source meeting, please add it to the agenda page: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda See you in Hippotropolis From dzonatas at dzonux.net Wed Dec 19 09:03:16 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Dec 19 09:03:13 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <4768D861.5080009@cf-estates.com> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47688373.1030600@dzonux.net> <20071218184220.d8r2nyoo80owgk0o@66.152.166.10> <476888F0.6050901@dzonux.net> <20071218190810.4ovmmyy1sggk0o00@66.152.166.10> <47689E62.4030403@dzonux.net> <20071218210353.uh9yiy9k84s44ckc@66.152.166.10> <4768D681.3090802@dzonux.net> <4768D861.5080009@cf-estates.com> Message-ID: <47694ED4.4020906@dzonux.net> Nikki Claymore wrote: > You might want to recompare those messages. I accidentally replied > directly to you the first time then redirected the message verbatim to > the list. Ok. When I read what you posted, I felt you left out an essential point I made. You did, in a way, paraphrase what I said and seemingly agree to that point. The rest of your argument and questions conflicts the point, so it was not clear what point you tried to make. > I would suggest that the rights of the content creators have nothing > to do with the form of compensation received whether its USD, EUR, > Lindens or frozen turkey's. Here, you have demonstrated a lack of concern about transactions that do not include any form of dollar value from any market. If the virtual world is kept centralized and self-contained with all content only shared or traded within the world, then your point has some validity. That is not the case here, however. The content is not self-contained. There is decentralization efforts. The transaction of the trade, or just plainly movement of content itself from sim to sim, is not obvious for the reason there was a transaction request. Questions to ask, for example: 1) Was the transaction done because someone bought content? 2) Was the transaction done because sim X needs to express content from sim Y? 3) Was the transaction done because someone injected content to in-world? Each of these questions could carry copyright issues. Each could carry different value for the same kind of transaction. I'm pretty sure sim owners gasps at #2. Wait till regions become more open source... omg.. #2 becomes the biggest concern. I understand if you are a sim owner that your concern to what I have said becomes obvious. I understand why you want to make sure there is a complete separation between dollar value and content being shared to make sure there is a seamless imaginable virtual world constituted with IP from any content creator. >> > That would depend on what court the suit is filed in wouldn't? Looks > like Adam knows more about where filing would be needed than me. > Adam's answer is a bit of brave legal advice. What also matters is where the content actually exists and where the transactions actually took place -- both are less obvious. LL's arbitration process is a generous service offer that may help where the law doesn't if both parties agree to it. Again, there are limits. -- Power to Change the Void From matthew.dowd at hotmail.co.uk Wed Dec 19 10:31:58 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Dec 19 10:31:59 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <4768FA6D.6060709@gwala.net> References: <47683D28.30803@lindenlab.com> <47685EF5.4060506@lindenlab.com> <4768FA6D.6060709@gwala.net> Message-ID: Maybe - but wouldn't that require different HTML web pages for the in viewer authentication and the external browser authentication routes? Matthew ---------------------------------------- > Date: Wed, 19 Dec 2007 19:03:09 +0800 > From: adam@gwala.net > To: matthew.dowd@hotmail.co.uk > CC: tess@lindenlab.com; sldev@lists.secondlife.com; Second@stupor.lindenlab.com > Subject: Re: [sldev] Re: [VWR] Web login without llmozlib > > My guess would be it's a .CSS file included with the SL Viewer in the SL > directory. > > Adam > > Matthew Dowd wrote: > >> >> >>>We have a framed solution ready for QA for clients like the OnRez viewer >>>so that a provided CSS file will set a particular look and feel, and a >>>provided URL can set a specific page for the top portion of the login >>>page. That should solve the customization concerns here. >> >> >> How will the URL and CSS be provided? Is this something you have to request LL to manually add to their website? Or will it be provided as parameters to the URL to load the logon page? >> >> If the latter, will these parameters also work with the proposed logon via an external browser? Please, please, please tell me the answer to that last question is no, otherwise the possibilities for code/exploit injection are endless! >> >> Matthew >> _________________________________________________________________ >> Who's friends with who and co-starred in what? >> http://www.searchgamesbox.com/celebrityseparation.shtml_______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml From donovan at lindenlab.com Wed Dec 19 10:58:55 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Wed Dec 19 10:59:23 2007 Subject: [sldev] [AWG] Capabilities In-Reply-To: <23bbb49e0712190558s6bdef207jb9992af8a3bcf265@mail.gmail.com> References: <23bbb49e0712190558s6bdef207jb9992af8a3bcf265@mail.gmail.com> Message-ID: <08A7EA58-0543-4CF4-ADB3-A81A50618BDA@lindenlab.com> On Dec 19, 2007, at 5:58 AM, Tao Takashi wrote: > Hi! > > Just FYI: I wrote a bit together about capabilities on my blog: > > http://mrtopf.de/blog/secondlife/slga-capabilities-explained- > technical/ > > Feel free to correct me there. Excellent post. I'm not sure your concerns will be problems: * capabilities are easy to understand (thus easing adoption) * the seed capability can give you another seed capability into another service (solves the seed capability requiring global knowledge problem) - the login service gives you an agent domain seed capability - the agent domain seed capability gives you a region domain seed capability (if the agent chooses to enter a region) * capabilities are usually requested at the beginning of a "session" with some entity and then used repeatedly (thus you do not need 2 http requests per request during normal usage) - a user wants to log in to just group chat: - request the group chat seed capability from the authentication service, and then request the GetNextMessage and SendMessage capabilities from the seed cap - repeatedly invoke these GetNextMessage and SendMessage capabilities for the duration of the chat session with the server Hope this helps clear up any confusion. Again, excellent post, great work! Donovan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/6c1ce7e3/attachment-0001.htm From GordonWendt at gmail.com Wed Dec 19 12:23:16 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Dec 19 12:23:23 2007 Subject: [sldev] How Asset server handles saving of scripts Message-ID: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> Hi, I'm sure it's documented somewhere but for the life of me I can't find it but with the current asset issue that's going on I was thinking of how script saving is handled by the asset server, specifically since apparently it attempts to save each time you hit save but while it's in the process of saving you can make a small change (even if you change it back before hitting save again) then hit save which sends a second request and how the asset server handles that. Obviously it has to deal with the second request since that's the most recent change however what happens to the first save attempt? and is there a way to streamline the way it deals with such requests since as far as I can tell that seems to be a fairly intensive operation especially if someone were to do so repeatedly (can't figure why someone would but people do strange things). Just a thought. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/f385428d/attachment.htm From secret.argent at gmail.com Wed Dec 19 12:25:57 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 19 12:26:08 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <47683D28.30803@lindenlab.com> References: <47683D28.30803@lindenlab.com> Message-ID: On 2007-12-18, at 15:35, Tess Chu wrote: > Thanks Robin! > > It looks like the code uses curl to post the credentials and parses > the response for the web login key. Patching this into llstartup > for building without llmozlib will require a few more steps to > work, namely putting back the interface for which the credentials > are entered, or adding in command line options. Can this replace > the web service we discussed in prior email threads? Tess, That pretty much *is* the web-service API I was referring to. The only difference is that I suggested that a successful response should be a redirect to the "secondlife:" URI described in the original announcement. That allows the normal HTTP response codes to do the rest of the job. > The tricky part here is what to do when login fails. That's covered in the response codes. HTTP is designed for this situation. Successful login: 303 Success-message-for-user Location: secondlife:... Other-headers... -- no body --- Authentication failure: 403 Failure-message-for-user Headers... HTML error message Server failure: 5xx Message-for-user Headers... HTML error message Special handling: 307 Message-for-user Location: URL requesting more information Other-headers... --- no body --- The viewer doesn't require any new complex code. No matter what the response is, it contains a message to display to the user. If a web page display is required, it contains a redirect to that page. The client can display that in llMozLib or redirect to an external browser. It can even use the existing framework for llLoadURL to give the user a dialog approving that redirect. From secret.argent at gmail.com Wed Dec 19 12:33:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 19 12:55:42 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <47688505.8080106@dzonux.net> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> <47688505.8080106@dzonux.net> Message-ID: On 2007-12-18, at 20:42, Dzonatas wrote: > There would be no need to remove it if there truly was no value to > it. It is more then just about appeasement, as you seem to > implicitly acknowledge the appeasement to the masses that feel > there is something of value that needs to be protected. Whether it has real value or not is irrelevant. The rules of the game are that it has value in game terms. Things that have value in game terms get protected in game terms. Even if they're just high scores. IN ADDITION, the "toy economy" is what many people are paying LL to participate in, therefor it, itself, has real value. From secret.argent at gmail.com Wed Dec 19 13:04:30 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 19 13:04:38 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <47683D28.30803@lindenlab.com> <47685EF5.4060506@lindenlab.com> <4768FA6D.6060709@gwala.net> Message-ID: On 2007-12-19, at 12:31, Matthew Dowd wrote: > Maybe - but wouldn't that require different HTML web pages for the > in viewer authentication and the external browser authentication > routes? From context, I don't think that the CSS customization has anything to do with authentication per se, it's just a response to an earlier message about whether the HTML login inside the browser prevented the browser from being customized. From ashea at ups.com Wed Dec 19 13:31:40 2007 From: ashea at ups.com (ashea@ups.com) Date: Wed Dec 19 13:32:11 2007 Subject: [sldev] Source release for 1.18.6.0 References: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com><4758A4BB.6020807@lindenlab.com> Message-ID: This is my first time (ever) compiling the code I have a few error, but it might just be me. Let me know what I missed please. Here are my errors, I am using WindowsXP VS2005. Warning 1 warning LNK4221: no public symbols found; archive member will be inaccessible llrect.obj Error 2 error PRJ0019: A tool returned an error code from "Building ytab.cpp" lscript_compile_fb_vc8 Error 3 fatal error C1083: Cannot open source file: '.\lex_yy.cpp': No such file or directory c1xx Error 4 fatal error C1083: Cannot open source file: '.\ytab.cpp': No such file or directory c1xx Warning 5 warning C4189: 'result' : local variable is initialized but not referenced Warning 6 warning C4701: potentially uninitialized local variable 'msg' used Error 7 fatal error LNK1181: cannot open input file 'apr-1.lib' win_crash_logger Error 8 fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory Error 9 fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory Error 10 fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory Error 11 fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory Error 12 fatal error C1083: Cannot open include file: 'MacTypes.h': No such file or directory Where do I get MacTypes.h, ytab.cpp, and lex_yy.cpp Thanks, Anthony -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Soft Sent: Thursday, December 06, 2007 9:23 PM To: Rob Lanphier Cc: sldev@lists.secondlife.com Subject: Re: [sldev] Source release for 1.18.6.0 On 12/6/07, Rob Lanphier wrote: > Good news: Soft is diligently working on getting the build issues > sorted out in the exported code, so that we know this compiles out of > the box for at least one developer. > > Bad news: he wasn't able to get this work done before Anthony posted > this source code. > > Good news: he's heads down on fixing this. I'll let him report when > he's made progress. > > So, unless you're really determined, you'll probably want to hold off > until he gets done before trying to build this code. If anyone wants to grab the Windows source and try compiling, I'd be curious if the existing source works for you. I'm having a really odd time with llviewerapp.cpp. When building the headers, it seems to be pulling in unwanted Quicktime defines for check() and verify(), but I can't yet figure out how they're getting there, or why it's different on the public source drop. _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Wed Dec 19 13:37:55 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Dec 19 13:37:51 2007 Subject: [sldev] Source release for 1.18.6.0 In-Reply-To: References: <1844.24.6.233.189.1196987994.squirrel@mail.lindenlab.com><4758A4BB.6020807@lindenlab.com> Message-ID: <47698F33.60204@dzonux.net> Please, try the instructions that I have wrote up here: http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/Compiling_The_Viewer If that does not solve or provide answers to help in compilation, let us know. =) ashea@ups.com wrote: > This is my first time (ever) compiling the code I have a few error, but > it might just be me. Let me know what I missed please. Here are my > errors, I am using WindowsXP VS2005. > > Warning 1 warning LNK4221: no public symbols found; archive member will > be inaccessible llrect.obj > Error 2 error PRJ0019: A tool returned an error code from "Building > ytab.cpp" lscript_compile_fb_vc8 > Error 3 fatal error C1083: Cannot open source file: '.\lex_yy.cpp': No > such file or directory c1xx > Error 4 fatal error C1083: Cannot open source file: '.\ytab.cpp': No > such file or directory c1xx > Warning 5 warning C4189: 'result' : local variable is initialized but > not referenced > Warning 6 warning C4701: potentially uninitialized local variable 'msg' > used > Error 7 fatal error LNK1181: cannot open input file 'apr-1.lib' > win_crash_logger > Error 8 fatal error C1083: Cannot open include file: 'MacTypes.h': No > such file or directory > Error 9 fatal error C1083: Cannot open include file: 'MacTypes.h': No > such file or directory > Error 10 fatal error C1083: Cannot open include file: 'MacTypes.h': No > such file or directory > Error 11 fatal error C1083: Cannot open include file: 'MacTypes.h': No > such file or directory > Error 12 fatal error C1083: Cannot open include file: 'MacTypes.h': No > such file or directory > > Where do I get MacTypes.h, ytab.cpp, and lex_yy.cpp > > Thanks, > Anthony > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Soft > Sent: Thursday, December 06, 2007 9:23 PM > To: Rob Lanphier > Cc: sldev@lists.secondlife.com > Subject: Re: [sldev] Source release for 1.18.6.0 > > On 12/6/07, Rob Lanphier wrote: > >> Good news: Soft is diligently working on getting the build issues >> sorted out in the exported code, so that we know this compiles out of >> the box for at least one developer. >> >> Bad news: he wasn't able to get this work done before Anthony posted >> this source code. >> >> Good news: he's heads down on fixing this. I'll let him report when >> he's made progress. >> >> So, unless you're really determined, you'll probably want to hold off >> until he gets done before trying to build this code. >> > > If anyone wants to grab the Windows source and try compiling, I'd be > curious if the existing source works for you. I'm having a really odd > time with llviewerapp.cpp. When building the headers, it seems to be > pulling in unwanted Quicktime defines for check() and verify(), but I > can't yet figure out how they're getting there, or why it's different on > the public source drop. > _______________________________________________ > 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/20071219/ee97858c/attachment-0001.htm From robin.cornelius at gmail.com Wed Dec 19 13:49:04 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed Dec 19 13:43:03 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> Message-ID: <476991D0.9060302@gmail.com> Gordon Wendt wrote: > Hi, I'm sure it's documented somewhere but for the life of me I can't > find it but with the current asset issue that's going on I was thinking > of how script saving is handled by the asset server, specifically since > apparently it attempts to save each time you hit save but while it's in > the process of saving you can make a small change (even if you change it > back before hitting save again) then hit save which sends a second > request and how the asset server handles that. Obviously it has to deal > with the second request since that's the most recent change however what > happens to the first save attempt? and is there a way to streamline the > way it deals with such requests since as far as I can tell that seems to > be a fairly intensive operation especially if someone were to do so > repeatedly (can't figure why someone would but people do strange > things). Just a thought. Don't forget that you do a client side compile before the asset is uploaded so that takes a while. And yes *every* time you press save thats a new asset same as with notecard. But good point about making minor changes, its a shame the asset just can't be updated but i assume thats a whole world of additional complications? Robin -------------- 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/20071219/87849af0/signature.pgp From GordonWendt at gmail.com Wed Dec 19 13:58:57 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Dec 19 13:59:06 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <476991D0.9060302@gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> Message-ID: <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> It would be nice if the client sent a drop request before the new save went in that way any pending requests server side were removed before the new one came in, that would save load I think since instead of having to deal with one request that would be immediately overwritten once the second one went through it could deal with the first one and if s second one came through immediately drop the first to work on the next one in the queue which is possibly the second request. We're probably not talking a huge difference here but with heavy asset loads every little bit counts especially when each one is compounded by script saves constantly across the grid. On Dec 19, 2007 4:49 PM, Robin Cornelius wrote: > > Don't forget that you do a client side compile before the asset is > uploaded so that takes a while. And yes *every* time you press save > thats a new asset same as with notecard. But good point about making > minor changes, its a shame the asset just can't be updated but i assume > thats a whole world of additional complications? > > Robin > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/e525683f/attachment.htm From jhurliman at wsu.edu Wed Dec 19 14:05:33 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Dec 19 14:03:44 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> Message-ID: <476995AD.9020802@wsu.edu> The client would just need to cancel any pending asset uploads for that script if a new one was started. Maybe the code already does this, otherwise it could be added without any server side changes needed. John Gordon Wendt wrote: > It would be nice if the client sent a drop request before the new save > went in that way any pending requests server side were removed before > the new one came in, that would save load I think since instead of > having to deal with one request that would be immediately overwritten > once the second one went through it could deal with the first one and > if s second one came through immediately drop the first to work on the > next one in the queue which is possibly the second request. We're > probably not talking a huge difference here but with heavy asset loads > every little bit counts especially when each one is compounded by > script saves constantly across the grid. > > On Dec 19, 2007 4:49 PM, Robin Cornelius > wrote: > > > Don't forget that you do a client side compile before the asset is > uploaded so that takes a while. And yes *every* time you press save > thats a new asset same as with notecard. But good point about making > minor changes, its a shame the asset just can't be updated but i > assume > thats a whole world of additional complications? > > Robin > From GordonWendt at gmail.com Wed Dec 19 14:21:41 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Dec 19 14:21:45 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <476995AD.9020802@wsu.edu> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <476995AD.9020802@wsu.edu> Message-ID: <493033a70712191421y7df0b337k71b8283cfb1bdd5b@mail.gmail.com> I figured that the real work for something like that would be done server side, the client would have to cancel the upload and the upload request but it takes the server to kill off the upload process (thus freeing up processing) which I'm not sure it does at the moment. I've tried fidgeting around client side to try to figure out what effect repeatedly re-saving a script has with little success so your right maybe this is being handled but if it isn't or if it could be tweaked then it could make a difference. On Dec 19, 2007 5:05 PM, John Hurliman wrote: > The client would just need to cancel any pending asset uploads for that > script if a new one was started. Maybe the code already does this, > otherwise it could be added without any server side changes needed. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/14a08db3/attachment.htm From jhurliman at wsu.edu Wed Dec 19 14:34:21 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Dec 19 14:32:17 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <493033a70712191421y7df0b337k71b8283cfb1bdd5b@mail.gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <476995AD.9020802@wsu.edu> <493033a70712191421y7df0b337k71b8283cfb1bdd5b@mail.gmail.com> Message-ID: <47699C6D.1080702@wsu.edu> I assume the server knows how to handle AbortXfer packets, but if you have evidence to show that it doesn't you should file a bug. However I'm not sure that starting a new script upload actually AbortXfers the previous uploads, which could be something to look in to. It doesn't seem like a high priority fix though as CAPS script uploads can't be too far off. Gordon Wendt wrote: > I figured that the real work for something like that would be done > server side, the client would have to cancel the upload and the upload > request but it takes the server to kill off the upload process (thus > freeing up processing) which I'm not sure it does at the moment. I've > tried fidgeting around client side to try to figure out what effect > repeatedly re-saving a script has with little success so your right > maybe this is being handled but if it isn't or if it could be tweaked > then it could make a difference. > > On Dec 19, 2007 5:05 PM, John Hurliman > wrote: > > The client would just need to cancel any pending asset uploads for > that > script if a new one was started. Maybe the code already does this, > otherwise it could be added without any server side changes needed. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Dec 19 14:33:35 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 19 14:33:47 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <493033a70712191421y7df0b337k71b8283cfb1bdd5b@mail.gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <476995AD.9020802@wsu.edu> <493033a70712191421y7df0b337k71b8283cfb1bdd5b@mail.gmail.com> Message-ID: <01D1AA69-4143-4A1C-BA16-1CA5106276AE@gmail.com> Do people frequently hit "save" and then make some changes and hit "save" again without waiting to see the results of the first set of changes? I do that occasionally, but hardly often enough that sending extra packets to cancel uploads would be a net win? Or is this about some automated process, such as saving in the background to improve reliability, so that changes to the script are saved? I don't think that automatically saving assets in the background is a good idea for a number of reasons. It would be better to automatically save open scripts to a local file, and give the user a way to request they be re-uploaded when the asset issues are resolved. From Harleen at comcast.net Wed Dec 19 14:46:51 2007 From: Harleen at comcast.net (Harleen Gretzky) Date: Wed Dec 19 14:46:56 2007 Subject: [sldev] How Asset server handles saving of scripts References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com><476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> Message-ID: <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> Nothing is overwritten, each save is a new asset with a new UUID. ----- Original Message ----- From: Gordon Wendt To: sldev@lists.secondlife.com Sent: Wednesday, December 19, 2007 4:58 PM Subject: Re: [sldev] How Asset server handles saving of scripts It would be nice if the client sent a drop request before the new save went in that way any pending requests server side were removed before the new one came in, that would save load I think since instead of having to deal with one request that would be immediately overwritten once the second one went through it could deal with the first one and if s second one came through immediately drop the first to work on the next one in the queue which is possibly the second request. We're probably not talking a huge difference here but with heavy asset loads every little bit counts especially when each one is compounded by script saves constantly across the grid. On Dec 19, 2007 4:49 PM, Robin Cornelius wrote: Don't forget that you do a client side compile before the asset is uploaded so that takes a while. And yes *every* time you press save thats a new asset same as with notecard. But good point about making minor changes, its a shame the asset just can't be updated but i assume thats a whole world of additional complications? Robin ------------------------------------------------------------------------------ _______________________________________________ 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/20071219/8fcddb3a/attachment-0001.htm From GordonWendt at gmail.com Wed Dec 19 15:16:29 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Dec 19 15:16:32 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <01D1AA69-4143-4A1C-BA16-1CA5106276AE@gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <476995AD.9020802@wsu.edu> <493033a70712191421y7df0b337k71b8283cfb1bdd5b@mail.gmail.com> <01D1AA69-4143-4A1C-BA16-1CA5106276AE@gmail.com> Message-ID: <493033a70712191516h79068b71jcae6e86eb0484958@mail.gmail.com> That would actually be pretty nice (similar to what google does now) however I doubt we'll ever see it just because of the changes that would have to be made to implement it on the backend, the ui, and the client, it just boggles the mind. On Dec 19, 2007 5:33 PM, Argent Stonecutter wrote: > Do people frequently hit "save" and then make some changes and hit > "save" again without waiting to see the results of the first set of > changes? I do that occasionally, but hardly often enough that sending > extra packets to cancel uploads would be a net win? > > Or is this about some automated process, such as saving in the > background to improve reliability, so that changes to the script are > saved? I don't think that automatically saving assets in the > background is a good idea for a number of reasons. It would be better > to automatically save open scripts to a local file, and give the user > a way to request they be re-uploaded when the asset issues are resolved. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/951cba75/attachment.htm From me at hamncheeseomlet.com Wed Dec 19 15:26:00 2007 From: me at hamncheeseomlet.com (Hamncheese) Date: Wed Dec 19 15:26:13 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com><476991D0.9060302@gmail.com><493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> Message-ID: <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> This is done probably for performance reasons. It is more performant to insert a new row in a table than to locate, lock, and then update, release lock. Also, I'm pretty sure that script uploads go through CAPS today. The client side compile, then upload model (see LLPreviewLSL::uploadAssetLegacy) is being ditched in favor of upload file over HTTPClient::Post (see LLPreviewLSL::uploadAssetViaCaps). Part of the disconnect of the missing asset problem is that when LL personnel (QA, etc) run SL they go through legacy instead of CAPS (from what I can tell). What I think the developer forgot in the CAPS model is that HTTP is not guaranteed delivery (upstream or downstream). I think to get a definitive answer, you need to talk to someone at LL, because all this is largely guess work on my part. ----- Original Message ----- From: Harleen Gretzky To: Gordon Wendt ; sldev@lists.secondlife.com Sent: Wednesday, December 19, 2007 5:46 PM Subject: Re: [sldev] How Asset server handles saving of scripts Nothing is overwritten, each save is a new asset with a new UUID. ----- Original Message ----- From: Gordon Wendt To: sldev@lists.secondlife.com Sent: Wednesday, December 19, 2007 4:58 PM Subject: Re: [sldev] How Asset server handles saving of scripts It would be nice if the client sent a drop request before the new save went in that way any pending requests server side were removed before the new one came in, that would save load I think since instead of having to deal with one request that would be immediately overwritten once the second one went through it could deal with the first one and if s second one came through immediately drop the first to work on the next one in the queue which is possibly the second request. We're probably not talking a huge difference here but with heavy asset loads every little bit counts especially when each one is compounded by script saves constantly across the grid. On Dec 19, 2007 4:49 PM, Robin Cornelius wrote: Don't forget that you do a client side compile before the asset is uploaded so that takes a while. And yes *every* time you press save thats a new asset same as with notecard. But good point about making minor changes, its a shame the asset just can't be updated but i assume thats a whole world of additional complications? Robin _______________________________________________ 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 Dec 19 15:38:28 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Dec 19 15:38:30 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com><476991D0.9060302@gmail.com><493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> Message-ID: Well, personally, at the moment, I'd just like to be able to save scripts! All I get is an asset upload failed everytime I attempt to save a script and this is *after* the blog has declared an All Clear on the asset servers! Matthew _________________________________________________________________ Free games, great prizes - get gaming at Gamesbox. http://www.searchgamesbox.com From GordonWendt at gmail.com Wed Dec 19 15:51:51 2007 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed Dec 19 15:51:54 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> Message-ID: <493033a70712191551v1695a8caj37d48451c3e1b9a3@mail.gmail.com> I know the feeling, there's several forum threads and from the jira update list I've seen at least one jira issue on the subject and I was hoping on actually getting some work done on a few Christmas time products I'm hoping to have ready to sell :( On Dec 19, 2007 6:38 PM, Matthew Dowd wrote: > > Well, personally, at the moment, I'd just like to be able to save scripts! > All I get is an asset upload failed everytime I attempt to save a script and > this is *after* the blog has declared an All Clear on the asset servers! > > Matthew > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/481d0458/attachment.htm From odysseus654 at gmail.com Wed Dec 19 16:46:07 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Wed Dec 19 16:46:10 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> Message-ID: <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> You sure about this? I always thought this was a caching issue, so a sim can say "the UUID is one that I already have, and assets cannot be modified, so no reason to ask for fresh content from the asset server". The thing is, prims aren't affected by this "dirty write" system, why just notecards and scripts? On Dec 19, 2007 3:26 PM, Hamncheese wrote: > This is done probably for performance reasons. It is more performant to > insert a new row in a table than to locate, lock, and then update, release > lock. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/b1f328e8/attachment.htm From secret.argent at gmail.com Wed Dec 19 17:07:02 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 19 17:07:09 2007 Subject: [sldev] Automatically backing up scripts locally. References: Message-ID: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> Since this is really a separate issue from how the asset server saves assets, a new thread. On 2007-12-19, at 17:15, Gordon Wendt wrote: > That would actually be pretty nice (similar to what google does > now) however I doubt we'll ever see it just because of the changes > that would have to be made to implement it on the backend, the ui, > and the client, it just boggles the mind. Which is why I suggested that the following alternative would be more useful: >> It would be better >> to automatically save open scripts to a local file, and give the user >> a way to request they be re-uploaded when the asset issues are >> resolved. Dale? Nicolaz? This is something that's completely client-side. From secret.argent at gmail.com Wed Dec 19 17:07:56 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 19 17:08:01 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> Message-ID: <22E5BAD3-A830-402E-B146-983E1AE869BC@gmail.com> On 2007-12-19, at 18:46, Erik Anderson wrote: > You sure about this? I always thought this was a caching issue, so > a sim can say "the UUID is one that I already have, and assets > cannot be modified, so no reason to ask for fresh content from the > asset server". The thing is, prims aren't affected by this "dirty > write" system, why just notecards and scripts? Prims aren't stored on the asset server, they're stored on the sim. From dale at daleglass.net Wed Dec 19 17:16:39 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Dec 19 17:16:49 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> Message-ID: <200712200216.43659.dale@daleglass.net> On Thursday 20 December 2007 02:07:02 Argent Stonecutter wrote: > >> It would be better > >> to automatically save open scripts to a local file, and give the user > >> a way to request they be re-uploaded when the asset issues are > >> resolved. > > Dale? Nicolaz? This is something that's completely client-side. I like the idea, although I'm quite busy already, unfortunately. Sounds easy enough, although there's a potential issue with scripts being edited inside objects. I guess an easy solution would be taking note of where the object being edited was, and if the script can't be reuploaded tell the user and save to the inventory. Or something like that. -------------- 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/20071220/9965e8a5/attachment-0001.pgp From secret.argent at gmail.com Wed Dec 19 17:30:33 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 19 17:30:40 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <200712200216.43659.dale@daleglass.net> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> Message-ID: <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> On 2007-12-19, at 19:16, Dale Glass wrote: > I like the idea, although I'm quite busy already, unfortunately. Me too. :( > Sounds easy enough, although there's a potential issue with scripts > being > edited inside objects. I guess an easy solution would be taking > note of > where the object being edited was, and if the script can't be > reuploaded > tell the user and save to the inventory. Well, I was thinking more like letting the user know there was an un- uploaded script when they connected, and let them decide what to do with it. I mean, you wouldn't want it to overwrite a script in an object inventory with an old version because you'd already re-done the edits elsewhere. Hell, I'd be satisfied with a preference option "Save copy of scripts and notecards in [~/Documents/SL]", and have it ALWAYS write "scriptname.lsl" or "notecardname.txt" in that folder when I hit save. From kelly at lindenlab.com Wed Dec 19 17:46:22 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Wed Dec 19 17:46:39 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> Message-ID: <4769C96E.8030507@lindenlab.com> Erik Anderson wrote: > You sure about this? I always thought this was a caching issue, so a > sim can say "the UUID is one that I already have, and assets cannot be > modified, so no reason to ask for fresh content from the asset > server". The thing is, prims aren't affected by this "dirty write" > system, why just notecards and scripts? > > On Dec 19, 2007 3:26 PM, Hamncheese > wrote: > > This is done probably for performance reasons. It is more > performant to > insert a new row in a table than to locate, lock, and then update, > release > lock. > > > An asset system vs inventory vs simulator run down might be useful here. The asset system is a giant ass web server cluster that implements the fairly standard WebDAV interface. It is fancy only in its design for redundancy and handling large amounts of requests. I am not going to comment on today's issues any more than to say some things don't always work the way they should. :( "Assets" are stored static datasets that are always written just once. All textures, notecards and scripts fall in this category, as well as landmarks and clothing items etc. These are items that don't get simulated, as well as objects (which do get simulated) that are not currently being simulated. These are essentially files on the giant ass web server cluster, they aren't being actively simulated and they don't exist in a DB. So when you take an object into inventory the dataset that describes the object is saved to the asset system, and a row is updated in the DB for the inventory item (see below). Yes the write once helps tremendously with caching, you know if you have that specific version of an asset by the ID alone. Inventory on the other hand is stored in a Database and is essentially a set of links to assets plus some meta data (mostly relating to permissions). When you rez an inventory item what really happens is the simulator looks up the asset ID for the specific inventory item and pulls the data from the asset system to create a copy to actively simulate. It also applies any meta data changes made to the inventory item to the newly rezed object. Objects that are in the simulator are actively being simulated. Their state may differ significantly from the asset that was originally rezed, and no new version is saved to the asset server until it is taken into inventory. Simulators themselves create assets known as Simstates on a regular basis that are a serialized version of the state of the entire region being simulated including the data that would be an object's asset. These simstates are created on a regular basis and stored either on a local simulator host or (usually) on the asset server. When you save a script new assets are created and uploaded through the simulator (or caps server) to the asset cluster. If modifying a script in your inventory the inventory DB must be updated to reflect that it points to the new asset. If it is a script in an object the simulator can update the asset id that object-inventory item points to purely in memory. Maybe that will cause more clarity than confusion .... but maybe not. :D - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071219/ae423e1b/attachment.htm From dzonatas at dzonux.net Wed Dec 19 18:00:35 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Dec 19 18:00:29 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> Message-ID: <4769CCC3.1000309@dzonux.net> Argent Stonecutter wrote: > On 2007-12-19, at 19:16, Dale Glass wrote: >> I like the idea, although I'm quite busy already, unfortunately. > > Me too. :( > >> Sounds easy enough, although there's a potential issue with scripts >> being >> edited inside objects. I guess an easy solution would be taking note of >> where the object being edited was, and if the script can't be reuploaded >> tell the user and save to the inventory. > > Well, I was thinking more like letting the user know there was an > un-uploaded script when they connected, and let them decide what to do > with it. I mean, you wouldn't want it to overwrite a script in an > object inventory with an old version because you'd already re-done the > edits elsewhere. > > Hell, I'd be satisfied with a preference option "Save copy of scripts > and notecards in [~/Documents/SL]", and have it ALWAYS write > "scriptname.lsl" or "notecardname.txt" in that folder when I hit save. Is it a project worth invoicing LL to get done? =) -- Power to Change the Void From robin.cornelius at gmail.com Thu Dec 20 00:42:54 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu Dec 20 00:42:58 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> Message-ID: On Dec 19, 2007 10:46 PM, Harleen Gretzky wrote: > > > Nothing is overwritten, each save is a new asset with a new UUID. > But is there any record of the last UUID? and is it possible to recall a script from just a UUID? Together that could be useful for recovering work. But a automated client save would probably be better. Robin From gigstaggart at gmail.com Thu Dec 20 01:15:34 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Dec 20 01:14:53 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> Message-ID: <476A32B6.3060605@gmail.com> Erik Anderson wrote: > You sure about this? I always thought this was a caching issue, so a > sim can say "the UUID is one that I already have, and assets cannot be > modified, so no reason to ask for fresh content from the asset server". > The thing is, prims aren't affected by this "dirty write" system, why > just notecards and scripts? It can be both. Copy-on-Update has a lot of benefits, and caching is a big one. -Jason From adam at gwala.net Thu Dec 20 03:15:59 2007 From: adam at gwala.net (Adam Frisby) Date: Thu Dec 20 03:16:17 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> Message-ID: <476A4EEF.4040108@gwala.net> Why not save it as the name + UUID to avoid any kind of collision between objects (IE, I'd have ten thousand New Script.lsl's) Regards, Adam Argent Stonecutter wrote: > On 2007-12-19, at 19:16, Dale Glass wrote: > >> I like the idea, although I'm quite busy already, unfortunately. > > > Me too. :( > >> Sounds easy enough, although there's a potential issue with scripts >> being >> edited inside objects. I guess an easy solution would be taking note of >> where the object being edited was, and if the script can't be reuploaded >> tell the user and save to the inventory. > > > Well, I was thinking more like letting the user know there was an un- > uploaded script when they connected, and let them decide what to do > with it. I mean, you wouldn't want it to overwrite a script in an > object inventory with an old version because you'd already re-done the > edits elsewhere. > > Hell, I'd be satisfied with a preference option "Save copy of scripts > and notecards in [~/Documents/SL]", and have it ALWAYS write > "scriptname.lsl" or "notecardname.txt" in that folder when I hit save. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From me at hamncheeseomlet.com Thu Dec 20 05:47:27 2007 From: me at hamncheeseomlet.com (Hamncheese) Date: Thu Dec 20 05:47:35 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> Message-ID: <8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream> No I'm not sure about anything I said and I wasn't when I said it. Based on Kelly's description, I went back and did a packet sniff on a script save that is in object inventory and a script save that is in regular inventory. I'm going to have to dig into my CAPS vs legacy assumptions. It is clearly pushing the script in clear text through UDP to 63.210.157.63:13006 in both cases but I'm not sure if that is the whole story. ----- Original Message ----- From: Erik Anderson To: Hamncheese Cc: sldev@lists.secondlife.com Sent: Wednesday, December 19, 2007 7:46 PM Subject: Re: [sldev] How Asset server handles saving of scripts You sure about this? I always thought this was a caching issue, so a sim can say "the UUID is one that I already have, and assets cannot be modified, so no reason to ask for fresh content from the asset server". The thing is, prims aren't affected by this "dirty write" system, why just notecards and scripts? On Dec 19, 2007 3:26 PM, Hamncheese wrote: This is done probably for performance reasons. It is more performant to insert a new row in a table than to locate, lock, and then update, release lock. From secret.argent at gmail.com Thu Dec 20 08:43:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 08:43:33 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <476A4EEF.4040108@gwala.net> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> Message-ID: <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> On 2007-12-20, at 05:15, Adam Frisby wrote: > Why not save it as the name + UUID to avoid any kind of collision > between objects (IE, I'd have ten thousand New Script.lsl's) Because I was writing about what I'd be satisfied with. Not designing the ultimate not-quite-a-source-control-system-for-SL. But now that you mention it I'm not sure that I'd want 10,000 files named "ANOTHER-DAMN-UUID_New_Script.lsl" instead of just the one that I happened to have saved last. Plus I don't believe the server tells you the UUID of the object you just uploaded, wasn't there a discussion recently about how to find that out? I guess you'll see it when you get the object updates after the save, but once it's saved you don't need the backup (at least not for what I was thinking of). For archival purposes: perhaps save it to ScriptName.lsl and then rename it to ScriptName.UUID.lsl once it's saved? If you want the ideal scheme... maybe something like this (modulo symlink errors): SLBackup ObjectName -> Region1/ObjectName # Rezzed objects exist in regions Region1 ObjectName -> ObjectName.UUID2 # Names aren't unique, UUIDs are ObjectName.UUID1 Stuff in that other copy of ObjectName ObjectName.UUID2 # Rezzed object *do* have a unique name, use that. Properties.xml -- object properties Linkset # Linksets are part of objects RootPrim.UUID3 -> ../../Assets/RootPrim.UUID3 AnotherPrimName.UUID4 -> ../../Assets/AnotherPrimName.UUID4 Assets RootPrim.UUID3 # I think names of rezzed assets are unique Parameters.xml -- prim parameters ScriptName.lsl -> ScriptName.2007-12-20.lsl # Hasn't been saved yet ScriptName.2007-12-20.lsl AnotherScript.lsl -> ../../Assets/ScriptName.UUID5 TextureName -> ../../../Assets/TEXTURE_UUID.png # UUIDs are unique, but could have a different name in invemntory AnotherTextureName -> ../../../Assets/ANOTHER_TEXTURE_UUID.png NoCopyObjectName -> Missing/OBJECT_UUID # Dead link for missing UUIDs because of perms or whatever AnotherObject -> ../../../Assets/ANOTHER_OBJECT_UUID # Hasn't been rezzed, is not in region's assets? ScriptName.UUID5 Script.lsl -> ../UUID5.lsl State.xml # Running, etc... UUID5.lsl Assets # Assets on asset server or unknown region TEXTURE_UUID.png ANOTHER_TEXTURE_UUID.png ANOTHER_OBJECT_UUID Parameters.xml UUID6.lsl Inventory Scripts ScriptInInventory -> ../../Assets/UUID6.lsl From dzonatas at dzonux.net Thu Dec 20 08:50:11 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Dec 20 08:50:05 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> Message-ID: <476A9D43.2070707@dzonux.net> There is already system that does exactly your ideal scheme and much more: http://jira.secondlife.com/browse/MISC-830 No need to reinvent the wheel. It offers complete asset exchange and filter processes in the scheme. Argent Stonecutter wrote: > On 2007-12-20, at 05:15, Adam Frisby wrote: >> Why not save it as the name + UUID to avoid any kind of collision >> between objects (IE, I'd have ten thousand New Script.lsl's) > > Because I was writing about what I'd be satisfied with. Not designing > the ultimate not-quite-a-source-control-system-for-SL. > > But now that you mention it I'm not sure that I'd want 10,000 files > named "ANOTHER-DAMN-UUID_New_Script.lsl" instead of just the one that > I happened to have saved last. Plus I don't believe the server tells > you the UUID of the object you just uploaded, wasn't there a > discussion recently about how to find that out? I guess you'll see it > when you get the object updates after the save, but once it's saved > you don't need the backup (at least not for what I was thinking of). > For archival purposes: perhaps save it to ScriptName.lsl and then > rename it to ScriptName.UUID.lsl once it's saved? > > If you want the ideal scheme... maybe something like this (modulo > symlink errors): > > SLBackup > ObjectName -> Region1/ObjectName # Rezzed objects exist in regions > Region1 > ObjectName -> ObjectName.UUID2 # Names aren't unique, UUIDs are > ObjectName.UUID1 > Stuff in that other copy of ObjectName > ObjectName.UUID2 # Rezzed object *do* have a unique > name, use that. > Properties.xml -- object properties > Linkset # Linksets are part of objects > RootPrim.UUID3 -> ../../Assets/RootPrim.UUID3 > AnotherPrimName.UUID4 -> ../../Assets/AnotherPrimName.UUID4 > Assets > RootPrim.UUID3 # I think names of rezzed assets are > unique > Parameters.xml -- prim parameters > ScriptName.lsl -> ScriptName.2007-12-20.lsl # Hasn't > been saved yet > ScriptName.2007-12-20.lsl > AnotherScript.lsl -> ../../Assets/ScriptName.UUID5 > TextureName -> ../../../Assets/TEXTURE_UUID.png # UUIDs > are unique, but could have a different name in invemntory > AnotherTextureName -> ../../../Assets/ANOTHER_TEXTURE_UUID.png > NoCopyObjectName -> Missing/OBJECT_UUID # Dead link for > missing UUIDs because of perms or whatever > AnotherObject -> ../../../Assets/ANOTHER_OBJECT_UUID # > Hasn't been rezzed, is not in region's assets? > ScriptName.UUID5 > Script.lsl -> ../UUID5.lsl > State.xml # Running, etc... > UUID5.lsl > Assets # Assets on asset server or unknown region > TEXTURE_UUID.png > ANOTHER_TEXTURE_UUID.png > ANOTHER_OBJECT_UUID > Parameters.xml > UUID6.lsl > Inventory > Scripts > ScriptInInventory -> ../../Assets/UUID6.lsl > > _______________________________________________ > 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 Thu Dec 20 10:01:40 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 10:01:47 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <476A9D43.2070707@dzonux.net> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> Message-ID: <894D37DA-E678-450C-98B9-B69E160025F7@gmail.com> On 2007-12-20, at 10:50, Dzonatas wrote: > There is already system that does exactly your ideal scheme and > much more: Does that provide a complete unmodified roundtrip capability for all parameters, properties, and content of all SL assets? If not, it's not usable as a backup format. From jhurliman at wsu.edu Thu Dec 20 10:11:41 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Dec 20 10:09:41 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> <8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream> Message-ID: <476AB05D.6060400@wsu.edu> It should also be pushing the script binary using the same Xfer (UDP) system IIRC. Pretty sure the only uploads that are using CAPS right now are textures and this seems to confirm it. Useless trivia: If there is a compile error the script source code is uploaded anyways, but no compiled binary. OpenSim uses this to their advantage; if you place a precompiler directive at the top of the file to indicate it is another language the viewer will fail to compile it but upload the plaintext, and the simulator will do server-side compilation of the script and run it. Hamncheese wrote: > No I'm not sure about anything I said and I wasn't when I said it. > Based on Kelly's description, I went back and did a packet sniff on a > script save that is in object inventory and a script save that is in > regular inventory. I'm going to have to dig into my CAPS vs legacy > assumptions. It is clearly pushing the script in clear text through > UDP to 63.210.157.63:13006 in both cases but I'm not sure if that is > the whole story. > > ----- Original Message ----- From: Erik Anderson > To: Hamncheese > Cc: sldev@lists.secondlife.com > Sent: Wednesday, December 19, 2007 7:46 PM > Subject: Re: [sldev] How Asset server handles saving of scripts > > > You sure about this? I always thought this was a caching issue, so a > sim can say "the UUID is one that I already have, and assets cannot be > modified, so no reason to ask for fresh content from the asset > server". The thing is, prims aren't affected by this "dirty write" > system, why just notecards and scripts? > > > On Dec 19, 2007 3:26 PM, Hamncheese wrote: > > This is done probably for performance reasons. It is more performant to > insert a new row in a table than to locate, lock, and then update, > release > lock. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From jhurliman at wsu.edu Thu Dec 20 10:13:35 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Dec 20 10:11:29 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> Message-ID: <476AB0CF.8090009@wsu.edu> Robin Cornelius wrote: > On Dec 19, 2007 10:46 PM, Harleen Gretzky wrote: > >> Nothing is overwritten, each save is a new asset with a new UUID. >> >> > > But is there any record of the last UUID? and is it possible to recall > a script from just a UUID? > > There can be if you want, and yes until garbage collection cleans it up (assuming there are no references to the old script source). From jhurliman at wsu.edu Thu Dec 20 10:19:36 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Dec 20 10:17:30 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> Message-ID: <476AB238.7040800@wsu.edu> Argent Stonecutter wrote: > > ... Plus I don't believe the server tells you the UUID of the object > you just uploaded, wasn't there a discussion recently about how to > find that out? ... You already know the UUID before the upload starts in the Xfer system. The client generates a random UUID that when MD5ed together with the current SecureSessionID (a shared secret between client and server) gives you the future AssetID. The random UUID is sent in the upload initiation packet, so before the data is even sent across the wire the client knows what the AssetID will be, and the server knows after the first packet is sent. Fun fact: If you somehow get ahold of an enormous amount of computing power, or figure out a way to build rainbow tables extremely fast you could orchestrate AssetID collisions which would be guaranteed entertainment. The possibility of either or those things happening is probably pretty low though. John From ordinal.malaprop at fastmail.fm Thu Dec 20 10:18:49 2007 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Thu Dec 20 10:18:59 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> Message-ID: <04598093-16A7-41F6-AD49-92F37230B3CA@fastmail.fm> Ugh. Certainly not. I may make several edits and recompiles a minute to a script; even if I _wasn't_ editing them offline and pasting them in, I wouldn't want that many versions. Really, scripts and notecards are the easiest thing to maintain versions of anyway. I really don't think there's a huge call for an aggressive automatic backup system - or, well, it's not something for consideration in a main client. Being able to backup whole objects (the ones that I don't have backups of and where "script is not missing from database") or entire inventories, though, maybe just once and then archive them, or maybe with a tick-box and a time interval - that's the thing. On 20 Dec 2007, at 16:43, Argent Stonecutter wrote: > But now that you mention it I'm not sure that I'd want 10,000 files > named "ANOTHER-DAMN-UUID_New_Script.lsl" instead of just the one > that I happened to have saved last. From secret.argent at gmail.com Thu Dec 20 10:43:42 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 10:43:47 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <476A9D43.2070707@dzonux.net> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> Message-ID: OK, I've looked at the COLLADA spec, and it doesn't seem to have anything to do with what I'm talking about here. * The primitive object is a mesh, there's no mechanism to encode parametric geometry. * There's no mechanism to encode the contents of objects. * There's no mechanism to encode SL-specific content, such as scripts. * There's no mechanism to describe the relationships between the backup and in-world assets. The overall structure of region objects, region assets, object contents, and global assets represented by the files, directories, and symlinks would need to be retained. Not only doesn't COLLADA have any comparable structure, but also ince this is a mirror backup of ongoing work: this really would need to stay in the filesystem. In addition, for the individual assets, about the only things for which the portable format would be useful would be textures, animations, and sounds. And these would be better off stored as tga or png files, bvh files, and flac files referenced by name from any COLLADA objects. Everything else would be in elements. It would be useful to include COLLADA descriptions of object meshes, but that wouldn't be used in restoring a backup. I don't see COLLADA as being relevant, other than adding a "COLLADA.xml" file to each object directory, and maybe having the ability to select a set of objects and snapshot them... but it would really be more useful to make that a separate tool. From secret.argent at gmail.com Thu Dec 20 10:46:18 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 10:46:24 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <476AB05D.6060400@wsu.edu> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> <8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream> <476AB05D.6060400@wsu.edu> Message-ID: On 2007-12-20, at 12:11, John Hurliman wrote: > Useless trivia: If there is a compile error the script source code > is uploaded anyways, but no compiled binary. OpenSim uses this to > their advantage; if you place a precompiler directive at the top of > the file to indicate it is another language the viewer will fail to > compile it but upload the plaintext, and the simulator will do > server-side compilation of the script and run it. Yeh, I know about this. It's silly, because the client source tree already contains the code to generate CIL from LSL. From secret.argent at gmail.com Thu Dec 20 10:51:25 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 10:51:31 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <04598093-16A7-41F6-AD49-92F37230B3CA@fastmail.fm> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <04598093-16A7-41F6-AD49-92F37230B3CA@fastmail.fm> Message-ID: On 2007-12-20, at 12:18, ordinal.malaprop@fastmail.fm wrote: > Really, scripts and notecards are the easiest thing to maintain > versions of anyway. I really don't think there's a huge call for an > aggressive automatic backup system - or, well, it's not something > for consideration in a main client. One that just saves the file you're editing to disk when you hit save, without versioning, by script or notecard name, in a single directory... that would be a huge win. I don't see that as being "aggressive". I see that as being "the minimum expected effort". From dzonatas at dzonux.net Thu Dec 20 10:54:00 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Dec 20 10:53:53 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> Message-ID: <476ABA48.7030508@dzonux.net> Those mechanisms are there. What you probably compared is data that is common as being interoperable with different virtual worlds than data being stored as a single unit for one particular virtual world. Not all virtual worlds need all the data and mechanisms you described. Of course, SL does. It will appear like meta data until there is more collaboration with COLLADA itself -- as it is open source. As for those lists of virtual worlds that have started to interoperate, SL is not common as of yet. You can settle for a hack to just back up scripts for now. Argent Stonecutter wrote: > OK, I've looked at the COLLADA spec, and it doesn't seem to have > anything to do with what I'm talking about here. > > * The primitive object is a mesh, there's no mechanism to encode > parametric geometry. > * There's no mechanism to encode the contents of objects. > * There's no mechanism to encode SL-specific content, such as scripts. > * There's no mechanism to describe the relationships between the > backup and in-world assets. > > The overall structure of region objects, region assets, object > contents, and global assets represented by the files, directories, and > symlinks would need to be retained. Not only doesn't COLLADA have any > comparable structure, but also ince this is a mirror backup of ongoing > work: this really would need to stay in the filesystem. > > In addition, for the individual assets, about the only things for > which the portable format would be useful would be textures, > animations, and sounds. And these would be better off stored as tga or > png files, bvh files, and flac files referenced by name from any > COLLADA objects. Everything else would be in elements. It > would be useful to include COLLADA descriptions of object meshes, but > that wouldn't be used in restoring a backup. > > I don't see COLLADA as being relevant, other than adding a > "COLLADA.xml" file to each object directory, and maybe having the > ability to select a set of objects and snapshot them... but it would > really be more useful to make that a separate tool. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From donovan at lindenlab.com Thu Dec 20 11:19:07 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Thu Dec 20 11:19:16 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <47683D28.30803@lindenlab.com> Message-ID: On Dec 19, 2007, at 12:25 PM, Argent Stonecutter wrote: > That pretty much *is* the web-service API I was referring to. The > only difference is that I suggested that a successful response > should be a redirect to the "secondlife:" URI described in the > original announcement. That allows the normal HTTP response codes to > do the rest of the job. I'm confused by this. Currently, a successful response from the go.php service *is* a redirect to the "secondlife:" URI. I am going to attempt to add llsd content type encoding for the input to go.php today (instead of multipart/mime it currently accepts from the embedded browser). This will reduce the number of protocols required to log in and make it easier for viewers built without llmozlib to log in without knowing how to generate multipart/mime. However, what is the llsd-supporting version of go.php to do when authentication does not succeed? I think you're on the right track, comments below. >> The tricky part here is what to do when login fails. > > That's covered in the response codes. HTTP is designed for this > situation. > > Successful login: > 303 Success-message-for-user > Location: secondlife:... > Other-headers... > > -- no body --- > > Authentication failure: > 403 Failure-message-for-user > Headers... > > HTML error message 403 is "Forbidden", and the rfc says the client shouldn't *ever* bother trying again, cause it ain't gonna work. So I don't think this is what we want. > Server failure: > 5xx Message-for-user > Headers... > > HTML error message This would only be used if the server choked and died. > Special handling: > 307 Message-for-user > Location: URL requesting more information > Other-headers... > > --- no body --- I think one of the redirects is right. 307 is probably right because it's not cacheable. In practice it doesn't matter since POST isn't cacheable anyway. So I think the heuristic should be: Successful login, redirect to secondlife: URI. Additional information required, redirect to https: URL. > The viewer doesn't require any new complex code. No matter what the > response is, it contains a message to display to the user. If a web > page display is required, it contains a redirect to that page. The > client can display that in llMozLib or redirect to an external > browser. It can even use the existing framework for llLoadURL to > give the user a dialog approving that redirect. Sounds great. Donovan From donovan at lindenlab.com Thu Dec 20 11:31:31 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Thu Dec 20 11:31:39 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <476AB05D.6060400@wsu.edu> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> <8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream> <476AB05D.6060400@wsu.edu> Message-ID: <7E68B062-7227-468C-AB9A-27C12143E175@lindenlab.com> On Dec 20, 2007, at 10:11 AM, John Hurliman wrote: > It should also be pushing the script binary using the same Xfer > (UDP) system IIRC. Pretty sure the only uploads that are using CAPS > right now are textures and this seems to confirm it. Server-side script compilation, which uses a capability to upload, has been done for a year now, but it's in Branch_MONO. So hopefully it'll be on agni sometime in 2008... :-) Donovan From jhurliman at wsu.edu Thu Dec 20 11:37:19 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Dec 20 11:35:13 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> <8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream> <476AB05D.6060400@wsu.edu> Message-ID: <476AC46F.5090805@wsu.edu> Argent Stonecutter wrote: > On 2007-12-20, at 12:11, John Hurliman wrote: >> Useless trivia: If there is a compile error the script source code is >> uploaded anyways, but no compiled binary. OpenSim uses this to their >> advantage; if you place a precompiler directive at the top of the >> file to indicate it is another language the viewer will fail to >> compile it but upload the plaintext, and the simulator will do >> server-side compilation of the script and run it. > > Yeh, I know about this. It's silly, because the client source tree > already contains the code to generate CIL from LSL. OpenSim doesn't have an adequate CIL sandbox to trust random binaries from clients, no one has that (yet). The first version of Mono's CoreCLR security is out, and I understand Babbage designed his own for SL, but I would like to see some sort of audit on them before trusting a system with it*. Additionally, you would have to run a modified client to actually produce and upload that CIL which no one is doing right now, and you still wouldn't have support for all of the languages OpenSim is currently supporting such as Javascript. * I hope there is some way to prevent code from using any sort of reflection at the runtime level, because it seems like that would subvert any security model you could think of From donovan at lindenlab.com Thu Dec 20 11:47:45 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Thu Dec 20 11:48:23 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <476AC46F.5090805@wsu.edu> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> <8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream> <476AB05D.6060400@wsu.edu> <476AC46F.5090805@wsu.edu> Message-ID: On Dec 20, 2007, at 11:37 AM, John Hurliman wrote: > OpenSim doesn't have an adequate CIL sandbox to trust random > binaries from clients, no one has that (yet). The first version of > Mono's CoreCLR security is out, and I understand Babbage designed > his own for SL, but I would like to see some sort of audit on them > before trusting a system with it*. Additionally, you would have to > run a modified client to actually produce and upload that CIL which > no one is doing right now, and you still wouldn't have support for > all of the languages OpenSim is currently supporting such as > Javascript. Babbage has not designed a bytecode verifier. Babbage would know more, but I think he prodded the mono community and was going to wait for them to step up for this one, and it sounds like CoreCLR might be that piece, or something like it. However, the initial mono design involves server-side compilation so that we can get away with running bytecode we created, without sandboxing. > * I hope there is some way to prevent code from using any sort of > reflection at the runtime level, because it seems like that would > subvert any security model you could think of I don't really think it's that difficult with a sandbox and a capability security model. Any references the bytecode is able to reach are references it should be allowed to see. Does the CLR have a run-time "eval" or compile code function? If so, that would need to be extended to call the bytecode verifier. In other words, the eval you put in the sandbox is your own custom eval which calls the generic eval and then runs the bytecode verifier, raising exceptions if it fails. Since the bytecode will then be run in the same sandbox as the code that called eval, it will be subject to the same restrictions on what objects it is able to access. Donovan From ordinal.malaprop at fastmail.fm Thu Dec 20 11:53:58 2007 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop@fastmail.fm) Date: Thu Dec 20 11:54:04 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <04598093-16A7-41F6-AD49-92F37230B3CA@fastmail.fm> Message-ID: <8F9F12F7-E7B9-4080-8D68-212FBEDA9CCB@fastmail.fm> It would help a lot of people certainly, particularly those who have not yet been burned by script loss - it was the every-version thing that I considered overly aggressive. Of course, it's not that much use if everything is called "New Script". Perhaps a timestamp as well, to the nearest X minutes definable via preferences. On 20 Dec 2007, at 18:51, Argent Stonecutter wrote: > On 2007-12-20, at 12:18, ordinal.malaprop@fastmail.fm wrote: >> Really, scripts and notecards are the easiest thing to maintain >> versions of anyway. I really don't think there's a huge call for an >> aggressive automatic backup system - or, well, it's not something >> for consideration in a main client. > > One that just saves the file you're editing to disk when you hit > save, without versioning, by script or notecard name, in a single > directory... that would be a huge win. I don't see that as being > "aggressive". I see that as being "the minimum expected effort". > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From secret.argent at gmail.com Thu Dec 20 12:23:21 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 12:23:27 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <476ABA48.7030508@dzonux.net> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> <476ABA48.7030508@dzonux.net> Message-ID: <4F88F3B1-D063-459D-B204-B1F7CC0BC83E@gmail.com> On 2007-12-20, at 12:54, Dzonatas wrote: > Those mechanisms are there. What you probably compared is data that > is common as being interoperable with different virtual worlds than > data being stored as a single unit for one particular virtual world. Yes, I know about the world-specific data. The world-specific data in COLLADA is in the elements. That's why I wrote "everything else would be in elements". That is "I already said that". In addition, the relationship between the backed-up assets and in- world objects is out of scope of COLLADA. It's a data transfer format, not a backup format. Unless (as I said) you duplicate the rest of the structure, backing up to COLLADA would be like backing up an SQL database by dumping the tables without the schema. > You can settle for a hack to just back up scripts for now. I already said that, too. From sldev at free.fr Thu Dec 20 12:43:34 2007 From: sldev at free.fr (Henri Beauchamp) Date: Thu Dec 20 12:43:36 2007 Subject: [sldev] Sources for FL v1.18.6.75762, please ? In-Reply-To: <4767FF08.8050900@lindenlab.com> References: <20071218161858.1f9c6d5e.sldev@free.fr> <4767FF08.8050900@lindenlab.com> Message-ID: <20071220214334.72850cf8.sldev@free.fr> On Tue, 18 Dec 2007 12:10:32 -0500, Brad Kittenbrink wrote: > Henri Beauchamp wrote: > > Hello, > > > > Could someone please make the FL v1.18.6.75762 sources available on the Wiki ? > > > > Thx. > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > I will be doing this later today. Sorry about the delay. > > -Brad Linden Hmm... Still no sources... :-/ From secret.argent at gmail.com Thu Dec 20 13:05:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 13:05:15 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <47683D28.30803@lindenlab.com> Message-ID: On 2007-12-20, at 13:19, Donovan Preston wrote: > On Dec 19, 2007, at 12:25 PM, Argent Stonecutter wrote: >> That pretty much *is* the web-service API I was referring to. The >> only difference is that I suggested that a successful response >> should be a redirect to the "secondlife:" URI described in the >> original announcement. That allows the normal HTTP response codes >> to do the rest of the job. > > I'm confused by this. Currently, a successful response from the > go.php service *is* a redirect to the "secondlife:" URI. That's what I thought, but Tess was talking about "parsing" it out, which isn't quite how I'd describe reading the "Location:" header. >>> The tricky part here is what to do when login fails. >> >> That's covered in the response codes. HTTP is designed for this >> situation. >> >> Successful login: >> 303 Success-message-for-user >> Location: secondlife:... >> Other-headers... >> >> -- no body --- >> >> Authentication failure: >> 403 Failure-message-for-user >> Headers... >> >> HTML error message > > 403 is "Forbidden", and the rfc says the client shouldn't *ever* > bother trying again, cause it ain't gonna work. So I don't think > this is what we want. I thought of 401 but it says "The response MUST include a WWW- Authenticate header field (section 14.47) containing a challenge applicable to the requested resource". You could use 404, but that should really be restricted to missing data. You could be cheeky and use 402, but that's reserved even though it's vaguely appropriate. I think that "Authorization will not help and the request SHOULD NOT be repeated" refers to HTTP authorization using WWW-Authenticate. That is, if the server is implementing authentication outside the HTTP authentication mechanism (for example, with a login form) then it certainly doesn't want the browser popping up a WWW authentication dialog, so it should return 403 to tell the browser that it can't use that mechanism. There really isn't another code than 403 that could be used here, and 403 is what I've seen from most servers (except for the ones that don't bother to implement any 4xx other than 404... and some servers don't even return 404, they always return redirects to annoyingly uninformative help files). > This would only be used if the server choked and died. That's what I was thinking of this case being for. :) >> Special handling: >> 307 Message-for-user >> Location: URL requesting more information >> Other-headers... >> >> --- no body --- > > I think one of the redirects is right. 307 is probably right > because it's not cacheable. That's what I thought. > In practice it doesn't matter since POST isn't cacheable anyway. So > I think the heuristic should be: > Successful login, redirect to secondlife: URI. > Additional information required, redirect to https: URL. I thought about that, but that means that if you just got the password wrong you'd have to open a browser window. I considered that, too, but it's not really good user interface design. If you typo the account name and password you should just get a message saying the login failed so you can correct it and try again. For unattended clients, too, it's useful to distinguish a bad account/ password (likely a configuration error) from something that needs immediate human attention. That doesn't mean you can't trigger a redirect if the user's tried 20 different passwords in the last minute and you want to let them know the account's locked out. Now I think about it, for interactive clients, the user interface can handle that case. Just a slight change: >> The viewer doesn't require any new complex code. No matter what >> the response is, it contains a message to display to the user. If >> a web page display is required, it contains a redirect to that >> page. The client can display that in llMozLib or redirect to an >> external browser. It can even use the existing framework for >> llLoadURL to give the user a dialog approving that redirect. The message would be displayed, and instead of using the llLoadURL dialog you'd just put a "(More Information)" button next to the message... clicking that would follow the redirect. From secret.argent at gmail.com Thu Dec 20 13:06:08 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 13:06:11 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <7E68B062-7227-468C-AB9A-27C12143E175@lindenlab.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com> <8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream> <476AB05D.6060400@wsu.edu> <7E68B062-7227-468C-AB9A-27C12143E175@lindenlab.com> Message-ID: On 2007-12-20, at 13:31, Donovan Preston wrote: > Server-side script compilation, which uses a capability to upload, > has been done for a year now, but it's in Branch_MONO. So hopefully > it'll be on agni sometime in 2008... :-) Aha... so you gave up on letting people upload CIL bytecodes? :) From secret.argent at gmail.com Thu Dec 20 13:09:38 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 13:09:44 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <8F9F12F7-E7B9-4080-8D68-212FBEDA9CCB@fastmail.fm> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <04598093-16A7-41F6-AD49-92F37230B3CA@fastmail.fm> <8F9F12F7-E7B9-4080-8D68-212FBEDA9CCB@fastmail.fm> Message-ID: On 2007-12-20, at 13:53, ordinal.malaprop@fastmail.fm wrote: > It would help a lot of people certainly, particularly those who > have not yet been burned by script loss Or those who are effective coding interactively and don't remember to CMD-A-CMD-C-CMD-TAB-TAB-TAB-CMD-V when they're "in the zone". > Of course, it's not that much use if everything is called "New > Script". Sort by date, the last one saved is the one you want, 99.44% of the time. From me at hamncheeseomlet.com Thu Dec 20 13:16:31 2007 From: me at hamncheeseomlet.com (Hamncheese) Date: Thu Dec 20 13:16:45 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <7E68B062-7227-468C-AB9A-27C12143E175@lindenlab.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com><8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream><476AB05D.6060400@wsu.edu> <7E68B062-7227-468C-AB9A-27C12143E175@lindenlab.com> Message-ID: <8CEA42C6191546909AFE5CEE02D6C734@DreamStream> But what is the code at LLPreviewLSL::uploadAssetViaCaps? Isn't that HTTPClient::Post? ----- Original Message ----- From: "Donovan Preston" To: "John Hurliman" Cc: Sent: Thursday, December 20, 2007 2:31 PM Subject: Re: [sldev] How Asset server handles saving of scripts > > On Dec 20, 2007, at 10:11 AM, John Hurliman wrote: > >> It should also be pushing the script binary using the same Xfer (UDP) >> system IIRC. Pretty sure the only uploads that are using CAPS right now >> are textures and this seems to confirm it. > > Server-side script compilation, which uses a capability to upload, has > been done for a year now, but it's in Branch_MONO. So hopefully it'll be > on agni sometime in 2008... :-) > > Donovan > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From donovan at lindenlab.com Thu Dec 20 13:22:29 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Thu Dec 20 13:22:39 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <47683D28.30803@lindenlab.com> Message-ID: <0CDC628F-D250-427D-B4B1-D1D9E6BD82C7@lindenlab.com> On Dec 20, 2007, at 1:05 PM, Argent Stonecutter wrote: > On 2007-12-20, at 13:19, Donovan Preston wrote: >> >> Successful login, redirect to secondlife: URI. >> Additional information required, redirect to https: URL. > > I thought about that, but that means that if you just got the > password wrong you'd have to open a browser window. I considered > that, too, but it's not really good user interface design. If you > typo the account name and password you should just get a message > saying the login failed so you can correct it and try again. For > unattended clients, too, it's useful to distinguish a bad account/ > password (likely a configuration error) from something that needs > immediate human attention. Ok, I think the distinction should be 303 (success, proceed) and 307 (temporary correctable failure, go to the location header to correct). In order to be able to distinguish between what type of failure has occurred, I think the 307 response should have an LLSD body containing an error code and a human readable message. If the error code matches the "user entered password wrong" code, a thin ui can discover that info by reading the body. > > That doesn't mean you can't trigger a redirect if the user's tried > 20 different passwords in the last minute and you want to let them > know the account's locked out. > > Now I think about it, for interactive clients, the user interface > can handle that case. Just a slight change: > >>> The viewer doesn't require any new complex code. No matter what >>> the response is, it contains a message to display to the user. If >>> a web page display is required, it contains a redirect to that >>> page. The client can display that in llMozLib or redirect to an >>> external browser. It can even use the existing framework for >>> llLoadURL to give the user a dialog approving that redirect. > > The message would be displayed, and instead of using the llLoadURL > dialog you'd just put a "(More Information)" button next to the > message... clicking that would follow the redirect. Sounds appropriate. Donovan From donovan at lindenlab.com Thu Dec 20 13:24:25 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Thu Dec 20 13:24:33 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <8CEA42C6191546909AFE5CEE02D6C734@DreamStream> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com><8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream><476AB05D.6060400@wsu.edu> <7E68B062-7227-468C-AB9A-27C12143E175@lindenlab.com> <8CEA42C6191546909AFE5CEE02D6C734@DreamStream> Message-ID: <36C9F487-896B-497E-9E14-3305A543B856@lindenlab.com> On Dec 20, 2007, at 1:16 PM, Hamncheese wrote: > But what is the code at LLPreviewLSL::uploadAssetViaCaps? Isn't that > HTTPClient::Post? It's probably blacklisted on the server. The code works, we just don't have a compelling reason to roll it out as a separate release than the Branch_MONO release. Donovan From secret.argent at gmail.com Thu Dec 20 13:26:39 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 13:26:44 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <0CDC628F-D250-427D-B4B1-D1D9E6BD82C7@lindenlab.com> References: <47683D28.30803@lindenlab.com> <0CDC628F-D250-427D-B4B1-D1D9E6BD82C7@lindenlab.com> Message-ID: On 2007-12-20, at 15:22, Donovan Preston wrote: > Ok, I think the distinction should be 303 (success, proceed) and > 307 (temporary correctable failure, go to the location header to > correct). > > In order to be able to distinguish between what type of failure has > occurred, I think the 307 response should have an LLSD body > containing an error code and a human readable message. If the error > code matches the "user entered password wrong" code, a thin ui can > discover that info by reading the body. What's wrong with including the human readable message after the 307? That's what that part of the HTTP protocol is for. From me at hamncheeseomlet.com Thu Dec 20 13:53:41 2007 From: me at hamncheeseomlet.com (Hamncheese) Date: Thu Dec 20 13:53:52 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <36C9F487-896B-497E-9E14-3305A543B856@lindenlab.com> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com><8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream><476AB05D.6060400@wsu.edu> <7E68B062-7227-468C-AB9A-27C12143E175@lindenlab.com> <8CEA42C6191546909AFE5CEE02D6C734@DreamStream> <36C9F487-896B-497E-9E14-3305A543B856@lindenlab.com> Message-ID: <528701703D8140BC9B662DD03CBB5DFF@DreamStream> I guess I don't understand "blacklisted at the server" means, unless you mean that "UpdateScriptTaskInventory" CAPS is turned off on all sims? The code under save if needed does a "get caps from region, if a url is returned then call uploadAssetViaCaps, if not a valid url call uploadAssetLegacy" So if CAPS isn't being used until mono is released why have the check for that CAP in the code for every save? ----- Original Message ----- From: "Donovan Preston" To: "Hamncheese" Cc: "Second Life Developer Mailing List" Sent: Thursday, December 20, 2007 4:24 PM Subject: Re: [sldev] How Asset server handles saving of scripts > > On Dec 20, 2007, at 1:16 PM, Hamncheese wrote: > >> But what is the code at LLPreviewLSL::uploadAssetViaCaps? Isn't that >> HTTPClient::Post? > > It's probably blacklisted on the server. The code works, we just don't > have a compelling reason to roll it out as a separate release than the > Branch_MONO release. > > Donovan > > From seg at haxxed.com Thu Dec 20 14:51:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Dec 20 14:51:03 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> Message-ID: <1198191071.3486.26.camel@localhost> On Wed, 2007-12-19 at 19:30 -0600, Argent Stonecutter wrote: > Hell, I'd be satisfied with a preference option "Save copy of scripts > and notecards in [~/Documents/SL]", and have it ALWAYS write > "scriptname.lsl" or "notecardname.txt" in that folder when I hit save. How about we start with a simple, basic, standard "Save As..." option. -------------- 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/20071220/da878d81/attachment.pgp From donovan at lindenlab.com Thu Dec 20 14:50:40 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Thu Dec 20 14:51:18 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <47683D28.30803@lindenlab.com> <0CDC628F-D250-427D-B4B1-D1D9E6BD82C7@lindenlab.com> Message-ID: <94EC7322-70DB-4D46-8621-1376C1457D16@lindenlab.com> On Dec 20, 2007, at 1:26 PM, Argent Stonecutter wrote: > On 2007-12-20, at 15:22, Donovan Preston wrote: >> Ok, I think the distinction should be 303 (success, proceed) and >> 307 (temporary correctable failure, go to the location header to >> correct). >> >> In order to be able to distinguish between what type of failure has >> occurred, I think the 307 response should have an LLSD body >> containing an error code and a human readable message. If the error >> code matches the "user entered password wrong" code, a thin ui can >> discover that info by reading the body. > > What's wrong with including the human readable message after the > 307? That's what that part of the HTTP protocol is for. That's fine too. How about both, so that the Reason can be used as the machine readable version, and the body could contain additional metadata such as a human readable version. Donovan From donovan at lindenlab.com Thu Dec 20 14:54:21 2007 From: donovan at lindenlab.com (Donovan Preston) Date: Thu Dec 20 14:54:31 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: <528701703D8140BC9B662DD03CBB5DFF@DreamStream> References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com><8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream><476AB05D.6060400@wsu.edu> <7E68B062-7227-468C-AB9A-27C12143E175@lindenlab.com> <8CEA42C6191546909AFE5CEE02D6C734@DreamStream> <36C9F487-896B-497E-9E14-3305A543B856@lindenlab.com> <528701703D8140BC9B662DD03CBB5DFF@DreamStream> Message-ID: On Dec 20, 2007, at 1:53 PM, Hamncheese wrote: > I guess I don't understand "blacklisted at the server" means, unless > you mean that "UpdateScriptTaskInventory" CAPS is turned off on all > sims? Yep, that's right. > The code under save if needed does a "get caps from region, if a url > is returned then call uploadAssetViaCaps, if not a valid url call > uploadAssetLegacy" So if CAPS isn't being used until mono is > released why have the check for that CAP in the code for every save? No reason really, other than we rolled the code out blacklisted and haven't taken the time to QA it and turn it on as a feature separate from mono. If there is sufficient demand it would be easy enough to start a project to turn on the UpdateScriptTaskInventory cap, since the remaining work to be done is QA (currently being done on this feature in the mono branch). But there would have to be a compelling use case. Donovan > > > > ----- Original Message ----- From: "Donovan Preston" > > To: "Hamncheese" > Cc: "Second Life Developer Mailing List" > Sent: Thursday, December 20, 2007 4:24 PM > Subject: Re: [sldev] How Asset server handles saving of scripts > > >> >> On Dec 20, 2007, at 1:16 PM, Hamncheese wrote: >> >>> But what is the code at LLPreviewLSL::uploadAssetViaCaps? Isn't >>> that HTTPClient::Post? >> >> It's probably blacklisted on the server. The code works, we just >> don't have a compelling reason to roll it out as a separate release >> than the Branch_MONO release. >> >> Donovan >> > From brad at lindenlab.com Thu Dec 20 15:27:28 2007 From: brad at lindenlab.com (Brad Kittenbrink) Date: Thu Dec 20 15:26:36 2007 Subject: [sldev] Source release for WindLight FL-1.18.6.75762 Message-ID: <476AFA60.50108@lindenlab.com> WindLight FL-1.18.6.75762 source release is available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_FL-1.18.6.75762 Release note information here: http://blog.secondlife.com/2007/12/17/new-windlight-viewer-extended-commentary-75762/ Checksums: d036a01fd49f578c9d561d68493f852a slviewer-darwin-libs-FL-1.18.6.75762.tar.gz eba59bbad174a7089c22ba84e34cbe66 slviewer-linux-libs-FL-1.18.6.75762.tar.gz df64097e9fd7b12f76af32280b84e003 slviewer-src-FL-1.18.6.75762.tar.gz d804e22f32e3baf81e8a3396e044143c slviewer-artwork-FL-1.18.6.75762.zip a45acd940656134824376b2a48a7ce58 slviewer-src-FL-1.18.6.75762.zip 9714c5f3b580be0d9f196fdbeb480767 slviewer-win32-libs-FL-1.18.6.75762.zip SVN checkout will be available shortly. thanks! Brad Linden From dzonatas at dzonux.net Thu Dec 20 16:18:59 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Dec 20 16:18:51 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <4F88F3B1-D063-459D-B204-B1F7CC0BC83E@gmail.com> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> <476ABA48.7030508@dzonux.net> <4F88F3B1-D063-459D-B204-B1F7CC0BC83E@gmail.com> Message-ID: <476B0673.5090203@dzonux.net> Argent Stonecutter wrote: > In addition, the relationship between the backed-up assets and > in-world object is out of scope of COLLADA. It probably appears out of scope because the published implementation of COLLADA uses a more standalone-ish server. From the dump you stated, it sounded more like you just wanted a flat-file backup version -- that would be a filter. I'd be more in favor of a secondary database for backup usage and as a hop to back-end automation. -- Power to Change the Void From jhurliman at wsu.edu Thu Dec 20 17:18:08 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Dec 20 17:16:11 2007 Subject: [sldev] How Asset server handles saving of scripts In-Reply-To: References: <493033a70712191223w368e884aud3d1614f38c3f72c@mail.gmail.com> <476991D0.9060302@gmail.com> <493033a70712191358k1f7053adre7089f66973ef41a@mail.gmail.com> <01f501c84291$0cc09d20$6869a8c0@PJRIII.local> <60072FCC768D4295AFDC08BAE1CA3DD1@DreamStream> <1674f6c70712191646o3e837192r5aae5a2752f9e699@mail.gmail.com><8CD857B7E80443D9BFDFC8B7241ED4FA@DreamStream><476AB05D.6060400@wsu.edu> <7E68B062-7227-468C-AB9A-27C12143E175@lindenlab.com> <8CEA42C6191546909AFE5CEE02D6C734@DreamStream> <36C9F487-896B-497E-9E14-3305A543B856@lindenlab.com> <528701703D8140BC9B662DD03CBB5DFF@DreamStream> Message-ID: <476B1450.7000603@wsu.edu> Donovan Preston wrote: > > On Dec 20, 2007, at 1:53 PM, Hamncheese wrote: > >> I guess I don't understand "blacklisted at the server" means, unless >> you mean that "UpdateScriptTaskInventory" CAPS is turned off on all >> sims? > > Yep, that's right. > >> The code under save if needed does a "get caps from region, if a url >> is returned then call uploadAssetViaCaps, if not a valid url call >> uploadAssetLegacy" So if CAPS isn't being used until mono is released >> why have the check for that CAP in the code for every save? > > No reason really, other than we rolled the code out blacklisted and > haven't taken the time to QA it and turn it on as a feature separate > from mono. If there is sufficient demand it would be easy enough to > start a project to turn on the UpdateScriptTaskInventory cap, since > the remaining work to be done is QA (currently being done on this > feature in the mono branch). But there would have to be a compelling > use case. > > Donovan My compelling reason is that the implementation of the Xfer system in libsecondlife is the only place in the code that contains swearing and desperation in the comments, if all of the uploads were switched to CAPS it would make our codebase more family friendly. So there's a "think of the children" angle to this discussion. The other reasons include more pedantic things like if you start a second upload before the first gets a RequestXfer packet back there is no way to discern between the ACKs for each upload (the system wasn't designed for parallel uploads at all from what I can tell, but it can be done if you are really careful), and you have to typecast from a 64-bit integer to a 128-bit UUID (allocating a bit of memory) each time a ConfirmXferPacket is received. Speaking of which, the two layers of ACKing (PacketAck + ConfirmXferPacket) means it uses more bandwidth then a TCP upload would even under perfect network conditions. And from an overall protocol design spec it's another redundant system to document. Having said that, there are a lot of other things I'd like to see pushed out before retiring the Xfer system. I'm just saying I don't think anyone will be sad to see it go. John From secret.argent at gmail.com Thu Dec 20 17:25:18 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 17:25:23 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <476B0673.5090203@dzonux.net> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> <476ABA48.7030508@dzonux.net> <4F88F3B1-D063-459D-B204-B1F7CC0BC83E@gmail.com> <476B0673.5090203@dzonux.net> Message-ID: On 2007-12-20, at 18:18, Dzonatas wrote: > Argent Stonecutter wrote: >> In addition, the relationship between the backed-up assets and in- >> world object is out of scope of COLLADA. > > It probably appears out of scope because the published > implementation of COLLADA uses a more standalone-ish server. I'm going by the specification, not any implementation. > From the dump you stated, it sounded more like you just wanted a > flat-file backup version -- that would be a filter. That wasn't a dump of a file, it was a directory tree. From dzonatas at dzonux.net Thu Dec 20 18:31:57 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Dec 20 18:31:49 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> <476ABA48.7030508@dzonux.net> <4F88F3B1-D063-459D-B204-B1F7CC0BC83E@gmail.com> <476B0673.5090203@dzonux.net> Message-ID: <476B259D.5060006@dzonux.net> Argent Stonecutter wrote: > On 2007-12-20, at 18:18, Dzonatas wrote: >> Argent Stonecutter wrote: >>> In addition, the relationship between the backed-up assets and >>> in-world object is out of scope of COLLADA. >> > >> It probably appears out of scope because the published implementation >> of COLLADA uses a more standalone-ish server. > > I'm going by the specification, not any implementation. There is some confusion here then. How do you see that there is a difference between the two assets you stated? > >> From the dump you stated, it sounded more like you just wanted a >> flat-file backup version -- that would be a filter. > > That wasn't a dump of a file, it was a directory tree. > A directory tree, you mean pointing back to your ideal scheme? -- Power to Change the Void From secret.argent at gmail.com Thu Dec 20 19:32:50 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 20 19:32:56 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <476B259D.5060006@dzonux.net> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> <476ABA48.7030508@dzonux.net> <4F88F3B1-D063-459D-B204-B1F7CC0BC83E@gmail.com> <476B0673.5090203@dzonux.net> <476B259D.5060006@dzonux.net> Message-ID: <0BD56245-AEE5-43D6-A000-F7A6762C2EEF@gmail.com> On 2007-12-20, at 20:31, Dzonatas wrote: > Argent Stonecutter wrote: >> On 2007-12-20, at 18:18, Dzonatas wrote: >>> Argent Stonecutter wrote: >>>> In addition, the relationship between the backed-up assets and >>>> in-world object is out of scope of COLLADA. >>> >>> It probably appears out of scope because the published >>> implementation of COLLADA uses a more standalone-ish server. >> >> I'm going by the specification, not any implementation. > > There is some confusion here then. How do you see that there is a > difference between the two assets you stated? What do you mean? I'm talking about the relationship between them, not the differences between them. > A directory tree, you mean pointing back to your ideal scheme? The backup layout I described *is* a directory tree. Each line is the name of a file, directory, or symlink. I don't claim it's ideal, but something like it that lets me deal with assets at the file level is kind of a requirement. Whether the individual xml files are in Linden Labs' XML format or in some COLLADA format is orthogonal. From nicholaz at blueflash.cc Fri Dec 21 06:24:04 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Dec 21 06:24:12 2007 Subject: [sldev] Windlight Builds Message-ID: <476BCC84.3050902@blueflash.cc> If you have problems with Windlight builds (glh/assert with stars), see my last comment https://jira.secondlife.com/browse/VWR-3415. I also updated the wiki (build instructions and common errors) From dzonatas at dzonux.net Fri Dec 21 08:02:20 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Dec 21 08:02:11 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <0BD56245-AEE5-43D6-A000-F7A6762C2EEF@gmail.com> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> <476ABA48.7030508@dzonux.net> <4F88F3B1-D063-459D-B204-B1F7CC0BC83E@gmail.com> <476B0673.5090203@dzonux.net> <476B259D.5060006@dzonux.net> <0BD56245-AEE5-43D6-A000-F7A6762C2EEF@gmail.com> Message-ID: <476BE38C.9020302@dzonux.net> Argent Stonecutter wrote: > On 2007-12-20, at 20:31, Dzonatas wrote: >> Argent Stonecutter wrote: >>> On 2007-12-20, at 18:18, Dzonatas wrote: >>>> Argent Stonecutter wrote: >>>>> In addition, the relationship between the backed-up assets and >>>>> in-world object is out of scope of COLLADA. >>>> > >>>> It probably appears out of scope because the published >>>> implementation of COLLADA uses a more standalone-ish server. >>> > >>> I'm going by the specification, not any implementation. >> > >> There is some confusion here then. How do you see that there is a >> difference between the two assets you stated? > > What do you mean? I'm talking about the relationship between them, not > the differences between them. > Understood. I am also concerned about the permissive properties that affect the relationships. To that, it would have to stay within scope of something like COLLADA if not COLLADA itself to respect those properties. The filters have to abide by the such properties, for example. In my current view of this, instead of a hack to the viewer itself to save scripts, any program can query the filter to dump its data. The filter in that sense acts as a database cursor. The process I'm seeing is that one would write their script. A local cache of the asset is updated with the script. An event is triggered to create a pending request to update the primary database (i.e. in-world). Another event can be triggered to run the filter and dump data that is allowed to be seen by such query and properties. Just to enable the ability to save scripts can be done out-of-scope of COLLADA. That is fine because we know the viewer now gets forced to respect the properties of scripts. For example, the sim doesn't send the text of the script. Going beyond that, there are various properties involved. If we locally cache an asset for backup purposes or automation, there are relationships in the asset that need to be respected. For example, an object that has two scripts but one script has restricted permissions. Without any specific implementation, lets say anyone can locally cache the asset with all the scripts, restricted and publicly viewable kinds, but only one script can be seen. We don't want to allow a complete backup (or dump) of the asset because that could look malicious for lack of respect about permissive properties such that being able to exploit all scripts -- even unintentionally. Your ideal scheme is not a bad idea. I feel, however, the effort is better spent on either the hack to just save viewable scripts (and it is a hack) or on efforts to bring COLLADA more in scope. With the ideal filter on COLLADA, your ideal scheme is still possible but some relations may be restricted. -- Power to Change the Void From secret.argent at gmail.com Fri Dec 21 09:50:32 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Dec 21 09:50:39 2007 Subject: [sldev] Automatically backing up scripts locally. In-Reply-To: <476BE38C.9020302@dzonux.net> References: <405F29B3-1097-4388-A65E-72ED9D0571A6@gmail.com> <200712200216.43659.dale@daleglass.net> <8DF9FAF9-2379-4520-A565-D6243922DB61@gmail.com> <476A4EEF.4040108@gwala.net> <814B4FAF-DB55-43A3-B98F-8601EE396C0B@gmail.com> <476A9D43.2070707@dzonux.net> <476ABA48.7030508@dzonux.net> <4F88F3B1-D063-459D-B204-B1F7CC0BC83E@gmail.com> <476B0673.5090203@dzonux.net> <476B259D.5060006@dzonux.net> <0BD56245-AEE5-43D6-A000-F7A6762C2EEF@gmail.com> <476BE38C.9020302@dzonux.net> Message-ID: <3940E051-58F2-43DD-B49C-268B1F6B4A60@gmail.com> On 2007-12-21, at 10:02, Dzonatas wrote: > I am also concerned about the permissive properties that affect the > relationships. I'm talking about backing up things I'm creating as I'm creating them. I'm not talking about backing up things that I do not have permissions for: if I upload an image, or edit a script, or create a prim, I have full permissions to do so. If I don't have permissions, I won't be able to back it up. Whether the backup format is COLLADA or LLXML is irrelevant: COLLADA does not enforce permissions, it merely documents them. Also, you keep going on about my ideal scheme. I don't have an "ideal scheme". When I wrote my ideal scheme would be "something like" the example I gave, that's all it was, an example of what I would like to do if I was doing it. I have a set of requirements. The first two are 1. Each asset is stored in a separate file or directory. * This allows assets to be accessed directly by any application * Saving one asset can not corrupt another * Saving one asset is efficient 2. Open-format components of assets are stored in open formats, preferably those supported by SL. * This allows assets to be edited by any application * This means that uploads are automatic, and can be done directly from the SL application. 3. The directory structure describes the in-world relationships between assets. * This makes it easy to locate assets. * This maintains the relationship between the backup and the in- world assets. 4. Asset contents are not duplicated in the directory hierarchy. 5. References to assets are unambiguous. * These last two are desirable for efficiency and consistency. The example scheme satisfies these requirements: * Atomic assets are stored as text files, PNG or TGA images, FLAC or WAV audio files, BVH animations, and so on. * Combined assets are stored as directories, containing XML parameters and properties and symlinks to referenced assets. * Assets rezzed in-world are stored under the region. * Assets in inventory are stored under the directory tree of the inventory. This is an example scheme. There are other possible schemes. There is nothing in this scheme that requires you to use COLLADA formats, nor does it prevent you from using COLLADA formats, or using both. The use of standard file formats is explicitly supported by COLLADA: consider the example image file in the spec: Textures/WoodFloor-01.png So consider a simple one-prim object: ObjectName Properties.xml ImageName.png Scriptname.txt Properties.xml could look like this: Argent Stonecutter ... Or it could look like this: Argent Stonecutter Argent Stonecutter ... ImageName.png ...COLLADA description... The same data, the same files, using COLLADA or not using COLLADA is completely orthogonal to anything in the example layout. From anthony at lindenlab.com Fri Dec 21 15:40:42 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Fri Dec 21 15:40:56 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <47608821.2030805@lindenlab.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> Message-ID: <476C4EFA.6080203@lindenlab.com> Hey everyone, Release Candidate in time for the holiday weekend. RC-1.18.6.2 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.2 Release note information here: http://blog.secondlife.com/2007/12/21/updated-release-candidate-viewer-second-life-1186-rc2-available-today/ Checksums: ab0d0957c1e3b6991a0df0f85b4200ac slviewer-darwin-libs-RC-1.18.6.2.tar.gz b25f0a64db07b5d714f436d6970ec0bc slviewer-linux-libs-RC-1.18.6.2.tar.gz 1d4744b6502f34612597e61ecb0bc892 slviewer-src-RC-1.18.6.2.tar.gz 6cc9f49811c99db92adc664582029593 slviewer-artwork-RC-1.18.6.2.zip 710e615d83e9d18b0fa746427282c1de slviewer-src-RC-1.18.6.2.zip e3e7bfbe47cf784619c7df653265e676 slviewer-win32-libs-RC-1.18.6.2.zip SVN checkout: update to be provided by rob. Enjoy. -Anthony From carjay at gmx.net Fri Dec 21 18:18:21 2007 From: carjay at gmx.net (Carsten Juttner) Date: Fri Dec 21 18:18:24 2007 Subject: [sldev] [VWR] [llmozlib] - what version of mozilla/firefox? In-Reply-To: <47684E60.3090700@lindenlab.com> References: <47684BA0.7090506@sun.com> <47684E60.3090700@lindenlab.com> Message-ID: <476C73ED.7000903@gmx.net> Callum Prentice wrote: > It is available via SVN - https://svn.secondlife.com/svn/llmozlib/trunk/ Hm, the SVN seems no longer to be up to date, the header file for the RC 1.18.6.2 sources includes some additional methods: bool enableProxy( bool proxyEnabledIn, std::string proxyHostNameIn, int proxyPortIn ); bool mouseLeftDoubleClick( int browserWindowIdIn, int xPosIn, int yPosIn ); Regards, Carsten From anthony at lindenlab.com Fri Dec 21 21:10:35 2007 From: anthony at lindenlab.com (anthony@lindenlab.com) Date: Fri Dec 21 21:10:43 2007 Subject: [sldev] Viewer Source Release of FL-1.18.6.76116 In-Reply-To: <476C4EFA.6080203@lindenlab.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <476C4EFA.6080203@lindenlab.com> Message-ID: <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> Hey everyone, Don't think I forgot about the First Look viewer. WindLight gets a source drop for the holidays as well. This branch has not be double checked by soft to build, so it will probably have more issues than the RC source. FL-1.18.6.76116 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_FL-1.18.6.76116 Release note information here: http://blog.secondlife.com/2007/12/21/the-new-windlight-viewer-pondering-aesthetics-76116/ Checksums: 9f7f30febafb75b4b6bb399a2302c341 slviewer-darwin-libs-FL-1.18.6.76116.tar.gz 6616c748058db3261aeaf71db2e0f6f6 slviewer-linux-libs-FL-1.18.6.76116.tar.gz 1cfc9c210271289c6a068798125c9e09 slviewer-src-FL-1.18.6.76116.tar.gz 8f09d005afa93c996fa78592ae469a73 slviewer-artwork-FL-1.18.6.76116.zip aea0a595d03ec1a3fecf50ea0e011c61 slviewer-src-FL-1.18.6.76116.zip 5ad269def83da1c7661d5e6c675e491a slviewer-win32-libs-FL-1.18.6.76116.zip SVN checkout: update to be provided by rob. Enjoy. -Anthony From anthony at lindenlab.com Fri Dec 21 21:21:32 2007 From: anthony at lindenlab.com (anthony@lindenlab.com) Date: Fri Dec 21 21:21:40 2007 Subject: [sldev] Viewer Source Release of Relase branch 20071221a In-Reply-To: <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <476C4EFA.6080203@lindenlab.com> <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> Message-ID: <3456.24.6.233.189.1198300892.squirrel@mail.lindenlab.com> Hey everyone, Let's round out the available sources with a nice dated release snapshot. Hope you all have fun with this. 20071221a source release available here: https://wiki.secondlife.com/wiki/Source_downloads#2007-Dec-21 Checksums: 4428398a8c01051f160044bedfa692af slviewer-darwin-libs-20071221a.tar.gz d6f1802eec8e332879e6521b3db89ab7 slviewer-linux-libs-20071221a.tar.gz f23d329d397256dfd86d7f56f0756ba7 slviewer-src-20071221a.tar.gz 262b262ea25034c2f2d2232faae30be5 slviewer-artwork-20071221a.zip 0b91974ce7dfc300470b1aaf0f07c9f9 slviewer-src-20071221a.zip d92f887c1428ec38fed45d91f03e0fb0 slviewer-win32-libs-20071221a.zip SVN checkout: update to be provided by rob. Enjoy. -Anthony From bboomslang at googlemail.com Sat Dec 22 11:09:52 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Sat Dec 22 11:09:54 2007 Subject: [sldev] Viewer Source Release of FL-1.18.6.76116 In-Reply-To: <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <476C4EFA.6080203@lindenlab.com> <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> Message-ID: <347b550f0712221109v453cc189nb9c9428d458eded0@mail.gmail.com> Uh, so this "double checks" do happen? I doubt it with some of the source drops, but well, if in dubio pro reo, eh? But well, even if you don't actually double check, it would have been nice to pay attention to the build problems of the _previous_ source drop for FL and actually include the missing glh headers ... Oh, the headers Nicholaz provides on his site do help, but for Macs the includes for gl.h need adaption in the glh headers, still. And even after adapting the GL/gl.h include in one of the glh headers to OpenGL/gl.h, I get an error later on about GLH_EXT_NAME not being declared. I guess the glh headers somehow are platform specific? On Dec 22, 2007 6:10 AM, wrote: > Hey everyone, > > Don't think I forgot about the First Look viewer. WindLight gets a source > drop for the holidays as well. This branch has not be double checked by > soft to build, so it will probably have more issues than the RC source. > > FL-1.18.6.76116 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_FL-1.18.6.76116 > > Release note information here: > > http://blog.secondlife.com/2007/12/21/the-new-windlight-viewer-pondering-aesthetics-76116/ > > Checksums: > > 9f7f30febafb75b4b6bb399a2302c341 > slviewer-darwin-libs-FL-1.18.6.76116.tar.gz > 6616c748058db3261aeaf71db2e0f6f6 > slviewer-linux-libs-FL-1.18.6.76116.tar.gz > 1cfc9c210271289c6a068798125c9e09 slviewer-src-FL-1.18.6.76116.tar.gz > 8f09d005afa93c996fa78592ae469a73 slviewer-artwork-FL-1.18.6.76116.zip > aea0a595d03ec1a3fecf50ea0e011c61 slviewer-src-FL-1.18.6.76116.zip > 5ad269def83da1c7661d5e6c675e491a slviewer-win32-libs-FL-1.18.6.76116.zip > > > SVN checkout: update to be provided by rob. > > Enjoy. > -Anthony > > _______________________________________________ > 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/20071222/db9d673c/attachment.htm From robla at lindenlab.com Sat Dec 22 12:17:55 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sat Dec 22 12:18:16 2007 Subject: [sldev] Viewer Source Release of FL-1.18.6.76116 In-Reply-To: <347b550f0712221109v453cc189nb9c9428d458eded0@mail.gmail.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <476C4EFA.6080203@lindenlab.com> <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> <347b550f0712221109v453cc189nb9c9428d458eded0@mail.gmail.com> Message-ID: <476D70F3.1050301@lindenlab.com> We're currently in the process of doublechecking the redistribution rights associated with the version of the GLH code we use, which is taking us longer than we hoped. Sorry for the inconvenience. Rob On 12/22/07 11:09 AM, Barney Boomslang wrote: > Uh, so this "double checks" do happen? I doubt it with some of the > source drops, but well, if in dubio pro reo, eh? But well, even if you > don't actually double check, it would have been nice to pay attention > to the build problems of the _previous_ source drop for FL and > actually include the missing glh headers ... > > Oh, the headers Nicholaz provides on his site do help, but for Macs > the includes for gl.h need adaption in the glh headers, still. And > even after adapting the GL/gl.h include in one of the glh headers to > OpenGL/gl.h, I get an error later on about GLH_EXT_NAME not being > declared. I guess the glh headers somehow are platform specific? > > On Dec 22, 2007 6:10 AM, > wrote: > > Hey everyone, > > Don't think I forgot about the First Look viewer. WindLight gets > a source > drop for the holidays as well. This branch has not be double > checked by > soft to build, so it will probably have more issues than the RC > source. > > FL-1.18.6.76116 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_FL-1.18.6.76116 > > > Release note information here: > http://blog.secondlife.com/2007/12/21/the-new-windlight-viewer-pondering-aesthetics-76116/ > > > Checksums: > > 9f7f30febafb75b4b6bb399a2302c341 > slviewer-darwin-libs-FL-1.18.6.76116.tar.gz > 6616c748058db3261aeaf71db2e0f6f6 > slviewer-linux-libs-FL-1.18.6.76116.tar.gz > 1cfc9c210271289c6a068798125c9e09 slviewer-src-FL-1.18.6.76116.tar.gz > 8f09d005afa93c996fa78592ae469a73 slviewer-artwork-FL-1.18.6.76116.zip > aea0a595d03ec1a3fecf50ea0e011c61 slviewer-src-FL-1.18.6.76116.zip > 5ad269def83da1c7661d5e6c675e491a > slviewer-win32-libs-FL-1.18.6.76116.zip > > > SVN checkout: update to be provided by rob. > > Enjoy. > -Anthony > > _______________________________________________ > 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/20071222/e25bb519/signature.pgp From robin.cornelius at gmail.com Sat Dec 22 13:11:00 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Dec 22 13:04:27 2007 Subject: [sldev] Viewer Source Release of FL-1.18.6.76116 In-Reply-To: <476D70F3.1050301@lindenlab.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <476C4EFA.6080203@lindenlab.com> <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> <347b550f0712221109v453cc189nb9c9428d458eded0@mail.gmail.com> <476D70F3.1050301@lindenlab.com> Message-ID: <476D7D64.9070105@gmail.com> Rob Lanphier wrote: > We're currently in the process of doublechecking the redistribution > rights associated with the version of the GLH code we use, which is > taking us longer than we hoped. Sorry for the inconvenience. > The versions i have found from http://developer.nvidia.com/attach/8196 have in the top level folder a licence_info.txt that states "The files bison.exe, bison.simple, and flex.exe are covered by the GPL. All other files in this distribution can be used however you want." And individual files have a basic MIT style licence,eg :- you may redistribute providing you leave the copyright notices in place and that you do not claim any endorse..etc. I really can't seen any problem distributing those files? may be you obtained your files from a different source with a different licence. If they don't have a DFSG free licence perhaps you may wish to "switch" to the download source i linked to above. Regards Robin -------------- 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/20071222/b23a8f4a/signature.pgp From robin.cornelius at gmail.com Sat Dec 22 14:26:59 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Dec 22 14:20:29 2007 Subject: [sldev] [VWR] [llmozlib] - what version of mozilla/firefox? In-Reply-To: <476C73ED.7000903@gmx.net> References: <47684BA0.7090506@sun.com> <47684E60.3090700@lindenlab.com> <476C73ED.7000903@gmx.net> Message-ID: <476D8F33.2070607@gmail.com> Carsten Juttner wrote: > Callum Prentice wrote: >> It is available via SVN - https://svn.secondlife.com/svn/llmozlib/trunk/ > > Hm, the SVN seems no longer to be up to date, the header file for the RC > 1.18.6.2 sources includes some additional methods: > > bool enableProxy( bool proxyEnabledIn, std::string proxyHostNameIn, int > proxyPortIn ); > bool mouseLeftDoubleClick( int browserWindowIdIn, int xPosIn, int yPosIn ); > I've marked this on JIRA http://jira.secondlife.com/browse/VWR-3985 so it doesn't get forgotten :-) Robin -------------- 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/20071222/278ef65a/signature.pgp From bboomslang at googlemail.com Sun Dec 23 03:22:03 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Sun Dec 23 03:22:05 2007 Subject: [sldev] The criminalization of open source In-Reply-To: <98C2B399-2EEE-46B3-9208-04742FED1203@gmail.com> References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> <1197967765.30098.1227154689@webmail.messagingengine.com> <98C2B399-2EEE-46B3-9208-04742FED1203@gmail.com> Message-ID: <347b550f0712230322t1dff19bk7c88c504e2aaef76@mail.gmail.com> On Dec 18, 2007 10:33 AM, Argent Stonecutter wrote: > Thanks, Ordinal. This is the key bit. > > On 2007-12-18, at 02:49, Ordinal Malaprop wrote: > > Without the "toy economy" none of us would be here talking about it > > on this list. > > Missing this point is just as bad as missing the original point about > the ineffectiveness of DRM. Yes. And it's quite irritating to see how allmost like being driven by a program some ppl jump on any situation that in the farthest sense could be seen as "they don't get the technical implications" and comes to conclusions like "toy economy" and "they are stupid". Educating people with a big stick that is banged on their head _never_ really worked right. It only will further the bad feelings toward the techies. I really don't understand why some ppl have to jump on that and start with calling names and calling the end of the virtual universe on something as simple as this. And that's true for both sides of the argument. Yes, hiding the UUID in the interface won't help at all. But what it does provide is a simple signal of "well, yes, you can get that - but if you do, you will know you had to jump through hoops and even you should by now have noticed that what you do is against what we want" in contrast to the former signal of "well, h ere is the data, do what you like". Please don't forget that humans are not run by programs, but by wetware and that does work quite differently. "Security by obscurity is no security at all" is _not_ (and _never_ will be!) a valid _social_ argument. It is allways and _only_ a technical argument. If you work with someone who produces security systems, you can slap them with that line, but not in a discussion about behavioural norms and social interaction. In a social construct it is complete and utter bullshit. As should be visible to anybody who has ever seen doors in houses where the window right beside it is not barred - that's no security at all, but we live by that "security measure" quite fine - because anybody knows that breaking the window or door (regardless of how simple that is) is illegal, while having no door at all might be seen as invitation to public space. Please don't measure humans with technical scales and axioms. It will backfire and make you look stupid. bye, Barney -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071223/55c514a1/attachment.htm From warkirby3333 at hotmail.co.uk Sun Dec 23 06:17:22 2007 From: warkirby3333 at hotmail.co.uk (Paul Cook) Date: Sun Dec 23 06:17:23 2007 Subject: [sldev] Windlight Glow Message-ID: Does anyone have any information on when the LSL controls for windlight's glow feature will be available? As per : https://jira.secondlife.com/browse/VWR-3114 _________________________________________________________________ Telly addicts unite! http://www.searchgamesbox.com/tvtown.shtml -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071223/c3185dc4/attachment.htm From tao.takashi at googlemail.com Sun Dec 23 08:19:11 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sun Dec 23 08:19:14 2007 Subject: [sldev] Windlight Glow In-Reply-To: References: Message-ID: <23bbb49e0712230819m5bbf2756ha43c8fede58e3a38@mail.gmail.com> On Dec 23, 2007 3:17 PM, Paul Cook wrote: > Does anyone have any information on when the LSL controls for windlight's > glow feature will be available? > It was said that first the bugs need to get ironed out before implementing new features (at the office hour). What new feature is then to come is probably open, I would guess saving of settings serverside is one and LSL controls for Windlight is another. After that it was said it might be Nimble (new clouds) and layered textures with more maps to configure. -- Tao > > As per : https://jira.secondlife.com/browse/VWR-3114 > > ------------------------------ > Messenger on the move. Text MSN to 63463 now! > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- taotakashi@gmail.com Blog: http://mrtopf.de Planet: http://worldofsl.com RL: Christian Scholz, mrtopf@gmail.com http://mrtopf.de Company: http://comlounge.net Tech Video Blog: http://comlounge.tv IRC: MrTopf/Tao_T -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071223/557f5d2b/attachment.htm From tshephard at gmail.com Sun Dec 23 15:29:47 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sun Dec 23 15:29:50 2007 Subject: [sldev] Hooking the wii up to SL for head (body?) tracking Message-ID: <3b19a500712231529y18a3a032w836ec4283d0f256e@mail.gmail.com> A pretty interesting project: http://www.youtube.com/watch?v=Jd3-eiid-Uw My guess is that if you projected a very large secondlife screen onto a wall, it would be an interesting effect if the client could use this to project where you are in the room relative to your avatar's location in SecondLife in mouselook. I don't think this does much for tracking the angle of your head relative to your body, so you'd probably have to stiff neck it. Maybe there is a way to do that with a third infrared LED (the wii can track up to 4, apparently). If not, there is a fascinating use of a gyroscope which might be of use: http://video.google.com/videoplay?docid=-2237947353453839215&q=rc+plane+vr+goggles&total=8&start=0&num=10&so=0&type=search&plindex=0 Anyhow, cool stuff. From tshephard at gmail.com Sun Dec 23 15:35:02 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sun Dec 23 15:35:03 2007 Subject: [sldev] Re: Hooking the wii up to SL for head (body?) tracking In-Reply-To: <3b19a500712231529y18a3a032w836ec4283d0f256e@mail.gmail.com> References: <3b19a500712231529y18a3a032w836ec4283d0f256e@mail.gmail.com> Message-ID: <3b19a500712231535t498b3634sf59caf7e2aef7631@mail.gmail.com> "it would be an interesting effect if the client could use this to project where you are in the room relative to your avatar's location in SecondLife in mouselook." Sorry, I meant track your position relative to some fixed point in the room (the "window" Mr Lee talks about..). I guess you could set it up so the window moved relative to your avatar when you want to move 'locales' .. but you'd probably lose the 3d effect during that period of time. On Dec 23, 2007 3:29 P Tim Shephard wrote: > A pretty interesting project: > > http://www.youtube.com/watch?v=Jd3-eiid-Uw > > My guess is that if you projected a very large secondlife screen onto > a wall, it would be an interesting effect if the client could use this > to project where you are in the room relative to your avatar's > location in SecondLife in mouselook. > > I don't think this does much for tracking the angle of your head > relative to your body, so you'd probably have to stiff neck it. Maybe > there is a way to do that with a third infrared LED (the wii can track > up to 4, apparently). If not, there is a fascinating use of a > gyroscope which might be of use: > > http://video.google.com/videoplay?docid=-2237947353453839215&q=rc+plane+vr+goggles&total=8&start=0&num=10&so=0&type=search&plindex=0 > > Anyhow, cool stuff. > From tlang303 at gmail.com Sun Dec 23 18:03:55 2007 From: tlang303 at gmail.com (Tobias Lang) Date: Sun Dec 23 18:03:58 2007 Subject: [sldev] Re: Hooking the wii up to SL for head (body?) tracking In-Reply-To: <3b19a500712231535t498b3634sf59caf7e2aef7631@mail.gmail.com> References: <3b19a500712231529y18a3a032w836ec4283d0f256e@mail.gmail.com> <3b19a500712231535t498b3634sf59caf7e2aef7631@mail.gmail.com> Message-ID: <66bc8ec50712231803r752f1bd6g8ef5d3099ea18f47@mail.gmail.com> Hi, yes, this particular head tracking method is acutally pretty neat. In this context it might be interesting to point to our own research project, which uses Second Life for Augmented Reality (AR). For people who don't know AR - it is a technology which incorporates virtual graphics to a real environment. AR also relies on headtracking (more specifically). In our setup, we use live video and a 6 Degree-of-Freedom tracker to blend Second Life graphics perspectively correct within a physical room. Please take a look at http://arsecondlife.gvu.gatech.edu for more information. The Wii tracking setup shown in the video could actually be integrated pretty easy into our modified SL client - thanks for sharing it. -Tobias On Dec 23, 2007 6:35 PM, Tim Shephard wrote: > "it would be an interesting effect if the client could use this > to project where you are in the room relative to your avatar's > location in SecondLife in mouselook." > > Sorry, I meant track your position relative to some fixed point in the > room (the "window" Mr Lee talks about..). I guess you could set it > up so the window moved relative to your avatar when you want to move > 'locales' .. but you'd probably lose the 3d effect during that period > of time. > > > > On Dec 23, 2007 3:29 P Tim Shephard wrote: > > A pretty interesting project: > > > > http://www.youtube.com/watch?v=Jd3-eiid-Uw > > > > My guess is that if you projected a very large secondlife screen onto > > a wall, it would be an interesting effect if the client could use this > > to project where you are in the room relative to your avatar's > > location in SecondLife in mouselook. > > > > I don't think this does much for tracking the angle of your head > > relative to your body, so you'd probably have to stiff neck it. Maybe > > there is a way to do that with a third infrared LED (the wii can track > > up to 4, apparently). If not, there is a fascinating use of a > > gyroscope which might be of use: > > > > > http://video.google.com/videoplay?docid=-2237947353453839215&q=rc+plane+vr+goggles&total=8&start=0&num=10&so=0&type=search&plindex=0 > > > > Anyhow, cool stuff. > > > _______________________________________________ > 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/20071223/78d65acf/attachment.htm From sldev at free.fr Mon Dec 24 01:57:57 2007 From: sldev at free.fr (Henri Beauchamp) Date: Mon Dec 24 01:57:58 2007 Subject: [sldev] Viewer Source Release of FL-1.18.6.76116 In-Reply-To: <347b550f0712221109v453cc189nb9c9428d458eded0@mail.gmail.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <476C4EFA.6080203@lindenlab.com> <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> <347b550f0712221109v453cc189nb9c9428d458eded0@mail.gmail.com> Message-ID: <20071224105757.49fe2dd6.sldev@free.fr> On Sat, 22 Dec 2007 20:09:52 +0100, Barney Boomslang wrote: > Uh, so this "double checks" do happen? I doubt it with some of the source > drops, but well, if in dubio pro reo, eh? But well, even if you don't > actually double check, it would have been nice to pay attention to the build > problems of the _previous_ source drop for FL and actually include the > missing glh headers ... > Oh, the headers Nicholaz provides on his site do help, but for Macs the > includes for gl.h need adaption in the glh headers, still. And even after > adapting the GL/gl.h include in one of the glh headers to OpenGL/gl.h, I get > an error later on about GLH_EXT_NAME not being declared. I guess the glh > headers somehow are platform specific? You may use the patch I posted a few days ago for VWR-3415 on the JIRA ( http://jira.secondlife.com/browse/VWR-3415 ). The headers in there allow me to build a functional Windlight viewer. Henri Beauchamp. From alissa_sabre at yahoo.co.jp Tue Dec 25 07:58:25 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue Dec 25 07:58:40 2007 Subject: [sldev] [VWR] Compiling WindLight on MacOS Message-ID: <1f84kznds4kw885Y6PJdG5cL.alissa_sabre@yahoo.co.jp> Has anybody tried compiling WindLight viewer on MacOS? I grabbed and compiled the FL-1.18.6.76116 source on MacOS X (10.4.11). The first try failed because glh/glh_linear.h and glh/glh_convenience.h were not found. So, I went to the Nick's site and downloaded http://www.blueflash.cc/users/nicholaz/~libs/glh.zip Then, I got an error message that says GL/gl.h : No such file or directory in glh_convenience.h. Well, on MacOS (or xcode I should say), gl.h is under OpenGL directory but GL, so it must be included as . I edited the file as follows: #if LL_DARWIN #include #else #include #endif The problem here is, that the include is in glh_convenience.h, and the comment in glh_convenience.h says "glh is platform independent". Also, the file has NVIDIA copyright. I have a feeling that I should not put SL specific LL_DARWIN or any other platform-specific macro/#if's there. What should I do? What Lindens are doing? Any idea? # I hope Soft makes source QA on WindLight next time... Alissa Sabre -------------------------------------- New Design Yahoo! JAPAN 2008/01/01 http://pr.mail.yahoo.co.jp/newdesign/ From nicholaz at blueflash.cc Tue Dec 25 08:32:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Dec 25 08:32:32 2007 Subject: [sldev] [VWR] Compiling WindLight on MacOS In-Reply-To: <1f84kznds4kw885Y6PJdG5cL.alissa_sabre@yahoo.co.jp> References: <1f84kznds4kw885Y6PJdG5cL.alissa_sabre@yahoo.co.jp> Message-ID: <47713096.8010705@blueflash.cc> Hi! My files up there already had minor modifications (including with "glh/" or "gl/" and also one MSVC warning fixed) so I just added Alissa's #ifdef to the ZIP file on my server. If anyone else finds something that needs tweaked for a good compile, please let me know. Nick Alissa Sabre wrote: > Has anybody tried compiling WindLight viewer on MacOS? > > I grabbed and compiled the FL-1.18.6.76116 source on MacOS X > (10.4.11). The first try failed because glh/glh_linear.h and > glh/glh_convenience.h were not found. So, I went to the Nick's site > and downloaded http://www.blueflash.cc/users/nicholaz/~libs/glh.zip > > Then, I got an error message that says GL/gl.h : No such file or > directory in glh_convenience.h. Well, on MacOS (or xcode I should > say), gl.h is under OpenGL directory but GL, so it must be included as > . I edited the file as follows: > > #if LL_DARWIN > #include > #else > #include > #endif > > The problem here is, that the include is in > glh_convenience.h, and the comment in glh_convenience.h says "glh is > platform independent". Also, the file has NVIDIA copyright. I have a > feeling that I should not put SL specific LL_DARWIN or any other > platform-specific macro/#if's there. > > What should I do? What Lindens are doing? > > Any idea? > > # I hope Soft makes source QA on WindLight next time... > > Alissa Sabre > -------------------------------------- > New Design Yahoo! JAPAN 2008/01/01 > http://pr.mail.yahoo.co.jp/newdesign/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From bboomslang at googlemail.com Tue Dec 25 10:54:56 2007 From: bboomslang at googlemail.com (Barney Boomslang) Date: Tue Dec 25 10:55:02 2007 Subject: [sldev] [VWR] Compiling WindLight on MacOS In-Reply-To: <47713096.8010705@blueflash.cc> References: <1f84kznds4kw885Y6PJdG5cL.alissa_sabre@yahoo.co.jp> <47713096.8010705@blueflash.cc> Message-ID: <347b550f0712251054q7d0bbb6dl43e82e8a1752a74a@mail.gmail.com> Thanks folks, that helped me to finally get a nicholaz build of windlight going on the mac :) will upload it to my server soon, just giving it a test twirl now. bye, Barney On Dec 25, 2007 5:32 PM, Nicholaz Beresford wrote: > > Hi! > > My files up there already had minor modifications (including > with "glh/" or "gl/" and also one MSVC warning fixed) so I just > added Alissa's #ifdef to the ZIP file on my server. > > If anyone else finds something that needs tweaked for a good > compile, please let me know. > > > > Nick > > > Alissa Sabre wrote: > > Has anybody tried compiling WindLight viewer on MacOS? > > > > I grabbed and compiled the FL-1.18.6.76116 source on MacOS X > > (10.4.11). The first try failed because glh/glh_linear.h and > > glh/glh_convenience.h were not found. So, I went to the Nick's site > > and downloaded http://www.blueflash.cc/users/nicholaz/~libs/glh.zip > > > > Then, I got an error message that says GL/gl.h : No such file or > > directory in glh_convenience.h. Well, on MacOS (or xcode I should > > say), gl.h is under OpenGL directory but GL, so it must be included as > > . I edited the file as follows: > > > > #if LL_DARWIN > > #include > > #else > > #include > > #endif > > > > The problem here is, that the include is in > > glh_convenience.h, and the comment in glh_convenience.h says "glh is > > platform independent". Also, the file has NVIDIA copyright. I have a > > feeling that I should not put SL specific LL_DARWIN or any other > > platform-specific macro/#if's there. > > > > What should I do? What Lindens are doing? > > > > Any idea? > > > > # I hope Soft makes source QA on WindLight next time... > > > > Alissa Sabre > > -------------------------------------- > > New Design Yahoo! JAPAN 2008/01/01 > > http://pr.mail.yahoo.co.jp/newdesign/ > > _______________________________________________ > > 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/20071225/17f5bb58/attachment.htm From alissa_sabre at yahoo.co.jp Wed Dec 26 05:48:25 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Dec 26 06:08:42 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <94EC7322-70DB-4D46-8621-1376C1457D16@lindenlab.com> References: <94EC7322-70DB-4D46-8621-1376C1457D16@lindenlab.com> Message-ID: <76GJ4ds4s0hds48Lxasxhs0b.alissa_sabre@yahoo.co.jp> > > What's wrong with including the human readable message after the > > 307? That's what that part of the HTTP protocol is for. No. It's a bad idea because you can't translate it into user's language. Putting some ASCII string containing some English text after a response code is part of the Internet protocol tradition, but it is designed in 1970s when the net was designed only for US citizen. You can't assume everybody on the net understands English language anymore. The message after the error code is not for users; it is for developers and experienced administrators. > That's fine too. How about both, so that the Reason can be used as the > machine readable version, and the body could contain additional > metadata such as a human readable version. Yes. This is fine, as long as the language used in the body reflects the user's preferred language, e.g., through Accept-Language header field in the HTTP request. -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From secret.argent at gmail.com Wed Dec 26 09:09:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 26 09:09:23 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <76GJ4ds4s0hds48Lxasxhs0b.alissa_sabre@yahoo.co.jp> References: <94EC7322-70DB-4D46-8621-1376C1457D16@lindenlab.com> <76GJ4ds4s0hds48Lxasxhs0b.alissa_sabre@yahoo.co.jp> Message-ID: On 2007-12-26, at 07:48, Alissa Sabre wrote: >>> What's wrong with including the human readable message after the >>> 307? That's what that part of the HTTP protocol is for. > > No. It's a bad idea because you can't translate it into user's > language. Why not? Where in the spec does it say that the human-readable message for the status code can't be based on the same internationalization policies as anything else in the response? This message, in this case, is generated by the same software that is generating the message in the body, and should follow the same policy as the same message in the body. There's even an HTTP/1.1 header, "Vary", for the server to inform the client that the response was modified based on an entry in the header. Eg: Request: GET /ixnay HTTP/1.1 Accept-Language pig-latin Response: HTTP/1.1 404 Onay Uchsay Agepay Vary: Accept-Language Possibly it should follow something similar to RFC 3463 (supersedes 1893), where there's a detailed status code buried in the response. Or, better, use RFC 2774 HTTP/1.1 307 Moved Temporarily Opt: "http://xxx.secondlife.com/authentication"; ns=23 23-Status: 307.42 Account on hold 23-Language-Encoding: en-us... http://www.faqs.org/rfcs/rfc2774.html Yes, this is an experimental protocol, but it's documented in RFC-4229 so it's not going to conflict. > The message after the error code is not for users; it is for > developers and experienced administrators. The message after the status code is routinely delivered to end- users, by all kinds of software, when it's the best available response (for example, a fatal error with no body). The only software that I have run into that goes to great lengths to hide this information is Internet Explorer... and any time IE does something different than the rest of the world the odds are pretty overwhelming that it's not the rest of the world that's messed up (this is not to say that anything by Microsoft is suspect, just that IE seems to have become Microsoft's resident foulup fairy). From teravus at gmail.com Wed Dec 26 09:31:06 2007 From: teravus at gmail.com (Teravus Ovares) Date: Wed Dec 26 09:31:09 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <94EC7322-70DB-4D46-8621-1376C1457D16@lindenlab.com> <76GJ4ds4s0hds48Lxasxhs0b.alissa_sabre@yahoo.co.jp> Message-ID: <34cc66250712260931ka678d05n478cbd42dabceeec@mail.gmail.com> Just as a side note, Since we're talking about HTTP status codes.. a 301 Permanantly moved status code *works* so long as your calling form says; or you set the Headers to explicitly tell the browser not to cache. (Tested on OpenSim with redirection to a secondlife:///app/login url, though, there's another bug where the client only logs into agni or lldmz - VWR-4021) Best Regards On 12/26/07, Argent Stonecutter wrote: > > On 2007-12-26, at 07:48, Alissa Sabre wrote: > > >>> What's wrong with including the human readable message after the > >>> 307? That's what that part of the HTTP protocol is for. > > > > > No. It's a bad idea because you can't translate it into user's > > language. > > Why not? Where in the spec does it say that the human-readable > message for the status code can't be based on the same > internationalization policies as anything else in the response? > > This message, in this case, is generated by the same software that is > generating the message in the body, and should follow the same policy > as the same message in the body. There's even an HTTP/1.1 header, > "Vary", for the server to inform the client that the response was > modified based on an entry in the header. > > Eg: > Request: > GET /ixnay HTTP/1.1 > Accept-Language pig-latin > > Response: > HTTP/1.1 404 Onay Uchsay Agepay > Vary: Accept-Language > > Possibly it should follow something similar to RFC 3463 (supersedes > 1893), where there's a detailed status code buried in the response. > > Or, better, use RFC 2774 > > HTTP/1.1 307 Moved Temporarily > Opt: "http://xxx.secondlife.com/authentication"; ns=23 > 23-Status: 307.42 Account on hold > 23-Language-Encoding: en-us... > > http://www.faqs.org/rfcs/rfc2774.html > > Yes, this is an experimental protocol, but it's documented in > RFC-4229 so it's not going to conflict. > > > The message after the error code is not for users; it is for > > developers and experienced administrators. > > The message after the status code is routinely delivered to end- > users, by all kinds of software, when it's the best available > response (for example, a fatal error with no body). The only software > that I have run into that goes to great lengths to hide this > information is Internet Explorer... and any time IE does something > different than the rest of the world the odds are pretty overwhelming > that it's not the rest of the world that's messed up (this is not to > say that anything by Microsoft is suspect, just that IE seems to have > become Microsoft's resident foulup fairy). > > _______________________________________________ > 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/20071226/f25367d3/attachment.htm From lenglish5 at cox.net Wed Dec 26 09:32:21 2007 From: lenglish5 at cox.net (Lawson English) Date: Wed Dec 26 09:32:26 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <94EC7322-70DB-4D46-8621-1376C1457D16@lindenlab.com> <76GJ4ds4s0hds48Lxasxhs0b.alissa_sabre@yahoo.co.jp> Message-ID: <47729025.2080603@cox.net> Argent Stonecutter wrote: > [...] > The message after the status code is routinely delivered to end-users, > by all kinds of software, when it's the best available response (for > example, a fatal error with no body). The only software that I have > run into that goes to great lengths to hide this information is > Internet Explorer... and any time IE does something different than the > rest of the world the odds are pretty overwhelming that it's not the > rest of the world that's messed up (this is not to say that anything > by Microsoft is suspect, just that IE seems to have become Microsoft's > resident foulup fairy). > Actually, anything Microsoft does IS suspect. They may have improved in recent years, but it really WAS the unofficial motto of the DOS division of MS that "DOS ain't done 'til Lotus won't run." The OS division at Apple found that the main reason they couldn't upgrade the Mac OS past a certain point was because it would break certain "important word processing software," no matter how they did it (It wasn't purchasing NeXT that allowed Apple to bring out a new OS, it was falling RAM prices that allowed them to run two OS's simultaneously so they could support legacy MS software without interfering with the features of the new OS). Even MS's own software wasn't immune to MS's interesting policies concerning how software was written. According to insiders who revealed MS's so-called "best software practices" after their non-disclosure agreement had lapsed, MS would allow any application programmer access to the source code of hte OS and, if knowledge of the value of a variable was required, they had two choices: they could request that the variable be exposed via a function call OR they could do what was done in at least one case: examine the call frames of the internals of the text editing routines, implement a callback function, and walk back the required number bytes through the call stack to grab that variable "the hard way." This latter approach, of course, required an upgrade of the application software with each new OS release or patch or potentially for every new processor.... ...hmmm guess MS's practices haven't changed, eh? Lawson From secret.argent at gmail.com Wed Dec 26 09:50:34 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Dec 26 09:50:44 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <47729025.2080603@cox.net> References: <94EC7322-70DB-4D46-8621-1376C1457D16@lindenlab.com> <76GJ4ds4s0hds48Lxasxhs0b.alissa_sabre@yahoo.co.jp> <47729025.2080603@cox.net> Message-ID: On 2007-12-26, at 11:32, Lawson English wrote: > Argent Stonecutter wrote: >> [...] >> The message after the status code is routinely delivered to end- >> users, by all kinds of software, when it's the best available >> response (for example, a fatal error with no body). The only >> software that I have run into that goes to great lengths to hide >> this information is Internet Explorer... and any time IE does >> something different than the rest of the world the odds are pretty >> overwhelming that it's not the rest of the world that's messed up >> (this is not to say that anything by Microsoft is suspect, just >> that IE seems to have become Microsoft's resident foulup fairy). > Actually, anything Microsoft does IS suspect. They may have > improved in recent years, but it really WAS the unofficial motto of > the DOS division of MS that "DOS ain't done 'til Lotus won't run." OK, "this is not to say that everything by Microsoft is messed up". Happy? From alissa_sabre at yahoo.co.jp Thu Dec 27 01:37:37 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Dec 27 05:36:29 2007 Subject: [sldev] Viewer Source Release of FL-1.18.6.76116 In-Reply-To: <476D70F3.1050301@lindenlab.com> References: <476D70F3.1050301@lindenlab.com> Message-ID: <7vfJ6Gc4t0eur2kwmkw4un.alissa_sabre@yahoo.co.jp> Rob, > We're currently in the process of doublechecking the redistribution > rights associated with the version of the GLH code we use, which is > taking us longer than we hoped. Sorry for the inconvenience. I believe that's OK. I understand your effort and difficulties of external negotiation. I also understand your lawyers need to be very careful. It was better if you informed this before or when the WindLight source was distributed. However, hard-to-build source is far better than nothing, and I appreciate LL for distributing the first look viewer source, not waiting for legal clarification of glh license. Please keep distributing more sources, even in case they are incomplete, work-in-progress, or otherwise not ready in an aspect. Alissa Sabre -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From alissa_sabre at yahoo.co.jp Thu Dec 27 05:21:40 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Dec 27 05:36:33 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: Message-ID: > >>> What's wrong with including the human readable message after the > >>> 307? That's what that part of the HTTP protocol is for. > > No. It's a bad idea because you can't translate it into user's > > language. > Why not? Well, if you can send translated message that's fine. I have no big concern how you implement it. > > The message after the error code is not for users; it is for > > developers and experienced administrators. > > The message after the status code is routinely delivered to end- > users, That's true. But, all those programs are wrong, IMHO. -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From secret.argent at gmail.com Thu Dec 27 07:08:00 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Dec 27 07:08:17 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: Message-ID: <9976D8B5-082E-44B9-8B48-03BDC13D4965@gmail.com> On 2007-12-27, at 07:21, Alissa Sabre wrote: >>> The message after the error code is not for users; it is for >>> developers and experienced administrators. >> >> The message after the status code is routinely delivered to end- >> users, > > That's true. But, all those programs are wrong, IMHO. They're wrong for following the RFC? What else is (for example) a program that contains no HTTP or XML parsing code supposed to do? Software that has a valid error message *even not internationalized* and refuses to let the end-user see it is far more in error than software that provides the best information that it has. This is one of the biggest problems with modern GUI software. When something goes wrong down in the innards of the code, and the user needs to know about it, the information they need to know what to do about the problem is thrown away. Then, later, a dialog box pops up and the user gets a message about what the programmer thought was most likely the cause. I've had software tell me that there was a network problem when the real problem was that the user didn't have permission to do what they were trying to do. I've had software tell me that there was a permissions problem when a disk was full. I have had software tell me that I was out of disk space whenever an attempt to save a file failed, even if it was a network error or a permissions problem. I've had software tell me that I needed to restart my computer when the problem was a missing configuration file (so of course that didn't help). The result of trying to protect the user is that the modern computer is all too often like a sick pet. You can see it's unhappy, but it can't tell you that it hurts, or it's bored, or it's mad at you because you moved the water dish. It's like a car where the idiot lights are all miswired, so when you're low on gas it turns on the "upshift" light, and when the radiator overheats it plays a recording... "Your door is open" in any one of 20 melodious voices. And while Second Life is probably the least guilty out of any game software I've ever seen, it does already do a lot of this. I understand why it happens. People want to believe that software is inherently well behaved and reliable. They set up programming guidelines that encourage programmers to attempt to hide errors, because the people who write the guidelines think end-users are better off if they don't see them. Then something goes wrong that wasn't anticipated and the end user ends up convinced that the programmers are insane. Or that computers are somehow inherently impossible for them to understand. From dzonatas at dzonux.net Thu Dec 27 08:07:41 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Dec 27 08:09:40 2007 Subject: [sldev] The criminalization of open source In-Reply-To: References: <47673915.9040909@gmail.com> <1197955427.18986.44.camel@localhost> <47677BEB.5050706@cox.net> <47678141.5050204@gwala.net> <47688505.8080106@dzonux.net> Message-ID: <4773CDCD.5080307@dzonux.net> Argent Stonecutter wrote: > > Whether it has real value or not is irrelevant. The rules of the game > are that it has value in game terms. Things that have value in game > terms get protected in game terms. Even if they're just high scores. > > IN ADDITION, the "toy economy" is what many people are paying LL to > participate in, therefor it, itself, has real value. > If it didn't have any real value, it be pretty hard... no... practically impossible for LL to sustain its mission statement. -- Happy New Years From matthew.dowd at hotmail.co.uk Fri Dec 28 02:16:28 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Dec 28 02:16:29 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: Message-ID: >>>>> What's wrong with including the human readable message after the >>>>> 307? That's what that part of the HTTP protocol is for. > >>> No. It's a bad idea because you can't translate it into user's >>> language. > >> Why not? > > Well, if you can send translated message that's fine. I have no big > concern how you implement it. Well, let's face it, the whole strategy of downloading UI from the web (as in the new logon screen, the new search etc.) does not lend itself well to community driven internationalisation. In the current non-RC/non-Windlight client, if someone wants to maintain a High Tibetian (say) version, they can, by editing the skin files (although as has been noted here, this would be helped by tooling for maintaining the skins files after the initial translation into future versions). Although the new logon screen sends a parameter to the web server to request different languages, you are completely beholden to LL deciding to host and maintain a webpage in that language. Anyone wanting to offer a logon screen in a different language would have to distribute a third party client which either pulled down the logon page from a different server (but sent the form post to LL) or did the entire logon page in XUI. Matthew _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml From matthew.dowd at hotmail.co.uk Fri Dec 28 02:22:56 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Dec 28 02:22:57 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: Message-ID: ---------------------------------------- > Date: Thu, 27 Dec 2007 22:21:40 +0900 > From: alissa_sabre@yahoo.co.jp > To: sldev@lists.secondlife.com > Subject: Re: [sldev] Re: [VWR] Web login without llmozlib > >>>>> What's wrong with including the human readable message after the >>>>> 307? That's what that part of the HTTP protocol is for. > >>> No. It's a bad idea because you can't translate it into user's >>> language. > >> Why not? > > Well, if you can send translated message that's fine. I have no big > concern how you implement it. http://jira.secondlife.com/browse/VWR-4016 gives a suggested mechanism for this: "It is suggested to send the user's preferred language through an Accept-Language header field in HTTP request, and let the server send back a login screen in the matching language. That's the standard way the web works." But as noted in the last e-mail - community driven localisations are no longer possible without LL support. Matthew _________________________________________________________________ Who's friends with who and co-starred in what? http://www.searchgamesbox.com/celebrityseparation.shtml From tateru.nino at gmail.com Fri Dec 28 07:20:09 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Dec 28 07:20:58 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: Message-ID: <47751429.3010507@gmail.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071229/dab3e962/attachment.htm From secret.argent at gmail.com Fri Dec 28 07:40:17 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Dec 28 07:40:21 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <47751429.3010507@gmail.com> References: <47751429.3010507@gmail.com> Message-ID: On 2007-12-28, at 09:20, Tateru Nino wrote: > As I understand it, the present (1.18.6) HTML logon screen is only > temporary, and in some future version (1.18.7?) there will be no > logon screen at all - you'll be launching SL through your already > logged in account from the LL website. And the phishers will have a field day with that. From matthew.dowd at hotmail.co.uk Fri Dec 28 09:55:44 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Fri Dec 28 09:56:03 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: <47751429.3010507@gmail.com> References: <47751429.3010507@gmail.com> Message-ID: > As I understand it, the present (1.18.6) HTML logon screen is only temporary, and in some future version (1.18.7?) there will be no logon screen at all - you'll be launching SL through your already logged in account from the LL website. My understanding was that, that would be an optional way of logging onto SL in addition to logging on within the client. It had better be optional - we've already rehearsed many of the problems that the logon via web page approach will cause particularly if you have alts, logon to different grids, have multiple versions of the client installed, are testing new client builds, run the client with different commandline options, run the client with different OS options (e.g. I have icons for startng the client with different processor affinities), etc. and that before we get onto all the security/safety loopholes! Here's wishing LL a sudden revelation of common sense in 2008 ;-) Matthew _________________________________________________________________ Get Hotmail on your mobile, text MSN to 63463! http://mobile.uk.msn.com/pc/mail.aspx From lenglish5 at cox.net Fri Dec 28 10:07:43 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Dec 28 10:07:46 2007 Subject: [sldev] Re: [VWR] Web login without llmozlib In-Reply-To: References: <47751429.3010507@gmail.com> Message-ID: <47753B6F.2090305@cox.net> Matthew Dowd wrote: >> As I understand it, the present (1.18.6) HTML logon screen is only temporary, and in some future version (1.18.7?) there will be no logon screen at all - you'll be launching SL through your already logged in account from the LL website. >> > > My understanding was that, that would be an optional way of logging onto SL in addition to logging on within the client. > > It had better be optional - we've already rehearsed many of the problems that the logon via web page approach will cause particularly if you have alts, logon to different grids, have multiple versions of the client installed, are testing new client builds, run the client with different commandline options, run the client with different OS options (e.g. I have icons for startng the client with different processor affinities), etc. and that before we get onto all the security/safety loopholes! > > Here's wishing LL a sudden revelation of common sense in 2008 ;-) > > Actually, I thought the web login was a prelude to the multi-grid login, but perhaps I'm wrong. Lawson From sv193702 at ohio.edu Fri Dec 28 19:22:52 2007 From: sv193702 at ohio.edu (Stan Vernier) Date: Fri Dec 28 19:23:07 2007 Subject: [sldev] movement within the client Message-ID: <4775BD8C.6030408@ohio.edu> I'm looking into being able to control the avatar within the client and I'm trying to simulate the teleport script to move the avatar from point a to point b within the same region. I can get the avatar to move from a to b, but the moment I try to move the avatar, it pops back to point a. I tried sendPositionUpdate(), but it didn't work. Anyone got any suggestions? From lenglish5 at cox.net Fri Dec 28 22:37:02 2007 From: lenglish5 at cox.net (Lawson English) Date: Fri Dec 28 22:37:04 2007 Subject: [sldev] movement within the client In-Reply-To: <4775BD8C.6030408@ohio.edu> References: <4775BD8C.6030408@ohio.edu> Message-ID: <4775EB0E.1030707@cox.net> Stan Vernier wrote: > I'm looking into being able to control the avatar within the client > and I'm trying to simulate the teleport script to move the avatar from > point a to point b within the same region. I can get the avatar to > move from a to b, but the moment I try to move the avatar, it pops > back to point a. I tried sendPositionUpdate(), but it didn't work. > Anyone got any suggestions? I suspect the server limits non-TP motion to no more than 10 meters just like with LSL. You could fake a warppos thing I suppose. Lawson From kelly at lindenlab.com Fri Dec 28 22:49:45 2007 From: kelly at lindenlab.com (Kelly Linden) Date: Fri Dec 28 22:49:54 2007 Subject: [sldev] movement within the client In-Reply-To: <4775EB0E.1030707@cox.net> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> Message-ID: <4775EE09.8000602@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20071228/aa4f1f3d/attachment.htm From meni.kaiousei at gmail.com Sat Dec 29 05:46:36 2007 From: meni.kaiousei at gmail.com (Meni Kaiousei) Date: Sat Dec 29 05:46:40 2007 Subject: [sldev] new login feature compromised in the windlight linux client? Message-ID: <7139dfaa0712290546o76b7b8cer4fef496390e91b9c@mail.gmail.com> I just saw this Jira issue reported by Birkoff Enoch: https://jira.secondlife.com/browse/VWR-4037 It looks like the login webpage for the German version of the SecondLife_i686_1_18_6_76116_WINDLIGHT linux client points to https://sdfsfsfds.com. Someone registered that domain name yesterday: Domain Name: SDFSFSFDS.COM Registrar: RED REGISTER, INC. Whois Server: whois.redregister.com Referral URL: http://www.redregister.com Name Server: NS1.IDITE-NA-HUI.COM Name Server: NS2.IDITE-NA-HUI.COM Status: ok Updated Date: 26-dec-2007 Creation Date: 26-dec-2007 Expiration Date: 26-dec-2008 From robin.cornelius at gmail.com Sat Dec 29 06:04:00 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Dec 29 06:02:53 2007 Subject: [sldev] new login feature compromised in the windlight linux client? In-Reply-To: <7139dfaa0712290546o76b7b8cer4fef496390e91b9c@mail.gmail.com> References: <7139dfaa0712290546o76b7b8cer4fef496390e91b9c@mail.gmail.com> Message-ID: <477653D0.40308@gmail.com> Meni Kaiousei wrote: > I just saw this Jira issue reported by Birkoff Enoch: > https://jira.secondlife.com/browse/VWR-4037 > Has this been reported through the security process? http://wiki.secondlife.com/wiki/Security_issues I've CC'd security to make sure. Although this looks like a simple mistake by whoever copied the panel_login.xml file, its an unacceptable mistake and the person responsible should NOT have done this. If they wanted a temporary page they should have pointed at the english version or a other page on the linden servers. Considering this web login was forced upon us as the "solution" this is a grave situation. It doesn't look like the owner of the reported domain has a spoof page (yet) and infact its not accepting https connections, its just being squatted upon. But there is now a real risk that if a spoof page appeared anyone using the broken release would have a compromised account. I think LL need to scan that domain now and if they see a spoof page get an immediate take down. Regards Robin From tateru.nino at gmail.com Sat Dec 29 09:33:18 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Dec 29 09:34:05 2007 Subject: [sldev] movement within the client In-Reply-To: <4775EE09.8000602@lindenlab.com> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4775EE09.8000602@lindenlab.com> Message-ID: <477684DE.7080800@gmail.com> Kelly Linden wrote: > Lawson English wrote: >> Stan Vernier wrote: >>> I'm looking into being able to control the avatar within the client >>> and I'm trying to simulate the teleport script to move the avatar >>> from point a to point b within the same region. I can get the >>> avatar to move from a to b, but the moment I try to move the avatar, >>> it pops back to point a. I tried sendPositionUpdate(), but it >>> didn't work. Anyone got any suggestions? >> >> I suspect the server limits non-TP motion to no more than 10 meters >> just like with LSL. You could fake a warppos thing I suppose. >> >> >> Lawson >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > TPs within the same sim are greatly shortcut from 'normal' TPs and > should be near instant. I'd suggest you try just using the standard > TP calls to trigger a TP, if you want to get fancy you could do > something about the TP Progress screen (like, not show it). I think > this may be the easiest way to do what you want. > > - Kelly Actually, on the occasions that the TP progress screen fails to appear - the effect is really very cool. The world around you deconstructs, and then the new configuration assembles itself rapidly all around the avatar. Well worth seeing, though there's no reliable repro. -- Tateru Nino http://dwellonit.blogspot.com/ From sv193702 at ohio.edu Sat Dec 29 10:52:41 2007 From: sv193702 at ohio.edu (Stan Vernier) Date: Sat Dec 29 10:53:05 2007 Subject: [sldev] movement within the client In-Reply-To: <4775EE09.8000602@lindenlab.com> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4775EE09.8000602@lindenlab.com> Message-ID: <47769779.9000003@ohio.edu> Kelly Linden wrote: > Lawson English wrote: >> Stan Vernier wrote: >>> I'm looking into being able to control the avatar within the client >>> and I'm trying to simulate the teleport script to move the avatar >>> from point a to point b within the same region. I can get the >>> avatar to move from a to b, but the moment I try to move the avatar, >>> it pops back to point a. I tried sendPositionUpdate(), but it >>> didn't work. Anyone got any suggestions? >> >> I suspect the server limits non-TP motion to no more than 10 meters >> just like with LSL. You could fake a warppos thing I suppose. >> >> >> Lawson >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > TPs within the same sim are greatly shortcut from 'normal' TPs and > should be near instant. I'd suggest you try just using the standard > TP calls to trigger a TP, if you want to get fancy you could do > something about the TP Progress screen (like, not show it). I think > this may be the easiest way to do what you want. > > - Kelly Huh, it works(kinda). In my experience, the teleport ability never seemed to work within a region, but it works fine as long as there isn't a telehub on the island. If there is, it seems to either throw an error that you're too close to the point to teleport or teleports you to the telehub. I'll be looking into bypassing the telehub, but thanks for the help! From phoenix at secondlife.com Sat Dec 29 10:52:07 2007 From: phoenix at secondlife.com (Phoenix) Date: Sat Dec 29 10:55:13 2007 Subject: [sldev] new login feature compromised in the windlight linux client? In-Reply-To: <7139dfaa0712290546o76b7b8cer4fef496390e91b9c@mail.gmail.com> References: <7139dfaa0712290546o76b7b8cer4fef496390e91b9c@mail.gmail.com> Message-ID: We are evaluating the problem now and are currently taking steps to address this. The first look viewer has been taken down and taking further actions to prevent the owner of sdfsfsfds.com from unauthorized access to accounts. On 2007-12-29, at 5:46 , Meni Kaiousei wrote: > I just saw this Jira issue reported by Birkoff Enoch: > https://jira.secondlife.com/browse/VWR-4037 > > It looks like the login webpage for the German version of the > SecondLife_i686_1_18_6_76116_WINDLIGHT linux client points to > https://sdfsfsfds.com. > > Someone registered that domain name yesterday: > > Domain Name: SDFSFSFDS.COM > Registrar: RED REGISTER, INC. > Whois Server: whois.redregister.com > Referral URL: http://www.redregister.com > Name Server: NS1.IDITE-NA-HUI.COM > Name Server: NS2.IDITE-NA-HUI.COM > Status: ok > Updated Date: 26-dec-2007 > Creation Date: 26-dec-2007 > Expiration Date: 26-dec-2008 > _______________________________________________ > 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/20071229/c8ff0cd6/PGP.pgp From robin.cornelius at gmail.com Sat Dec 29 11:04:30 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Dec 29 11:03:31 2007 Subject: [sldev] [VWR] OpenAL and streaming audio via gstreamer Message-ID: <47769A3E.1000900@gmail.com> Hi Guys, Fiddled with Seg's OpenAL patch and have munged in gstreamer support for streaming audio. So now i have a completely opensource client with sound, streaming audio and streaming video :-) (only missing is wind and i don't miss that) I've uploaded my patch to VWR-2662 As i mentioned on the JIRA, it probably needs some better null pointer protection and to ensure that LLMediaImplGStreamer really does what we want in this instance, but its a quick hack for the moment to at least get things moving :-) Robin From seg at haxxed.com Sat Dec 29 12:43:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Dec 29 12:42:38 2007 Subject: [sldev] [VWR] OpenAL and streaming audio via gstreamer In-Reply-To: <47769A3E.1000900@gmail.com> References: <47769A3E.1000900@gmail.com> Message-ID: <1198960988.3486.84.camel@localhost> On Sat, 2007-12-29 at 19:04 +0000, Robin Cornelius wrote: > Hi Guys, > > Fiddled with Seg's OpenAL patch and have munged in gstreamer support for > streaming audio. So now i have a completely opensource client with > sound, streaming audio and streaming video :-) (only missing is wind and > i don't miss that) Sweet. Though of course jira is refusing connections right now. Now can someone confirm if the lossless texture bug has been fixed in 1.18.6? I'm kind of a long way from getting 1.18.6 working... Also, WTF won't gstreamer work in Fedora... (Seems to be arcane threading problems. There's a jira related to this but its down so I can't get the number...) -------------- 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/20071229/de30f76e/attachment.pgp From phoenix at secondlife.com Sat Dec 29 13:06:30 2007 From: phoenix at secondlife.com (Phoenix) Date: Sat Dec 29 13:06:40 2007 Subject: [sldev] [VWR] OpenAL and streaming audio via gstreamer In-Reply-To: <1198960988.3486.84.camel@localhost> References: <47769A3E.1000900@gmail.com> <1198960988.3486.84.camel@localhost> Message-ID: <71FDC10C-CA37-4123-9987-22352F34AAAD@secondlife.com> I have contacted the hosting provider for jira. The openjpeg texture issue ( https://jira.secondlife.com/browse/ VWR-1475 ) is tagged as being in the 1.19.0 viewer. On 2007-12-29, at 12:43 , Callum Lerwick wrote: > Sweet. Though of course jira is refusing connections right now. Now > can > someone confirm if the lossless texture bug has been fixed in 1.18.6? > I'm kind of a long way from getting 1.18.6 working... > > Also, WTF won't gstreamer work in Fedora... (Seems to be arcane > threading problems. There's a jira related to this but its down so I > can't get the number...) -------------- 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/20071229/386344bc/PGP.pgp From jhurliman at wsu.edu Sat Dec 29 13:31:37 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Dec 29 13:31:43 2007 Subject: [sldev] movement within the client In-Reply-To: <4775EB0E.1030707@cox.net> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> Message-ID: <4776BCB9.7040103@wsu.edu> Lawson English wrote: > Stan Vernier wrote: >> I'm looking into being able to control the avatar within the client >> and I'm trying to simulate the teleport script to move the avatar >> from point a to point b within the same region. I can get the avatar >> to move from a to b, but the moment I try to move the avatar, it pops >> back to point a. I tried sendPositionUpdate(), but it didn't work. >> Anyone got any suggestions? > > I suspect the server limits non-TP motion to no more than 10 meters > just like with LSL. You could fake a warppos thing I suppose. > > > Lawson The client doesn't actually send positional movements to the server at all, it sends the equivalent of keypresses (a large bitflag integer in the AgentUpdate packet) and the server which has the physics engine calculates movement based on that and sends updates back to the client. The only way around this is to do a local teleport, but if there is a very large plot of land in the region with a landing spot/telehub, or the entire region has a telehub you have a problem. If you do find any way around this please keep the list updated with your findings as many people would be interested to know. John From robin.cornelius at gmail.com Sat Dec 29 13:40:20 2007 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat Dec 29 13:39:19 2007 Subject: [sldev] [VWR] OpenAL and streaming audio via gstreamer In-Reply-To: <1198960988.3486.84.camel@localhost> References: <47769A3E.1000900@gmail.com> <1198960988.3486.84.camel@localhost> Message-ID: <4776BEC4.90704@gmail.com> Callum Lerwick wrote: > On Sat, 2007-12-29 at 19:04 +0000, Robin Cornelius wrote: > >> Hi Guys, >> >> Fiddled with Seg's OpenAL patch and have munged in gstreamer support for >> streaming audio. So now i have a completely opensource client with >> sound, streaming audio and streaming video :-) (only missing is wind and >> i don't miss that) >> > > Sweet. Though of course jira is refusing connections right now. Now can > someone confirm if the lossless texture bug has been fixed in 1.18.6? > I'm kind of a long way from getting 1.18.6 working... > > I don't think it hit 1.18.6.X BTW have a look at the patches i use to build the Debian version http://slupdate.byteme.org.uk/svn/ you will find the patch sets under slviewer/slviewer/trunk/debian/patches/ Check out the whole lot if you want from svn://slupdate.byteme.org.uk/slviewer/slviewer/trunk Also you did see the curl patch to avoid LLMozLib did you? > Also, WTF won't gstreamer work in Fedora... (Seems to be arcane > threading problems. There's a jira related to this but its down so I > can't get the number...) > Something seems horribly broken here in Fedora Robin From phoenix at secondlife.com Sat Dec 29 13:41:33 2007 From: phoenix at secondlife.com (Phoenix) Date: Sat Dec 29 13:41:50 2007 Subject: [sldev] jira back up Message-ID: <930B01FC-B4FD-4E76-A013-63F926C60E54@secondlife.com> Apparently it was a firewall problem that has been corrected. Thanks for the heads up. -------------- 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/20071229/64f3a25a/PGP.pgp From josh at lindenlab.com Sat Dec 29 14:29:23 2007 From: josh at lindenlab.com (Joshua Bell) Date: Sat Dec 29 14:27:38 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <476C4EFA.6080203@lindenlab.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <476C4EFA.6080203@lindenlab.com> Message-ID: <4776CA43.2040809@lindenlab.com> As called out on this page http://www.massively.com/2007/12/29/german-second-life-users-at-risk/ the Second Life 1.18.6 RC2 package contains an incorrect URL ("sdfsfsfds.com") for the German language login page (/skins/xui/de/panel_login.xml). This affects both the RC-1.18.6.2 and the WindLight FL-1.18.6.76116. We are in the process of rebuilding/repackaging viewers for download with a corrected URL. Developers who build from source should correct the URL (to "secondlife.com"). Anyone who is distributing viewers based on this code base should update and repackage the viewers so that users are not at risk. This does not affect the "release branch" source (20071221a) made available on the same day. Anthony Foster wrote: > Hey everyone, > > Release Candidate in time for the holiday weekend. > > RC-1.18.6.2 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_RC-1.18.6.2 > > Release note information here: > http://blog.secondlife.com/2007/12/21/updated-release-candidate-viewer-second-life-1186-rc2-available-today/ > > > Checksums: > > ab0d0957c1e3b6991a0df0f85b4200ac slviewer-darwin-libs-RC-1.18.6.2.tar.gz > b25f0a64db07b5d714f436d6970ec0bc slviewer-linux-libs-RC-1.18.6.2.tar.gz > 1d4744b6502f34612597e61ecb0bc892 slviewer-src-RC-1.18.6.2.tar.gz > 6cc9f49811c99db92adc664582029593 slviewer-artwork-RC-1.18.6.2.zip > 710e615d83e9d18b0fa746427282c1de slviewer-src-RC-1.18.6.2.zip > e3e7bfbe47cf784619c7df653265e676 slviewer-win32-libs-RC-1.18.6.2.zip > > > SVN checkout: update to be provided by rob. > > Enjoy. > -Anthony > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From josh at lindenlab.com Sat Dec 29 14:29:36 2007 From: josh at lindenlab.com (Joshua Bell) Date: Sat Dec 29 14:27:44 2007 Subject: [sldev] Viewer Source Release of FL-1.18.6.76116 In-Reply-To: <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> References: <47422988.6000601@lindenlab.com> <474B55B5.2050704@lindenlab.com> <47608821.2030805@lindenlab.com> <476C4EFA.6080203@lindenlab.com> <3399.24.6.233.189.1198300235.squirrel@mail.lindenlab.com> Message-ID: <4776CA50.7060004@lindenlab.com> As called out on this page http://www.massively.com/2007/12/29/german-second-life-users-at-risk/ the Second Life 1.18.6 RC2 package contains an incorrect URL ("sdfsfsfds.com") for the German language login page (/skins/xui/de/panel_login.xml). This affects both the RC-1.18.6.2 and the WindLight FL-1.18.6.76116. We are in the process of rebuilding/repackaging viewers for download with a corrected URL. Developers who build from source should correct the URL (to "secondlife.com"). Anyone who is distributing viewers based on this code base should update and repackage the viewers so that users are not at risk. This does not affect the "release branch" source (20071221a) made available on the same day. anthony@lindenlab.com wrote: > Hey everyone, > > Don't think I forgot about the First Look viewer. WindLight gets a source > drop for the holidays as well. This branch has not be double checked by > soft to build, so it will probably have more issues than the RC source. > > FL-1.18.6.76116 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_FL-1.18.6.76116 > > Release note information here: > http://blog.secondlife.com/2007/12/21/the-new-windlight-viewer-pondering-aesthetics-76116/ > > Checksums: > > 9f7f30febafb75b4b6bb399a2302c341 slviewer-darwin-libs-FL-1.18.6.76116.tar.gz > 6616c748058db3261aeaf71db2e0f6f6 slviewer-linux-libs-FL-1.18.6.76116.tar.gz > 1cfc9c210271289c6a068798125c9e09 slviewer-src-FL-1.18.6.76116.tar.gz > 8f09d005afa93c996fa78592ae469a73 slviewer-artwork-FL-1.18.6.76116.zip > aea0a595d03ec1a3fecf50ea0e011c61 slviewer-src-FL-1.18.6.76116.zip > 5ad269def83da1c7661d5e6c675e491a slviewer-win32-libs-FL-1.18.6.76116.zip > > > SVN checkout: update to be provided by rob. > > Enjoy. > -Anthony > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From seg at haxxed.com Sat Dec 29 14:54:46 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Dec 29 14:54:10 2007 Subject: [sldev] [VWR] OpenAL and streaming audio via gstreamer In-Reply-To: <71FDC10C-CA37-4123-9987-22352F34AAAD@secondlife.com> References: <47769A3E.1000900@gmail.com> <1198960988.3486.84.camel@localhost> <71FDC10C-CA37-4123-9987-22352F34AAAD@secondlife.com> Message-ID: <1198968886.3486.101.camel@localhost> On Sat, 2007-12-29 at 13:06 -0800, Phoenix wrote: > I have contacted the hosting provider for jira. > > The openjpeg texture issue ( https://jira.secondlife.com/browse/ > VWR-1475 ) is tagged as being in the 1.19.0 viewer. Actually the bug I'm talking about is VWR-1815/VWR-2404. http://jira.secondlife.com/browse/VWR-1815 Qarl is claiming a fix on VWR-2404 but I have yet to be able to see it or confirm it. Supposedly it is in 1.18.6 but I haven't got that nightmare working yet. I suppose I could nuke KDU out of an official build and see if the bug is still there... I don't suppose a Linden could pretty please dig into the internal SCM and dig out Qarl's commit for VWR-2404 and toss me the diff. :) I have no idea what his fix even *is*... > > Also, WTF won't gstreamer work in Fedora... (Seems to be arcane > > threading problems. There's a jira related to this but its down so I > > can't get the number...) http://jira.secondlife.com/browse/VWR-3737 -------------- 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/20071229/26172681/attachment.pgp From phoenix at secondlife.com Sat Dec 29 15:18:30 2007 From: phoenix at secondlife.com (Phoenix) Date: Sat Dec 29 15:18:41 2007 Subject: [sldev] [VWR] OpenAL and streaming audio via gstreamer In-Reply-To: <1198968886.3486.101.camel@localhost> References: <47769A3E.1000900@gmail.com> <1198960988.3486.84.camel@localhost> <71FDC10C-CA37-4123-9987-22352F34AAAD@secondlife.com> <1198968886.3486.101.camel@localhost> Message-ID: <096CB91F-D9BC-4FE6-9E68-0BB99883FC7D@secondlife.com> VWR-2044 is marked as fixed in 1.18.6. VWR-1815 does not have a schedule. Digging into the internal SCM would be difficult, but perhaps Qarl knows exactly where the fix can be found. Internally, we're dedicating time to making sure there is no significant difference between the publicly available source and what we are actually working on. On 2007-12-29, at 14:54 , Callum Lerwick wrote: >> The openjpeg texture issue ( https://jira.secondlife.com/browse/ >> VWR-1475 ) is tagged as being in the 1.19.0 viewer. > > Actually the bug I'm talking about is VWR-1815/VWR-2404. > > http://jira.secondlife.com/browse/VWR-1815 > > Qarl is claiming a fix on VWR-2404 but I have yet to be able to see it > or confirm it. Supposedly it is in 1.18.6 but I haven't got that > nightmare working yet. I suppose I could nuke KDU out of an official > build and see if the bug is still there... > > I don't suppose a Linden could pretty please dig into the internal SCM > and dig out Qarl's commit for VWR-2404 and toss me the diff. :) I have > no idea what his fix even *is*... -------------- 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/20071229/a9e74ea8/PGP-0001.pgp From lenglish5 at cox.net Sat Dec 29 17:34:49 2007 From: lenglish5 at cox.net (Lawson English) Date: Sat Dec 29 17:34:51 2007 Subject: [sldev] movement within the client In-Reply-To: <4776BCB9.7040103@wsu.edu> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4776BCB9.7040103@wsu.edu> Message-ID: <4776F5B9.9070604@cox.net> John Hurliman wrote: > Lawson English wrote: >> Stan Vernier wrote: >>> I'm looking into being able to control the avatar within the client >>> and I'm trying to simulate the teleport script to move the avatar >>> from point a to point b within the same region. I can get the >>> avatar to move from a to b, but the moment I try to move the avatar, >>> it pops back to point a. I tried sendPositionUpdate(), but it >>> didn't work. Anyone got any suggestions? >> >> I suspect the server limits non-TP motion to no more than 10 meters >> just like with LSL. You could fake a warppos thing I suppose. >> >> >> Lawson > > The client doesn't actually send positional movements to the server at > all, it sends the equivalent of keypresses (a large bitflag integer in > the AgentUpdate packet) and the server which has the physics engine > calculates movement based on that and sends updates back to the > client. The only way around this is to do a local teleport, but if > there is a very large plot of land in the region with a landing > spot/telehub, or the entire region has a telehub you have a problem. > If you do find any way around this please keep the list updated with > your findings as many people would be interested to know. Thanks for the info. Rather than workarounds, I'd rather that we asked for new features though. This isn't supposed to be a competition to see who can hack the server the best: its supposed to be a collaborative effort to see this thing thrive, or such is my attitude. Lawson From alissa_sabre at yahoo.co.jp Sat Dec 29 17:52:14 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat Dec 29 17:52:28 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <4776CA43.2040809@lindenlab.com> References: <4776CA43.2040809@lindenlab.com> Message-ID: > This affects both the RC-1.18.6.2 and the WindLight FL-1.18.6.76116. We > are in the process of rebuilding/repackaging viewers for download with a > corrected URL. That's fine. > Developers who build from source should correct the URL (to > "secondlife.com"). Anyone who is distributing viewers based on this code > base should update and repackage the viewers so that users are not at risk. Why don't you distribute sources for 1.18.6.3 and 1.18.6.76453 then? -------------------------------------- Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar http://pr.mail.yahoo.co.jp/toolbar/ From jay_reynolds_freeman at mac.com Sun Dec 30 16:11:45 2007 From: jay_reynolds_freeman at mac.com (Jay Reynolds Freeman) Date: Sun Dec 30 16:11:48 2007 Subject: [sldev] Question by newbie to viewer source ... In-Reply-To: References: <4776CA43.2040809@lindenlab.com> Message-ID: <01746F12-9F36-4401-9805-951C12F83B95@mac.com> I am rather a newbie to this list and to the SL viewer source. I have one of those questions which may betray my ignorance and be easily answered by providing a pointer to documentation I have missed; please indulge me while I ask it. I am attempting to build a modified viewer for use in MacOS. I can download sources and get them to build and run with no problem, and I am a moderately experienced Mac developer, Cocoa user, and XCode user. So far, so good, but ... I am particularly interested in access to information provided by the SL servers, to the viewer, that describes the locations and perhaps various items of state about objects, about avatars, and in particular, about the avatar that represents the user. I am also wondering if any collision-detection information is provided by the servers to the viewer (I believe I understand that all collision-detection is done on the servers, but wonder if that information is passed down to the viewer.) I have been through the wiki in some detail, and what appears to be the most promising wiki pages, "Rendering System" and "Viewer Object System", are at the moment just stubs. Is there any other documentation I should look at? What source files, class names, and method names are particularly important to look for? What questions should I be asking if I were not such an ignoramus? Thanks for any pointers, and apologies for wasting bandwidth. Hoping to avoid doing a full calls tree ... -- Jay Reynolds Freeman (CeeJay Tigerpaw) --------------------- Jay_Reynolds_Freeman@mac.com http://web.mac.com/jay_reynolds_freeman (personal web site) From dzonatas at dzonux.net Sun Dec 30 16:22:32 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Dec 30 16:22:40 2007 Subject: [sldev] Question by newbie to viewer source ... In-Reply-To: <01746F12-9F36-4401-9805-951C12F83B95@mac.com> References: <4776CA43.2040809@lindenlab.com> <01746F12-9F36-4401-9805-951C12F83B95@mac.com> Message-ID: <47783648.90203@dzonux.net> Jay Reynolds Freeman wrote: > I am also wondering if any collision-detection information > is provided by the servers to the viewer (I believe I understand > that all collision-detection is done on the servers, but wonder > if that information is passed down to the viewer.) > Most of the collision information can be passed on through lsl scripts with lsl triggers: http://wiki.secondlife.com/wiki/Collision That is the most accurate you will get that will match the server side state, but it is not the fastest. Faster collision will need to be simulated, but it most likely won't be accurate. That accuracy would mainly be offset by the sim lag and for only being able to have a partial capture of a physics world in the simulation being derived from the real simulation. So... it is not impossible. Practical solutions have yet to be made. LSL scripts is your best bet for now. From warkirby3333 at hotmail.co.uk Sun Dec 30 21:07:22 2007 From: warkirby3333 at hotmail.co.uk (Paul Cook) Date: Sun Dec 30 21:07:23 2007 Subject: [sldev] movement within the client In-Reply-To: <20071230200015.7A40341B36B@stupor.lindenlab.com> References: <20071230200015.7A40341B36B@stupor.lindenlab.com> Message-ID: The Dale Glass client allows teleporting to an av. It can do this over pretty short distances, and sucessfully in rapid sucession. Pretty fun actually. http://sl.daleglass.net/ Might be of use in this matter _________________________________________________________________ Get Hotmail on your mobile, text MSN to 63463! http://mobile.uk.msn.com/pc/mail.aspx From lenglish5 at cox.net Mon Dec 31 01:26:07 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Dec 31 01:26:09 2007 Subject: [sldev] Question by newbie to viewer source ... In-Reply-To: <01746F12-9F36-4401-9805-951C12F83B95@mac.com> References: <4776CA43.2040809@lindenlab.com> <01746F12-9F36-4401-9805-951C12F83B95@mac.com> Message-ID: <4778B5AF.2090605@cox.net> Jay Reynolds Freeman wrote: > I am rather a newbie to this list and to the SL viewer source. > > I have one of those questions which may betray my ignorance > and be easily answered by providing a pointer to documentation > I have missed; please indulge me while I ask it. > > I am attempting to build a modified viewer for use in MacOS. > I can download sources and get them to build and run with no > problem, and I am a moderately experienced Mac developer, Cocoa > user, and XCode user. So far, so good, but ... > > I am particularly interested in access to information provided > by the SL servers, to the viewer, that describes the locations > and perhaps various items of state about objects, about avatars, > and in particular, about the avatar that represents the user. I'm part of AW Groupies, the in-world group centered around the Architectural Working Group. https://wiki.secondlife.com/wiki/Architecture_Working_Group We're currently trying to document the existing protocols in order to better advise Linden Lab about how to move towards LL's stated goal of a multi-grid, multi-vendor system. http://secondlifegrid.net/programs/awg Various other groups, such as libsecondlife and OpenSim are working on documenting and implementing their own versions of the client and server, and you can find documentation relevant to what they are doing on their respective websites (they are years beyond what we are doing): http://opensimulator.org/wiki/Main_Page http://www.libsecondlife.org/wiki/Main_Page The AW Groupies work is currently focused on creating language-neutral documentation of the client-server protohttps://wiki.secondlife.com/wiki/AW_Groupies#Documenting_current_protocolscols and implementing various parts of the client using Python and other languages such as Java in order to ensure our docs make sense. https://wiki.secondlife.com/wiki/AW_Groupies#Documenting_current_protocols AW Groupies has an discussion group that you can join by contacting Saijanai Kuhn, Tree Kyomoon or Zha Ewry (Fearless Leader) in-world. We meet Tuesdays, 9:30 AM SL time, at Zha's island and often come up with new questions to ask Zero Linden at his office hours later in the day. https://wiki.secondlife.com/wiki/AW_Groupies The libsecondlife people maintain a lively discussion IRC chatroom at #libsl-dev irc.efnet.org or irc.choopa.ca The opensim people maintain a lively discussion RIC chatroom at #opensim irc.freenode.net They hold weekly meetinsgs as well: http://opensimulator.org/wiki/Office_hours Many of the technical "Lindens" hold in-world office hours to discuss various aspects of Second Life technology (all employees of Linden Labs take the last name of "Linden" for their avatar"): http://www.google.com/calendar/embed?src=mvktahmo6mjpvpkkkdnmabmghg%40group.calendar.google.com *Zero Linden was formerly involved with"Icehouse," the server/communications aspect of SL. He's now focused primarily on the AWG itself. *Which Linden specializes in communications services. *Andrew Linden specializes in Physics and the like. His office hours are currently about bug squashing during the transition from Havok 1 to Havok 4, but you may be able to get him to discuss other things. *Rob Linden is involved with managing the open source effort at Linden Labs *Bridie Linden is in charge of squashing bugs *Qarl Linden is involved with graphics, especially "sculpties" *Benjamin Linden is involved with User Interface design and countless more. If you have a chance, visit Torley Linden's place during office hours just so you can say you've met Teh Watermalinden... http://wiki.secondlife.com/wiki/Office_Hours Hope this helps... Lawson (Saijanai Kuhn--Contact me in-world for an invite to AW Groupies if you're interested in helping design the future of SL...) From sldev at free.fr Mon Dec 31 10:34:42 2007 From: sldev at free.fr (Henri Beauchamp) Date: Mon Dec 31 10:34:54 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: References: <4776CA43.2040809@lindenlab.com> Message-ID: <20071231193442.55b4d820.sldev@free.fr> On Sun, 30 Dec 2007 10:52:14 +0900, Alissa Sabre wrote: > > This affects both the RC-1.18.6.2 and the WindLight FL-1.18.6.76116. We > > are in the process of rebuilding/repackaging viewers for download with a > > corrected URL. > > That's fine. > > > Developers who build from source should correct the URL (to > > "secondlife.com"). Anyone who is distributing viewers based on this code > > base should update and repackage the viewers so that users are not at risk. > > Why don't you distribute sources for 1.18.6.3 and 1.18.6.76453 then? That's a good question... It looks like LL is still unable to provide the sources at the same time as the binaries... not even a few hours later, obviously. :-( From lenglish5 at cox.net Mon Dec 31 11:21:29 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Dec 31 11:21:31 2007 Subject: [sldev] Viewer Source Release of RC-1.18.6.2 In-Reply-To: <20071231193442.55b4d820.sldev@free.fr> References: <4776CA43.2040809@lindenlab.com> <20071231193442.55b4d820.sldev@free.fr> Message-ID: <47794139.2080904@cox.net> Henri Beauchamp wrote: > On Sun, 30 Dec 2007 10:52:14 +0900, Alissa Sabre wrote: > > >>> This affects both the RC-1.18.6.2 and the WindLight FL-1.18.6.76116. We >>> are in the process of rebuilding/repackaging viewers for download with a >>> corrected URL. >>> >> That's fine. >> >> >>> Developers who build from source should correct the URL (to >>> "secondlife.com"). Anyone who is distributing viewers based on this code >>> base should update and repackage the viewers so that users are not at risk. >>> >> Why don't you distribute sources for 1.18.6.3 and 1.18.6.76453 then? >> > > That's a good question... > > It looks like LL is still unable to provide the sources at the same time as > the binaries... not even a few hours later, obviously. :-( > Well, in all fairness, the week before Christmas to the week or so after Christmas is a very hectic time in the USA. If things fail to function as you want a week after New Year's Day, THEN complain, before then, its futile, except during emergency situations. Too many people are on vacation, visiting families, recovering from parties, etc., to expect things to work well before then. Lawson From seg at haxxed.com Mon Dec 31 12:06:00 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 31 12:05:19 2007 Subject: [sldev] movement within the client In-Reply-To: <4776F5B9.9070604@cox.net> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4776BCB9.7040103@wsu.edu> <4776F5B9.9070604@cox.net> Message-ID: <1199131560.3486.134.camel@localhost> On Sat, 2007-12-29 at 18:34 -0700, Lawson English wrote: > Thanks for the info. Rather than workarounds, I'd rather that we asked > for new features though. This isn't supposed to be a competition to see > who can hack the server the best: its supposed to be a collaborative > effort to see this thing thrive, or such is my attitude. Yes, the way movement is handled now is pretty crackrocky. Under laggy conditions, and especially under low framerates, which basically means always in popular areas, it becomes impossible to move without overshooting all over the place, rudely plowing through people and falling off platforms. There's basically three things I want to see: 1) No overshooting 2) Proportional control (such as with a joystick) 3) A "move to here" option I can't say I know what I'm doing as far as low level protocol design for this, but my guess is this all could be accomplished with a "I want to be at X,Y,Z" client-to-sim message. The sim would still be authoritative about avatar position, it should be viewed as a request, the sim could ignore or modify the actual result as it sees fit, such as collisions, bounding avatar velocity, etc. Which is pretty much what it is doing already. This would prevent overshooting, since the message is an absolute, not relative. This would allow proportional control, the client would just be sending a series of short X,Y,Z updates. SL actually already has a "move here" feature, but it only works on terrain, so unless you're in a sandbox it is pretty much useless. (And of course we can and should always ask the question, "How does Quake 1/2/3, Doom3, HL 1/2, Unreal etc etc game engines handle this?", they've been doing this for years... AFAIK a major difference is they all perform collisions/physics simultaneously on the client and server, and resolve any de-synchronization by holding the server authoritative.) -------------- 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/20071231/dd70a44e/attachment.pgp From secret.argent at gmail.com Mon Dec 31 13:06:04 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Dec 31 13:06:10 2007 Subject: [sldev] movement within the client In-Reply-To: <1199131560.3486.134.camel@localhost> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4776BCB9.7040103@wsu.edu> <4776F5B9.9070604@cox.net> <1199131560.3486.134.camel@localhost> Message-ID: <29835C58-8AEF-4B6A-B844-9BD5DCC5C5AE@gmail.com> On 2007-12-31, at 14:06, Callum Lerwick wrote: > (And of course we can and should always ask the question, "How does > Quake 1/2/3, Doom3, HL 1/2, Unreal etc etc game engines handle this?", > they've been doing this for years... AFAIK a major difference is they > all perform collisions/physics simultaneously on the client and > server, > and resolve any de-synchronization by holding the server > authoritative.) Would that require making Havok part of the client code? From seg at haxxed.com Mon Dec 31 14:54:10 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Dec 31 14:53:25 2007 Subject: [sldev] movement within the client In-Reply-To: <29835C58-8AEF-4B6A-B844-9BD5DCC5C5AE@gmail.com> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4776BCB9.7040103@wsu.edu> <4776F5B9.9070604@cox.net> <1199131560.3486.134.camel@localhost> <29835C58-8AEF-4B6A-B844-9BD5DCC5C5AE@gmail.com> Message-ID: <1199141650.3486.157.camel@localhost> On Mon, 2007-12-31 at 15:06 -0600, Argent Stonecutter wrote: > On 2007-12-31, at 14:06, Callum Lerwick wrote: > > (And of course we can and should always ask the question, "How does > > Quake 1/2/3, Doom3, HL 1/2, Unreal etc etc game engines handle this?", > > they've been doing this for years... AFAIK a major difference is they > > all perform collisions/physics simultaneously on the client and > > server, > > and resolve any de-synchronization by holding the server > > authoritative.) > > Would that require making Havok part of the client code? Good question, actually. I'd like to know how Doom3 (Which is apparently "id Tech 4" now) and Source handle this. Do all clients really perform full physics simulation? Is the physics simulation predictable enough to do this on large numbers of colliding objects? The Source engine is Havok based, actually. However John Carmack has to reinvent the wheel as usual. Still, full client prediction of physics is orthogonal to the functionality I/we want. Better client prediction would be nice. The "fall through the ground then suddenly pop backwards" thing that happens in laggy situations, especially when crossing sims, especially in vehicles, is really annoying and I don't even understands why this happens. Is the client simulating gravity? As well as the "walk forever" thing that happens. The client does not seem to have any code in it that does something like "I have not received any updates from the sim in x seconds/milliseconds, I should stop moving the avatar as it is likely not what is intended by the user". -------------- 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/20071231/e0c97bc0/attachment.pgp From lenglish5 at cox.net Mon Dec 31 19:05:50 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Dec 31 19:05:54 2007 Subject: [sldev] movement within the client In-Reply-To: <1199131560.3486.134.camel@localhost> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4776BCB9.7040103@wsu.edu> <4776F5B9.9070604@cox.net> <1199131560.3486.134.camel@localhost> Message-ID: <4779AE0E.4000308@cox.net> Callum Lerwick wrote: > On Sat, 2007-12-29 at 18:34 -0700, Lawson English wrote: > > >> Thanks for the info. Rather than workarounds, I'd rather that we asked >> for new features though. This isn't supposed to be a competition to see >> who can hack the server the best: its supposed to be a collaborative >> effort to see this thing thrive, or such is my attitude. >> > > Yes, the way movement is handled now is pretty crackrocky. Under laggy > conditions, and especially under low framerates, which basically means > always in popular areas, it becomes impossible to move without > overshooting all over the place, rudely plowing through people and > falling off platforms. > > There's basically three things I want to see: > > 1) No overshooting > 2) Proportional control (such as with a joystick) > 3) A "move to here" option > > I can't say I know what I'm doing as far as low level protocol design > for this, but my guess is this all could be accomplished with a "I want > to be at X,Y,Z" client-to-sim message. The sim would still be > authoritative about avatar position, it should be viewed as a request, > the sim could ignore or modify the actual result as it sees fit, such as > collisions, bounding avatar velocity, etc. Which is pretty much what it > is doing already. > > This would prevent overshooting, since the message is an absolute, not > relative. This would allow proportional control, the client would just > be sending a series of short X,Y,Z updates. > > SL actually already has a "move here" feature, but it only works on > terrain, so unless you're in a sandbox it is pretty much useless. > > (And of course we can and should always ask the question, "How does > Quake 1/2/3, Doom3, HL 1/2, Unreal etc etc game engines handle this?", > they've been doing this for years... AFAIK a major difference is they > all perform collisions/physics simultaneously on the client and server, > and resolve any de-synchronization by holding the server authoritative.) > AN interesting point. The problem is, as long as SL uses Havok, I don't see how you'd handle it client-side unless you could add a client physics engine that worked just like Havok. And the folks that made Havok would proably be a tad less than pleased if SL added a requirement for people to use a 3rd party engine that competed with them. They might suddenly yank LL's Havok license. Or maybe not, though the server code is soooo far from being ready for release (from what I've heard) that worrying about making the client physics more efficient probably isnt' even a blip on the LL horizon. Lawson From lenglish5 at cox.net Mon Dec 31 19:11:07 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Dec 31 19:11:10 2007 Subject: [sldev] movement within the client In-Reply-To: <1199141650.3486.157.camel@localhost> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4776BCB9.7040103@wsu.edu> <4776F5B9.9070604@cox.net> <1199131560.3486.134.camel@localhost> <29835C58-8AEF-4B6A-B844-9BD5DCC5C5AE@gmail.com> <1199141650.3486.157.camel@localhost> Message-ID: <4779AF4B.2020604@cox.net> Callum Lerwick wrote: > On Mon, 2007-12-31 at 15:06 -0600, Argent Stonecutter wrote: > >> On 2007-12-31, at 14:06, Callum Lerwick wrote: >> >>> (And of course we can and should always ask the question, "How does >>> Quake 1/2/3, Doom3, HL 1/2, Unreal etc etc game engines handle this?", >>> they've been doing this for years... AFAIK a major difference is they >>> all perform collisions/physics simultaneously on the client and >>> server, >>> and resolve any de-synchronization by holding the server >>> authoritative.) >>> >> Would that require making Havok part of the client code? >> > > Good question, actually. I'd like to know how Doom3 (Which is apparently > "id Tech 4" now) and Source handle this. Do all clients really perform > full physics simulation? Is the physics simulation predictable enough to > do this on large numbers of colliding objects? The Source engine is > Havok based, actually. However John Carmack has to reinvent the wheel as > usual. > > Still, full client prediction of physics is orthogonal to the > functionality I/we want. Better client prediction would be nice. The > "fall through the ground then suddenly pop backwards" thing that happens > in laggy situations, especially when crossing sims, especially in > vehicles, is really annoying and I don't even understands why this > happens. Is the client simulating gravity? As well as the "walk forever" > thing that happens. The client does not seem to have any code in it that > does something like "I have not received any updates from the sim in x > seconds/milliseconds, I should stop moving the avatar as it is likely > not what is intended by the user". > Actually, I've seen it where the client ends up walking into the AIR as it crosses the sim border rather than sinking: it sinks crossing one way, and rises, crossing the other. To make sim-crossing issues 100% reproduceable (last time I checked), go purchase Qarl LInden's ant for $1L from his maze in Q and wear it as an attachment. The full perms version that you can find floating around doesn't do this --I know, I've checked. Code Tracer and I spent many hours verifying the behavior at various problem sim-borders. Lawson From jhurliman at wsu.edu Mon Dec 31 19:33:19 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Dec 31 19:33:20 2007 Subject: [sldev] movement within the client In-Reply-To: <1199141650.3486.157.camel@localhost> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4776BCB9.7040103@wsu.edu> <4776F5B9.9070604@cox.net> <1199131560.3486.134.camel@localhost> <29835C58-8AEF-4B6A-B844-9BD5DCC5C5AE@gmail.com> <1199141650.3486.157.camel@localhost> Message-ID: <4779B47F.1050600@wsu.edu> Callum Lerwick wrote: > On Mon, 2007-12-31 at 15:06 -0600, Argent Stonecutter wrote: > >> On 2007-12-31, at 14:06, Callum Lerwick wrote: >> >>> (And of course we can and should always ask the question, "How does >>> Quake 1/2/3, Doom3, HL 1/2, Unreal etc etc game engines handle this?", >>> they've been doing this for years... AFAIK a major difference is they >>> all perform collisions/physics simultaneously on the client and >>> server, >>> and resolve any de-synchronization by holding the server >>> authoritative.) >>> >> Would that require making Havok part of the client code? >> > > Good question, actually. I'd like to know how Doom3 (Which is apparently > "id Tech 4" now) and Source handle this. Do all clients really perform > full physics simulation? Is the physics simulation predictable enough to > do this on large numbers of colliding objects? The Source engine is > Havok based, actually. However John Carmack has to reinvent the wheel as > usual. > > Still, full client prediction of physics is orthogonal to the > functionality I/we want. Better client prediction would be nice. The > "fall through the ground then suddenly pop backwards" thing that happens > in laggy situations, especially when crossing sims, especially in > vehicles, is really annoying and I don't even understands why this > happens. Is the client simulating gravity? As well as the "walk forever" > thing that happens. The client does not seem to have any code in it that > does something like "I have not received any updates from the sim in x > seconds/milliseconds, I should stop moving the avatar as it is likely > not what is intended by the user". > Second Life clients use http://en.wikipedia.org/wiki/Dead_reckoning based on position, velocity, acceleration, angular acceleration, and an attempt to synchronize time steps between the client and the sim. If you jump in the air and then start falling down or you stop flying and the sim hiccups in sending you position updates, or you are crossing a border at the time and the handover goes less then seamlessly you will probably start falling through the earth. The client *could* do basic collision detection with the avatar and the terrain heightmap to prevent this effect. John From lenglish5 at cox.net Mon Dec 31 20:26:53 2007 From: lenglish5 at cox.net (Lawson English) Date: Mon Dec 31 20:26:54 2007 Subject: [sldev] movement within the client In-Reply-To: <4779B47F.1050600@wsu.edu> References: <4775BD8C.6030408@ohio.edu> <4775EB0E.1030707@cox.net> <4776BCB9.7040103@wsu.edu> <4776F5B9.9070604@cox.net> <1199131560.3486.134.camel@localhost> <29835C58-8AEF-4B6A-B844-9BD5DCC5C5AE@gmail.com> <1199141650.3486.157.camel@localhost> <4779B47F.1050600@wsu.edu> Message-ID: <4779C10D.7000101@cox.net> John Hurliman wrote: > Callum Lerwick wrote: >> On Mon, 2007-12-31 at 15:06 -0600, Argent Stonecutter wrote: >> >>> On 2007-12-31, at 14:06, Callum Lerwick wrote: >>> >>>> (And of course we can and should always ask the question, "How does >>>> Quake 1/2/3, Doom3, HL 1/2, Unreal etc etc game engines handle this?", >>>> they've been doing this for years... AFAIK a major difference is they >>>> all perform collisions/physics simultaneously on the client and >>>> server, >>>> and resolve any de-synchronization by holding the server >>>> authoritative.) >>>> >>> Would that require making Havok part of the client code? >>> >> >> Good question, actually. I'd like to know how Doom3 (Which is apparently >> "id Tech 4" now) and Source handle this. Do all clients really perform >> full physics simulation? Is the physics simulation predictable enough to >> do this on large numbers of colliding objects? The Source engine is >> Havok based, actually. However John Carmack has to reinvent the wheel as >> usual. >> >> Still, full client prediction of physics is orthogonal to the >> functionality I/we want. Better client prediction would be nice. The >> "fall through the ground then suddenly pop backwards" thing that happens >> in laggy situations, especially when crossing sims, especially in >> vehicles, is really annoying and I don't even understands why this >> happens. Is the client simulating gravity? As well as the "walk forever" >> thing that happens. The client does not seem to have any code in it that >> does something like "I have not received any updates from the sim in x >> seconds/milliseconds, I should stop moving the avatar as it is likely >> not what is intended by the user". >> > > Second Life clients use http://en.wikipedia.org/wiki/Dead_reckoning > based on position, velocity, acceleration, angular acceleration, and > an attempt to synchronize time steps between the client and the sim. > If you jump in the air and then start falling down or you stop flying > and the sim hiccups in sending you position updates, or you are > crossing a border at the time and the handover goes less then > seamlessly you will probably start falling through the earth. The > client *could* do basic collision detection with the avatar and the > terrain heightmap to prevent this effect. > That might help get rid of the worst of the errors, but it won't give SL WOW/EQ fighting capabilties, I think. In the long run, the clients will have to be modded to allow for this functionality on certain grids, even if the "pure" SL grid doesn't do it. IN WW Groupies, we've been talking about allowing for P2P capabilities in some future version of the client. That way, clients on a given sim could pass physics and other data to each other without havig to wait for the all-too-slow SL strategy of physics handling. Same kind of thing could allow for distributed processing in AI sims, or sharing/synchronization of MIDI/audio data in some kind of performance sim, etc. Lawson