From nicholaz at blueflash.cc Fri Jun 1 03:50:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 1 03:50:38 2007 Subject: [sldev] Interesting Crash ... In-Reply-To: <465F53CE.7050900@gwala.net> References: <465F5273.8040707@blueflash.cc> <465F537F.5010605@wsu.edu> <465F53CE.7050900@gwala.net> Message-ID: <465FF9EA.7000705@blueflash.cc> Thanks Adam and John for the comment, I'll see what the user says and if I can get the location of the sim where this was happening. Nick Adam Frisby wrote: > I see ATI in that previous crash log - I believe that was why the > functionality was removed (other than the giant resource waste the > textures are) > > Adam > > John Hurliman wrote: >> Nicholaz Beresford wrote: >> >>> >>> I just got a dump from a user with an interesting constellation: >>> >>> The system throws a std::bad_alloc exception (Windows) and the stack >>> shows >>> an allocation of a 2048x2048x4 image. >>> >>> Does anybody know if 2048x2048x4 is a valid or common size and if an >>> alloc of >>> 16MB is supposed to go through? >> >> >> My understanding was that 2048x2048x[3/4] images existed at one time, >> and although new ones can't be created the old textures were never >> removed from the grid or resized. Not positive on that though. >> >> 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 nicholaz at blueflash.cc Fri Jun 1 05:02:35 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 1 05:02:43 2007 Subject: [sldev] New Feature: Mute Visibility Message-ID: <46600ADB.5010307@blueflash.cc> I just found an interesting idea on a feature request (SVC-246) which could be rather easy to implement and could solve a couple of problems for many people. I made a new feature request for that and will probably try and see if I can implement it: https://jira.secondlife.com/browse/VWR-1017 Does anyone have thoughts about how this could be best done or possible (positive or negative) ramifications in this? Nick From tateru.nino at gmail.com Fri Jun 1 05:07:13 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 1 05:07:26 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: <46600ADB.5010307@blueflash.cc> References: <46600ADB.5010307@blueflash.cc> Message-ID: <46600BF1.50808@gmail.com> Well, I'd rather that neither an avatar nor their attachments becomes invisible. I see problems down that road. I *can* see a problem with colliding with objects that I can't see is about the only serious downside. Nicholaz Beresford wrote: > > I just found an interesting idea on a feature request (SVC-246) which > could be rather easy to implement and could solve a couple of problems > for many people. > > I made a new feature request for that and will probably try and see if > I can implement it: https://jira.secondlife.com/browse/VWR-1017 > > Does anyone have thoughts about how this could be best done or > possible (positive or negative) ramifications in this? > > > Nick > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From nicholaz at blueflash.cc Fri Jun 1 05:14:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 1 05:14:27 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: <46600BF1.50808@gmail.com> References: <46600ADB.5010307@blueflash.cc> <46600BF1.50808@gmail.com> Message-ID: <46600D9A.8060201@blueflash.cc> I guess from the gut I'd also say to not extend that on the avatars. But with objects, I guess a combination of invisible and and phantom would be an interesting thing (dunno if that's possible from the viewer alone). Nick Tateru Nino wrote: > Well, I'd rather that neither an avatar nor their attachments becomes > invisible. I see problems down that road. > > I *can* see a problem with colliding with objects that I can't see is > about the only serious downside. > > Nicholaz Beresford wrote: >> I just found an interesting idea on a feature request (SVC-246) which >> could be rather easy to implement and could solve a couple of problems >> for many people. >> >> I made a new feature request for that and will probably try and see if >> I can implement it: https://jira.secondlife.com/browse/VWR-1017 >> >> Does anyone have thoughts about how this could be best done or >> possible (positive or negative) ramifications in this? >> >> >> Nick >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > From tateru.nino at gmail.com Fri Jun 1 05:20:56 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 1 05:21:03 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: <46600D9A.8060201@blueflash.cc> References: <46600ADB.5010307@blueflash.cc> <46600BF1.50808@gmail.com> <46600D9A.8060201@blueflash.cc> Message-ID: <46600F28.9050504@gmail.com> Physics and collisions all hapen at the server, I believe, so I don't believe the option to affect third-party tangibility is practicable. Nicholaz Beresford wrote: > > I guess from the gut I'd also say to not extend that > on the avatars. But with objects, I guess a combination > of invisible and and phantom would be an interesting > thing (dunno if that's possible from the viewer alone). > > > Nick > > > > Tateru Nino wrote: >> Well, I'd rather that neither an avatar nor their attachments becomes >> invisible. I see problems down that road. >> >> I *can* see a problem with colliding with objects that I can't see is >> about the only serious downside. >> >> Nicholaz Beresford wrote: >>> I just found an interesting idea on a feature request (SVC-246) which >>> could be rather easy to implement and could solve a couple of problems >>> for many people. >>> >>> I made a new feature request for that and will probably try and see if >>> I can implement it: https://jira.secondlife.com/browse/VWR-1017 >>> >>> Does anyone have thoughts about how this could be best done or >>> possible (positive or negative) ramifications in this? >>> >>> >>> Nick >>> >>> _______________________________________________ >>> 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 able.whitman at gmail.com Fri Jun 1 07:00:56 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 1 07:00:58 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: <46600F28.9050504@gmail.com> References: <46600ADB.5010307@blueflash.cc> <46600BF1.50808@gmail.com> <46600D9A.8060201@blueflash.cc> <46600F28.9050504@gmail.com> Message-ID: <7b3a84fb0706010700i5779ff50vdb915ff68a40ebaf@mail.gmail.com> Rather than trying to make "visibly muted" object invisible, perhaps it would be possible to just make them less intrusive? I think it would be possible, in practice, to have the client do the following for such objects: * render them with just the default grey texture * render them at 50% transparency (or perhaps a configurable transparency) * do not apply any client-side llTargetOmega() effects, so they do not spin * don't pass on any "touch" events, for ad prims that hand out landmarks or notecards * don't play any sounds which eminate from the object That way you could still see the objects and avoid them while walking / flying, but at least they wouldn't be as annoying. One possible downside I can see is that the list of "visibly muted" objects could grow to be quite large, and it might become a hinderance to rendering performance to check objects against this list. Of course, one must not optimize prematurely, so perhaps this won't be a problem. :) I don't have a lot of familiarity with the rendering pipeline, but it seems like the client constructs a list of all objects that are within the view distance. Perhaps it would be possible to modify the code that caches texture and rotation information from the server such that it marks an object as "muted" just at the time the object is added to the list, instead of special-casing the rendering of a "muted" object at every frame that is rendered. The more I think about it, the more I like the idea of being able to "visibly mute" objects. --Able On 6/1/07, Tateru Nino wrote: > > Physics and collisions all hapen at the server, I believe, so I don't > believe the option to affect third-party tangibility is practicable. > > Nicholaz Beresford wrote: > > > > I guess from the gut I'd also say to not extend that > > on the avatars. But with objects, I guess a combination > > of invisible and and phantom would be an interesting > > thing (dunno if that's possible from the viewer alone). > > > > > > Nick > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/0fd7a760/attachment.htm From nicholaz at blueflash.cc Fri Jun 1 07:06:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 1 07:06:48 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: <7b3a84fb0706010700i5779ff50vdb915ff68a40ebaf@mail.gmail.com> References: <46600ADB.5010307@blueflash.cc> <46600BF1.50808@gmail.com> <46600D9A.8060201@blueflash.cc> <46600F28.9050504@gmail.com> <7b3a84fb0706010700i5779ff50vdb915ff68a40ebaf@mail.gmail.com> Message-ID: <466027DE.6030301@blueflash.cc> Another idea could be to just light them up fully rendered for a few seconds on a bump. Regarding the performance, we'll have to see if that can be done right with object creation as a flag and then subsequently just check that flag in the rendering process). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Able Whitman wrote: > Rather than trying to make "visibly muted" object invisible, perhaps > it would be possible to just make them less intrusive? I think it > would be possible, in practice, to have the client do the following > for such objects: > > * render them with just the default grey texture > * render them at 50% transparency (or perhaps a configurable transparency) > * do not apply any client-side llTargetOmega() effects, so they do not > spin > * don't pass on any "touch" events, for ad prims that hand out > landmarks or notecards > * don't play any sounds which eminate from the object > > That way you could still see the objects and avoid them while walking > / flying, but at least they wouldn't be as annoying. > > One possible downside I can see is that the list of "visibly muted" > objects could grow to be quite large, and it might become a hinderance > to rendering performance to check objects against this list. Of > course, one must not optimize prematurely, so perhaps this won't be a > problem. :) > > I don't have a lot of familiarity with the rendering pipeline, but it > seems like the client constructs a list of all objects that are within > the view distance. Perhaps it would be possible to modify the code > that caches texture and rotation information from the server such that > it marks an object as "muted" just at the time the object is added to > the list, instead of special-casing the rendering of a "muted" object > at every frame that is rendered. > > The more I think about it, the more I like the idea of being able to > "visibly mute" objects. > > --Able > > > On 6/1/07, *Tateru Nino* > wrote: > > Physics and collisions all hapen at the server, I believe, so I don't > believe the option to affect third-party tangibility is practicable. > > Nicholaz Beresford wrote: > > > > I guess from the gut I'd also say to not extend that > > on the avatars. But with objects, I guess a combination > > of invisible and and phantom would be an interesting > > thing (dunno if that's possible from the viewer alone). > > > > > > Nick > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/de595a24/attachment.htm From able.whitman at gmail.com Fri Jun 1 07:24:40 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 1 07:24:41 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: <466027DE.6030301@blueflash.cc> References: <46600ADB.5010307@blueflash.cc> <46600BF1.50808@gmail.com> <46600D9A.8060201@blueflash.cc> <46600F28.9050504@gmail.com> <7b3a84fb0706010700i5779ff50vdb915ff68a40ebaf@mail.gmail.com> <466027DE.6030301@blueflash.cc> Message-ID: <7b3a84fb0706010724y87b35a3ra5960708bd58f606@mail.gmail.com> The only problem I see with that is that you wouldn't be able to see them coming. My personal feeling is that having random objects appear in front of me after I run into them is almost as bad as seeing spinning ad prims in the first place. Plus, not all such objects are small enough to fit on a 16sqm parcel; some ad prims are actually quite large. --Able On 6/1/07, Nicholaz Beresford wrote: > > > Another idea could be to just light them up fully rendered for a few > seconds on a bump. > > Regarding the performance, we'll have to see if that can be done right > with object > creation as a flag and then subsequently just check that flag in the > rendering process). > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/a270f173/attachment.htm From alvargi at hotmail.com Fri Jun 1 07:37:32 2007 From: alvargi at hotmail.com (Alvargi) Date: Fri Jun 1 07:37:37 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: <7b3a84fb0706010724y87b35a3ra5960708bd58f606@mail.gmail.com> Message-ID: Rob Linden has talked about clients on low-end and mobile client devices, where reducing bandwidth or tuning what information is sent to the client based on device or network capabilities is a key consideration. A 100% client-side mute feature would also concern those aligned with the more commercial aspects of SL. (like the ability to mute commercials on television). I can also see where muting content based on its rating or other privacy flags could be a valuable tool in resolving some of those issues. You can easily make an "invisible" prim today and place it in the middle of the road (so to speak). My point is that this particular feature has much broader implications and really should involve the sim/server side. Best, Alvargi _____ From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Able Whitman Sent: Friday, June 01, 2007 7:25 AM To: Nicholaz Beresford Cc: sldev@lists.secondlife.com Subject: Re: [sldev] New Feature: Mute Visibility The only problem I see with that is that you wouldn't be able to see them coming. My personal feeling is that having random objects appear in front of me after I run into them is almost as bad as seeing spinning ad prims in the first place. Plus, not all such objects are small enough to fit on a 16sqm parcel; some ad prims are actually quite large. --Able On 6/1/07, Nicholaz Beresford wrote: Another idea could be to just light them up fully rendered for a few seconds on a bump. Regarding the performance, we'll have to see if that can be done right with object creation as a flag and then subsequently just check that flag in the rendering process). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/89f1bdac/attachment-0001.htm From able.whitman at gmail.com Fri Jun 1 11:28:19 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 1 11:28:22 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: References: <7b3a84fb0706010724y87b35a3ra5960708bd58f606@mail.gmail.com> Message-ID: <7b3a84fb0706011128p5eb55778v41b82d32f285d5eb@mail.gmail.com> I've given this feature some thought, and I think that without additional support for muting objects on the server side, this feature could wind up making things worse instead of better. The goal of "visibility muting" is to allow users to select objects in-world that they don't wish to see, or at least that they wish to see in a less instrusive or annoying manner. This muting will overwhelmingly be applied to ad prims. The goal of ad prims (or rather, the goal of their owners) is for the ad prims to be seen, since this is what makes them useful and valuable (from the perspective of the advertiser). If you mute an ad, the owner will obviously want to modify their ad prims so that they circumvent the muting mechanism. Without additional support from the server, this is an arms race that the client cannot win. There are several properties that would be useful as filters for which objects to mute: * object id or object name * owner id or owner name * creator id or creator name * texture id Creator id or name is out, because (as far as I have been able to find) the only way the client can get the creator id of an object is to make that object the currently selected object. Getting the creator name then requires the name cache to make an asynchronous request from the server. This makes creator information too cumbersome to use as a mute filter. Object name and object id are the most promising properties to use. Unfortunately, both of these properties are easily mutable. The object name can easily be scripted to change randomly with llSetObjectName(). The object id will change every time the object is rezzed. If the client implements object-id-based filtering, I think in a very short order ad prims will be supplanted by ad prim rezzers, which could periodically re-rez the ad prims, effectively randomizing their ids. Muting the ad rezzer wouldn't help, because the client can't prevent it from rezzing objects, and (again, as far as I know) the client has no way of knowing that a given object was rezzed by another given object. Filtering muted objects based on owner name or id could work, but this paints with a pretty wide brush, and I think it's probably too much of an all-or-nothing approach to be really useful. And with the ready availability of SL bots, it wouldn't be long before advertisers were regularly creating new bots to be able to vary the owner of their ad prims. (Having a bot place ad prims isn't appreciably different in complexity than having a bot sit in a camping chair, in any event.) Perhaps filtering by texture id is the most promising approach, but with so many ad prims driven by a client-server advertising network, it wouldn't be much additional work on the part of the advertiser to regularly upload multiple copies of the same texture, each with a new texture id. Further complicating things is the fact that being seen isn't the only way an ad prim can convey its content. It can play audio, speak in public chat, give notecards or textures, or raise a script dialog on someone's client. Texture filtering doesn't address any of those techniques. Certainly, implementing an object muting feature would be useful, at least for static prims. It would initially be useful for ad prims as well, but the availability of client-side visibility muting would motivate ad prim owners to modify their techniques in such a way that the muting feature would be rendered ineffective. Worse still, the circumvention techniques that are available to ad prim owners are those which the client cannot practically overcome, without additional server support. (And I am not even certain what kind of server-side mechanisms would be helpful in dealing with randomly changing object and owner ids.) --Able On 6/1/07, Alvargi wrote: > > Rob Linden has talked about clients on low-end and mobile client devices, > where reducing bandwidth or tuning what information is sent to the client > based on device or network capabilities is a key consideration. A 100% > client-side mute feature would also concern those aligned with the more > commercial aspects of SL. (like the ability to mute commercials on > television). I can also see where muting content based on its rating or > other privacy flags could be a valuable tool in resolving some of those > issues. You can easily make an "invisible" prim today and place it in the > middle of the road (so to speak). > > > > My point is that this particular feature has much broader implications and > really should involve the sim/server side. > > > > Best, > > Alvargi > > > > > ------------------------------ > > *From:* sldev-bounces@lists.secondlife.com [mailto: > sldev-bounces@lists.secondlife.com] *On Behalf Of *Able Whitman > *Sent:* Friday, June 01, 2007 7:25 AM > *To:* Nicholaz Beresford > *Cc:* sldev@lists.secondlife.com > *Subject:* Re: [sldev] New Feature: Mute Visibility > > > > The only problem I see with that is that you wouldn't be able to see them > coming. My personal feeling is that having random objects appear in front of > me after I run into them is almost as bad as seeing spinning ad prims in the > first place. Plus, not all such objects are small enough to fit on a 16sqm > parcel; some ad prims are actually quite large. > > --Able > > On 6/1/07, *Nicholaz Beresford* wrote: > > > Another idea could be to just light them up fully rendered for a few > seconds on a bump. > > Regarding the performance, we'll have to see if that can be done right > with object > creation as a flag and then subsequently just check that flag in the > rendering process). > > > Nick > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/ded7c5f8/attachment.htm From max.case at gmail.com Fri Jun 1 11:29:59 2007 From: max.case at gmail.com (max case) Date: Fri Jun 1 11:30:02 2007 Subject: [sldev] Re: Patch to make View Admin Options sticky. In-Reply-To: <465F2B1A.3090203@gmail.com> References: <20070529115141.2AAC841AF01@stupor.lindenlab.com> <8710222F-6EC7-42F8-AB7D-982498D5B262@gmail.com> <465E21DE.6030505@gmail.com> <465F1721.90402@lindenlab.com> <465F2B1A.3090203@gmail.com> Message-ID: > > As someone who doesn't spend a lot of time not in God mode, I have to > > ask: what is useful about View Admin Options for you? It would be nice A trick someone taught me recently that causes me ot use god mode is that you can offer teleports to friends, when just pullin up their profile doesn't always offer it. m. From robla at lindenlab.com Fri Jun 1 14:40:15 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jun 1 14:40:30 2007 Subject: [sldev] Volunteers to sort out agenda for bug triage? Message-ID: <4660923F.1030404@lindenlab.com> Hi folks, Next bug triage is Monday, 3pm PDT. See here for details: https://wiki.secondlife.com/wiki/Bug_triage Could someone volunteer to make up an agenda? I think next week's theme should be around reviewing any unreviewed/unimported patches, but I'm open to discuss any filed issue that's of particular importance. 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/20070601/2e373519/signature.pgp From secret.argent at gmail.com Fri Jun 1 15:48:55 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 1 15:48:58 2007 Subject: [sldev] Re: New Feature: Mute Visibility In-Reply-To: <20070601143737.CDAED41B937@stupor.lindenlab.com> References: <20070601143737.CDAED41B937@stupor.lindenlab.com> Message-ID: <23E77551-3256-4780-9EA7-8274F01E9DE1@gmail.com> I would suggest a combination. If the object can potentially be collided with, render it with the "loading" texture. Otherwise, don't render it at all. So, muted objects would only be rendered even in "reduced" mode if they are not attached to an avatar, not flexible, not phantom (if the viewer can tell), and in a certain distance of the avatar. From secret.argent at gmail.com Fri Jun 1 15:59:44 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 1 15:59:48 2007 Subject: [sldev] Re: SLDev Digest, Vol 6, Issue 3 In-Reply-To: <20070601190009.74C8C41B608@stupor.lindenlab.com> References: <20070601190009.74C8C41B608@stupor.lindenlab.com> Message-ID: <4245E3DA-9812-4F34-B8BB-DFDEB5AE2A86@gmail.com> On Jun 1, 2007, at 2:00 PM, sldev-request@lists.secondlife.com wrote: > The goal of ad prims (or rather, the goal of their owners) is for > the ad prims to be seen, since this is what makes them useful and > valuable > (from the perspective of the advertiser). If you mute an ad, the > owner will > obviously want to modify their ad prims so that they circumvent the > muting > mechanism. How do they know their prims are muted? They don't. And unless you mute them globally (which the viewer can't do) why do they care? Muting would even help... it would reduce complaints from nearby landowners and renters (who are almost certainly NOT not potential customers) while visitors (who are) would still see them. > There are several properties that would be useful as filters for which > objects to mute: > * object id or object name > * owner id or owner name > * creator id or creator name > * texture id * Location. * Parcel. Object ID or name would be great for hiding griefers who show up with huge prim wangs and the like. Hiding all prims in a parcel would be great for ad farms, especially if you can specify "keep this area muted even if the owner changes". From able.whitman at gmail.com Fri Jun 1 16:17:12 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 1 16:17:14 2007 Subject: [sldev] Re: SLDev Digest, Vol 6, Issue 3 In-Reply-To: <4245E3DA-9812-4F34-B8BB-DFDEB5AE2A86@gmail.com> References: <20070601190009.74C8C41B608@stupor.lindenlab.com> <4245E3DA-9812-4F34-B8BB-DFDEB5AE2A86@gmail.com> Message-ID: <7b3a84fb0706011617t1fc733d9q8d702ae20eea40de@mail.gmail.com> On 6/1/07, Argent Stonecutter wrote: > > On Jun 1, 2007, at 2:00 PM, sldev-request@lists.secondlife.com wrote: > > The goal of ad prims (or rather, the goal of their owners) is for > > the ad prims to be seen, since this is what makes them useful and > > valuable > > (from the perspective of the advertiser). If you mute an ad, the > > owner will > > obviously want to modify their ad prims so that they circumvent the > > muting > > mechanism. > > How do they know their prims are muted? > > They don't. Well, if I was an advertiser, and I see a new SL client come out with "visual object muting", you can bet I'd be figuring out how to get around it and updating my ad prims to do so. It's a pretty safe bet that any feature that can be used to block ads will have the advertisers looking for ways around it. This is similar to the back-and-forth between people making browser ad blockers and online advertisers looking for ways to get around them, etc. And unless you mute them globally (which the viewer can't do) why do > they care? Muting would even help... it would reduce complaints from > nearby landowners and renters (who are almost certainly NOT not > potential customers) while visitors (who are) would still see them. Like I said, my point wasn't to condemn the feature idea; if my post came across as harshly critical, I apologize. I do think the feature is a good idea, and I'd be more than happy to help implement and/or test it. All I'm saying is that, if you look a couple of moves into the future, the advertisers can make use of techniques to circumvent the muting that leave the client ill-equipped to circumvent their circumventions. > There are several properties that would be useful as filters for which > > objects to mute: > > * object id or object name > > * owner id or owner name > > * creator id or creator name > > * texture id > > * Location. > * Parcel. > > Object ID or name would be great for hiding griefers who show up with > huge prim wangs and the like. > > Hiding all prims in a parcel would be great for ad farms, especially > if you can specify "keep this area muted even if the owner changes". Yes, I too had thought of the idea of "muting by parcel", after I wrote my last post. And I agree with you-- muting objects by parcel (or even "mute all objects within X meters of here") is probably the most effective way to deal with ad farms, and it has the great advantage of being resistant to many of the circumvention techniques that filtering by object name or id, etc. are vulnerable to. --Able _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/b22a6c7c/attachment.htm From able.whitman at gmail.com Fri Jun 1 16:18:42 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 1 16:18:44 2007 Subject: [sldev] Re: New Feature: Mute Visibility In-Reply-To: <23E77551-3256-4780-9EA7-8274F01E9DE1@gmail.com> References: <20070601143737.CDAED41B937@stupor.lindenlab.com> <23E77551-3256-4780-9EA7-8274F01E9DE1@gmail.com> Message-ID: <7b3a84fb0706011618h2bd4094dj6e3ea2ed54abc650@mail.gmail.com> I like this idea very much. The viewer can definitely tell whether and object is flexi / phantom or not. On 6/1/07, Argent Stonecutter wrote: > > I would suggest a combination. > > If the object can potentially be collided with, render it with the > "loading" texture. > > Otherwise, don't render it at all. > > So, muted objects would only be rendered even in "reduced" mode if > they are not attached to an avatar, not flexible, not phantom (if the > viewer can tell), and in a certain distance of the avatar. > > _______________________________________________ > 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/20070601/d3f6e80a/attachment.htm From nicholaz at blueflash.cc Fri Jun 1 17:00:26 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 1 17:00:49 2007 Subject: [sldev] Volunteers to sort out agenda for bug triage? In-Reply-To: <4660923F.1030404@lindenlab.com> References: <4660923F.1030404@lindenlab.com> Message-ID: <4660B31A.4010103@blueflash.cc> I Wiki'd the whole list and tried to sort the patches in groups and made a few comments to some about how obvious or easy to import they are. Maybe others here could look over bugs there and make similar comments (how obvious, important, correct, etc.) you think they are. https://wiki.secondlife.com/wiki/Bug_triage/2007-06-04 Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Rob Lanphier wrote: > Hi folks, > > Next bug triage is Monday, 3pm PDT. See here for details: > > https://wiki.secondlife.com/wiki/Bug_triage > > Could someone volunteer to make up an agenda? I think next week's theme > should be around reviewing any unreviewed/unimported patches, but I'm > open to discuss any filed issue that's of particular importance. > > Rob From nicholaz at blueflash.cc Fri Jun 1 17:13:48 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 1 17:14:10 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: <7b3a84fb0706011128p5eb55778v41b82d32f285d5eb@mail.gmail.com> References: <7b3a84fb0706010724y87b35a3ra5960708bd58f606@mail.gmail.com> <7b3a84fb0706011128p5eb55778v41b82d32f285d5eb@mail.gmail.com> Message-ID: <4660B63C.1000002@blueflash.cc> I've given this some thought today (and no, I don't think that was overly critical or anything) and think many concerns are valid. I was thinking about what those people might do to circumvent this also, I just wasn't creative enough. One thing I think isn't of major concern is the collision, but maybe cause I'm mostly thinking in terms of those overpriced 16sqm parcels. If someone mutes such a thing in their neighborhood, I guess they know where they are. But if collision is a concern, I think applying 90% transparency might be effective. But I think with the 16sqm parcels in mind, Argent's idea of muting the parcel would be most elegant. Dunno if the viewer can do that on it's own, but it would be a very nice approach. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Able Whitman wrote: > I've given this feature some thought, and I think that without > additional support for muting objects on the server side, this feature > could wind up making things worse instead of better. > > The goal of "visibility muting" is to allow users to select objects > in-world that they don't wish to see, or at least that they wish to see > .... From able.whitman at gmail.com Fri Jun 1 18:16:23 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 1 18:16:26 2007 Subject: [sldev] New Feature: Mute Visibility In-Reply-To: <4660B63C.1000002@blueflash.cc> References: <7b3a84fb0706010724y87b35a3ra5960708bd58f606@mail.gmail.com> <7b3a84fb0706011128p5eb55778v41b82d32f285d5eb@mail.gmail.com> <4660B63C.1000002@blueflash.cc> Message-ID: <7b3a84fb0706011816g5ec229dew9e38be1854548ac7@mail.gmail.com> I think in principle the viewer has, or can get, all of the information necessary to make a determination as to whether "location X is in parcel Y". I'm still digging through the code to see how such an algorithm might work (or indeed, if one is already implemented). The larger question is how to properly integrate the muting mechanism into the render loop; this is something I don't begin to have the expertise to be able to answer. :) On 6/1/07, Nicholaz Beresford wrote: > > > I've given this some thought today (and no, I don't think > that was overly critical or anything) and think many concerns > are valid. I was thinking about what those people might do > to circumvent this also, I just wasn't creative enough. > > One thing I think isn't of major concern is the collision, but > maybe cause I'm mostly thinking in terms of those overpriced > 16sqm parcels. If someone mutes such a thing in their > neighborhood, I guess they know where they are. > > But if collision is a concern, I think applying 90% transparency > might be effective. > > But I think with the 16sqm parcels in mind, Argent's idea > of muting the parcel would be most elegant. Dunno if the > viewer can do that on it's own, but it would be a very nice > approach. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Able Whitman wrote: > > I've given this feature some thought, and I think that without > > additional support for muting objects on the server side, this feature > > could wind up making things worse instead of better. > > > > The goal of "visibility muting" is to allow users to select objects > > in-world that they don't wish to see, or at least that they wish to see > > .... > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/abdfe9c9/attachment.htm From able.whitman at gmail.com Fri Jun 1 19:09:53 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 1 19:09:54 2007 Subject: [sldev] Volunteers to sort out agenda for bug triage? In-Reply-To: <4660B31A.4010103@blueflash.cc> References: <4660923F.1030404@lindenlab.com> <4660B31A.4010103@blueflash.cc> Message-ID: <7b3a84fb0706011909j35ae4cdeid9ec377ba3499a87@mail.gmail.com> I found a couple of bugs in the list that I think, based on the release notes, were fixed in 1.15.0.2. I also noted which bugs have, as of this evening, 3 or more votes. --Able On 6/1/07, Nicholaz Beresford wrote: > > > I Wiki'd the whole list and tried to sort the > patches in groups and made a few comments to some > about how obvious or easy to import they are. > > Maybe others here could look over bugs there and > make similar comments (how obvious, important, correct, > etc.) you think they are. > > https://wiki.secondlife.com/wiki/Bug_triage/2007-06-04 > > > Nick > > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Rob Lanphier wrote: > > Hi folks, > > > > Next bug triage is Monday, 3pm PDT. See here for details: > > > > https://wiki.secondlife.com/wiki/Bug_triage > > > > Could someone volunteer to make up an agenda? I think next week's theme > > should be around reviewing any unreviewed/unimported patches, but I'm > > open to discuss any filed issue that's of particular importance. > > > > Rob > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070601/199b92ed/attachment.htm From dzonatas at dzonux.net Fri Jun 1 19:25:05 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jun 1 19:23:40 2007 Subject: [sldev] Volunteers to sort out agenda for bug triage? In-Reply-To: <4660B31A.4010103@blueflash.cc> References: <4660923F.1030404@lindenlab.com> <4660B31A.4010103@blueflash.cc> Message-ID: <4660D501.7050006@dzonux.net> This has been moved here: https://wiki.secondlife.com/wiki/Bug_triage/Agenda That we way don't have to update our watchlist each new agenda. Nicholaz Beresford wrote: > > I Wiki'd the whole list and tried to sort the > patches in groups and made a few comments to some > about how obvious or easy to import they are. > > Maybe others here could look over bugs there and > make similar comments (how obvious, important, correct, > etc.) you think they are. > > https://wiki.secondlife.com/wiki/Bug_triage/2007-06-04 > > > Nick > > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Rob Lanphier wrote: >> Hi folks, >> >> Next bug triage is Monday, 3pm PDT. See here for details: >> >> https://wiki.secondlife.com/wiki/Bug_triage >> >> Could someone volunteer to make up an agenda? I think next week's theme >> should be around reviewing any unreviewed/unimported patches, but I'm >> open to discuss any filed issue that's of particular importance. >> >> Rob > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- From Paul.Hampson at Pobox.com Sat Jun 2 03:12:37 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Sat Jun 2 03:12:45 2007 Subject: [sldev] QueryPerformanceCounter() In-Reply-To: <000b01c7a3eb$3fb2e840$b20b1352@tomhome> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> Message-ID: <20070602101237.GA22431@keitarou> On Fri, Jun 01, 2007 at 02:21:54AM +0100, Thomas Rowland wrote: > Available to all via google 'rdtc' is; > http://www-unix.mcs.anl.gov/~kazutomo/rdtsc.html > Which also gives a PPC equiv. function, and is as good as any. There's no copyright statement or similar on that page, and I'm pretty sure that's been copied from somewhere itself. I can't remember where, but I've seen the 'byte blah on x86, rdtsc on amd64' thing. I thought it was the mplayer sources, but it's not. I'm not sure what functionality these provide over my patch, except that mine is certified by me to be either my own work, or a contribution from someone who has absolved their copyright claim if one exists. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070602/0078bf29/attachment.pgp From Paul.Hampson at Pobox.com Sat Jun 2 03:15:42 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Sat Jun 2 03:15:44 2007 Subject: [sldev] Debian Etch i386 build of my packages Message-ID: <20070602101542.GA23321@keitarou> A very helpful user has contributed a build of my Debian packages of 1.16.0.5, at [1]. They're built for Debian/Etch (but should work on Sid, although you'll have to dig up the libcurl-openssl3 package yourself from http://snapshot.debian.net) on i386. So now I've got successful build-tests on all three supported platforms, thankyou all very much. [1] http://alzental-castle.de/~rd/SL/ -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070602/9b7c7a4e/attachment.pgp From nicholaz at blueflash.cc Sat Jun 2 03:17:39 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 2 03:18:06 2007 Subject: [sldev] Volunteers to sort out agenda for bug triage? In-Reply-To: <4660D501.7050006@dzonux.net> References: <4660923F.1030404@lindenlab.com> <4660B31A.4010103@blueflash.cc> <4660D501.7050006@dzonux.net> Message-ID: <466143C3.3030900@blueflash.cc> Dzonatas wrote: > This has been moved here: > > https://wiki.secondlife.com/wiki/Bug_triage/Agenda > > That we way don't have to update our watchlist each new agenda. Ahh, makes sense! :-) Nick From grazel.cosmo at gmail.com Sat Jun 2 03:24:21 2007 From: grazel.cosmo at gmail.com (Kele Kravelin) Date: Sat Jun 2 03:24:24 2007 Subject: [sldev] Patch to Address Debit Permission Spoofing In-Reply-To: <465D9574.5080705@gmail.com> References: <465C00CA.2090408@blueflash.cc> <11kJ4G5cc5s6sJ8s08rz8shx1.alissa_sabre@yahoo.co.jp> <465D65E7.9020903@gmail.com> <2925011a0705300748t7408649do655c20a54ddfc5b5@mail.gmail.com> <7b3a84fb0705300805u16a6c7ecjfefc315241753a70@mail.gmail.com> <465D9574.5080705@gmail.com> Message-ID: <3c1fe370706020324s627bcbe0ne24bf88fb8c5dd38@mail.gmail.com> Hmmm has anyone told the victim here about hte newish 'inspect' pie menu option. As I recall it shows the owner and creator of all prims and inventory of an object, that should give the name of the creator of the malicious script and help track it down. Of course that means one of the victims would have to believe Dave and work with him to track the true thief down. Also they can look at their transaction history since their lost L$ will be going to someone (and if Dave is innocent it won't be Dave's name). While there are remedies (which many will just ignore and just go after the fast 'solution') it does highlight a need for changes in the debit permission system. On 5/30/07, Tateru Nino wrote: > > > > Able Whitman wrote: > > Of course, as others have pointed out, malicious scripts are rare. But > > the need to grant an object the debit permission is also rare, or at > > least it is uncommon. And once granted it is difficult to both revoke > > the permission and to seek remedy for fraudulent debits. > Not so rare, perhaps: > http://www.gridgrind.com/?p=93 > > -- > 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/20070602/0ec10138/attachment-0001.htm From dzonatas at dzonux.net Sat Jun 2 04:44:34 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jun 2 04:43:08 2007 Subject: [sldev] QueryPerformanceCounter() & related issues VWR-940, VWR-962, VWR975 In-Reply-To: <20070602101237.GA22431@keitarou> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> <20070602101237.GA22431@keitarou> Message-ID: <46615822.9040300@dzonux.net> Paul TBBle Hampson wrote: > There's no copyright statement or similar on that page, and I'm > pretty sure that's been copied from somewhere itself. > > It has a governmental address, which it is common to assume public domain. They are pretty simple. I have updated that related issues. I started to sort out the related contributions. Attached is a patch for review... more works need to be done on it. Main change I did was move rdtsc and likewise code into the header file, llfasttimers.h, so that code can now assemble in-line. Eh... saves a little overhead. -- -------------- next part -------------- Index: indra/llcommon/llfasttimer.h =================================================================== --- indra/llcommon/llfasttimer.h (revision 62604) +++ indra/llcommon/llfasttimer.h (working copy) @@ -13,8 +13,70 @@ #define FAST_TIMER_ON 1 -U64 get_cpu_clock_count(); +//---------------------------------------------------- +//---------------------------------------------------- +// get_cpu_clock_count() - platform dependant +//---------------------------------------------------- +//---------------------------------------------------- +#if LL_MSVC + +inline U64 get_cpu_clock_count() +{ + U64 ret; + __asm + { + _emit 0x0f + _emit 0x31 + mov dword ptr [ret+4], edx + mov dword ptr [ret], eax + } + return ret; +}; + + +#elif LL_GNUC && defined(__i386__) +inline U64 get_cpu_clock_count() +{ + U64 ret; + asm (".byte 0x0f, 0x31" : "=A" (ret)); + return ret; +} + + +#elif LL_GNUC && defined(__amd64__) || defined(__x86_64__) +inline U64 get_cpu_clock_count() +{ + U64 lo, hi; + asm ("rdtsc" : "=a" (x), "=d" (y)); + return (hi << 32) | lo; +} + + +#elif LL_GNUC && defined(__powerpc__) +inline U64 get_cpu_clock_count() +{ + U32 lo, hi, tmp; + asm ("0: mftbu %0; mftb %1; mftbu %2; cmplw %0,%2; bne 0b" : "=r"(hi), "=r"(lo), "=r"(tmp) ); + return ((U64)hi << 32) | lo; +} + + +#else +inline U64 get_cpu_clock_count() +{ + return get_clock_count(); +} + + +#endif + +//---------------------------------------------------- +//---------------------------------------------------- +// LLFastTimer +//---------------------------------------------------- +//---------------------------------------------------- + class LLFastTimer { public: Index: indra/llcommon/llsys.cpp =================================================================== --- indra/llcommon/llsys.cpp (revision 62604) +++ indra/llcommon/llsys.cpp (working copy) @@ -288,14 +288,42 @@ mHasSSE2 = (info->_Ext.SSE2_StreamingSIMD2_Extensions != 0); mCPUMhz = (S32)(proc.GetCPUFrequency(50)/1000000.0); mFamily.assign( info->strFamily ); +#ifdef LL_LINUX + // *NOTE: This works on linux. What will it do on other systems? + FILE* cpuinfo = LLFile::fopen(CPUINFO_FILE, "r"); /* Flawfinder: ignore */ + if(cpuinfo) + { + char line[MAX_STRING]; /* Flawfinder: ignore */ + memset(line, 0, MAX_STRING); + while(fgets(line, MAX_STRING, cpuinfo)) + { + // /proc/cpuinfo on Linux looks like: + // name\t*: value\n + char* tabspot = strchr( line, '\t' ); + if (tabspot == NULL) + continue; + char* colspot = strchr( tabspot, ':' ); + if (colspot == NULL) + continue; + char* nlspot = strchr( line, '\n' ); + if (nlspot == NULL) + nlspot = line + strlen( line ); // Fallback to terminating NULL + + std::string linename( line, tabspot ); + std::string lineval( colspot + 2, nlspot ); + mCPUInfoLines[ linename ] = lineval; + } + fclose(cpuinfo); + } +#endif } std::string LLCPUInfo::getCPUString() const { -#if LL_WINDOWS || LL_DARWIN std::ostringstream out; +#if LL_WINDOWS || LL_DARWIN CProcessor proc; (void) proc.GetCPUInfo(); out << proc.strCPUName << " "; @@ -308,12 +336,32 @@ out << "(" << (S32)(freq) << " MHz)"; } - return out.str(); +#else // LL_LINUX +#if ( defined(__i386__) || defined(__amd64__) || defined(__x86_64__) ) + out << getInfoLine( "model name" ); +#elif defined(__powerpc__) + out << getInfoLine( "platform" ) << " (" << getInfoLine( "clock" ) << ")"; #else - return "Can't get terse CPU information"; + out << "Can't get terse CPU information"; #endif +#endif + return out.str(); } +const std::string& LLCPUInfo::getInfoLine( const std::string index ) const +{ + std::map< std::string, std::string >::const_iterator data = mCPUInfoLines.find( index ); + if (data != mCPUInfoLines.end()) + { + return (*data).second; + } + else + { + static const std::string empty; + return empty; + } +} + void LLCPUInfo::stream(std::ostream& s) const { #if LL_WINDOWS || LL_DARWIN @@ -329,22 +377,16 @@ s << "Unable to collect processor info"; } #else - // *NOTE: This works on linux. What will it do on other systems? - FILE* cpuinfo = LLFile::fopen(CPUINFO_FILE, "r"); /* Flawfinder: ignore */ - if(cpuinfo) + // Return the machine information we gathered in the constructor + if(!mCPUInfoLines.empty()) { - char line[MAX_STRING]; /* Flawfinder: ignore */ - memset(line, 0, MAX_STRING); - while(fgets(line, MAX_STRING, cpuinfo)) - { - line[strlen(line)-1] = ' '; /*Flawfinder: ignore*/ - s << line; - } - fclose(cpuinfo); + for( std::map< std::string, std::string >::const_iterator i = mCPUInfoLines.begin(); + i != mCPUInfoLines.end(); ++i ) + s << (*i).first << "\t: " << (*i).second << ' '; } else { - s << "Unable to collect memory information"; + s << "Unable to collect processor information"; } #endif } Index: indra/llcommon/llsys.h =================================================================== --- indra/llcommon/llsys.h (revision 62604) +++ indra/llcommon/llsys.h (working copy) @@ -20,6 +20,7 @@ #include #include +#include class LLOSInfo { @@ -59,11 +60,18 @@ // Family is "AMD Duron" or "Intel Pentium Pro" const std::string& getFamily() const { return mFamily; } +#ifdef LL_LINUX + const std::string& getInfoLine( const std::string index ) const; +#endif + private: BOOL mHasSSE; BOOL mHasSSE2; S32 mCPUMhz; std::string mFamily; +#ifdef LL_LINUX + std::map< std::string, std::string > mCPUInfoLines; +#endif }; class LLMemoryInfo Index: indra/llcommon/llprocessor.cpp =================================================================== --- indra/llcommon/llprocessor.cpp (revision 62686) +++ indra/llcommon/llprocessor.cpp (working copy) @@ -38,6 +38,10 @@ # include #endif +#if LL_LINUX +# include +#endif + #if !LL_DARWIN #ifdef PROCESSOR_FREQUENCY_MEASURE_AVAILABLE @@ -156,9 +160,11 @@ //////////////////////////////////////////////////////////////////////////// F64 CProcessor::GetCPUFrequency(unsigned int uiMeasureMSecs) { -#ifndef PROCESSOR_FREQUENCY_MEASURE_AVAILABLE - return 0; -#else +#if LL_LINUX + extern LLCPUInfo gSysCPU; + return boost::lexical_cast(gSysCPU.getInfoLine( "cpu MHz" )) * 1000000; + +#elif LL_WINDOWS // PROCESSOR_FREQUENCY_MEASURE_AVAILABLE // If there are invalid measure time parameters, zero msecs for example, // we've to exit the function if (uiMeasureMSecs < 1) @@ -225,16 +231,7 @@ QueryPerformanceCounter((LARGE_INTEGER *) &starttime); // Then we get the current cpu clock and store it -#if LL_GNUC - __asm__("rdtsc" : "=A" (start) ) ; -#else - __asm - { - rdtsc - mov dword ptr [start+4], edx - mov dword ptr [start], eax - } -#endif + start = get_cpu_clock_count(); // Now we wait for some msecs _Delay(uiMeasureMSecs); @@ -244,16 +241,7 @@ QueryPerformanceCounter((LARGE_INTEGER *) &endtime); // And also for the end cpu clock -#if LL_GNUC - __asm__("rdtsc" : "=A" (end) ) ; -#else - __asm - { - rdtsc - mov dword ptr [end+4], edx - mov dword ptr [end], eax - } -#endif + end = get_cpu_clock_count(); // Now we can restore the default process and thread priorities SetProcessAffinityMask(hProcess, dwProcessMask); @@ -271,6 +259,8 @@ // At last we just return the frequency that is also stored in the call // member var uqwFrequency return uqwFrequency; +#else + return 0; #endif } Index: indra/llcommon/llfasttimer.cpp =================================================================== --- indra/llcommon/llfasttimer.cpp (revision 62604) +++ indra/llcommon/llfasttimer.cpp (working copy) @@ -17,6 +17,7 @@ #include #include #include +#include #elif LL_DARWIN # include @@ -43,64 +44,17 @@ F64 LLFastTimer::sCPUClockFrequency = 0.0; -////////////////////////////////////////////////////////////////////////////// -// -// CPU clock/other clock frequency and count functions -// - -#if LL_WINDOWS - -U64 get_cpu_clock_count() -{ U32 hi,lo; - - __asm - { - _emit 0x0f - _emit 0x31 - mov lo,eax - mov hi,edx - } - - U64 ret = hi; - ret *= 4294967296L; - ret |= lo; - return ret; -}; - -#endif // LL_WINDOWS - - -#if LL_LINUX -U64 get_cpu_clock_count() -{ - U64 x; - __asm__ volatile (".byte 0x0f, 0x31" : "=A" (x)); - return x; -} -#endif - -#if LL_DARWIN -// -// Mac implementation of CPU clock -// -// Just use gettimeofday implementation for now - -U64 get_cpu_clock_count() -{ - return get_clock_count(); -} -#endif - ////////////////////////////////////////////////////////////////////////////// -//static -#if LL_LINUX || LL_DARWIN -// Both Linux and Mac use gettimeofday for accurate time + +#if LL_LINUX && defined(__powerpc__) U64 LLFastTimer::countsPerSecond() { - return 1000000; // microseconds, so 1 Mhz. + extern LLCPUInfo gSysCPU; + return boost::lexical_cast(gSysCPU.getInfoLine( "timebase" )); } + #else U64 LLFastTimer::countsPerSecond() { @@ -108,6 +62,8 @@ { CProcessor proc; sCPUClockFrequency = proc.GetCPUFrequency(50); + if(!sCPUClockFrequency) + sCPUClockFrequency = 1000000.0; } return U64(sCPUClockFrequency); } From tom at cornish-pasty.com Sat Jun 2 04:47:33 2007 From: tom at cornish-pasty.com (Thomas Rowland) Date: Sat Jun 2 04:47:35 2007 Subject: [sldev] QueryPerformanceCounter() In-Reply-To: <20070602101237.GA22431@keitarou> Message-ID: <003101c7a50b$cf0a98f0$b8071352@tomhome> I somehow expected someone to bring that up. > > > On Fri, Jun 01, 2007 at 02:21:54AM +0100, Thomas Rowland wrote: > > Available to all via google 'rdtc' is; > > http://www-unix.mcs.anl.gov/~kazutomo/rdtsc.html > > Which also gives a PPC equiv. function, and is as good as any. > > There's no copyright statement or similar on that page, and > I'm pretty sure that's been copied from somewhere itself. > > I can't remember where, but I've seen the 'byte blah on x86, > rdtsc on amd64' thing. I thought it was the mplayer sources, > but it's not. > > I'm not sure what functionality these provide over my patch, > except that mine is certified by me to be either my own work, > or a contribution from someone who has absolved their > copyright claim if one exists. > > -- > ----------------------------------------------------------- > Paul "TBBle" Hampson, B.Sc, LPI, MCSE > On-hiatus Asian Studies student, ANU > The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) > Paul.Hampson@Pobox.com > > Of course Pacman didn't influence us as kids. If it did, > we'd be running around in darkened rooms, popping pills and > listening to repetitive music. > -- Kristian Wilson, Nintendo, Inc, 1989 > > License: http://creativecommons.org/licenses/by/2.1/au/ > ----------------------------------------------------------- > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.472 / Virus Database: 269.8.4/825 - Release > Date: 30/05/2007 15:03 > > > From chance at kalacia.com Sat Jun 2 06:03:53 2007 From: chance at kalacia.com (Chance Unknown) Date: Sat Jun 2 06:03:56 2007 Subject: [sldev] Patch to Address Debit Permission Spoofing In-Reply-To: <3c1fe370706020324s627bcbe0ne24bf88fb8c5dd38@mail.gmail.com> References: <465C00CA.2090408@blueflash.cc> <11kJ4G5cc5s6sJ8s08rz8shx1.alissa_sabre@yahoo.co.jp> <465D65E7.9020903@gmail.com> <2925011a0705300748t7408649do655c20a54ddfc5b5@mail.gmail.com> <7b3a84fb0705300805u16a6c7ecjfefc315241753a70@mail.gmail.com> <465D9574.5080705@gmail.com> <3c1fe370706020324s627bcbe0ne24bf88fb8c5dd38@mail.gmail.com> Message-ID: <2925011a0706020603j47754f44le0956467ebdd2d68@mail.gmail.com> You missed the earlier discussion. Why do you need to inspect a prim that you own? To find out who the joker was that sent you the prim thats robbing you? You shouldn't accept inventory items from a grey-goo cloud in the first place -- let alone rez them. Thats part of the game legacy that all NOOBS get at one point. Then after that we all laugh that someone else got hit with it too. On 6/2/07, Kele Kravelin wrote: > Hmmm has anyone told the victim here about hte newish 'inspect' pie menu > option. As I recall it shows the owner and creator of all prims and > inventory of an object, that should give the name of the creator of the > malicious script and help track it down. Of course that means one of the > victims would have to believe Dave and work with him to track the true thief > down. Also they can look at their transaction history since their lost L$ > will be going to someone (and if Dave is innocent it won't be Dave's name). > While there are remedies (which many will just ignore and just go after the > fast 'solution') it does highlight a need for changes in the debit > permission system. > > > On 5/30/07, Tateru Nino wrote: > > > > > > Able Whitman wrote: > > > Of course, as others have pointed out, malicious scripts are rare. But > > > the need to grant an object the debit permission is also rare, or at > > > least it is uncommon. And once granted it is difficult to both revoke > > > the permission and to seek remedy for fraudulent debits. > > Not so rare, perhaps: > > http://www.gridgrind.com/?p=93 > > > > -- > > Tateru Nino > > http://dwellonit.blogspot.com/ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From Paul.Hampson at Pobox.com Sat Jun 2 09:43:51 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Sat Jun 2 09:44:01 2007 Subject: [sldev] QueryPerformanceCounter() & related issues VWR-940, VWR-962, VWR975 In-Reply-To: <46615822.9040300@dzonux.net> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> <20070602101237.GA22431@keitarou> <46615822.9040300@dzonux.net> Message-ID: <20070602164351.GA25053@keitarou> On Sat, Jun 02, 2007 at 04:44:34AM -0700, Dzonatas wrote: > Paul TBBle Hampson wrote: > >There's no copyright statement or similar on that page, and I'm > >pretty sure that's been copied from somewhere itself. > It has a governmental address, which it is common to assume public > domain. They are pretty simple. Assuming something in copyright isn't exactly iron-clad. In this case, the person who's personal site this is, is also working on ZeptOS which comes from the same address and carries a GPL license. [1] So that assumption has no basis here. On the other hand, the simplicity was asserted by the person who wrote the PowerPC assembly routine I used in my patch. And authorative as he might be for his code, I'm not sure he can speak for anyone else who's implemented functionally identical code. > I started to sort out the related contributions. Attached is a patch > for review... more works need to be done on it. > Main change I did was move rdtsc and likewise code into the header > file, llfasttimers.h, so that code can now assemble in-line. Eh... > saves a little overhead. As per coding standard, please provide profiling justification for this. It's already hard enough to make sense of as it is, and moving things around like that makes it _very_ hard to review a patch. Once the code is done and working, profile and inline it as neccessary. You don't mention this, but I assume this is based on your previously- posted patch, since it removes some of the LL_GNUC #define usage you added in that patch. > @@ -156,9 +160,11 @@ > //////////////////////////////////////////////////////////////////////////// > F64 CProcessor::GetCPUFrequency(unsigned int uiMeasureMSecs) > { > -#ifndef PROCESSOR_FREQUENCY_MEASURE_AVAILABLE > - return 0; > -#else > +#if LL_LINUX > + extern LLCPUInfo gSysCPU; > + return boost::lexical_cast(gSysCPU.getInfoLine( "cpu MHz" )) * 1000000; > + > +#elif LL_WINDOWS // PROCESSOR_FREQUENCY_MEASURE_AVAILABLE > // If there are invalid measure time parameters, zero msecs for example, > // we've to exit the function > if (uiMeasureMSecs < 1) cpu MHz only exists on x86 and AMD64. It's "clock" on PowerPC. /proc might not be the best place to fetch the current CPU speed from, /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq is prolly more reliable, /sys/ is designed for code to process, but I dunno if it's actually widespead enough. My i386 box doesn't have it, but it's also much too slow to run SLViewer... Frankly, I'm getting more and more uncomfortable with the idea of measuring the CPU Frequency by rdtscing a _Delay call, whatever that is. Mind you, the cpu MHz output from /proc/cpuinfo isn't actually any more reliable, since that's basically what the kernel does during boot on i386, I believe, and prolly AMD64 too. But at least at that stage, there's nothing else going on. I dunno if win32 allows you to get kicked off the CPU unexpectedly, but if that happened in the middle of a Delay, that'd blow the measurement. I'm guessing that doesn't happen or it wouldn't have been written like that. ^_^ Although that's then 50ms of wasted CPU time... (On my G4 1.5Ghz PowerCPU, the "clock" line is 1499.999000MHz, but I think that's actually due to rounding on the reads from the timing data, rather than calibrating it from a loop during boot.) ##else > U64 LLFastTimer::countsPerSecond() > { > @@ -108,6 +62,8 @@ > { > CProcessor proc; > sCPUClockFrequency = proc.GetCPUFrequency(50); > + if(!sCPUClockFrequency) > + sCPUClockFrequency = 1000000.0; > return U64(sCPUClockFrequency); I think this rather confusingly ties "has a high-performance counter" code to the "has a sensible GetCPUFrequency value" code. This is fine on win32 (has both), Linux x86 (has both), Linux AMD64 (has both), and PowerPC (Special-cased with #define, never hits this). Also the high performance counters falling back to gettime of day, will be correct. But it took me two readings to realise that, and I suggest it's a rather tangled way of approaching the problem. That is also prolly related to the complete lack of comments giving any kind of context to these numbers. That's could alternatively be solved by rearranging this file to keep the countsPerSecond and related get_cpu_clock_count methods together. I considered doing that in my patch, but I didn't want to produce a hard-to-read mess of #defines for patch review, especially when the code was not as feature-complete as I'd like and I'd had no feedback on the direction I was taking. It also needs a comment in the LLFastTimer class definition to the effect that sCPUClockFrequency is CPUFrequency at first call on i386 Linux, AMD64 Linux and Win32, undefined on PowerPC Linux, and 1 million on platforms that use gettimeofday to implement fast-timers. That's of course true of the upstream code as well, as it happens, apart from the last, arbitrary possible value you've introduced here. It really out to be renamed, methinks, and used either for all the countsPerSecond methods, only the ones where GetCPUFrequency is expensive (ie. win32, under your proposed implementation) The former makes sense under your implementation, and the latter makes sense under mine, where I've already split up the different platforms, even the ones that happen to do the same thing. ('cause I expected someone would want to implement a similar thing to the linux PowerPC/AMD64 split in the MacOS X code, and wanted to make sure the patches didn't turn into a mess of #define changes at the same time) === Mind you, I haven't actually looked to see how this sort of thing is going to handle changes in the timebase on x86 and AMD64 arches, anyway, but using the static cpu MHz from /proc/cpuinfo at program start can't be the right solution. As it is, chaning the CPU frequency on win32 or Linux x86 or Linux AMD64 is going to have a proportional effect on the results of the llfasttimers. Bleh. At least on Apple PowerPC hardware, I can rely on the timebase staying constant, even if I pull out the AC adaptor while it's happening and my CPU drop to 700Mhz. Then again, I'd prolly like some of the low-speed CPU effects to kick in then, so GetCPUFrequency prolly _should_ return the current CPU speed, but I doubt the featuremanager checks it after startup. That smells like a different issue to me at this point. [1] http://www-unix.mcs.anl.gov/zeptoos/docs/license.php -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070603/27735318/attachment.pgp From dzonatas at dzonux.net Sat Jun 2 11:55:10 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jun 2 11:53:44 2007 Subject: [sldev] QueryPerformanceCounter() & related issues VWR-940, VWR-962, VWR975 In-Reply-To: <20070602164351.GA25053@keitarou> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> <20070602101237.GA22431@keitarou> <46615822.9040300@dzonux.net> <20070602164351.GA25053@keitarou> Message-ID: <4661BD0E.9030404@dzonux.net> Paul TBBle Hampson wrote: > So that assumption has no basis here. > Correct. > On the other hand, the simplicity was asserted by the person who wrote > the PowerPC assembly routine I used in my patch. And authorative as he > might be for his code, I'm not sure he can speak for anyone else who's > implemented functionally identical code. > A quick google reveals similar code used elsewhere. Actually, a cmpw instruction instead of a cmplw seems more common. Hmm. > Main change I did was move rdtsc and likewise code into the header >> file, llfasttimers.h, so that code can now assemble in-line. Eh... >> saves a little overhead. >> > > As per coding standard, please provide profiling justification for this. > Consider that the code that calls this function is in-line (in the class header), it creates a bias in the compiler to not in-line any of the code -- even the code of the class header. The reason that it originally exists in the object module rather than the header may be based on the pentium 1 or pre VS6.0 era. That is a easy presumption because of the emit usage. The instruction rdtsc was undocumented, and the only sure way to use it was to wrap it up in a call structure with a stack. Newer compilers know about rdtsc and how to handle its usage, so there is no need to wrap it anymore unless you want to time individual assembly instructions and need to prevent out-of-order execution. The basic recommended system is past the pentium 1 era. > It's already hard enough to make sense of as it is, and moving things > around like that makes it _very_ hard to review a patch. Once the code > is done and working, profile and inline it as neccessary. > I've profiled the viewer and found that there is high cache pollution. A polluted cache will not let any of the viewer run at expected speed. One step to fix this is to reduce bandwidth bottlenecks. The change to make this more in-line will help localize data access. For one, more in-line code avoids a global call stack and further page faults. Such isolated cache fetches are not easy to profile, if they can be isolated, due to the nature of live data being much more random with the overhead of 50 threads. General data alignment is another way to reduce cache pollution, but we are aways from that being worthwhile. I've turned on alignment and optimizations for more recent processors. With the viewer completely compiled that way, I've seen code run 2 to 3 times faster. However, that would mean maintenance overhead for separate binaries for similar processors, which I've learned has been discussed and passed on. We need incentives to improve end user hardware. > cpu MHz only exists on x86 and AMD64. It's "clock" on PowerPC. > Thanks. I'll add that. > /proc might not be the best place to fetch the current CPU speed from, > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq is prolly more > reliable, Between what Tofu and a google recommends, this appears to be the preferred order: Test /sys/devices/system/cpu/cpu0/cpuinfo_cur_freq, else Test /sys/devices/system/cpu/cpu0/scaling_cur_freq, else Test /proc/cpuinfo, else Test gettimeofday() & rdtsc (or likewise), else Test gettimeofday() & expect 1Mhz > ##else > >> U64 LLFastTimer::countsPerSecond() >> { >> @@ -108,6 +62,8 @@ >> { >> CProcessor proc; >> sCPUClockFrequency = proc.GetCPUFrequency(50); >> + if(!sCPUClockFrequency) >> + sCPUClockFrequency = 1000000.0; >> >> return U64(sCPUClockFrequency); >> > > I think this rather confusingly ties "has a high-performance counter" > code to the "has a sensible GetCPUFrequency value" code. > > This is fine on win32 (has both), Linux x86 (has both), Linux AMD64 (has > both), and PowerPC (Special-cased with #define, never hits this). > > Also the high performance counters falling back to gettime of day, will > be correct. > > But it took me two readings to realise that, and I suggest it's a rather > tangled way of approaching the problem. > Yep. Needs work. Perhaps, it is best to call LLCPUInfo.getMhz() instead of a direct call to CProcessor::GetCPUFrequency(). That way the best frequency determination can be more localized to LLCPUInfo, and fallback can be in CProcessor::GetCPUFrequency(). ...almost quietly fixed a bug here. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070602/fc585fb2/attachment-0001.htm From gigstaggart at gmail.com Sat Jun 2 12:11:13 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jun 2 12:21:31 2007 Subject: [sldev] Alignment and optimizations In-Reply-To: <4661BD0E.9030404@dzonux.net> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> <20070602101237.GA22431@keitarou> <46615822.9040300@dzonux.net> <20070602164351.GA25053@keitarou> <4661BD0E.9030404@dzonux.net> Message-ID: <4661C0D1.7020401@gmail.com> Dzonatas wrote: > General data alignment is another way to reduce cache pollution, but we > are aways from that being worthwhile. I've turned on alignment and > optimizations for more recent processors. With the viewer completely > compiled that way, I've seen code run 2 to 3 times faster. However, that > would mean maintenance overhead for separate binaries for similar > processors, which I've learned has been discussed and passed on. Would it? How bad is the performance hit on a system it wasn't compiled for? Is there a "best compromise" CPU that could be optimized for that has the least negative impact on other CPUs? -Jason From dzonatas at dzonux.net Sat Jun 2 13:27:57 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jun 2 13:26:36 2007 Subject: [sldev] Alignment and optimizations In-Reply-To: <4661C0D1.7020401@gmail.com> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> <20070602101237.GA22431@keitarou> <46615822.9040300@dzonux.net> <20070602164351.GA25053@keitarou> <4661BD0E.9030404@dzonux.net> <4661C0D1.7020401@gmail.com> Message-ID: <4661D2CD.4010402@dzonux.net> Jason Giglio wrote: > Would it? How bad is the performance hit on a system it wasn't > compiled for? Is there a "best compromise" CPU that could be > optimized for that has the least negative impact on other CPUs? > The best compromise is to have the open source available and to be able to compile it to a certain processor. Linux distributors have an edge on that with the inherit package tools. With a look at the future specifications for processors, one can easily compare the man-hour cost of support for older hardware and find at end of the same man-hour time that there will no longer be a need to support that older hardware. Any hardware that doesn't support at least 128bit data-paths on board can be considered as older hardware. That bias is trivial by sheer cost to process 3D data. Any attempt to outsource 3D tasks to graphics cards is a band-aid approach. That is the non-Linux based "best compromise". Some people feel at ease to get a new GPU every new manufacture revision, so that approach seems justifiable. Why doesn't it happen so easily for the CPU? Could it be that the cost to rebuild a system has increased? Windows doesn't make it easy anymore to upgrade to a new mobo+CPU under the same Windows key, but it will easily accept a new plug-n-play GPU! Hmm. D -- From dzonatas at dzonux.net Sat Jun 2 19:34:22 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jun 2 19:32:54 2007 Subject: [sldev] Linux cpu frequency Message-ID: <466228AE.80700@dzonux.net> I just tested a little tidbit, and I was surprised it was accurate even on a virtualized Linux. in CProcessor::GetCPUFrequency() struct timeval tv_start, tv_end; U64 start, end; F64 secs_start, secs_end; gettimeofday(&tv_start, NULL); start = get_cpu_clock_count(); usleep(uiMeasureMSecs); gettimeofday(&tv_end, NULL); end = get_cpu_clock_count(); secs_start = (F64)tv_start.tv_usec / 1000000.0f + (F64)tv_start.tv_sec; secs_end = (F64)tv_end.tv_usec / 1000000.0f + (F64)tv_end.tv_sec; return ( uqwFrequency = (F64)(end - start) / (secs_end - secs_start) / 1000000 ); That'll work for a default method for any x86 Unix that supports usleep() and an accurate gettimeofday(). Now to test /proc and /sys before this is used... -- From Paul.Hampson at Pobox.com Sat Jun 2 22:47:11 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Sat Jun 2 22:47:21 2007 Subject: [sldev] QueryPerformanceCounter() & related issues VWR-940, VWR-962, VWR975 In-Reply-To: <4661BD0E.9030404@dzonux.net> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> <20070602101237.GA22431@keitarou> <46615822.9040300@dzonux.net> <20070602164351.GA25053@keitarou> <4661BD0E.9030404@dzonux.net> Message-ID: <20070603054711.GA32143@keitarou> On Sat, Jun 02, 2007 at 11:55:10AM -0700, Dzonatas wrote: > Paul TBBle Hampson wrote: > >So that assumption has no basis here. > > > Correct. > >On the other hand, the simplicity was asserted by the person who wrote > >the PowerPC assembly routine I used in my patch. And authorative as he > >might be for his code, I'm not sure he can speak for anyone else who's > >implemented functionally identical code. > A quick google reveals similar code used elsewhere. Actually, a cmpw instruction instead of a cmplw seems more common. Hmm. > >Main change I did was move rdtsc and likewise code into the header > >>file, llfasttimers.h, so that code can now assemble in-line. Eh... > >>saves a little overhead. > >As per coding standard, please provide profiling justification for this. > Consider that the code that calls this function is in-line (in the class header), it creates a bias in the compiler to not in-line any of the code -- even the code of the class header. The reason that it > originally exists in the object module rather than the header may be based on the pentium 1 or pre VS6.0 era. That is a easy presumption because of the emit usage. The instruction rdtsc was undocumented, and the > only sure way to use it was to wrap it up in a call structure with a stack. Newer compilers know about rdtsc and how to handle its usage, so there is no need to wrap it anymore unless you want to time individual > assembly instructions and need to prevent out-of-order execution. Huh. I was under the impression that it was the other way around, putting short code in the class header made it bias _towards_ inlining. I'm not sure about this whole Pentium-1 argument you've put forward, I doubt slviewer's that old (At least here in Australia, the Pentium 1 predated the public arrival of the Internet). Mind you, I haven't got a _good_ reason why gcc sample code uses the .byte version instead of the rdtsc instruction itself. I'm assuming the assembler would come up with the same answer either way. > >It's already hard enough to make sense of as it is, and moving things > >around like that makes it _very_ hard to review a patch. Once the code > >is done and working, profile and inline it as neccessary. > I've profiled the viewer and found that there is high cache pollution. > A polluted cache will not let any of the viewer run at expected speed. > One step to fix this is to reduce bandwidth bottlenecks. The change to > make this more in-line will help localize data access. For one, more > in-line code avoids a global call stack and further page faults. Such > isolated cache fetches are not easy to profile, if they can be > isolated, due to the nature of live data being much more random with > the overhead of 50 threads. OK, but that's not what the coding-standard requires. I haven't looked, but if it's being called from inlined code, then it prolly should be inlined. My reading of the Coding Standard implies numerical proof, presumably showing (a) that that code is a hotspot; and (b) that the proposed change fixes that hotspot. (I could be wrong about that... but experience suggests that optimisation without numerical support is wasted effort) This code isn't yet functionally complete, so it _can't_ have been proved to be a hotspot yet... I still feel this's something that should be done _after_ the patch review, not during. I would however be particularly interested in the method of profiling you use, so I can try applying it to my build here, and work out why _it_ is so painfully slow. > General data alignment is another way to reduce cache pollution, but we are aways from that being worthwhile. I've turned on alignment and optimizations for more recent processors. With the viewer completely > compiled that way, I've seen code run 2 to 3 times faster. However, that would mean maintenance overhead for separate binaries for similar processors, which I've learned has been discussed and passed on. Oh, I like the idea of 2-3x speed improvement. It's basically not currently playable on my 1.5GHz 512MB PowerBook. -_- > We need incentives to improve end user hardware. We need what now? I'm just not even going to think too hard about that. > >cpu MHz only exists on x86 and AMD64. It's "clock" on PowerPC. > Thanks. I'll add that. > >/proc might not be the best place to fetch the current CPU speed from, > >/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq is prolly more > >reliable, > Between what Tofu and a google recommends, this appears to be the preferred order: > Test /sys/devices/system/cpu/cpu0/cpuinfo_cur_freq, else > Test /sys/devices/system/cpu/cpu0/scaling_cur_freq, else > Test /proc/cpuinfo, else > Test gettimeofday() & rdtsc (or likewise), else > Test gettimeofday() & expect 1Mhz Looks good to me. > > ##else > > > >> U64 LLFastTimer::countsPerSecond() > >> { > >>@@ -108,6 +62,8 @@ > >> { > >> CProcessor proc; > >> sCPUClockFrequency = proc.GetCPUFrequency(50); > >>+ if(!sCPUClockFrequency) > >>+ sCPUClockFrequency = 1000000.0; > >> return U64(sCPUClockFrequency); > >> > >I think this rather confusingly ties "has a high-performance counter" > >code to the "has a sensible GetCPUFrequency value" code. > > This is fine on win32 (has both), Linux x86 (has both), Linux AMD64 (has > >both), and PowerPC (Special-cased with #define, never hits this). > >Also the high performance counters falling back to gettime of day, will > >be correct. > >But it took me two readings to realise that, and I suggest it's a rather > >tangled way of approaching the problem. > Yep. Needs work. > Perhaps, it is best to call LLCPUInfo.getMhz() instead of a direct call to CProcessor::GetCPUFrequency(). That way the best frequency determination can be more localized to LLCPUInfo, and fallback can be in > CProcessor::GetCPUFrequency(). > ...almost quietly fixed a bug here. I think so, yes. Over the course of this discussion, a voice in the back of my head has been helpfully suggesting that we've got two classes that are trying to do the same thing... -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070603/e128e080/attachment.pgp From jingcomics at email.it Sun Jun 3 05:59:57 2007 From: jingcomics at email.it (Alice in Wire) Date: Sun Jun 3 06:00:01 2007 Subject: [sldev] a script for add someone Message-ID: <4662BB4D.1040104@email.it> how a script can send a add to someone? -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Speciale, pacchetti all inclusive per 1 settimana in Kenya, a partire da Euro 1.085. Scopri tutte le offerte Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6605&d=3-6 From dzonatas at dzonux.net Sun Jun 3 10:02:55 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jun 3 10:01:25 2007 Subject: [sldev] VWR-940, VWR-962, VWR975 In-Reply-To: <20070603054711.GA32143@keitarou> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> <20070602101237.GA22431@keitarou> <46615822.9040300@dzonux.net> <20070602164351.GA25053@keitarou> <4661BD0E.9030404@dzonux.net> <20070603054711.GA32143@keitarou> Message-ID: <4662F43F.4040505@dzonux.net> Paul TBBle Hampson wrote: > I would however be particularly interested in the method of profiling > you use, so I can try applying it to my build here, and work out why > _it_ is so painfully slow. > I used VTune and also added benchmarks. I've also tested code that runs in a single thread and compared it to the live situation in SL. It's interesting that a few spin locks come up as hotspots. Their threshold could be optimized. > I think so, yes. Over the course of this discussion, a voice in the back > of my head has been helpfully suggesting that we've got two classes that > are trying to do the same thing... > One is raw data from the hardware while the other is what the OS reports. I've sorted these patches. I'm compiling today for final tests. -- From nicholaz at blueflash.cc Sun Jun 3 13:29:25 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 3 13:29:30 2007 Subject: [sldev] Processor Optimizations (Windows) Message-ID: <466324A5.2040908@blueflash.cc> Someone mentioned processor optimizations here a few days ago (something around the Linux fasttimers), so I decided to give that a go with Windows. I hardly did any proper profiling, but in specific situations that were sort of reproduceable (like going to the same sim, sitting there for textures to download and look at the FPS rates) I saw frame rates noticeably higher that what I usually get. So, if someone makes their own Windows build, try to enable inline function expansion (anything suitable), intrinsic functions (/OI), favor fast code (/Ot), optimize for processor (P4 and above, /G7) and optimize for Windows application (/GA). Details here: http://nicholaz-beresford.blogspot.com/2007/06/running-with-5-50-higher-frame-rates.html Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Sun Jun 3 14:25:06 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jun 3 14:23:36 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <466324A5.2040908@blueflash.cc> References: <466324A5.2040908@blueflash.cc> Message-ID: <466331B2.5000506@dzonux.net> Nicholaz Beresford wrote: > Details here: > http://nicholaz-beresford.blogspot.com/2007/06/running-with-5-50-higher-frame-rates.html > When you benchmark these results, it is a good measure to turn off different features. Use the Client->Rendering menu to do this. That way you can easily see the maximum possible framerate and see how individual features affect the framerate. I turned off a set of features and obtained up to 120FPS with general optimization on. This dropped down to 70FPS with the same features off and no optimizations. Almost a 2x speed difference kinda like that 50% increase you saw. In this same sim location with all features on, I get below 25 FPS with or without optimizations. -- From robla at lindenlab.com Sun Jun 3 15:36:28 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sun Jun 3 15:36:38 2007 Subject: [sldev] Contributing code you didn't write (Re: QueryPerformanceCounter() & related issues VWR-940, VWR-962, VWR975) In-Reply-To: <20070602164351.GA25053@keitarou> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> <20070602101237.GA22431@keitarou> <46615822.9040300@dzonux.net> <20070602164351.GA25053@keitarou> Message-ID: <4663426C.6030805@lindenlab.com> On 6/2/07 9:43 AM, Paul TBBle Hampson wrote: > On Sat, Jun 02, 2007 at 04:44:34AM -0700, Dzonatas wrote: > >> It has a governmental address, which it is common to assume public >> domain. They are pretty simple. >> > > Assuming something in copyright isn't exactly iron-clad. > That is a severe understatement. Do NOT copy code from outside sources and include it in a patch. If, for whatever reason, you think it'd be good for Linden Lab to pull in code from someone that doesn't have a contributor agreement on file, please note that in the appropriate context. For example, put in a JIRA comment where a patch would go: "there's code from X that addresses this issue (link). Please approve this for inclusion, and I'll work it into a patch.". Assuming someone from Linden Lab actually gives the go ahead, please make sure it is extremely clear from looking at the code who the copyright holder is, and /exactly/ which parts are from the third party and where they came from. It should not be necessary to sift through a thread on sldev to find out the real author of a piece of source code. Is there code in a patch on JIRA that was copied from outside sources without clear markings for where the code came from? If there is, please remove it immediately. Almost every software license out there (including MIT and BSD) have minimal requirements for acknowledgment. Even in the rare case where someone has signed their code into the public domain, or is truly the work of the U.S. Federal Government, copying without explicit and proper acknowledgment of the source or prior agreement with the author is plagiarism, and is widely considered to be bad form. Please be very careful about this. Mistakes in this area can be very costly. Thanks Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070603/3e6ca60f/signature.pgp From able.whitman at gmail.com Sun Jun 3 16:42:59 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sun Jun 3 16:43:01 2007 Subject: [sldev] Investigating how the viewer creates object (Re: New Feature: Mute Visibility) Message-ID: <7b3a84fb0706031642k8fb4831g8d4bb1d591887c15@mail.gmail.com> With an eye towards figuring out how to implement visual object muting (VWR-1017), I decided to look into how the viewer handles sim notifications of new objects for it to render. I don't know how interesting or useful this is, but I thought I'd share what I've learned. If it would be helpful, I'd be happy to make a wiki entry with this information. In summary, the process by which the viewer handles new object notifications (as well as existing object updates) works like this: * register_viewer_callbacks() in llstartup.cpp registers an handler for the ObjectUpdate message (defined in message_template.msg) * the viewer receives an ObjectUpdate message from a sim * the message is handled by process_object_update() in llviewermessage.cpp * the message is passed to gObjectList.processObjectUpdate() in llviewerobjectlist.cpp * if the object is a new object, gObjectList.createObject() is called - the object params are passed to the static LLViewerObject::createObject() in llviewerobject.cpp - LLViewerObject::createObject() examines the type of object to create, and calls a specific constructor of a descendant of LLViewerObject - for prims, flexi-prims, and sculpties, the class in question is LLVOVolume * gObjectList.processObjectUpdate() passes the message to processUpdateCore() * processUpdateCore() passes the message to processUpdateMessage() on the instance returned by LLViewerObject::createObject() - for all LLViewerObject objects: . the region and coordinates for the object are obtained . object params like scale, material, touch (click) actions, and attached sounds are processed . object rotation, velocity, acceleration, angular velocity, hover text, particle system settings, parent object, etc. are processed - for LLVOVolume objects: . scuplted prim settings and texture are processed . animated textures are processed . prim parameters like hollow, shear, twist, taper, skew, etc. are processed by the static LLVolumeMessage::unpackVolumeParams() . prim textures are updated by LLVOVolume::updateTEData() * processUpdateCore() adds the object to the list of active viewer objects, and also to the render pipeline via gPipeline.addObject() The process by which the viewer handles object deletion notifications works like this: * register_viewer_callbacks() in llstartup.cpp registers an handler for the KillObject message (defined in message_template.msg) * the viewer receives a KillObject message from a sim * the message is handled by process_kill_object() in llviewermessage.cpp, which loops through all objects to be killed as listed in the message * if an object to be killed is selected, it is unselected via gSelectMgr->removeObjectFromSelections() * the viewer object to be killed is found via gObjectList.findObject() * the object is killed by calling gObjectList.killObject() Thoughts on Implementing Object Muting: It seems like the straightforward approach would be something like this: * add a flag to the LLVOVolume class (perhaps BOOL mIsVisuallyMuted or similar) which defaults to FALSE * in LLVOVolume::processUpdateMessage(), use the prim region, coordinates, object id, and owner id to determine whether to flag the object as muted or not * if the object is muted, override the object audio and click (touch) settings so that the viewer's version of the object doesn't play sound or respond to touch events * hook into LLVOVolume::updateTextures() to force the object to use the default texture for all faces if the object is muted * also hook into LLPrimitive::unpackTEMessage() to force any texture updates for the object sent from the sim result in "new" textures also being forced to be the default texture Note that the default texture is the static LLViewerImage* LLViewerImage::sDefaultImagep, which uses the IMG_DEFAULT texture LLUUID (d2114404-dd59-4a4d-8e6c-49359e91bbf0, which seems to be the default grey texture). I make a quick-and-dirty hack similar to the above to the LLVOAvatar class, which forced every avatar to have their skin and clothing rendered with the default grey texture. It was in the process of making this hack that I discovered that hooking updateTextures() is not enough, and that unpackTEMessage() was also necessary. Open issues I haven't investigated yet: * how to store and persist the list of filters to use to determine which objects are muted * how to hook into the viewer UI to enable users to mark object as muted or unmuted * how to determine whether a given region and coordinate, whether that point exists within a given parcel or not I plan to look into how the existing muting mechanism works, to see how feasible it would be to extend this to support visual muting of object as well. I'm also going to look into how the viewer determines the boundaries for parcels in a region, to see if there is a way to quickly and efficiently check whether a point exists within a given parcel or not, since I believe that muting object by parcel is the most effective way to choose objects to mute. More Details on Object Creation: The viewer is notified buy the simulator of new objects to draw by a variety of messages, most of them similar to the ObjectUpdate message (defined in message_template.msg). These are the messages that appear to be related to sim notifications of object that need to be drawn by the viewer: * ObjectUpdate - handled by process_object_update() in llviewermessage.cpp * ObjectUpdateCompressed - handled by process_compressed_object_update() in llviewermessage.cpp * ObjectUpdateCached - handled by process_cached_object_update() in llviewermessage.cpp * ImprovedTerseObjectUpdate - handled by process_terse_object_update() in llviewermessage.cpp - essentially the same handling code as ObjectUpdateCompressed * KillObject It's not entirely clear to me what what specific circumstances cause the various ObjectUpdate messages to be generated, but for now I'm mostly concerned with the general process for creating and updating objects. Message handlers are configured by register_viewer_callbacks() in llstartup.cpp. All of the ObjectUpdate-related messages call through to LLViewerObjectList::processObjectUpdate() in llviewerobjectlist.cpp with a little or no message-specific preprocessing. In LLViewerObjectList::processObjectUpdate(): * the handle for the region that the object is in is decoded * this handled is validated against a list of regions known to the viewer * the viewer looks up the object in its list of known objects - the global viewer object list is an LLViewerObjectList named gObjectList - lookups for known objects via gObjectList->findObject() * if the object already exists, the viewer updates its localid (which I think is session-specific) - the localid will also be updated if the object has moved from one region to another * if the object doesn't exist, the viewer creates it Object creation occurrs in LLViewerObjectList::createObject(), which just does some pre-processing and calls down to the static method LLViewerObject::createObject() in llviewerobject.cpp. Based on the type of object specified in the ObjectUpdate message, createObject() call constructors for one of the following classes: LLVOVolume, LLVOAvatar, LLVOGrass, LLVOTree, LLVOTextBubble, LLVOClouds, LLVOSurfacePatch, LLVOSky, LLVOStars, LLVOWater, LLVOGround, LLVOPartGroup All of these classes derive (eventually) from LLViewerObject, which itself derives from LLPrimitive. Of these classes, the most interesting one is LLBVOVolume, which is the class that encapsulates what we generally think of as "prims". This includes all basic prim types, plus flexi-prims and sculpted prims. Once the existing LLViewerObject is updated, or a new one is created, processUpdateObject() calls into LLViewerObjectList::processUpdateCore() in llviewerobjectlist.cpp. The first thing processUpdateCore() does is call the instance method processUpdateMessage() on the LLViewerObject instance returned from LLViewerObject::createObject(). (If the object already existed, this method is called on the existing instance of the object found via gObjectList->findObject().) In the case of prim objects, the method called is LLVOVolume::processUpdateMessage(), which immediately calls into the base implementation on LLViewerObject::processUpdateMessage(). The base implmenentation of processUpdateMessage(): * first determines the region the object is in and its coordinates in that region * processes properties common to all the different ObjectUpdate-related messages: object id, parent id, material, attached sound, click (touch) action, scale, etc. * processes properties specific to the different types of ObjectUpdate-related messages There is rather a mess of code which handles the special cases of ObjectUpdate messages--cached, compressed, terse, or improved terse message types. The special cases are handled by nested switch and if/then blocks, with a lot of magic numbers and a good deal of code specific to more-derived LLViewerObject types. This section of code alone is more than 1,000 lins long, and parts of it probably should be moved into the derived implementations of processUpdateMessage(). (The whole base implementation of this method is about 1,200 lines, so the special-cased section is likely ripe for refactoring.) The derived LLVOVolume::processUpdateMessage(): * processes scuplted prim settings and textures * processes animated textures * processes prim parameters like hollow, shear, twist, taper, skew, etc. via the static method LLVolumeMessage::unpackVolumeParams() * updates prim textures via LLVOVolume::updateTEData() Finally, processUpdateCore() adds the prim to the list of active viewer object (if the object is indeed active) and then calls the updateTextures() method on the instance of LLViwerObject for the object. Then the object is added to the render pipeline by calling gPipeline.addObject(). --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070603/874e855b/attachment-0001.htm From ziggy at planetziggy.com Sun Jun 3 18:37:04 2007 From: ziggy at planetziggy.com (Ziggy Puff) Date: Sun Jun 3 18:37:09 2007 Subject: [sldev] Help with VWR-332 (Re: Investigating how the viewer creates object) In-Reply-To: <7b3a84fb0706031642k8fb4831g8d4bb1d591887c15@mail.gmail.com> References: <7b3a84fb0706031642k8fb4831g8d4bb1d591887c15@mail.gmail.com> Message-ID: <46636CC0.6040909@planetziggy.com> I'd submitted VWR-332 a while back, and today I thought I'd try and figure it out myself. Since I just downloaded the code, this description helps a lot. VWR-332 appears to be an issue in how scripted prim movement is rendered, specifically, the interpolation applied to rotation and translation. If anyone has pointers on where to look, I would really appreciate that. I found the LLVOVolume class, and LLCriticalDamp (though that's probably used for physical movement?). There are lerp and slerp functions in LLQuaternion, and there's LLDrawable::updateXform which seems to calculate damping/interpolation for translations and rotations. Right now I'm trying to figure out how all of these fit together, and which portions I should be looking at. https://jira.secondlife.com/browse/VWR-332 Thanks, Ziggy Able Whitman wrote: > With an eye towards figuring out how to implement visual object muting > (VWR-1017), I decided to look into how the viewer handles sim > notifications of new objects for it to render. I don't know how > interesting or useful this is, but I thought I'd share what I've > learned. If it would be helpful, I'd be happy to make a wiki entry > with this information. > > In summary, the process by which the viewer handles new object > notifications (as well as existing object updates) works like this: > > * register_viewer_callbacks() in llstartup.cpp registers an handler > for the ObjectUpdate message (defined in message_template.msg) > * the viewer receives an ObjectUpdate message from a sim > * the message is handled by process_object_update() in llviewermessage.cpp > * the message is passed to gObjectList.processObjectUpdate() in > llviewerobjectlist.cpp > * if the object is a new object, gObjectList.createObject() is called > - the object params are passed to the static > LLViewerObject::createObject() in llviewerobject.cpp > - LLViewerObject::createObject() examines the type of object to > create, and calls a specific constructor of a descendant of > LLViewerObject > - for prims, flexi-prims, and sculpties, the class in question is > LLVOVolume > * gObjectList.processObjectUpdate() passes the message to > processUpdateCore() > * processUpdateCore() passes the message to processUpdateMessage() on > the instance returned by LLViewerObject::createObject() > - for all LLViewerObject objects: > . the region and coordinates for the object are obtained > . object params like scale, material, touch (click) actions, and > attached sounds are processed > . object rotation, velocity, acceleration, angular velocity, hover > text, particle system settings, parent object, etc. are processed > - for LLVOVolume objects: > . scuplted prim settings and texture are processed > . animated textures are processed > . prim parameters like hollow, shear, twist, taper, skew, etc. are > processed by the static LLVolumeMessage::unpackVolumeParams() > . prim textures are updated by LLVOVolume::updateTEData() > * processUpdateCore() adds the object to the list of active viewer > objects, and also to the render pipeline via gPipeline.addObject() > > The process by which the viewer handles object deletion notifications > works like this: > > * register_viewer_callbacks() in llstartup.cpp registers an handler > for the KillObject message (defined in message_template.msg) > * the viewer receives a KillObject message from a sim > * the message is handled by process_kill_object() in > llviewermessage.cpp, which loops through all objects to be killed as > listed in the message > * if an object to be killed is selected, it is unselected via > gSelectMgr->removeObjectFromSelections() > * the viewer object to be killed is found via gObjectList.findObject() > * the object is killed by calling gObjectList.killObject() > > Thoughts on Implementing Object Muting: > > It seems like the straightforward approach would be something like this: > * add a flag to the LLVOVolume class (perhaps BOOL mIsVisuallyMuted or > similar) which defaults to FALSE > * in LLVOVolume::processUpdateMessage(), use the prim region, > coordinates, object id, and owner id to determine whether to flag the > object as muted or not > * if the object is muted, override the object audio and click (touch) > settings so that the viewer's version of the object doesn't play sound > or respond to touch events > * hook into LLVOVolume::updateTextures() to force the object to use > the default texture for all faces if the object is muted > * also hook into LLPrimitive::unpackTEMessage() to force any texture > updates for the object sent from the sim result in "new" textures also > being forced to be the default texture > > Note that the default texture is the static LLViewerImage* > LLViewerImage::sDefaultImagep, which uses the IMG_DEFAULT texture > LLUUID (d2114404-dd59-4a4d-8e6c-49359e91bbf0, which seems to be the > default grey texture). > > I make a quick-and-dirty hack similar to the above to the LLVOAvatar > class, which forced every avatar to have their skin and clothing > rendered with the default grey texture. It was in the process of > making this hack that I discovered that hooking updateTextures() is > not enough, and that unpackTEMessage() was also necessary. > > Open issues I haven't investigated yet: > * how to store and persist the list of filters to use to determine > which objects are muted > * how to hook into the viewer UI to enable users to mark object as > muted or unmuted > * how to determine whether a given region and coordinate, whether that > point exists within a given parcel or not > > I plan to look into how the existing muting mechanism works, to see > how feasible it would be to extend this to support visual muting of > object as well. I'm also going to look into how the viewer determines > the boundaries for parcels in a region, to see if there is a way to > quickly and efficiently check whether a point exists within a given > parcel or not, since I believe that muting object by parcel is the > most effective way to choose objects to mute. > > More Details on Object Creation: > > The viewer is notified buy the simulator of new objects to draw by a > variety of messages, most of them similar to the ObjectUpdate message > (defined in message_template.msg). These are the messages that appear > to be related to sim notifications of object that need to be drawn by > the viewer: > > * ObjectUpdate > - handled by process_object_update() in llviewermessage.cpp > * ObjectUpdateCompressed > - handled by process_compressed_object_update() in llviewermessage.cpp > * ObjectUpdateCached > - handled by process_cached_object_update() in llviewermessage.cpp > * ImprovedTerseObjectUpdate > - handled by process_terse_object_update() in llviewermessage.cpp > - essentially the same handling code as ObjectUpdateCompressed > * KillObject > > It's not entirely clear to me what what specific circumstances cause > the various ObjectUpdate messages to be generated, but for now I'm > mostly concerned with the general process for creating and updating > objects. > > Message handlers are configured by register_viewer_callbacks() in > llstartup.cpp. All of the ObjectUpdate-related messages call through > to LLViewerObjectList::processObjectUpdate() in llviewerobjectlist.cpp > with a little or no message-specific preprocessing. > > In LLViewerObjectList::processObjectUpdate(): > > * the handle for the region that the object is in is decoded > * this handled is validated against a list of regions known to the viewer > * the viewer looks up the object in its list of known objects > - the global viewer object list is an LLViewerObjectList named > gObjectList > - lookups for known objects via gObjectList->findObject() > * if the object already exists, the viewer updates its localid (which > I think is session-specific) > - the localid will also be updated if the object has moved from one > region to another > * if the object doesn't exist, the viewer creates it > > Object creation occurrs in LLViewerObjectList::createObject(), which > just does some pre-processing and calls down to the static method > LLViewerObject::createObject() in llviewerobject.cpp. Based on the > type of object specified in the ObjectUpdate message, createObject() > call constructors for one of the following classes: > > LLVOVolume, LLVOAvatar, LLVOGrass, LLVOTree, LLVOTextBubble, > LLVOClouds, LLVOSurfacePatch, LLVOSky, LLVOStars, LLVOWater, > LLVOGround, LLVOPartGroup > > All of these classes derive (eventually) from LLViewerObject, which > itself derives from LLPrimitive. Of these classes, the most > interesting one is LLBVOVolume, which is the class that encapsulates > what we generally think of as "prims". This includes all basic prim > types, plus flexi-prims and sculpted prims. Once the existing > LLViewerObject is updated, or a new one is created, > processUpdateObject() calls into > LLViewerObjectList::processUpdateCore() in llviewerobjectlist.cpp. > > The first thing processUpdateCore() does is call the instance method > processUpdateMessage() on the LLViewerObject instance returned from > LLViewerObject::createObject(). (If the object already existed, this > method is called on the existing instance of the object found via > gObjectList->findObject().) > > In the case of prim objects, the method called is > LLVOVolume::processUpdateMessage(), which immediately calls into the > base implementation on LLViewerObject::processUpdateMessage(). > > The base implmenentation of processUpdateMessage(): > > * first determines the region the object is in and its coordinates in > that region > * processes properties common to all the different > ObjectUpdate-related messages: object id, parent id, material, > attached sound, click (touch) action, scale, etc. > * processes properties specific to the different types of > ObjectUpdate-related messages > > There is rather a mess of code which handles the special cases of > ObjectUpdate messages--cached, compressed, terse, or improved terse > message types. The special cases are handled by nested switch and > if/then blocks, with a lot of magic numbers and a good deal of code > specific to more-derived LLViewerObject types. This section of code > alone is more than 1,000 lins long, and parts of it probably should be > moved into the derived implementations of processUpdateMessage(). (The > whole base implementation of this method is about 1,200 lines, so the > special-cased section is likely ripe for refactoring.) > > The derived LLVOVolume::processUpdateMessage(): > > * processes scuplted prim settings and textures > * processes animated textures > * processes prim parameters like hollow, shear, twist, taper, skew, > etc. via the static method LLVolumeMessage::unpackVolumeParams() > * updates prim textures via LLVOVolume::updateTEData() > > Finally, processUpdateCore() adds the prim to the list of active > viewer object (if the object is indeed active) and then calls the > updateTextures() method on the instance of LLViwerObject for the > object. Then the object is added to the render pipeline by calling > gPipeline.addObject(). > > > --Able > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From able.whitman at gmail.com Sun Jun 3 23:26:09 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sun Jun 3 23:26:12 2007 Subject: [sldev] Help with VWR-332 (Re: Investigating how the viewer creates object) In-Reply-To: <46636CC0.6040909@planetziggy.com> References: <7b3a84fb0706031642k8fb4831g8d4bb1d591887c15@mail.gmail.com> <46636CC0.6040909@planetziggy.com> Message-ID: <7b3a84fb0706032326t698d767agb79acdbc9c8b8b3@mail.gmail.com> In the comments for VWR-322, you mention two separate issues: the bug itself describes the behavior where selecting an object stops it from moving and snaps it to it's final rotation. This is actually the expected behavior when selecting an object. I'm pretty sure the pertinent code is in LLSelectMgr::selectObjectOnly(), in llselectmgr.cpp at line 289 (in the 1.15.0.5 release): // Stop the object from moving (this anticipates changes on the // simulator in LLTask::userSelect) // *FIX: shouldn't zero out these either object->setVelocity(LLVector3::zero); object->setAcceleration(LLVector3::zero); //object->setAngularVelocity(LLVector3::zero); object->resetRot(); There is similar code in the selectObjectAndFamily() methods, which act on the root of a linkset to stop it from moving as well. The other issue you mention is the fact that repeatedly changing the rotation of an object via a script is jerky. I'm honestly not sure exactly what might cause this, but I can try to make an educated guess: Scripts run at the sim, so whenever a script changes the rotation of an object, it sends clients that can see the object an ObjectUpdate message with the new rotation. From a cursory inspection of the code, it looks like changes to an object's scale, rotation, etc. result in a call to LLViewerObject::updateDrawable() when a viewer object processes an ObjectUpdate message. The updateDrawable() method in turn calls gPipeline.markMoved() with a flag indicating whether the movement is damped or not. I'm pretty sure that in the client source terminology "damped" is the term for the client-side effect of smoothing the transition between rotations, etc. I think the damping effect is handled in the LLDrawable::updateXform() method, but I'm not entirely sure. Remember of course, that the damped motion is a client-side effect, so if there is a noticable lag between when the script requests a rotation change, and the sim sends an ObjectUpdate, and a client processes the ObjectUpdate, the result will be a jerky motion. It's because of exactly this situation that the llSetTargetOmega() LSL function exists; this tells the client to smoothly rotate a prim at a given angular velocity, and since this is a client-side only effect, it isn't subject to the jerkiness that message lag between the sim and the client can suffer from. In other words, I'm not sure that there is a lot you can do to avoid the jerkiness of rotation changes, except to use llSetTargetOmega(). --Able On 6/3/07, Ziggy Puff wrote: > > I'd submitted VWR-332 a while back, and today I thought I'd try and > figure it out myself. Since I just downloaded the code, this description > helps a lot. VWR-332 appears to be an issue in how scripted prim > movement is rendered, specifically, the interpolation applied to > rotation and translation. If anyone has pointers on where to look, I > would really appreciate that. I found the LLVOVolume class, and > LLCriticalDamp (though that's probably used for physical movement?). > There are lerp and slerp functions in LLQuaternion, and there's > LLDrawable::updateXform which seems to calculate damping/interpolation > for translations and rotations. Right now I'm trying to figure out how > all of these fit together, and which portions I should be looking at. > > https://jira.secondlife.com/browse/VWR-332 > > Thanks, > Ziggy > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070604/34132777/attachment.htm From soft at softnoel.org Sun Jun 3 23:52:50 2007 From: soft at softnoel.org (Soft Noel) Date: Sun Jun 3 23:52:52 2007 Subject: [sldev] Re: dead code In-Reply-To: <71CD2413-8934-4717-9AF8-2895F4010974@mm.st> References: <46545C49.9080202@lindenlab.com> <4654ADE6.7000202@dzonux.net> <71CD2413-8934-4717-9AF8-2895F4010974@mm.st> Message-ID: <9e6e5c9e0706032352p53499a7cqf00f664b466ce6d7@mail.gmail.com> On 5/29/07, Ben Byer wrote: > On May 23, 2007, at 5:11 PM, Dzonatas wrote: > > > Andrew Meadows wrote: > >> Ben Byer - > >> > >> Your list undoubtedly contains lots of dead code however I > >> find some of it suspiciously alive. > > > > Compiler optimizations may have moved code from inside one function > > and stuck it in-line in another. That would give the appearance of > > dead code. The symbols are generally left inside the object file, > > but they can be removed if size optimization is desired. I see the > > default is to compile for speed over size. > > Yeah, I think this is what happened. When I get a chance, I'll try > rerunning through the same steps with -O0 for both runs -- however, > I'm not sure if dead code stripping will still happen with > optimizations turned off. I don't think the optimization level affects the linker at all, but if you want to be sure dead stripping still happens no matter what, you can pass ld the -dead-strip option. A combination of -fno-inline, -fno-inline-implicit-templates and -fno-inline-functions should make gcc avoid inlining even with O3... just be sure to specify in the right order so O3 doesn't stomp on them. :) From soft at softnoel.org Mon Jun 4 00:02:32 2007 From: soft at softnoel.org (Soft Noel) Date: Mon Jun 4 00:02:40 2007 Subject: [sldev] Debian preliminary packages In-Reply-To: <20070530093153.GA13848@keitarou> References: <20070506234827.GB18130@keitarou> <20070507092458.GA23509@keitarou> <20070530093153.GA13848@keitarou> Message-ID: <9e6e5c9e0706040002t70307522g11a46c44f2194d46@mail.gmail.com> On 5/30/07, Paul TBBle Hampson wrote: > On Mon, May 07, 2007 at 07:24:58PM +1000, Paul TBBle Hampson wrote: > > On Mon, May 07, 2007 at 09:48:27AM +1000, Paul TBBle Hampson wrote: > >> I've just posted the preliminary Debian packaging of > >> slviewer, to http://www.tbble.net/debian/ > > >> However, they don't actually work just now, due to both the > >> missing res-sdl and character directories in the 1.15.0.2 > >> release tarball, and an error I get when I try to connect, > >> "Ran off end of packet ObjectUpdate from 64.154.220.9:13004". > > > OK, fixed the packages, so they aren't missing files. ObjectUpdate > > packet underrun still happens on agni though. -_- > > Just flicking back through the SLTraffic, and noticed that there might > have been some expectation of binary uploads of these packages from > me for arches other than PowerPC. > > I've not got any other system capable of building them for upload > (or in fact, any other systems at the moment. -_-) > > The plan is to actually get these into Debian proper, so that > the Debian buildd network will actually build the other arches > for me. ^_^ In the past, Debian has not been good about accepting software that needs to change often. Even software like SpamAssassin that's usable, but which goes stale quickly, was met with resistance in the past. Given that the viewer would only remain usable for a tiny fragment of the typical Debian release cycle, would it make more sense to look at something like the pine-tracker package, which merely makes note of changes to the authoritative package elsewhere, or even the Sun JavaSDK packages which centrally install and track the contents of tarballs the user downloads to an appropriate directory? From soft at softnoel.org Mon Jun 4 01:15:58 2007 From: soft at softnoel.org (Soft Noel) Date: Mon Jun 4 01:16:00 2007 Subject: [sldev] SLDev-Traffic #14 Message-ID: <9e6e5c9e0706040115g21c2df7byc0286b06d9f43458@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_14 SLDev-Traffic number 14 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From nicholaz at blueflash.cc Mon Jun 4 06:57:43 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 4 06:58:01 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <466331B2.5000506@dzonux.net> References: <466324A5.2040908@blueflash.cc> <466331B2.5000506@dzonux.net> Message-ID: <46641A57.6000409@blueflash.cc> >> http://nicholaz-beresford.blogspot.com/2007/06/running-with-5-50-higher-frame-rates.html >> > When you benchmark these results, it is a good measure to turn off > different features. Use the Client->Rendering menu to do this. That way > you can easily see the maximum possible framerate and see how individual > features affect the framerate. > > I turned off a set of features and obtained up to 120FPS with general > optimization on. This dropped down to 70FPS with the same features off > and no optimizations. Almost a 2x speed difference kinda like that 50% > increase you saw. In this same sim location with all features on, I get > below 25 FPS with or without optimizations. I was just running around sims with all stuff enabled (I really don't want to spend much time on this as it's unlikely that anything like a major change in project settings will ever make it into the SL build), but with the FPS display enabled I often see FPS rates much higher than before as soon as downloading of textures seem to settle down. Not sure if that has any real usage impact at all, like more fluid motion when actually being in motion or walking or flying, but these compiler options seem to have at least some visible impact in isolated areas. Nick From gigstaggart at gmail.com Mon Jun 4 08:07:17 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 4 08:07:27 2007 Subject: [sldev] Contributing code you didn't write (Re: QueryPerformanceCounter() & related issues VWR-940, VWR-962, VWR975) In-Reply-To: <4663426C.6030805@lindenlab.com> References: <465E96DD.2020601@dzonux.net> <000b01c7a3eb$3fb2e840$b20b1352@tomhome> <20070602101237.GA22431@keitarou> <46615822.9040300@dzonux.net> <20070602164351.GA25053@keitarou> <4663426C.6030805@lindenlab.com> Message-ID: <46642AA5.6010406@gmail.com> Rob Lanphier wrote: > work of the U.S. Federal Government, copying without explicit and proper Also note that a whole lot of government published code is written by contractors, which is almost never public domain. Government orgs also assert trademark rights sometimes even on public domain works. -Jason From ziggy at planetziggy.com Mon Jun 4 08:22:12 2007 From: ziggy at planetziggy.com (Ziggy Puff) Date: Mon Jun 4 08:22:17 2007 Subject: [sldev] Help with VWR-332 (Re: Investigating how the viewer creates object) In-Reply-To: <7b3a84fb0706032326t698d767agb79acdbc9c8b8b3@mail.gmail.com> References: <7b3a84fb0706031642k8fb4831g8d4bb1d591887c15@mail.gmail.com> <46636CC0.6040909@planetziggy.com> <7b3a84fb0706032326t698d767agb79acdbc9c8b8b3@mail.gmail.com> Message-ID: <46642E24.40405@planetziggy.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070604/d6401242/attachment.htm From okumoto at ucsd.edu Mon Jun 4 09:08:18 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Mon Jun 4 09:08:24 2007 Subject: [sldev] Doxygen config file? Message-ID: <466438F2.3090707@ucsd.edu> Is there a doxygen config file for the viewer source code? It looks like most of the files have javadoc style file headers. I'm attaching one that I created, but if there is an official version it would be nice if was in the distribution. http://www.doxygen.org/index.html Max Okumoto -------------- next part -------------- # Doxyfile 1.5.1 # This file describes the settings to be used by the documentation system # doxygen (www.doxygen.org) for a project # # All text after a hash (#) is considered a comment and will be ignored # The format is: # TAG = value [value, ...] # For lists items can also be appended using: # TAG += value [value, ...] # Values that contain spaces should be placed between quotes (" ") #--------------------------------------------------------------------------- # Project related configuration options #--------------------------------------------------------------------------- # The PROJECT_NAME tag is a single word (or a sequence of words surrounded # by quotes) that should identify the project. PROJECT_NAME = 2ndLife # The PROJECT_NUMBER tag can be used to enter a project or revision number. # This could be handy for archiving the generated documentation or # if some version control system is used. PROJECT_NUMBER = # The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) # base path where the generated documentation will be put. # If a relative path is entered, it will be relative to the location # where doxygen was started. If left blank the current directory will be used. OUTPUT_DIRECTORY = # If the CREATE_SUBDIRS tag is set to YES, then doxygen will create # 4096 sub-directories (in 2 levels) under the output directory of each output # format and will distribute the generated files over these directories. # Enabling this option can be useful when feeding doxygen a huge amount of # source files, where putting all generated files in the same directory would # otherwise cause performance problems for the file system. CREATE_SUBDIRS = NO # The OUTPUT_LANGUAGE tag is used to specify the language in which all # documentation generated by doxygen is written. Doxygen will use this # information to generate all constant output in the proper language. # The default language is English, other supported languages are: # Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional, # Croatian, Czech, Danish, Dutch, Finnish, French, German, Greek, Hungarian, # Italian, Japanese, Japanese-en (Japanese with English messages), Korean, # Korean-en, Lithuanian, Norwegian, Polish, Portuguese, Romanian, Russian, # Serbian, Slovak, Slovene, Spanish, Swedish, and Ukrainian. OUTPUT_LANGUAGE = English # This tag can be used to specify the encoding used in the generated output. # The encoding is not always determined by the language that is chosen, # but also whether or not the output is meant for Windows or non-Windows users. # In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES # forces the Windows encoding (this is the default for the Windows binary), # whereas setting the tag to NO uses a Unix-style encoding (the default for # all platforms other than Windows). USE_WINDOWS_ENCODING = NO # If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will # include brief member descriptions after the members that are listed in # the file and class documentation (similar to JavaDoc). # Set to NO to disable this. BRIEF_MEMBER_DESC = YES # If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend # the brief description of a member or function before the detailed description. # Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the # brief descriptions will be completely suppressed. REPEAT_BRIEF = YES # This tag implements a quasi-intelligent brief description abbreviator # that is used to form the text in various listings. Each string # in this list, if found as the leading text of the brief description, will be # stripped from the text and the result after processing the whole list, is # used as the annotated text. Otherwise, the brief description is used as-is. # If left blank, the following values are used ("$name" is automatically # replaced with the name of the entity): "The $name class" "The $name widget" # "The $name file" "is" "provides" "specifies" "contains" # "represents" "a" "an" "the" ABBREVIATE_BRIEF = # If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then # Doxygen will generate a detailed section even if there is only a brief # description. ALWAYS_DETAILED_SEC = NO # If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all # inherited members of a class in the documentation of that class as if those # members were ordinary class members. Constructors, destructors and assignment # operators of the base classes will not be shown. INLINE_INHERITED_MEMB = NO # If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full # path before files name in the file list and in the header files. If set # to NO the shortest path that makes the file name unique will be used. FULL_PATH_NAMES = YES # If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag # can be used to strip a user-defined part of the path. Stripping is # only done if one of the specified strings matches the left-hand part of # the path. The tag can be used to show relative paths in the file list. # If left blank the directory from which doxygen is run is used as the # path to strip. STRIP_FROM_PATH = # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of # the path mentioned in the documentation of a class, which tells # the reader which header file to include in order to use a class. # If left blank only the name of the header file containing the class # definition is used. Otherwise one should specify the include paths that # are normally passed to the compiler using the -I flag. STRIP_FROM_INC_PATH = # If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter # (but less readable) file names. This can be useful is your file systems # doesn't support long names like on DOS, Mac, or CD-ROM. SHORT_NAMES = NO # If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen # will interpret the first line (until the first dot) of a JavaDoc-style # comment as the brief description. If set to NO, the JavaDoc # comments will behave just like the Qt-style comments (thus requiring an # explicit @brief command for a brief description. JAVADOC_AUTOBRIEF = NO # The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen # treat a multi-line C++ special comment block (i.e. a block of //! or /// # comments) as a brief description. This used to be the default behaviour. # The new default is to treat a multi-line C++ comment block as a detailed # description. Set this tag to YES if you prefer the old behaviour instead. MULTILINE_CPP_IS_BRIEF = NO # If the DETAILS_AT_TOP tag is set to YES then Doxygen # will output the detailed description near the top, like JavaDoc. # If set to NO, the detailed description appears after the member # documentation. DETAILS_AT_TOP = NO # If the INHERIT_DOCS tag is set to YES (the default) then an undocumented # member inherits the documentation from any documented member that it # re-implements. INHERIT_DOCS = YES # If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce # a new page for each member. If set to NO, the documentation of a member will # be part of the file/class/namespace that contains it. SEPARATE_MEMBER_PAGES = NO # The TAB_SIZE tag can be used to set the number of spaces in a tab. # Doxygen uses this value to replace tabs by spaces in code fragments. TAB_SIZE = 8 # This tag can be used to specify a number of aliases that acts # as commands in the documentation. An alias has the form "name=value". # For example adding "sideeffect=\par Side Effects:\n" will allow you to # put the command \sideeffect (or @sideeffect) in the documentation, which # will result in a user-defined paragraph with heading "Side Effects:". # You can put \n's in the value part of an alias to insert newlines. ALIASES = # Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C # sources only. Doxygen will then generate output that is more tailored for C. # For instance, some of the names that are used will be different. The list # of all members will be omitted, etc. OPTIMIZE_OUTPUT_FOR_C = NO # Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java # sources only. Doxygen will then generate output that is more tailored for Java. # For instance, namespaces will be presented as packages, qualified scopes # will look different, etc. OPTIMIZE_OUTPUT_JAVA = NO # If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to # include (a tag file for) the STL sources as input, then you should # set this tag to YES in order to let doxygen match functions declarations and # definitions whose arguments contain STL classes (e.g. func(std::string); v.s. # func(std::string) {}). This also make the inheritance and collaboration # diagrams that involve STL classes more complete and accurate. BUILTIN_STL_SUPPORT = YES # If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC # tag is set to YES, then doxygen will reuse the documentation of the first # member in the group (if any) for the other members of the group. By default # all members of a group must be documented explicitly. DISTRIBUTE_GROUP_DOC = NO # Set the SUBGROUPING tag to YES (the default) to allow class member groups of # the same type (for instance a group of public functions) to be put as a # subgroup of that type (e.g. under the Public Functions section). Set it to # NO to prevent subgrouping. Alternatively, this can be done per class using # the \nosubgrouping command. SUBGROUPING = YES #--------------------------------------------------------------------------- # Build related configuration options #--------------------------------------------------------------------------- # If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in # documentation are documented, even if no documentation was available. # Private class members and static file members will be hidden unless # the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES EXTRACT_ALL = NO # If the EXTRACT_PRIVATE tag is set to YES all private members of a class # will be included in the documentation. EXTRACT_PRIVATE = NO # If the EXTRACT_STATIC tag is set to YES all static members of a file # will be included in the documentation. EXTRACT_STATIC = NO # If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) # defined locally in source files will be included in the documentation. # If set to NO only classes defined in header files are included. EXTRACT_LOCAL_CLASSES = YES # This flag is only useful for Objective-C code. When set to YES local # methods, which are defined in the implementation section but not in # the interface are included in the documentation. # If set to NO (the default) only methods in the interface are included. EXTRACT_LOCAL_METHODS = NO # If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all # undocumented members of documented classes, files or namespaces. # If set to NO (the default) these members will be included in the # various overviews, but no documentation section is generated. # This option has no effect if EXTRACT_ALL is enabled. HIDE_UNDOC_MEMBERS = NO # If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all # undocumented classes that are normally visible in the class hierarchy. # If set to NO (the default) these classes will be included in the various # overviews. This option has no effect if EXTRACT_ALL is enabled. HIDE_UNDOC_CLASSES = NO # If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all # friend (class|struct|union) declarations. # If set to NO (the default) these declarations will be included in the # documentation. HIDE_FRIEND_COMPOUNDS = NO # If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any # documentation blocks found inside the body of a function. # If set to NO (the default) these blocks will be appended to the # function's detailed documentation block. HIDE_IN_BODY_DOCS = NO # The INTERNAL_DOCS tag determines if documentation # that is typed after a \internal command is included. If the tag is set # to NO (the default) then the documentation will be excluded. # Set it to YES to include the internal documentation. INTERNAL_DOCS = NO # If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate # file names in lower-case letters. If set to YES upper-case letters are also # allowed. This is useful if you have classes or files whose names only differ # in case and if your file system supports case sensitive file names. Windows # and Mac users are advised to set this option to NO. CASE_SENSE_NAMES = YES # If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen # will show members with their full class and namespace scopes in the # documentation. If set to YES the scope will be hidden. HIDE_SCOPE_NAMES = NO # If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen # will put a list of the files that are included by a file in the documentation # of that file. SHOW_INCLUDE_FILES = YES # If the INLINE_INFO tag is set to YES (the default) then a tag [inline] # is inserted in the documentation for inline members. INLINE_INFO = YES # If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen # will sort the (detailed) documentation of file and class members # alphabetically by member name. If set to NO the members will appear in # declaration order. SORT_MEMBER_DOCS = YES # If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the # brief documentation of file, namespace and class members alphabetically # by member name. If set to NO (the default) the members will appear in # declaration order. SORT_BRIEF_DOCS = NO # If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be # sorted by fully-qualified names, including namespaces. If set to # NO (the default), the class list will be sorted only by class name, # not including the namespace part. # Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. # Note: This option applies only to the class list, not to the # alphabetical list. SORT_BY_SCOPE_NAME = NO # The GENERATE_TODOLIST tag can be used to enable (YES) or # disable (NO) the todo list. This list is created by putting \todo # commands in the documentation. GENERATE_TODOLIST = YES # The GENERATE_TESTLIST tag can be used to enable (YES) or # disable (NO) the test list. This list is created by putting \test # commands in the documentation. GENERATE_TESTLIST = YES # The GENERATE_BUGLIST tag can be used to enable (YES) or # disable (NO) the bug list. This list is created by putting \bug # commands in the documentation. GENERATE_BUGLIST = YES # The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or # disable (NO) the deprecated list. This list is created by putting # \deprecated commands in the documentation. GENERATE_DEPRECATEDLIST= YES # The ENABLED_SECTIONS tag can be used to enable conditional # documentation sections, marked by \if sectionname ... \endif. ENABLED_SECTIONS = # The MAX_INITIALIZER_LINES tag determines the maximum number of lines # the initial value of a variable or define consists of for it to appear in # the documentation. If the initializer consists of more lines than specified # here it will be hidden. Use a value of 0 to hide initializers completely. # The appearance of the initializer of individual variables and defines in the # documentation can be controlled using \showinitializer or \hideinitializer # command in the documentation regardless of this setting. MAX_INITIALIZER_LINES = 30 # Set the SHOW_USED_FILES tag to NO to disable the list of files generated # at the bottom of the documentation of classes and structs. If set to YES the # list will mention the files that were used to generate the documentation. SHOW_USED_FILES = YES # If the sources in your project are distributed over multiple directories # then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy # in the documentation. The default is NO. SHOW_DIRECTORIES = YES # The FILE_VERSION_FILTER tag can be used to specify a program or script that # doxygen should invoke to get the current version for each file (typically from the # version control system). Doxygen will invoke the program by executing (via # popen()) the command , where is the value of # the FILE_VERSION_FILTER tag, and is the name of an input file # provided by doxygen. Whatever the program writes to standard output # is used as the file version. See the manual for examples. FILE_VERSION_FILTER = #--------------------------------------------------------------------------- # configuration options related to warning and progress messages #--------------------------------------------------------------------------- # The QUIET tag can be used to turn on/off the messages that are generated # by doxygen. Possible values are YES and NO. If left blank NO is used. QUIET = NO # The WARNINGS tag can be used to turn on/off the warning messages that are # generated by doxygen. Possible values are YES and NO. If left blank # NO is used. WARNINGS = YES # If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings # for undocumented members. If EXTRACT_ALL is set to YES then this flag will # automatically be disabled. WARN_IF_UNDOCUMENTED = YES # If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for # potential errors in the documentation, such as not documenting some # parameters in a documented function, or documenting parameters that # don't exist or using markup commands wrongly. WARN_IF_DOC_ERROR = YES # This WARN_NO_PARAMDOC option can be abled to get warnings for # functions that are documented, but have no documentation for their parameters # or return value. If set to NO (the default) doxygen will only warn about # wrong or incomplete parameter documentation, but not about the absence of # documentation. WARN_NO_PARAMDOC = NO # The WARN_FORMAT tag determines the format of the warning messages that # doxygen can produce. The string should contain the $file, $line, and $text # tags, which will be replaced by the file and line number from which the # warning originated and the warning text. Optionally the format may contain # $version, which will be replaced by the version of the file (if it could # be obtained via FILE_VERSION_FILTER) WARN_FORMAT = "$file:$line: $text" # The WARN_LOGFILE tag can be used to specify a file to which warning # and error messages should be written. If left blank the output is written # to stderr. WARN_LOGFILE = #--------------------------------------------------------------------------- # configuration options related to the input files #--------------------------------------------------------------------------- # The INPUT tag can be used to specify the files and/or directories that contain # documented source files. You may enter file names like "myfile.cpp" or # directories like "/usr/src/myproject". Separate the files or directories # with spaces. INPUT = \ lib \ linux_crash_logger \ llaudio \ llcharacter \ llcommon \ llimage \ llimagej2coj \ llinventory \ llmath \ llmedia \ llmessage \ llprimitive \ llrender \ llui \ llvfs \ llwindow \ llxml \ lscript \ newview # If the value of the INPUT tag contains directories, you can use the # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp # and *.h) to filter out the source-files in the directories. If left # blank the following patterns are tested: # *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx # *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py FILE_PATTERNS = # The RECURSIVE tag can be used to turn specify whether or not subdirectories # should be searched for input files as well. Possible values are YES and NO. # If left blank NO is used. RECURSIVE = NO # The EXCLUDE tag can be used to specify files and/or directories that should # excluded from the INPUT source files. This way you can easily exclude a # subdirectory from a directory tree whose root is specified with the INPUT tag. EXCLUDE = # The EXCLUDE_SYMLINKS tag can be used select whether or not files or # directories that are symbolic links (a Unix filesystem feature) are excluded # from the input. EXCLUDE_SYMLINKS = NO # If the value of the INPUT tag contains directories, you can use the # EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude # certain files from those directories. Note that the wildcards are matched # against the file with absolute path, so to exclude all test directories # for example use the pattern */test/* EXCLUDE_PATTERNS = # The EXAMPLE_PATH tag can be used to specify one or more files or # directories that contain example code fragments that are included (see # the \include command). EXAMPLE_PATH = # If the value of the EXAMPLE_PATH tag contains directories, you can use the # EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp # and *.h) to filter out the source-files in the directories. If left # blank all files are included. EXAMPLE_PATTERNS = # If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be # searched for input files to be used with the \include or \dontinclude # commands irrespective of the value of the RECURSIVE tag. # Possible values are YES and NO. If left blank NO is used. EXAMPLE_RECURSIVE = NO # The IMAGE_PATH tag can be used to specify one or more files or # directories that contain image that are included in the documentation (see # the \image command). IMAGE_PATH = # The INPUT_FILTER tag can be used to specify a program that doxygen should # invoke to filter for each input file. Doxygen will invoke the filter program # by executing (via popen()) the command , where # is the value of the INPUT_FILTER tag, and is the name of an # input file. Doxygen will then use the output that the filter program writes # to standard output. If FILTER_PATTERNS is specified, this tag will be # ignored. INPUT_FILTER = # The FILTER_PATTERNS tag can be used to specify filters on a per file pattern # basis. Doxygen will compare the file name with each pattern and apply the # filter if there is a match. The filters are a list of the form: # pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further # info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER # is applied to all files. FILTER_PATTERNS = # If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using # INPUT_FILTER) will be used to filter the input files when producing source # files to browse (i.e. when SOURCE_BROWSER is set to YES). FILTER_SOURCE_FILES = NO #--------------------------------------------------------------------------- # configuration options related to source browsing #--------------------------------------------------------------------------- # If the SOURCE_BROWSER tag is set to YES then a list of source files will # be generated. Documented entities will be cross-referenced with these sources. # Note: To get rid of all source code in the generated output, make sure also # VERBATIM_HEADERS is set to NO. SOURCE_BROWSER = YES # Setting the INLINE_SOURCES tag to YES will include the body # of functions and classes directly in the documentation. INLINE_SOURCES = YES # Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct # doxygen to hide any special comment blocks from generated source code # fragments. Normal C and C++ comments will always remain visible. STRIP_CODE_COMMENTS = NO # If the REFERENCED_BY_RELATION tag is set to YES (the default) # then for each documented function all documented # functions referencing it will be listed. REFERENCED_BY_RELATION = YES # If the REFERENCES_RELATION tag is set to YES (the default) # then for each documented function all documented entities # called/used by that function will be listed. REFERENCES_RELATION = YES # If the REFERENCES_LINK_SOURCE tag is set to YES (the default) # and SOURCE_BROWSER tag is set to YES, then the hyperlinks from # functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will # link to the source code. Otherwise they will link to the documentstion. REFERENCES_LINK_SOURCE = YES # If the USE_HTAGS tag is set to YES then the references to source code # will point to the HTML generated by the htags(1) tool instead of doxygen # built-in source browser. The htags tool is part of GNU's global source # tagging system (see http://www.gnu.org/software/global/global.html). You # will need version 4.8.6 or higher. USE_HTAGS = NO # If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen # will generate a verbatim copy of the header file for each class for # which an include is specified. Set to NO to disable this. VERBATIM_HEADERS = YES #--------------------------------------------------------------------------- # configuration options related to the alphabetical class index #--------------------------------------------------------------------------- # If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index # of all compounds will be generated. Enable this if the project # contains a lot of classes, structs, unions or interfaces. ALPHABETICAL_INDEX = NO # If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then # the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns # in which this list will be split (can be a number in the range [1..20]) COLS_IN_ALPHA_INDEX = 5 # In case all classes in a project start with a common prefix, all # classes will be put under the same header in the alphabetical index. # The IGNORE_PREFIX tag can be used to specify one or more prefixes that # should be ignored while generating the index headers. IGNORE_PREFIX = #--------------------------------------------------------------------------- # configuration options related to the HTML output #--------------------------------------------------------------------------- # If the GENERATE_HTML tag is set to YES (the default) Doxygen will # generate HTML output. GENERATE_HTML = YES # The HTML_OUTPUT tag is used to specify where the HTML docs will be put. # If a relative path is entered the value of OUTPUT_DIRECTORY will be # put in front of it. If left blank `html' will be used as the default path. HTML_OUTPUT = html # The HTML_FILE_EXTENSION tag can be used to specify the file extension for # each generated HTML page (for example: .htm,.php,.asp). If it is left blank # doxygen will generate files with .html extension. HTML_FILE_EXTENSION = .html # The HTML_HEADER tag can be used to specify a personal HTML header for # each generated HTML page. If it is left blank doxygen will generate a # standard header. HTML_HEADER = # The HTML_FOOTER tag can be used to specify a personal HTML footer for # each generated HTML page. If it is left blank doxygen will generate a # standard footer. HTML_FOOTER = # The HTML_STYLESHEET tag can be used to specify a user-defined cascading # style sheet that is used by each HTML page. It can be used to # fine-tune the look of the HTML output. If the tag is left blank doxygen # will generate a default style sheet. Note that doxygen will try to copy # the style sheet file to the HTML output directory, so don't put your own # stylesheet in the HTML output directory as well, or it will be erased! HTML_STYLESHEET = # If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, # files or namespaces will be aligned in HTML using tables. If set to # NO a bullet list will be used. HTML_ALIGN_MEMBERS = YES # If the GENERATE_HTMLHELP tag is set to YES, additional index files # will be generated that can be used as input for tools like the # Microsoft HTML help workshop to generate a compressed HTML help file (.chm) # of the generated HTML documentation. GENERATE_HTMLHELP = NO # If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can # be used to specify the file name of the resulting .chm file. You # can add a path in front of the file if the result should not be # written to the html output directory. CHM_FILE = # If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can # be used to specify the location (absolute path including file name) of # the HTML help compiler (hhc.exe). If non-empty doxygen will try to run # the HTML help compiler on the generated index.hhp. HHC_LOCATION = # If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag # controls if a separate .chi index file is generated (YES) or that # it should be included in the master .chm file (NO). GENERATE_CHI = NO # If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag # controls whether a binary table of contents is generated (YES) or a # normal table of contents (NO) in the .chm file. BINARY_TOC = NO # The TOC_EXPAND flag can be set to YES to add extra items for group members # to the contents of the HTML help documentation and to the tree view. TOC_EXPAND = NO # The DISABLE_INDEX tag can be used to turn on/off the condensed index at # top of each HTML page. The value NO (the default) enables the index and # the value YES disables it. DISABLE_INDEX = NO # This tag can be used to set the number of enum values (range [1..20]) # that doxygen will group on one line in the generated HTML documentation. ENUM_VALUES_PER_LINE = 4 # If the GENERATE_TREEVIEW tag is set to YES, a side panel will be # generated containing a tree-like index structure (just like the one that # is generated for HTML Help). For this to work a browser that supports # JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+, # Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are # probably better off using the HTML help feature. GENERATE_TREEVIEW = NO # If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be # used to set the initial width (in pixels) of the frame in which the tree # is shown. TREEVIEW_WIDTH = 250 #--------------------------------------------------------------------------- # configuration options related to the LaTeX output #--------------------------------------------------------------------------- # If the GENERATE_LATEX tag is set to YES (the default) Doxygen will # generate Latex output. GENERATE_LATEX = YES # The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. # If a relative path is entered the value of OUTPUT_DIRECTORY will be # put in front of it. If left blank `latex' will be used as the default path. LATEX_OUTPUT = latex # The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be # invoked. If left blank `latex' will be used as the default command name. LATEX_CMD_NAME = latex # The MAKEINDEX_CMD_NAME tag can be used to specify the command name to # generate index for LaTeX. If left blank `makeindex' will be used as the # default command name. MAKEINDEX_CMD_NAME = makeindex # If the COMPACT_LATEX tag is set to YES Doxygen generates more compact # LaTeX documents. This may be useful for small projects and may help to # save some trees in general. COMPACT_LATEX = NO # The PAPER_TYPE tag can be used to set the paper type that is used # by the printer. Possible values are: a4, a4wide, letter, legal and # executive. If left blank a4wide will be used. PAPER_TYPE = a4wide # The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX # packages that should be included in the LaTeX output. EXTRA_PACKAGES = # The LATEX_HEADER tag can be used to specify a personal LaTeX header for # the generated latex document. The header should contain everything until # the first chapter. If it is left blank doxygen will generate a # standard header. Notice: only use this tag if you know what you are doing! LATEX_HEADER = # If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated # is prepared for conversion to pdf (using ps2pdf). The pdf file will # contain links (just like the HTML output) instead of page references # This makes the output suitable for online browsing using a pdf viewer. PDF_HYPERLINKS = NO # If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of # plain latex in the generated Makefile. Set this option to YES to get a # higher quality PDF documentation. USE_PDFLATEX = NO # If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. # command to the generated LaTeX files. This will instruct LaTeX to keep # running if errors occur, instead of asking the user for help. # This option is also used when generating formulas in HTML. LATEX_BATCHMODE = NO # If LATEX_HIDE_INDICES is set to YES then doxygen will not # include the index chapters (such as File Index, Compound Index, etc.) # in the output. LATEX_HIDE_INDICES = NO #--------------------------------------------------------------------------- # configuration options related to the RTF output #--------------------------------------------------------------------------- # If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output # The RTF output is optimized for Word 97 and may not look very pretty with # other RTF readers or editors. GENERATE_RTF = NO # The RTF_OUTPUT tag is used to specify where the RTF docs will be put. # If a relative path is entered the value of OUTPUT_DIRECTORY will be # put in front of it. If left blank `rtf' will be used as the default path. RTF_OUTPUT = rtf # If the COMPACT_RTF tag is set to YES Doxygen generates more compact # RTF documents. This may be useful for small projects and may help to # save some trees in general. COMPACT_RTF = NO # If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated # will contain hyperlink fields. The RTF file will # contain links (just like the HTML output) instead of page references. # This makes the output suitable for online browsing using WORD or other # programs which support those fields. # Note: wordpad (write) and others do not support links. RTF_HYPERLINKS = NO # Load stylesheet definitions from file. Syntax is similar to doxygen's # config file, i.e. a series of assignments. You only have to provide # replacements, missing definitions are set to their default value. RTF_STYLESHEET_FILE = # Set optional variables used in the generation of an rtf document. # Syntax is similar to doxygen's config file. RTF_EXTENSIONS_FILE = #--------------------------------------------------------------------------- # configuration options related to the man page output #--------------------------------------------------------------------------- # If the GENERATE_MAN tag is set to YES (the default) Doxygen will # generate man pages GENERATE_MAN = NO # The MAN_OUTPUT tag is used to specify where the man pages will be put. # If a relative path is entered the value of OUTPUT_DIRECTORY will be # put in front of it. If left blank `man' will be used as the default path. MAN_OUTPUT = man # The MAN_EXTENSION tag determines the extension that is added to # the generated man pages (default is the subroutine's section .3) MAN_EXTENSION = .3 # If the MAN_LINKS tag is set to YES and Doxygen generates man output, # then it will generate one additional man file for each entity # documented in the real man page(s). These additional files # only source the real man page, but without them the man command # would be unable to find the correct page. The default is NO. MAN_LINKS = NO #--------------------------------------------------------------------------- # configuration options related to the XML output #--------------------------------------------------------------------------- # If the GENERATE_XML tag is set to YES Doxygen will # generate an XML file that captures the structure of # the code including all documentation. GENERATE_XML = NO # The XML_OUTPUT tag is used to specify where the XML pages will be put. # If a relative path is entered the value of OUTPUT_DIRECTORY will be # put in front of it. If left blank `xml' will be used as the default path. XML_OUTPUT = xml # The XML_SCHEMA tag can be used to specify an XML schema, # which can be used by a validating XML parser to check the # syntax of the XML files. XML_SCHEMA = # The XML_DTD tag can be used to specify an XML DTD, # which can be used by a validating XML parser to check the # syntax of the XML files. XML_DTD = # If the XML_PROGRAMLISTING tag is set to YES Doxygen will # dump the program listings (including syntax highlighting # and cross-referencing information) to the XML output. Note that # enabling this will significantly increase the size of the XML output. XML_PROGRAMLISTING = YES #--------------------------------------------------------------------------- # configuration options for the AutoGen Definitions output #--------------------------------------------------------------------------- # If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will # generate an AutoGen Definitions (see autogen.sf.net) file # that captures the structure of the code including all # documentation. Note that this feature is still experimental # and incomplete at the moment. GENERATE_AUTOGEN_DEF = NO #--------------------------------------------------------------------------- # configuration options related to the Perl module output #--------------------------------------------------------------------------- # If the GENERATE_PERLMOD tag is set to YES Doxygen will # generate a Perl module file that captures the structure of # the code including all documentation. Note that this # feature is still experimental and incomplete at the # moment. GENERATE_PERLMOD = NO # If the PERLMOD_LATEX tag is set to YES Doxygen will generate # the necessary Makefile rules, Perl scripts and LaTeX code to be able # to generate PDF and DVI output from the Perl module output. PERLMOD_LATEX = NO # If the PERLMOD_PRETTY tag is set to YES the Perl module output will be # nicely formatted so it can be parsed by a human reader. This is useful # if you want to understand what is going on. On the other hand, if this # tag is set to NO the size of the Perl module output will be much smaller # and Perl will parse it just the same. PERLMOD_PRETTY = YES # The names of the make variables in the generated doxyrules.make file # are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. # This is useful so different doxyrules.make files included by the same # Makefile don't overwrite each other's variables. PERLMOD_MAKEVAR_PREFIX = #--------------------------------------------------------------------------- # Configuration options related to the preprocessor #--------------------------------------------------------------------------- # If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will # evaluate all C-preprocessor directives found in the sources and include # files. ENABLE_PREPROCESSING = YES # If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro # names in the source code. If set to NO (the default) only conditional # compilation will be performed. Macro expansion can be done in a controlled # way by setting EXPAND_ONLY_PREDEF to YES. MACRO_EXPANSION = NO # If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES # then the macro expansion is limited to the macros specified with the # PREDEFINED and EXPAND_AS_DEFINED tags. EXPAND_ONLY_PREDEF = NO # If the SEARCH_INCLUDES tag is set to YES (the default) the includes files # in the INCLUDE_PATH (see below) will be search if a #include is found. SEARCH_INCLUDES = YES # The INCLUDE_PATH tag can be used to specify one or more directories that # contain include files that are not input files but should be processed by # the preprocessor. INCLUDE_PATH = # You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard # patterns (like *.h and *.hpp) to filter out the header-files in the # directories. If left blank, the patterns specified with FILE_PATTERNS will # be used. INCLUDE_FILE_PATTERNS = # The PREDEFINED tag can be used to specify one or more macro names that # are defined before the preprocessor is started (similar to the -D option of # gcc). The argument of the tag is a list of macros of the form: name # or name=definition (no spaces). If the definition and the = are # omitted =1 is assumed. To prevent a macro definition from being # undefined via #undef or recursively expanded use the := operator # instead of the = operator. PREDEFINED = # If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then # this tag can be used to specify a list of macro names that should be expanded. # The macro definition that is found in the sources will be used. # Use the PREDEFINED tag if you want to use a different macro definition. EXPAND_AS_DEFINED = # If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then # doxygen's preprocessor will remove all function-like macros that are alone # on a line, have an all uppercase name, and do not end with a semicolon. Such # function macros are typically used for boiler-plate code, and will confuse # the parser if not removed. SKIP_FUNCTION_MACROS = YES #--------------------------------------------------------------------------- # Configuration::additions related to external references #--------------------------------------------------------------------------- # The TAGFILES option can be used to specify one or more tagfiles. # Optionally an initial location of the external documentation # can be added for each tagfile. The format of a tag file without # this location is as follows: # TAGFILES = file1 file2 ... # Adding location for the tag files is done as follows: # TAGFILES = file1=loc1 "file2 = loc2" ... # where "loc1" and "loc2" can be relative or absolute paths or # URLs. If a location is present for each tag, the installdox tool # does not have to be run to correct the links. # Note that each tag file must have a unique name # (where the name does NOT include the path) # If a tag file is not located in the directory in which doxygen # is run, you must also specify the path to the tagfile here. TAGFILES = # When a file name is specified after GENERATE_TAGFILE, doxygen will create # a tag file that is based on the input files it reads. GENERATE_TAGFILE = # If the ALLEXTERNALS tag is set to YES all external classes will be listed # in the class index. If set to NO only the inherited external classes # will be listed. ALLEXTERNALS = NO # If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed # in the modules index. If set to NO, only the current project's groups will # be listed. EXTERNAL_GROUPS = YES # The PERL_PATH should be the absolute path and name of the perl script # interpreter (i.e. the result of `which perl'). PERL_PATH = /usr/bin/perl #--------------------------------------------------------------------------- # Configuration options related to the dot tool #--------------------------------------------------------------------------- # If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will # generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base # or super classes. Setting the tag to NO turns the diagrams off. Note that # this option is superseded by the HAVE_DOT option below. This is only a # fallback. It is recommended to install and use dot, since it yields more # powerful graphs. CLASS_DIAGRAMS = YES # If set to YES, the inheritance and collaboration graphs will hide # inheritance and usage relations if the target is undocumented # or is not a class. HIDE_UNDOC_RELATIONS = YES # If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is # available from the path. This tool is part of Graphviz, a graph visualization # toolkit from AT&T and Lucent Bell Labs. The other options in this section # have no effect if this option is set to NO (the default) HAVE_DOT = NO # If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen # will generate a graph for each documented class showing the direct and # indirect inheritance relations. Setting this tag to YES will force the # the CLASS_DIAGRAMS tag to NO. CLASS_GRAPH = YES # If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen # will generate a graph for each documented class showing the direct and # indirect implementation dependencies (inheritance, containment, and # class references variables) of the class with other documented classes. COLLABORATION_GRAPH = YES # If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen # will generate a graph for groups, showing the direct groups dependencies GROUP_GRAPHS = YES # If the UML_LOOK tag is set to YES doxygen will generate inheritance and # collaboration diagrams in a style similar to the OMG's Unified Modeling # Language. UML_LOOK = NO # If set to YES, the inheritance and collaboration graphs will show the # relations between templates and their instances. TEMPLATE_RELATIONS = NO # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT # tags are set to YES then doxygen will generate a graph for each documented # file showing the direct and indirect include dependencies of the file with # other documented files. INCLUDE_GRAPH = YES # If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and # HAVE_DOT tags are set to YES then doxygen will generate a graph for each # documented header file showing the documented files that directly or # indirectly include this file. INCLUDED_BY_GRAPH = YES # If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will # generate a call dependency graph for every global function or class method. # Note that enabling this option will significantly increase the time of a run. # So in most cases it will be better to enable call graphs for selected # functions only using the \callgraph command. CALL_GRAPH = NO # If the CALLER_GRAPH and HAVE_DOT tags are set to YES then doxygen will # generate a caller dependency graph for every global function or class method. # Note that enabling this option will significantly increase the time of a run. # So in most cases it will be better to enable caller graphs for selected # functions only using the \callergraph command. CALLER_GRAPH = NO # If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen # will graphical hierarchy of all classes instead of a textual one. GRAPHICAL_HIERARCHY = YES # If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES # then doxygen will show the dependencies a directory has on other directories # in a graphical way. The dependency relations are determined by the #include # relations between the files in the directories. DIRECTORY_GRAPH = YES # The DOT_IMAGE_FORMAT tag can be used to set the image format of the images # generated by dot. Possible values are png, jpg, or gif # If left blank png will be used. DOT_IMAGE_FORMAT = png # The tag DOT_PATH can be used to specify the path where the dot tool can be # found. If left blank, it is assumed the dot tool can be found in the path. DOT_PATH = # The DOTFILE_DIRS tag can be used to specify one or more directories that # contain dot files that are included in the documentation (see the # \dotfile command). DOTFILE_DIRS = # The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width # (in pixels) of the graphs generated by dot. If a graph becomes larger than # this value, doxygen will try to truncate the graph, so that it fits within # the specified constraint. Beware that most browsers cannot cope with very # large images. MAX_DOT_GRAPH_WIDTH = 1024 # The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height # (in pixels) of the graphs generated by dot. If a graph becomes larger than # this value, doxygen will try to truncate the graph, so that it fits within # the specified constraint. Beware that most browsers cannot cope with very # large images. MAX_DOT_GRAPH_HEIGHT = 1024 # The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the # graphs generated by dot. A depth value of 3 means that only nodes reachable # from the root by following a path via at most 3 edges will be shown. Nodes # that lay further from the root node will be omitted. Note that setting this # option to 1 or 2 may greatly reduce the computation time needed for large # code bases. Also note that a graph may be further truncated if the graph's # image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH # and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default), # the graph is not depth-constrained. MAX_DOT_GRAPH_DEPTH = 0 # Set the DOT_TRANSPARENT tag to YES to generate images with a transparent # background. This is disabled by default, which results in a white background. # Warning: Depending on the platform used, enabling this option may lead to # badly anti-aliased labels on the edges of a graph (i.e. they become hard to # read). DOT_TRANSPARENT = NO # Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output # files in one run (i.e. multiple -o and -T options on the command line). This # makes dot run faster, but since only newer versions of dot (>1.8.10) # support this, this feature is disabled by default. DOT_MULTI_TARGETS = NO # If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will # generate a legend page explaining the meaning of the various boxes and # arrows in the dot generated graphs. GENERATE_LEGEND = YES # If the DOT_CLEANUP tag is set to YES (the default) Doxygen will # remove the intermediate dot files that are used to generate # the various graphs. DOT_CLEANUP = YES #--------------------------------------------------------------------------- # Configuration::additions related to the search engine #--------------------------------------------------------------------------- # The SEARCHENGINE tag specifies whether or not a search engine should be # used. If set to NO the values of all tags below this one will be ignored. SEARCHENGINE = NO From okumoto at ucsd.edu Mon Jun 4 14:01:46 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Mon Jun 4 14:01:52 2007 Subject: [sldev] There are a few files in the 1.16.0.5 src dist without Copyright text Message-ID: <46647DBA.4030505@ucsd.edu> Is there any interest in patches to add the missing Linden labs copyright? The list of files follows: linden/indra/llmessage/llmessagebuilder.h linden/indra/llmessage/llmessagereader.cpp linden/indra/llmessage/llmessagereader.h linden/indra/llmessage/llmessagetemplate.cpp linden/indra/llmessage/llmessagetemplate.h linden/indra/llmessage/llmsgvariabletype.h linden/indra/llmessage/llsdmessagebuilder.cpp linden/indra/llmessage/llsdmessagebuilder.h linden/indra/llmessage/llsdmessagereader.cpp linden/indra/llmessage/llsdmessagereader.h linden/indra/llmessage/lltemplatemessagebuilder.cpp linden/indra/llmessage/lltemplatemessagebuilder.h linden/indra/llmessage/lltemplatemessagereader.cpp linden/indra/llmessage/lltemplatemessagereader.h linden/indra/llrender/llvertexbuffer.cpp linden/indra/llrender/llvertexbuffer.h linden/indra/newview/llassetuploadresponders.cpp linden/indra/newview/llassetuploadresponders.h linden/indra/newview/llfloaterinspect.cpp linden/indra/test/llsdtraits.h From rdw at lindenlab.com Mon Jun 4 14:44:11 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Mon Jun 4 14:44:12 2007 Subject: [sldev] Re: Patch to make View Admin Options sticky. In-Reply-To: References: <20070529115141.2AAC841AF01@stupor.lindenlab.com> <8710222F-6EC7-42F8-AB7D-982498D5B262@gmail.com> <465E21DE.6030505@gmail.com> <465F1721.90402@lindenlab.com> <465F2B1A.3090203@gmail.com> Message-ID: <466487AB.7050508@lindenlab.com> max case wrote: >> > As someone who doesn't spend a lot of time not in God mode, I have to >> > ask: what is useful about View Admin Options for you? It would be nice > A trick someone taught me recently that causes me ot use god mode is > that you can offer teleports to friends, when just pullin up their > profile doesn't always offer it. Wow, interesting, that's pretty clever. Thanks for the tip, I'll be sure to add this to the task. -RYaN From phoenix at secondlife.com Mon Jun 4 14:45:24 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Jun 4 14:45:41 2007 Subject: [sldev] There are a few files in the 1.16.0.5 src dist without Copyright text In-Reply-To: <46647DBA.4030505@ucsd.edu> References: <46647DBA.4030505@ucsd.edu> Message-ID: <7E67966A-A01C-4029-91E2-DCB9B8F62525@secondlife.com> Yes, I found this as well. Many of these files were in development during the original internal open source push, so they missed the fun 'give every file a header' patch-fest. These files are licensed under the same terms as every other source file, gpl, and we have corrected the issue in appropriate branches. Updated files will come soon. SL-43091: Fix copyright and license notice thanks for noticing though. :) On 2007 Jun 4, at 14:01, Max Okumoto wrote: > Is there any interest in patches to add the missing Linden labs > copyright? The list of files > follows: > > linden/indra/llmessage/llmessagebuilder.h > linden/indra/llmessage/llmessagereader.cpp > linden/indra/llmessage/llmessagereader.h > linden/indra/llmessage/llmessagetemplate.cpp > linden/indra/llmessage/llmessagetemplate.h > linden/indra/llmessage/llmsgvariabletype.h > linden/indra/llmessage/llsdmessagebuilder.cpp > linden/indra/llmessage/llsdmessagebuilder.h > linden/indra/llmessage/llsdmessagereader.cpp > linden/indra/llmessage/llsdmessagereader.h > linden/indra/llmessage/lltemplatemessagebuilder.cpp > linden/indra/llmessage/lltemplatemessagebuilder.h > linden/indra/llmessage/lltemplatemessagereader.cpp > linden/indra/llmessage/lltemplatemessagereader.h > linden/indra/llrender/llvertexbuffer.cpp > linden/indra/llrender/llvertexbuffer.h > linden/indra/newview/llassetuploadresponders.cpp > linden/indra/newview/llassetuploadresponders.h > linden/indra/newview/llfloaterinspect.cpp > linden/indra/test/llsdtraits.h > > _______________________________________________ > 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/20070604/6bd87ba5/PGP.pgp From dzonatas at dzonux.net Mon Jun 4 15:15:15 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jun 4 15:13:42 2007 Subject: [sldev] [PATCH] VWR-962: llprocessor.cpp: enable x86 detection for GCC Message-ID: <46648EF3.2090007@dzonux.net> I've updated the patch to VWR-962. I've confirmed it works on Windows and x86 Linux. This alone will produce the raw detection. There are updates I made to related files that process this data further for better results. Raw results will most likely be off on scaled processors for Linux since the application doesn't have root access, for example to set desired affinity like Windows easily gives. I do not see the CPUSlow mask applied after this patch and the related patches. https://jira.secondlife.com/browse/VWR-962 https://jira.secondlife.com/secure/attachment/10715/llprocessor.r62589.patch.txt -- From dzonatas at dzonux.net Mon Jun 4 15:19:00 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jun 4 15:17:26 2007 Subject: [sldev] There are a few files in the 1.16.0.5 src dist without Copyright text In-Reply-To: <7E67966A-A01C-4029-91E2-DCB9B8F62525@secondlife.com> References: <46647DBA.4030505@ucsd.edu> <7E67966A-A01C-4029-91E2-DCB9B8F62525@secondlife.com> Message-ID: <46648FD4.8080103@dzonux.net> It's not just the copyright header, as some miss one of the standard #include's. https://jira.secondlife.com/browse/VWR-1061 Phoenix wrote: > Yes, I found this as well. Many of these files were in development > during the original internal open source push, so they missed the fun > 'give every file a header' patch-fest. These files are licensed under > the same terms as every other source file, gpl, and we have corrected > the issue in appropriate branches. Updated files will come soon. > > SL-43091: Fix copyright and license notice > > thanks for noticing though. :) > > > On 2007 Jun 4, at 14:01, Max Okumoto wrote: >> Is there any interest in patches to add the missing Linden labs >> copyright? The list of files >> follows: >> >> linden/indra/llmessage/llmessagebuilder.h >> linden/indra/llmessage/llmessagereader.cpp >> linden/indra/llmessage/llmessagereader.h >> linden/indra/llmessage/llmessagetemplate.cpp >> linden/indra/llmessage/llmessagetemplate.h >> linden/indra/llmessage/llmsgvariabletype.h >> linden/indra/llmessage/llsdmessagebuilder.cpp >> linden/indra/llmessage/llsdmessagebuilder.h >> linden/indra/llmessage/llsdmessagereader.cpp >> linden/indra/llmessage/llsdmessagereader.h >> linden/indra/llmessage/lltemplatemessagebuilder.cpp >> linden/indra/llmessage/lltemplatemessagebuilder.h >> linden/indra/llmessage/lltemplatemessagereader.cpp >> linden/indra/llmessage/lltemplatemessagereader.h >> linden/indra/llrender/llvertexbuffer.cpp >> linden/indra/llrender/llvertexbuffer.h >> linden/indra/newview/llassetuploadresponders.cpp >> linden/indra/newview/llassetuploadresponders.h >> linden/indra/newview/llfloaterinspect.cpp >> linden/indra/test/llsdtraits.h >> >> _______________________________________________ >> 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/20070604/9a90d30b/attachment.htm From Harleen at comcast.net Mon Jun 4 17:24:18 2007 From: Harleen at comcast.net (Harleen Gretzky) Date: Mon Jun 4 17:25:27 2007 Subject: [sldev] Re: Patch to make View Admin Options sticky. References: <20070529115141.2AAC841AF01@stupor.lindenlab.com> <8710222F-6EC7-42F8-AB7D-982498D5B262@gmail.com> <465E21DE.6030505@gmail.com> <465F1721.90402@lindenlab.com><465F2B1A.3090203@gmail.com> <466487AB.7050508@lindenlab.com> Message-ID: <007101c7a707$dbb85990$6869a8c0@PJRIII.local> It is already in the KB: http://secondlife.com/knowledgebase/article.php?id=404 ----- Original Message ----- From: "Ryan Williams" To: "max case" Cc: Sent: Monday, June 04, 2007 5:44 PM Subject: Re: [sldev] Re: Patch to make View Admin Options sticky. > max case wrote: >>> > As someone who doesn't spend a lot of time not in God mode, I have to >>> > ask: what is useful about View Admin Options for you? It would be >>> > nice >> A trick someone taught me recently that causes me ot use god mode is >> that you can offer teleports to friends, when just pullin up their >> profile doesn't always offer it. > > Wow, interesting, that's pretty clever. Thanks for the tip, I'll be > sure to add this to the task. > > -RYaN > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From robla at lindenlab.com Mon Jun 4 18:49:25 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jun 4 18:49:31 2007 Subject: [sldev] Bug triage transcript posted Message-ID: <4664C125.3050009@lindenlab.com> Hi folks, By request, I've posted the transcript of the last triage to the wiki: https://wiki.secondlife.com/wiki/Bug_triage/2007-06-04 I'd like to start doing that more, for both general office hours and for bug triages. Thanks everyone for showing up! 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/20070604/04aca4a0/signature.pgp From tom at cornish-pasty.com Mon Jun 4 20:14:05 2007 From: tom at cornish-pasty.com (Thomas Rowland) Date: Mon Jun 4 20:14:10 2007 Subject: [sldev] [PATCH] VWR-962: llprocessor.cpp: enable x86 detection forGCC In-Reply-To: <46648EF3.2090007@dzonux.net> Message-ID: <001301c7a71f$9351b9e0$990d1352@tomhome> The code +719,28 (in CProcessor::AnalyzeAMDProcessor) could be updated to include https://jira.secondlife.com/browse/VWR-1049 Simply, the sizeof calculations are broken by a misplaced closing brace; strncpy( CPUInfo.strBrandID, tmp, sizeof( CPUInfo.strBrandID-1 ) ); CPUInfo.strBrandID[ sizeof( CPUInfo.strBrandID-1 ) ] = '\0'; Where sizeof returns 4 Should be; strncpy( CPUInfo.strBrandID, tmp, sizeof( CPUInfo.strBrandID ) -1 ); CPUInfo.strBrandID[ sizeof( CPUInfo.strBrandID ) -1 ] = '\0'; Where sizeof is then 64-1 > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Dzonatas > Sent: 04 June 2007 23:15 > To: sldev@lists.secondlife.com > Subject: [sldev] [PATCH] VWR-962: llprocessor.cpp: enable x86 > detection forGCC > > > I've updated the patch to VWR-962. I've confirmed it works on Windows > and x86 Linux. > > This alone will produce the raw detection. There are updates > I made to > related files that process this data further for better results. > > Raw results will most likely be off on scaled processors for > Linux since > the application doesn't have root access, for example to set desired > affinity like Windows easily gives. > > I do not see the CPUSlow mask applied after this patch and > the related > patches. > > https://jira.secondlife.com/browse/VWR-962 > > https://jira.secondlife.com/secure/attachment/10715/llprocesso r.r62589.patch.txt -- _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Mon Jun 4 21:12:20 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jun 4 21:10:47 2007 Subject: [sldev] [PATCH] VWR-962: llprocessor.cpp: enable x86 detection forGCC In-Reply-To: <001301c7a71f$9351b9e0$990d1352@tomhome> References: <001301c7a71f$9351b9e0$990d1352@tomhome> Message-ID: <4664E2A4.1090109@dzonux.net> Done. Thank you! Thomas Rowland wrote: > The code +719,28 (in CProcessor::AnalyzeAMDProcessor) could be updated to > include https://jira.secondlife.com/browse/VWR-1049 > Simply, the sizeof calculations are broken by a misplaced closing brace; > > strncpy( CPUInfo.strBrandID, tmp, sizeof( CPUInfo.strBrandID-1 ) ); > CPUInfo.strBrandID[ sizeof( CPUInfo.strBrandID-1 ) ] = '\0'; > > Where sizeof returns 4 > Should be; > > strncpy( CPUInfo.strBrandID, tmp, sizeof( CPUInfo.strBrandID ) -1 ); > CPUInfo.strBrandID[ sizeof( CPUInfo.strBrandID ) -1 ] = '\0'; > > Where sizeof is then 64-1 > > >> -----Original Message----- >> From: sldev-bounces@lists.secondlife.com >> [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Dzonatas >> Sent: 04 June 2007 23:15 >> To: sldev@lists.secondlife.com >> Subject: [sldev] [PATCH] VWR-962: llprocessor.cpp: enable x86 >> detection forGCC >> >> >> I've updated the patch to VWR-962. I've confirmed it works on Windows >> and x86 Linux. >> >> This alone will produce the raw detection. There are updates >> I made to >> related files that process this data further for better results. >> >> Raw results will most likely be off on scaled processors for >> Linux since >> the application doesn't have root access, for example to set desired >> affinity like Windows easily gives. >> >> I do not see the CPUSlow mask applied after this patch and >> the related >> patches. >> >> https://jira.secondlife.com/browse/VWR-962 >> >> https://jira.secondlife.com/secure/attachment/10715/llprocesso >> > r.r62589.patch.txt > > > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070604/b105f55c/attachment.htm From bbyer at mm.st Mon Jun 4 22:21:46 2007 From: bbyer at mm.st (Ben Byer) Date: Mon Jun 4 22:21:58 2007 Subject: [sldev] Re: dead code In-Reply-To: <46545C49.9080202@lindenlab.com> References: <46545C49.9080202@lindenlab.com> Message-ID: <5C75920C-8346-484A-915D-D185F5C96F78@mm.st> On May 23, 2007, at 8:22 AM, Andrew Meadows wrote: > Your list undoubtedly contains lots of dead code however I > find some of it suspiciously alive. Consider the the LLAgent > methods. The LLAgent constructor is in the list, however the > SL viewer has a big fat global LLAgent called gAgent that is > initialized in viewer.cpp using, as far as I can tell, the only > constructor that is defined in the LLAgent class. > > If you track down some of the other LLAgent methods listed here > it appears a few are actually being called. For instance, > LLAgent::getCameraMinOffGround() is called inside of > LLAgent::calcCameraPositionTargetGlobal() which is not on your > list. > > Some other examples of non-LLAgent undead code: > > ~LLMatrix4() sure it's a trivial method and not explicitly > called, but it shouldn't be removed > LLPipeline::unloadShaders() explicitly called in > LLPipeline::destroyGL() > LLPrimitive() explicitly called in constructor of LLViewerObject, > which derives from LLPrimitive Okay. I rebuilt the list, but this time I used -O0. I've made an effort to remove all obvious library functions, as well as constructors and destructors; some may remain, but this list should be more helpful: CProcessor::WriteInfoTextFile(char const*) FFT842(int, int, DPCOMPLEX*) Head::getInertia() Head::getMass() Head::getRadius() Head::propagate(float, float, float) Head::setMass(float) Head::setRadius(float) LLAgent::copyWearableToInventory(EWearableType) LLAgent::getLookAtType() LLAgent::getName(LLStringBase&) LLAgent::getPointAtType() LLAgent::getPowerInGroup(LLUUID const&) const LLAgent::getQuat() const LLAgent::getWearablePermMask(EWearableType) LLAgent::isGroupMember() const LLAgent::needsReplacement(EWearableType, int) LLAgent::renderAutoPilotTarget() LLAgent::resetAxes() LLAgent::roll(float) LLAgent::rotate(LLMatrix3 const&) LLAgent::rotate(LLQuaternion const&) LLAgent::rotate(float, LLVector3 const&) LLAgent::startFollowPilot(LLUUID const&) LLAgentPilot::addWaypoint(void*) LLAggregatePermissions::aggregate(unsigned int) LLAggregatePermissions::aggregateBit (LLAggregatePermissions::EPermIndex, int) LLAggregatePermissions::getU8() const LLAggregatePermissions::isEmpty() const LLAggregatePermissions::packMessage(LLMessageSystem*, char const*) const LLAlertDialog::createXml(LLStringBase const&, void (*)(int, void*), void*) LLAlertDialog::setOptionEnabled(int, int) LLApp::fork() LLApp::getOptionData(LLApp::OptionPriority) LLApp::getPid() LLApp::getSigChildCount() LLApp::incSigChildCount() LLApp::isError() LLApp::isExiting() LLApp::isQuitting() LLApp::isRunning() LLApp::isStopped() LLApp::parseCommandOptions(int, char**) LLApp::runErrorHandler() LLApp::sDefaultChildCallback LLApp::sErrorHandler LLApp::sErrorThreadRunning LLApp::sLogInSignal LLApp::sSigChildCount LLApp::sStatus LLApp::setChildCallback(int, void (*)(int, bool, int)) LLApp::setDefaultChildCallback(void (*)(int, bool, int)) LLApp::setError() LLApp::setErrorHandler(void (*)()) LLApp::setOptionData(LLApp::OptionPriority, LLSD) LLApp::setQuitting() LLApp::setStatus(LLApp::e_app_status) LLApp::setStopped() LLApp::setupErrorHandling() LLApp::stepFrame() LLAssetInfo::setFromNameValue(LLNameValue const&) LLAssetStorage::getNumPendingDownloads() const LLAssetStorage::getNumPendingLocalUploads() LLAssetStorage::uploadCompleteCallback(LLUUID const&, void*, int) LLAssetType::lookupHumanReadable(char const*) LLAsyncHostByName::cancelPendingRequest() LLAudioEngine::findAudioSource(LLUUID const&) LLAudioEngine::getInternetStreamGain() LLAudioEngine::hasLocalFile(LLUUID const&) LLAudioEngine_FMOD::callbackMetaData(char*, char*, void*) LLAvatarTracker::getDegreesAndDist(float&, double&, double&) LLAvatarTracker::isBuddyEmpowered(LLUUID const&) const LLAvatarTracker::setBuddyEmpowered(LLUUID const&, bool) LLBBox::addPointAgent(LLVector3) LLBBox::expand(float) LLBBoxLocal::expand(float) LLBVHLoader::ST_NO_FILE LLBase64::encode(unsigned char const*, unsigned long) LLBlowfishCipher::decrypt(unsigned char const*, unsigned int, unsigned char*, unsigned int) LLBlowfishCipher::encrypt(unsigned char const*, unsigned int, unsigned char*, unsigned int) LLBlowfishCipher::requiredEncryptionSpace(unsigned int) const LLBottomPanel::setFocusIndicator(LLView*) LLBufferArray::capacity() const LLBufferArray::prepend(int, unsigned char const*, int) LLBufferArray::takeContents(LLBufferArray&) LLButton::setLabel(LLStringBase const&) LLCRC::update(unsigned char) LLCacheName::Impl::Impl(LLMessageSystem*) LLCacheName::deleteEntriesOlderThan(int) LLCacheName::dump() LLCacheName::dumpStats() LLCacheName::removeObserver(void (*)(LLUUID const&, char const*, char const*, int, void*)) LLCallbackList::containsFunction(void (*)(void*), void*) LLCallbackList::deleteAllFunctions() LLCamera::calculateWorldFrustumPlanes() LLCamera::heightInPixels(LLVector3 const&, float) const LLCamera::readFrustumFromBuffer(char const*) LLCamera::sphereInFrustumOld(LLVector3 const&, float) const LLCamera::sphereInFrustumQuick(LLVector3 const&, float) LLCamera::visibleDistance(LLVector3 const&, float, float, unsigned int) const LLCamera::visibleHorizDistance(LLVector3 const&, float, float, unsigned int) const LLCamera::writeFrustumToBuffer(char*) const LLCategory::getSubCategory(unsigned char) const LLCategory::getSubCategoryCount() const LLCategory::getU32() const LLCategory::lookupName() const LLCategory::packMessage(LLMessageSystem*) const LLCategoryDropDescendentsObserver::done() LLChatBar::setIgnoreArrowKeys(int) LLCircuit::getInfoString() const LLCircuitData::getAgeInSeconds() const LLCircuitData::getAllowTimeout() const LLCircuitData::getBytesOut() const LLCircuitData::getInfoString() const LLCircuitData::setAllowTimeout(int) LLCircuitData::setTimeoutCallback(void (*)(LLHost const&, void*), void*) LLCloseAllFoldersFunctor::doFolder(LLFolderViewFolder*) LLCloseAllFoldersFunctor::doItem(LLFolderViewItem*) LLCloudLayer::renderDensityField() LLCloudLayer::reset() LLCloudLayer::setRegion(LLViewerRegion*) LLCollectOnlineBuddies::operator()(LLUUID const&, LLRelationship*) LLColor4::setVec(LLColor3 const&, float) LLColor4U::addClampMax(LLColor4U const&) LLColor4U::multAll(float) LLComboBox::setButtonVisible(int) LLCompass::draw() LLCompass::setBkgndTexture(LLUUID) LLCompass::setTexture(LLUUID) LLCondition::broadcast() LLCone::renderface(int, int) LLControl::addListener(void (*)(LLSD const&, int, LLControl&)) LLControlBase::allocateListenerID() LLControlBase::mTopID LLControlGroup::getWString(LLStringBase const&) LLControlGroup::registerListener(LLStringBase const&, LLSimpleListenerObservable*) LLControlGroup::resetToDefaults() LLControlGroup::setColor4U(LLStringBase const&, LLColor4U const&) LLCoordFrame::getOpenGLRotation(float*) const LLCoordFrame::getOpenGLTranslation(float*) const LLCoordFrame::getRotMatrixToParent(LLMatrix4&) const LLCoordFrame::lookAt(LLVector3 const&, LLVector3 const&) LLCoordFrame::lookAt(LLVector3 const&, LLVector3 const&)::up_direction LLCoordFrame::lookDir(LLVector3 const&) LLCoordFrame::lookDir(LLVector3 const&)::up_direction LLCoordFrame::readOrientation(char const*) LLCoordFrame::reset() LLCoordFrame::resetAxes() LLCoordFrame::roll(float) LLCoordFrame::rotateToAbsolute(LLVector4 const&) const LLCoordFrame::rotateToLocal(LLVector4 const&) const LLCoordFrame::setAxes(LLMatrix3 const&) LLCoordFrame::setAxes(LLQuaternion const&) LLCoordFrame::setAxes(float const*) LLCoordFrame::setOrigin(float const*) LLCoordFrame::transformToAbsolute(LLVector4 const&) const LLCoordFrame::transformToLocal(LLVector3 const&) const LLCoordFrame::transformToLocal(LLVector4 const&) const LLCoordFrame::translate(float const*) LLCoordFrame::translate(float, float, float) LLCoordFrame::writeOrientation(char*) const LLCountdown::draw() LLCountdown::isExpired() LLCtrlSelectionInterface::deselectByValue(LLSD) LLCubeMap::map(unsigned char, unsigned short, unsigned short) const LLCubeMap::paintIn(LLVector3*, LLColor4U const&) LLCubeMap::project(float&, float&, float&, float&, unsigned char, LLVector3*) const LLCubeMap::project(float&, float&, int&, unsigned char, LLVector3 const&) const LLCurl::Easy::perform() LLCurl::Multi::easyAlloc() LLCurrencyUIManager::Impl::Impl(LLPanel&) LLCurrencyUIManager::inProcess() LLCylinder::drawBottom(int) LLCylinder::drawSide(int) LLCylinder::drawTop(int) LLCylinder::render(float) LLCylinder::renderface(float, int) LLDataPacker::packFixed(float, char const*, int, unsigned int, unsigned int) LLDataPackerAsciiBuffer::dump() LLDataPackerBinaryBuffer::freeBuffer() LLDate::secondsSinceEpoch(double) LLDoubleLinkedList::addDataAtEnd(LLRoamTriNode*) LLDoubleLinkedList::addNodeAtEnd (LLDoubleLinkedNode*) LLDoubleLinkedList::getFirstData() LLDoubleLinkedList::isEmpty() LLDoubleLinkedList::removeCurrentData() LLDoubleLinkedList::getLastData() LLDoubleLinkedList::getNextData() LLDoubleLinkedList::getPreviousData() LLDoubleLinkedNode::removeData() LLDrawPoolAvatar::getDebugColor() const LLDrawPoolTerrain::getDebugColor() const LLDrawPoolTree::getDebugColor() const LLDrawPoolWater::getDebugColor() const LLDrawable::applyLightsAsPoint(LLColor4&) LLDrawable::findReferences(LLDrawable*) LLDrawable::getBounds(LLVector3&, LLVector3&) const LLDrawable::mergeFaces(LLDrawable*) LLDrawable::update() LLDrawable::updateMaterial() LLDrawable::updateUVMinMax() LLDropCopyableItems::operator()(LLInventoryCategory*, LLInventoryItem*) LLDropTarget::doDrop(EDragAndDropType, void*) LLDynamicArray::reserve_block(unsigned int) LLDynamicArray::count() const LLDynamicArray::reset() LLEditMenuHandlerMgr::getInstance() LLEditMenuHandlerMgr::getInstance()::instance LLError::Settings::restore(LLError::Settings*) LLError::Settings::saveAndReset() LLError::restoreSettings(LLError::Settings*) LLError::saveAndResetSettings() LLError::shouldLogCallCount() LLErrorThread::getUserData() const LLErrorThread::run() LLErrorThread::setUserData(void*) LLFFTPlan::buffer() const LLFFTPlan::cols() const LLFFTPlan::rows() const LLFFTPlan::valid() const LLFace::enableLights() const LLFace::getGeometryTerrain(LLStrider&, LLStrider&, LLStrider&, LLStrider&, LLStrider&, LLStrider&) LLFace::getIndices(LLStrider&) LLFace::getVertices(LLStrider&) LLFace::renderSetColor() const LLFace::sSafeRenderSelect LLFace::setWorldMatrix(LLMatrix4 const&) LLFace::unsetFaceColor() LLFacePool::moveFace(LLFace*, LLDrawPool*, int) LLFacePool::renderVisibility() LLFacePool::renderVisibility()::C.819 LLFastTimer::sCPUClockFrequency LLFeatureList::dump() LLFile::_fsopen(char const*, char const*, int) LLFilterSD2XMLRPCRequest::process_impl(LLChannelDescriptors const&, boost::shared_ptr&, bool&, LLSD&, LLPumpIO*) LLFilterSD2XMLRPCResponse::process_impl(LLChannelDescriptors const&, boost::shared_ptr&, bool&, LLSD&, LLPumpIO*) LLFilterXMLRPCRequest2LLSD::process_impl(LLChannelDescriptors const&, boost::shared_ptr&, bool&, LLSD&, LLPumpIO*) LLFilterXMLRPCResponse2LLSD::process_impl(LLChannelDescriptors const&, boost::shared_ptr&, bool&, LLSD&, LLPumpIO*) LLFirstUse::disableFirstUse() LLFirstUse::useAttach() LLFloaterAvatarInfo::showProfileCallback(int, void*) LLFloaterBuildOptions::getInstance() LLFloaterBuildOptions::visible(void*) LLFloaterBuyLand::isOpen() LLFloaterColorPicker::getOrigRgb(float&, float&, float&) LLFloaterCustomize::getEditGroup() LLFloaterCustomize::onBtnSnapshot(void*) LLFloaterDirectory::toggleEvents(void*) LLFloaterGodTools::refreshAll() LLFloaterGodTools::showPanel(LLStringBase const&) LLFloaterGodTools::updatePopup(LLCoordGL, unsigned int) LLFloaterGroupInfo::showMyGroupInfo(void*) LLFloaterGroupInvite::impl::impl(LLUUID const&) LLFloaterHtmlFind::draw() LLFloaterHtmlFind::onClickClose(void*) LLFloaterHtmlFind::onClickLinkHref(LLWebBrowserCtrlEvent const&) LLFloaterHtmlFind::onClose(bool) LLFloaterHtmlFind::postBuild() LLFloaterHtmlFind::sInstance LLFloaterHtmlFind::show(void*) LLFloaterIMPanel::onTabClick(void*) LLFloaterIMPanel::selectAll() LLFloaterIMPanel::selectNone() LLFloaterImagePreview::onMouseCaptureLost(LLMouseHandler*) LLFloaterImport::LoadPreviewImage(LLStringBase, LLUUID) LLFloaterImport::asset_uploaded_callback(LLUUID const&, void*, int) LLFloaterImport::draw() LLFloaterImport::finishImport(ImportAssetInfo*) LLFloaterImport::handleMouseDown(int, int, unsigned int) LLFloaterImport::onBtnCancel(void*) LLFloaterImport::onBtnOK(void*) LLFloaterImport::postBuild() LLFloaterImport::recalcCost() LLFloaterInspect::isVisible() LLFloaterJoystick::getInstance() LLFloaterJoystick::visible(void*) LLFloaterMove::toggle(void*) LLFloaterNewIM::isUUIDAvailable(LLUUID const&) LLFloaterPermissionsMgr::onClose(bool) LLFloaterPermissionsMgr::processPermissionsList(LLMessageSystem*, void**) LLFloaterPermissionsMgr::sInstance LLFloaterPermissionsMgr::show() LLFloaterReporter::addDescription(LLStringBase const&, LLMeanCollisionData*) LLFloaterReporter::setDescription(LLStringBase const&, LLMeanCollisionData*) LLFloaterSaveAvatar::onSave(void*) LLFloaterSaveAvatar::postBuild() LLFloaterSaveAvatar::show() LLFloaterView::destroyAllChildren() LLFloaterView::getBackmost() LLFloaterView::unhighlightFocusedFloater() LLFloaterWorldMap::fly() LLFloaterWorldMap::flyToAvatar() LLFloaterWorldMap::flyToLandmark() LLFloaterWorldMap::onCheckEvents(LLUICtrl*, void*) LLFloaterWorldMap::onFlyBtn(void*) LLFloaterWorldMap::onGoToLandmarkDialog(int, void*) LLFloaterWorldMap::onPanBtn(void*) LLFloaterWorldMap::teleportToAvatar() LLFloaterWorldMap::teleportToLandmark() LLFolderBridge::createNewCategory(void*) LLFolderBridge::createNewEyes(void*) LLFolderBridge::createNewGloves(void*) LLFolderBridge::createNewHair(void*) LLFolderBridge::createNewJacket(void*) LLFolderBridge::createNewPants(void*) LLFolderBridge::createNewShape(void*) LLFolderBridge::createNewShirt(void*) LLFolderBridge::createNewShoes(void*) LLFolderBridge::createNewSkin(void*) LLFolderBridge::createNewSkirt(void*) LLFolderBridge::createNewSocks(void*) LLFolderBridge::createNewUnderpants(void*) LLFolderBridge::createNewUndershirt(void*) LLFolderBridge::createWearable(LLFolderBridge*, EWearableType) LLFolderBridge::pasteClipboard(void*) LLFolderView::checkTreeResortForModelChanged() LLFolderView::closeAllFolders() LLFolderView::dumpSelectionInformation() LLFolderView::propertiesSelectedItems() LLFolderViewFolder::hasFilteredDescendants() LLFolderViewItem::isDescendantOf(LLFolderViewFolder const*) LLFollowCamMgr::isScriptedCameraSource(LLUUID const&) LLFontGL::getImageGL() const LLFontGL::nameFromVAlign(LLFontGL::VAlign) LLFontGL::operator=(LLFontGL const&) LLFontGL::vAlignFromName(LLStringBase const&) LLFrameStats::getCurStatName() const LLFrameTimer::expiresAt() const LLFrameTimer::setExpiryAt(double) LLGLManager::initWGL() LLGLState::checkClientArrays(unsigned int) LLGLState::checkClientArrays(unsigned int)::label LLGLState::checkClientArrays(unsigned int)::value LLGLState::checkStates() LLGLState::checkTextureChannels() LLGLState::checkTextureChannels()::label LLGLState::checkTextureChannels()::value LLGLState::dumpStates() LLGesture::MAX_SERIAL_SIZE LLGesture::getMaxSerialSize() LLGesture::getOutputString() const LLGesture::getTrigger() const LLGesture::operator=(LLGesture const&) LLGesture::serialize(unsigned char*) const LLGestureList::SERIAL_HEADER_SIZE LLGestureList::count() const LLGestureList::deserialize(unsigned char*, int) LLGestureList::getMaxSerialSize() LLGestureList::serialize(unsigned char*) const LLGestureList::triggerAndReviseString(LLStringBase const&, LLStringBase*) LLGestureManager::getPlayingCount() const LLGestureManager::init() LLGlobalEconomy::calculateLightRent(LLVector3 const&) const LLGlobalEconomy::calculateTeleportCost(float) const LLGroupDropTarget::doDrop(EDragAndDropType, void*) LLGroupMoneyTabEventHandler::impl::impl(LLButton*, LLButton*, LLTextEditor*, LLPanel*, LLUUID const&, int, int) LLHTTPBuffer::asLLSD() LLHTTPBuffer::asString() LLHTTPBuffer::curl_write(void*, unsigned long, unsigned long, void*) LLHTTPNode::Response::status(int) LLHTTPNode::allNodePaths() const LLHTTPNode::rootNode() const LLHUDConnector::setDoFade(int) LLHUDConnector::setEndpoints(int const&, int const&) LLHUDConnector::setZCompare(int) LLHUDEffectBeam::packData(LLMessageSystem*) LLHUDEffectBeam::render() LLHUDEffectBeam::setSourceObject(LLViewerObject*) LLHUDEffectBeam::setTargetObject(LLViewerObject*) LLHUDEffectBeam::setTargetPos(LLVector3d const&) LLHUDEffectBeam::setupParticle(int) LLHUDEffectBeam::unpackData(LLMessageSystem*, int) LLHUDEffectLookAt::getLookAtType() LLHUDEffectPointAt::getPointAtType() LLHUDView::colorFromType(int) LLHasAsset::operator()(LLInventoryCategory*, LLInventoryItem*) LLHeapBuffer::bytesLeft() const LLHorizontalCompass::draw() LLHorizontalCompass::setTexture(LLUUID const&) LLHost::getHostName() const LLHost::getIPString() const LLHtmlFind::show(void*) LLIMInfo::clone() LLIMInfo::packInstantMessage(LLMessageSystem*) const LLIMInfo::packMessageBlock(LLMessageSystem*) const LLIMView::isIMSessionOpen(LLUUID const&) LLIMView::pruneSessions() LLIOBuffer::bytesLeft() const LLIOBuffer::clear() LLIOBuffer::current() const LLIOBuffer::data() const LLIOBuffer::process_impl(LLChannelDescriptors const&, boost::shared_ptr&, bool&, LLSD&, LLPumpIO*) LLIOBuffer::seek(LLIOBuffer::EHead, long long) LLIOBuffer::size() const LLImageBase::calc_download_priority(float, float, int) LLImageDXT::convertToDXR() LLImageDXT::setFormat() LLImageGL::create(LLPointer&, LLImageRaw const*, int) LLImageGL::create(LLPointer&, int) LLImageGL::create(LLPointer&, unsigned int, unsigned int, unsigned char, int) LLImageGL::dataFormatComponents(int) LLImageGL::getBytes(int) const LLImageGL::getIsResident(int) LLImageGL::getMaxDiscardLevel() const LLImageGL::setImage(LLImageRaw const*) LLImageJ2C::decodeFailed() LLImageJ2C::setMaxBytes(int) LLImageRaw::contractToPowerOfTwo(int, int) LLImageRaw::createFromFile(LLStringBase const&, bool) LLImageRaw::fill(LLColor4U const&) LLImageRaw::getSubImage(unsigned int, unsigned int, unsigned int, unsigned int) const LLImageWorker::cleanupClass() LLInventoryClipboard::store(LLDynamicArray const&) LLInventoryClipboard::store(LLUUID const&) LLInventoryExistenceObserver::watchItem(LLUUID const&) LLInventoryFilter::isModifiedAndClear() LLInventoryItem::asLLSD() const LLInventoryItem::fromLLSD(LLSD&) LLInventoryItem::importXML(LLXMLNode*) LLInventoryItem::packBinaryBucket(unsigned char*, LLPermissions*) const LLInventoryItem::setInventoryType(LLInventoryType::EType) LLInventoryItem::unpackBinaryBucket(unsigned char*, int) LLInventoryModel::deleteFromServer(LLDynamicArray&, LLDynamicArray&) LLInventoryModel::getCategoryCount() const LLInventoryObject::setType(LLAssetType::EType) LLInventoryPanel::dumpSelectionInformation(void*) LLInventoryPanel::getShowFolderState() LLInventoryPanel::openAllFolders() LLInventoryView::filtersVisible(void*) LLJoint::clampRotation(LLQuaternion, LLQuaternion) LLJoint::getLastWorldPosition() LLJoint::getLastWorldRotation() LLJoint::setConstraintSilhouette(LLDynamicArray&) LLJoint::setWorldMatrix(LLMatrix4 const&) LLJointSolverRP3::getPoleVector() LLJointSolverRP3::getTwist() LLJointSolverRP3::setTwist(float) LLKeyboard::inverseTranslateKey(unsigned char) LLKeyboardMacOSX::inverseTranslateNumpadKey(unsigned char) LLKeyframeDataCache::clear() LLKeyframeDataCache::dumpDiagInfo() LLKeyframeMotion::JointMotionList::dumpDiagInfo() LLKeyframeMotion::isLoaded() LLKeyframeMotion::writeCAL3D(apr_file_t*) LLKeyframeMotionParam::addKeyframeMotion(char*, LLUUID const&, char*, float) LLKeyframeMotionParam::getBlendType() LLKeyframeMotionParam::getDuration() LLKeyframeMotionParam::getEaseInDuration() LLKeyframeMotionParam::getEaseOutDuration() LLKeyframeMotionParam::getLoop() LLKeyframeMotionParam::getMinPixelArea() LLKeyframeMotionParam::getPose() LLKeyframeMotionParam::getPriority() LLKeyframeMotionParam::loadMotions() LLKeyframeMotionParam::onActivate() LLKeyframeMotionParam::onDeactivate() LLKeyframeMotionParam::onInitialize(LLCharacter*) LLKeyframeMotionParam::onUpdate(float, unsigned char*) LLKeyframeMotionParam::setDefaultKeyframeMotion(char*) LLKillerSky::getMieCoefficients(float, float, float*) LLKillerSky::getRaleighCoefficients(float, float, float*) LLKillerSky::sMieFactor LLKillerSky::sNearFalloffFactor LLKillerSky::sRaleighGroundDensity LLKillerSky::sSkyContrib LLLFSThread::read(LLStringBase const&, unsigned char*, int, int, LLLFSThread::Responder*, unsigned int) LLLandmark::getRegionPos() const LLLandmark::setRegionHandle(LLUUID const&, unsigned long long) LLLightParams::getCutoff() const LLLineEditor::setIgnoreArrowKeys(int) LLLineSegmentAABB(LLVector3 const&, LLVector3 const&, LLVector3 const&, LLVector3 const&) LLLinkedList::removeData(LLPolyMorphData*) LLLinkedList::LLLinkNode::deleteData() LLLinkedList::LLLinkNode::removeData() LLLinkedList::addData(LLToolContainer*) LLLinkedList::checkData(LLToolContainer*) LLLinkedList::deleteAllData() LLLinkedList::getFirstData() LLLinkedList::getNextData() LLLinkedList::removeAllNodes() LLLiveLSLEditor::loadScriptText(char const*) LLLogTextMessage::flush() LLLogTextMessage::log(LLUUID const&, LLUUID const&, char const*) LLLogTextMessage::log(LLUUID const&, LLUUID const&, double, double, char const*) LLLogTextMessage::log(LLUUID const&, double, double, char const*) LLManipRotate::projectToSphere(float, float, int*) LLManipScale::renderEdges(LLBBox const&) LLManipScale::setShowAxes(int) LLManipScale::setStretchTextures(int) LLManipScale::setUniform(int) LLMap::operator[](EReportType const&) LLMap::addData(unsigned int const&, float*) LLMap::getIfThere(unsigned int const&) LLMaterialTable::DEFAULT_FRICTION LLMaterialTable::DEFAULT_RESTITUTION LLMaterialTable::getCollisionParticleUUID(unsigned char, unsigned char) LLMaterialTable::getCollisionSoundUUID(unsigned char, unsigned char) LLMaterialTable::getDamageMod(unsigned char) LLMaterialTable::getDefaultTextureID(char*) LLMaterialTable::getDefaultTextureID(unsigned char) LLMaterialTable::getDensity(unsigned char) LLMaterialTable::getEPMod(unsigned char) LLMaterialTable::getFriction(unsigned char) LLMaterialTable::getGroundCollisionParticleUUID(unsigned char) LLMaterialTable::getGroundCollisionSoundUUID(unsigned char) LLMaterialTable::getGroundRollingSoundUUID(unsigned char) LLMaterialTable::getGroundSlidingSoundUUID(unsigned char) LLMaterialTable::getHPMod(unsigned char) LLMaterialTable::getRestitution(unsigned char) LLMaterialTable::getRollingSoundUUID(unsigned char, unsigned char) LLMaterialTable::getShatterSoundUUID(unsigned char) LLMaterialTable::getSlidingSoundUUID(unsigned char, unsigned char) LLMatrix3::adjointTranspose() LLMatrix3::determinant() const LLMatrix3::invert() LLMatrix3::rotate(LLQuaternion const&) LLMatrix3::rotate(float, LLVector3 const&) LLMatrix3::rotate(float, float, float) LLMatrix3::rotate(float, float, float, float) LLMatrix3::setRot(float, LLVector3 const&) LLMatrix3::setRot(float, float, float, float) LLMatrix3::zero() LLMatrix4::determinant() const LLMatrix4::initMatrix(LLMatrix3 const&, LLVector4 const&) LLMatrix4::initRotTrans(float, LLVector3 const&, LLVector3 const&) LLMatrix4::initRotTrans(float, float, float, LLVector4 const&) LLMatrix4::initRotTrans(float, float, float, float, float, float, float) LLMatrix4::initRotation(float, LLVector4 const&) LLMatrix4::initRotation(float, float, float) LLMatrix4::initRotation(float, float, float, float) LLMatrix4::rotate(float, LLVector4 const&) LLMatrix4::rotate(float, float, float) LLMatrix4::rotate(float, float, float, float) LLMatrix4::setTranslation(LLVector3 const&) LLMatrix4::setTranslation(float, float, float) LLMediaEngine::getNetworkProxy(int&, LLStringBase&, int&, int&, LLStringBase&) LLMediaEngine::init() LLMediaEngine::setAvailable(int) LLMediaEngine::setEnabled(int) LLMediaEngine::setNetworkProxy(int, LLStringBase const&, int, int, LLStringBase const&) LLMediaMovieBase::make(LLMediaBase::MediaType, int, int) LLMemType::printMem() LLMemType::sMaxTotalMem LLMemType::sTotalMem LLMemory::freeReserve() LLMenuGL::empty() LLMenuGL::setLeftAndBottom(int, int) LLMessageConfig::isServerDefaultBuilderLLSD() LLMessageReader::setTimeDecodes(int) LLMessageReader::setTimeDecodesSpamThreshold(float) LLMessageSystem::addF64(char const*, double) LLMessageSystem::addIPAddr(char const*, unsigned int) LLMessageSystem::addIPPort(char const*, unsigned short) LLMessageSystem::addIPPortFast(char const*, unsigned short) LLMessageSystem::addQuat(char const*, LLQuaternion const&) LLMessageSystem::addS16(char const*, short) LLMessageSystem::addU16(char const*, unsigned short) LLMessageSystem::addVector4(char const*, LLVector4 const&) LLMessageSystem::addVector4Fast(char const*, LLVector4 const&) LLMessageSystem::checkCircuitAlive(LLHost const&) LLMessageSystem::checkCircuitAlive(unsigned int) LLMessageSystem::checkCircuitBlocked(unsigned int) LLMessageSystem::copyMessageRtoS() LLMessageSystem::establishBidirectionalTrust(LLHost const&, long long) LLMessageSystem::findHost(unsigned int) LLMessageSystem::flush(LLHost const&) LLMessageSystem::flushReliable(LLHost const&) LLMessageSystem::flushSemiReliable(LLHost const&, void (*)(void**, int), void**) LLMessageSystem::forwardMessage(LLHost const&) LLMessageSystem::forwardReliable(LLHost const&) LLMessageSystem::forwardReliable(unsigned int) LLMessageSystem::generateDigestForNumber(char*, unsigned int) const LLMessageSystem::generateDigestForWindow(char*, int) const LLMessageSystem::getCircuitInfoString() LLMessageSystem::getCircuitTrust(LLHost const&) LLMessageSystem::getF64(char const*, char const*, double&, int) LLMessageSystem::getIPAddr(char const*, char const*, unsigned int&, int) LLMessageSystem::getIPPort(char const*, char const*, unsigned short&, int) LLMessageSystem::getListenPort() const LLMessageSystem::getReceiveBytes() const LLMessageSystem::getS16(char const*, char const*, short&, int) LLMessageSystem::getSenderID() const LLMessageSystem::getSenderSessionID() const LLMessageSystem::getU16(char const*, char const*, unsigned short&, int) LLMessageSystem::getVector4(char const*, char const*, LLVector4&, int) LLMessageSystem::isCircuitCodeKnown(unsigned int) const LLMessageSystem::isClear() const LLMessageSystem::isMatchingDigestForWindow(char const*, int) const LLMessageSystem::isMessageFast(char const*) LLMessageSystem::poll(float) LLMessageSystem::processMessageTemplateChecksumReply (LLMessageSystem*, void**) LLMessageSystem::removeLastBlock() LLMessageSystem::sanityCheck() LLMessageSystem::sendMessageTemplateChecksum(LLHost const&) LLMessageSystem::setCircuitAllowTimeout(LLHost const&, int) LLMessageSystem::setCircuitTimeoutCallback(LLHost const&, void (*) (LLHost const&, void*), void*) LLMessageSystem::setMaxMessageCounts(int) LLMessageSystem::setMessageBans(LLSD const&, LLSD const&) LLMessageSystem::setTimeDecodes(int) LLMessageSystem::setTimeDecodesSpamThreshold(float) LLMessageSystem::setTimingFunc(void (*)(char const*, float, void*), void*) LLMessageSystem::showCircuitInfo() LLMessageSystem::zeroCodeAdjustCurrentSendTotal() LLMessageThrottle::addAgentAlert(LLUUID const&, LLUUID const&, char const*) LLMessageThrottle::addViewerAlert(LLUUID const&, char const*) LLMessageThrottle::pruneEntries() LLMessageThrottleEntry::getEntryTime() LLMessageThrottleEntry::getHash() LLMetaClass::beginProperties() const LLMetaClass::endProperties() const LLMetaClass::getPropertyCount() const LLMetaProperty::getObjectMetaClass() const LLModalDialog::onAppFocusLost() LLMsgData::addDataFast(char*, char*, void const*, int, e_message_variable_type, int) LLMultiGesture::dump() LLMultiPreview::getAutoOpenInstance(LLUUID const&) LLMultiPreview::setAutoOpenInstance(LLMultiPreview*, LLUUID const&) LLMuteList::addObserver(LLMuteListObserver*) LLMuteList::removeObserver(LLMuteListObserver*) LLNameListCtrl::removeNameItem(LLUUID const&) LLNameValue::callCallback() LLNameValue::getAsset() const LLNameValue::getF32() LLNameValue::getS32() LLNameValue::getU32() LLNameValue::getU64() LLNameValue::getVec3() LLNameValue::getVec3(LLVector3&) LLNameValue::magnitude() LLNameValue::nonzero() LLNameValue::operator=(LLNameValue const&) LLNameValue::sendToData() const LLNameValue::sendToViewer() const LLNameValue::setAsset(char const*) LLNameValue::setF32(float) LLNameValue::setS32(int) LLNameValue::setString(char const*) LLNameValue::setU32(unsigned int) LLNameValue::setVec3(LLVector3 const&) LLNetMap::translatePan(float, float) LLNetworkData::isValid(unsigned short, unsigned int) LLNullCipher::decrypt(unsigned char const*, unsigned int, unsigned char*, unsigned int) LLNullCipher::encrypt(unsigned char const*, unsigned int, unsigned char*, unsigned int) LLNullCipher::requiredEncryptionSpace(unsigned int) const LLOSInfo::getMaxOpenFiles() LLOSInfo::getMaxOpenFiles()::open_max LLOSInfo::getProcessResidentSizeKB() LLOSInfo::getProcessVirtualSizeKB() LLObjectSelection::applyToNodes(LLSelectedNodeFunctor*) LLObjectSelection::applyToRootObjects(LLSelectedObjectFunctor*) LLObjectSelection::contains(LLViewerObject*) LLObjectSelection::getCurrentTE(LLViewerObject**, int*) LLObjectSelection::getOwnershipCost(int&) LLObjectSelection::getTECount() LLOctreePick::check(LLDrawable*) LLOctreePick::check(LLOctreeNode const*) LLOctreePick::visit(LLOctreeState const*) LLOpenFilteredFolders::doFolder(LLFolderViewFolder*) LLOpenFilteredFolders::doItem(LLFolderViewItem*) LLOverlayBar::onClickResetView(void*) LLPanel::childDisplayNotFound() LLPanel::getBackgroundColor() LLPanel::getPanelByHandle(LLViewHandle) LLPanelAvatar::setAvatar(LLViewerObject*) LLPanelAvatarSecondLife::onClickImage(void*) LLPanelClassified::reset() LLPanelDebug::apply() LLPanelDebug::cancel() LLPanelDirBrowser::addHelpText(char const*) LLPanelDirBrowser::newClassified() LLPanelDirBrowser::renameClassified(LLUUID const&, char const*) LLPanelDirFind::onCommitScope(LLUICtrl*, void*) LLPanelDirPlaces::initialQuery() LLPanelDirPopular::onClickSearch(void*) LLPanelDisplay3::setDefaults() LLPanelDisplay::onApplyResolution(LLUICtrl*, void*) LLPanelEditWearable::getCurrentSubpart() LLPanelEstateCovenant::getEstateName() const LLPanelEstateCovenant::getOwnerName() const LLPanelGroupInvite::impl::impl(LLUUID const&) LLPanelGroupLandMoney::impl::impl(LLUUID const&) LLPanelGroupTab::createTab(void*) LLPanelGroupVoting::impl::impl(LLUUID const&) LLPanelInventory::removeSelectedItem() LLPanelInventory::startRenamingSelectedItem() LLPanelLandAccess::onAccessLevelChange(LLUICtrl*, void*) LLPanelLandGeneral::buyPassDialogVisible() LLPanelLandGeneral::enableDeedToGroup(void*) LLPanelLandMedia::onClickStartMedia(void*) LLPanelLandMedia::onClickStopMedia(void*) LLPanelLandRenters::onClickAdd(void*) LLPanelLandRenters::onClickRemove(void*) LLPanelLandRenters::refresh() LLPanelObject::onCommitCastShadows(LLUICtrl*, void*) LLPanelObject::sendCastShadows() LLPanelObjectTools::onClickSetBySelection(void*) LLPanelPermissions::onClickClaim(void*) LLPanelPermissions::onClickRelease(void*) LLPanelPick::reset() LLPanelRegionTextureInfo::onClickDump(void*) LLPanelRegionTools::getGridPosX() const LLPanelRegionTools::getGridPosY() const LLPanelWeb::apply() LLPanelWeb::cancel() LLParcel::allowTerraformBy(LLUUID const&) const LLParcel::blockAccess(LLUUID const&, LLUUID const&, int, int) const LLParcel::clearParcel() LLParcel::clearSale() LLParcel::completeSale(unsigned int&, unsigned char&, LLUUID&) LLParcel::dump() LLParcel::expirePasses(int) LLParcel::expireSale(unsigned int&, unsigned char&, LLUUID&, LLUUID&) LLParcel::extendAABB(LLVector3 const&, LLVector3 const&) LLParcel::getActionString(LLParcel::EAction) LLParcel::getAdjustedRentPerMeter() const LLParcel::getCategoryFromUIString(char const*) LLParcel::getCategoryString(LLParcel::ECategory) LLParcel::getOwnershipStatusString(LLParcel::EOwnershipStatus) LLParcel::isAgentBanned(LLUUID const&) const LLParcel::isBuyerAuthorized(LLUUID const&) const LLParcel::isSaleTimerExpired(unsigned long long const&) LLParcel::operator==(LLParcel const&) const LLParcel::overrideOwner(LLUUID const&, int) LLParcel::overrideParcelFlags(unsigned int) LLParcel::setArea(int, int) LLParcel::setDiscountRate(float) LLParcel::startSale(LLUUID const&, int) LLPartData::asLLSD() const LLPartData::fromLLSD(LLSD&) LLPartData::pack(LLDataPacker&) LLPartData::setEndAlpha(float) LLPartData::setEndColor(LLVector3 const&) LLPartData::setEndScale(float, float) LLPartData::setFlags(unsigned int) LLPartData::setMaxAge(float) LLPartData::setStartAlpha(float) LLPartData::setStartColor(LLVector3 const&) LLPartData::setStartScale(float, float) LLPartSysData::clampSourceParticleRate() LLPartSysData::pack(LLDataPacker&) LLPartSysData::packBlock() LLPartSysData::packNull() LLPartSysData::setPartAccel(LLVector3 const&) LLPathParams::asLLSD() const LLPathParams::copyParams(LLPathParams const&) LLPathParams::exportFile(__sFILE*) const LLPathParams::fromLLSD(LLSD&) LLPathParams::importFile(__sFILE*) LLPathParams::operator LLSD() const LLPathParams::setScaleX(float) LLPathParams::setScaleY(float) LLPathParams::setShearX(float) LLPathParams::setShearY(float) LLPerlinNoise::clouds3(float, float, float, float) LLPerlinNoise::init() LLPerlinNoise::noise1(float) LLPerlinNoise::noise2(float, float) LLPerlinNoise::noise3(float, float, float) LLPerlinNoise::sInitialized LLPerlinNoise::turbulence2(float, float, float) LLPerlinNoise::turbulence3(float, float, float, float) LLPermissions::deedToGroup(LLUUID const&, LLUUID const&) LLPermissions::getSafeOwner() const LLPermissions::importXML(LLXMLNode*) LLPermissions::operator==(LLPermissions const&) const LLPermissions::set(LLPermissions const&) LLPermissions::setBaseBits(LLUUID const&, int, unsigned int) LLPermissions::setOwnerBits(LLUUID const&, int, unsigned int) LLPermissionsView::addPermissionsData(LLStringBase const&, LLUUID const&, unsigned int) LLPermissionsView::clearPermissionsData() LLPermissionsView::findObject(void*) LLPermissionsView::getWidgetTag() const LLPermissionsView::getWidgetType() const LLPermissionsView::revokePermissions(void*) LLPipeline::enableShadows(int) LLPipeline::findReferences(LLDrawable*) LLPipeline::getPoolFromTE(LLTextureEntry const*, LLViewerImage*) LLPipeline::pickObject(LLVector3 const&, LLVector3 const&, LLVector3&) LLPipeline::setAmbient(LLColor4 const&) LLPointer::operator bool() const LLPointer::operator bool() const LLPolyMesh::deleteAllMorphData() LLPolyMesh::dumpDiagInfo() LLPolyMesh::getWritableWeights() const LLPolyMesh::removeMorphData(LLPolyMorphData*) LLPolyMeshSharedData::genIndices(int) LLPolyMeshSharedData::getNumKB() LLPose::findJointState(LLJoint*) LLPose::getNumJointStates() const LLPose::removeAllJointStates() LLPose::removeJointState(LLJointState*) LLPoseBlender::getBlendedPose() LLPreview::getFirstPreviewForSource(LLUUID const&) LLPreview::onRadio(LLUICtrl*, void*) LLPreviewAnim::saveAnim(void*) LLPreviewLandmark::getMarkerColor() const LLPreviewLandmark::getPositionGlobal() const LLPrimitive::copyTEs(LLPrimitive const*) LLPrimitive::createPrimitive(unsigned char) LLPrimitive::legacyToPCode(unsigned char) LLPrimitive::pCodeToLegacy(unsigned char) LLPrimitive::packTEMessage(LLDataPacker&) const LLPrimitive::setPCode(unsigned char) LLPrimitive::setTEArrays(unsigned char, LLUUID const*, float const*, float const*) LLPrimitive::setTextureList(LLTextureEntry*) LLProfile::genNormals() LLProfile::getTotalOut() const LLProfile::isConcave() const LLProfileParams::asLLSD() const LLProfileParams::copyParams(LLProfileParams const&) LLProfileParams::exportFile(__sFILE*) const LLProfileParams::fromLLSD(LLSD&) LLProfileParams::importFile(__sFILE*) LLProfileParams::operator LLSD() const LLProfileParams::operator!=(LLProfileParams const&) const LLPumpIO::LLChainInfo::LLChainInfo() LLPumpIO::control(LLPumpIO::EControl) LLPumpIO::prime(apr_pool_t*) LLPumpIO::setConditional(LLIOPipe*, apr_pollfd_t const*) LLPumpIO::setTimeoutSeconds(float) LLQuaternion::getMatrix4() const LLQuaternion::quantize16(float, float) LLQuaternion::quantize8(float, float) LLQuaternion::setQuat(LLMatrix3 const&) LLQuaternion::setQuat(LLMatrix4 const&) LLQuaternion::setQuat(float, LLVector4 const&) LLQueuedThread::check() LLQueuedThread::getRequestStatus(unsigned int) LLQueuedThread::printQueueStats() LLQueuedThread::waitOnPending() LLRayAABB(LLVector3 const&, LLVector3 const&, LLVector3 const&, LLVector3 const&, LLVector3&, float) LLRegionEconomy::getPriceParcelClaim() const LLRegionEconomy::getPriceParcelRent() const LLRegionEconomy::hasData() const LLRegionEconomy::print() LLRegionEconomy::processEconomyData(LLMessageSystem*, void**) LLRegionEconomy::processEconomyDataRequest(LLMessageSystem*, void**) LLRegionEconomy::setBasePriceParcelClaimActual(int) LLRegionEconomy::setBasePriceParcelClaimDefault(int) LLRegionEconomy::setBasePriceParcelRent(int) LLRegionEconomy::setPriceParcelClaimFactor(float) LLRegionPosition::getPositionAgent() const LLRegionPosition::getPositionGlobal() const LLRelationship::GRANTED_VISIBLE_MASK LLRelationship::grantRights(int, int) LLRelationship::revokeRights(int, int) LLResMgr::getMonetaryDecimalPoint() const LLRoam::flushMerge() LLRoam::flushSplit() LLRoam::numOfProcessedTrisInc() LLRoam::popMerge() LLRoam::popSplit() LLRoam::process() LLRoam::processMerge() LLRoam::processSplit() LLRoam::pushMerge(LLRoamTriNode*) LLRoam::pushSplit(LLRoamTriNode*) LLRoam::queueForMerge(LLRoamTriNode*, int) LLRoam::queueForSplit(LLRoamTriNode*, int) LLRoamPatch::numTrisDec() LLRoamPatch::numTrisInc() LLRoamTriNode::Lchild() const LLRoamTriNode::Rchild() const LLRoamTriNode::base() const LLRoamTriNode::dequeue() LLRoamTriNode::enqueue() LLRoamTriNode::getFirstLeaf() const LLRoamTriNode::getNextLeaf() const LLRoamTriNode::inQueue() const LLRoamTriNode::merge() LLRoamTriNode::mergeSimple() LLRoamTriNode::sQueues LLRoamTriNode::setBase(LLRoamTriNode*) LLRoamTriNode::setLeft(LLRoamTriNode*) LLRoamTriNode::setRight(LLRoamTriNode*) LLRoamTriNode::split(int) LLRoamTriNode::update() LLRoamTriNode::updateLink(LLRoamTriNode*, LLRoamTriNode*) LLRunner::removeRunnable(long long) LLSD::Impl::safe(LLSD::Impl const*) LLSD::Impl::safe(LLSD::Impl const*)::theUndefined LLSD::allocationCount() LLSD::beginMap() LLSD::endMap() LLSD::erase(int) LLSD::get(int) const LLSD::insert(int, LLSD const&) LLSD::outstandingCount() LLSD::set(int, LLSD const&) LLSDFormatter::boolalpha(bool) LLSDXMLParser::Impl::Impl() LLSDXMLParser::Impl::parsePart(char const*, int) LLSDXMLParser::parsePart(char const*, int) LLSaleInfo::fromLLSD(LLSD&, int&, unsigned int&) LLSaleInfo::importXML(LLXMLNode*) LLSaleInfo::operator==(LLSaleInfo const&) const LLSavedSettingsGlue::setF32(LLUICtrl*, void*) LLSavedSettingsGlue::setS32(LLUICtrl*, void*) LLSavedSettingsGlue::setString(LLUICtrl*, void*) LLSavedSettingsGlue::setU32(LLUICtrl*, void*) LLScatterShader::init(void*, int) LLScopedLock::unlock() LLScriptByteCodeChunk::addBytesDontInc(int) LLScriptEdCore::enableDeselectMenu(void*) LLScriptEdCore::onBtnInsertSample(void*) LLScriptEdCore::onDeselectMenu(void*) LLScriptExpression::addExpression(LLScriptExpression*) LLScriptGenerateErrorText::writeWarning(__sFILE*, int, int, e_lscript_warnings) LLScriptGlobalFunctions::addGlobalFunction(LLScriptGlobalFunctions*) LLScriptGlobalVariable::addGlobal(LLScriptGlobalVariable*) LLScriptLibrary::assignExec(char*, void (*)(LLScriptLibData*, LLScriptLibData*, LLUUID const&)) LLScriptStatement::addStatement(LLScriptStatement*) LLScrollListCtrl::isEmpty() const LLScrollableContainerView::setBorderVisible(int) LLScrollbar::setHighlightColor(LLColor4 const&) LLScrollbar::setShadowColor(LLColor4 const&) LLScrollbar::setThumbColor(LLColor4 const&) LLScrollbar::setTrackColor(LLColor4 const&) LLScrollingPanelParam::onSliderMouseDown(LLUICtrl*, void*) LLScrollingPanelParam::onSliderMouseUp(LLUICtrl*, void*) LLSegment::operator==(LLSegment const&) const LLSelectMgr::packAgentAndGroupID(void*) LLSelectMgr::packAgentID(void*) LLSelectMgr::packHingeHead(void*) LLSelectMgr::packObjectCategory(LLSelectNode*, void*) LLSelectMgr::packPhysics(LLSelectNode*, void*) LLSelectMgr::packShape(LLSelectNode*, void*) LLSelectMgr::repeatDuplicate() LLSelectMgr::selectGetOwnershipCost(int*) LLSelectMgr::selectObjectAndFamily(LLDynamicArray const&, int) LLSelectMgr::selectionGetBumpmap(unsigned char*) LLSelectMgr::selectionGetFullbright(unsigned char*) LLSelectMgr::selectionGetMediaType(unsigned char*) LLSelectMgr::selectionGetShiny(unsigned char*) LLSelectMgr::selectionResetRotation() LLSelectMgr::selectionResetTexInfo(int) LLSelectMgr::selectionRotateAroundZ(float) LLSelectMgr::selectionSetColor(LLColor4 const&) LLSelectMgr::selectionSetObjectCategory(LLCategory const&) LLSelectMgr::selectionUpdateCastShadows(int) LLSelectMgr::sendDehinge() LLSelectMgr::sendHinge(unsigned char) LLSelectMgr::unhighlightObjectAndFamily(LLViewerObject*) LLSetItemSortFunction::doFolder(LLFolderViewFolder*) LLSetItemSortFunction::doItem(LLFolderViewItem*) LLShaderMgr::loadShadersInterface() LLShaderMgr::validateProgramObject(void*) LLSky::calcInScatter(LLColor4&, LLVector3 const&, float) const LLSky::getFadeColor() const LLSky::getFogRatio() const LLSky::getSunPhase() const LLSky::sunUp() const LLSliderCtrl::isMouseHeldDown() LLSliderCtrl::onSliderMouseDown(LLUICtrl*, void*) LLSliderCtrl::onSliderMouseUp(LLUICtrl*, void*) LLSliderCtrl::setSliderMouseDownCallback(void (*)(LLUICtrl*, void*)) LLSliderCtrl::setSliderMouseUpCallback(void (*)(LLUICtrl*, void*)) LLSnapshotLivePreview::getImageRect() LLSpatialClearState::visit(LLOctreeState const*) LLSpatialClearStateDiff::traverse(LLTreeNode const*) LLSpatialGroup::clearState(unsigned int, int) LLSpatialGroup::makeStatic() LLSpatialGroup::validate() LLSpatialGroup::validateDrawMap() LLSpatialPartition::isVisible(LLVector3 const&) LLSpatialPartition::pickDrawable(LLVector3 const&, LLVector3 const&, LLVector3&) LLSpinCtrl::forceEditorCommit() LLSpinCtrl::isMouseHeldDown() LLSplashScreen::create() LLSprite::setColor(LLColor4 const&) LLSprite::setPitch(float) LLSprite::setTexMode(unsigned int) LLSprite::setUseCameraUp(int) LLStat::addValueTime(double, float) LLStat::getBin(int) const LLStat::getBinBeginTime(int) const LLStat::getBinPerSec(int) const LLStat::getCurrentBeginTime() const LLStat::getCurrentTime() const LLStat::getMinDuration() const LLStat::getSum() const LLStat::getSumDuration() const LLStat::setBeginTime(double) LLStatAccum::impl::getCurrentUsecs() const LLStatAccum::impl::meanValue(LLStatAccum::TimeScale) const LLStatAccum::impl::reset(unsigned long long) LLStatAccum::impl::sScaleTimes LLStatAccum::impl::sum(double) LLStatAccum::impl::sum(double, unsigned long long) LLStatAccum::meanValue(LLStatAccum::TimeScale) const LLStatBar::getLabel() const LLStatGraph::setValue(float) LLStatMeasure::sample(double) LLStatRate::count(unsigned int) LLStatTime::start() LLStatTime::stop() LLStatView::getStatBar(LLStringBase const&) LLStateDiagram::addDefaultTransition(LLFSMState&, LLFSMTransition&) LLStateDiagram::addState(LLFSMState*) LLStateDiagram::addTransition(LLFSMState&, LLFSMState&, LLFSMTransition&) LLStateDiagram::addUndirectedTransition(LLFSMState&, LLFSMState&, LLFSMTransition&) LLStateDiagram::getState(unsigned int) LLStateDiagram::numDeadendStates() LLStateDiagram::processTransition(LLFSMState&, LLFSMTransition&) LLStateDiagram::saveDotFile(char const*) LLStateDiagram::setDefaultState(LLFSMState&) LLStateDiagram::stateIsValid(LLFSMState&) LLStateMachine::getCurrentState() const LLStateMachine::processTransition(LLFSMTransition&, void*) LLStateMachine::runCurrentState(void*) LLStateMachine::setCurrentState(LLFSMState*, void*, int) LLStateMachine::setCurrentState(unsigned int, void*, int) LLStateMachine::setStateDiagram(LLStateDiagram*) LLStatusBar::creditBalance(int) LLStatusBar::getHealth() const LLStatusBar::isUserTiered() const LLStrider::operator[](unsigned int) LLStyle::operator!=(LLStyle const&) const LLStyle::operator==(LLStyle const&) const LLSurface::containsPosition(LLVector3 const&) LLSurface::getPatchesPerEdge() const LLSurface::moveZ(int, int, float) LLSurface::renderSurfaceBounds() LLSurface::resolvePatchGlobal(LLVector3d const&) const LLSurfacePatch::getDistance() const LLSurfacePatch::getMeanComposition() const LLSurfacePatch::getRenderLevel() const LLSurfacePatch::getTexCoords(unsigned int, unsigned int) const LLTabContainer::getMaxTabWidth() const LLTabContainer::getMinTabWidth() const LLTabContainerCommon::onCloseBtn(void*) LLTabContainerCommon::setTitle(LLStringBase const&) LLTemplateMessageBuilder::addData(char const*, void const*, e_message_variable_type) LLTexLayer::renderImageRaw(unsigned char*, int, int, int, int, int, int) LLTexLayer::requestUpdate() LLTexLayerSetBuffer::bindBumpTexture(unsigned int) LLTextCmd::overwrite(LLTextEditor*, int, wchar_t) LLTextCmdOverwriteChar::execute(LLTextEditor*, int*) LLTextCmdOverwriteChar::redo(LLTextEditor*) LLTextCmdOverwriteChar::undo(LLTextEditor*) LLTextEditor::fromXML(LLPointer, LLView*, LLUICtrlFactory*) LLTextEditor::getCurrentSegment() LLTextEditor::getWChar(int) LLTextEditor::overwriteChar(int, wchar_t) LLTextEditor::overwriteCharNoUndo(int, wchar_t) LLTextEditor::setHighlightColor(LLColor4 const&) LLTextEditor::setOnScrollEndCallback(void (*)(void*), void*) LLTextEditor::setShadowColor(LLColor4 const&) LLTextEditor::setThumbColor(LLColor4 const&) LLTextEditor::setTrackColor(LLColor4 const&) LLTextSegment::dump() LLTextureAnim::asLLSD() const LLTextureAnim::equals(LLTextureAnim const&) const LLTextureAnim::fromLLSD(LLSD&) LLTextureAnim::packTAMessage(LLDataPacker&) const LLTextureAnim::packTAMessage(LLMessageSystem*) const LLTextureCache::ReadResponder::ReadResponder() LLTextureCache::getReader(unsigned int) LLTextureCache::getWriter(unsigned int) LLTextureCtrl::setLabel(LLStringBase const&) LLTextureCtrl::setValid(int) LLTextureEntry::asLLSD() const LLTextureEntry::fromLLSD(LLSD&) LLTextureEntry::operator!=(LLTextureEntry const&) const LLTextureEntry::operator==(LLTextureEntry const&) const LLTextureFetch::dump() LLTextureFetchWorker::callbackHttpGet(unsigned char*, int, bool) LLTextureFetchWorker::callbackURLReceived(LLSD const&, bool) LLTextureFetchWorker::sStateDescs LLTextureTable::deleteAll() LLThread::wakeLocked() LLThrottleGroup::packThrottle(LLDataPacker&) const LLThrottleGroup::setNominalBPS(float*) LLThrottleGroup::unpackThrottle(LLDataPacker&) LLTimer::getCurrentClockCount() LLTimer::getRemainingTimeF32() LLTimer::getTotalSeconds() LLTimer::getTotalTime() LLTimer::setLastClockCount(unsigned long long) LLToolDragAndDrop::createContainer (LLDynamicArray, 32>&, char const*) LLToolDragAndDrop::dad3dAssetOnLand(LLViewerObject*, int, unsigned int, int) LLToolDragAndDrop::dad3dCategoryOnLand(LLViewerObject*, int, unsigned int, int) LLToolDragAndDrop::dadUpdateInventory(LLViewerObject*, int) LLToolMgr::usingTransientTool() LLToolPie::outsideSlop(int, int, int, int) LLToolPlacerPanel::addButton(LLStringBase const&, LLStringBase const&, unsigned char*) LLToolPlacerPanel::sButtons LLToolPlacerPanel::sButtonsAdded LLToolPlacerPanel::setObjectType(void*) LLToolTexEyedropper::handleHover(int, int, unsigned int) LLToolTexEyedropper::handleMouseDown(int, int, unsigned int) LLToolView::addTool(LLStringBase const&, LLStringBase const&, LLPanel*, LLTool*, LLView*, char const*) LLToolView::draw() LLToolView::findToolContainer(LLTool*) LLToolView::getButtonRect(int) LLToolView::onClickToolButton(void*) LLToolset::isToolSelected(int) LLToolset::selectNextTool() LLToolset::selectPrevTool() LLTracker::getTrackedLocationName() LLTracker::hasLandmarkPosition() LLTransferManager::processTransferPriority(LLMessageSystem*, void**) LLTransferSource::registerSourceType(e_transfer_source_type, LLTransferSource* (*)(LLUUID const&, float)) LLTransferSourceChannel::updatePriority(LLTransferSource*, float) LLTransferSourceParamsEstate::setAsset(LLUUID const&, LLAssetType::EType) LLTriangleLineSegmentIntersect(LLVector3 const&, LLVector3 const&, LLVector3 const&, LLVector3&, LLVector3 const&) LLUI::setScissorRegionScreen(LLRectBase const&) LLUICtrl::getParentPanel() const LLUICtrlFactory::getScrollingPanelList(LLPanel*, LLStringBase const&) LLUICtrlFactory::getWidgetType(LLStringBase const&) LLUICtrlFactory::rebuild() LLUICtrlFactory::removeFloater(LLFloater*) LLUICtrlFactory::removePanel(LLPanel*) LLUIString::clearArgs() LLUIString::replace(int, wchar_t) LLURI::authority() const LLURI::hostName() const LLURI::hostPort() const LLURI::opaque() const LLURI::path() const LLURI::query() const LLURI::queryMap() const LLURI::scheme() const LLURL::free() LLURL::getFQURL() const LLURL::getFullPath() LLURL::init(char const*) LLURL::isExtension(char const*) LLURL::operator!=(LLURL const&) const LLURL::operator=(LLURL const&) LLURL::operator==(LLURL const&) const LLURL::sReturnString LLURL::updateRelativePath(LLURL const&) LLURLRequest::setBodyLimit(unsigned int) LLUUID::combine(LLUUID const&) const LLUUID::getString() const LLUUID::toCompressedString(char*) const LLUUIDAndName::operator<(LLUUIDAndName const&) const LLUUIDAndName::operator==(LLUUIDAndName const&) const LLUUIDAndName::operator>(LLUUIDAndName const&) const LLUniqueID::getID() LLUniqueID::sNextID LLUploadDialog::modalUploadIsFinished() LLUrlWhiteList::cleanupClass() LLUrlWhiteList::containsMatch(LLStringBase const&) LLUrlWhiteList::initClass() LLVFS::audit() LLVFS::checkMem() LLVFS::dumpFiles() LLVFS::dumpMap() LLVFS::listFiles() LLVFSFileBlock::SERIAL_SIZE LLVFSFileSpecifier::operator==(LLVFSFileSpecifier const&) const LLVFile::READ_WRITE LLVFile::getMaxSize() LLVFile::setReadPriority(float) LLVLComposition::getDetailTexture(int) LLVOAvatar::bindScratchTexture(unsigned int) LLVOAvatar::dumpAvatarTEs(char const*) LLVOAvatar::dumpAvatarTEs(char const*)::C.2293 LLVOAvatar::getAnimLabels(LLDynamicArray*) LLVOAvatar::getAnimNames(LLDynamicArray*) LLVOAvatar::getLocalTextureRaw(int, LLImageRaw*) LLVOAvatar::resetAnimations() LLVOAvatar::updateAllAvatarVisiblity() LLVOAvatarSkeletonInfo::getNumBones() LLVOAvatarSkeletonInfo::getNumCollisionVolumes() LLVOCacheEntry::assignCRC(unsigned int, LLDataPackerBinaryBuffer&) LLVOCacheEntry::dump() const LLVOSky::calcInScatter(LLColor3&, LLColor3&, LLVector3 const&, float) const LLVOSky::calcInScatter(LLColor4&, LLVector3 const&, float) const LLVOSky::generateScatterMap() LLVOSky::getFadeColor() const LLVOSky::getFogRatio() const LLVOSky::isSunUp() const LLVOSurfacePatch::updateShadows(int) LLVOTree::render(LLAgent&) LLVOVolume::agentDirectionToVolume(LLVector3 const&) const LLVOVolume::agentPositionToVolume(LLVector3 const&) const LLVOVolume::getLightCutoff() const LLVOVolume::getLightDistance(LLVector3 const&) const LLVOVolume::sLODSlopDistanceFactor LLVOVolume::setLightCutoff(float) LLVOVolume::setTexture(int) LLVOVolume::volumePositionToAgent(LLVector3 const&) const LLVector2::abs() LLVector3::operator=(LLSD const&) LLVector3::rotVec(float, LLVector3 const&) LLVector3::snap(int) LLVector3d::rotVec(LLMatrix3 const&) LLVector3d::rotVec(LLQuaternion const&) LLVector4::abs() LLVector4::rotVec(LLMatrix4 const&) LLVector4::rotVec(LLQuaternion const&) LLVertexBuffer::makeStatic() LLVertexBuffer::setStride(int, int) LLView::addListenerToControl(LLEventDispatcher*, LLStringBase const&, LLSD, LLSD) LLView::deregisterEventListener(LLStringBase) LLView::escapeXML(LLStringBase const&, LLStringBase&) LLView::escapeXML(LLStringBase const&) LLView::getCtrlListSorted() const LLView::getScreenRect() const LLView::hasChild(LLStringBase const&, int) const LLView::sLastBottomXML LLView::sLastLeftXML LLView::sSelectID LLView::selectFontStyle(LLPointer) LLView::selectFontVAlign(LLPointer) LLViewBorder::setColors(LLColor4 const&, LLColor4 const&) LLViewBorder::setColorsExtended(LLColor4 const&, LLColor4 const&, LLColor4 const&, LLColor4 const&) LLViewBorder::setTexture(LLUUID const&) LLViewChildren::enable(char const*, bool) LLViewChildren::setAction(char const*, void (*)(void*), void*) LLViewChildren::show(char const*, bool) LLViewQuery::getPostFilters() const LLViewQuery::getSorter() const LLViewerCamera::roundToPixel(LLVector3 const&) LLViewerGestureList::xferCallback(void*, int, void**, int) LLViewerImage::sCurrentFileVersion LLViewerImageList::calcMaxTextureRAM() LLViewerImageList::dump() LLViewerImageList::sUUIDCallback LLViewerInventoryItem::exportFileLocal(__sFILE*) const LLViewerJoint::setSkeletonComponents(unsigned int, int) LLViewerJointMesh::getBoundJointsByIndex(int, int&, int&) LLViewerJointMesh::getColor(float*, float*, float*, float*) LLViewerJointMesh::sClothingMaskImageName LLViewerJointMesh::sPipelineRender LLViewerJointMesh::writeCAL3D(apr_file_t*, int, LLCharacter*) LLViewerJointShape::drawBone() LLViewerJointShape::drawShape(float, int) LLViewerJointShape::getColor(float*, float*, float*, float*) LLViewerJointShape::getTexture() LLViewerJointShape::getType() LLViewerJointShape::isTransparent() LLViewerJointShape::sColorScale LLViewerJointShape::setColor(float, float, float, float) LLViewerJointShape::setTexture(LLViewerImage*) LLViewerJointShape::setType(LLViewerJointShape::ShapeType) LLViewerLayer::getValue(int, int) const LLViewerObject::clearDrawableState(unsigned int, int) LLViewerObject::countInventoryContents(LLAssetType::EType) LLViewerObject::decreaseArrowLength() LLViewerObject::fitFaceTexture(unsigned char) LLViewerObject::getMediaPassedWhitelist() const LLViewerObject::getMediaType() const LLViewerObject::getMediaURL() const LLViewerObject::getSubParent() const LLViewerObject::increaseArrowLength() LLViewerObject::sAxisArrowLength LLViewerObject::sMapDebug LLViewerObject::sPulseEnabled LLViewerObject::sUseSharedDrawables LLViewerObject::sendPositionUpdate() const LLViewerObject::sendRotationUpdate() const LLViewerObject::sendScaleUpdate() LLViewerObject::setCanSelect(int) LLViewerObject::setData(unsigned char const*, unsigned int) LLViewerObject::setDrawableState(unsigned int, int) LLViewerObject::setLineWidthForWindowSize(int) LLViewerObject::setMediaPassedWhitelist(int) LLViewerObject::setMediaType(unsigned char) LLViewerObject::setMediaURL(LLStringBase const&) LLViewerObjectList::OrphanInfo::operator!= (LLViewerObjectList::OrphanInfo const&) const LLViewerObjectList::findReferences(LLDrawable*) const LLViewerObjectList::renderObjectBounds(LLVector3 const&) LLViewerObjectList::replaceObject(LLUUID const&, unsigned char, LLViewerRegion*) LLViewerParcelMgr::agentCanFly() const LLViewerParcelMgr::agentCanTakeDamage() const LLViewerParcelMgr::agentDrawDistance() const LLViewerParcelMgr::dump() LLViewerParcelMgr::isOwnedAt(LLVector3d const&) const LLViewerParcelMgr::isOwnedOtherAt(LLVector3d const&) const LLViewerParcelMgr::isOwnedSelfAt(LLVector3d const&) const LLViewerParcelOverlay::getOwnedRatio() const LLViewerParcelOverlay::isOwned(LLVector3 const&) const LLViewerParcelOverlay::isOwnedOther(LLVector3 const&) const LLViewerParcelOverlay::ownership(LLVector3 const&) const LLViewerPart::operator=(LLViewerPart const&) LLViewerPartGroup::removePart(int) LLViewerPartSource::updatePart(LLViewerPart&, float) LLViewerPartSourceBeam::updatePart(LLViewerPart&, float) LLViewerRegion::accessToShortString(unsigned char) LLViewerRegion::getInfoString() LLViewerRegion::getPacketsLost() const LLViewerRegion::sendMessage() LLViewerRegion::setAllowDamage(int) LLViewerRegion::setAllowDirectTeleport(int) LLViewerRegion::setAllowLandmark(int) LLViewerRegion::setAllowSetHome(int) LLViewerRegion::setBlockFly(int) LLViewerRegion::setResetHomeOnTeleport(int) LLViewerRegion::setSunFixed(int) LLViewerStats::statTypeToText(LLViewerStats::EStatType) LLViewerThrottle::save() const LLViewerUICtrlFactory::getMediaRemoteByName(LLPanel*, LLStringBase const&) LLViewerWindow::clickPointOnSurfaceGlobal(int, int, LLViewerObject*, LLVector3d&) const LLViewerWindow::dumpState() LLViewerWindow::getKeyboardFocus() LLViewerWindow::getMouseCaptor() const LLViewerWindow::getObjectUnderCursor(float) LLViewerWindow::getProgressView() const LLViewerWindow::hitUIElementAsync(int, int, unsigned int, void (*) (int, int, unsigned int)) LLViewerWindow::hitUIElementImmediate(int, int, void (*)(int, int, unsigned int)) LLViewerWindow::mouseDirectionCamera(int, int) const LLVolume::getTriangleIndices(unsigned int&) const LLVolume::isCap(int) LLVolume::isConvex() const LLVolume::isFaceMaskValid(unsigned short) LLVolume::isFlat(int) LLVolume::lineSegmentIntersect(LLVector3 const&, LLVector3&) const LLVolumeFace::updateColors(LLColor4U*, int, LLVolumeFace const&, LLStrider&, int, LLVolumeFace const&) LLVolumeImplFlexible::getEndPosition() LLVolumeImplFlexible::getEndRotation() LLVolumeImplFlexible::getNodePosition(int) LLVolumeImplFlexible::setCollisionSphere(LLVector3, float) LLVolumeImplFlexible::setParentPositionAndRotationDirectly(LLVector3, LLQuaternion) LLVolumeImplFlexible::setRenderingCollisionSphere(bool) LLVolumeImplFlexible::setUsingCollisionSphere(bool) LLVolumeMessage::packPathParams(LLPathParams const*, LLDataPacker&) LLVolumeMessage::packPathParams(LLPathParams const*, LLDataPacker&)::defaultparams LLVolumeMessage::packProfileParams(LLProfileParams const*, LLDataPacker&) LLVolumeMessage::packProfileParams(LLProfileParams const*, LLDataPacker&)::defaultparams LLVolumeMessage::packVolumeParams(LLVolumeParams const*, LLDataPacker&) LLVolumeParams::asLLSD() const LLVolumeParams::copyParams(LLVolumeParams const&) LLVolumeParams::exportFile(__sFILE*) const LLVolumeParams::fromLLSD(LLSD&) LLVolumeParams::importFile(__sFILE*) LLVolumeParams::isConvex() const LLVolumeParams::operator!=(LLVolumeParams const&) const LLVolumeParams::reduceS(float, float) LLVolumeParams::reduceT(float, float) LLVolumeParams::validate(unsigned char, float, float, float, unsigned char, float, float, float, float, float, float, float, float, float, float, float, float, float) LLWearable::dump() LLWearable::isMatchedToInventoryItem(LLViewerInventoryItem*) LLWearableBridge::canEditOnAvatar(void*) LLWearableBridge::canRemoveFromAvatar(void*) LLWearableBridge::canWearOnAvatar(void*) LLWearableBridge::onEditOnAvatar(void*) LLWearableBridge::onRemoveFromAvatar(void*) LLWearableBridge::onWearOnAvatar(void*) LLWearableList::createLegacyWearableFromAvatar(EWearableType) LLWearableList::createWearableMatchedToInventoryItem(LLWearable*, LLViewerInventoryItem*) LLWebBrowserCtrl::getHomePageUrl() LLWind::renderVectors() LLWindowMacOSX::getCursor() LLWindowMacOSX::getFullscreen() LLWindowMacOSX::minimize() LLWindowMacOSX::resetDisplayResolution() LLWindowMacOSX::restore() LLWindowManager::createWindow(char*, char*, LLCoordScreen, LLCoordScreen, unsigned int, int, int, int, int, int) LLWindowManager::isWindowValid(LLWindow*) LLWorkerClass::setWorkerThread(LLWorkerThread*) LLWorkerClass::yield() LLWorld::disconnectRegions() LLWorld::getInfoString() LLWorld::getLandFarClip() const LLWorld::printPacketsLost() LLWorld::resolveLandPatchGlobal(LLVector3d const&) LLWorld::resolveRegionAgent(LLVector3&, LLVector3 const&) LLWorldMap::coveredByTelehub(LLSimInfo*) LLWorldMap::dump() LLWorldMap::updateTelehubCoverage() LLWorldMapView::drawDots() LLWorldMapView::setDirectionPos(LLTextBox*, float) LLWorldMapView::translatePan(int, int) LLXMLNode::appendValue(LLStringBase const&) LLXMLNode::deleteChild(LLXMLNode*) LLXMLNode::deleteChildren(LLStringBase const&) LLXMLNode::deleteChildren(LLStringTableEntry*) LLXMLNode::getAttributeColor4(LLStringBase const&, LLColor4&) LLXMLNode::getAttributeColor4U(LLStringBase const&, LLColor4U&) LLXMLNode::getAttributeF64(LLStringBase const&, double&) LLXMLNode::getAttributeQuat(LLStringBase const&, LLQuaternion&) LLXMLNode::getAttributeS16(LLStringBase const&, short&) LLXMLNode::getAttributeS8(LLStringBase const&, signed char&) LLXMLNode::getAttributeU16(LLStringBase const&, unsigned short&) LLXMLNode::getAttributeU8(LLStringBase const&, unsigned char&) LLXMLNode::getAttributeVector3(LLStringBase const&, LLVector3&) LLXMLNode::getAttributeVector3d(LLStringBase const&, LLVector3d&) LLXMLNode::getByteValue(unsigned int, unsigned char*, LLXMLNode::Encoding) LLXMLNode::getChild(LLStringBase const&, LLPointer&, int) LLXMLNode::getChild(LLStringTableEntry const*, LLPointer&, int) LLXMLNode::getChildCount() const LLXMLNode::getID() const LLXMLNode::isNull() LLXMLNode::scrubToTree(LLXMLNode*) LLXMLNode::setAttributeString(LLStringBase const&, LLStringBase const&) LLXMLNode::setAttributes(LLXMLNode::ValueType, unsigned int, LLXMLNode::Encoding, unsigned int) LLXMLNode::writeHeaderToFile(__sFILE*) LLXMLNode::writeToFile(__sFILE*, LLStringBase) LLXMLRPCValue::append(char const*, LLXMLRPCValue&) LLXMLRPCValue::appendBool(bool) LLXMLRPCValue::appendBool(char const*, bool) LLXMLRPCValue::appendDouble(char const*, double) LLXMLRPCValue::appendDouble(double) LLXMLRPCValue::appendInt(int) LLXMLRPCValue::asDouble() const LLXMLRPCValue::free() LLXORCipher::operator=(LLXORCipher const&) LLXformMatrix::getMinMax(LLVector3&, LLVector3&) const LLXmlParser::getCurrentColumnNumber() LLXmlParser::parse(char const*, int, int) LLXmlTree::dump() LLXmlTree::dumpNode(LLXmlTreeNode*, LLStringBase const&) LLXmlTreeNode::dump(LLStringBase const&) LLXmlTreeNode::getTextContents() LoadCol(DPCOMPLEX*, COMPLEX*, unsigned int, unsigned int, unsigned int) LoadRow(DPCOMPLEX*, COMPLEX*, unsigned int, unsigned int) OrderToString(LLQuaternion::Order) R2TX(int, DPCOMPLEX*, DPCOMPLEX*) R4TX(int, DPCOMPLEX*, DPCOMPLEX*, DPCOMPLEX*, DPCOMPLEX*) R8TX(int, int, int, DPCOMPLEX*, DPCOMPLEX*, DPCOMPLEX*, DPCOMPLEX*, DPCOMPLEX*, DPCOMPLEX*, DPCOMPLEX*, DPCOMPLEX*) StoreCol(DPCOMPLEX*, COMPLEX*, unsigned int, unsigned int, unsigned int) StoreRow(DPCOMPLEX*, COMPLEX*, unsigned int, unsigned int) _AVATAR_OFFSET_NORMAL _AVATAR_OFFSET_POS _AVATAR_OFFSET_TEX0 _AVATAR_OFFSET_TEX1 _AVATAR_VERTEX_BYTES _AddFormInfo _BEAM_SPACING _BLOGS_URL _BTN_GRID _BUY_CURRENCY_URL _CATEGORY_INDEX _CATEGORY_NAME _CLOTHING_ACCEL_FORCE_FACTOR _COMPASS_RANGE _COMPASS_SIZE _CONE_SIZE _CRYPTO_cleanup_all_ex_data _DebugDetailMap _END_OF_PATCHES _ERR_free_strings _EVP_cleanup _FIND_HINT _FLEXIBLE_OBJECT_DEFAULT_LENGTH _FLEXIBLE_OBJECT_DEFAULT_RENDERING_COLLISION_SPHERE _FLEXIBLE_OBJECT_DEFAULT_USING_COLLISION_SPHERE _FOLDER_INCLUDES_ATTACHMENTS_BEING_WORN _K256 _K512 _LAND_URL _LEGACY_NON_HEADER _LIGHT_DEFAULT_CUTOFF _LIGHT_DEFAULT_FALLOFF _LIGHT_DEFAULT_RADIUS _LLSDRPC_FAULT_FOOTER _LLSDRPC_FAULT_HADER_1 _LLSDRPC_FAULT_HADER_2 _LLSDRPC_REQUEST_FOOTER _LLSDRPC_REQUEST_HEADER_1 _LLSDRPC_REQUEST_HEADER_2 _LLSDRPC_RESPONSE_FOOTER _LLSDRPC_RESPONSE_HEADER _LL_SMACKDOWN_SIGNAL _LSL_DOC_URL _Laguerre_With_Deflation _MANAGE_ACCOUNT _MAX_MESSAGE_AGE _MAX_PART_SCALE _NAME_SEARCH_DESC _NEGATIVE_VALUE _NEVER_CHAIN_EXPIRY_SECS _Newton_Raphson _OBJECT_CUT_INC _OBJECT_CUT_MAX _OBJECT_CUT_MIN _OBJECT_REV_INC _OBJECT_REV_MAX _OBJECT_REV_MIN _PARCEL_ACTION_STRING _PARCEL_OWNERSHIP_STATUS_STRING _PING_INTERVAL_ALARM _POSITIVE_VALUE _Q_AtHead _Q_AtTail _Q_DelCur _Q_Find _Q_Get _Q_Insert _Q_IsEmpty _Q_Iter_Del _Q_Iter_Get _Q_Iter_Head _Q_Iter_Next _Q_Iter_Prev _Q_Iter_Put _Q_Iter_Tail _Q_PopTail _Q_Previous _Q_PushHead _Q_Put _Q_Seek _Q_Sort _Q_Tail _QuickSort _RELEASE_NOTES _RepadBitmap _SCRIPT_DIALOG_HEADER _SHORT_CHAIN_EXPIRY_SECS _SL_KB_URL _SOAP_VALUE_to_xml_element _SSLeay _THROTTLE_NAMES _TIER_UP_URL _TRANSACTION_FLAGS_NONE _TRANSACTION_FLAG_DEST_GROUP _TRANSACTION_FLAG_OWNER_GROUP _TRANSACTION_FLAG_SIMULTANEOUS_CONTRIBUTION _TRANSACTION_FLAG_SIMULTANEOUS_CONTRIBUTION_REMOVAL _TRANSACTION_FLAG_SOURCE_GROUP _UPGRADE_TO_PREMIUM_URL _VIA_URL _VOTE_ABSTAIN _VOTE_MAJORITY _VOTE_NO _VOTE_SUPER_MAJORITY _VOTE_UNANIMOUS _VOTE_YES _WIND_ALTITUDE _XmlGetUtf16InternalEncoding _XmlGetUtf16InternalEncodingNS _XmlPrologStateInitExternalEntity _XmlUtf16Encode _ZERO_CODE _ZERO_EOB add_use_callback(char*, void (*)(LLNameValue*, void**), void**) angle_between(LLVector2 const&, LLVector2 const&) angle_between(LLVector4 const&, LLVector4 const&) append_aggregate(LLStringBase&, LLAggregatePermissions const&, unsigned int, char const*) are_parallel(LLVector2 const&, LLVector2 const&, float) are_parallel(LLVector4 const&, LLVector4 const&, float) assert_glerror() asset_callback_nothing(LLVFS*, LLUUID const&, LLAssetType::EType, void*, int) b_integer_ok(char*) callback_leave_group(int, void*) callback_show_buy_currency(int, void*) catch_signals() category_to_string(LLParcel::ECategory) category_ui_string_to_category(char const*) check_same_clock_dir(LLVector3 const&, LLVector3 const&, LLVector3 const&, LLVector3 const&) check_toggle_control(LLUICtrl*, void*) clear_glerror() clear_signals() click_popup_done(void*) click_popup_dozer_size(LLUICtrl*, void*) click_popup_info(void*) click_popup_rotate_left(void*) click_popup_rotate_reset(void*) click_popup_rotate_right(void*) code_end_of_data(LLBitPack&) code_patch(LLBitPack&, int*, int) code_patch_group_header(LLBitPack&, LLGroupHeader*) code_patch_header(LLBitPack&, LLPatchHeader*, int*) color_avg(LLColor3 const&) commit_radio_zoom(LLUICtrl*, void*) compare_int(void const*, void const*) copy_selected_item(void*) curlOutputCallback(void*, unsigned long, unsigned long, void*) decompress_patchv(LLVector3*, int*, LLPatchHeader*) default_unix_signal_handler(int, __siginfo*, void*) delete_selected_item(void*) disabled_duplicate(void*) dist_vec(LLVector2 const&, LLVector2 const&) dist_vec_squared(LLVector2 const&, LLVector2 const&) dist_vec_squared2D(LLVector2 const&, LLVector2 const&) drawBars(float, float, float) elevation_from_vector(LLVector3 const&) enable_activate(void*) enable_deed_object_to_group(void*) enable_dehinge(void*) enable_export_selected(void*) enable_god_full(void*) enable_god_liaison(void*) enable_has_attachments(void*) enable_land_build(void*) enable_land_selected(void*) enable_more_than_one_selected(void*) enable_never(void*) enable_not_thirdperson(void*) enable_object_build(void*) enable_region_owner(void*) enable_selection_you_own_all(void*) enable_selection_you_own_one(void*) encode_vorbis_file(char const*, char const*) end_patch_coding(LLBitPack&) eq_message_throttle_entry(LLMessageThrottleEntry, LLMessageThrottleEntry) equalTriangle(int const*, int const*) export_complete() exported_item_complete(e_status_codes, void*) exported_j2c_complete(e_status_codes, void*) fastlog2(int) fft(LLFFTPlan const&, COMPLEX*, int, int, int) find_file(LLStringBase&, signed char*) first_run_dialog_callback(int, void*) flush_glerror() force_breakpoint(void*) get_child_status(int, int&, bool&, bool) get_extension(LLAssetType::EType) get_family_count(LLViewerObject*) get_sender_ip() get_sender_port() gl_corners_2d(int, int, int, int, int, float) gl_draw_rotated_image(int, int, float, LLImageGL*, LLColor4 const&) gl_draw_scaled_image_inverted(int, int, int, int, LLImageGL*, LLColor4 const&) gl_rect_2d_xor(int, int, int, int) handle_activate(void*) handle_agent_stop_moving(void*) handle_buy_currency(void*) handle_crash(void*) handle_debug_avatar_textures(void*) handle_deed_object_to_group(void*) handle_dehinge(void*) handle_disconnect_viewer(void*) handle_dump_avatar_local_textures(void*) handle_dump_image_list(void*) handle_duplicate_in_place(void*) handle_events(void*) handle_export_selected(void*) handle_focus(void*) handle_follow(void*) handle_force_unlock(void*) handle_fullscreen_debug(void*) handle_god_request_havok(void*) handle_hinge(void*) handle_leave_group(void*) handle_lptop(void*) handle_mouselook(void*) handle_move(void*) handle_ptop(void*) handle_region_clear_temp_asset_data(void*) handle_reload_settings(void*) handle_repeat_duplicate(void*) handle_reset_selection(void*) handle_set_not_run_selection(void*) handle_set_run_selection(void*) handle_show_mean_events(void*) handle_show_newest_map(void*) handle_show_overlay_title(void*) handle_test_load_url(void*) handle_upload(void*) handle_upload_object(void*) handle_wheel(void*) hide_top_view(LLView*) idct_column_large(float*, float*, int) idct_line_large(float*, float*, int) im_info_to_llsd(LLPointer) init_cache()::cache_version init_crash_handler() init_patch_coding(LLBitPack&) init_patch_decoding(LLBitPack&) is_agent_in_region(LLViewerRegion*, LLSimInfo*) is_asset_id_knowable(LLAssetType::EType) is_cf_update_time(unsigned char) is_daylight_savings() is_inventory_visible(void*) is_tf_dest_group(unsigned char) is_tf_owner_group(unsigned char) is_tf_source_group(unsigned char) item_date_sort(LLInventoryItem*, LLInventoryItem*) item_dictionary_sort(LLInventoryItem*, LLInventoryItem*) item_name_precedes(LLInventoryItem*, LLInventoryItem*) label_touch(LLStringBase&, void*) lat2xyz(LLVector3*, float, float) lat2xyz_rad(LLVector3*, float, float) lerp(float, LLQuaternion const&) lessTriangle::operator()(int const*, int const*) lessVertex::operator()(LLVertexIndexPair const*, LLVertexIndexPair const*) ll_allocate(unsigned long) ll_apr_assert_status(int) ll_apr_dir_make(LLStringBase const&, apr_pool_t*) ll_apr_dir_remove(LLStringBase const&, apr_pool_t*) ll_apr_file_rename(LLStringBase const&, LLStringBase const&, apr_pool_t*) ll_binary_from_string(LLSD const&) ll_color4_from_sd(LLSD const&) ll_create_category_from_sd(LLSD const&) ll_create_item_from_sd(LLSD const&) ll_create_sd_from_inventory_category(LLPointer) ll_create_sd_from_inventory_item(LLPointer) ll_create_sd_from_permissions(LLPermissions const&) ll_create_sd_from_sale_info(LLSaleInfo const&) ll_drand() ll_drand(double) ll_ntohd(double) ll_ntohll(unsigned long long) ll_permissions_from_sd(LLSD const&) ll_print_sd(LLSD const&) ll_print_sd(LLSD const&)::buffer ll_release(void*) ll_sale_info_from_sd(LLSD const&) ll_sd_from_color4(LLColor4 const&) ll_sd_from_vector2(LLVector2 const&) ll_string_from_binary(LLSD const&) ll_vector2_from_sd(LLSD const&) llstrtou64(char const*, char**, int) llyield() login_done(int, void*) lsa_cat_lists(unsigned char*, int, int, int) lsa_cat_strings(unsigned char*, int, int, int) lsa_cmp_lists(unsigned char*, int, int) lsa_cmp_strings(unsigned char*, int, int) lsa_create_heap(unsigned char*, int) lsa_decrease_ref_count(unsigned char*, int) lsa_fprint_heap(unsigned char*, __sFILE*) lsa_get_data(unsigned char*, int&, int) lsa_get_list_ptr(unsigned char*, int&, int) lsa_heap_add_data(unsigned char*, LLScriptLibData*, int, int) lsa_heap_top(unsigned char*, int) lsa_increase_ref_count(unsigned char*, int) lsa_insert_data(unsigned char*, int&, LLScriptLibData*, LLScriptAllocEntry&, int) lsa_postadd_lists(unsigned char*, int, LLScriptLibData*, int) lsa_preadd_lists(unsigned char*, LLScriptLibData*, int, int) lsa_print_heap(unsigned char*) lsa_randomize(LLScriptLibData*, int) lsa_split_block(unsigned char*, int&, int, LLScriptAllocEntry&) lscript_compile(char*, int) main::enable_threads menu_check_build_tool(void*) menu_ui_enabled(void*) nlerp(float, LLQuaternion const&) open_selected_items(void*) operator!=(LLMatrix3 const&, LLMatrix3 const&) operator!=(LLMatrix4 const&, LLMatrix4 const&) operator!=(LLNameValue const&, LLNameValue const&) operator!=(LLUniqueID const&, LLUniqueID const&) operator!=(LLViewHandle const&, LLViewHandle const&) operator%(LLNameValue const&, LLNameValue const&) operator%(LLNameValue const&, LLNameValue const&)::retval operator*(LLBBoxLocal const&, LLMatrix4 const&) operator*(LLNameValue const&, LLNameValue const&) operator*(LLNameValue const&, LLNameValue const&)::retval operator*(LLNameValue const&, float) operator*(LLNameValue const&, float)::retval operator*(LLVector4 const&, LLQuaternion const&) operator*(float, LLNameValue const&) operator*(float, LLNameValue const&)::retval operator*=(LLMatrix3&, LLMatrix3 const&) operator*=(LLMatrix4&, float) operator+(LLNameValue const&, LLNameValue const&) operator+(LLNameValue const&, LLNameValue const&)::retval operator-(LLNameValue const&) operator-(LLNameValue const&)::retval operator-(LLNameValue const&, LLNameValue const&) operator-(LLNameValue const&, LLNameValue const&)::retval operator/(LLNameValue const&, LLNameValue const&) operator/(LLNameValue const&, LLNameValue const&)::retval operator<(LLNameValue const&, LLNameValue const&) operator<=(LLNameValue const&, LLNameValue const&) operator==(LLColor4 const&, LLColor3 const&) operator==(LLMatrix3 const&, LLMatrix3 const&) operator==(LLMatrix4 const&, LLMatrix4 const&) operator==(LLNameValue const&, LLNameValue const&) operator==(LLUniqueID const&, LLUniqueID const&) operator>(LLNameValue const&, LLNameValue const&) operator>=(LLNameValue const&, LLNameValue const&) ownership_status_to_string(LLParcel::EOwnershipStatus) ownership_string_to_status(char const*) paste_items(void*) phi_spring(float, float) power_of_2(int) pref_min_height() pref_min_width() print_packets_lost(void*) promote(e_lscript_types, e_lscript_types) properties_selected_items(void*) pushVertsColorCoded(LLSpatialGroup*, unsigned int)::col_count releaseImageCursor(void*) reload_ui(void*) rotate_quat(LLQuaternion&) rotate_vector(LLVector4 const&, LLMatrix4 const&) round_up(int, int) save_avatar(void*) scale_stamp(float, float, float, float) secondsToTimecodeString(float, char*) setVecZ(LLVector3&) setup_signals() show_buy_currency(char const*) show_first_run_dialog() show_permissions_control(void*) show_window_creation_error(char const*) signal_handlers(int) slerp(float, LLQuaternion const&) stamp(float, float, float, float) test_callback(e_status_codes) test_llxmltree() theta_spring(float, float) toggle_cull_small(void*) toggle_map(void*) toggle_wind_audio() ui_point_in_rect(int, int, int, int, int, int) unsigned long llhash(char const*) utf16chars_to_utf8chars(unsigned short const*, char*, int*) utf8str_to_utf16str(LLStringBase const&) vec3to4(LLColor3 const&) vec3to4(LLVector3 const&) vec4to3(LLColor4 const&) viewer_crash_callback() void DeletePointer::operator()(LLVertexIndexPair*) const From dzonatas at dzonux.net Mon Jun 4 22:48:58 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jun 4 22:47:24 2007 Subject: [sldev] Re: dead code In-Reply-To: <5C75920C-8346-484A-915D-D185F5C96F78@mm.st> References: <46545C49.9080202@lindenlab.com> <5C75920C-8346-484A-915D-D185F5C96F78@mm.st> Message-ID: <4664F94A.6000004@dzonux.net> I can confirm this one is not used: Ben Byer wrote: > LLVertexBuffer::setStride(int, int) -- From monkowsk at watson.ibm.com Tue Jun 5 08:13:35 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jun 5 08:13:42 2007 Subject: [sldev] Doxygen config file? In-Reply-To: <466438F2.3090707@ucsd.edu> References: <466438F2.3090707@ucsd.edu> Message-ID: <46657D9F.8050606@watson.ibm.com> Max Okumoto wrote: > Is there a doxygen config file for the viewer source code? It looks > like most of the files have javadoc style file headers. > > I'm attaching one that I created, but if there is an official version it > would be nice if was in the distribution. Most of the doxygen parameters reflect a person's personal preferences in what they like to see and how long they're willing to wait for it to complete execution, so I doubt there could be an official version. Mike From okumoto at ucsd.edu Tue Jun 5 09:13:37 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Tue Jun 5 09:13:49 2007 Subject: [sldev] Doxygen config file? In-Reply-To: <46657D9F.8050606@watson.ibm.com> References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> Message-ID: <46658BB1.20003@ucsd.edu> Hi Mike, Thats very true. But if its there and documented it would help people new to the code. Not everyone knows about such tools, and in an indirect way I'm asking what they use :-) Would patches which add javadoc type comments to functions be welcome? I usually add comments to code that I am trying to understand. Max Mike Monkowski wrote: > Max Okumoto wrote: >> Is there a doxygen config file for the viewer source code? It looks >> like most of the files have javadoc style file headers. >> >> I'm attaching one that I created, but if there is an official version it >> would be nice if was in the distribution. > > Most of the doxygen parameters reflect a person's personal preferences > in what they like to see and how long they're willing to wait for it > to complete execution, so I doubt there could be an official version. > > Mike From gwardell at ApprovalSystems.net Tue Jun 5 12:24:42 2007 From: gwardell at ApprovalSystems.net (Gary Wardell) Date: Tue Jun 5 12:24:52 2007 Subject: [sldev] FYI In-Reply-To: <46658BB1.20003@ucsd.edu> Message-ID: <017b01c7a7a7$2be2a840$a4689943@gwsystems2.com> Hi, Is anyone concerned that everything on this list is published on a public website that is googelable, along with e-mail full addresses? I found this when goggling my name https://lists.secondlife.com/pipermail/sldev/2007-February.txt Yes, some of the addresses are listed as "name at domain", but that is probably well known to spammers by now and easily unmunged. Gary From gigstaggart at gmail.com Tue Jun 5 13:48:44 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 5 13:48:50 2007 Subject: [sldev] FYI In-Reply-To: <017b01c7a7a7$2be2a840$a4689943@gwsystems2.com> References: <017b01c7a7a7$2be2a840$a4689943@gwsystems2.com> Message-ID: <4665CC2C.6090504@gmail.com> Gary Wardell wrote: > Hi, > > Is anyone concerned that everything on this list is published on a public website that is googelable, along with e-mail full > addresses? No, not really. Standard practice on open source lists. -Jason From kamilion at gmail.com Tue Jun 5 15:20:57 2007 From: kamilion at gmail.com (Kamilion) Date: Tue Jun 5 15:20:59 2007 Subject: [sldev] FYI In-Reply-To: References: <017b01c7a7a7$2be2a840$a4689943@gwsystems2.com> <4665CC2C.6090504@gmail.com> Message-ID: In fact, IIRC, the sldev google coop search should have picked every archived mail here, available here: http://tinyurl.com/yflh2s -- http://www.google.com/coop/cse?cx=001010425210852223575%3Aogwhgz5_tue created by Pathfinder Linden. I'm guessing this would likely add all the results into a standard google search as well. Besides, spamassassin / gmail / google apps for your domain mail / other RBL email filters work wonders on most spam. I've gotten maybe 5 messages it didn't catch when those stock-touting images were being sent around, and I'm on all sorts of mailing lists like bugtraq, full-disclosure, sldev, colinux, and many other FOSS MLs. Get a CPU to do the work for you ;) > On 6/5/07, Jason Giglio wrote: > > Gary Wardell wrote: > > > Hi, > > > > > > Is anyone concerned that everything on this list is published on a public website that is googelable, along with e-mail full > > > addresses? > > > > No, not really. Standard practice on open source lists. > > > > -Jason > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From james at lindenlab.com Tue Jun 5 22:32:05 2007 From: james at lindenlab.com (James Cook) Date: Tue Jun 5 22:32:07 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <46641A57.6000409@blueflash.cc> References: <466324A5.2040908@blueflash.cc> <466331B2.5000506@dzonux.net> <46641A57.6000409@blueflash.cc> Message-ID: <466646D5.4050500@lindenlab.com> > I was just running around sims with all stuff enabled (I really don't > want to spend much time on this as it's unlikely that anything like > a major change in project settings will ever make it into the SL build), Don't give up on compiler options! I would happily accept a patch that changed compiler optimization options, especially if there were benchmark results to demonstrate the benefits. Keep in mind though that we have to support many different processor and OS combinations. Steve may have more recent stats on what chips our users are actually using, but I would be a little nervous, for example, deciding to drop support for PIII chips without a solid benchmark. We don't really want to be doing multiple Windows builds internally. I would be curious about benchmarks where SSE code generation was turned on for all files. James From able.whitman at gmail.com Tue Jun 5 23:24:33 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jun 5 23:24:40 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <466646D5.4050500@lindenlab.com> References: <466324A5.2040908@blueflash.cc> <466331B2.5000506@dzonux.net> <46641A57.6000409@blueflash.cc> <466646D5.4050500@lindenlab.com> Message-ID: <7b3a84fb0706052324t2ef21f55ue8189c0f45c89c5d@mail.gmail.com> In terms of optimizations for Windows builds, Visual C++ 2005 helps somewhat in this regard, since they have removed processor-specific optimization options in the 2005 version of the C++ compiler: "In Visual C++ 2005, the /G3-/G7 options have been removed in favor of a 'blended model' that generates code that works well across all of the architectures. With no processor-specific optimization switches to worry about, optimizations are now controlled exclusively using the /O family of switches." (see: http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/VS2005pro/Framework/CPlus32BitOptimization.htm ) This is also noted in the "Breaking Changes in the Visual C++ 2005 Compiler" (see: http://msdn2.microsoft.com/en-us/library/ms177253(vs.80).aspx). Although I don't believe the omission of processor-specific flags is truly a breaking change, since the compiler just ignores them if they are present. Also of interest to those on SLDev using the VC++ 2005 Express Edition, I found this note in the compiler help: "/G is available in all editions of Visual C++, but the compiler can perform more optimizations when /G is used with one of the /O compiler options. However, /O is not available in the Visual C++ standard edition." (see: http://msdn2.microsoft.com/en-us/library/h66s5s0e(VS.80).aspx) I believe this statement is in error, however, since I have the Standard edition of VS 2005, and inspecting the generated code shows that the compiler is respecting the various /O optimization flags. I believe this is the case also for the Express edition, although I can't find documentation that absolutely confirms this. The closest I can find is this statement in the VC++ FAQ: "Yes, Visual C++ 2005 Express Edition includes the same core optimizing compiler that will be included with all other Visual Studio 2005 editions. Some new expanded optimization features, including Profile Guided Optimizations, will be available only in the Professional and above editions of Visual Studio 2005." (see: http://msdn.microsoft.com/vstudio/express/support/faq/#vcpp) So I'm pretty sure that VC++ Express is only missing the profile guided optimizations, although again, I am not completely certain. In any case, using VC++ 2005 would allow for an optimized Windows binary that makes use of inline expansion and other such optimzations, but which is still not processor-specific. --Able On 6/6/07, James Cook wrote: > > > I was just running around sims with all stuff enabled (I really don't > > want to spend much time on this as it's unlikely that anything like > > a major change in project settings will ever make it into the SL build), > > Don't give up on compiler options! I would happily accept a patch that > changed compiler optimization options, especially if there were > benchmark results to demonstrate the benefits. > > Keep in mind though that we have to support many different processor and > OS combinations. Steve may have more recent stats on what chips our > users are actually using, but I would be a little nervous, for example, > deciding to drop support for PIII chips without a solid benchmark. We > don't really want to be doing multiple Windows builds internally. > > I would be curious about benchmarks where SSE code generation was turned > on for all files. > > James > > _______________________________________________ > 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/20070606/1bb53397/attachment.htm From blindwanderer at gmail.com Wed Jun 6 00:31:43 2007 From: blindwanderer at gmail.com (Strife Onizuka) Date: Wed Jun 6 00:31:45 2007 Subject: [sldev] FYI In-Reply-To: References: <017b01c7a7a7$2be2a840$a4689943@gwsystems2.com> <4665CC2C.6090504@gmail.com> Message-ID: <89ca6da00706060031r28965b2bj21b04c3741aa5a8c@mail.gmail.com> When the list was made public it was recommended that we all get gmail accounts (or maybe i'm thinking of the scripting list?). On 6/5/07, Kamilion wrote: > > In fact, IIRC, the sldev google coop search should have picked every > archived mail here, available here: http://tinyurl.com/yflh2s -- > http://www.google.com/coop/cse?cx=001010425210852223575%3Aogwhgz5_tue > created by Pathfinder Linden. > I'm guessing this would likely add all the results into a standard > google search as well. > > Besides, spamassassin / gmail / google apps for your domain mail / > other RBL email filters work wonders on most spam. I've gotten maybe 5 > messages it didn't catch when those stock-touting images were being > sent around, and I'm on all sorts of mailing lists like bugtraq, > full-disclosure, sldev, colinux, and many other FOSS MLs. > > Get a CPU to do the work for you ;) > > > > On 6/5/07, Jason Giglio wrote: > > > Gary Wardell wrote: > > > > Hi, > > > > > > > > Is anyone concerned that everything on this list is published on a > public website that is googelable, along with e-mail full > > > > addresses? > > > > > > No, not really. Standard practice on open source lists. > > > > > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070606/e8fda9df/attachment.htm From nicholaz at blueflash.cc Wed Jun 6 03:33:34 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 6 03:33:44 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <7b3a84fb0706052324t2ef21f55ue8189c0f45c89c5d@mail.gmail.com> References: <466324A5.2040908@blueflash.cc> <466331B2.5000506@dzonux.net> <46641A57.6000409@blueflash.cc> <466646D5.4050500@lindenlab.com> <7b3a84fb0706052324t2ef21f55ue8189c0f45c89c5d@mail.gmail.com> Message-ID: <46668D7E.4070307@blueflash.cc> Able Whitman wrote: > This is also noted in the "Breaking Changes in the Visual C++ 2005 > Compiler" (see: > http://msdn2.microsoft.com/en-us/library/ms177253(vs.80).aspx > ). > Although I don't believe the omission of processor-specific flags is > truly a breaking change, since the compiler just ignores them if they > are present. LOL, that's the kind of stuff many companies are doing, like trying to sell you something that takes away something you had as being good. The "blended" model was there in VS2003 as well and is what Linden has enabled in their builds already. Nick From nicholaz at blueflash.cc Wed Jun 6 03:45:59 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 6 03:46:06 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <466646D5.4050500@lindenlab.com> References: <466324A5.2040908@blueflash.cc> <466331B2.5000506@dzonux.net> <46641A57.6000409@blueflash.cc> <466646D5.4050500@lindenlab.com> Message-ID: <46669067.4040606@blueflash.cc> James Cook wrote: > Don't give up on compiler options! I would happily accept a patch that > changed compiler optimization options, especially if there were > benchmark results to demonstrate the benefits. > > Keep in mind though that we have to support many different processor and > OS combinations. Steve may have more recent stats on what chips our > users are actually using, but I would be a little nervous, for example, > deciding to drop support for PIII chips without a solid benchmark. We > don't really want to be doing multiple Windows builds internally. > > I would be curious about benchmarks where SSE code generation was turned > on for all files. Unfortunately I'm hardly in the position to do any proper profiling, much less on different hardware platforms. As I said, this was just a quick hack because I wanted to see if it did anything noteworthy. What I'm wondering about is that not even "favor speed over size" was enabled in the projects. From what I saw as a result, the size didn't grow to any meaningful extent, dunno if it had any impact on speed though, because I was turning on those features all at once. I don't know about PIII processors, also not how P4 optimization would affect AMD's, but from what I can say from hands on experience with my laptop, I doubt that your minimal requirement of a PIII/256MB will allow for any meaningful experience, besides a SL slideshow maybe (even running SL on a P4/1.6GHz/512MB/ATIX300 mobile was a pain and that configuration is a long way head of of a PIII/800/256MB). For anyone wanting to try it, the process is quite simple. Just mark all projects, except script_fb, go Properties and you can set the options for all at once. Some of them may be helpful processor independent (although agressive inlining will make the crash dumps less readable), but I don't have the expertise or controlled environments where I could make any solid conclusions. I can say, that I'm seeing higher FPSs than before in some situations and on the same machine (even with all my patches applied, so it's not the patches) but that's merely a starting point. Nick From odysseus654 at gmail.com Wed Jun 6 08:27:53 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Wed Jun 6 08:27:56 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <46669067.4040606@blueflash.cc> References: <466324A5.2040908@blueflash.cc> <466331B2.5000506@dzonux.net> <46641A57.6000409@blueflash.cc> <466646D5.4050500@lindenlab.com> <46669067.4040606@blueflash.cc> Message-ID: <1674f6c70706060827g7c9e407hc2973464c11ead0@mail.gmail.com> I don't remember where I read it, but I believe I heard that this switch is best set to "size" for most general applications, with the speed optimizations added on. SecondLife isn't exactly a "general application" though... On 6/6/07, Nicholaz Beresford wrote: > > What I'm wondering about is that not even "favor speed over size" was > enabled in the projects. From what I saw as a result, the size didn't > grow to any meaningful extent, dunno if it had any impact on speed > though, because I was turning on those features all at once. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070606/455ce3d2/attachment.htm From matthew.dowd at hotmail.co.uk Wed Jun 6 10:02:10 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jun 6 10:02:11 2007 Subject: [sldev] Moving the permissions window Message-ID: I raised this with Rob Linden, who suggested I post the issue here. It also relates to Able Whitman's recently debit permissions patch. As well as making the permissions dialog different, I would suggest moving it to a different part of the window than the normal permissions. Whenever I buy from a vendor in SL, typically two windows pop-up ("You have paid xxx" following by "You have received..."), I've lost count how many times I have gone to click on the former, and the latter has popped up just as I click, and I end up clicking (luckily on keep) in the former. Maybe by timing is just strangely tuned to the delay between the two popup windows ;-) It did occur to me, that it would be very easy to script a dialog followed by the permissions request, in the hope that someone would go to close the first and end up accepting the permission by mistake. The solution would be to have the window appear somewhere different from the normal dialogs. In many ways this would also have the effect of highlighting the window as different (as per Able Whitman's patch) but in a manner which would also work fo those suffering colour blindness. Matthew _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From able.whitman at gmail.com Wed Jun 6 11:51:29 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 6 11:51:31 2007 Subject: [sldev] Moving the permissions window In-Reply-To: References: Message-ID: <7b3a84fb0706061151u473d1099od0f7c2177cdb2baa@mail.gmail.com> The current version of the patch, which is attached to VWR-650, doesn't move the permissions notification, but it does alter the notification in other ways to help make the changes readily apparent even to users with color blindness: * the debit notification window is much taller than the standard notification, which mitigates the "accidental click-through" problem * the debit notification includes an additional textual warning at the top of the window, in bold white (in contrast to the non-bold black text on the rest of the window) * the debit notification uses a different icon in the upper-left corner * instead of 2 buttons, "Yes" and "No", the debit notification has 3 buttons, "Grant", "Deny", and "Details..." (the 3rd button raising a modal alert with more information about the debit permission) It would certainly be possible to do something like move the debit permission notification to another corner of the screen, or even to move it to the left so that it doesn't overlap the standard notifications. Another suggestion I got was to make it a modal dialog or something similar to that, where the debit permission behaved completely differently from other permissions requests. I chose the current implementation of the debit notification because I felt it struck a good balance between communicating the importance of the debit permission, while not annoying the user (something moving the window around, or imposing a forced delay before dismissing it might), or confusing the user (which presenting them with a new, modal dialog instead of a popup notification might). If you'd like, I would be happy to provide anyone who's interested with a private drop of the Windows binaries built from 1.16.0.5 sources which includes the debit permissions patch. I would love to get more feedback from people who have tried out the new behavior. If you're interested in getting a private drop, just send me an email. I've also attached some screencaps of the debit patch in action to the bug, and you can also see them on my blog: http://ablewhitman.blogspot.com/2007/05/update-1-second-life-viewer-patch-to.html All that said, I'm willing to be convinced that a different approach is better, so if you think the current behavior is still inadequate, let me know! I'm the only person so far who has tried out the changes "in-world", but for me they seem to be just fine :) --Able On 6/6/07, Matthew Dowd wrote: > > > I raised this with Rob Linden, who suggested I post the issue here. It > also relates to Able Whitman's recently debit permissions patch. > > As well as making the permissions dialog different, I would suggest moving > it to a different part of the window than the normal permissions. > > Whenever I buy from a vendor in SL, typically two windows pop-up ("You > have paid xxx" following by "You have received..."), I've lost count how > many times I have gone to click on the former, and the latter has popped up > just as I click, and I end up clicking (luckily on keep) in the former. > Maybe by timing is just strangely tuned to the delay between the two popup > windows ;-) > > It did occur to me, that it would be very easy to script a dialog followed > by the permissions request, in the hope that someone would go to close the > first and end up accepting the permission by mistake. > > The solution would be to have the window appear somewhere different from > the normal dialogs. In many ways this would also have the effect of > highlighting the window as different (as per Able Whitman's patch) but in a > manner which would also work fo those suffering colour blindness. > > Matthew > > > _________________________________________________________________ > 100's of Music vouchers to be won with MSN Music > > https://www.musicmashup.co.uk/index.html_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070606/287f1730/attachment.htm From matthew.dowd at hotmail.co.uk Wed Jun 6 12:30:55 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Wed Jun 6 12:30:57 2007 Subject: [sldev] Moving the permissions window Message-ID: > * the debit notification window is much taller than the standard notification, which mitigates the "accidental click-through" problem I hadn't appreciated that aspect - yes, moving the buttons would also address accidental click-through. Matthew _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb From nicholaz at blueflash.cc Wed Jun 6 12:33:24 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 6 12:33:33 2007 Subject: [sldev] VWR-176 Message-ID: <46670C04.6090407@blueflash.cc> Attached is a patch for 176. Nice one had me on the wrong track for a while. As it seems, snprintf goes to a safe_snprintf which insists on putting a zero at the end of the buffer, no matter what. Line numbers in the patch may be off a bit, I deleted the hunk that was VWR-808 in the same file. Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ -------------- next part -------------- # XP [W:\sl1.16.0.5]udiff linden-orig/indra/llmessage/message.cpp linden/indra/llmessage/message.cpp --- linden-orig/indra/llmessage/message.cpp 2007-05-23 11:55:56.000000000 +0200 +++ linden/indra/llmessage/message.cpp 2007-06-06 21:09:21.906250000 +0200 @@ -4154,14 +4181,19 @@ { llwarns << "Packet Dump from:" << mPacketRing.getLastSender() << llendl; llwarns << "Packet Size:" << mTrueReceiveSize << llendl; + char line_buffer[256]; /* Flawfinder: ignore */ S32 i; S32 cur_line_pos = 0; - S32 cur_line = 0; + S32 buf_offset; + + memset(line_buffer, 0xFE, sizeof(line_buffer)); + for (i = 0; i < mTrueReceiveSize; i++) { - snprintf(line_buffer + cur_line_pos*3, sizeof(line_buffer),"%02x ", mTrueReceiveBuffer[i]); /* Flawfinder: ignore */ + buf_offset = cur_line_pos*3; + snprintf(line_buffer + buf_offset, sizeof(line_buffer)-buf_offset, "%02x ", mTrueReceiveBuffer[i]); /* Flawfinder: ignore */ cur_line_pos++; if (cur_line_pos >= 16) { From nicholaz at blueflash.cc Wed Jun 6 12:45:14 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 6 12:45:26 2007 Subject: [sldev] VWR-176 In-Reply-To: <46670C04.6090407@blueflash.cc> References: <46670C04.6090407@blueflash.cc> Message-ID: <46670ECA.2010407@blueflash.cc> OOps, obivously the memset there is from testing, shouldn't be there. Nick. Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Nicholaz Beresford wrote: > > Attached is a patch for 176. Nice one had me on the wrong > track for a while. > > As it seems, snprintf goes to a safe_snprintf which insists on > putting a zero at the end of the buffer, no matter what. > > Line numbers in the patch may be off a bit, I deleted the > hunk that was VWR-808 in the same file. > > > Nick > > > ------------------------------------------------------------------------ > > > # XP [W:\sl1.16.0.5]udiff linden-orig/indra/llmessage/message.cpp linden/indra/llmessage/message.cpp > --- linden-orig/indra/llmessage/message.cpp 2007-05-23 11:55:56.000000000 +0200 > +++ linden/indra/llmessage/message.cpp 2007-06-06 21:09:21.906250000 +0200 > @@ -4154,14 +4181,19 @@ > { > llwarns << "Packet Dump from:" << mPacketRing.getLastSender() << llendl; > llwarns << "Packet Size:" << mTrueReceiveSize << llendl; > + > char line_buffer[256]; /* Flawfinder: ignore */ > S32 i; > S32 cur_line_pos = 0; > - > S32 cur_line = 0; > + S32 buf_offset; > + > + memset(line_buffer, 0xFE, sizeof(line_buffer)); > + > for (i = 0; i < mTrueReceiveSize; i++) > { > - snprintf(line_buffer + cur_line_pos*3, sizeof(line_buffer),"%02x ", mTrueReceiveBuffer[i]); /* Flawfinder: ignore */ > + buf_offset = cur_line_pos*3; > + snprintf(line_buffer + buf_offset, sizeof(line_buffer)-buf_offset, "%02x ", mTrueReceiveBuffer[i]); /* Flawfinder: ignore */ > cur_line_pos++; > if (cur_line_pos >= 16) > { > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From bbyer at mm.st Wed Jun 6 13:28:17 2007 From: bbyer at mm.st (Ben Byer) Date: Wed Jun 6 13:28:24 2007 Subject: [sldev] Re: dead code In-Reply-To: <4664F94A.6000004@dzonux.net> References: <46545C49.9080202@lindenlab.com> <5C75920C-8346-484A-915D-D185F5C96F78@mm.st> <4664F94A.6000004@dzonux.net> Message-ID: On Jun 4, 2007, at 10:48 PM, Dzonatas wrote: >> Ben Byer wrote: >>> LLVertexBuffer::setStride(int, int) > I can confirm this one is not used: Okay. Barring further objections, I'll pick a couple of source files and wrap all of the unused code in #ifdef LL_UNUSED; if it still compiles in the viewer, we can assume that code is genuinely not used in the viewer. If it then gets integrated in the official codebase, any LL internal code (sim? etc) will then build against it, and assuming they have no problems, we can later go back and submit a patch to just remove anything surrounded by those ifdefs. Sound like a plan? -b From kelly at lindenlab.com Wed Jun 6 14:20:01 2007 From: kelly at lindenlab.com (Kelly Washington) Date: Wed Jun 6 14:20:09 2007 Subject: [sldev] Re: dead code In-Reply-To: <5C75920C-8346-484A-915D-D185F5C96F78@mm.st> References: <46545C49.9080202@lindenlab.com> <5C75920C-8346-484A-915D-D185F5C96F78@mm.st> Message-ID: <46672501.1030109@lindenlab.com> Ben Byer wrote: > Okay. I rebuilt the list, but this time I used -O0. I've made an > effort to remove all obvious library functions, as well as > constructors and destructors; some may remain, but this list should be > more helpful: > A great many of these are used in the simulator code. You probably want to restrict your culling to the files specifically in newview. A few more comments below. > LLLinkedList* > LLMap* > LLDoubleLinkedList* Ew. These are our own template container classes. It looks like your method found specific functions that weren't used in specific lists. Ideally code that uses these should be converted to some appropriate std:: container. You probably don't want to start trimming LLDoubleLinkedList based on which functions aren't used by specific instances of it. > LLFolderBridge::createNew* Be careful with these. The inventory Bridge classes and functions are .... complex. - Kelly From rdw at lindenlab.com Wed Jun 6 16:07:01 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Wed Jun 6 16:09:07 2007 Subject: [sldev] Preferred CAPS timeouts and retries? In-Reply-To: <465396B5.40303@wsu.edu> References: <46522D45.9030103@wsu.edu> <465266DC.4070707@lindenlab.com> <46528D4D.4080708@wsu.edu> <4653391F.8000609@lindenlab.com> <465396B5.40303@wsu.edu> Message-ID: <46673E15.9080901@lindenlab.com> John Hurliman wrote: > Ryan Williams wrote: >> I have a few more questions: >> >> -is this happening on socket open, or is it refusing to deliver data >> over the open socket, or both? >> - what are the logs from the official client that you're reading to >> determine that it's occasionaly problematic there? >> - have you noticed any pattern for which regions have the problem? >> >> Thanks for bringing this to our attention, BTW, we appreciate it. >> >> -RYaN >> > > I don't have any of the old log files from the official viewer so I'm > going to start looking for it again and save the log when it happens so > I can post. Translating .NET callbacks in libsecondlife to what is > actually happening at the lower layer, lets see here: > > BeginGetRequestStream succeeds > EndGetRequestStream succeeds > BeginGetResponse hangs (indefinitely?) > > So it looks like the socket opens, the client sends a request, but the > server never sends a response. I only go to three or four sims in SL > usually, but out of those I've most often noticed it in Ahern on a busy > night. The sim turns in to what I call a "blackhole sim" because you can > teleport in just fine, but since CAPS is unavailable in that sim there > is no way to walk or TP out, and you get trapped in the sim. Hi, sorry for the long delay on this, but we think we've identified one issue that might cause this, and deployed the fix to the beta grid. The problem that we identified was that the caps server was not responding when an invalid cap was invoked, it should have been returning a 404. Now it returns a 404 instead of keeping the connection open forever. Would you let me know if you still see the issues with connecting to the caps server on the beta grid? -RYaN > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From gigstaggart at gmail.com Wed Jun 6 19:08:35 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 6 19:08:42 2007 Subject: [sldev] Re: dead code In-Reply-To: <46672501.1030109@lindenlab.com> References: <46545C49.9080202@lindenlab.com> <5C75920C-8346-484A-915D-D185F5C96F78@mm.st> <46672501.1030109@lindenlab.com> Message-ID: <466768A3.4020401@gmail.com> Kelly Washington wrote: >> LLFolderBridge::createNew* > Be careful with these. The inventory Bridge classes and functions are > .... complex. > To put it mildly! The entire inventory message handlers could use a good refactor. The work JC and I did when we added inventory throttling helped a little, but there's still plenty to be done there. -Jason From tateru.nino at gmail.com Wed Jun 6 20:28:10 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Jun 6 20:28:16 2007 Subject: [sldev] Silly suggestion - improved initial rez time Message-ID: <46677B4A.1010105@gmail.com> Here's a stupid idea. When you log in, 99 times out of 100, you're going to log in to the same place as you logged out. If you're not logging into the 'last location', well the viewer knows that. What if.... on logout, the viewer wrote out a list of currently loaded texture assets - the index of the memory cache? When logging in to the last location, the list is accessed, and the textures decoded and loaded into the memory cache with their timestamps updated to 'now' (or in the event of long loading times, are actually a little post-dated). That would preload all the textures that are most likely to be around your avatar at the time you log in. Some things may have changed, sure, but they can push into the memory cache as normal. It's also possible that the grid and the viewer may disagree as to where you were last. It happens sometimes, but the extra time preloading textures in that event probably won't hurt any. Thoughts? -- Tateru Nino http://dwellonit.blogspot.com/ From sllists at boroon.dasgupta.ch Thu Jun 7 01:22:58 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Thu Jun 7 01:23:31 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <46677B4A.1010105@gmail.com> References: <46677B4A.1010105@gmail.com> Message-ID: <51212.82.130.81.3.1181204578.squirrel@datendelphin.net> Sounds good. (And not at all stupid) Tateru Nino schrieb: > It's also possible that the grid and the viewer may disagree as to where you were last. It happens sometimes, but the extra time preloading textures in that event probably won't hurt any. This might happen to people who log in from two (or more) different machines on a regular basis. Like someone going inworld from his workplace during daytime and from home at the evening. Boroondas From nicholaz at blueflash.cc Thu Jun 7 02:07:34 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 7 02:07:46 2007 Subject: [sldev] Re: dead code In-Reply-To: <466768A3.4020401@gmail.com> References: <46545C49.9080202@lindenlab.com> <5C75920C-8346-484A-915D-D185F5C96F78@mm.st> <46672501.1030109@lindenlab.com> <466768A3.4020401@gmail.com> Message-ID: <4667CAD6.5020408@blueflash.cc> Jason Giglio wrote: > Kelly Washington wrote: >>> LLFolderBridge::createNew* >> Be careful with these. The inventory Bridge classes and functions are >> .... complex. > > To put it mildly! The entire inventory message handlers could use a > good refactor. The work JC and I did when we added inventory throttling > helped a little, but there's still plenty to be done there. Btw, speaking of inventory. When debugging I've seen asserts on something like (childitems >= 0) (don't remember the exact assert as Inventory isn't one of my interests) on a semi regular basis. Nick From dzonatas at dzonux.net Thu Jun 7 09:17:53 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 7 09:17:54 2007 Subject: [sldev] Doxygen & Comments In-Reply-To: <46658BB1.20003@ucsd.edu> References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> <46658BB1.20003@ucsd.edu> Message-ID: <46682FB1.7050403@dzonux.net> Max Okumoto wrote: > Would patches which add javadoc type comments to functions be > welcome? I usually add comments to code that I am trying to understand. The main problem with comments in code is that the comments are usually in some sub-human form of English. The prose of the sub-human language is insignificant to on the scale of readability and communicative expression of the content it relates to the reader, or, better yet, to the programmer. What matters more to the programmer is the ability to communicate that content of that comment to the intended audience. If the programmer desires to only to deal with an audience that is able to read at least some form of sub-human English, the comments will be written in that so stated English form. The global world is much greater and diverse, and there are many programmers that can barely translate English. The comments may be of some interest to them, but it may be more of a pain in the ass in their time to comprehend it than it is just to look straight at the code. Also, there are more programmers out there that do not speak any form of English. Those comments that are written in a form of English are of no use to a programmer that does not speak any form of English. In fact, the comments appear more like litter on the road where you have to go pay some state or province tax to clean-up, which such taxs funds are usually channeled through endless reams of political red-tape until it ends up in the paycheck of a law enforcement officer to watch over a community work project of less fortunate group of sub-humans to complete the road service clean-up job. I could get into a debate over the amount of time is wasted in comments, which are pieces of the source that have absolutely no function to the end-user. There are obviously far better tools to document source than in-line liter. Some of the most simplest issue trackers make a better basis for a documentative system. If a programmer thinks there is a need to create further documentation for a class, then that programmer has done well to follow-up with a tracker item for such reason and where such documentation will flow. Do not take this mixture of documentation and tracker issue as the only way or as the way that I suggest is best, as it is merely better idea to give a programmer the fluidity to work focused on the code itself than for that programmer to worry about foreign, sub-human comments. Being able to program is like a fluid degree of skill at a foreign language or any language, really. Skill with a program language profoundly compares to skill with a foreign language. Does anybody tell professional English writers that they must comment their books and articles with C++? I didn't think so. Dz -- From phoenix at secondlife.com Thu Jun 7 09:48:30 2007 From: phoenix at secondlife.com (Phoenix) Date: Thu Jun 7 09:48:40 2007 Subject: [sldev] Doxygen & Comments In-Reply-To: <46682FB1.7050403@dzonux.net> References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> <46658BB1.20003@ucsd.edu> <46682FB1.7050403@dzonux.net> Message-ID: Regardless of international consumers of the code, the majority of english speaking devs that work on SL would benefit from: * comments in headers which describe ** parameters ** valid parameter ranges ** if parameter ranges are checked ** return value * comments in code which describe ** why a tricky and non-obvious is not written for clarity ** what a tricky and non-obvious tangle of code does On 2007 Jun 7, at 09:17, Dzonatas wrote: > Max Okumoto wrote: >> Would patches which add javadoc type comments to functions be >> welcome? I usually add comments to code that I am trying to >> understand. > > The main problem with comments in code is that the comments are > usually in some sub-human form of English. The prose of the sub- > human language is insignificant to on the scale of readability and > communicative expression of the content it relates to the reader, > or, better yet, to the programmer. What matters more to the > programmer is the ability to communicate that content of that > comment to the intended audience. If the programmer desires to only > to deal with an audience that is able to read at least some form of > sub-human English, the comments will be written in that so stated > English form. The global world is much greater and diverse, and > there are many programmers that can barely translate English. The > comments may be of some interest to them, but it may be more of a > pain in the ass in their time to comprehend it than it is just to > look straight at the code. Also, there are more programmers out > there that do not speak any form of English. Those comments that > are written in a form of English are of no use to a programmer that > does not speak any form of English. In fact, the comments appear > more like litter on the road where you have to go pay some state or > province tax to clean-up, which such taxs funds are usually > channeled through endless reams of political red-tape until it ends > up in the paycheck of a law enforcement officer to watch over a > community work project of less fortunate group of sub-humans to > complete the road service clean-up job. > > I could get into a debate over the amount of time is wasted in > comments, which are pieces of the source that have absolutely no > function to the end-user. There are obviously far better tools to > document source than in-line liter. Some of the most simplest issue > trackers make a better basis for a documentative system. If a > programmer thinks there is a need to create further documentation > for a class, then that programmer has done well to follow-up with a > tracker item for such reason and where such documentation will > flow. Do not take this mixture of documentation and tracker issue > as the only way or as the way that I suggest is best, as it is > merely better idea to give a programmer the fluidity to work > focused on the code itself than for that programmer to worry about > foreign, sub-human comments. > > Being able to program is like a fluid degree of skill at a foreign > language or any language, really. Skill with a program language > profoundly compares to skill with a foreign language. Does anybody > tell professional English writers that they must comment their > books and articles with C++? I didn't think so. > > Dz > > -- > _______________________________________________ > 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/20070607/5d0e5694/PGP.pgp From robla at lindenlab.com Thu Jun 7 09:55:09 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jun 7 09:55:11 2007 Subject: Hosting Doxygen docs (Re: [sldev] Doxygen & Comments) In-Reply-To: References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> <46658BB1.20003@ucsd.edu> <46682FB1.7050403@dzonux.net> Message-ID: <4668386D.7000203@lindenlab.com> Hi all, On a tangent, if you all would like us to host a set of Doxygen-generated comments, let us know, specifically by filing a task in JIRA in the WEB project. Since I'm a little fuzzy on where I'd put said comments, I'm not sure when I'd personally get around to doing it, but a JIRA task would be a handy reminder to get around to it. Thanks Rob On 6/7/07 9:48 AM, Phoenix wrote: > Regardless of international consumers of the code, the majority of > english speaking devs that work on SL would benefit from: > > * comments in headers which describe > ** parameters > ** valid parameter ranges > ** if parameter ranges are checked > ** return value > * comments in code which describe > ** why a tricky and non-obvious is not written for clarity > ** what a tricky and non-obvious tangle of code does > > > On 2007 Jun 7, at 09:17, Dzonatas wrote: >> Max Okumoto wrote: >>> Would patches which add javadoc type comments to functions be >>> welcome? I usually add comments to code that I am trying to >>> understand. >> >> The main problem with comments in code is that the comments are >> usually in some sub-human form of English. The prose of the sub-human >> language is insignificant to on the scale of readability and >> communicative expression of the content it relates to the reader, or, >> better yet, to the programmer. What matters more to the programmer is >> the ability to communicate that content of that comment to the >> intended audience. If the programmer desires to only to deal with an >> audience that is able to read at least some form of sub-human >> English, the comments will be written in that so stated English form. >> The global world is much greater and diverse, and there are many >> programmers that can barely translate English. The comments may be of >> some interest to them, but it may be more of a pain in the ass in >> their time to comprehend it than it is just to look straight at the >> code. Also, there are more programmers out there that do not speak >> any form of English. Those comments that are written in a form of >> English are of no use to a programmer that does not speak any form of >> English. In fact, the comments appear more like litter on the road >> where you have to go pay some state or province tax to clean-up, >> which such taxs funds are usually channeled through endless reams of >> political red-tape until it ends up in the paycheck of a law >> enforcement officer to watch over a community work project of less >> fortunate group of sub-humans to complete the road service clean-up job. >> >> I could get into a debate over the amount of time is wasted in >> comments, which are pieces of the source that have absolutely no >> function to the end-user. There are obviously far better tools to >> document source than in-line liter. Some of the most simplest issue >> trackers make a better basis for a documentative system. If a >> programmer thinks there is a need to create further documentation for >> a class, then that programmer has done well to follow-up with a >> tracker item for such reason and where such documentation will flow. >> Do not take this mixture of documentation and tracker issue as the >> only way or as the way that I suggest is best, as it is merely better >> idea to give a programmer the fluidity to work focused on the code >> itself than for that programmer to worry about foreign, sub-human >> comments. >> >> Being able to program is like a fluid degree of skill at a foreign >> language or any language, really. Skill with a program language >> profoundly compares to skill with a foreign language. Does anybody >> tell professional English writers that they must comment their books >> and articles with C++? I didn't think so. >> >> Dz >> >> -- >> _______________________________________________ >> 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/20070607/9cc7b805/signature.pgp From chance at kalacia.com Thu Jun 7 10:26:22 2007 From: chance at kalacia.com (Chance Unknown) Date: Thu Jun 7 10:26:24 2007 Subject: Hosting Doxygen docs (Re: [sldev] Doxygen & Comments) In-Reply-To: <4668386D.7000203@lindenlab.com> References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> <46658BB1.20003@ucsd.edu> <46682FB1.7050403@dzonux.net> <4668386D.7000203@lindenlab.com> Message-ID: <2925011a0706071026p40c6c24fnf8cf72b3058adb93@mail.gmail.com> IMHO Comments in the source are beneficial only when they conform to a style guide for the type of information included. If its just an academic bunch of notes to make clear the selection of algorithm: then its far better to document on a wiki for other people to look at, and not include in the source code. If you get a 30 person team all stuffing notes into source code, it becomes a maintenance nightmare, it hides the code, and it makes the algorithms very difficult to see. STYLE GUIDE : KNOW IT, BREATHE IT, LIVE IT. Usually, whatever gets buried into source code should be of use to everyone, and not hide algorithms or language constructs because of the verbosity. Notes do much better in an attached text file within a project that has many participants. A team usually will read the notes once or twice, and then know what it is that they are looking at in the source code. If you deposit those notes physically into the source, then you make it something a team collectively now has to page past in order to get to the algorithm. That wastes everybodys time. --- On 6/7/07, Rob Lanphier wrote: > > Hi all, > > On a tangent, if you all would like us to host a set of > Doxygen-generated comments, let us know, specifically by filing a task > in JIRA in the WEB project. Since I'm a little fuzzy on where I'd put > said comments, I'm not sure when I'd personally get around to doing it, > but a JIRA task would be a handy reminder to get around to it. > > Thanks > Rob > > On 6/7/07 9:48 AM, Phoenix wrote: > > Regardless of international consumers of the code, the majority of > > english speaking devs that work on SL would benefit from: > > > > * comments in headers which describe > > ** parameters > > ** valid parameter ranges > > ** if parameter ranges are checked > > ** return value > > * comments in code which describe > > ** why a tricky and non-obvious is not written for clarity > > ** what a tricky and non-obvious tangle of code does > > > > > > On 2007 Jun 7, at 09:17, Dzonatas wrote: > >> Max Okumoto wrote: > >>> Would patches which add javadoc type comments to functions be > >>> welcome? I usually add comments to code that I am trying to > >>> understand. > >> > >> The main problem with comments in code is that the comments are > >> usually in some sub-human form of English. The prose of the sub-human > >> language is insignificant to on the scale of readability and > >> communicative expression of the content it relates to the reader, or, > >> better yet, to the programmer. What matters more to the programmer is > >> the ability to communicate that content of that comment to the > >> intended audience. If the programmer desires to only to deal with an > >> audience that is able to read at least some form of sub-human > >> English, the comments will be written in that so stated English form. > >> The global world is much greater and diverse, and there are many > >> programmers that can barely translate English. The comments may be of > >> some interest to them, but it may be more of a pain in the ass in > >> their time to comprehend it than it is just to look straight at the > >> code. Also, there are more programmers out there that do not speak > >> any form of English. Those comments that are written in a form of > >> English are of no use to a programmer that does not speak any form of > >> English. In fact, the comments appear more like litter on the road > >> where you have to go pay some state or province tax to clean-up, > >> which such taxs funds are usually channeled through endless reams of > >> political red-tape until it ends up in the paycheck of a law > >> enforcement officer to watch over a community work project of less > >> fortunate group of sub-humans to complete the road service clean-up > job. > >> > >> I could get into a debate over the amount of time is wasted in > >> comments, which are pieces of the source that have absolutely no > >> function to the end-user. There are obviously far better tools to > >> document source than in-line liter. Some of the most simplest issue > >> trackers make a better basis for a documentative system. If a > >> programmer thinks there is a need to create further documentation for > >> a class, then that programmer has done well to follow-up with a > >> tracker item for such reason and where such documentation will flow. > >> Do not take this mixture of documentation and tracker issue as the > >> only way or as the way that I suggest is best, as it is merely better > >> idea to give a programmer the fluidity to work focused on the code > >> itself than for that programmer to worry about foreign, sub-human > >> comments. > >> > >> Being able to program is like a fluid degree of skill at a foreign > >> language or any language, really. Skill with a program language > >> profoundly compares to skill with a foreign language. Does anybody > >> tell professional English writers that they must comment their books > >> and articles with C++? I didn't think so. > >> > >> Dz > >> > >> -- > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070607/795543c5/attachment.htm From nicholaz at blueflash.cc Thu Jun 7 11:07:12 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 7 11:07:25 2007 Subject: Hosting Doxygen docs (Re: [sldev] Doxygen & Comments) In-Reply-To: <2925011a0706071026p40c6c24fnf8cf72b3058adb93@mail.gmail.com> References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> <46658BB1.20003@ucsd.edu> <46682FB1.7050403@dzonux.net> <4668386D.7000203@lindenlab.com> <2925011a0706071026p40c6c24fnf8cf72b3058adb93@mail.gmail.com> Message-ID: <46684950.1010709@blueflash.cc> IMHO not. Usually what gets buried in the source code is needed exactly then when the source code is looked at anyway. If of those 30 persons every one puts into the source code that which is not obvious from looking at the code itself, you'll have a readable program. Usually, in my experience, when you put notes and codes in different places, what you get quite quickly are two things entirely out of sync. Phoenix wrote: > * comments in headers which describe > ** parameters > ** valid parameter ranges > ** if parameter ranges are checked > ** return value > > * comments in code which describe > ** why a tricky and non-obvious is not written for clarity > ** what a tricky and non-obvious tangle of code does Of all those, I'd only need the 2nd part. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Chance Unknown wrote: > IMHO > > Comments in the source are beneficial only when they conform to a style > guide for the type of information included. If its just an academic > bunch of notes to make clear the selection of algorithm: then its far > better to document on a wiki for other people to look at, and not > include in the source code. If you get a 30 person team all stuffing > notes into source code, it becomes a maintenance nightmare, it hides the > code, and it makes the algorithms very difficult to see. > > STYLE GUIDE : KNOW IT, BREATHE IT, LIVE IT. > > Usually, whatever gets buried into source code should be of use to > everyone, and not hide algorithms or language constructs because of the > verbosity. Notes do much better in an attached text file within a > project that has many participants. A team usually will read the notes > once or twice, and then know what it is that they are looking at in the > source code. If you deposit those notes physically into the source, then > you make it something a team collectively now has to page past in order > to get to the algorithm. That wastes everybodys time. From gwardell at ApprovalSystems.net Thu Jun 7 11:21:13 2007 From: gwardell at ApprovalSystems.net (Gary Wardell) Date: Thu Jun 7 11:21:32 2007 Subject: Hosting Doxygen docs (Re: [sldev] Doxygen & Comments) In-Reply-To: <46684950.1010709@blueflash.cc> Message-ID: <023c01c7a930$a2275700$a4689943@gwsystems2.com> > > Usually, in my experience, when you put notes > and codes in different places, what you get quite > quickly are two things entirely out of sync. And usually it's the location that requires extra effort to go to. > > > Phoenix wrote: > > * comments in headers which describe > > ** parameters > > ** valid parameter ranges > > ** if parameter ranges are checked > > ** return value > > > > * comments in code which describe > > ** why a tricky and non-obvious is not written for clarity > > ** what a tricky and non-obvious tangle of code does > > Of all those, I'd only need the 2nd part. > Yes, but I'd also include a short definition of the parameters, like maybe what each is for. Parameter ranges should be obvious from asserts and thus self documenting. I also agree with the person that said it should be standardized. Also, the comments should not simply restate the code or what is obvious form the code, they should add some insight as to what the code is doing, otherwise they are a waste of resources. Gary From nicholaz at blueflash.cc Thu Jun 7 11:24:06 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 7 11:24:17 2007 Subject: Hosting Doxygen docs (Re: [sldev] Doxygen & Comments) In-Reply-To: <023c01c7a930$a2275700$a4689943@gwsystems2.com> References: <023c01c7a930$a2275700$a4689943@gwsystems2.com> Message-ID: <46684D46.6010204@blueflash.cc> > Also, the comments should not simply restate the code or > what is obvious form the code, they should add some insight > as to what the code is doing, otherwise they are a waste > of resources. Absolutely. I only use comments to give an idea what a larger part of the source is doing on an abstract level. This is also something I like in the function headers. Nick From dzonatas at dzonux.net Thu Jun 7 10:45:03 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 7 11:33:20 2007 Subject: [sldev] Doxygen & Comments In-Reply-To: References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> <46658BB1.20003@ucsd.edu> <46682FB1.7050403@dzonux.net> Message-ID: <4668441F.80600@dzonux.net> In the same regards, you are telling me that the majority of C++ programmers will benefit from: * comments on English words in source code, which describe, ** common grammar of the English word ** appropriate usage of such English word in a prescribed context ** the expected perception of others when such word is used * and further describe ** why such words should one have one meaning, as intended, if possible ** a justification of a to be rewritten usage of words that have lasted to this date because, solely, it has gone way beyond the scope of its original usage to the point a simple look-up into a thesaurus can't even justify the time to further beautify it in the context it exists By no means is that meant negative, but it simply a reflection. In my experience, C++ is a way to speak with a diverse population of programmers even when there is no common non-program language for which the two programmers may use to effectively communicate. I merely suggest an accelerated means by reasonably attempt to pave the way on beautiful virtual roads with nice lush un-littered scenic green grassy fields. If their is to be commented source code, then those comments are best put in another database. The reference number can be left in the source code. That is justifiable, example: // SLC++1234 class theCamelCaseClassName { void someMethod(); ... } boom! Reference SLC++1234 if you want the English context of it, which could be linked further to translations of that class written into other spoken languages, which Phoenix started to type in the previous message. I bet the entanglement, good and bad, becomes a bit easier to understand across the board at that point, especially (mush less) for those that do not speak English and (more so) for those that do not read C++ at all. =) When push comes to shove (I mean to shove a release out to ship), is there a need to immediately re-write a piece of code to the intention that the comment says it is suppose to do, or would it be better just to delete the comment because the code that exists has gone through tried and tested means and an expert in C++ can translate exactly what it does for you? Well, I don't want to waste just anybody's time anymore on my suggestion. Second Life kicks ass! Let's build worlds! =) Dz Phoenix wrote: > Regardless of international consumers of the code, the majority of > english speaking devs that work on SL would benefit from: > > * comments in headers which describe > ** parameters > ** valid parameter ranges > ** if parameter ranges are checked > ** return value > * comments in code which describe > ** why a tricky and non-obvious is not written for clarity > ** what a tricky and non-obvious tangle of code does > > > On 2007 Jun 7, at 09:17, Dzonatas wrote: >> Max Okumoto wrote: >>> Would patches which add javadoc type comments to functions be >>> welcome? I usually add comments to code that I am trying to >>> understand. >> >> The main problem with comments in code is that the comments are >> usually in some sub-human form of English. The prose of the sub-human >> language is insignificant to on the scale of readability and >> communicative expression of the content it relates to the reader, or, >> better yet, to the programmer. What matters more to the programmer is >> the ability to communicate that content of that comment to the >> intended audience. If the programmer desires to only to deal with an >> audience that is able to read at least some form of sub-human >> English, the comments will be written in that so stated English form. >> The global world is much greater and diverse, and there are many >> programmers that can barely translate English. The comments may be of >> some interest to them, but it may be more of a pain in the ass in >> their time to comprehend it than it is just to look straight at the >> code. Also, there are more programmers out there that do not speak >> any form of English. Those comments that are written in a form of >> English are of no use to a programmer that does not speak any form of >> English. In fact, the comments appear more like litter on the road >> where you have to go pay some state or province tax to clean-up, >> which such taxs funds are usually channeled through endless reams of >> political red-tape until it ends up in the paycheck of a law >> enforcement officer to watch over a community work project of less >> fortunate group of sub-humans to complete the road service clean-up job. >> >> I could get into a debate over the amount of time is wasted in >> comments, which are pieces of the source that have absolutely no >> function to the end-user. There are obviously far better tools to >> document source than in-line liter. Some of the most simplest issue >> trackers make a better basis for a documentative system. If a >> programmer thinks there is a need to create further documentation for >> a class, then that programmer has done well to follow-up with a >> tracker item for such reason and where such documentation will flow. >> Do not take this mixture of documentation and tracker issue as the >> only way or as the way that I suggest is best, as it is merely better >> idea to give a programmer the fluidity to work focused on the code >> itself than for that programmer to worry about foreign, sub-human >> comments. >> >> Being able to program is like a fluid degree of skill at a foreign >> language or any language, really. Skill with a program language >> profoundly compares to skill with a foreign language. Does anybody >> tell professional English writers that they must comment their books >> and articles with C++? I didn't think so. >> >> Dz >> >> --_______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- From jhurliman at wsu.edu Thu Jun 7 11:55:27 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Jun 7 11:54:16 2007 Subject: [sldev] Doxygen & Comments In-Reply-To: <4668441F.80600@dzonux.net> References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> <46658BB1.20003@ucsd.edu> <46682FB1.7050403@dzonux.net> <4668441F.80600@dzonux.net> Message-ID: <4668549F.6050008@wsu.edu> Dzonatas wrote: > By no means is that meant negative, but it simply a reflection. In my > experience, C++ is a way to speak with a diverse population of > programmers even when there is no common non-program language for > which the two programmers may use to effectively communicate. I merely > suggest an accelerated means by reasonably attempt to pave the way on > beautiful virtual roads with nice lush un-littered scenic green grassy > fields. While we are talking about experiences I will throw mine in. When contracted to write software for international teams I've always been asked to go the extra mile on software comments and documentation, because the code is written in English. I might name a variable "increment", but never "??" (or whatever). The variable name is an extremely terse wording that usually doesn't provide enough context for anyone to understand what is going on without looking at the rest of the code, and if the rest of the code does some non-obvious things like a lot of pointer arithmetic or has bugs in it, you have a communication breakdown. Documenting what code is supposed to do and then verifying that it actually does that can go a long ways towards finding problems. Beyond documenting the purpose of something, documenting usage and parameters can be either helpful or necessary if you have functions that aren't immediately obvious what they are used for or what the parameters and return values are used for. John Hurliman From robla at lindenlab.com Thu Jun 7 12:21:02 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jun 7 12:21:08 2007 Subject: [sldev] Next bug triage: June 11 Message-ID: <46685A9E.3040207@lindenlab.com> Hi folks, Yet another bug triage coming up. It's been working really well to have a community-generated agenda, so I'd like to make that a standard tradition. Here's the agenda page: https://wiki.secondlife.com/wiki/Bug_triage/Agenda The theme last week was "bugs with patches attached", which resulted in a lot of bugs getting imported. We didn't get through last week's agenda, so one possibility is to continue using that agenda: https://wiki.secondlife.com/wiki/Bug_triage/2007-06-04#Agenda_.28ran_out_of_time.29 If something has already been imported (which you can see by whether or not there's a "Linden Lab Issue ID" associated with it), we probably don't need to discuss it at this point, since there's probably already a discussion that's happening at Linden Lab about that issue. If an issue that's been imported already, but it looks stale, then just put something in the comments asking about the issue. It may make sense to have triage meetings based on component themes, so that we can make sure we have the right set of people from Linden Lab at the triage. If we know well in advance that the subject will be i18n, for example, I can invite the people working on that stuff to show up. 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/20070607/023206fd/signature.pgp From nicholaz at blueflash.cc Thu Jun 7 12:26:02 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 7 12:26:13 2007 Subject: [sldev] Doxygen & Comments In-Reply-To: <4668441F.80600@dzonux.net> References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> <46658BB1.20003@ucsd.edu> <46682FB1.7050403@dzonux.net> <4668441F.80600@dzonux.net> Message-ID: <46685BCA.10701@blueflash.cc> C++ as a language of expression clearly has it's benefits and I agree that readable code (which most likely also will use real world language to clarify, i.e. a variable will be named particle_count rather than x32) is preferrable over comment. But where a real life language has benefits is describing the why and what. Here are two examples of recent patches (or stuff I'm working on): + // vary view limit depending on usage. view_limit determines the quota an emitter + // may generate: 100% generation a 0-meters distance, 0% generation at a distance of + // view_limit-meters (or more) and proportional quotas in between (based on distance) + // (with a view_limit of draw_dist*4 the most distant visible (at draw_distance) source could + // generate at a quota of 75%) + view_limit = view_limit_low + (1.f - usage) * (view_limit_high - view_limit_low); + { + // simple quota computation based on distance to camera + + // (normally this would start from 1.f (100%) but this gives + // nearer particles extra leeway, i.e. make the filter not cut + // in from the first meter) + pass_quota = 1.1f - dist_cam / view_limit; + + } I think both those comments belong to the place where a fellow coder would look at the code, trying to understand what it does (or fixing a bug) and the English would be very hard to be substituted by an algorithmic language. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dzonatas wrote: > By no means is that meant negative, but it simply a reflection. In my > experience, C++ is a way to speak with a diverse population of > programmers even when there is no common non-program language for which > the two programmers may use to effectively communicate. I merely suggest > an accelerated means by reasonably attempt to pave the way on beautiful > virtual roads with nice lush un-littered scenic green grassy fields. > > If their is to be commented source code, then those comments are best > put in another database. The reference number can be left in the source > code. That is justifiable, example: From gigstaggart at gmail.com Thu Jun 7 12:42:02 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jun 7 12:42:13 2007 Subject: Hosting Doxygen docs (Re: [sldev] Doxygen & Comments) In-Reply-To: <46684950.1010709@blueflash.cc> References: <466438F2.3090707@ucsd.edu> <46657D9F.8050606@watson.ibm.com> <46658BB1.20003@ucsd.edu> <46682FB1.7050403@dzonux.net> <4668386D.7000203@lindenlab.com> <2925011a0706071026p40c6c24fnf8cf72b3058adb93@mail.gmail.com> <46684950.1010709@blueflash.cc> Message-ID: <46685F8A.7020200@gmail.com> Nicholaz Beresford wrote: > Usually, in my experience, when you put notes > and codes in different places, what you get quite > quickly are two things entirely out of sync. One of the major principles of good language and program design is that related things should be close to each other in the file and application. Putting comment-type documentation all the way in some external wiki is probably the worst thing you could do to violate this design rule. -Jason From anthony at lindenlab.com Thu Jun 7 16:35:55 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Thu Jun 7 16:34:51 2007 Subject: [sldev] Source release for 1.17.0.9 Message-ID: <4668965B.8080400@lindenlab.com> Hello everyone, 1.17.0.9 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_1-17-0-9 Release notes: http://blog.secondlife.com/2007/06/07/preview-of-second-life-11709-on-beta-grid-updated/ Checksums: 667cddcd132c19d8eee83d4cc01c53e9 slviewer-darwin-libs-1-17-0-9.tar.gz 370aab98b73f37ff8b930f7f172e6438 slviewer-linux-libs-1-17-0-9.tar.gz cfb952e0204b8edb1bc76770113efee1 slviewer-src-1-17-0-9.tar.gz 0241886b42a387f9a223cc9b03c1de83 slviewer-artwork-1-17-0-9.zip 2332652eed28f14ad88884379140d4e7 slviewer-src-1-17-0-9.zip 0ec61bab878c8a65ae70a62efe118354 slviewer-win32-libs-1-17-0-9.zip Enjoy. -Anthony From able.whitman at gmail.com Thu Jun 7 16:45:49 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 7 16:45:51 2007 Subject: [sldev] Source release for 1.17.0.9 In-Reply-To: <4668965B.8080400@lindenlab.com> References: <4668965B.8080400@lindenlab.com> Message-ID: <7b3a84fb0706071645x7c3b51e7sd2d39073c19afa15@mail.gmail.com> Thanks, Anthony! What is the likelihood that 1.17.0.9 is going to be the version released to the main grid next week? I have a few patches that I'm working on that I'd like to bring forward to the next official release, and I'd rather only have to integrate them into one newer build, rather than one now and another one next week. --Able On 6/7/07, Anthony Foster wrote: > > Hello everyone, > > 1.17.0.9 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1-17-0-9 > > Release notes: > > http://blog.secondlife.com/2007/06/07/preview-of-second-life-11709-on-beta-grid-updated/ > > Checksums: > > 667cddcd132c19d8eee83d4cc01c53e9 slviewer-darwin-libs-1-17-0-9.tar.gz > 370aab98b73f37ff8b930f7f172e6438 slviewer-linux-libs-1-17-0-9.tar.gz > cfb952e0204b8edb1bc76770113efee1 slviewer-src-1-17-0-9.tar.gz > 0241886b42a387f9a223cc9b03c1de83 slviewer-artwork-1-17-0-9.zip > 2332652eed28f14ad88884379140d4e7 slviewer-src-1-17-0-9.zip > 0ec61bab878c8a65ae70a62efe118354 slviewer-win32-libs-1-17-0-9.zip > > > 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/20070607/ad8aec50/attachment.htm From anthony at lindenlab.com Thu Jun 7 16:55:18 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Thu Jun 7 16:54:11 2007 Subject: [sldev] Source release for 1.17.0.9 In-Reply-To: <7b3a84fb0706071645x7c3b51e7sd2d39073c19afa15@mail.gmail.com> References: <4668965B.8080400@lindenlab.com> <7b3a84fb0706071645x7c3b51e7sd2d39073c19afa15@mail.gmail.com> Message-ID: <46689AE6.1080700@lindenlab.com> Able, This won't be the final version you'll see next week; however, it's close. There are a few minor changes/fixes that will be coming along before we release it on the main grid. -Anthony Able Whitman wrote: > Thanks, Anthony! What is the likelihood that 1.17.0.9 > is going to be the version released to the main grid > next week? I have a few patches that I'm working on that I'd like to > bring forward to the next official release, and I'd rather only have > to integrate them into one newer build, rather than one now and > another one next week. > > --Able > > > On 6/7/07, *Anthony Foster* > wrote: > > Hello everyone, > > 1.17.0.9 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1-17-0-9 > > > Release notes: > http://blog.secondlife.com/2007/06/07/preview-of-second-life-11709-on-beta-grid-updated/ > > > Checksums: > > 667cddcd132c19d8eee83d4cc01c53e9 slviewer-darwin-libs-1-17-0-9.tar.gz > 370aab98b73f37ff8b930f7f172e6438 slviewer-linux-libs-1-17-0-9.tar.gz > cfb952e0204b8edb1bc76770113efee1 slviewer-src-1-17-0-9.tar.gz > 0241886b42a387f9a223cc9b03c1de83 slviewer-artwork-1-17-0-9.zip > 2332652eed28f14ad88884379140d4e7 slviewer-src-1-17-0-9.zip > 0ec61bab878c8a65ae70a62efe118354 slviewer-win32-libs-1-17-0-9.zip > > > Enjoy. > -Anthony > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From nicholaz at blueflash.cc Thu Jun 7 17:20:03 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 7 17:20:23 2007 Subject: [sldev] Source release for 1.17.0.9 In-Reply-To: <46689AE6.1080700@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <7b3a84fb0706071645x7c3b51e7sd2d39073c19afa15@mail.gmail.com> <46689AE6.1080700@lindenlab.com> Message-ID: <4668A0B3.5050902@blueflash.cc> I just saw that VWR-207 was closed/fixed on JIRA and also VWR-364 With the upcoming 1.17. release I would really urge to look into VWR-733 before release, because this was part of what people confused with the memory leak and which also causes excess disk swapping on many lower end systems. There is a simple fix that would ease the problem (my first patch attached to VWR-733) which would be to change const S32 min_non_tex_system_mem = (128<<20); // 128 MB but I have a more extensive change there also (which is used in my edition of the viewer currently) and also posted the latest version of that on the jira today. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Anthony Foster wrote: > Able, > > This won't be the final version you'll see next week; however, it's > close. There are a few minor changes/fixes that will be coming along > before we release it on the main grid. > > -Anthony > > Able Whitman wrote: >> Thanks, Anthony! What is the likelihood that 1.17.0.9 >> is going to be the version released to the main grid >> next week? I have a few patches that I'm working on that I'd like to >> bring forward to the next official release, and I'd rather only have >> to integrate them into one newer build, rather than one now and >> another one next week. >> >> --Able >> >> >> On 6/7/07, *Anthony Foster* > > wrote: >> >> Hello everyone, >> >> 1.17.0.9 source release available here: >> https://wiki.secondlife.com/wiki/Source_downloads#ver_1-17-0-9 >> >> >> Release notes: >> >> http://blog.secondlife.com/2007/06/07/preview-of-second-life-11709-on-beta-grid-updated/ >> >> >> >> Checksums: >> >> 667cddcd132c19d8eee83d4cc01c53e9 >> slviewer-darwin-libs-1-17-0-9.tar.gz >> 370aab98b73f37ff8b930f7f172e6438 slviewer-linux-libs-1-17-0-9.tar.gz >> cfb952e0204b8edb1bc76770113efee1 slviewer-src-1-17-0-9.tar.gz >> 0241886b42a387f9a223cc9b03c1de83 slviewer-artwork-1-17-0-9.zip >> 2332652eed28f14ad88884379140d4e7 slviewer-src-1-17-0-9.zip >> 0ec61bab878c8a65ae70a62efe118354 slviewer-win32-libs-1-17-0-9.zip >> >> >> 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 From soft at softnoel.org Thu Jun 7 19:18:58 2007 From: soft at softnoel.org (Soft Noel) Date: Thu Jun 7 19:19:00 2007 Subject: [sldev] Soft Linden Message-ID: <9e6e5c9e0706071918h37a42048ne33084108eab1ed3@mail.gmail.com> Executive Summary: Soft Noel = Soft Linden. Joy! Soon: smuggling patches into LL. A number of ya know me from SLDev[-Traffic] and haunting Rob's office hours whenever I've been able. To those of you who don't know me: Hi! I'm happy to say that I've taken a job at Linden Lab. I'm going through the "onboarding" process right now, which lasts a couple weeks. After I've finished my orientation, I want to start holding meetings for developers with contribution agreements on file. If you have questions related to projects in development, or patches that are ready for incorporation but haven't been given attention, I want to ensure you've got a straight pipeline to any help you need. If you haven't signed a contributor agreement, please consider sending one in. You've got a couple weeks before our first meeting: http://robla.webdev.lindenlab.com/developers/opensource/submitting If you've sent a contributor agreement in, but never received a confirmation, feel free to email me at soft@softnoel.org with both your SL name and RL name. I can check to verify that you're on the list. The process for submitting patches hasn't changed, and it's documented very well here: https://wiki.secondlife.com/wiki/Submitting_patches What is changing is that I'm going to start ensuring that every patch gets acceptance or constructive feedback, and that contributors get extra technical help when they need it. While LL's patch acceptance has improved a lot in recent weeks, I hope I can help make it better still. When you make the effort to help us out, it's the least we can do in return for the favor. In the near term, I should be making Rob's office hours regularly from now on - nobody looks at me askance if I ask to go on SL for an hour or so at work anymore. :) Catch ya there! From secret.argent at gmail.com Thu Jun 7 19:54:58 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 7 19:55:06 2007 Subject: [sldev] Re: Comments and foreign lnguages In-Reply-To: <20070607190007.DF72641B0A9@stupor.lindenlab.com> References: <20070607190007.DF72641B0A9@stupor.lindenlab.com> Message-ID: I'm largely in agreement with John here. Documenting what variables are intended to do is something I don't do nearly enough. On the other hand, I sure haven't been impressed by automatic documentation systems in the past. :) From soft at softnoel.org Thu Jun 7 19:59:18 2007 From: soft at softnoel.org (Soft Noel) Date: Thu Jun 7 19:59:20 2007 Subject: [sldev] Re: Soft Linden In-Reply-To: <9e6e5c9e0706071918h37a42048ne33084108eab1ed3@mail.gmail.com> References: <9e6e5c9e0706071918h37a42048ne33084108eab1ed3@mail.gmail.com> Message-ID: <9e6e5c9e0706071959t566b9cb8o91d74eb6bb8ae480@mail.gmail.com> And of course... that link for the contributor agreement should be: http://secondlife.com/developers/opensource/submitting Cheers :) On 6/7/07, Soft Noel wrote: > Executive Summary: Soft Noel = Soft Linden. Joy! Soon: smuggling > patches into LL. > > > A number of ya know me from SLDev[-Traffic] and haunting Rob's office > hours whenever I've been able. To those of you who don't know me: Hi! > > I'm happy to say that I've taken a job at Linden Lab. I'm going > through the "onboarding" process right now, which lasts a couple > weeks. After I've finished my orientation, I want to start holding > meetings for developers with contribution agreements on file. If you > have questions related to projects in development, or patches that are > ready for incorporation but haven't been given attention, I want to > ensure you've got a straight pipeline to any help you need. > > If you haven't signed a contributor agreement, please consider sending > one in. You've got a couple weeks before our first meeting: > [wrong link] > > If you've sent a contributor agreement in, but never received a > confirmation, feel free to email me at soft@softnoel.org with both > your SL name and RL name. I can check to verify that you're on the > list. > > > The process for submitting patches hasn't changed, and it's documented > very well here: > > https://wiki.secondlife.com/wiki/Submitting_patches > > What is changing is that I'm going to start ensuring that every patch > gets acceptance or constructive feedback, and that contributors get > extra technical help when they need it. While LL's patch acceptance > has improved a lot in recent weeks, I hope I can help make it better > still. When you make the effort to help us out, it's the least we can > do in return for the favor. > > > In the near term, I should be making Rob's office hours regularly from > now on - nobody looks at me askance if I ask to go on SL for an hour > or so at work anymore. :) Catch ya there! > From okumoto at ucsd.edu Thu Jun 7 21:49:32 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Thu Jun 7 21:49:36 2007 Subject: [sldev] Problem with new src tar files. Message-ID: <4668DFDC.4050700@ucsd.edu> Looks like the valgrind config file is missing from the new src tar file. [success full compile and link stuff deleted] Processing unicode.ttf => unicode.ttf Processing secondlife-i686-bin-stripped => bin/do-not-directly-run-secondlife-bin Processing linux_tools/launch_url.sh => launch_url.sh Processing * => None Processing featuretable_linux.txt => None Processing secondlife-i686.supp => None Traceback (most recent call last): File "newview/viewer_manifest.py", line 455, in ? main(srctree=viewer_dir, dsttree=os.path.join(viewer_dir, "packaged")) File "newview/../lib/python/indra/llmanifest.py", line 203, in main wm.do(*args['actions']) File "newview/../lib/python/indra/llmanifest.py", line 573, in do self.construct() File "newview/viewer_manifest.py", line 414, in construct self.path("secondlife-i686.supp") File "newview/../lib/python/indra/llmanifest.py", line 563, in path self.check_file_exists(src) File "newview/../lib/python/indra/llmanifest.py", line 527, in check_file_exists raise RuntimeError("Path %s doesn't exist" % ( RuntimeError: Path /local/home/linden/linden/indra/newview/secondlife-i686.supp doesn't exist scons: *** [newview/SecondLife_i686_1_17_0_9.tar.bz2] Error 1 scons: building terminated because of errors. make: *** [build] Error 2 Script done, file is build.log-Jun-07-2 From robla at lindenlab.com Thu Jun 7 22:37:47 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jun 7 22:37:53 2007 Subject: [sldev] Problem with new src tar files. In-Reply-To: <4668DFDC.4050700@ucsd.edu> References: <4668DFDC.4050700@ucsd.edu> Message-ID: <4668EB2B.6080700@lindenlab.com> Hi Max, Sorry about that; it should be in the next release. In the meantime, you can download it from here: https://svn.secondlife.com/svn/linden/branches/non-voice-1-17-0/indra/newview/secondlife-i686.supp Rob On 6/7/07 9:49 PM, Max Okumoto wrote: > Looks like the valgrind config file is missing from the new src tar file. > > [success full compile and link stuff deleted] > > Processing unicode.ttf => unicode.ttf > Processing secondlife-i686-bin-stripped => > bin/do-not-directly-run-secondlife-bin > Processing linux_tools/launch_url.sh => launch_url.sh > Processing * => None > Processing featuretable_linux.txt => None > Processing secondlife-i686.supp => None > Traceback (most recent call last): > File "newview/viewer_manifest.py", line 455, in ? > main(srctree=viewer_dir, dsttree=os.path.join(viewer_dir, "packaged")) > File "newview/../lib/python/indra/llmanifest.py", line 203, in main > wm.do(*args['actions']) > File "newview/../lib/python/indra/llmanifest.py", line 573, in do > self.construct() > File "newview/viewer_manifest.py", line 414, in construct > self.path("secondlife-i686.supp") > File "newview/../lib/python/indra/llmanifest.py", line 563, in path > self.check_file_exists(src) > File "newview/../lib/python/indra/llmanifest.py", line 527, in > check_file_exists > raise RuntimeError("Path %s doesn't exist" % ( > RuntimeError: Path > /local/home/linden/linden/indra/newview/secondlife-i686.supp doesn't > exist > scons: *** [newview/SecondLife_i686_1_17_0_9.tar.bz2] Error 1 > scons: building terminated because of errors. > make: *** [build] Error 2 > Script done, file is build.log-Jun-07-2 > > _______________________________________________ > 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/20070607/d99848f2/signature.pgp From okumoto at ucsd.edu Thu Jun 7 23:13:29 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Thu Jun 7 23:13:33 2007 Subject: [sldev] Problem with new src tar files. In-Reply-To: <4668EB2B.6080700@lindenlab.com> References: <4668DFDC.4050700@ucsd.edu> <4668EB2B.6080700@lindenlab.com> Message-ID: <4668F389.5090207@ucsd.edu> Thanks. That was fast. Didn't even have time to finish writing the bug report. Max Rob Lanphier wrote: > Hi Max, > > Sorry about that; it should be in the next release. > > In the meantime, you can download it from here: > https://svn.secondlife.com/svn/linden/branches/non-voice-1-17-0/indra/newview/secondlife-i686.supp > > Rob > > On 6/7/07 9:49 PM, Max Okumoto wrote: > >> Looks like the valgrind config file is missing from the new src tar file. >> >> [success full compile and link stuff deleted] >> >> Processing unicode.ttf => unicode.ttf >> Processing secondlife-i686-bin-stripped => >> bin/do-not-directly-run-secondlife-bin >> Processing linux_tools/launch_url.sh => launch_url.sh >> Processing * => None >> Processing featuretable_linux.txt => None >> Processing secondlife-i686.supp => None >> Traceback (most recent call last): >> File "newview/viewer_manifest.py", line 455, in ? >> main(srctree=viewer_dir, dsttree=os.path.join(viewer_dir, "packaged")) >> File "newview/../lib/python/indra/llmanifest.py", line 203, in main >> wm.do(*args['actions']) >> File "newview/../lib/python/indra/llmanifest.py", line 573, in do >> self.construct() >> File "newview/viewer_manifest.py", line 414, in construct >> self.path("secondlife-i686.supp") >> File "newview/../lib/python/indra/llmanifest.py", line 563, in path >> self.check_file_exists(src) >> File "newview/../lib/python/indra/llmanifest.py", line 527, in >> check_file_exists >> raise RuntimeError("Path %s doesn't exist" % ( >> RuntimeError: Path >> /local/home/linden/linden/indra/newview/secondlife-i686.supp doesn't >> exist >> scons: *** [newview/SecondLife_i686_1_17_0_9.tar.bz2] Error 1 >> scons: building terminated because of errors. >> make: *** [build] Error 2 >> Script done, file is build.log-Jun-07-2 >> >> _______________________________________________ >> 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/20070607/d31c704f/attachment.htm From okumoto at ucsd.edu Thu Jun 7 23:52:26 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Thu Jun 7 23:52:31 2007 Subject: [sldev] Problem with new src tar files. In-Reply-To: <4668F389.5090207@ucsd.edu> References: <4668DFDC.4050700@ucsd.edu> <4668EB2B.6080700@lindenlab.com> <4668F389.5090207@ucsd.edu> Message-ID: <4668FCAA.5030908@ucsd.edu> The slviewer-linux-libs-1-17-0-9.tar.gz is missing two shared libs libtcmalloc.so.0 libstacktrace.so.0 So the releasefordownload build does not work. But after every thing is in place it looks like things are working. Startup is alot faster! Max Max Okumoto wrote: > Thanks. That was fast. Didn't even have time to finish writing the > bug report. > > Max > Rob Lanphier wrote: >> Hi Max, >> >> Sorry about that; it should be in the next release. >> >> In the meantime, you can download it from here: >> https://svn.secondlife.com/svn/linden/branches/non-voice-1-17-0/indra/newview/secondlife-i686.supp >> >> Rob >> >> On 6/7/07 9:49 PM, Max Okumoto wrote: >> >>> Looks like the valgrind config file is missing from the new src tar file. >>> >>> [success full compile and link stuff deleted] >>> >>> Processing unicode.ttf => unicode.ttf >>> Processing secondlife-i686-bin-stripped => >>> bin/do-not-directly-run-secondlife-bin >>> Processing linux_tools/launch_url.sh => launch_url.sh >>> Processing * => None >>> Processing featuretable_linux.txt => None >>> Processing secondlife-i686.supp => None >>> Traceback (most recent call last): >>> File "newview/viewer_manifest.py", line 455, in ? >>> main(srctree=viewer_dir, dsttree=os.path.join(viewer_dir, "packaged")) >>> File "newview/../lib/python/indra/llmanifest.py", line 203, in main >>> wm.do(*args['actions']) >>> File "newview/../lib/python/indra/llmanifest.py", line 573, in do >>> self.construct() >>> File "newview/viewer_manifest.py", line 414, in construct >>> self.path("secondlife-i686.supp") >>> File "newview/../lib/python/indra/llmanifest.py", line 563, in path >>> self.check_file_exists(src) >>> File "newview/../lib/python/indra/llmanifest.py", line 527, in >>> check_file_exists >>> raise RuntimeError("Path %s doesn't exist" % ( >>> RuntimeError: Path >>> /local/home/linden/linden/indra/newview/secondlife-i686.supp doesn't >>> exist >>> scons: *** [newview/SecondLife_i686_1_17_0_9.tar.bz2] Error 1 >>> scons: building terminated because of errors. >>> make: *** [build] Error 2 >>> Script done, file is build.log-Jun-07-2 >>> >>> _______________________________________________ >>> 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/20070607/eefb811f/attachment-0001.htm From p.rizla at yahoo.co.uk Fri Jun 8 02:21:27 2007 From: p.rizla at yahoo.co.uk (Peter Rizla) Date: Fri Jun 8 02:21:30 2007 Subject: [sldev] Doxygen & Comments Message-ID: <306092.40857.qm@web25312.mail.ukl.yahoo.com> IMAO: The ability to insert comments was not made a part of source code files just so a company could claim ownership of some generic/bespoke code, nor to big up the author of said piece of code. They were created so that a noob to it could soon follow and understand the code without much hard study. And to know where to go if there is a problem with (a bit of) the code or their clarity in understanding it (in both senses). Nicholaz Beresford wrote: > C++ as a language of expression clearly has it's > benefits and I agree that readable code (which most likely also will > use real world language to clarify, i.e. a variable will be named > particle_count rather than x32) is preferrable over comment. Jason Giglio wrote: > One of the major principles of good language and program design is > that > related things should be close to each other in the file and application. John Hurliman wrote: > While we are talking about experiences I will throw mine in. When > contracted to write software for international teams I've always been > asked to go the extra mile on software comments and documentation, ************************************ IMAO: Those are things that can be thought of as some golden rules. Do they not teach them anymore? Is it just anarchic rebellion? Or laziness? It is fair enough, and we have almost certainly all done it, rules can be broken. Especially behind closed doors. That does not necessarily make it right. Certainly if you were to break social rules out in the open, you will have trouble from it. It is also all too easy to fall foul of the rules when you are ignorant of them, or if they are unclear to you. Especially when you are among those rules that do not follow an obvious logic. Ignorance is of course, often regarded as no defence. I'd rather jump onto a bus that goes to where I wanna go, or read a map of the route, than try to follow the road signs or landmarks as, if and when I see them. Sure enough, so that I can know exactly where I am along the journey the next time I go, I will be taking note of those road signs and landmarks as I travel this time. Dzonatas wrote: > In the same regards, you are telling me that the majority of C++ > programmers will benefit from: > * comments on English words in source code, which describe, > ** common grammar of the English word > ** appropriate usage of such English word in a prescribed context > ** the expected perception of others when such word is used > * and further describe > ** why such words should one have one meaning, as intended, if possible > ** a justification of a to be rewritten usage of words that have lasted > to this date because, solely, it has gone way beyond the scope of its > original usage to the point a simple look-up into a thesaurus can't even > justify the time to further beautify it in the context it exists ************************************ I don't think they are saying that, and I guess you are being a bit sarcastic. I think its better to not use slang, write cryptic or irrelevant comments, just to use plain and simple English. English, because LL talks (American) English. Dzonatas wrote: > > If their is to be commented source code, then those comments are best > put in another database. The reference number can be left in > the source ************************************ I'm sorry but my externally hyperlinked comment on this cannot be accessed because I have decided to re-arrange things, or it was removed to another location during the archiving process. And I all but repeated others. Dzonatas wrote: > > When push comes to shove (I mean to shove a release out to ship), is > there a need to immediately re-write a piece of code to the intention > that the comment says it is suppose to do, or would it be > better just to > delete the comment because the code that exists has gone > through tried > and tested means and an expert in C++ can translate exactly > what it does > for you? ************************************ Check with the author if I can find them? (darn, his name was excluded by the coding standards) Highlight this code vs comment mismatch in discussion with the community/developers? Jump to a conclusion by doing one of your choices ? - because you think you have a bigger one than everyone else ___________________________________________________________ Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070608/169e6e01/attachment.htm From nicholaz at blueflash.cc Fri Jun 8 04:38:46 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 8 04:39:05 2007 Subject: [sldev] Next bug triage: June 11 In-Reply-To: <46685A9E.3040207@lindenlab.com> References: <46685A9E.3040207@lindenlab.com> Message-ID: <46693FC6.8050103@blueflash.cc> Rob Lanphier wrote: > The theme last week was "bugs with patches attached", which resulted in > a lot of bugs getting imported. > > We didn't get through last week's agenda, so one possibility is to > continue using that agenda: > https://wiki.secondlife.com/wiki/Bug_triage/2007-06-04#Agenda_.28ran_out_of_time.29 > > If something has already been imported (which you can see by whether or > not there's a "Linden Lab Issue ID" associated with it), we probably > don't need to discuss it at this point, since there's probably already a > discussion that's happening at Linden Lab about that issue. If an issue > that's been imported already, but it looks stale, then just put > something in the comments asking about the issue. I just made a first draft for the next meeting based on the stuff where we ran out of time and added a section on top with room for non-patch related stuff. What can stil be done about the list is: * check issues if they have a recent LL-ID (I'd say around 40000 upwards): simply delete these from the wiki * check issues if thes have an ID but seem stale (I saw two or three) * add a short comment to the issue that sums it up (i.e. how complex, how safe) * especially if you have objections or see need for discussion this could probably be done upfront here or via comments on the wiki * promote order Nick From tateru.nino at gmail.com Fri Jun 8 04:39:16 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 8 04:39:39 2007 Subject: [sldev] Doxygen & Comments In-Reply-To: <306092.40857.qm@web25312.mail.ukl.yahoo.com> References: <306092.40857.qm@web25312.mail.ukl.yahoo.com> Message-ID: <46693FE4.6040201@gmail.com> Comments are there so you know what the code is *supposed* to do. The code only tells you what it actually *does* ;) Peter Rizla wrote: > > IMAO: The ability to insert comments was not made a part of source > code files just so a company could claim ownership of some > generic/bespoke code, nor to big up the author of said piece of code. > They were created so that a noob to it could soon follow and > understand the code without much hard study. And to know where to go > if there is a problem with (a bit of) the code or their clarity in > understanding it (in both senses). > > > > Nicholaz Beresford wrote: > > > C++ as a language of expression clearly has it's > > > benefits and I agree that readable code (which most likely also will > > > use real world language to clarify, i.e. a variable will be named > > > particle_count rather than x32) is preferrable over comment. > > > > Jason Giglio wrote: > > > One of the major principles of good language and program design is > > > that > > > related things should be close to each other in the file and > application. > > > > John Hurliman wrote: > > > While we are talking about experiences I will throw mine in. When > > > contracted to write software for international teams I've always been > > > asked to go the extra mile on software comments and documentation, > > > > ************************************ > > IMAO: Those are things that can be thought of as some golden rules. > > Do they not teach them anymore? Is it just anarchic rebellion? Or > laziness? > > It is fair enough, and we have almost certainly all done it, rules can > be broken. Especially behind closed doors. That does not necessarily > make it right. Certainly if you were to break social rules out in the > open, you will have trouble from it. It is also all too easy to fall > foul of the rules when you are ignorant of them, or if they are > unclear to you. Especially when you are among those rules that do not > follow an obvious logic. Ignorance is of course, often regarded as no > defence. > > > > I'd rather jump onto a bus that goes to where I wanna go, or read a > map of the route, than try to follow the road signs or landmarks as, > if and when I see them. Sure enough, so that I can know exactly where > I am along the journey the next time I go, I will be taking note of > those road signs and landmarks as I travel this time. > > > > Dzonatas wrote: > > > In the same regards, you are telling me that the majority of C++ > > > programmers will benefit from: > > > * comments on English words in source code, which describe, > > > ** common grammar of the English word > > > ** appropriate usage of such English word in a prescribed context > > > ** the expected perception of others when such word is used > > > * and further describe > > > ** why such words should one have one meaning, as intended, if possible > > > ** a justification of a to be rewritten usage of words that have lasted > > > to this date because, solely, it has gone way beyond the scope of its > > > original usage to the point a simple look-up into a thesaurus can't > even > > > justify the time to further beautify it in the context it exists > > > > ************************************ > > I don't think they are saying that, and I guess you are being a bit > sarcastic. > > I think its better to not use slang, write cryptic or irrelevant > comments, just to use plain and simple English. > > English, because LL talks (American) English. > > > > Dzonatas wrote: > > > > > > If their is to be commented source code, then those comments are best > > > put in another database. The reference number can be left in > > > the source > > > > ************************************ > > I'm sorry but my externally hyperlinked comment on this cannot be > accessed because I have decided to re-arrange things, or it was > removed to another location during the archiving process. And I all > but repeated others. > > > > Dzonatas wrote: > > > > > > When push comes to shove (I mean to shove a release out to ship), is > > > there a need to immediately re-write a piece of code to the intention > > > that the comment says it is suppose to do, or would it be > > > better just to > > > delete the comment because the code that exists has gone > > > through tried > > > and tested means and an expert in C++ can translate exactly > > > what it does > > > for you? > > ************************************ > > Check with the author if I can find them? (darn, his name was excluded > by the coding standards) > > Highlight this code vs comment mismatch in discussion with the > community/developers? > > Jump to a conclusion by doing one of your choices ? - because you > think you have a bigger one than everyone else > > > > > ------------------------------------------------------------------------ > New Yahoo! Mail is the ultimate force in competitive emailing. Find > out more at the Yahoo! Mail Championships > . > Plus: play games and win prizes. > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From nicholaz at blueflash.cc Fri Jun 8 06:20:40 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 8 06:21:05 2007 Subject: PWNED ... Re: [sldev] Soft Linden In-Reply-To: <9e6e5c9e0706071918h37a42048ne33084108eab1ed3@mail.gmail.com> References: <9e6e5c9e0706071918h37a42048ne33084108eab1ed3@mail.gmail.com> Message-ID: <466957A8.1050008@blueflash.cc> Soft Noel wrote: > Executive Summary: Soft Noel = Soft Linden. Joy! Soon: smuggling > patches into LL. Hehe, see attached :-) (go soft go!) (See http://www.encyclopediadramatica.com/index.php/I_am_in_your_base_killing_your_d00ds if you don't know that internet meme) Nick -------------- next part -------------- A non-text attachment was scrubbed... Name: PWNED (past the guards).jpg Type: image/jpeg Size: 45644 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070608/a2aaa910/PWNEDpasttheguards-0001.jpg From blakar at gmail.com Fri Jun 8 06:23:23 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Fri Jun 8 06:23:26 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <466646D5.4050500@lindenlab.com> References: <466324A5.2040908@blueflash.cc> <466331B2.5000506@dzonux.net> <46641A57.6000409@blueflash.cc> <466646D5.4050500@lindenlab.com> Message-ID: <7992d0d60706080623s487b83bvbd8d276b1ba28329@mail.gmail.com> In the past I've done some things in regards to optimising C/C++ code for better performance. For optimal results you also need to have C++ code that is begging to be optimised. Some parts already are fine, some do need some reordering. Hardest part for a project like this is that its very large. That leaves a lot of room for improvement but it's very hard to find what will yield the most benefit. Your proposal to turn on SSE for all parts may yield unsatisfactory results as a lot of the code is not ready to be turned into SSE instructions. I compile on VS 2005 C++ Express so whatever I dig up will apply to the VS 2005 C++ compiler. I can't guarantee you can reproduce it on the VS 2003 one or that it'll be always equally applicable to other platforms/compilers. It's for example possible that a certain code rewrite allows VS 2005 to replace slower instructions with faster ones while on VS 2003 it may have no effect at all. Note though: In general rewritten C++ will benefit any architecture. Especially changes like the reconstruction of loops like what I had in the patch for VWR-881. No compiler will do that for you and the benefit applies to any architecture. I'll try at first to see if there are things we can easily change for all possible CPU's, be it compiler options or small restructuring. SSE optimisations are out for now as the Athlon didn't have it and the higher speed versions can run SL. Where possible I'll also check how gcc handles the reordering. The math libraries for example can be easily test compiled to assembler using Cygwin or minGW. On 6/6/07, James Cook wrote: > > I was just running around sims with all stuff enabled (I really don't > > want to spend much time on this as it's unlikely that anything like > > a major change in project settings will ever make it into the SL build), > > Don't give up on compiler options! I would happily accept a patch that > changed compiler optimization options, especially if there were > benchmark results to demonstrate the benefits. > > Keep in mind though that we have to support many different processor and > OS combinations. Steve may have more recent stats on what chips our > users are actually using, but I would be a little nervous, for example, > deciding to drop support for PIII chips without a solid benchmark. We > don't really want to be doing multiple Windows builds internally. > > I would be curious about benchmarks where SSE code generation was turned > on for all files. > > James > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From cfk at pacbell.net Fri Jun 8 13:56:55 2007 From: cfk at pacbell.net (Charles Krinke) Date: Fri Jun 8 13:56:58 2007 Subject: [sldev] compiling the viewer Message-ID: <548634.2086.qm@web82605.mail.mud.yahoo.com> I have tried 4 different ways to compile the viewer unsuccesfully and have a few questions about each way. First the opensl-pre-win32.sh. I know this script fails per the wiki trying to find windows.h and winsock2.h amongst others. My question is "How do I tell cygwin to search in the "c:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include" directory where Windows.h and Winsock2.h reside. This is more of interest as I suspect one of the other two paths is more fruitful. Second, on the download from opensecondlife.org with 'svn co svn://opensecondlife.org/opensl/trunk opensl", this one kerchunks with VC# for some time and builds most of the libraries but has trouble with class std:;basic_string symbol resolve. Third, on the download from wiki.secondlife.com/wiki/Source_downloads, I have the 1.16.0.5 three zip files (viewer, libraries & artwork), and this one errors with things like llerror.cpp:177 Cannot convert U16* to LPCWSTR". I suspect this may be an include issue in my setting up the pre-requisites. Fourth, in Linux, I have followed the http://opensecondlife.org/User:Opensource_Obscure/Building_Linux_Viewer recipe and get quite aways but error out with things like gdk-pixbuf/gdk-pixbuf-core.h:169 having trouble with "expected initializer before G_GNUC_NULL_TERMINATED and G_GNUC_MALLOC. Again, I suspect some setup or include issue. A suggestion or four would be greatly appreciated. Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070608/682cb98c/attachment.htm From nicholaz at blueflash.cc Fri Jun 8 13:58:29 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 8 13:58:36 2007 Subject: [sldev] Compiling under VS2005 Message-ID: <4669C2F5.3050604@blueflash.cc> I'm currently trying to build a working set of VC8 project files, but am getting 20>llcompilequeue.obj : error LNK2019: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) referenced in function "protected: void __thiscall LLFloaterCompileQueue::compile(char const *,class LLUUID const &)" (?compile@LLFloaterCompileQueue@@IAEXPBDABVLLUUID@@@Z) 20>llpreviewscript.obj : error LNK2001: unresolved external symbol "int __cdecl lscript_compile(char const *,char const *,char const *,int)" (?lscript_compile@@YAHPBD00H@Z) Does anybody know these or have a solution? Thanks Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From okumoto at ucsd.edu Fri Jun 8 15:06:12 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Fri Jun 8 15:06:16 2007 Subject: [sldev] compiling the viewer In-Reply-To: <548634.2086.qm@web82605.mail.mud.yahoo.com> References: <548634.2086.qm@web82605.mail.mud.yahoo.com> Message-ID: <4669D2D4.5070903@ucsd.edu> I can't speak to building on windows but I might be able to help on the linux side. What distro are you using? And are you using the lastest tar files 1.17.0.9? Max Charles Krinke wrote: > I have tried 4 different ways to compile the viewer unsuccesfully and > have a few questions about each way. > > First the opensl-pre-win32.sh. I know this script fails per the wiki > trying to find windows.h and winsock2.h amongst others. My question is > "How do I tell cygwin to search in the "c:\Program Files\Microsoft > Platform SDK for Windows Server 2003 R2\Include" directory where > Windows.h and Winsock2.h reside. This is more of interest as I suspect > one of the other two paths is more fruitful. > > Second, on the download from opensecondlife.org with 'svn co > svn://opensecondlife.org/opensl/trunk opensl", this one kerchunks with > VC# for some time and builds most of the libraries but has trouble > with class std:;basic_string symbol resolve. > > Third, on the download from wiki.secondlife.com/wiki/Source_downloads, > I have the 1.16.0.5 three zip files (viewer, libraries & artwork), and > this one errors with things like llerror.cpp:177 Cannot convert U16* > to LPCWSTR". I suspect this may be an include issue in my setting up > the pre-requisites. > > Fourth, in Linux, I have followed the > http://opensecondlife.org/User:Opensource_Obscure/Building_Linux_Viewer > recipe and get quite aways but error out with things like > gdk-pixbuf/gdk-pixbuf-core.h:169 having trouble with "expected > initializer before G_GNUC_NULL_TERMINATED and G_GNUC_MALLOC. Again, I > suspect some setup or include issue. > > A suggestion or four would be greatly appreciated. > > Charles > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20070608/5bebe0ec/attachment.htm From cfk at pacbell.net Fri Jun 8 16:08:42 2007 From: cfk at pacbell.net (Charles Krinke) Date: Fri Jun 8 16:08:44 2007 Subject: [sldev] compiling the viewer Message-ID: <461734.39777.qm@web82611.mail.mud.yahoo.com> Dear Max: Thank you for collaborating with me. I am using FedoraCore6 and have all updates installed. This includes atk-1.0, gtk-2.0, glib-2.0, pango-1.0, cairo and scons. I was trying to compile 1.16.0.5, but will download 1.17.0.9 and try again this evening. Perhaps you could kindly help me understand what steps are involved beyond untarring the two .tar.gz and the one .zip file into a common directory and then building. I understand from others that scons is used and although I have this on my system, I have not used it before. Thank you in advance for your kind offer to help.. Charles I can't speak to building on windows but I might be able to help on the linux side. What distro are you using? And are you using the lastest tar files 1.17.0.9? Max -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070608/d1743c4c/attachment.htm From okumoto at ucsd.edu Fri Jun 8 16:46:41 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Fri Jun 8 16:46:45 2007 Subject: [sldev] compiling the viewer In-Reply-To: <461734.39777.qm@web82611.mail.mud.yahoo.com> References: <461734.39777.qm@web82611.mail.mud.yahoo.com> Message-ID: <4669EA61.9030100@ucsd.edu> Skipped content of type multipart/alternative-------------- next part -------------- # # @author Max Okumoto # # Makefile use to down load and build SecondLife binary from source files # from website. # # If SVN_REV is set then use SVN instead of the slviewer-src-${SL_VER}.tar.gz # #SVN_REV = http://svn.secondlife.com/svn/linden/release BUILD = releasefordownload DISTFILES = /local/home/linden/distfiles SL_YEAR = 2007 SL_MONTH = 06 SL_DAY = 02 SL_TYPE = a SL_VER = ${SL_YEAR}${SL_MONTH}${SL_DAY}${SL_TYPE} SL_VER = 1-17-0-9 SL_FOO = SL_URL_PREFIX = http://secondlife.com/developers/opensource/downloads/${SL_YEAR}/${SL_MONTH} SL_SRC_TAR = slviewer-src-${SL_FOO}${SL_VER}.tar.gz SL_ART_ZIP = slviewer-artwork-${SL_FOO}${SL_VER}.zip SL_LIB_TAR = slviewer-linux-libs-${SL_FOO}${SL_VER}.tar.gz FMOD_MAJ = 3 FMOD_MIN = 75 FMOD_VER = fmodapi${FMOD_MAJ}${FMOD_MIN}linux FMOD_URL_PREFIX = http://www.fmod.org/files FMOD_SRC_TAR = ${FMOD_VER}.tar.gz ############################################################################## # ############################################################################## all: unpack update replace build ############################################################################## # Get stuff ############################################################################## get: ${DISTFILES}/${SL_SRC_TAR} get: ${DISTFILES}/${SL_ART_ZIP} get: ${DISTFILES}/${SL_LIB_TAR} ${DISTFILES}/${SL_LIB_TAR}: (cd ${DISTFILES}; wget ${SL_URL_PREFIX}/${SL_LIB_TAR}) ${DISTFILES}/${SL_SRC_TAR}: (cd ${DISTFILES}; wget ${SL_URL_PREFIX}/${SL_SRC_TAR}) ${DISTFILES}/${SL_ART_ZIP}: (cd ${DISTFILES}; wget ${SL_URL_PREFIX}/${SL_ART_ZIP}) ${DISTFILES}/${FMOD_SRC_TAR}: (cd ${DISTFILES}; wget ${FMOD_URL_PREFIX}/${FMOD_SRC_TAR}) ############################################################################## # Unpack stuff ############################################################################## unpack: linden/LICENSE-source.txt unpack: linden/LICENSE-logos.txt unpack: linden/LICENSE-libraries-linux.txt unpack: linden/libraries/i686-linux/lib_release_client/libfmod-${FMOD_MAJ}.${FMOD_MIN}.so linden/LICENSE-logos.txt: ${DISTFILES}/${SL_ART_ZIP} @echo 'Unpack slviewer artwork' @unzip -q ${DISTFILES}/${SL_ART_ZIP} @touch linden/LICENSE-logos.txt linden/LICENSE-libraries-linux.txt: ${DISTFILES}/${SL_LIB_TAR} @echo 'Unpack slviewer libraries' @tar xf ${DISTFILES}/${SL_LIB_TAR} @touch linden/LICENSE-libraries-linux.txt linden/LICENSE-source.txt: ${DISTFILES}/${SL_SRC_TAR} @if [ -n "${SVN_REV}" ]; then \ echo 'Download slviewer src using SVN'; \ svn co -q ${SVN_REV} linden; \ else \ echo 'Unpack slviewer src'; \ tar xf ${DISTFILES}/${SL_SRC_TAR}; \ fi @touch linden/LICENSE-source.txt linden/libraries/i686-linux/lib_release_client/libfmod-${FMOD_MAJ}.${FMOD_MIN}.so: ${DISTFILES}/${FMOD_SRC_TAR} @echo 'Unpack FMOD library' @tar xf ${DISTFILES}/${FMOD_SRC_TAR} @(cd ${FMOD_VER}/api/inc; tar cf - .) |\ (cd linden/libraries/i686-linux/include; tar xf -) @(cd ${FMOD_VER}/api; tar -cf - libfmod-${FMOD_MAJ}.${FMOD_MIN}.so) |\ (cd linden/libraries/i686-linux/lib_release_client/; tar xf -) @rm -rf ${FMOD_VER} ############################################################################## # Update stuff ############################################################################## update: if [ -f linden/.svn/entries ]; then \ (cd linden; svn update); \ fi ############################################################################## # Replase stuff ############################################################################## replace: linden/indra/newview/libllkdu.so replace: linden/indra/lib/libkdu_v42R.so replace: linden/indra/newview/viewer_manifest.py.fixed linden/indra/newview/libllkdu.so: cp linden/libraries/i686-linux/lib_release_client/libllkdu.so \ linden/indra/newview/libllkdu.so linden/indra/lib/libkdu_v42R.so: cp linden/libraries/i686-linux/lib_release_client/libkdu_v42R.so \ linden/indra/lib/libkdu_v42R.so linden/indra/newview/viewer_manifest.py.fixed: # # Enable faster jpg decode libraries. # sed \ -e '/^#.*libllkdu\.so/s/^#//' \ -e '/^#.*libkdu_v42R\.so/s/^#//' \ linden/indra/newview/viewer_manifest.py > linden/indra/newview/viewer_manifest.py.fixed cp linden/indra/newview/viewer_manifest.py.fixed linden/indra/newview/viewer_manifest.py foo: # # Don't package up google-profiling stuff (this can be removed when # Linden Labs adds these libaries to the tar file. # sed \ -e '/^ *self.path("libtcmalloc\.so/s/^/#/' \ -e '/^ *self.path("libstacktrace\.so/s/^/#/' \ linden/indra/newview/viewer_manifest.py > linden/indra/newview/viewer_manifest.py.fixed cp linden/indra/newview/viewer_manifest.py.fixed linden/indra/newview/viewer_manifest.py ############################################################################## # Build stuff ############################################################################## build: date (cd linden/indra; scons DISTCC=no BTARGET=client MOZLIB=no BUILD=${BUILD}) date build-no-fmod: date (cd linden/indra; scons FMOD=no DISTCC=no BTARGET=client MOZLIB=no BUILD=${BUILD}) date ############################################################################## # Install stuff ############################################################################## install: #bzcat linden/indra/newview/SecondLife_i686_1_16_0_5.tar.bz2 | (cd /opt; tar xf -) bzcat linden/indra/newview/SecondLife_i686_1_17_0_9.tar.bz2 | (cd /opt; tar xf -) ############################################################################## # Clean stuff ############################################################################## clean: rm -rf linden ############################################################################## # Utilities ############################################################################## tags: find linden -type f -name '*.cpp' -exec ctags -e --append {} \; -------------- next part -------------- # @file secondlife-i686.supp # @brief Valgrind suppressions for Linux i686 viewer. # # Copyright (c) 2000-$CurrentYear$, Linden Research, Inc. # $License$ # # This is a Valgrind suppression file for use on the viewer. # # Hints for most successful use of valgrind: # # - If your distro comes with library packages that contain debug info # (Fedora calls these debuginfo packages), install them. # - Inside the SConstruct script, disable linking against tcmalloc. # Valgrind and tcmalloc don't get along. # - Delete the copy of libstdc++.so.6 that is bundled with the viewer # (if you have one), so that the viewer will use the system's # libstdc++. # - After you build the viewer, replace the stripped # do-not-directly-run-secondlife-bin binary with an unstripped copy. # Mozilla noise. { Cond:mozilla-runtime/*.so Memcheck:Cond obj:*/mozilla-runtime-*/*.so } { Value4:mozilla-runtime/*.so Memcheck:Value4 obj:*/mozilla-runtime-*/*.so } { Cond:mozilla-runtime/*/*.so Memcheck:Cond obj:*/mozilla-runtime-*/*/*.so } { Value4:mozilla-runtime/*/*.so Memcheck:Value4 obj:*/mozilla-runtime-*/*/*.so } { Cond:mozilla-runtime/libmozjs.so Memcheck:Cond obj:*/libmozjs.so } { Cond:mozilla-runtime/libxul Memcheck:Cond obj:*/libxul.so } { Value4:mozilla-runtime/libxul Memcheck:Value4 obj:*/libxul.so } # libcurl badness. { Cond:libcurl/inflate/Curl_unencode_gzip_write Memcheck:Cond fun:inflate fun:inflate_stream fun:Curl_unencode_gzip_write } { Cond:libcurl/ares_mkquery/Curl_getaddrinfo Memcheck:Cond fun:ares_mkquery fun:ares_query fun:ares_search fun:next_lookup fun:Curl_getaddrinfo } # libdl business. { Cond:libdl/_dl_relocate_object Memcheck:Cond fun:_dl_relocate_object } # X11 fun. { Param:X11/_X11TransSocketWritev/writev/vector Memcheck:Param writev(vector[...]) fun:writev fun:_X11TransSocketWritev } { Param:X11/_X11TransWrite/write/buf Memcheck:Param write(buf) obj:/lib/libc-2.6.so fun:_X11TransWrite } # OpenSSL stuff. { Value4:libcrypto Memcheck:Value4 obj:*/libcrypto.so.0.9* } { Cond:libcrypto Memcheck:Cond obj:*/libcrypto.so.0.9* } { Value4:libssl Memcheck:Value4 obj:*/libssl.so.0.9* } { Cond:libcrypto Memcheck:Cond obj:*/libssl.so.0.9* } # NVIDIA driver brokenness. { Addr4:NVIDIA/libGL Memcheck:Addr4 obj:/usr/lib/libGL.so.1.0.* } { Value4:NVIDIA/libGL Memcheck:Value4 obj:/usr/lib/libGL.so.1.0.* } { Cond:NVIDIA/libGL Memcheck:Cond obj:/usr/lib/libGL.so.1.0.* } { Value4:NVIDIA/libGLcore Memcheck:Value4 obj:/usr/lib/libGLcore.so.1.0.* } { Cond:NVIDIA/libGLcore Memcheck:Cond obj:/usr/lib/libGLcore.so.1.0.* } { Param:NVIDIA/ioctl Memcheck:Param ioctl(generic) fun:ioctl fun:_nv000130gl } From cfk at pacbell.net Fri Jun 8 17:03:42 2007 From: cfk at pacbell.net (Charles Krinke) Date: Fri Jun 8 17:03:44 2007 Subject: [sldev] compiling the viewer Message-ID: <707361.74226.qm@web82606.mail.mud.yahoo.com> Thank you Max for giving me something to study. Let me go and work through this carefully over the weekend and see if I can get results. One last parting question. I noticed mention on the secondlife wiki that gcc 4 was not compatible with this compile and LL used gcc-3.4, so I am installing the compat-gcc-34-c++ package to hopefully allow both compilers to co-exist on this system. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070608/39657889/attachment.htm From okumoto at ucsd.edu Fri Jun 8 17:20:10 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Fri Jun 8 17:20:14 2007 Subject: [sldev] compiling the viewer In-Reply-To: <707361.74226.qm@web82606.mail.mud.yahoo.com> References: <707361.74226.qm@web82606.mail.mud.yahoo.com> Message-ID: <4669F23A.40500@ucsd.edu> Sorry should have mentioned that. Yes for FC6 I used % yum install compat-gcc-34 compate-gcc-34-c++ And they do not conflict with the system gcc. Max Charles Krinke wrote: > Thank you Max for giving me something to study. Let me go and work > through this carefully over the weekend and see if I can get results. > One last parting question. I noticed mention on the secondlife wiki > that gcc 4 was not compatible with this compile and LL used gcc-3.4, > so I am installing the compat-gcc-34-c++ package to hopefully allow > both compilers to co-exist on this system. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070608/0f7e499b/attachment.htm From alissa_sabre at yahoo.co.jp Fri Jun 8 17:52:36 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri Jun 8 17:52:50 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <4669C2F5.3050604@blueflash.cc> References: <4669C2F5.3050604@blueflash.cc> Message-ID: <76kwms0nei5ds4ds4f84s0.alissa_sabre@yahoo.co.jp> NIck, > I'm currently trying to build a working set of VC8 project files, but am > getting ... abridged ... > Does anybody know these or have a solution? I'm not sure this is the answer you want, but my solution to the problem is always use VC7 solution and project files even on VS2005. That means you need to convert VC7 files to VC8 files and adjust some details of the project properties by hands everytime a new release is distributed... Exact steps you need to follow is explained on the wiki: http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#Environment_Setup # I doubt you are asking different thing, Nick, because I don't think you have not read the page... -------------------------------------- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ From dzonatas at dzonux.net Fri Jun 8 17:35:53 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jun 8 18:03:01 2007 Subject: [sldev] SL on Xeon processors Message-ID: <4669F5E9.8020703@dzonux.net> The Xeon processor appears to have something a bit different about it, which the compile for mainline pentium 4 with GCC doesn't include. The Windows OS appears to be a bit more random in how it schedules processes on different parts of Xeon CPUs. It is obvious the software will have to do a little more work to fix which threads get scheduled on each logical unit. It is a bit easier to do on Windows. On Linux, a special program would have to be run in order to properly enable optimal schedules. The problem of the Xeon environment in default Windows can be easily exploited with random benchmarks of different threads under heavy cache hits. As SL starts up, the collection of threads that get schedule on any particular logical unit is fairly arbitrary. A simple solution would be to pair up those threads that can multi-thread optimally together on a single logical unit. Don't think that SL is not capable of being able to run tests to determine the best thread chain, but it can tend to look not worthwhile to complete the analysis phase. Beyond SL, next years machine that have dynamic multi-core technology have already started to claim such analysis phase worthwhile for many application. Simply and recently, processor producers continue to claim that most application still do not know how to handle multi-core technology optimally. Just a helpful note. =) -- From cnd at knowprose.com Fri Jun 8 19:06:43 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Fri Jun 8 19:06:51 2007 Subject: [sldev] Doxygen & Comments In-Reply-To: <46693FE4.6040201@gmail.com> References: <306092.40857.qm@web25312.mail.ukl.yahoo.com> <46693FE4.6040201@gmail.com> Message-ID: <466A0B33.7030106@knowprose.com> Tateru Nino wrote: > Comments are there so you know what the code is *supposed* to do. The > code only tells you what it actually *does* ;) > Good comments are supposed to do both. -- Taran Rampersad Presently in: San Fernando, Trinidad and Tobago cnd@knowprose.com http://www.knowprose.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla From peter at phillips.net Fri Jun 8 21:03:14 2007 From: peter at phillips.net (Peter Phillips) Date: Fri Jun 8 21:03:15 2007 Subject: [sldev] SL on Xeon processors In-Reply-To: <4669F5E9.8020703@dzonux.net> References: <4669F5E9.8020703@dzonux.net> Message-ID: <466A2682.1020107@phillips.net> Dzonatas, Are you alluding to the use of hyper-threading? For what it's worth I wound up turning hyper-threading off on the dual xeon box I was using to build and run Second Life and found that it generally "felt" more consistent than having HT turned on. I think my compile times slowed a bit, but overall the trade-off felt very worthwhile. Cheers, Peter Dzonatas wrote: > The Xeon processor appears to have something a bit different about it, > which the compile for mainline pentium 4 with GCC doesn't include. The > Windows OS appears to be a bit more random in how it schedules > processes on different parts of Xeon CPUs. It is obvious the software > will have to do a little more work to fix which threads get scheduled > on each logical unit. It is a bit easier to do on Windows. On Linux, a > special program would have to be run in order to properly enable > optimal schedules. > > The problem of the Xeon environment in default Windows can be easily > exploited with random benchmarks of different threads under heavy > cache hits. As SL starts up, the collection of threads that get > schedule on any particular logical unit is fairly arbitrary. A simple > solution would be to pair up those threads that can multi-thread > optimally together on a single logical unit. > > Don't think that SL is not capable of being able to run tests to > determine the best thread chain, but it can tend to look not > worthwhile to complete the analysis phase. > > Beyond SL, next years machine that have dynamic multi-core technology > have already started to claim such analysis phase worthwhile for many > application. Simply and recently, processor producers continue to > claim that most application still do not know how to handle multi-core > technology optimally. > > Just a helpful note. =) > From dzonatas at dzonux.net Fri Jun 8 23:00:18 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jun 8 23:00:14 2007 Subject: HT Re: [sldev] SL on Xeon processors In-Reply-To: <466A2682.1020107@phillips.net> References: <4669F5E9.8020703@dzonux.net> <466A2682.1020107@phillips.net> Message-ID: <466A41F2.50205@dzonux.net> Peter Phillips wrote: > Dzonatas, > > Are you alluding to the use of hyper-threading? http://news.zdnet.co.uk/hardware/0,1000000091,39286539,00.htm The reason why current OS thread schedulers fail on HT systems are (1) dumb cache-awareness and (2) paired threads that need to use the exact same resources that were not designed to be shared. The methodology naturally follows more advanced software development skills. http://en.wikipedia.org/wiki/Pair_programming That wikipedia article starts to clearly state the idea, but it immediately went into some other issue about political discipline. The architects of the BlueGene/L have loudly stated that two physically connected logical units are paired to do exactly two separate tasks. For example, one accesses the network bus while the other number crunches. In the BlueGene/L, there is 65,536 cores (two logical units per each CPU). The machine does about 280 teraflops. http://www.llnl.gov/asc/computing_resources/bluegenel/ This is by no means meant to compare people who sit near each other in cubical style as an enabled HT multi-core processor. Instead, Intel's 80x86 Terascale CPU has 80 of the x86 based processors. It is rated around 1.8 teraflops for a single CPU. That is 80 logical units per CPU. If one replaced all the BlueGene/L CPUs with 80x86 Terascale CPUs, that would be about 117,964 teraflops. We can expect something like that performance increase in the next major supercomputer. I allude the size of the 80x86 Terascale CPU to roughly the size of the CPU that is currently in a typical workstation. It uses about the same amount of power. The Xeon and others... similar size. Intel's Nahelem, being partially derived from the terascale technology, is only the "tock" of the particular microarchitecture series. For SL, the "tick" after would be the realization of a filled in void. =) -- From Paul.Hampson at Pobox.com Fri Jun 8 23:47:15 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Fri Jun 8 23:47:26 2007 Subject: [sldev] Debian preliminary packages In-Reply-To: <9e6e5c9e0706040002t70307522g11a46c44f2194d46@mail.gmail.com> References: <20070506234827.GB18130@keitarou> <20070507092458.GA23509@keitarou> <20070530093153.GA13848@keitarou> <9e6e5c9e0706040002t70307522g11a46c44f2194d46@mail.gmail.com> Message-ID: <20070609064715.GA21873@keitarou> On Mon, Jun 04, 2007 at 12:02:32AM -0700, Soft Noel wrote: > On 5/30/07, Paul TBBle Hampson wrote: > >On Mon, May 07, 2007 at 07:24:58PM +1000, Paul TBBle Hampson wrote: > >> On Mon, May 07, 2007 at 09:48:27AM +1000, Paul TBBle Hampson wrote: > >>> I've just posted the preliminary Debian packaging of > >>> slviewer, to http://www.tbble.net/debian/ > >>> However, they don't actually work just now, due to both the > >>> missing res-sdl and character directories in the 1.15.0.2 > >>> release tarball, and an error I get when I try to connect, > >>> "Ran off end of packet ObjectUpdate from 64.154.220.9:13004". > >> OK, fixed the packages, so they aren't missing files. ObjectUpdate > >> packet underrun still happens on agni though. -_- > >Just flicking back through the SLTraffic, and noticed that there might > >have been some expectation of binary uploads of these packages from > >me for arches other than PowerPC. > >I've not got any other system capable of building them for upload > >(or in fact, any other systems at the moment. -_-) > >The plan is to actually get these into Debian proper, so that > >the Debian buildd network will actually build the other arches > >for me. ^_^ > In the past, Debian has not been good about accepting software that > needs to change often. Even software like SpamAssassin that's usable, > but which goes stale quickly, was met with resistance in the past. As of Etch's release, debian-volatile [1] has become an officially supported project, where things that target fast-moving targers, such as spamassassin, can be updated during the life of a stable release. I expect slviewer'd go there somewhere. If debian-volatile does not wish to take slviewer under its wing, them backports.org would prolly be accepting of a stable backport of slviewer. By "resistance" you mean "Debian would not change its stable-update policy to accomodate things like Spamassassin", I take it. Not "Debian refused to allow things like Spamassassin into Debian", which would surprise me, having used Spamassassin on Debian for over two full stable release cycles. [1] http://www.debian.org/volatile/ > Given that the viewer would only remain usable for a tiny fragment of > the typical Debian release cycle, would it make more sense to look at > something like the pine-tracker package, which merely makes note of > changes to the authoritative package elsewhere, or even the Sun > JavaSDK packages which centrally install and track the contents of > tarballs the user downloads to an appropriate directory? Pine isn't in Debian because it's license is not DFSG free. In fact, a glance suggets it's unredistributable for Debian in binary form, which is why the pine-tracker package in non-free actually includes the entire source, but does not build it for Debian archive uploads. I think you're thinking of java-package, which was used to make .deb packages of Java SDKs and JREs from the un-redistributable upstream tarballs. Sun's JDK and JRE is now redistributable, and appears fully in non-free, without alternative downloads needed. Other JDKs that are not redistributable (such as the IBM JDK and JRE) still require the use of a package such as java-package. Thankyou for the opportunity to correct these misconceptions about Debian. ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070609/845a6316/attachment.pgp From Paul.Hampson at Pobox.com Sat Jun 9 00:09:37 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Sat Jun 9 00:09:41 2007 Subject: [sldev] There are a few files in the 1.16.0.5 src dist without Copyright text In-Reply-To: <46647DBA.4030505@ucsd.edu> References: <46647DBA.4030505@ucsd.edu> Message-ID: <20070609070937.GB21873@keitarou> On Mon, Jun 04, 2007 at 02:01:46PM -0700, Max Okumoto wrote: > Is there any interest in patches to add the missing Linden labs copyright? The list of files > follows: > linden/indra/llmessage/llmessagebuilder.h > linden/indra/llmessage/llmessagereader.cpp > linden/indra/llmessage/llmessagereader.h > linden/indra/llmessage/llmessagetemplate.cpp > linden/indra/llmessage/llmessagetemplate.h > linden/indra/llmessage/llmsgvariabletype.h > linden/indra/llmessage/llsdmessagebuilder.cpp > linden/indra/llmessage/llsdmessagebuilder.h > linden/indra/llmessage/llsdmessagereader.cpp > linden/indra/llmessage/llsdmessagereader.h > linden/indra/llmessage/lltemplatemessagebuilder.cpp > linden/indra/llmessage/lltemplatemessagebuilder.h > linden/indra/llmessage/lltemplatemessagereader.cpp > linden/indra/llmessage/lltemplatemessagereader.h > linden/indra/llrender/llvertexbuffer.cpp > linden/indra/llrender/llvertexbuffer.h > linden/indra/newview/llassetuploadresponders.cpp > linden/indra/newview/llassetuploadresponders.h > linden/indra/newview/llfloaterinspect.cpp > linden/indra/test/llsdtraits.h You of course meant to link to https://jira.secondlife.com/browse/VWR-679, right? Of course, from Rob's response I guess there's actually an internal issue being tracked for the same thing. ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070609/bf17b9af/attachment-0001.pgp From okumoto at ucsd.edu Sat Jun 9 01:01:23 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sat Jun 9 01:01:26 2007 Subject: [sldev] There are a few files in the 1.16.0.5 src dist without Copyright text In-Reply-To: <20070609070937.GB21873@keitarou> References: <46647DBA.4030505@ucsd.edu> <20070609070937.GB21873@keitarou> Message-ID: <466A5E53.5020607@ucsd.edu> Paul TBBle Hampson wrote: > On Mon, Jun 04, 2007 at 02:01:46PM -0700, Max Okumoto wrote: > >> Is there any interest in patches to add the missing Linden labs copyright? The list of files >> follows: >> [list of file deleted] > You of course meant to link to > https://jira.secondlife.com/browse/VWR-679, right? > > Of course, from Rob's response I guess there's actually an internal > issue being tracked for the same thing. > > ^_^ Yup, it should... I guess I need to look at more of the existing tickets. Max -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070609/96455918/attachment.htm From blakar at gmail.com Sat Jun 9 02:16:36 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jun 9 02:16:39 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <76kwms0nei5ds4ds4f84s0.alissa_sabre@yahoo.co.jp> References: <4669C2F5.3050604@blueflash.cc> <76kwms0nei5ds4ds4f84s0.alissa_sabre@yahoo.co.jp> Message-ID: <7992d0d60706090216v11a373dfwd4ca3af44412163e@mail.gmail.com> For those who got scared while reading all the stuff you needed to do to get it to build on VS2005 I updated the page, removed some clutter and replaced the most time consuming part of setting up the environment by a simple solution. It should now only take a few minutes to get thru all the steps. Nick, I've no idea what it could be. For me it builds fine (using 2005 Express). Mind redoing the steps? Where did you get the working VC8 files from? Personally I always do a clean conversion for each source tree. Dirk On 6/9/07, Alissa Sabre wrote: > NIck, > > > I'm currently trying to build a working set of VC8 project files, but am > > getting > ... abridged ... > > Does anybody know these or have a solution? > > I'm not sure this is the answer you want, but my solution to the > problem is always use VC7 solution and project files even on VS2005. > That means you need to convert VC7 files to VC8 files and adjust some > details of the project properties by hands everytime a new release is > distributed... > > Exact steps you need to follow is explained on the wiki: > > http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#Environment_Setup > > # I doubt you are asking different thing, Nick, because I don't think > you have not read the page... > -------------------------------------- > Start Yahoo! Auction now! Check out the cool campaign > http://pr.mail.yahoo.co.jp/auction/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nicholaz at blueflash.cc Sat Jun 9 02:39:12 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 9 02:39:20 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <76kwms0nei5ds4ds4f84s0.alissa_sabre@yahoo.co.jp> References: <4669C2F5.3050604@blueflash.cc> <76kwms0nei5ds4ds4f84s0.alissa_sabre@yahoo.co.jp> Message-ID: <466A7540.8040906@blueflash.cc> Alissa/Dirk, thanks for the suggestion ... but in fact retracing these steps was what I wanted to avoid :-) I don't need VS2005 and was just cleaning up the Wiki for VS2003 and tried to make the _vc8.vcproj files work. Turned out it took a lot longer than converting the stuff manually, but I really hate chores like this done manually and I'm hoping to build a set of _vc8.vcproj files and try to push them inside the release build, because ... well ... I better keep my mouth zipped in this particular area :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Alissa Sabre wrote: > NIck, > >> I'm currently trying to build a working set of VC8 project files, but am >> getting > ... abridged ... >> Does anybody know these or have a solution? > > I'm not sure this is the answer you want, but my solution to the > problem is always use VC7 solution and project files even on VS2005. > That means you need to convert VC7 files to VC8 files and adjust some > details of the project properties by hands everytime a new release is > distributed... > > Exact steps you need to follow is explained on the wiki: > > http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29#Environment_Setup > > # I doubt you are asking different thing, Nick, because I don't think > you have not read the page... > -------------------------------------- > Start Yahoo! Auction now! Check out the cool campaign > http://pr.mail.yahoo.co.jp/auction/ From nicholaz at blueflash.cc Sat Jun 9 07:59:39 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 9 07:59:54 2007 Subject: [sldev] VS8 Project Files Message-ID: <466AC05B.3050206@blueflash.cc> I think I succeeded in making a working set of VS8 sln and project files. As it appears, most of my problem came from a bug in VS2005 where the linker acted erratically because I had unloaded win_crash_logger and win_updater without taking them out of the newview dependencies. However, attached is a set of sln/vsprops/vcproj files which should be entirely independent of the VS2003 files. I.e. you should be able to unpack them onto the linden/indra tree, it will only overwrite the *_vc8.* files (and leave the 2003 solution files alone) and should work right out of the box if you open indra_complete_vc8.sln I'd be grateful if someone could test this with 1.16 and 1.17 (the files were made for 1.17.0.9). If it works out, I'll put them on JIRA for download and either they make their way into the Linden archive or we can link them there from the WIKI to make installation still easier. Btw, big thanks and kudos! to the guy who came up with the idea for using the vsprops file! Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: vs8proj.zip Type: application/x-zip-compressed Size: 46391 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070609/1d2f2e0d/vs8proj-0001.bin From alissa_sabre at yahoo.co.jp Sat Jun 9 08:27:10 2007 From: alissa_sabre at yahoo.co.jp (alissa_sabre@yahoo.co.jp) Date: Sat Jun 9 08:27:23 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <466A7540.8040906@blueflash.cc> References: <466A7540.8040906@blueflash.cc> Message-ID: <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> Nick, > in fact retracing these > steps was what I wanted to avoid :-) > just cleaning up the Wiki for VS2003 and tried to > make the _vc8.vcproj files work. Ok. I agree with you, but the problem is that Lindens never maintain *_vc8.vcproj files. A regident can create a working set of _vc8.vcproj and submit it to Linden Lab, but when the next release comes out, the release may contain new source files. Such addition is reflected into SConstruct, *.xcodeproj, and *.vcproj for VC71, but not in _vc8.vcproj files. The only thing to solve the issue is that someone in Linden Lab to update _vc8.vcproj files just befor the release of new source taballs. It only takes a few minutes, and all VS2005 developpers involved in Viewer Open Source will be happy. Unfortunately, Linden Lab. has no will to do so... That's why I committed myself to do the conversion work from VC7 to VC8 everytime. -------------------------------------- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ From cfk at pacbell.net Sat Jun 9 08:31:36 2007 From: cfk at pacbell.net (Charles Krinke) Date: Sat Jun 9 08:35:11 2007 Subject: [sldev] compiling the viewer Message-ID: <526814.39937.qm@web82612.mail.mud.yahoo.com> Dear Max: I was able to compile the 1.17.0.9 viewer in Linux thanks to your kind efforts. There were three minor issues which I am including here for reference. 1. Makefile uses "g++-3.4" and compat-gcc-34-c++ installs "g++34", so I added a softlink in my /usr/bin for this name. 2. Makefile uses /local/home/linden/distfiles and ./distfiles works better on a system without this hard-coded path. 3. The compilation needed the .supp file in the linden/indra/newview directory 4. both libtcmalloc.so.0 & libstacktrace.so.0 could not be found in the link stage and I put copies of both of them into the linden/libraries/i686-linux/lib_release_client directory. LD_LIBRARY_PATH did not seem to find these in /usr/lib Now, that I have a complete compile, this leads to a few other questions. a. Can we expect to run ddd/gdb on this binary and are there any nuances in getting this working in Linux? b. I see hints of a similar script/batch file notion for Cygwin on windows. Are there any hints for getting the Windows compile working with Cygwin? Again, thank you and I look forward to our next exchange. Charles p.s. As soon as possible, I also am anticipating working through Nicholas notes. Hi Charles, Since I'm using FC6 too so that should make it easier. I'm attaching the Makefile that I use to download and build the 1.17.0.9 binary that I am using. There are a few things missing, that they will fix in the next release of the tar files. But I will attach the missing on that rob posted today. As a normal user copy the Makefile into a directory, create a subdir called distfiles and copy the secondlife-i686.supp files into that. And if you have already downloaded the tar files from the second life site you can put them into the distfiles directory too. Then type: % script -f -c make build.log Then wait a long time depending on your system. :-) If the build works you will end up with a linden/indra/newview/SecondLife_i686_1_17_0_9.tar.bz2 file. Untar that file and run your new viewer. I have added some info to the wiki about google-perftools which contain both tcmalloc and stacktrace libraries. Max -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070609/ccc37a88/attachment.htm From nicholaz at blueflash.cc Sat Jun 9 08:58:02 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 9 08:58:11 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> References: <466A7540.8040906@blueflash.cc> <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> Message-ID: <466ACE0A.9050808@blueflash.cc> > The only thing to solve the issue is that someone in Linden Lab to > update _vc8.vcproj files just befor the release of new source > taballs. It only takes a few minutes, and all VS2005 developpers > involved in Viewer Open Source will be happy. > > Unfortunately, Linden Lab. has no will to do so... > > That's why I committed myself to do the conversion work from VC7 to > VC8 everytime. I guess (with regard to my post of the vc8 files) we can try to keep these updated (when they add new projects or files) and have them in a place for download. I think they might last a while and could be linked from the Wiki to the JIRA. That's why I was trying to make an independent set of files. Also that trick from the Wiki today with using a vcprops file will make things a lot easier. So, idea is to have a working set and one specific JIRA issue and once someone updates the files, they can upload them with the relevant version number. I'll also make stuff available to help with building those automatically. Nick From chance at kalacia.com Sat Jun 9 11:51:19 2007 From: chance at kalacia.com (Chance Unknown) Date: Sat Jun 9 11:51:21 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <466ACE0A.9050808@blueflash.cc> References: <466A7540.8040906@blueflash.cc> <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> <466ACE0A.9050808@blueflash.cc> Message-ID: <2925011a0706091151h265b561fm8abc0ac3be42bbdf@mail.gmail.com> ive had reasonable luck letting the tool doing a bunch of the conversion for me in the past when i open the files in vs express.. are there some tips can be fed off to the lindens that use the VC7 tools that make it easier for us to consistently import a project to a newer version of the tools with reasonable results? On 6/9/07, Nicholaz Beresford wrote: > > > > The only thing to solve the issue is that someone in Linden Lab to > > update _vc8.vcproj files just befor the release of new source > > taballs. It only takes a few minutes, and all VS2005 developpers > > involved in Viewer Open Source will be happy. > > > > Unfortunately, Linden Lab. has no will to do so... > > > > That's why I committed myself to do the conversion work from VC7 to > > VC8 everytime. > > I guess (with regard to my post of the vc8 files) we can try to > keep these updated (when they add new projects or files) and > have them in a place for download. I think they might last > a while and could be linked from the Wiki to the JIRA. > > That's why I was trying to make an independent set of files. > Also that trick from the Wiki today with using a vcprops file > will make things a lot easier. > > So, idea is to have a working set and one specific JIRA issue > and once someone updates the files, they can upload them with > the relevant version number. I'll also make stuff available > to help with building those automatically. > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070609/775a7d18/attachment.htm From nicholaz at blueflash.cc Sat Jun 9 12:20:09 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 9 12:20:23 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <2925011a0706091151h265b561fm8abc0ac3be42bbdf@mail.gmail.com> References: <466A7540.8040906@blueflash.cc> <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> <466ACE0A.9050808@blueflash.cc> <2925011a0706091151h265b561fm8abc0ac3be42bbdf@mail.gmail.com> Message-ID: <466AFD69.5070907@blueflash.cc> With the vcprops file it's actually pretty simple to convert (the instructions on the wiki were updated accordingly today by someone). But I still think since those vc8 files are already in the archive, building vc8 based on those may have the chance to get them into the source distribution and I guess the last one (had they worked) would have lasted three versions at least. And for guys like me who is using VS2003 and VS2005 having separate ones has a bit of extra benefit as well. But my reasoning is also to make the compilation easier for the average guy (or gal) by just giving them a project to open (the stuff around with the libs is still enough). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Chance Unknown wrote: > ive had reasonable luck letting the tool doing a bunch of the conversion > for me in the past when i open the files in vs express.. are there some > tips can be fed off to the lindens that use the VC7 tools that make it > easier for us to consistently import a project to a newer version of the > tools with reasonable results? > > > On 6/9/07, *Nicholaz Beresford* > wrote: > > > > The only thing to solve the issue is that someone in Linden Lab to > > update _vc8.vcproj files just befor the release of new source > > taballs. It only takes a few minutes, and all VS2005 developpers > > involved in Viewer Open Source will be happy. > > > > Unfortunately, Linden Lab. has no will to do so... > > > > That's why I committed myself to do the conversion work from VC7 to > > VC8 everytime. > > I guess (with regard to my post of the vc8 files) we can try to > keep these updated (when they add new projects or files) and > have them in a place for download. I think they might last > a while and could be linked from the Wiki to the JIRA. > > That's why I was trying to make an independent set of files. > Also that trick from the Wiki today with using a vcprops file > will make things a lot easier. > > So, idea is to have a working set and one specific JIRA issue > and once someone updates the files, they can upload them with > the relevant version number. I'll also make stuff available > to help with building those automatically. > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From nicholaz at blueflash.cc Sat Jun 9 12:21:35 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 9 12:21:46 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <2925011a0706091151h265b561fm8abc0ac3be42bbdf@mail.gmail.com> References: <466A7540.8040906@blueflash.cc> <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> <466ACE0A.9050808@blueflash.cc> <2925011a0706091151h265b561fm8abc0ac3be42bbdf@mail.gmail.com> Message-ID: <466AFDBF.2040400@blueflash.cc> Btw, speaking of making things easier. Is the development stuff (perl, cygwin, python) actually necessary to build a Windows exe? Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From tinacloud at gmx.de Sat Jun 9 12:58:26 2007 From: tinacloud at gmx.de (Zi Ree) Date: Sat Jun 9 12:58:31 2007 Subject: [sldev] Patch: About Land floater is not resizable, ban and access lists too small Message-ID: <200706092158.26944.tinacloud@gmx.de> Hi SL Developers! The About Land floater is not resizable and some of the most important controls (ban and access lists) are nearly unusable because of their small size and because they are not sorting properly. The attached patch fixes the UI issues as good as possible, the sorting issue probably comes from the caching of the avatar IDs, I'll try to fix that in the code later. https://jira.secondlife.com/browse/VWR-1140 On the Jira I've attached both a patch and a drop-in replacement for floater_about_land.xml for those who just want to see the improved floater without having to patch the old file. Please check the patch and tell me what you think. Zi! From jhurliman at wsu.edu Sat Jun 9 15:28:43 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Jun 9 15:27:35 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <466AFDBF.2040400@blueflash.cc> References: <466A7540.8040906@blueflash.cc> <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> <466ACE0A.9050808@blueflash.cc> <2925011a0706091151h265b561fm8abc0ac3be42bbdf@mail.gmail.com> <466AFDBF.2040400@blueflash.cc> Message-ID: <466B299B.9090405@wsu.edu> Nicholaz Beresford wrote: > > Btw, speaking of making things easier. Is the > development stuff (perl, cygwin, python) actually > necessary to build a Windows exe? > > > Nick > I have never needed any of that to compile SL on Windows. As long as you have the Windows SDK, DirectX SDK, boost binaries, and binaries for whatever optional (FMOD, Quicktime, Mozilla) stuff you want to install it should go fine. At one point I was looking in to removing the Windows and DirectX SDK dependencies but was pulled away for other things. John Hurliman From gwardell at gwsystems.co.il Sat Jun 9 16:45:18 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Sat Jun 9 16:45:28 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <466B299B.9090405@wsu.edu> Message-ID: <003601c7aaf0$3d0577f0$a4689943@gwsystems2.com> I also was wonding about that. The setup instructions from the wiki for 2005 say to put all of that stuff (perl, cygwin, python) on your system, but I was wondering why?, since those are usually used as scripting elements on websites. So, if it's not used in the build, what is it used for and do I really need it for something? Gary > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of John Hurliman > Sent: Sat, June 09, 2007 6:29 PM > To: sldev@lists.secondlife.com > Subject: Re: [sldev] Compiling under VS2005 > > > Nicholaz Beresford wrote: > > > > Btw, speaking of making things easier. Is the > > development stuff (perl, cygwin, python) actually > > necessary to build a Windows exe? > > > > > > Nick > > > > I have never needed any of that to compile SL on Windows. As > long as you > have the Windows SDK, DirectX SDK, boost binaries, and binaries for > whatever optional (FMOD, Quicktime, Mozilla) stuff you want > to install > it should go fine. At one point I was looking in to removing > the Windows > and DirectX SDK dependencies but was pulled away for other things. > > John Hurliman > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From blakar at gmail.com Sat Jun 9 17:20:23 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jun 9 17:20:26 2007 Subject: [sldev] VS8 Project Files In-Reply-To: <466AC05B.3050206@blueflash.cc> References: <466AC05B.3050206@blueflash.cc> Message-ID: <7992d0d60706091720o4648bee7u9f1b5d7e736be1cc@mail.gmail.com> On 6/9/07, Nicholaz Beresford wrote: > > > Btw, big thanks and kudos! to the guy who came up with the > idea for using the vsprops file! No problem ;-) I get fed up quite quickly by these boring editing chores so I always look for alternatives. At first I was planning to write perl scripts to do all the editing in the individual files but while investigating how it works I noticed it inherited stuff from a relative simple file so I played a bit with that and found a way to avoid all the fuss. Glad it has been picked up and improved upon immediately. Building with Express opens up the chance to play with the source for everyone as you don't need to spend any money on the tools. So it is important as it opens everything up. Dirk aka Blakar Ogre From jhurliman at wsu.edu Sat Jun 9 19:35:40 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Jun 9 19:34:21 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <003601c7aaf0$3d0577f0$a4689943@gwsystems2.com> References: <003601c7aaf0$3d0577f0$a4689943@gwsystems2.com> Message-ID: <466B637C.6060603@wsu.edu> If you are going to build every support library manually you will need all of those tools and probably more. If you are satisfied with using binaries of things like boost and whatever other support libraries are used then you don't need any of that to compile in Windows. SCons on UNIXy systems may be a different story however, I haven't taken a close look there. John Gary Wardell wrote: > I also was wonding about that. > > The setup instructions from the wiki for 2005 say to put all of that stuff (perl, cygwin, python) on your system, but I was > wondering why?, since those are usually used as scripting elements on websites. > > So, if it's not used in the build, what is it used for and do I really need it for something? > > Gary > > >> -----Original Message----- >> From: sldev-bounces@lists.secondlife.com >> [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of John Hurliman >> Sent: Sat, June 09, 2007 6:29 PM >> To: sldev@lists.secondlife.com >> Subject: Re: [sldev] Compiling under VS2005 >> >> >> Nicholaz Beresford wrote: >> >>> Btw, speaking of making things easier. Is the >>> development stuff (perl, cygwin, python) actually >>> necessary to build a Windows exe? >>> >>> >>> Nick >>> >>> >> I have never needed any of that to compile SL on Windows. As >> long as you >> have the Windows SDK, DirectX SDK, boost binaries, and binaries for >> whatever optional (FMOD, Quicktime, Mozilla) stuff you want >> to install >> it should go fine. At one point I was looking in to removing >> the Windows >> and DirectX SDK dependencies but was pulled away for other things. >> >> John Hurliman >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > > From nicholaz at blueflash.cc Sun Jun 10 03:31:59 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 10 03:32:15 2007 Subject: [sldev] VS8 Project Files In-Reply-To: <7992d0d60706091720o4648bee7u9f1b5d7e736be1cc@mail.gmail.com> References: <466AC05B.3050206@blueflash.cc> <7992d0d60706091720o4648bee7u9f1b5d7e736be1cc@mail.gmail.com> Message-ID: <466BD31F.4030701@blueflash.cc> > Building with Express opens up the chance to play with the source for > everyone as you don't need to spend any money on the tools. So it is > important as it opens everything up. That's why I'm dealing with it at the moment although I have VS2003. I think streamlining the process as far as possible may be a big help in making the project more attractive. I had stopped my first attempt at compiling when I saw how much stuff was needed and especially when I saw the part about the _CRT_XXXX macros. Nick From nicholaz at blueflash.cc Sun Jun 10 03:44:07 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 10 03:44:17 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <466B299B.9090405@wsu.edu> References: <466A7540.8040906@blueflash.cc> <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> <466ACE0A.9050808@blueflash.cc> <2925011a0706091151h265b561fm8abc0ac3be42bbdf@mail.gmail.com> <466AFDBF.2040400@blueflash.cc> <466B299B.9090405@wsu.edu> Message-ID: <466BD5F7.5080202@blueflash.cc> It appears the .vcproj files reference c:\cygwin\bin\flex c:\cygwin\bin\bison c:\cygwin\bin\mv (this may be new in 1.17 and could be changed to a Windows copy or move). so at least Cygwin seems to be required. But I can't see reference to the rest. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ John Hurliman wrote: > Nicholaz Beresford wrote: >> >> Btw, speaking of making things easier. Is the >> development stuff (perl, cygwin, python) actually >> necessary to build a Windows exe? >> >> >> Nick >> > > I have never needed any of that to compile SL on Windows. As long as you > have the Windows SDK, DirectX SDK, boost binaries, and binaries for > whatever optional (FMOD, Quicktime, Mozilla) stuff you want to install > it should go fine. At one point I was looking in to removing the Windows > and DirectX SDK dependencies but was pulled away for other things. > > John Hurliman > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From okumoto at ucsd.edu Sun Jun 10 04:53:53 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sun Jun 10 04:53:57 2007 Subject: [sldev] compiling the viewer In-Reply-To: <526814.39937.qm@web82612.mail.mud.yahoo.com> References: <526814.39937.qm@web82612.mail.mud.yahoo.com> Message-ID: <466BE651.2050700@ucsd.edu> Skipped content of type multipart/alternative-------------- next part -------------- # # @author Max Okumoto # # Makefile use to down load and build SecondLife binary from source files # from website on Fedora Core 6. # # If SVN_REV is set then use SVN instead of the slviewer-src-${SL_VER}.tar.gz # #SVN_REV = http://svn.secondlife.com/svn/linden/release BUILD = releasefordownload DISTFILES = distfiles SL_YEAR = 2007 SL_MONTH = 06 SL_DAY = 02 SL_TYPE = a SL_VER = ${SL_YEAR}${SL_MONTH}${SL_DAY}${SL_TYPE} SL_VER = 1-17-0-9 SL_FOO = SL_URL_PREFIX = http://secondlife.com/developers/opensource/downloads/${SL_YEAR}/${SL_MONTH} SL_SRC_TAR = slviewer-src-${SL_FOO}${SL_VER}.tar.gz SL_ART_ZIP = slviewer-artwork-${SL_FOO}${SL_VER}.zip SL_LIB_TAR = slviewer-linux-libs-${SL_FOO}${SL_VER}.tar.gz FMOD_MAJ = 3 FMOD_MIN = 75 FMOD_VER = fmodapi${FMOD_MAJ}${FMOD_MIN}linux FMOD_URL_PREFIX = http://www.fmod.org/files FMOD_SRC_TAR = ${FMOD_VER}.tar.gz ############################################################################## # ############################################################################## all: unpack update replace build ############################################################################## # Get stuff ############################################################################## get: ${DISTFILES}/${SL_SRC_TAR} get: ${DISTFILES}/${SL_ART_ZIP} get: ${DISTFILES}/${SL_LIB_TAR} ${DISTFILES}/${SL_LIB_TAR}: (cd ${DISTFILES}; wget ${SL_URL_PREFIX}/${SL_LIB_TAR}) ${DISTFILES}/${SL_SRC_TAR}: (cd ${DISTFILES}; wget ${SL_URL_PREFIX}/${SL_SRC_TAR}) ${DISTFILES}/${SL_ART_ZIP}: (cd ${DISTFILES}; wget ${SL_URL_PREFIX}/${SL_ART_ZIP}) ${DISTFILES}/${FMOD_SRC_TAR}: (cd ${DISTFILES}; wget ${FMOD_URL_PREFIX}/${FMOD_SRC_TAR}) ############################################################################## # Unpack stuff ############################################################################## unpack: linden/LICENSE-source.txt unpack: linden/LICENSE-logos.txt unpack: linden/LICENSE-libraries-linux.txt unpack: linden/libraries/i686-linux/lib_release_client/libfmod-${FMOD_MAJ}.${FMOD_MIN}.so unpack: linden/indra/newview/secondlife-i686.supp linden/LICENSE-logos.txt: ${DISTFILES}/${SL_ART_ZIP} @echo 'Unpack slviewer artwork' @unzip -q ${DISTFILES}/${SL_ART_ZIP} @touch linden/LICENSE-logos.txt linden/LICENSE-libraries-linux.txt: ${DISTFILES}/${SL_LIB_TAR} @echo 'Unpack slviewer libraries' @tar xf ${DISTFILES}/${SL_LIB_TAR} @touch linden/LICENSE-libraries-linux.txt linden/LICENSE-source.txt: ${DISTFILES}/${SL_SRC_TAR} @if [ -n "${SVN_REV}" ]; then \ echo 'Download slviewer src using SVN'; \ svn co -q ${SVN_REV} linden; \ else \ echo 'Unpack slviewer src'; \ tar xf ${DISTFILES}/${SL_SRC_TAR}; \ fi @touch linden/LICENSE-source.txt linden/libraries/i686-linux/lib_release_client/libfmod-${FMOD_MAJ}.${FMOD_MIN}.so: ${DISTFILES}/${FMOD_SRC_TAR} @echo 'Unpack FMOD library' @tar xf ${DISTFILES}/${FMOD_SRC_TAR} @(cd ${FMOD_VER}/api/inc; tar cf - .) |\ (cd linden/libraries/i686-linux/include; tar xf -) @(cd ${FMOD_VER}/api; tar -cf - libfmod-${FMOD_MAJ}.${FMOD_MIN}.so) |\ (cd linden/libraries/i686-linux/lib_release_client/; tar xf -) @rm -rf ${FMOD_VER} @touch linden/libraries/i686-linux/lib_release_client/libfmod-${FMOD_MAJ}.${FMOD_MIN}.so linden/indra/newview/secondlife-i686.supp: ${DISTFILES}/secondlife-i686.supp cp ${DISTFILES}/secondlife-i686.supp: linden/indra/newview/secondlife-i686.supp ############################################################################## # Update stuff ############################################################################## update: @if [ -f linden/.svn/entries ]; then \ echo "Update slviewer using SVN"; \ (cd linden; svn update); \ fi ############################################################################## # Replase stuff ############################################################################## replace: linden/indra/newview/libllkdu.so replace: linden/indra/lib/libkdu_v42R.so replace: linden/indra/newview/viewer_manifest.py.fixed replace: linden/indra/SConstruct.fixed linden/indra/newview/libllkdu.so: cp linden/libraries/i686-linux/lib_release_client/libllkdu.so \ linden/indra/newview/libllkdu.so linden/indra/lib/libkdu_v42R.so: cp linden/libraries/i686-linux/lib_release_client/libkdu_v42R.so \ linden/indra/lib/libkdu_v42R.so linden/indra/SConstruct.fixed: linden/indra/SConstruct Makefile # # compat-gcc-34 install as gcc34 # compate-gcc-34-c++ install as g++34 # sed \ -e "s/gcc_bin = 'g++-3.4'/gcc_bin = 'g++34'/" \ linden/indra/SConstruct > linden/indra/SConstruct.fixed cp linden/indra/SConstruct.fixed linden/indra/SConstruct linden/indra/newview/viewer_manifest.py.fixed: linden/indra/newview/viewer_manifest.py Makefile # # Enable faster jpg decode libraries. # sed \ -e '/^#.*libllkdu\.so/s/^#//' \ -e '/^#.*libkdu_v42R\.so/s/^#//' \ linden/indra/newview/viewer_manifest.py > linden/indra/newview/viewer_manifest.py.fixed cp linden/indra/newview/viewer_manifest.py.fixed linden/indra/newview/viewer_manifest.py # # Don't package up google-profiling stuff (this can be removed when # Linden Labs adds these libaries to the tar file. # sed \ -e '/^ *self.path("libtcmalloc\.so/s/^/#/' \ -e '/^ *self.path("libstacktrace\.so/s/^/#/' \ linden/indra/newview/viewer_manifest.py > linden/indra/newview/viewer_manifest.py.fixed cp linden/indra/newview/viewer_manifest.py.fixed linden/indra/newview/viewer_manifest.py ############################################################################## # Build stuff ############################################################################## build: @date (cd linden/indra; scons DISTCC=no BTARGET=client MOZLIB=no BUILD=${BUILD}) @date build-no-fmod: @date (cd linden/indra; scons FMOD=no DISTCC=no BTARGET=client MOZLIB=no BUILD=${BUILD}) @date ############################################################################## # Install stuff ############################################################################## install: #bzcat linden/indra/newview/SecondLife_i686_1_16_0_5.tar.bz2 | (cd /opt; tar xf -) bzcat linden/indra/newview/SecondLife_i686_1_17_0_9.tar.bz2 | (cd /opt; tar xf -) ############################################################################## # Clean stuff ############################################################################## clean: rm -rf linden ############################################################################## # Utilities ############################################################################## tags: find linden -type f -name '*.cpp' -exec ctags -e --append {} \; From okumoto at ucsd.edu Sun Jun 10 04:59:57 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sun Jun 10 05:00:01 2007 Subject: [sldev] compiling the viewer In-Reply-To: <466BE651.2050700@ucsd.edu> References: <526814.39937.qm@web82612.mail.mud.yahoo.com> <466BE651.2050700@ucsd.edu> Message-ID: <466BE7BD.8010907@ucsd.edu> Oops! There was an typo in the Makefile. Here is a replacement. Max Okumoto wrote: > Cool. I'm glad that I could be of help. Here is a new Makefile that > fixes the problems that you ran into: > > 1. It modifies linden/indra/SConstruct to use g++34 instead of g++-3.4 > 2. Fixed hard coded path. > 3. Added target to install secondlife-i686.supp file into correct location > 4. Fixed target for linden/indra/newview/viewer_manifest.py to not > package up missing libraries. > > The default binary installed is striped but the one you will find in > linden/indra/newview/secondlife-i686-bin > is not, so you should use that one with your debugger. I haven't used > the debugger with the binary yet so I > can't give you any advice on that yet. > > Don't have a windows box that I can develop on so can't help you > there, but it looks other people can help you there. > > Max -------------- next part -------------- # # @author Max Okumoto # # Makefile use to down load and build SecondLife binary from source files # from website on Fedora Core 6. # # If SVN_REV is set then use SVN instead of the slviewer-src-${SL_VER}.tar.gz # #SVN_REV = http://svn.secondlife.com/svn/linden/release BUILD = releasefordownload DISTFILES = distfiles SL_YEAR = 2007 SL_MONTH = 06 SL_DAY = 02 SL_TYPE = a SL_VER = ${SL_YEAR}${SL_MONTH}${SL_DAY}${SL_TYPE} SL_VER = 1-17-0-9 SL_FOO = SL_URL_PREFIX = http://secondlife.com/developers/opensource/downloads/${SL_YEAR}/${SL_MONTH} SL_SRC_TAR = slviewer-src-${SL_FOO}${SL_VER}.tar.gz SL_ART_ZIP = slviewer-artwork-${SL_FOO}${SL_VER}.zip SL_LIB_TAR = slviewer-linux-libs-${SL_FOO}${SL_VER}.tar.gz FMOD_MAJ = 3 FMOD_MIN = 75 FMOD_VER = fmodapi${FMOD_MAJ}${FMOD_MIN}linux FMOD_URL_PREFIX = http://www.fmod.org/files FMOD_SRC_TAR = ${FMOD_VER}.tar.gz ############################################################################## # ############################################################################## all: unpack update replace build ############################################################################## # Get stuff ############################################################################## get: ${DISTFILES}/${SL_SRC_TAR} get: ${DISTFILES}/${SL_ART_ZIP} get: ${DISTFILES}/${SL_LIB_TAR} ${DISTFILES}/${SL_LIB_TAR}: (cd ${DISTFILES}; wget ${SL_URL_PREFIX}/${SL_LIB_TAR}) ${DISTFILES}/${SL_SRC_TAR}: (cd ${DISTFILES}; wget ${SL_URL_PREFIX}/${SL_SRC_TAR}) ${DISTFILES}/${SL_ART_ZIP}: (cd ${DISTFILES}; wget ${SL_URL_PREFIX}/${SL_ART_ZIP}) ${DISTFILES}/${FMOD_SRC_TAR}: (cd ${DISTFILES}; wget ${FMOD_URL_PREFIX}/${FMOD_SRC_TAR}) ############################################################################## # Unpack stuff ############################################################################## unpack: linden/LICENSE-source.txt unpack: linden/LICENSE-logos.txt unpack: linden/LICENSE-libraries-linux.txt unpack: linden/libraries/i686-linux/lib_release_client/libfmod-${FMOD_MAJ}.${FMOD_MIN}.so unpack: linden/indra/newview/secondlife-i686.supp linden/LICENSE-logos.txt: ${DISTFILES}/${SL_ART_ZIP} @echo 'Unpack slviewer artwork' @unzip -q ${DISTFILES}/${SL_ART_ZIP} @touch linden/LICENSE-logos.txt linden/LICENSE-libraries-linux.txt: ${DISTFILES}/${SL_LIB_TAR} @echo 'Unpack slviewer libraries' @tar xf ${DISTFILES}/${SL_LIB_TAR} @touch linden/LICENSE-libraries-linux.txt linden/LICENSE-source.txt: ${DISTFILES}/${SL_SRC_TAR} @if [ -n "${SVN_REV}" ]; then \ echo 'Download slviewer src using SVN'; \ svn co -q ${SVN_REV} linden; \ else \ echo 'Unpack slviewer src'; \ tar xf ${DISTFILES}/${SL_SRC_TAR}; \ fi @touch linden/LICENSE-source.txt linden/libraries/i686-linux/lib_release_client/libfmod-${FMOD_MAJ}.${FMOD_MIN}.so: ${DISTFILES}/${FMOD_SRC_TAR} @echo 'Unpack FMOD library' @tar xf ${DISTFILES}/${FMOD_SRC_TAR} @(cd ${FMOD_VER}/api/inc; tar cf - .) |\ (cd linden/libraries/i686-linux/include; tar xf -) @(cd ${FMOD_VER}/api; tar -cf - libfmod-${FMOD_MAJ}.${FMOD_MIN}.so) |\ (cd linden/libraries/i686-linux/lib_release_client/; tar xf -) @rm -rf ${FMOD_VER} @touch linden/libraries/i686-linux/lib_release_client/libfmod-${FMOD_MAJ}.${FMOD_MIN}.so linden/indra/newview/secondlife-i686.supp: ${DISTFILES}/secondlife-i686.supp cp ${DISTFILES}/secondlife-i686.supp linden/indra/newview/secondlife-i686.supp ############################################################################## # Update stuff ############################################################################## update: @if [ -f linden/.svn/entries ]; then \ echo "Update slviewer using SVN"; \ (cd linden; svn update); \ fi ############################################################################## # Replase stuff ############################################################################## replace: linden/indra/newview/libllkdu.so replace: linden/indra/lib/libkdu_v42R.so replace: linden/indra/newview/viewer_manifest.py.fixed replace: linden/indra/SConstruct.fixed linden/indra/newview/libllkdu.so: cp linden/libraries/i686-linux/lib_release_client/libllkdu.so \ linden/indra/newview/libllkdu.so linden/indra/lib/libkdu_v42R.so: cp linden/libraries/i686-linux/lib_release_client/libkdu_v42R.so \ linden/indra/lib/libkdu_v42R.so linden/indra/SConstruct.fixed: linden/indra/SConstruct Makefile # # compat-gcc-34 install as gcc34 # compate-gcc-34-c++ install as g++34 # sed \ -e "s/gcc_bin = 'g++-3.4'/gcc_bin = 'g++34'/" \ linden/indra/SConstruct > linden/indra/SConstruct.fixed cp linden/indra/SConstruct.fixed linden/indra/SConstruct linden/indra/newview/viewer_manifest.py.fixed: linden/indra/newview/viewer_manifest.py Makefile # # Enable faster jpg decode libraries. # sed \ -e '/^#.*libllkdu\.so/s/^#//' \ -e '/^#.*libkdu_v42R\.so/s/^#//' \ linden/indra/newview/viewer_manifest.py > linden/indra/newview/viewer_manifest.py.fixed cp linden/indra/newview/viewer_manifest.py.fixed linden/indra/newview/viewer_manifest.py # # Don't package up google-profiling stuff (this can be removed when # Linden Labs adds these libaries to the tar file. # sed \ -e '/^ *self.path("libtcmalloc\.so/s/^/#/' \ -e '/^ *self.path("libstacktrace\.so/s/^/#/' \ linden/indra/newview/viewer_manifest.py > linden/indra/newview/viewer_manifest.py.fixed cp linden/indra/newview/viewer_manifest.py.fixed linden/indra/newview/viewer_manifest.py ############################################################################## # Build stuff ############################################################################## build: @date (cd linden/indra; scons DISTCC=no BTARGET=client MOZLIB=no BUILD=${BUILD}) @date build-no-fmod: @date (cd linden/indra; scons FMOD=no DISTCC=no BTARGET=client MOZLIB=no BUILD=${BUILD}) @date ############################################################################## # Install stuff ############################################################################## install: #bzcat linden/indra/newview/SecondLife_i686_1_16_0_5.tar.bz2 | (cd /opt; tar xf -) bzcat linden/indra/newview/SecondLife_i686_1_17_0_9.tar.bz2 | (cd /opt; tar xf -) ############################################################################## # Clean stuff ############################################################################## clean: rm -rf linden rm -rf /tmp/linden ############################################################################## # Utilities ############################################################################## tags: find linden -type f -name '*.cpp' -exec ctags -e --append {} \; From nicholaz at blueflash.cc Sun Jun 10 06:46:28 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 10 06:46:44 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <466BD5F7.5080202@blueflash.cc> References: <466A7540.8040906@blueflash.cc> <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> <466ACE0A.9050808@blueflash.cc> <2925011a0706091151h265b561fm8abc0ac3be42bbdf@mail.gmail.com> <466AFDBF.2040400@blueflash.cc> <466B299B.9090405@wsu.edu> <466BD5F7.5080202@blueflash.cc> Message-ID: <466C00B4.80803@blueflash.cc> I have uploaded my set of project/solution files for VS2005 to the JIRA as https://jira.secondlife.com/browse/VWR-1151 and updated https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MSVS2005%29 accordingly. Please check/reivew/comment. Thanks! Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From chance at kalacia.com Sun Jun 10 07:16:03 2007 From: chance at kalacia.com (Chance Unknown) Date: Sun Jun 10 07:16:05 2007 Subject: [sldev] Fwd: [rt.lindenlab.com #883538] Request Received: Support is Down In-Reply-To: References: Message-ID: <2925011a0706100716pb83cae3i2151d3d03370ab06@mail.gmail.com> also the vendor parature.com that runs the trouble tickets is down too. does anyone have suggestions? ---------- Forwarded message ---------- From: Our support system has changed. via RT Date: Jun 10, 2007 6:13 AM Subject: [rt.lindenlab.com #883538] Request Received: Support is Down To: chance@kalacia.com Thank you for contacting Linden Lab, the makers of Second Life. Our support system has changed and we have discontinued the use of this email address. To find information on your issue and to contact support, please visit http://secondlife.com/support . Please note, information sent to this email address will not be read or responded to. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070610/c33a2793/attachment.htm From chance at kalacia.com Sun Jun 10 07:17:41 2007 From: chance at kalacia.com (Chance Unknown) Date: Sun Jun 10 07:17:43 2007 Subject: [sldev] Fwd: [rt.lindenlab.com #883538] Request Received: Support is Down In-Reply-To: <2925011a0706100716pb83cae3i2151d3d03370ab06@mail.gmail.com> References: <2925011a0706100716pb83cae3i2151d3d03370ab06@mail.gmail.com> Message-ID: <2925011a0706100717s55cb82ffga87edcb7e1d9eb65@mail.gmail.com> support.secondlife.com reporting : when did they outsource btw? Parature is committed to providing our customers with quality service and solutions. To satisfy this commitment to our valued customers, scheduled maintenance is a necessary occurrence. *A system maintenance will occur on June 9th through June 10th between the hours of 09:00 PM EDT and 11:00 AM EDT.* Parature realizes how important your support solution is to your business, and we appreciate your patience during this time. Thank you for the opportunity to provide you with a support solution that meets your customer service needs. *-The Parature Team* www.parature.com ---------- Forwarded message ---------- From: Chance Unknown Date: Jun 10, 2007 7:16 AM Subject: Fwd: [rt.lindenlab.com #883538] Request Received: Support is Down To: sldev@lists.secondlife.com also the vendor parature.com that runs the trouble tickets is down too. does anyone have suggestions? ---------- Forwarded message ---------- From: Our support system has changed. via RT Date: Jun 10, 2007 6:13 AM Subject: [rt.lindenlab.com #883538] Request Received: Support is Down To: chance@kalacia.com Thank you for contacting Linden Lab, the makers of Second Life. Our support system has changed and we have discontinued the use of this email address. To find information on your issue and to contact support, please visit http://secondlife.com/support . Please note, information sent to this email address will not be read or responded to. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070610/a8a49997/attachment.htm From sllists at boroon.dasgupta.ch Sun Jun 10 07:31:06 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun Jun 10 07:31:32 2007 Subject: [sldev] Fwd: [rt.lindenlab.com #883538] Request Received: Support is Down In-Reply-To: <2925011a0706100716pb83cae3i2151d3d03370ab06@mail.gmail.com> References: <2925011a0706100716pb83cae3i2151d3d03370ab06@mail.gmail.com> Message-ID: <42107.83.180.83.164.1181485866.squirrel@datendelphin.net> > does anyone have suggestions? Wait until it's over? I know it's not optimal but it's what I do. (Being locked out due to MISC-264) > when did they outsource btw? That was when they changed to the new Support Portal. Only the portal software (and perhaps its hosting servers?) seem to be outsourced, tickets are still handled by Linden people, as far as I know. Boroondas From cfk at pacbell.net Sun Jun 10 10:03:53 2007 From: cfk at pacbell.net (Charles Krinke) Date: Sun Jun 10 10:04:46 2007 Subject: [sldev] getting a log file Message-ID: <966447.61898.qm@web82606.mail.mud.yahoo.com> This is actually a Windows 1.16.0.5 viewer question, but I suspect applies to all Windows viewer versions. There are a few command line arguments to the viewer and one of them is -log. I need to see a logfile from unsuccessful viewer logins and dont seem to be able to create one in the cwd (current working directory). This is what I am currently doing. c:> cd Program Files c:> cd SecondLife c:> SecondLife.exe -log logfile1.log At this point, I would expect to see a "logfile1.log" in the cwd, but there isnt. Is it perhaps written somewhere else, or have I got the incantation wrong? Charles -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070610/66437443/attachment.htm From nicholaz at blueflash.cc Sun Jun 10 10:16:39 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 10 10:16:56 2007 Subject: [sldev] getting a log file In-Reply-To: <966447.61898.qm@web82606.mail.mud.yahoo.com> References: <966447.61898.qm@web82606.mail.mud.yahoo.com> Message-ID: <466C31F7.6010306@blueflash.cc> I have not used that, but it might be created in documents & settings, user, application data (hidden folder) somewhere together with the settings and crash dumps. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Charles Krinke wrote: > This is actually a Windows 1.16.0.5 viewer question, but I suspect > applies to all Windows viewer versions. > > > > There are a few command line arguments to the viewer and one of them is > -log. I need to see a logfile from unsuccessful viewer logins and dont > seem to be able to create one in the cwd (current working directory). > This is what I am currently doing. > > > > c:> cd Program Files > > c:> cd SecondLife > > c:> SecondLife.exe -log logfile1.log > > > > At this point, I would expect to see a "logfile1.log" in the cwd, but > there isnt. Is it perhaps written somewhere else, or have I got the > incantation wrong? > > > > Charles > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From sllists at boroon.dasgupta.ch Sun Jun 10 10:36:07 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun Jun 10 10:36:34 2007 Subject: [sldev] compiling the viewer Message-ID: <38087.83.180.83.164.1181496967.squirrel@datendelphin.net> Thank you for the Makefile. Can we put this somewhere on the wiki? Here's a version that checks for both, g++34 and g++-3.4. (If there's a better/cleaner/more standard way to do the same, please let me know.) So it should run on most other systems, too. Boroondas -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 6883 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070610/d389aba4/Makefile.obj From kamilion at gmail.com Sun Jun 10 22:53:26 2007 From: kamilion at gmail.com (Kamilion) Date: Sun Jun 10 22:53:29 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems Message-ID: I'm having some problems with objects and receiving email from outside of the secondlife.com domain -- They seem to be failing without an error or bounce message, and the object never appears to receive the email. I was hoping someone could look into this or point someone who can at it. I submitted a ticket in the new support system, TicketID 4051-4201708. Synopsis: Object Sending Email (Working) Object Receiving Email from another Object (Working) Object Receiving Email from Google Apps for your Domain hosted system: (sllabs.com) (NOT WORKING) Object Receiving Email from Google Mail (gmail.com) (NOT WORKING) More information follows, including scripts used and messages inline. SENDER Script: (WORKS) string address; string subject = "Test!"; string message = "This is a test message."; default { state_entry() { llSay(0, "Email Test Unit. Touch me to Send Demo Email."); } touch_start(integer total_number) { address = (string)llGetKey() + "@lsl.secondlife.com"; llEmail(address, subject, message); // Send email to self. } } RECEIVER Script: (Works) default { state_entry() { llSay(0, (string)llGetKey() + "@lsl.secondlife.com"); // List my Address llSetTimerEvent(2.5); // Poll for emails. (Yes, that is a retarded way on an event-based system!) } timer() { llGetNextEmail("", ""); // Check for email with any sender address and subject. } touch_start(integer total_number) { //llSetTimerEvent(2.5); } email(string time, string address, string subj, string message, integer num_left) { llSay(0, "You got mail! " + (string)num_left + " more mails."); llSay(0, "\n" + llList2CSV([time, address, subj, message])); if (num_left == 0) { //llSetTimerEvent(0.0); // Stop timer when there's no more email. llSay(0, "No more mail!"); } } } RESULT: (WORKS) [21:35] Object: You got mail! 0 more mails. [21:35] Object: 1181536529, 513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com, Test!, Object-Name: Object Region: Gyeongju (263936, 232192) Local-Position: (78, 8, 601) This is a test message. [21:35] Object: No more mail! [21:36] Object: Email Test Unit. Touch me to Send Demo Email. [21:37] Object: 513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com TRY Google Apps for your Domain hosted Email: (FAIL, NO DELIVERY) SENDER Script: (Works) string address; string subject = "Test!"; string message = "This is a test message."; default { state_entry() { llSay(0, "Email Test Unit. Touch me to Send Demo Email."); } touch_start(integer total_number) { address = "phpsmtp@sllabs.com"; llEmail(address, subject, message); // Send email to self. } } RESULT: (Works) Delivered-To: phpsmtp@sllabs.com Received: by 10.65.43.6 with SMTP id v6cs110378qbj; Sun, 10 Jun 2007 21:36:16 -0700 (PDT) Received: by 10.114.78.1 with SMTP id a1mr5115599wab.1181536576719; Sun, 10 Jun 2007 21:36:16 -0700 (PDT) Return-Path: <513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com> Received: from sim324.agni.lindenlab.com (sim324.agni.lindenlab.com [69.25.104.10]) by mx.google.com with ESMTP id j21si7195806wah.2007.06.10.21.36.16; Sun, 10 Jun 2007 21:36:16 -0700 (PDT) Received-SPF: neutral (google.com: 69.25.104.10 is neither permitted nor denied by best guess record for domain of 513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com) Received: from lindenlab.com (localhost [127.0.0.1]) by sim324.agni.lindenlab.com (Postfix) with SMTP id 8CD0F5DC01F for ; Sun, 10 Jun 2007 21:36:15 -0700 (PDT) From: "Object" <513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com> To: Subject: Test! Message-Id: <20070611043615.8CD0F5DC01F@sim324.agni.lindenlab.com> Date: Sun, 10 Jun 2007 21:36:15 -0700 (PDT) Object-Name: Object Region: Gyeongju (263936, 232192) Local-Position: (78, 8, 601) This is a test message. TRY REPLY: (DOES NOT WORK) Received: by 10.65.43.6 with HTTP; Sun, 10 Jun 2007 21:36:42 -0700 (PDT) Message-ID: <7da7ad240706102136n75ef386ag2f98228e3b569939@mail.gmail.com> Date: Sun, 10 Jun 2007 21:36:42 -0700 From: "SLLabs Domain" To: Object <513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com> Subject: Re: Test! In-Reply-To: <20070611043615.8CD0F5DC01F@sim324.agni.lindenlab.com> Delivered-To: phpsmtp@sllabs.com TESTING REPLY And again from a real GMAIL account directly: (DOES NOT WORK) Received: by 10.100.165.16 with HTTP; Sun, 10 Jun 2007 21:44:10 -0700 (PDT) Message-ID: Date: Sun, 10 Jun 2007 21:44:10 -0700 From: Kamilion To: 513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com Subject: Testing MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Delivered-To: kamilion@gmail.com HEEEELLLLOOOOOOOOOO No response from the receiver. WTF? From labrat.hb at gmail.com Sun Jun 10 23:31:16 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Sun Jun 10 23:31:19 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: References: Message-ID: Welcome to the hell of trying to use external -> internal E-Mail with SL. For a nice history of the reliability of external -> internal E-Mail from May 2 -> current date, you can view my test log at this URL: http://www.rpgstats.com/SL/maillog.txt If you would like to review the history from February8 -> May2 it is available here: http://www.rpgstats.com/SL/maillog1.txt As of the time I'm replying there seems to be about 4 hour delay in e-mail processing for SL... There have been delays up to around 24 hours. For those interested in how the test works. I have an LSL script running on my sim that once every 30 minutes requests a PHP script on my webserver to send an e-mail. The PHP script generates a random string for the subject and logs the time that it sends to the maillog.txt file. The LSL script checks every 5 seconds for a new E-Mail, and upon receiving one it tells the PHP script on the server that it recieved an E-Mail and what the subject was. The PHP script then logs this information as well. On 6/10/07, Kamilion wrote: > > I'm having some problems with objects and receiving email from outside > of the secondlife.com domain -- They seem to be failing without an > error or bounce message, and the object never appears to receive the > email. I was hoping someone could look into this or point someone who > can at it. I submitted a ticket in the new support system, TicketID > 4051-4201708. > > Synopsis: > Object Sending Email (Working) > Object Receiving Email from another Object (Working) > Object Receiving Email from Google Apps for your Domain hosted system: > (sllabs.com) (NOT WORKING) > Object Receiving Email from Google Mail (gmail.com) (NOT WORKING) > > > More information follows, including scripts used and messages inline. > > SENDER Script: (WORKS) > > string address; > string subject = "Test!"; > string message = "This is a test message."; > > default > { > state_entry() > { > llSay(0, "Email Test Unit. Touch me to Send Demo Email."); > } > > touch_start(integer total_number) > { > address = (string)llGetKey() + "@lsl.secondlife.com"; > llEmail(address, subject, message); // Send email to self. > } > } > > RECEIVER Script: (Works) > > default { > state_entry() { > llSay(0, (string)llGetKey() + "@lsl.secondlife.com"); // List my > Address > > llSetTimerEvent(2.5); // Poll for emails. (Yes, that is a > retarded way on an event-based system!) > } > > timer() { > llGetNextEmail("", ""); // Check for email with any sender > address and subject. > } > > touch_start(integer total_number) > { > //llSetTimerEvent(2.5); > } > email(string time, string address, string subj, string message, > integer num_left) { > llSay(0, "You got mail! " + (string)num_left + " more mails."); > llSay(0, "\n" + llList2CSV([time, address, subj, message])); > if (num_left == 0) { > //llSetTimerEvent(0.0); // Stop timer when there's no more > email. > llSay(0, "No more mail!"); > } > } > } > > RESULT: (WORKS) > [21:35] Object: You got mail! 0 more mails. > [21:35] Object: > 1181536529, 513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com, > Test!, Object-Name: Object > Region: Gyeongju (263936, 232192) > Local-Position: (78, 8, 601) > > This is a test message. > [21:35] Object: No more mail! > [21:36] Object: Email Test Unit. Touch me to Send Demo Email. > [21:37] Object: 513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com > > > > > > > TRY Google Apps for your Domain hosted Email: (FAIL, NO DELIVERY) > > SENDER Script: (Works) > > string address; > string subject = "Test!"; > string message = "This is a test message."; > > default > { > state_entry() > { > llSay(0, "Email Test Unit. Touch me to Send Demo Email."); > } > > touch_start(integer total_number) > { > address = "phpsmtp@sllabs.com"; > llEmail(address, subject, message); // Send email to self. > } > } > > > RESULT: (Works) > > Delivered-To: phpsmtp@sllabs.com > Received: by 10.65.43.6 with SMTP id v6cs110378qbj; > Sun, 10 Jun 2007 21:36:16 -0700 (PDT) > Received: by 10.114.78.1 with SMTP id a1mr5115599wab.1181536576719; > Sun, 10 Jun 2007 21:36:16 -0700 (PDT) > Return-Path: <513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com> > Received: from sim324.agni.lindenlab.com (sim324.agni.lindenlab.com > [69.25.104.10]) > by mx.google.com with ESMTP id j21si7195806wah.2007.06.10.21.36.16; > Sun, 10 Jun 2007 21:36:16 -0700 (PDT) > Received-SPF: neutral (google.com: 69.25.104.10 is neither permitted > nor denied by best guess record for domain of > 513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com) > Received: from lindenlab.com (localhost [127.0.0.1]) > by sim324.agni.lindenlab.com (Postfix) with SMTP id 8CD0F5DC01F > for ; Sun, 10 Jun 2007 21:36:15 -0700 (PDT) > From: "Object" <513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com> > To: > Subject: Test! > Message-Id: <20070611043615.8CD0F5DC01F@sim324.agni.lindenlab.com> > Date: Sun, 10 Jun 2007 21:36:15 -0700 (PDT) > > Object-Name: Object > Region: Gyeongju (263936, 232192) > Local-Position: (78, 8, 601) > > This is a test message. > > > TRY REPLY: (DOES NOT WORK) > > Received: by 10.65.43.6 with HTTP; Sun, 10 Jun 2007 21:36:42 -0700 (PDT) > Message-ID: <7da7ad240706102136n75ef386ag2f98228e3b569939@mail.gmail.com> > Date: Sun, 10 Jun 2007 21:36:42 -0700 > From: "SLLabs Domain" > To: Object <513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com> > Subject: Re: Test! > In-Reply-To: <20070611043615.8CD0F5DC01F@sim324.agni.lindenlab.com> > Delivered-To: phpsmtp@sllabs.com > > TESTING REPLY > > > And again from a real GMAIL account directly: (DOES NOT WORK) > > Received: by 10.100.165.16 with HTTP; Sun, 10 Jun 2007 21:44:10 -0700 > (PDT) > Message-ID: > Date: Sun, 10 Jun 2007 21:44:10 -0700 > From: Kamilion > To: 513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com > Subject: Testing > MIME-Version: 1.0 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > Content-Disposition: inline > Delivered-To: kamilion@gmail.com > > HEEEELLLLOOOOOOOOOO > > No response from the receiver. > WTF? > _______________________________________________ > 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/20070610/a80006b4/attachment.htm From kamilion at gmail.com Mon Jun 11 02:35:54 2007 From: kamilion at gmail.com (Kamilion) Date: Mon Jun 11 02:35:56 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: References: Message-ID: Holy crap. This is far worse than I expected. I didn't want to use XMLRPC because I figured that a single point of failure and lag of a couple minutes wasn't worth it. >From what I knew, postfix ran on every simulator; so it was more distributed and hopefully more robust. Now it looks like something is SERIOUSLY wrong in email land. Last I knew, Michael, James, and Charity Linden were messing with postfix back in april's blog post. Now -- What can we do about this? I'm glad I said something, otherwise this might have been a quiet annoyance. I know postfix can be blazingly fast, I used to use it on my own domain before moving over to Google Apps for your Domain, So there's obviously some kind of misconfiguration somewhere. If you feel like sharing; I'd like a copy of that PHP and LSL you use; because this is EXACTLY the sort of setup I'm trying to achieve (PHP Mail to LSL). So far, I've had to bash at PHP to even get it to talk to Google's AfyD server. Google uses SSL/TLS *ONLY* for SMTP auth, so php's mail() function doesn't work so well. After doing exhaustive research, I came up with the following options: http://www.bytewize.com/linux/BetterSMTPhelp.php BetterSMTP, a phpbb2.x mod to use the SquirrelMail SMTP classes. Looked to be broken and forum posts about it were awash with PLZ HELP. No good. http://www.vulgarisoip.com/?p=17 PHPGmailer, a Cut & Paste job on PHPMailer to kitbash it into using TLSSTART. Also no good, PHPMailer isn't maintained anymore and this kitbash comes up with SSL errors on connection close. The winner: Still poking along, I ran across this bug report for Wordpress: http://trac.wordpress.org/ticket/4326 #4326 (WP can't use Google Apps For Your Domain email accounts.) Which linked me here: http://www.shiftthis.net/wordpress-swift-smtp-plugin/ Which linked me here: http://www.swiftmailer.org/ "Swift is a free feature-rich PHP Mailer -- Swift is a fully OOP library for sending e-mails from PHP websites and applications. It does not rely on PHP's native mail() function which is known for using high server resources when sending multiple emails. Instead, Swift communicates directly with an SMTP server or a MTA binary to send mail quickly and efficiently." Score! One of the features it lists: "SSL & TLS Support - for Gmail servers" So, here's how I hacked together a nice little test script: \n
\n"; // Create a SMTP connection handler (Google Apps for your Domain) $smtp = new Swift_Connection_SMTP("smtp.googlemail.com", Swift_Connection_SMTP::PORT_SECURE, Swift_Connection_SMTP::ENC_TLS); $smtp->setUsername("phpsmtp@sllabs.com"); $smtp->setpassword("smtpmail"); // Create the Swift object interface $swift =& new Swift($smtp); $to = "513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com"; $subject = "Testing my subject"; $message = "A very long\n and drawn out\n message.\n\nRar!"; //Create the message $swiftmessage =& new Swift_Message($subject, $message); //Now check if Swift actually sends it if ($swift->send($swiftmessage, $to, "phpsmtp@sllabs.com")) { echo "Sent"; } else { echo "Failed"; } ?> Here's a sample result: Delivered-To: kamilion@gmail.com Received: by 10.100.165.16 with SMTP id n16cs242953ane; Sun, 10 Jun 2007 20:14:00 -0700 (PDT) Received: by 10.64.204.19 with SMTP id b19mr8395228qbg.1181531640038; Sun, 10 Jun 2007 20:14:00 -0700 (PDT) Return-Path: Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.225]) by mx.google.com with ESMTP id q14si5481907qbq.2007.06.10.20.13.59; Sun, 10 Jun 2007 20:14:00 -0700 (PDT) Received-SPF: neutral (google.com: 72.14.204.225 is neither permitted nor denied by best guess record for domain of phpsmtp@sllabs.com) Received: by qb-out-0506.google.com with SMTP id q12so1717954qba for ; Sun, 10 Jun 2007 20:13:59 -0700 (PDT) Received: by 10.115.110.6 with SMTP id n6mr5060449wam.1181531638487; Sun, 10 Jun 2007 20:13:58 -0700 (PDT) Return-Path: Received: from ?216.218.196.73? ( [216.218.196.73]) by mx.google.com with ESMTP id n38sm6862970wag.2007.06.10.20.13.57 (version=SSLv3 cipher=OTHER); Sun, 10 Jun 2007 20:13:58 -0700 (PDT) Return-Path: To: Kamilion@gmail.com From: phpsmtp@sllabs.com Reply-To: phpsmtp@sllabs.com Subject: My subject Date: Sun, 10 Jun 2007 20:15:09 -0700 X-LibVersion: 3.2.6 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Message-ID: <20070611031509.22850.1036293226.swift@vendor.sllabs.com> My body So, anyway. External Domain Email's obviously broked somehow. Included some data that could be useful for others. Harold, I've got land in multiple mainland and private sims. If you feel like it, I can set up some additional prims to take multiple metrics, and see if there's a correlation. sllabs.com is run from a Gentoo VPS hosted by atarack.com in Hurricane Electric's Fremont-II datacenter, roughly 2ms from the main LL datacenter in SF. If you should decide to decline sharing your code, heck, I'll bash up a similar PHP&LSL script and share it in this thread, just because I wanna get to the bottom of this; and hopefully share as much data as I can with the lindens so they can fix it properly. -- Graham Cantin (Kamilion Schnook) (sorry for the longwinded mails, but this stuff's archived, so it may help out others in the future who are browsing the SLDev archives or the Google Coop search :) On 6/10/07, Harold Brown wrote: > Welcome to the hell of trying to use external -> internal E-Mail with SL. > > For a nice history of the reliability of external -> internal E-Mail from > May 2 -> current date, you can view my test log at this URL: > http://www.rpgstats.com/SL/maillog.txt > > If you would like to review the history from February8 -> May2 it is > available here: > http://www.rpgstats.com/SL/maillog1.txt > > As of the time I'm replying there seems to be about 4 hour delay in e-mail > processing for SL... There have been delays up to around 24 hours. > > For those interested in how the test works. > > I have an LSL script running on my sim that once every 30 minutes requests a > PHP script on my webserver to send an e-mail. The PHP script generates a > random string for the subject and logs the time that it sends to the > maillog.txt file. The LSL script checks every 5 seconds for a new E-Mail, > and upon receiving one it tells the PHP script on the server that it > recieved an E-Mail and what the subject was. The PHP script then logs this > information as well. > > On 6/10/07, Kamilion wrote: > > > > I'm having some problems with objects and receiving email from outside > > of the secondlife.com domain -- They seem to be failing without an > > error or bounce message, and the object never appears to receive the > > email. I was hoping someone could look into this or point someone who > > can at it. I submitted a ticket in the new support system, TicketID > > 4051-4201708. > > > > Synopsis: > > Object Sending Email (Working) > > Object Receiving Email from another Object (Working) > > Object Receiving Email from Google Apps for your Domain hosted system: > > ( sllabs.com) (NOT WORKING) > > Object Receiving Email from Google Mail (gmail.com) (NOT WORKING) From seg at haxxed.com Mon Jun 11 02:47:47 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Jun 11 02:47:41 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <46669067.4040606@blueflash.cc> References: <466324A5.2040908@blueflash.cc> <466331B2.5000506@dzonux.net> <46641A57.6000409@blueflash.cc> <466646D5.4050500@lindenlab.com> <46669067.4040606@blueflash.cc> Message-ID: <1181555267.9159.11.camel@localhost> On Wed, 2007-06-06 at 12:45 +0200, Nicholaz Beresford wrote: > I don't know about PIII processors, also not how P4 optimization > would affect AMD's, but from what I can say from hands on experience > with my laptop, I doubt that your minimal requirement of a PIII/256MB > will allow for any meaningful experience, besides a SL slideshow maybe > (even running SL on a P4/1.6GHz/512MB/ATIX300 mobile was a pain and > that configuration is a long way head of of a PIII/800/256MB). Note that PIII's of up to 1.4ghz were made. Personally I have a laptop with a Celeron 1.3, which is based on a PIII core. It manages to crank out ~3fps with a few avatars on screen, the limiting factor seems to be more the 5 year old Intel 830M video, which is severely fill rate limited, than the CPU. Additional avatars of course quickly kill the framerate, even on my fastest machines... -------------- 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/20070611/2eb5d50f/attachment.pgp From zortiger at gmail.com Mon Jun 11 03:40:12 2007 From: zortiger at gmail.com (Erik Hill) Date: Mon Jun 11 03:40:16 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: References: Message-ID: <7c61ce730706110340t4a53d23fqda0a8c986b70092d@mail.gmail.com> This dosent sound vary good XMLRPC is already vary screwed up. Ill be testing this within the next few days my self. I am currently working on an application that has tight integration between a website and SL, that normally means some sort of communication. While i plan to make use of email for a good minority of it, as its only simi time sensitve, XMLPRC is a must for time sensitive data, such as results when they interact with a web page, I need both up and working correctly in order for my plans to completely work. I know from my current venders that rely on XMLRPC that its failor rate is up in the 20-30% depending on the time of day. >From what i can figure out single threaded applications tell horror stories about SL's XMLRPC functions, such as getting stuck infinity reading an open port that never gets data. >From what iv seen with the XMLRPC ill have to build a threaded application that opens up multiple attempts at the same time to get data in to SL, then shuts down after a thread receives data back from the object. Its the only way I can see to get data into SL at a realtime speed, and realtime is necessary in some cases. But yea, im next to getting into the email stuff for my project, so testing its delay is short list of things to do. On 6/11/07, Kamilion wrote: > > Holy crap. This is far worse than I expected. > I didn't want to use XMLRPC because I figured that a single point of > failure and lag of a couple minutes wasn't worth it. > > >From what I knew, postfix ran on every simulator; so it was more > distributed and hopefully more robust. > > Now it looks like something is SERIOUSLY wrong in email land. > > Last I knew, Michael, James, and Charity Linden were messing with > postfix back in april's blog post. > > Now -- What can we do about this? I'm glad I said something, otherwise > this might have been a quiet annoyance. > > I know postfix can be blazingly fast, I used to use it on my own > domain before moving over to Google Apps for your Domain, So there's > obviously some kind of misconfiguration somewhere. > > If you feel like sharing; I'd like a copy of that PHP and LSL you use; > because this is EXACTLY the sort of setup I'm trying to achieve (PHP > Mail to LSL). > > So far, I've had to bash at PHP to even get it to talk to Google's AfyD > server. > Google uses SSL/TLS *ONLY* for SMTP auth, so php's mail() function > doesn't work so well. > > After doing exhaustive research, I came up with the following options: > http://www.bytewize.com/linux/BetterSMTPhelp.php > BetterSMTP, a phpbb2.x mod to use the SquirrelMail SMTP classes. > Looked to be broken and forum posts about it were awash with PLZ HELP. > No good. > http://www.vulgarisoip.com/?p=17 > PHPGmailer, a Cut & Paste job on PHPMailer to kitbash it into using > TLSSTART. Also no good, PHPMailer isn't maintained anymore and this > kitbash comes up with SSL errors on connection close. > > The winner: > Still poking along, I ran across this bug report for Wordpress: > http://trac.wordpress.org/ticket/4326 #4326 (WP can't use Google > Apps For Your Domain email accounts.) > Which linked me here: > http://www.shiftthis.net/wordpress-swift-smtp-plugin/ > Which linked me here: > http://www.swiftmailer.org/ > "Swift is a free feature-rich PHP Mailer -- Swift is a fully OOP > library for sending e-mails from PHP websites and applications. It > does not rely on PHP's native mail() function which is known for using > high server resources when sending multiple emails. Instead, Swift > communicates directly with an SMTP server or a MTA binary to send mail > quickly and efficiently." > > Score! > One of the features it lists: "SSL & TLS Support - for Gmail servers" > > So, here's how I hacked together a nice little test script: > > require_once "swiftmailer/Swift.php"; > require_once "swiftmailer/Swift/Connection/SMTP.php"; > > echo "Starting...\n
\n
\n"; > > // Create a SMTP connection handler (Google Apps for your Domain) > $smtp = new Swift_Connection_SMTP("smtp.googlemail.com", > Swift_Connection_SMTP::PORT_SECURE, Swift_Connection_SMTP::ENC_TLS); > $smtp->setUsername("phpsmtp@sllabs.com"); > $smtp->setpassword("smtpmail"); > > // Create the Swift object interface > $swift =& new Swift($smtp); > > $to = "513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com"; > $subject = "Testing my subject"; > $message = "A very long\n and drawn out\n message.\n\nRar!"; > > //Create the message > $swiftmessage =& new Swift_Message($subject, $message); > > //Now check if Swift actually sends it > if ($swift->send($swiftmessage, $to, "phpsmtp@sllabs.com")) > { echo "Sent"; } else { echo "Failed"; } > > ?> > > > Here's a sample result: > > Delivered-To: kamilion@gmail.com > Received: by 10.100.165.16 with SMTP id n16cs242953ane; > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > Received: by 10.64.204.19 with SMTP id b19mr8395228qbg.1181531640038; > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > Return-Path: > Received: from qb-out-0506.google.com (qb-out-0506.google.com [ > 72.14.204.225]) > by mx.google.com with ESMTP id q14si5481907qbq.2007.06.10.20.13.59 > ; > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > Received-SPF: neutral (google.com: 72.14.204.225 is neither permitted > nor denied by best guess record for domain of phpsmtp@sllabs.com) > Received: by qb-out-0506.google.com with SMTP id q12so1717954qba > for ; Sun, 10 Jun 2007 20:13:59 -0700 (PDT) > Received: by 10.115.110.6 with SMTP id n6mr5060449wam.1181531638487; > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > Return-Path: > Received: from ?216.218.196.73? ( [216.218.196.73]) > by mx.google.com with ESMTP id n38sm6862970wag.2007.06.10.20.13.57 > (version=SSLv3 cipher=OTHER); > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > Return-Path: > To: Kamilion@gmail.com > From: phpsmtp@sllabs.com > Reply-To: phpsmtp@sllabs.com > Subject: My subject > Date: Sun, 10 Jun 2007 20:15:09 -0700 > X-LibVersion: 3.2.6 > MIME-Version: 1.0 > Content-Type: text/plain; charset=iso-8859-1; format=flowed > Content-Transfer-Encoding: 8bit > Message-ID: <20070611031509.22850.1036293226.swift@vendor.sllabs.com> > > My body > > > > So, anyway. > External Domain Email's obviously broked somehow. > Included some data that could be useful for others. > > Harold, I've got land in multiple mainland and private sims. If you > feel like it, I can set up some additional prims to take multiple > metrics, and see if there's a correlation. > > sllabs.com is run from a Gentoo VPS hosted by atarack.com in Hurricane > Electric's Fremont-II datacenter, roughly 2ms from the main LL > datacenter in SF. > > If you should decide to decline sharing your code, heck, I'll bash up > a similar PHP&LSL script and share it in this thread, just because I > wanna get to the bottom of this; and hopefully share as much data as I > can with the lindens so they can fix it properly. > > -- Graham Cantin (Kamilion Schnook) > > (sorry for the longwinded mails, but this stuff's archived, so it may > help out others in the future who are browsing the SLDev archives or > the Google Coop search :) > > > > On 6/10/07, Harold Brown wrote: > > Welcome to the hell of trying to use external -> internal E-Mail with > SL. > > > > For a nice history of the reliability of external -> internal E-Mail > from > > May 2 -> current date, you can view my test log at this URL: > > http://www.rpgstats.com/SL/maillog.txt > > > > If you would like to review the history from February8 -> May2 it is > > available here: > > http://www.rpgstats.com/SL/maillog1.txt > > > > As of the time I'm replying there seems to be about 4 hour delay in > e-mail > > processing for SL... There have been delays up to around 24 hours. > > > > For those interested in how the test works. > > > > I have an LSL script running on my sim that once every 30 minutes > requests a > > PHP script on my webserver to send an e-mail. The PHP script generates > a > > random string for the subject and logs the time that it sends to the > > maillog.txt file. The LSL script checks every 5 seconds for a new > E-Mail, > > and upon receiving one it tells the PHP script on the server that it > > recieved an E-Mail and what the subject was. The PHP script then logs > this > > information as well. > > > > On 6/10/07, Kamilion wrote: > > > > > > I'm having some problems with objects and receiving email from outside > > > of the secondlife.com domain -- They seem to be failing without an > > > error or bounce message, and the object never appears to receive the > > > email. I was hoping someone could look into this or point someone who > > > can at it. I submitted a ticket in the new support system, TicketID > > > 4051-4201708. > > > > > > Synopsis: > > > Object Sending Email (Working) > > > Object Receiving Email from another Object (Working) > > > Object Receiving Email from Google Apps for your Domain hosted system: > > > ( sllabs.com) (NOT WORKING) > > > Object Receiving Email from Google Mail (gmail.com) (NOT WORKING) > _______________________________________________ > 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/20070611/dd7e308a/attachment.htm From soft at softnoel.org Mon Jun 11 07:41:12 2007 From: soft at softnoel.org (Soft Noel) Date: Mon Jun 11 07:41:13 2007 Subject: [sldev] SLDev-Traffic #15 Message-ID: <9e6e5c9e0706110741w57c01a1fnc2ae81e40022928f@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_15 SLDev-Traffic number 15 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From Dana.Fagerstrom at Sun.COM Mon Jun 11 07:51:48 2007 From: Dana.Fagerstrom at Sun.COM (Dana Fagerstrom) Date: Mon Jun 11 07:54:23 2007 Subject: [sldev] alignment problems in the viewer Message-ID: <466D6184.90207@sun.com> Folks, One of the largest problems I've had in porting the viewer to SPARC are alignment problems assumed throughout the source. For example, llmath/lluuid.h defines mData as: U8 mData[[UUID_BYTES]; Tricks are used using U32 so that 4 byte chunks can be manipulated. This is all well and good when the CPU in question aligns properly but it fails miserably on other CPUs. It's not a weakness of the CPU but poor coding practice. I've been able to get around these issues using: U8 mData[UUID_BYTES] __attribute__ ((aligned(8))); which forces the compiler to ensure all bytes are aligned and no padding is added. I'd like to ask those much more familiar with the code to identify other areas where this alignment is assumed so I can fix the code accordingly. As expected, I am wrapping these changes in #if's so that x86 users get the original code and so that the Lindens can decide if the changes should be made permanent across all platform. Thanks, D -- ===================================================================== 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 chance at kalacia.com Mon Jun 11 08:54:28 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jun 11 08:54:31 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: <7c61ce730706110340t4a53d23fqda0a8c986b70092d@mail.gmail.com> References: <7c61ce730706110340t4a53d23fqda0a8c986b70092d@mail.gmail.com> Message-ID: <2925011a0706110854l4f33c4deoaa27b7a6cd5f7269@mail.gmail.com> email between objects is more robust and breaks with less frequency than the xmlrpc interface. but, when your sim is constipated on the email, trying to find someone to come fix it is a nightmare. and without support channels or access to lindens. you can feel basically screwed. HTTPRequest() is the way to go right now. On 6/11/07, Erik Hill wrote: > > This dosent sound vary good > > XMLRPC is already vary screwed up. > > Ill be testing this within the next few days my self. > > I am currently working on an application that has tight integration > between a website and SL, that normally means some sort of communication. > While i plan to make use of email for a good minority of it, as its only > simi time sensitve, XMLPRC is a must for time sensitive data, such as > results when they interact with a web page, I need both up and working > correctly in order for my plans to completely work. > > I know from my current venders that rely on XMLRPC that its failor rate is > up in the 20-30% depending on the time of day. > From what i can figure out single threaded applications tell horror > stories about SL's XMLRPC functions, such as getting stuck infinity reading > an open port that never gets data. > From what iv seen with the XMLRPC ill have to build a threaded application > that opens up multiple attempts at the same time to get data in to SL, then > shuts down after a thread receives data back from the object. Its the only > way I can see to get data into SL at a realtime speed, and realtime is > necessary in some cases. > > But yea, im next to getting into the email stuff for my project, so > testing its delay is short list of things to do. > > On 6/11/07, Kamilion < kamilion@gmail.com> wrote: > > > > Holy crap. This is far worse than I expected. > > I didn't want to use XMLRPC because I figured that a single point of > > failure and lag of a couple minutes wasn't worth it. > > > > >From what I knew, postfix ran on every simulator; so it was more > > distributed and hopefully more robust. > > > > Now it looks like something is SERIOUSLY wrong in email land. > > > > Last I knew, Michael, James, and Charity Linden were messing with > > postfix back in april's blog post. > > > > Now -- What can we do about this? I'm glad I said something, otherwise > > this might have been a quiet annoyance. > > > > I know postfix can be blazingly fast, I used to use it on my own > > domain before moving over to Google Apps for your Domain, So there's > > obviously some kind of misconfiguration somewhere. > > > > If you feel like sharing; I'd like a copy of that PHP and LSL you use; > > because this is EXACTLY the sort of setup I'm trying to achieve (PHP > > Mail to LSL). > > > > So far, I've had to bash at PHP to even get it to talk to Google's AfyD > > server. > > Google uses SSL/TLS *ONLY* for SMTP auth, so php's mail() function > > doesn't work so well. > > > > After doing exhaustive research, I came up with the following options: > > http://www.bytewize.com/linux/BetterSMTPhelp.php > > BetterSMTP, a phpbb2.x mod to use the SquirrelMail SMTP classes. > > Looked to be broken and forum posts about it were awash with PLZ HELP. > > No good. > > http://www.vulgarisoip.com/?p=17 > > PHPGmailer, a Cut & Paste job on PHPMailer to kitbash it into using > > TLSSTART. Also no good, PHPMailer isn't maintained anymore and this > > kitbash comes up with SSL errors on connection close. > > > > The winner: > > Still poking along, I ran across this bug report for Wordpress: > > http://trac.wordpress.org/ticket/4326 #4326 (WP can't use Google > > Apps For Your Domain email accounts.) > > Which linked me here: > > http://www.shiftthis.net/wordpress-swift-smtp-plugin/ > > Which linked me here: > > http://www.swiftmailer.org/ > > "Swift is a free feature-rich PHP Mailer -- Swift is a fully OOP > > library for sending e-mails from PHP websites and applications. It > > does not rely on PHP's native mail() function which is known for using > > high server resources when sending multiple emails. Instead, Swift > > communicates directly with an SMTP server or a MTA binary to send mail > > quickly and efficiently." > > > > Score! > > One of the features it lists: "SSL & TLS Support - for Gmail servers" > > > > So, here's how I hacked together a nice little test script: > > > > > require_once "swiftmailer/Swift.php"; > > require_once "swiftmailer/Swift/Connection/SMTP.php"; > > > > echo "Starting...\n
\n
\n"; > > > > // Create a SMTP connection handler (Google Apps for your Domain) > > $smtp = new Swift_Connection_SMTP("smtp.googlemail.com", > > Swift_Connection_SMTP::PORT_SECURE, Swift_Connection_SMTP::ENC_TLS); > > $smtp->setUsername("phpsmtp@sllabs.com"); > > $smtp->setpassword("smtpmail"); > > > > // Create the Swift object interface > > $swift =& new Swift($smtp); > > > > $to = "513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com"; > > $subject = "Testing my subject"; > > $message = "A very long\n and drawn out\n message.\n\nRar!"; > > > > //Create the message > > $swiftmessage =& new Swift_Message($subject, $message); > > > > //Now check if Swift actually sends it > > if ($swift->send($swiftmessage, $to, " phpsmtp@sllabs.com")) > > { echo "Sent"; } else { echo "Failed"; } > > > > ?> > > > > > > Here's a sample result: > > > > Delivered-To: kamilion@gmail.com > > Received: by 10.100.165.16 with SMTP id n16cs242953ane; > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > Received: by 10.64.204.19 with SMTP id b19mr8395228qbg.1181531640038; > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > Return-Path: > > Received: from qb-out-0506.google.com (qb-out-0506.google.com [ > > 72.14.204.225]) > > by mx.google.com with ESMTP id > > q14si5481907qbq.2007.06.10.20.13.59; > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > Received-SPF: neutral (google.com: 72.14.204.225 is neither permitted > > nor denied by best guess record for domain of phpsmtp@sllabs.com) > > Received: by qb-out-0506.google.com with SMTP id q12so1717954qba > > for ; Sun, 10 Jun 2007 20:13:59 -0700 (PDT) > > Received: by 10.115.110.6 with SMTP id n6mr5060449wam.1181531638487 ; > > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > > Return-Path: > > Received: from ?216.218.196.73? ( [216.218.196.73 ]) > > by mx.google.com with ESMTP id > > n38sm6862970wag.2007.06.10.20.13.57 > > (version=SSLv3 cipher=OTHER); > > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > > Return-Path: < phpsmtp@sllabs.com> > > To: Kamilion@gmail.com > > From: phpsmtp@sllabs.com > > Reply-To: phpsmtp@sllabs.com > > Subject: My subject > > Date: Sun, 10 Jun 2007 20:15:09 -0700 > > X-LibVersion: 3.2.6 > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > Content-Transfer-Encoding: 8bit > > Message-ID: <20070611031509.22850.1036293226.swift@vendor.sllabs.com> > > > > My body > > > > > > > > So, anyway. > > External Domain Email's obviously broked somehow. > > Included some data that could be useful for others. > > > > Harold, I've got land in multiple mainland and private sims. If you > > feel like it, I can set up some additional prims to take multiple > > metrics, and see if there's a correlation. > > > > sllabs.com is run from a Gentoo VPS hosted by atarack.com in Hurricane > > Electric's Fremont-II datacenter, roughly 2ms from the main LL > > datacenter in SF. > > > > If you should decide to decline sharing your code, heck, I'll bash up > > a similar PHP&LSL script and share it in this thread, just because I > > wanna get to the bottom of this; and hopefully share as much data as I > > can with the lindens so they can fix it properly. > > > > -- Graham Cantin (Kamilion Schnook) > > > > (sorry for the longwinded mails, but this stuff's archived, so it may > > help out others in the future who are browsing the SLDev archives or > > the Google Coop search :) > > > > > > > > On 6/10/07, Harold Brown wrote: > > > Welcome to the hell of trying to use external -> internal E-Mail with > > SL. > > > > > > For a nice history of the reliability of external -> internal E-Mail > > from > > > May 2 -> current date, you can view my test log at this URL: > > > http://www.rpgstats.com/SL/maillog.txt > > > > > > If you would like to review the history from February8 -> May2 it is > > > available here: > > > http://www.rpgstats.com/SL/maillog1.txt > > > > > > As of the time I'm replying there seems to be about 4 hour delay in > > e-mail > > > processing for SL... There have been delays up to around 24 hours. > > > > > > For those interested in how the test works. > > > > > > I have an LSL script running on my sim that once every 30 minutes > > requests a > > > PHP script on my webserver to send an e-mail. The PHP script > > generates a > > > random string for the subject and logs the time that it sends to the > > > maillog.txt file. The LSL script checks every 5 seconds for a new > > E-Mail, > > > and upon receiving one it tells the PHP script on the server that it > > > recieved an E-Mail and what the subject was. The PHP script then logs > > this > > > information as well. > > > > > > On 6/10/07, Kamilion wrote: > > > > > > > > I'm having some problems with objects and receiving email from > > outside > > > > of the secondlife.com domain -- They seem to be failing without an > > > > error or bounce message, and the object never appears to receive the > > > > email. I was hoping someone could look into this or point someone > > who > > > > can at it. I submitted a ticket in the new support system, TicketID > > > > 4051-4201708. > > > > > > > > Synopsis: > > > > Object Sending Email (Working) > > > > Object Receiving Email from another Object (Working) > > > > Object Receiving Email from Google Apps for your Domain hosted > > system: > > > > ( sllabs.com) (NOT WORKING) > > > > Object Receiving Email from Google Mail ( gmail.com) (NOT WORKING) > > _______________________________________________ > > 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/20070611/8f452af7/attachment.htm From kelly at lindenlab.com Mon Jun 11 10:22:15 2007 From: kelly at lindenlab.com (Kelly Washington) Date: Mon Jun 11 10:22:24 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: <2925011a0706110854l4f33c4deoaa27b7a6cd5f7269@mail.gmail.com> References: <7c61ce730706110340t4a53d23fqda0a8c986b70092d@mail.gmail.com> <2925011a0706110854l4f33c4deoaa27b7a6cd5f7269@mail.gmail.com> Message-ID: <466D84C7.5030901@lindenlab.com> We are currently (this minute, really) investigating emails from outside to LSL being broken. Some more comments about communication between LSL and outside SL: - All XML-RPC requests go through a central server. That 'server' is really an apache host running a C++ cgi. This cgi module looks up object presence info (what host it is on) based on the channel ID and routes the message accordingly. This server is consistently overloaded although I believe we upgraded it, again, recently. As a central point of failure it will never scale as well as needed, and should eventually be deprecated. - All email from outside goes through a single server that maps to lsl.secondlife.com. The emails are passed to a perl script that checks some edge cases and looks up presence info (what host the object is on) in backbone (the python service that hosts agent presence as well). However, objects only have presence in backbone if they have called llGetNextEmail at least once; if there is no presence info for the object or the object is not where we think it is then it is put in the database and retrieved the next time the object calls llGetNextEmail. However, like xml-rpc email from outside SL to LSL goes through a central server that will never scale as well as needed and will eventually need to be deprecated or changed. By changed I mean for example requiring region information in addition to object ID in the email address used. (Email from lsl->lsl cheats, is never really an email and avoids the problems mentioned above except the presence part. If presence is broken then lsl->lsl email will fail unless the objects are on the same sim) *NOTE: While I used the word 'deprecated' above we currently have no solid plans to do so, I am not saying they are already deprecated and we will work with and communicate with the community a LOT before we move ahead with any plans related to that. Additionally we expect more communication alternatives to be in place before then. We are still supporting these methods and as I mentioned in the first line we are currently investigating the current email issues. - llHTTPRequest is the bomb. Really. It is lightweight and distributed. The entire action happens on the host the region with the object is on. There is no central server, no required presence registration. Lots and lots of requests can be done at the same time with essentially no effect on the rest of the simulator process. Yes there have been bugs before but most of those are now resolved. It is much better to have an object ping a server every second with an llHTTPRequest than it is use either XML-RPC or email->lsl. - Future communication methods: Zero Linden has talked about LSL communication methods at his office hours and has some pretty interesting stuff on his wiki page about it: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/Discussion#Incoming_HTTP No one, to my knowledge, is currently working on this. - Kelly Chance Unknown wrote: > email between objects is more robust and breaks with less frequency > than the xmlrpc interface. but, when your sim is constipated on the > email, trying to find someone to come fix it is a nightmare. and > without support channels or access to lindens. you can feel basically > screwed. HTTPRequest() is the way to go right now. > > On 6/11/07, *Erik Hill* > wrote: > > This dosent sound vary good > > XMLRPC is already vary screwed up. > > Ill be testing this within the next few days my self. > > I am currently working on an application that has tight > integration between a website and SL, that normally means some > sort of communication. > While i plan to make use of email for a good minority of it, as > its only simi time sensitve, XMLPRC is a must for time sensitive > data, such as results when they interact with a web page, I need > both up and working correctly in order for my plans to completely > work. > > I know from my current venders that rely on XMLRPC that its failor > rate is up in the 20-30% depending on the time of day. > From what i can figure out single threaded applications tell > horror stories about SL's XMLRPC functions, such as getting stuck > infinity reading an open port that never gets data. > From what iv seen with the XMLRPC ill have to build a threaded > application that opens up multiple attempts at the same time to > get data in to SL, then shuts down after a thread receives data > back from the object. Its the only way I can see to get data into > SL at a realtime speed, and realtime is necessary in some cases. > > But yea, im next to getting into the email stuff for my project, > so testing its delay is short list of things to do. > > > On 6/11/07, *Kamilion* < kamilion@gmail.com > > wrote: > > Holy crap. This is far worse than I expected. > I didn't want to use XMLRPC because I figured that a single > point of > failure and lag of a couple minutes wasn't worth it. > > >From what I knew, postfix ran on every simulator; so it was more > distributed and hopefully more robust. > > Now it looks like something is SERIOUSLY wrong in email land. > > Last I knew, Michael, James, and Charity Linden were messing with > postfix back in april's blog post. > > Now -- What can we do about this? I'm glad I said something, > otherwise > this might have been a quiet annoyance. > > I know postfix can be blazingly fast, I used to use it on my own > domain before moving over to Google Apps for your Domain, So > there's > obviously some kind of misconfiguration somewhere. > > If you feel like sharing; I'd like a copy of that PHP and LSL > you use; > because this is EXACTLY the sort of setup I'm trying to > achieve (PHP > Mail to LSL). > > So far, I've had to bash at PHP to even get it to talk to > Google's AfyD server. > Google uses SSL/TLS *ONLY* for SMTP auth, so php's mail() function > doesn't work so well. > > After doing exhaustive research, I came up with the following > options: > http://www.bytewize.com/linux/BetterSMTPhelp.php > BetterSMTP, a phpbb2.x mod to use the SquirrelMail SMTP classes. > Looked to be broken and forum posts about it were awash with > PLZ HELP. > No good. > http://www.vulgarisoip.com/?p=17 > PHPGmailer, a Cut & Paste job on PHPMailer to kitbash it into > using > TLSSTART. Also no good, PHPMailer isn't maintained anymore and > this > kitbash comes up with SSL errors on connection close. > > The winner: > Still poking along, I ran across this bug report for Wordpress: > http://trac.wordpress.org/ticket/4326 > #4326 (WP can't use > Google > Apps For Your Domain email accounts.) > Which linked me here: > http://www.shiftthis.net/wordpress-swift-smtp-plugin/ > Which linked me here: > http://www.swiftmailer.org/ > "Swift is a free feature-rich PHP Mailer -- Swift is a fully OOP > library for sending e-mails from PHP websites and applications. It > does not rely on PHP's native mail() function which is known > for using > high server resources when sending multiple emails. Instead, Swift > communicates directly with an SMTP server or a MTA binary to > send mail > quickly and efficiently." > > Score! > One of the features it lists: "SSL & TLS Support - for Gmail > servers" > > So, here's how I hacked together a nice little test script: > > require_once "swiftmailer/Swift.php"; > require_once "swiftmailer/Swift/Connection/SMTP.php"; > > echo "Starting...\n
\n
\n"; > > // Create a SMTP connection handler (Google Apps for your Domain) > $smtp = new Swift_Connection_SMTP(" smtp.googlemail.com > ", > Swift_Connection_SMTP::PORT_SECURE, > Swift_Connection_SMTP::ENC_TLS); > $smtp->setUsername("phpsmtp@sllabs.com > "); > $smtp->setpassword("smtpmail"); > > // Create the Swift object interface > $swift =& new Swift($smtp); > > $to = "513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com > > "; > $subject = "Testing my subject"; > $message = "A very long\n and drawn out\n message.\n\nRar!"; > > //Create the message > $swiftmessage =& new Swift_Message($subject, $message); > > //Now check if Swift actually sends it > if ($swift->send($swiftmessage, $to, " phpsmtp@sllabs.com > ")) > { echo "Sent"; } else { echo "Failed"; } > > ?> > > > Here's a sample result: > > Delivered-To: kamilion@gmail.com > Received: by 10.100.165.16 with SMTP id > n16cs242953ane; > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > Received: by 10.64.204.19 with SMTP id > b19mr8395228qbg.1181531640038; > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > Return-Path: > > Received: from qb-out-0506.google.com > (qb-out-0506.google.com > [ 72.14.204.225 > ]) > by mx.google.com with ESMTP id > q14si5481907qbq.2007.06.10.20.13.59; > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > Received-SPF: neutral (google.com : > 72.14.204.225 is neither permitted > nor denied by best guess record for domain of > phpsmtp@sllabs.com ) > Received: by qb-out-0506.google.com > with SMTP id q12so1717954qba > for >; > Sun, 10 Jun 2007 20:13:59 -0700 (PDT) > Received: by 10.115.110.6 with SMTP id > n6mr5060449wam.1181531638487 ; > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > Return-Path: > > Received: from ?216.218.196.73? ( [ 216.218.196.73 > ]) > by mx.google.com with ESMTP id > n38sm6862970wag.2007.06.10.20.13.57 > (version=SSLv3 cipher=OTHER); > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > Return-Path: < phpsmtp@sllabs.com > > To: Kamilion@gmail.com > From: phpsmtp@sllabs.com > Reply-To: phpsmtp@sllabs.com > Subject: My subject > Date: Sun, 10 Jun 2007 20:15:09 -0700 > X-LibVersion: 3.2.6 > MIME-Version: 1.0 > Content-Type: text/plain; charset=iso-8859-1; format=flowed > Content-Transfer-Encoding: 8bit > Message-ID: > <20070611031509.22850.1036293226.swift@vendor.sllabs.com > > > > My body > > > > So, anyway. > External Domain Email's obviously broked somehow. > Included some data that could be useful for others. > > Harold, I've got land in multiple mainland and private sims. > If you > feel like it, I can set up some additional prims to take multiple > metrics, and see if there's a correlation. > > sllabs.com is run from a Gentoo VPS hosted > by atarack.com in Hurricane > Electric's Fremont-II datacenter, roughly 2ms from the main LL > datacenter in SF. > > If you should decide to decline sharing your code, heck, I'll > bash up > a similar PHP&LSL script and share it in this thread, just > because I > wanna get to the bottom of this; and hopefully share as much > data as I > can with the lindens so they can fix it properly. > > -- Graham Cantin (Kamilion Schnook) > > (sorry for the longwinded mails, but this stuff's archived, so > it may > help out others in the future who are browsing the SLDev > archives or > the Google Coop search :) > > > > On 6/10/07, Harold Brown > wrote: > > Welcome to the hell of trying to use external -> internal > E-Mail with SL. > > > > For a nice history of the reliability of external -> internal > E-Mail from > > May 2 -> current date, you can view my test log at this URL: > > http://www.rpgstats.com/SL/maillog.txt > > > > If you would like to review the history from February8 -> > May2 it is > > available here: > > http://www.rpgstats.com/SL/maillog1.txt > > > > > As of the time I'm replying there seems to be about 4 hour > delay in e-mail > > processing for SL... There have been delays up to around 24 > hours. > > > > For those interested in how the test works. > > > > I have an LSL script running on my sim that once every 30 > minutes requests a > > PHP script on my webserver to send an e-mail. The PHP script > generates a > > random string for the subject and logs the time that it sends > to the > > maillog.txt file. The LSL script checks every 5 seconds for > a new E-Mail, > > and upon receiving one it tells the PHP script on the server > that it > > recieved an E-Mail and what the subject was. The PHP script > then logs this > > information as well. > > > > On 6/10/07, Kamilion > wrote: > > > > > > I'm having some problems with objects and receiving email > from outside > > > of the secondlife.com domain -- > They seem to be failing without an > > > error or bounce message, and the object never appears to > receive the > > > email. I was hoping someone could look into this or point > someone who > > > can at it. I submitted a ticket in the new support system, > TicketID > > > 4051-4201708. > > > > > > Synopsis: > > > Object Sending Email (Working) > > > Object Receiving Email from another Object (Working) > > > Object Receiving Email from Google Apps for your Domain > hosted system: > > > ( sllabs.com ) (NOT WORKING) > > > Object Receiving Email from Google Mail ( gmail.com > ) (NOT WORKING) > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070611/84737613/attachment-0001.htm From dzonatas at dzonux.net Mon Jun 11 11:12:20 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Mon Jun 11 11:12:11 2007 Subject: [sldev] Please, use "*.txt" extenstions in jira if the attachment is text based Message-ID: <466D9084.2040400@dzonux.net> Hi, JIRA does not automatically add any html/xml to the file attachment declaration to tell the browser that it has text based content. The simple solution is to add "*.txt" to the end of the filename, and the browser can easily override it based on the filename. The attachment files in JIRA then become easily click-able and immediately viewable. Thank you, Dz -- From gigstaggart at gmail.com Mon Jun 11 12:00:08 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Jun 11 12:00:19 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: References: Message-ID: <466D9BB8.4060906@gmail.com> Kamilion wrote: > Holy crap. This is far worse than I expected. > I didn't want to use XMLRPC because I figured that a single point of > failure and lag of a couple minutes wasn't worth it. > >> From what I knew, postfix ran on every simulator; so it was more > distributed and hopefully more robust. > > Now it looks like something is SERIOUSLY wrong in email land. > > Last I knew, Michael, James, and Charity Linden were messing with > postfix back in april's blog post. > > Now -- What can we do about this? I'm glad I said something, otherwise > this might have been a quiet annoyance. > > I know postfix can be blazingly fast, I used to use it on my own > domain before moving over to Google Apps for your Domain, So there's > obviously some kind of misconfiguration somewhere. > > If you feel like sharing; I'd like a copy of that PHP and LSL you use; > because this is EXACTLY the sort of setup I'm trying to achieve (PHP > Mail to LSL). > > So far, I've had to bash at PHP to even get it to talk to Google's AfyD > server. > Google uses SSL/TLS *ONLY* for SMTP auth, so php's mail() function > doesn't work so well. Pear has a mail class that does all you want and more. Why would anyone reinvent this wheel? http://email.about.com/od/emailprogrammingtips/qt/et073006.htm From zortiger at gmail.com Mon Jun 11 12:18:17 2007 From: zortiger at gmail.com (Erik Hill) Date: Mon Jun 11 12:18:21 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: <466D84C7.5030901@lindenlab.com> References: <7c61ce730706110340t4a53d23fqda0a8c986b70092d@mail.gmail.com> <2925011a0706110854l4f33c4deoaa27b7a6cd5f7269@mail.gmail.com> <466D84C7.5030901@lindenlab.com> Message-ID: <7c61ce730706111218n50199bd4l35ed9d6b4f9c4ee2@mail.gmail.com> Couldnt you do some load balancing on the XML-RPC, multiple servers, even round robin DNS could do better then a single server. SL really needs a realtime incoming communication method. My problem with useing HttpRequest is that its already being used in my system .. just below 1 call per second on large scale deployments. Around 36 objects (max) making HttRequests to get data into the system per sim. That dosent leave much time for any other httprequests, let alone others that arnt from my system and that are in that sim and under the same user. The consept im useing is more on the lines of a thin client. Considering LSL cant really becalled robust or fast. It would take me about 40 scripts and several months to recreate what can be done in a hour in most other languages, let alone data storage.. I need to store several mb's of information, and have it acessable fast - something thats not vary easy to do with LSL. So im porting every thing possable out of the server, and haveing only the reactions in LSL. Im hoping to also deploy something like this in upwards of 50 sims. The larger the scale the more important it becomes to get rid of unnessary data calls, it becomes necessary load on my server, and the outbound connection of SL.... Stable inbound connection would decrease the amount of load id have to put on my server, and decrease the httprequest calls that result in nothing more then saying 'Do i have a message?' When it should just simpily be able to drop a message to whatever object needs to get a message, saves bandwidth and resources, no extra sql querys to see if the message was gotten or if it was sent or if there is a message waiting. On 6/11/07, Kelly Washington wrote: > > We are currently (this minute, really) investigating emails from outside > to LSL being broken. > > Some more comments about communication between LSL and outside SL: > > - All XML-RPC requests go through a central server. That 'server' is > really an apache host running a C++ cgi. This cgi module looks up object > presence info (what host it is on) based on the channel ID and routes the > message accordingly. This server is consistently overloaded although I > believe we upgraded it, again, recently. As a central point of failure it > will never scale as well as needed, and should eventually be deprecated. > > - All email from outside goes through a single server that maps to > lsl.secondlife.com. The emails are passed to a perl script that checks > some edge cases and looks up presence info (what host the object is on) in > backbone (the python service that hosts agent presence as well). However, > objects only have presence in backbone if they have called llGetNextEmail at > least once; if there is no presence info for the object or the object is not > where we think it is then it is put in the database and retrieved the next > time the object calls llGetNextEmail. However, like xml-rpc email from > outside SL to LSL goes through a central server that will never scale as > well as needed and will eventually need to be deprecated or changed. By > changed I mean for example requiring region information in addition to > object ID in the email address used. (Email from lsl->lsl cheats, is never > really an email and avoids the problems mentioned above except the presence > part. If presence is broken then lsl->lsl email will fail unless the > objects are on the same sim) > > *NOTE: While I used the word 'deprecated' above we currently have no solid > plans to do so, I am not saying they are already deprecated and we will work > with and communicate with the community a LOT before we move ahead with any > plans related to that. Additionally we expect more communication > alternatives to be in place before then. We are still supporting these > methods and as I mentioned in the first line we are currently investigating > the current email issues. > > - llHTTPRequest is the bomb. Really. It is lightweight and > distributed. The entire action happens on the host the region with the > object is on. There is no central server, no required presence > registration. Lots and lots of requests can be done at the same time with > essentially no effect on the rest of the simulator process. Yes there have > been bugs before but most of those are now resolved. It is much better to > have an object ping a server every second with an llHTTPRequest than it is > use either XML-RPC or email->lsl. > > - Future communication methods: Zero Linden has talked about LSL > communication methods at his office hours and has some pretty interesting > stuff on his wiki page about it: > http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/Discussion#Incoming_HTTP > > No one, to my knowledge, is currently working on this. > > - Kelly > > Chance Unknown wrote: > > email between objects is more robust and breaks with less frequency than > the xmlrpc interface. but, when your sim is constipated on the email, trying > to find someone to come fix it is a nightmare. and without support channels > or access to lindens. you can feel basically screwed. HTTPRequest() is the > way to go right now. > > On 6/11/07, Erik Hill wrote: > > > > This dosent sound vary good > > > > XMLRPC is already vary screwed up. > > > > Ill be testing this within the next few days my self. > > > > I am currently working on an application that has tight integration > > between a website and SL, that normally means some sort of communication. > > While i plan to make use of email for a good minority of it, as its only > > simi time sensitve, XMLPRC is a must for time sensitive data, such as > > results when they interact with a web page, I need both up and working > > correctly in order for my plans to completely work. > > > > I know from my current venders that rely on XMLRPC that its failor rate > > is up in the 20-30% depending on the time of day. > > From what i can figure out single threaded applications tell horror > > stories about SL's XMLRPC functions, such as getting stuck infinity reading > > an open port that never gets data. > > From what iv seen with the XMLRPC ill have to build a threaded > > application that opens up multiple attempts at the same time to get data in > > to SL, then shuts down after a thread receives data back from the object. > > Its the only way I can see to get data into SL at a realtime speed, and > > realtime is necessary in some cases. > > > > But yea, im next to getting into the email stuff for my project, so > > testing its delay is short list of things to do. > > > > On 6/11/07, Kamilion < kamilion@gmail.com> wrote: > > > > > > Holy crap. This is far worse than I expected. > > > I didn't want to use XMLRPC because I figured that a single point of > > > failure and lag of a couple minutes wasn't worth it. > > > > > > >From what I knew, postfix ran on every simulator; so it was more > > > distributed and hopefully more robust. > > > > > > Now it looks like something is SERIOUSLY wrong in email land. > > > > > > Last I knew, Michael, James, and Charity Linden were messing with > > > postfix back in april's blog post. > > > > > > Now -- What can we do about this? I'm glad I said something, otherwise > > > > > > this might have been a quiet annoyance. > > > > > > I know postfix can be blazingly fast, I used to use it on my own > > > domain before moving over to Google Apps for your Domain, So there's > > > obviously some kind of misconfiguration somewhere. > > > > > > If you feel like sharing; I'd like a copy of that PHP and LSL you use; > > > because this is EXACTLY the sort of setup I'm trying to achieve (PHP > > > Mail to LSL). > > > > > > So far, I've had to bash at PHP to even get it to talk to Google's > > > AfyD server. > > > Google uses SSL/TLS *ONLY* for SMTP auth, so php's mail() function > > > doesn't work so well. > > > > > > After doing exhaustive research, I came up with the following options: > > > http://www.bytewize.com/linux/BetterSMTPhelp.php > > > BetterSMTP, a phpbb2.x mod to use the SquirrelMail SMTP classes. > > > Looked to be broken and forum posts about it were awash with PLZ HELP. > > > No good. > > > http://www.vulgarisoip.com/?p=17 > > > PHPGmailer, a Cut & Paste job on PHPMailer to kitbash it into using > > > TLSSTART. Also no good, PHPMailer isn't maintained anymore and this > > > kitbash comes up with SSL errors on connection close. > > > > > > The winner: > > > Still poking along, I ran across this bug report for Wordpress: > > > http://trac.wordpress.org/ticket/4326 #4326 (WP can't use Google > > > Apps For Your Domain email accounts.) > > > Which linked me here: > > > http://www.shiftthis.net/wordpress-swift-smtp-plugin/ > > > Which linked me here: > > > http://www.swiftmailer.org/ > > > "Swift is a free feature-rich PHP Mailer -- Swift is a fully OOP > > > library for sending e-mails from PHP websites and applications. It > > > does not rely on PHP's native mail() function which is known for using > > > > > > high server resources when sending multiple emails. Instead, Swift > > > communicates directly with an SMTP server or a MTA binary to send mail > > > quickly and efficiently." > > > > > > Score! > > > One of the features it lists: "SSL & TLS Support - for Gmail servers" > > > > > > So, here's how I hacked together a nice little test script: > > > > > > > > require_once "swiftmailer/Swift.php"; > > > require_once "swiftmailer/Swift/Connection/SMTP.php"; > > > > > > echo "Starting...\n
\n
\n"; > > > > > > // Create a SMTP connection handler (Google Apps for your Domain) > > > $smtp = new Swift_Connection_SMTP(" smtp.googlemail.com", > > > Swift_Connection_SMTP::PORT_SECURE, Swift_Connection_SMTP::ENC_TLS); > > > $smtp->setUsername("phpsmtp@sllabs.com"); > > > $smtp->setpassword("smtpmail"); > > > > > > // Create the Swift object interface > > > $swift =& new Swift($smtp); > > > > > > $to = "513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com "; > > > $subject = "Testing my subject"; > > > $message = "A very long\n and drawn out\n message.\n\nRar!"; > > > > > > //Create the message > > > $swiftmessage =& new Swift_Message($subject, $message); > > > > > > //Now check if Swift actually sends it > > > if ($swift->send($swiftmessage, $to, " phpsmtp@sllabs.com")) > > > { echo "Sent"; } else { echo "Failed"; } > > > > > > ?> > > > > > > > > > Here's a sample result: > > > > > > Delivered-To: kamilion@gmail.com > > > Received: by 10.100.165.16 with SMTP id n16cs242953ane; > > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > > Received: by 10.64.204.19 with SMTP id b19mr8395228qbg.1181531640038; > > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > > Return-Path: > > > Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.225 > > > ]) > > > by mx.google.com with ESMTP id > > > q14si5481907qbq.2007.06.10.20.13.59; > > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > > Received-SPF: neutral (google.com : 72.14.204.225 is neither permitted > > > > > > nor denied by best guess record for domain of phpsmtp@sllabs.com) > > > Received: by qb-out-0506.google.com with SMTP id q12so1717954qba > > > for ; Sun, 10 Jun 2007 20:13:59 -0700 > > > (PDT) > > > Received: by 10.115.110.6 with SMTP id n6mr5060449wam.1181531638487 ; > > > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > > > Return-Path: > > > Received: from ?216.218.196.73? ( [ 216.218.196.73 ]) > > > by mx.google.com with ESMTP id > > > n38sm6862970wag.2007.06.10.20.13.57 > > > (version=SSLv3 cipher=OTHER); > > > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > > > Return-Path: < phpsmtp@sllabs.com> > > > To: Kamilion@gmail.com > > > From: phpsmtp@sllabs.com > > > Reply-To: phpsmtp@sllabs.com > > > Subject: My subject > > > Date: Sun, 10 Jun 2007 20:15:09 -0700 > > > X-LibVersion: 3.2.6 > > > MIME-Version: 1.0 > > > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > > Content-Transfer-Encoding: 8bit > > > Message-ID: <20070611031509.22850.1036293226.swift@vendor.sllabs.com > > > > > > > My body > > > > > > > > > > > > So, anyway. > > > External Domain Email's obviously broked somehow. > > > Included some data that could be useful for others. > > > > > > Harold, I've got land in multiple mainland and private sims. If you > > > feel like it, I can set up some additional prims to take multiple > > > metrics, and see if there's a correlation. > > > > > > sllabs.com is run from a Gentoo VPS hosted by atarack.com in Hurricane > > > Electric's Fremont-II datacenter, roughly 2ms from the main LL > > > datacenter in SF. > > > > > > If you should decide to decline sharing your code, heck, I'll bash up > > > a similar PHP&LSL script and share it in this thread, just because I > > > wanna get to the bottom of this; and hopefully share as much data as I > > > > > > can with the lindens so they can fix it properly. > > > > > > -- Graham Cantin (Kamilion Schnook) > > > > > > (sorry for the longwinded mails, but this stuff's archived, so it may > > > help out others in the future who are browsing the SLDev archives or > > > the Google Coop search :) > > > > > > > > > > > > On 6/10/07, Harold Brown wrote: > > > > Welcome to the hell of trying to use external -> internal E-Mail > > > with SL. > > > > > > > > For a nice history of the reliability of external -> internal E-Mail > > > from > > > > May 2 -> current date, you can view my test log at this URL: > > > > http://www.rpgstats.com/SL/maillog.txt > > > > > > > > If you would like to review the history from February8 -> May2 it is > > > > available here: > > > > http://www.rpgstats.com/SL/maillog1.txt > > > > > > > > As of the time I'm replying there seems to be about 4 hour delay in > > > e-mail > > > > processing for SL... There have been delays up to around 24 hours. > > > > > > > > For those interested in how the test works. > > > > > > > > I have an LSL script running on my sim that once every 30 minutes > > > requests a > > > > PHP script on my webserver to send an e-mail. The PHP script > > > generates a > > > > random string for the subject and logs the time that it sends to the > > > > > > > maillog.txt file. The LSL script checks every 5 seconds for a new > > > E-Mail, > > > > and upon receiving one it tells the PHP script on the server that it > > > > recieved an E-Mail and what the subject was. The PHP script then > > > logs this > > > > information as well. > > > > > > > > On 6/10/07, Kamilion wrote: > > > > > > > > > > I'm having some problems with objects and receiving email from > > > outside > > > > > of the secondlife.com domain -- They seem to be failing without an > > > > > error or bounce message, and the object never appears to receive > > > the > > > > > email. I was hoping someone could look into this or point someone > > > who > > > > > can at it. I submitted a ticket in the new support system, > > > TicketID > > > > > 4051-4201708. > > > > > > > > > > Synopsis: > > > > > Object Sending Email (Working) > > > > > Object Receiving Email from another Object (Working) > > > > > Object Receiving Email from Google Apps for your Domain hosted > > > system: > > > > > ( sllabs.com) (NOT WORKING) > > > > > Object Receiving Email from Google Mail ( gmail.com) (NOT WORKING) > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > ------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070611/bbdf13b9/attachment-0001.htm From nicholaz at blueflash.cc Mon Jun 11 13:37:27 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 11 13:37:39 2007 Subject: [sldev] Wiki Formatting Message-ID: <466DB287.1030407@blueflash.cc> Hi All! Is there an "official" way to insert forced blank lines into the wiki? I noticed with the longer documents (like the VS2003 / VS2005 instructions) that editing a section (the [edit] link next to a header) removes empty lines and pushes the headings very close to the previous paragraph. The obvioius fix would be to add top margin to the headers in css files, but for the compile instructions, something like
or   would do fine as far as I'm concerned. Any thoughts or ideas? Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From kamilion at gmail.com Mon Jun 11 13:48:02 2007 From: kamilion at gmail.com (Kamilion) Date: Mon Jun 11 13:48:06 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: <466D84C7.5030901@lindenlab.com> References: <7c61ce730706110340t4a53d23fqda0a8c986b70092d@mail.gmail.com> <2925011a0706110854l4f33c4deoaa27b7a6cd5f7269@mail.gmail.com> <466D84C7.5030901@lindenlab.com> Message-ID: Replies in-line. On 6/11/07 at 10:22AM, Kelly Washington wrote: > > We are currently (this minute, really) investigating emails from outside to > LSL being broken. Yup, I just received a very kind IM from James Linden: [10:09] James Linden: Yes, inbound email to scripts appears to be broken. It looks like our mail queue got flooded by email from some outside domain. Operations is clearing the queue now. Thanks for pointing this out! Don Linden is leading the recovery efforts. This is why I love the SLDev ML -- Signal to noise is great, the lindens actually listen because the list is low traffic, and the people here are awesome! Three cheers for Kelly, James, and Don! And congrats, Soft! > > Some more comments about communication between LSL and outside SL: > > - All XML-RPC requests go through a central server. That 'server' is > really an apache host running a C++ cgi. This cgi module looks up object > presence info (what host it is on) based on the channel ID and routes the > message accordingly. This server is consistently overloaded although I > believe we upgraded it, again, recently. As a central point of failure it > will never scale as well as needed, and should eventually be deprecated. How hard would it be to deploy this CGI on more than one server? Anotherwords, where is the bottleneck here, CPU, Memory, network, or presance database? Technically, you guys should be able to bring a second server online called, for instance, xmlrpc2. New projects could use the second server and ignore the primary; or a round robin could be set up to load balance between them, but just the act of setting up a second unloaded server could mitigate a lot of the problem; Theoretically it should be simple to rig the simulator's LSLVM to remember which XMLRPC server the incoming request came in from and reply via the same. > > - All email from outside goes through a single server that maps to > lsl.secondlife.com. The emails are passed to a perl script that checks some > edge cases and looks up presence info (what host the object is on) in > backbone (the python service that hosts agent presence as well). However, > objects only have presence in backbone if they have called llGetNextEmail at > least once; if there is no presence info for the object or the object is not > where we think it is then it is put in the database and retrieved the next > time the object calls llGetNextEmail. However, like xml-rpc email from > outside SL to LSL goes through a central server that will never scale as > well as needed and will eventually need to be deprecated or changed. By > changed I mean for example requiring region information in addition to > object ID in the email address used. (Email from lsl->lsl cheats, is never > really an email and avoids the problems mentioned above except the presence > part. If presence is broken then lsl->lsl email will fail unless the > objects are on the same sim) Hm, This looks like another set of systems that could use some redundancy. James said the email server had been flooded. Are you guys using rate control to process incoming mail only, or do you have additional services deployed on that box like SpamAssassin or another Realtime Blackhole List for ignoring evil domains? Most proper domains have SPF set up, and if they don't, it's relatively simple to do if you have access to your DNS provider. (Personally, I use afraid.org 's free DNS, they rock!) > > *NOTE: While I used the word 'deprecated' above we currently have no solid > plans to do so, I am not saying they are already deprecated and we will work > with and communicate with the community a LOT before we move ahead with any > plans related to that. Additionally we expect more communication > alternatives to be in place before then. We are still supporting these > methods and as I mentioned in the first line we are currently investigating > the current email issues. > > - llHTTPRequest is the bomb. Really. It is lightweight and distributed. > The entire action happens on the host the region with the object is on. > There is no central server, no required presence registration. Lots and > lots of requests can be done at the same time with essentially no effect on > the rest of the simulator process. Yes there have been bugs before but > most of those are now resolved. It is much better to have an object ping a > server every second with an llHTTPRequest than it is use either XML-RPC or > email->lsl. Yeah, llHTTPRequest has been my savior since it was introduced; it makes coding PHP a breeze! Here's a little trick for y'all out there in PHP land: YOUR CODE GOES HERE Destroying Session.
"; // Wipe & Destroy session if asked. $_SESSION = array(); session_destroy();} // Wipe our Session Variables & Destroy our on-disk session file. ?> > > - Future communication methods: Zero Linden has talked about LSL > communication methods at his office hours and has some pretty interesting > stuff on his wiki page about it: > http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/Discussion#Incoming_HTTP > No one, to my knowledge, is currently working on this. That's sad to hear. I also submitted a proposal for llIMObject not too long ago ;) > > - Kelly > > Chance Unknown wrote: > email between objects is more robust and breaks with less frequency than the > xmlrpc interface. but, when your sim is constipated on the email, trying to > find someone to come fix it is a nightmare. and without support channels or > access to lindens. you can feel basically screwed. HTTPRequest() is the way > to go right now. Yeah, Live Help is dead, support@secondlife.com is dead; now all we have is a trouble ticket system and the MLs. Fortunately, we have a couple lindens who have an ear to the ground! Kudos! > > On 6/11/07, Jason Giglio wrote: > > Pear has a mail class that does all you want and more. Why would anyone > reinvent this wheel? > > > http://email.about.com/od/emailprogrammingtips/qt/et073006.htm > I like a class I can just drop in; some people on hosting don't really have access to PECL or PEAR. Swiftmailer's features: * Persistent connectivity improves performance * Connection types selected by user - extendable * Complete header control with RFC 2822 requirements handled * Internationalization support (i18n) * Connection redundancy support * Load balancing and/or throttling support * SSL & TLS Support - for Gmail servers * Embedded images or other file types * Full MIME 1.0 library included (create multipart messages, attachments etc) * Batch mail processing * Smart runtime caching (in small, self-maintained packets) * Send attachments of any size even with PHP's 8MB Memory Limit * Support for multiple attachments * Lossless protection against header injection (encode, don't strip) * Set message priority * Request read receipts * Pluggable SMTP authentication (LOGIN, PLAIN, MD5-CRAM, POP Before SMTP) * Anti-flooding support for servers with limits on emails-per-connection * Bandwidth monitor included * Extensive event-driven plugin support (easy to write) Plus the developer runs forums here: http://forums.devnetwork.net/viewforum.php?f=52 I left a message for him, and 15 minutes later I had a forum response from him. And Swiftmailer's updated regularly -- the last time the pear class had been updated was 2006-10-11, and PEAR very nicely tells me the following about it: Number of open bugs: 6 (84 total bugs) Average age of open bugs: 197 days Oldest open bug: 567 days Browsing the Swiftmailer forums, I've found a couple bugs which were solved in several hours. Fanatical support is ALWAYS something I look for. But thanks, Jason! -- Kami From chance at kalacia.com Mon Jun 11 13:55:30 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jun 11 13:55:34 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: <7c61ce730706111218n50199bd4l35ed9d6b4f9c4ee2@mail.gmail.com> References: <7c61ce730706110340t4a53d23fqda0a8c986b70092d@mail.gmail.com> <2925011a0706110854l4f33c4deoaa27b7a6cd5f7269@mail.gmail.com> <466D84C7.5030901@lindenlab.com> <7c61ce730706111218n50199bd4l35ed9d6b4f9c4ee2@mail.gmail.com> Message-ID: <2925011a0706111355i77fcd658m7404ad9a147b0b39@mail.gmail.com> the part of the system thats the turd is not the postfix mail server. its the locater service that identify the location of the sim a prim or object is in. think of how functional your friends online presence information has been in the past, and then apply the same general idea to location of prims.... the underlying infrastructure used for position location should have an enema. otoh -- llHTTPRequest(). those reach out and provide their presence to the website they are contacting; there is no layer that has to be used to locate in world presence information to direct the messages because basically, SL is polling. use the robust solution. shun the thing that gives you the grief. and then you too can dance on the swiss alps with julie andrews singing the -- i'd like to give the world a coke --- song. On 6/11/07, Erik Hill wrote: > > Couldnt you do some load balancing on the XML-RPC, multiple servers, even > round robin DNS could do better then a single server. > > SL really needs a realtime incoming communication method. > > My problem with useing HttpRequest is that its already being used in my > system .. just below 1 call per second on large scale deployments. Around 36 > objects (max) making HttRequests to get data into the system per sim. > > That dosent leave much time for any other httprequests, let alone others > that arnt from my system and that are in that sim and under the same user. > > The consept im useing is more on the lines of a thin client. Considering > LSL cant really becalled robust or fast. It would take me about 40 scripts > and several months to recreate what can be done in a hour in most other > languages, let alone data storage.. I need to store several mb's of > information, and have it acessable fast - something thats not vary easy to > do with LSL. > > So im porting every thing possable out of the server, and haveing only the > reactions in LSL. > > Im hoping to also deploy something like this in upwards of 50 sims. The > larger the scale the more important it becomes to get rid of unnessary data > calls, it becomes necessary load on my server, and the outbound connection > of SL.... > > Stable inbound connection would decrease the amount of load id have to put > on my server, and decrease the httprequest calls that result in nothing more > then saying 'Do i have a message?' > When it should just simpily be able to drop a message to whatever object > needs to get a message, saves bandwidth and resources, no extra sql querys > to see if the message was gotten or if it was sent or if there is a message > waiting. > > > > > > > > > > On 6/11/07, Kelly Washington wrote: > > > > We are currently (this minute, really) investigating emails from > > outside to LSL being broken. > > > > Some more comments about communication between LSL and outside SL: > > > > - All XML-RPC requests go through a central server. That 'server' is > > really an apache host running a C++ cgi. This cgi module looks up object > > presence info (what host it is on) based on the channel ID and routes the > > message accordingly. This server is consistently overloaded although I > > believe we upgraded it, again, recently. As a central point of failure it > > will never scale as well as needed, and should eventually be deprecated. > > > > - All email from outside goes through a single server that maps to > > lsl.secondlife.com. The emails are passed to a perl script that checks > > some edge cases and looks up presence info (what host the object is on) in > > backbone (the python service that hosts agent presence as well). However, > > objects only have presence in backbone if they have called llGetNextEmail at > > least once; if there is no presence info for the object or the object is not > > where we think it is then it is put in the database and retrieved the next > > time the object calls llGetNextEmail. However, like xml-rpc email from > > outside SL to LSL goes through a central server that will never scale as > > well as needed and will eventually need to be deprecated or changed. By > > changed I mean for example requiring region information in addition to > > object ID in the email address used. (Email from lsl->lsl cheats, is never > > really an email and avoids the problems mentioned above except the presence > > part. If presence is broken then lsl->lsl email will fail unless the > > objects are on the same sim) > > > > *NOTE: While I used the word 'deprecated' above we currently have no > > solid plans to do so, I am not saying they are already deprecated and we > > will work with and communicate with the community a LOT before we move ahead > > with any plans related to that. Additionally we expect more communication > > alternatives to be in place before then. We are still supporting these > > methods and as I mentioned in the first line we are currently investigating > > the current email issues. > > > > - llHTTPRequest is the bomb. Really. It is lightweight and > > distributed. The entire action happens on the host the region with the > > object is on. There is no central server, no required presence > > registration. Lots and lots of requests can be done at the same time with > > essentially no effect on the rest of the simulator process. Yes there have > > been bugs before but most of those are now resolved. It is much better to > > have an object ping a server every second with an llHTTPRequest than it is > > use either XML-RPC or email->lsl. > > > > - Future communication methods: Zero Linden has talked about LSL > > communication methods at his office hours and has some pretty interesting > > stuff on his wiki page about it: > > http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/Discussion#Incoming_HTTP > > > > No one, to my knowledge, is currently working on this. > > > > - Kelly > > > > Chance Unknown wrote: > > > > email between objects is more robust and breaks with less frequency than > > the xmlrpc interface. but, when your sim is constipated on the email, trying > > to find someone to come fix it is a nightmare. and without support channels > > or access to lindens. you can feel basically screwed. HTTPRequest() is the > > way to go right now. > > > > On 6/11/07, Erik Hill wrote: > > > > > > This dosent sound vary good > > > > > > XMLRPC is already vary screwed up. > > > > > > Ill be testing this within the next few days my self. > > > > > > I am currently working on an application that has tight integration > > > between a website and SL, that normally means some sort of communication. > > > While i plan to make use of email for a good minority of it, as its > > > only simi time sensitve, XMLPRC is a must for time sensitive data, such as > > > results when they interact with a web page, I need both up and working > > > correctly in order for my plans to completely work. > > > > > > I know from my current venders that rely on XMLRPC that its failor > > > rate is up in the 20-30% depending on the time of day. > > > From what i can figure out single threaded applications tell horror > > > stories about SL's XMLRPC functions, such as getting stuck infinity reading > > > an open port that never gets data. > > > >From what iv seen with the XMLRPC ill have to build a threaded > > > application that opens up multiple attempts at the same time to get data in > > > to SL, then shuts down after a thread receives data back from the object. > > > Its the only way I can see to get data into SL at a realtime speed, and > > > realtime is necessary in some cases. > > > > > > But yea, im next to getting into the email stuff for my project, so > > > testing its delay is short list of things to do. > > > > > > On 6/11/07, Kamilion < kamilion@gmail.com> wrote: > > > > > > > > Holy crap. This is far worse than I expected. > > > > I didn't want to use XMLRPC because I figured that a single point of > > > > failure and lag of a couple minutes wasn't worth it. > > > > > > > > >From what I knew, postfix ran on every simulator; so it was more > > > > distributed and hopefully more robust. > > > > > > > > Now it looks like something is SERIOUSLY wrong in email land. > > > > > > > > Last I knew, Michael, James, and Charity Linden were messing with > > > > postfix back in april's blog post. > > > > > > > > Now -- What can we do about this? I'm glad I said something, > > > > otherwise > > > > this might have been a quiet annoyance. > > > > > > > > I know postfix can be blazingly fast, I used to use it on my own > > > > domain before moving over to Google Apps for your Domain, So there's > > > > obviously some kind of misconfiguration somewhere. > > > > > > > > If you feel like sharing; I'd like a copy of that PHP and LSL you > > > > use; > > > > because this is EXACTLY the sort of setup I'm trying to achieve (PHP > > > > Mail to LSL). > > > > > > > > So far, I've had to bash at PHP to even get it to talk to Google's > > > > AfyD server. > > > > Google uses SSL/TLS *ONLY* for SMTP auth, so php's mail() function > > > > doesn't work so well. > > > > > > > > After doing exhaustive research, I came up with the following > > > > options: > > > > http://www.bytewize.com/linux/BetterSMTPhelp.php > > > > BetterSMTP, a phpbb2.x mod to use the SquirrelMail SMTP classes. > > > > Looked to be broken and forum posts about it were awash with PLZ > > > > HELP. > > > > No good. > > > > http://www.vulgarisoip.com/?p=17 > > > > PHPGmailer, a Cut & Paste job on PHPMailer to kitbash it into using > > > > TLSSTART. Also no good, PHPMailer isn't maintained anymore and this > > > > kitbash comes up with SSL errors on connection close. > > > > > > > > The winner: > > > > Still poking along, I ran across this bug report for Wordpress: > > > > http://trac.wordpress.org/ticket/4326 #4326 (WP can't use Google > > > > Apps For Your Domain email accounts.) > > > > Which linked me here: > > > > http://www.shiftthis.net/wordpress-swift-smtp-plugin/ > > > > Which linked me here: > > > > http://www.swiftmailer.org/ > > > > "Swift is a free feature-rich PHP Mailer -- Swift is a fully OOP > > > > library for sending e-mails from PHP websites and applications. It > > > > does not rely on PHP's native mail() function which is known for > > > > using > > > > high server resources when sending multiple emails. Instead, Swift > > > > communicates directly with an SMTP server or a MTA binary to send > > > > mail > > > > quickly and efficiently." > > > > > > > > Score! > > > > One of the features it lists: "SSL & TLS Support - for Gmail > > > > servers" > > > > > > > > So, here's how I hacked together a nice little test script: > > > > > > > > > > > require_once "swiftmailer/Swift.php"; > > > > require_once "swiftmailer/Swift/Connection/SMTP.php"; > > > > > > > > echo "Starting...\n
\n
\n"; > > > > > > > > // Create a SMTP connection handler (Google Apps for your Domain) > > > > $smtp = new Swift_Connection_SMTP(" smtp.googlemail.com", > > > > Swift_Connection_SMTP::PORT_SECURE, Swift_Connection_SMTP::ENC_TLS); > > > > > > > > $smtp->setUsername("phpsmtp@sllabs.com"); > > > > $smtp->setpassword("smtpmail"); > > > > > > > > // Create the Swift object interface > > > > $swift =& new Swift($smtp); > > > > > > > > $to = "513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com "; > > > > $subject = "Testing my subject"; > > > > $message = "A very long\n and drawn out\n message.\n\nRar!"; > > > > > > > > //Create the message > > > > $swiftmessage =& new Swift_Message($subject, $message); > > > > > > > > //Now check if Swift actually sends it > > > > if ($swift->send($swiftmessage, $to, " phpsmtp@sllabs.com")) > > > > { echo "Sent"; } else { echo "Failed"; } > > > > > > > > ?> > > > > > > > > > > > > Here's a sample result: > > > > > > > > Delivered-To: kamilion@gmail.com > > > > Received: by 10.100.165.16 with SMTP id n16cs242953ane; > > > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > > > Received: by 10.64.204.19 with SMTP id b19mr8395228qbg.1181531640038 > > > > ; > > > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > > > Return-Path: > > > > Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.225 > > > > ]) > > > > by mx.google.com with ESMTP id > > > > q14si5481907qbq.2007.06.10.20.13.59; > > > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > > > Received-SPF: neutral (google.com : 72.14.204.225 is neither > > > > permitted > > > > nor denied by best guess record for domain of phpsmtp@sllabs.com) > > > > Received: by qb-out-0506.google.com with SMTP id q12so1717954qba > > > > for ; Sun, 10 Jun 2007 20:13:59 -0700 > > > > (PDT) > > > > Received: by 10.115.110.6 with SMTP id n6mr5060449wam.1181531638487; > > > > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > > > > Return-Path: > > > > Received: from ?216.218.196.73? ( [ 216.218.196.73 ]) > > > > by mx.google.com with ESMTP id > > > > n38sm6862970wag.2007.06.10.20.13.57 > > > > (version=SSLv3 cipher=OTHER); > > > > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > > > > Return-Path: < phpsmtp@sllabs.com> > > > > To: Kamilion@gmail.com > > > > From: phpsmtp@sllabs.com > > > > Reply-To: phpsmtp@sllabs.com > > > > Subject: My subject > > > > Date: Sun, 10 Jun 2007 20:15:09 -0700 > > > > X-LibVersion: 3.2.6 > > > > MIME-Version: 1.0 > > > > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > > > Content-Transfer-Encoding: 8bit > > > > Message-ID: <20070611031509.22850.1036293226.swift@vendor.sllabs.com> > > > > > > > > My body > > > > > > > > > > > > > > > > So, anyway. > > > > External Domain Email's obviously broked somehow. > > > > Included some data that could be useful for others. > > > > > > > > Harold, I've got land in multiple mainland and private sims. If you > > > > feel like it, I can set up some additional prims to take multiple > > > > metrics, and see if there's a correlation. > > > > > > > > sllabs.com is run from a Gentoo VPS hosted by atarack.com in > > > > Hurricane > > > > Electric's Fremont-II datacenter, roughly 2ms from the main LL > > > > datacenter in SF. > > > > > > > > If you should decide to decline sharing your code, heck, I'll bash > > > > up > > > > a similar PHP&LSL script and share it in this thread, just because I > > > > wanna get to the bottom of this; and hopefully share as much data as > > > > I > > > > can with the lindens so they can fix it properly. > > > > > > > > -- Graham Cantin (Kamilion Schnook) > > > > > > > > (sorry for the longwinded mails, but this stuff's archived, so it > > > > may > > > > help out others in the future who are browsing the SLDev archives or > > > > > > > > the Google Coop search :) > > > > > > > > > > > > > > > > On 6/10/07, Harold Brown wrote: > > > > > Welcome to the hell of trying to use external -> internal E-Mail > > > > with SL. > > > > > > > > > > For a nice history of the reliability of external -> internal > > > > E-Mail from > > > > > May 2 -> current date, you can view my test log at this URL: > > > > > http://www.rpgstats.com/SL/maillog.txt > > > > > > > > > > If you would like to review the history from February8 -> May2 it > > > > is > > > > > available here: > > > > > http://www.rpgstats.com/SL/maillog1.txt > > > > > > > > > > As of the time I'm replying there seems to be about 4 hour delay > > > > in e-mail > > > > > processing for SL... There have been delays up to around 24 > > > > hours. > > > > > > > > > > For those interested in how the test works. > > > > > > > > > > I have an LSL script running on my sim that once every 30 minutes > > > > requests a > > > > > PHP script on my webserver to send an e-mail. The PHP script > > > > generates a > > > > > random string for the subject and logs the time that it sends to > > > > the > > > > > maillog.txt file. The LSL script checks every 5 seconds for a new > > > > E-Mail, > > > > > and upon receiving one it tells the PHP script on the server that > > > > it > > > > > recieved an E-Mail and what the subject was. The PHP script then > > > > logs this > > > > > information as well. > > > > > > > > > > On 6/10/07, Kamilion wrote: > > > > > > > > > > > > I'm having some problems with objects and receiving email from > > > > outside > > > > > > of the secondlife.com domain -- They seem to be failing without > > > > an > > > > > > error or bounce message, and the object never appears to receive > > > > the > > > > > > email. I was hoping someone could look into this or point > > > > someone who > > > > > > can at it. I submitted a ticket in the new support system, > > > > TicketID > > > > > > 4051-4201708. > > > > > > > > > > > > Synopsis: > > > > > > Object Sending Email (Working) > > > > > > Object Receiving Email from another Object (Working) > > > > > > Object Receiving Email from Google Apps for your Domain hosted > > > > system: > > > > > > ( sllabs.com) (NOT WORKING) > > > > > > Object Receiving Email from Google Mail ( gmail.com) (NOT > > > > WORKING) > > > > _______________________________________________ > > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > ------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070611/3bbaeb92/attachment-0001.htm From chance at kalacia.com Mon Jun 11 14:04:24 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jun 11 14:04:28 2007 Subject: [sldev] [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: <7c61ce730706111218n50199bd4l35ed9d6b4f9c4ee2@mail.gmail.com> References: <7c61ce730706110340t4a53d23fqda0a8c986b70092d@mail.gmail.com> <2925011a0706110854l4f33c4deoaa27b7a6cd5f7269@mail.gmail.com> <466D84C7.5030901@lindenlab.com> <7c61ce730706111218n50199bd4l35ed9d6b4f9c4ee2@mail.gmail.com> Message-ID: <2925011a0706111404v3ef0df31u777db2cbaf6f802c@mail.gmail.com> you can move roughly 2K of information per request. so lump it up and reduce your calls. OR put one llHTTPRequest() per prim and make a multi prim object. this allows you to move a maximum of 3MB/sec (15000 prims in a sim x 2KB /sec) data into or out of SL per sim. as these type of calls are throttled to basically one per second per prim. there are examples in the forums of how to multithread communications which gets around the artificial 20 second delay for the use of llEmail() to perform communications between objects. the same basic idea can be applied to bond llHTTPRequests() together in different prims linked within the same object. if your design doesn't currently scale right, start out by multi threading it so that a single prim is responsible for each of the different types of requests you generate to the web. On 6/11/07, Erik Hill wrote: > > Couldnt you do some load balancing on the XML-RPC, multiple servers, even > round robin DNS could do better then a single server. > > SL really needs a realtime incoming communication method. > > My problem with useing HttpRequest is that its already being used in my > system .. just below 1 call per second on large scale deployments. Around 36 > objects (max) making HttRequests to get data into the system per sim. > > That dosent leave much time for any other httprequests, let alone others > that arnt from my system and that are in that sim and under the same user. > > The consept im useing is more on the lines of a thin client. Considering > LSL cant really becalled robust or fast. It would take me about 40 scripts > and several months to recreate what can be done in a hour in most other > languages, let alone data storage.. I need to store several mb's of > information, and have it acessable fast - something thats not vary easy to > do with LSL. > > So im porting every thing possable out of the server, and haveing only the > reactions in LSL. > > Im hoping to also deploy something like this in upwards of 50 sims. The > larger the scale the more important it becomes to get rid of unnessary data > calls, it becomes necessary load on my server, and the outbound connection > of SL.... > > Stable inbound connection would decrease the amount of load id have to put > on my server, and decrease the httprequest calls that result in nothing more > then saying 'Do i have a message?' > When it should just simpily be able to drop a message to whatever object > needs to get a message, saves bandwidth and resources, no extra sql querys > to see if the message was gotten or if it was sent or if there is a message > waiting. > > > > > > > > > > On 6/11/07, Kelly Washington wrote: > > > > We are currently (this minute, really) investigating emails from > > outside to LSL being broken. > > > > Some more comments about communication between LSL and outside SL: > > > > - All XML-RPC requests go through a central server. That 'server' is > > really an apache host running a C++ cgi. This cgi module looks up object > > presence info (what host it is on) based on the channel ID and routes the > > message accordingly. This server is consistently overloaded although I > > believe we upgraded it, again, recently. As a central point of failure it > > will never scale as well as needed, and should eventually be deprecated. > > > > - All email from outside goes through a single server that maps to > > lsl.secondlife.com. The emails are passed to a perl script that checks > > some edge cases and looks up presence info (what host the object is on) in > > backbone (the python service that hosts agent presence as well). However, > > objects only have presence in backbone if they have called llGetNextEmail at > > least once; if there is no presence info for the object or the object is not > > where we think it is then it is put in the database and retrieved the next > > time the object calls llGetNextEmail. However, like xml-rpc email from > > outside SL to LSL goes through a central server that will never scale as > > well as needed and will eventually need to be deprecated or changed. By > > changed I mean for example requiring region information in addition to > > object ID in the email address used. (Email from lsl->lsl cheats, is never > > really an email and avoids the problems mentioned above except the presence > > part. If presence is broken then lsl->lsl email will fail unless the > > objects are on the same sim) > > > > *NOTE: While I used the word 'deprecated' above we currently have no > > solid plans to do so, I am not saying they are already deprecated and we > > will work with and communicate with the community a LOT before we move ahead > > with any plans related to that. Additionally we expect more communication > > alternatives to be in place before then. We are still supporting these > > methods and as I mentioned in the first line we are currently investigating > > the current email issues. > > > > - llHTTPRequest is the bomb. Really. It is lightweight and > > distributed. The entire action happens on the host the region with the > > object is on. There is no central server, no required presence > > registration. Lots and lots of requests can be done at the same time with > > essentially no effect on the rest of the simulator process. Yes there have > > been bugs before but most of those are now resolved. It is much better to > > have an object ping a server every second with an llHTTPRequest than it is > > use either XML-RPC or email->lsl. > > > > - Future communication methods: Zero Linden has talked about LSL > > communication methods at his office hours and has some pretty interesting > > stuff on his wiki page about it: > > http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/Discussion#Incoming_HTTP > > > > No one, to my knowledge, is currently working on this. > > > > - Kelly > > > > Chance Unknown wrote: > > > > email between objects is more robust and breaks with less frequency than > > the xmlrpc interface. but, when your sim is constipated on the email, trying > > to find someone to come fix it is a nightmare. and without support channels > > or access to lindens. you can feel basically screwed. HTTPRequest() is the > > way to go right now. > > > > On 6/11/07, Erik Hill wrote: > > > > > > This dosent sound vary good > > > > > > XMLRPC is already vary screwed up. > > > > > > Ill be testing this within the next few days my self. > > > > > > I am currently working on an application that has tight integration > > > between a website and SL, that normally means some sort of communication. > > > While i plan to make use of email for a good minority of it, as its > > > only simi time sensitve, XMLPRC is a must for time sensitive data, such as > > > results when they interact with a web page, I need both up and working > > > correctly in order for my plans to completely work. > > > > > > I know from my current venders that rely on XMLRPC that its failor > > > rate is up in the 20-30% depending on the time of day. > > > From what i can figure out single threaded applications tell horror > > > stories about SL's XMLRPC functions, such as getting stuck infinity reading > > > an open port that never gets data. > > > >From what iv seen with the XMLRPC ill have to build a threaded > > > application that opens up multiple attempts at the same time to get data in > > > to SL, then shuts down after a thread receives data back from the object. > > > Its the only way I can see to get data into SL at a realtime speed, and > > > realtime is necessary in some cases. > > > > > > But yea, im next to getting into the email stuff for my project, so > > > testing its delay is short list of things to do. > > > > > > On 6/11/07, Kamilion < kamilion@gmail.com> wrote: > > > > > > > > Holy crap. This is far worse than I expected. > > > > I didn't want to use XMLRPC because I figured that a single point of > > > > failure and lag of a couple minutes wasn't worth it. > > > > > > > > >From what I knew, postfix ran on every simulator; so it was more > > > > distributed and hopefully more robust. > > > > > > > > Now it looks like something is SERIOUSLY wrong in email land. > > > > > > > > Last I knew, Michael, James, and Charity Linden were messing with > > > > postfix back in april's blog post. > > > > > > > > Now -- What can we do about this? I'm glad I said something, > > > > otherwise > > > > this might have been a quiet annoyance. > > > > > > > > I know postfix can be blazingly fast, I used to use it on my own > > > > domain before moving over to Google Apps for your Domain, So there's > > > > obviously some kind of misconfiguration somewhere. > > > > > > > > If you feel like sharing; I'd like a copy of that PHP and LSL you > > > > use; > > > > because this is EXACTLY the sort of setup I'm trying to achieve (PHP > > > > Mail to LSL). > > > > > > > > So far, I've had to bash at PHP to even get it to talk to Google's > > > > AfyD server. > > > > Google uses SSL/TLS *ONLY* for SMTP auth, so php's mail() function > > > > doesn't work so well. > > > > > > > > After doing exhaustive research, I came up with the following > > > > options: > > > > http://www.bytewize.com/linux/BetterSMTPhelp.php > > > > BetterSMTP, a phpbb2.x mod to use the SquirrelMail SMTP classes. > > > > Looked to be broken and forum posts about it were awash with PLZ > > > > HELP. > > > > No good. > > > > http://www.vulgarisoip.com/?p=17 > > > > PHPGmailer, a Cut & Paste job on PHPMailer to kitbash it into using > > > > TLSSTART. Also no good, PHPMailer isn't maintained anymore and this > > > > kitbash comes up with SSL errors on connection close. > > > > > > > > The winner: > > > > Still poking along, I ran across this bug report for Wordpress: > > > > http://trac.wordpress.org/ticket/4326 #4326 (WP can't use Google > > > > Apps For Your Domain email accounts.) > > > > Which linked me here: > > > > http://www.shiftthis.net/wordpress-swift-smtp-plugin/ > > > > Which linked me here: > > > > http://www.swiftmailer.org/ > > > > "Swift is a free feature-rich PHP Mailer -- Swift is a fully OOP > > > > library for sending e-mails from PHP websites and applications. It > > > > does not rely on PHP's native mail() function which is known for > > > > using > > > > high server resources when sending multiple emails. Instead, Swift > > > > communicates directly with an SMTP server or a MTA binary to send > > > > mail > > > > quickly and efficiently." > > > > > > > > Score! > > > > One of the features it lists: "SSL & TLS Support - for Gmail > > > > servers" > > > > > > > > So, here's how I hacked together a nice little test script: > > > > > > > > > > > require_once "swiftmailer/Swift.php"; > > > > require_once "swiftmailer/Swift/Connection/SMTP.php"; > > > > > > > > echo "Starting...\n
\n
\n"; > > > > > > > > // Create a SMTP connection handler (Google Apps for your Domain) > > > > $smtp = new Swift_Connection_SMTP(" smtp.googlemail.com", > > > > Swift_Connection_SMTP::PORT_SECURE, Swift_Connection_SMTP::ENC_TLS); > > > > > > > > $smtp->setUsername("phpsmtp@sllabs.com"); > > > > $smtp->setpassword("smtpmail"); > > > > > > > > // Create the Swift object interface > > > > $swift =& new Swift($smtp); > > > > > > > > $to = "513d65af-98e3-f2ef-db09-9a112eca5d28@lsl.secondlife.com "; > > > > $subject = "Testing my subject"; > > > > $message = "A very long\n and drawn out\n message.\n\nRar!"; > > > > > > > > //Create the message > > > > $swiftmessage =& new Swift_Message($subject, $message); > > > > > > > > //Now check if Swift actually sends it > > > > if ($swift->send($swiftmessage, $to, " phpsmtp@sllabs.com")) > > > > { echo "Sent"; } else { echo "Failed"; } > > > > > > > > ?> > > > > > > > > > > > > Here's a sample result: > > > > > > > > Delivered-To: kamilion@gmail.com > > > > Received: by 10.100.165.16 with SMTP id n16cs242953ane; > > > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > > > Received: by 10.64.204.19 with SMTP id b19mr8395228qbg.1181531640038 > > > > ; > > > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > > > Return-Path: > > > > Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.225 > > > > ]) > > > > by mx.google.com with ESMTP id > > > > q14si5481907qbq.2007.06.10.20.13.59; > > > > Sun, 10 Jun 2007 20:14:00 -0700 (PDT) > > > > Received-SPF: neutral (google.com : 72.14.204.225 is neither > > > > permitted > > > > nor denied by best guess record for domain of phpsmtp@sllabs.com) > > > > Received: by qb-out-0506.google.com with SMTP id q12so1717954qba > > > > for ; Sun, 10 Jun 2007 20:13:59 -0700 > > > > (PDT) > > > > Received: by 10.115.110.6 with SMTP id n6mr5060449wam.1181531638487; > > > > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > > > > Return-Path: > > > > Received: from ?216.218.196.73? ( [ 216.218.196.73 ]) > > > > by mx.google.com with ESMTP id > > > > n38sm6862970wag.2007.06.10.20.13.57 > > > > (version=SSLv3 cipher=OTHER); > > > > Sun, 10 Jun 2007 20:13:58 -0700 (PDT) > > > > Return-Path: < phpsmtp@sllabs.com> > > > > To: Kamilion@gmail.com > > > > From: phpsmtp@sllabs.com > > > > Reply-To: phpsmtp@sllabs.com > > > > Subject: My subject > > > > Date: Sun, 10 Jun 2007 20:15:09 -0700 > > > > X-LibVersion: 3.2.6 > > > > MIME-Version: 1.0 > > > > Content-Type: text/plain; charset=iso-8859-1; format=flowed > > > > Content-Transfer-Encoding: 8bit > > > > Message-ID: <20070611031509.22850.1036293226.swift@vendor.sllabs.com> > > > > > > > > My body > > > > > > > > > > > > > > > > So, anyway. > > > > External Domain Email's obviously broked somehow. > > > > Included some data that could be useful for others. > > > > > > > > Harold, I've got land in multiple mainland and private sims. If you > > > > feel like it, I can set up some additional prims to take multiple > > > > metrics, and see if there's a correlation. > > > > > > > > sllabs.com is run from a Gentoo VPS hosted by atarack.com in > > > > Hurricane > > > > Electric's Fremont-II datacenter, roughly 2ms from the main LL > > > > datacenter in SF. > > > > > > > > If you should decide to decline sharing your code, heck, I'll bash > > > > up > > > > a similar PHP&LSL script and share it in this thread, just because I > > > > wanna get to the bottom of this; and hopefully share as much data as > > > > I > > > > can with the lindens so they can fix it properly. > > > > > > > > -- Graham Cantin (Kamilion Schnook) > > > > > > > > (sorry for the longwinded mails, but this stuff's archived, so it > > > > may > > > > help out others in the future who are browsing the SLDev archives or > > > > > > > > the Google Coop search :) > > > > > > > > > > > > > > > > On 6/10/07, Harold Brown wrote: > > > > > Welcome to the hell of trying to use external -> internal E-Mail > > > > with SL. > > > > > > > > > > For a nice history of the reliability of external -> internal > > > > E-Mail from > > > > > May 2 -> current date, you can view my test log at this URL: > > > > > http://www.rpgstats.com/SL/maillog.txt > > > > > > > > > > If you would like to review the history from February8 -> May2 it > > > > is > > > > > available here: > > > > > http://www.rpgstats.com/SL/maillog1.txt > > > > > > > > > > As of the time I'm replying there seems to be about 4 hour delay > > > > in e-mail > > > > > processing for SL... There have been delays up to around 24 > > > > hours. > > > > > > > > > > For those interested in how the test works. > > > > > > > > > > I have an LSL script running on my sim that once every 30 minutes > > > > requests a > > > > > PHP script on my webserver to send an e-mail. The PHP script > > > > generates a > > > > > random string for the subject and logs the time that it sends to > > > > the > > > > > maillog.txt file. The LSL script checks every 5 seconds for a new > > > > E-Mail, > > > > > and upon receiving one it tells the PHP script on the server that > > > > it > > > > > recieved an E-Mail and what the subject was. The PHP script then > > > > logs this > > > > > information as well. > > > > > > > > > > On 6/10/07, Kamilion wrote: > > > > > > > > > > > > I'm having some problems with objects and receiving email from > > > > outside > > > > > > of the secondlife.com domain -- They seem to be failing without > > > > an > > > > > > error or bounce message, and the object never appears to receive > > > > the > > > > > > email. I was hoping someone could look into this or point > > > > someone who > > > > > > can at it. I submitted a ticket in the new support system, > > > > TicketID > > > > > > 4051-4201708. > > > > > > > > > > > > Synopsis: > > > > > > Object Sending Email (Working) > > > > > > Object Receiving Email from another Object (Working) > > > > > > Object Receiving Email from Google Apps for your Domain hosted > > > > system: > > > > > > ( sllabs.com) (NOT WORKING) > > > > > > Object Receiving Email from Google Mail ( gmail.com) (NOT > > > > WORKING) > > > > _______________________________________________ > > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > ------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070611/513f23a7/attachment-0001.htm From soft at softnoel.org Mon Jun 11 14:23:07 2007 From: soft at softnoel.org (Soft Noel) Date: Mon Jun 11 14:23:08 2007 Subject: [sldev] Wiki Formatting In-Reply-To: <466DB287.1030407@blueflash.cc> References: <466DB287.1030407@blueflash.cc> Message-ID: <9e6e5c9e0706111423u381d8eb6m3d1302cec049a470@mail.gmail.com> On 6/11/07, Nicholaz Beresford wrote: > > Is there an "official" way to insert forced blank lines into the wiki? > I noticed with the longer documents (like the VS2003 / VS2005 instructions) > that editing a section (the [edit] link next to a header) removes empty > lines and pushes the headings very close to the previous paragraph. > > The obvioius fix would be to add top margin to the headers in css files, > but for the compile instructions, something like
or   would > do fine as far as I'm concerned. I've seen
used quite a bit, and nobody's chewed me out for using it myself! From secret.argent at gmail.com Mon Jun 11 14:50:03 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 11 14:50:05 2007 Subject: [sldev] Re: [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: <20070611205535.AC93C41B10C@stupor.lindenlab.com> References: <20070611205535.AC93C41B10C@stupor.lindenlab.com> Message-ID: > Technically, you guys should be able to bring a second server online > called, for instance, xmlrpc2. Or just a second A record for xmlrpc pointing to the same IP address. The DNS server will return the records permuted in a round-robin fashion so that different sites will contact different servers. From chance at kalacia.com Mon Jun 11 15:06:50 2007 From: chance at kalacia.com (Chance Unknown) Date: Mon Jun 11 15:06:52 2007 Subject: [sldev] Re: [LSL] [POSTFIX PROBLEMS] Object Email Receive from external domain problems In-Reply-To: References: <20070611205535.AC93C41B10C@stupor.lindenlab.com> Message-ID: <2925011a0706111506s5f0516bn504e2703b70aa0f5@mail.gmail.com> nice work. the email log jam on my sim came loose, i just got a SMS message to my phone im pretty sure was generated a couple weeks ago by the monitoring prim. i highly suggest use of the llHTTPRequest() functions if you cannot live with a latency of message delivery of up to and including 2 weeks. lindens: thanks for getting it unconstipated btw. maybe some proactive approaches to monitor the depth of mail queues? thanks On 6/11/07, Argent Stonecutter wrote: > > > Technically, you guys should be able to bring a second server online > > called, for instance, xmlrpc2. > > Or just a second A record for xmlrpc pointing to the same IP address. > The DNS server will return the records permuted in a round-robin > fashion so that different sites will contact different servers. > > _______________________________________________ > 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/20070611/9aede1c1/attachment.htm From seg at haxxed.com Mon Jun 11 17:02:50 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Jun 11 17:02:39 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <46677B4A.1010105@gmail.com> References: <46677B4A.1010105@gmail.com> Message-ID: <1181606570.9159.17.camel@localhost> On Thu, 2007-06-07 at 13:28 +1000, Tateru Nino wrote: > What if.... on logout, the viewer wrote out a list of currently loaded > texture assets - the index of the memory cache? Actually, after going over the audio engine, I'm beginning to think caching uncompressed textures on the filesystem really is a good idea. The audio engine currently caches uncompressed sounds on disk, but only as long as the session. Don't cache them in RAM at all, any more than necessary. Let the filesystem block cache do its job. I can't speak for windows, but on unix systems this would be quite efficient and effective. -------------- 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/20070611/f68eff24/attachment.pgp From anthony at lindenlab.com Mon Jun 11 18:36:32 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Mon Jun 11 18:34:43 2007 Subject: [sldev] Source release for 1.17.0.11 In-Reply-To: <4668965B.8080400@lindenlab.com> References: <4668965B.8080400@lindenlab.com> Message-ID: <466DF8A0.1000600@lindenlab.com> Hello everyone, We should be branching tomorrow to Branch_1-17-0. This is just an interim source drop for posterity. It does contain some updates, but nothing has been put into release notes, sorry about that lack. It'll be corrected with the branching. 1.17.0.11 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_1-17-0-11 Release notes: No new release notes made for this version, this is a quick release before the branch tomorrow. Checksums: 7b72d88ad2a7a723c39b603b26ba94f5 slviewer-darwin-libs-1.17.0.11.tar.gz d03875948ee4dcc37dca71cfc00237fc slviewer-linux-libs-1.17.0.11.tar.gz 782470452def67786243fafc45f1cb5d slviewer-src-1.17.0.11.tar.gz ba0f5aa7956629cf4a5ad559e03b1de1 slviewer-artwork-1.17.0.11.zip 09661fd6f465449fff4fce5b61301bf4 slviewer-src-1.17.0.11.zip a15721c01a810f8b5105c30b2769252e slviewer-win32-libs-1.17.0.11.zip Enjoy. -Anthony From tateru.nino at gmail.com Mon Jun 11 19:02:54 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Mon Jun 11 19:03:01 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <1181606570.9159.17.camel@localhost> References: <46677B4A.1010105@gmail.com> <1181606570.9159.17.camel@localhost> Message-ID: <466DFECE.9080805@gmail.com> Callum Lerwick wrote: > On Thu, 2007-06-07 at 13:28 +1000, Tateru Nino wrote: > >> What if.... on logout, the viewer wrote out a list of currently loaded >> texture assets - the index of the memory cache? >> > > Actually, after going over the audio engine, I'm beginning to think > caching uncompressed textures on the filesystem really is a good idea. > The audio engine currently caches uncompressed sounds on disk, but only > as long as the session. > > Don't cache them in RAM at all, any more than necessary. Let the > filesystem block cache do its job. I can't speak for windows, but on > unix systems this would be quite efficient and effective. > You mean, basically, mmap() the whole lot and be done? -- Tateru Nino http://dwellonit.blogspot.com/ From okumoto at ucsd.edu Tue Jun 12 02:30:51 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Tue Jun 12 02:30:55 2007 Subject: [sldev] updating "Compile the view (Linux)" on the wiki Message-ID: <466E67CB.7000707@ucsd.edu> I'm trying to update the wiki page on how to build from source he secondlife client. Can people look it over and see if the changes that I made, make sense? Max From bos at lindenlab.com Tue Jun 12 09:41:21 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Jun 12 09:43:08 2007 Subject: [sldev] Compiling under VS2005 In-Reply-To: <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> References: <466A7540.8040906@blueflash.cc> <1ei4fr90skwk73c15YrQ9zL1.alissa_sabre@yahoo.co.jp> Message-ID: <466ECCB1.6070309@lindenlab.com> alissa_sabre@yahoo.co.jp wrote: > I agree with you, but the problem is that Lindens never maintain > *_vc8.vcproj files. That's right. We use VS2003 internally. > A regident can create a working set of > _vc8.vcproj and submit it to Linden Lab, but when the next release > comes out, the release may contain new source files. If it's any use, you can send in patches against the _vc8 project files and we'll take them. At least then they'll only be a little out of date, instead of a lot. Here is the agenda and minutes of the previous Bug Triage: https://wiki.secondlife.com/wiki/Bug_triage/2007-06-11 We successfully completed the agenda! =) WOOT! Nice work everyone! Let's get started on the next week. I'm gonna influence this one a little with the Brown Act, so we can make this a little more robust. Rob Linden has already asked about a focus on components, and we can do that. I'll also ask for anyone's submission they feel needs attention. If you notice that stats on the previous agenda, we have a lot of items to work through. The main thing I'm concerned here about is the cut-off date of submissions. Since the Bug Triage is on Monday, the cut-off date is Saturday. It is best to have those submissions in on or before Friday. Here is the current agenda, and I make the first call-out to get it in order. https://wiki.secondlife.com/wiki/Bug_triage/Agenda For this agenda, out of all the components out there -- all are welcome -- yet I like to see at least a few of the critical issues, then a focus on the UI, then especially the details of the build process. Complete patches are bonus! Please, note the age and votes that issues have. If the issue is stale and you don't know what to do with it, go ahead and put it on the list under the section titled Stale. First Call! Dzonatas -- From able.whitman at gmail.com Tue Jun 12 12:52:15 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jun 12 12:52:27 2007 Subject: [sldev] Extending the Mute List Message-ID: <7b3a84fb0706121252t7dd4443y2a2fe815361c0d41@mail.gmail.com> While I was investigating how to extend the viewer's mute list functionality, I discovered that the format for the mute list that the viewer expects is actually different than the format that the service provides. This hasn't caused a problem yet, but only because the viewer code which parses the mute list just happens to do the right thing, even though it is broken. The problem is that this bug precludes the viewer from making use of the (currently unused) MuteFlags field in the mute entry list, since if this field has a value other than the default of zero, the mute list parser will be return an invalid value for the entry's MuteType field. It's sort of an odd, subtle bug, so I'll relegate the details to the actual JIRA issues: SVC-309: Mute list files returned by the service are malformed https://jira.secondlife.com/browse/SVC-309 VWR-1170: LLMuteList::loadFromFile() improperly parses the mute list returned from the service https://jira.secondlife.com/browse/VWR-1170 I'm working on a wiki entry detailing how the mute list works in the viewer, which I will (hopefully) post later today when it is done. --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070612/2c68bcc0/attachment.htm From blakar at gmail.com Tue Jun 12 13:31:53 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Jun 12 13:31:56 2007 Subject: [sldev] Processor Optimizations (Windows) In-Reply-To: <466646D5.4050500@lindenlab.com> References: <466324A5.2040908@blueflash.cc> <466331B2.5000506@dzonux.net> <46641A57.6000409@blueflash.cc> <466646D5.4050500@lindenlab.com> Message-ID: <7992d0d60706121331j1bf5034bw8ad85a3d4b41a3f6@mail.gmail.com> James, any news on those CPU statistics? :) It would be really useful to get a good idea of what people are using. If we see that nearly all chips have SSE we could use some SSE on a conditional basis if the SSE code including conditions is faster than the generic code. This'll off course make execution on non-SSE a bit slower as they'll still get to run generic code + branching. lltrunc() is a good example. The specially crafted fast code still gets beat by a normal cast in VS2005 on Athlon 64 XP. VS2005 does seem to use SSE for this regardless of whether you've enabled it but it proves that current CPU's don't like old tricks that much. Some of the easy things we can do is optimisation for the many calls that have been lazily written. llceil code for example could be replaced by: return -llfloor(-f); In that way it'll just take the (optimised) code from llfloor and add 2 sign changes. On Athlon 64 XP the above code results in 3x the speed compared to using C++'s ceil. I know it's not called a lot it's not hard to make it better. There should be tons of changes possible in the math code and several of those functions do get called quite a lot. Advantage is that they are small and hence it's easy to do some regression testing on the code snippets outside the SL source tree. On 6/6/07, James Cook wrote: > > I was just running around sims with all stuff enabled (I really don't > > want to spend much time on this as it's unlikely that anything like > > a major change in project settings will ever make it into the SL build), > > Don't give up on compiler options! I would happily accept a patch that > changed compiler optimization options, especially if there were > benchmark results to demonstrate the benefits. > > Keep in mind though that we have to support many different processor and > OS combinations. Steve may have more recent stats on what chips our > users are actually using, but I would be a little nervous, for example, > deciding to drop support for PIII chips without a solid benchmark. We > don't really want to be doing multiple Windows builds internally. > > I would be curious about benchmarks where SSE code generation was turned > on for all files. > > James > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nicholaz at blueflash.cc Tue Jun 12 17:11:30 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 12 17:11:40 2007 Subject: [sldev] Optimization via _set_sbh_threshold Message-ID: <466F3632.9070209@blueflash.cc> Through a wild series of hops while researching some crash dumps I stumbled over _set_sbh_threshold which seems to enable heap routines optimzed for many small allocations (just google for it). Did anyone ever try this so far? Given what I saw from my memory leak stuff, LL could be a nice candidate for that. Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Tue Jun 12 17:41:02 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 12 17:41:14 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <466F3632.9070209@blueflash.cc> References: <466F3632.9070209@blueflash.cc> Message-ID: <466F3D1E.605@blueflash.cc> Hi! I just added a _set_sbh_threshold(1016); near the top of WinMain and in one situation it was like WOHAA! in others I couldn't make out much difference. But if someone has test procedures or more experience with performance testing, it may be worth some efforts. I'll do a check tomorrow with counting allocs of various sizes (categories) to see if theory would back up usage of this function. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Nicholaz Beresford wrote: > > Through a wild series of hops while researching > some crash dumps I stumbled over > > _set_sbh_threshold which seems to enable heap > routines optimzed for many small allocations > (just google for it). > > Did anyone ever try this so far? Given what I > saw from my memory leak stuff, LL could be a nice > candidate for that. > > > Nick > > From okumoto at ucsd.edu Tue Jun 12 18:27:47 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Tue Jun 12 18:27:50 2007 Subject: [sldev] LL_USE_KDU flag isn't used? Message-ID: <466F4813.8060902@ucsd.edu> I greped the viewer source tree and there appears to be no reference to the LL_USE_KDU compiler flag. Can someone at LL confirm that it is not used? If not I would like to remove reference to it in the SConstruct, and the wiki Max From dzonatas at dzonux.net Tue Jun 12 18:31:41 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 12 18:31:25 2007 Subject: [sldev] [PATCH] VWR-1110: Scuplted Prims: Ability to Import .OBJ Files Message-ID: <466F48FD.7000503@dzonux.net> This has kinda sat around on my table for a bit, so I posted the source to let it bounce. https://jira.secondlife.com/secure/attachment/10783/llimageobj.patch.txt https://jira.secondlife.com/browse/VWR-1110 Is seven votes enough to make this worthwhile? Enjoy, Dz -- From jhurliman at wsu.edu Tue Jun 12 21:06:43 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Jun 12 21:05:29 2007 Subject: [sldev] [PATCH] VWR-1110: Scuplted Prims: Ability to Import .OBJ Files In-Reply-To: <466F48FD.7000503@dzonux.net> References: <466F48FD.7000503@dzonux.net> Message-ID: <466F6D53.6000208@wsu.edu> Dzonatas wrote: > This has kinda sat around on my table for a bit, so I posted the > source to let it bounce. > > https://jira.secondlife.com/secure/attachment/10783/llimageobj.patch.txt > > https://jira.secondlife.com/browse/VWR-1110 > > Is seven votes enough to make this worthwhile? > > Enjoy, > Dz > Looks great, I put a vote on it. If this doesn't make it in to the viewer I can at least implement something similar in sculptpreview, and maybe a command-line version can be written that is cross-platform. Taking OBJ importing a step further though, another idea I had was to allow temporary OBJ models to be loaded in to the Second Life world and moved around. No interaction with the server, but the scenario is you have talented 3D architects or modelers that construct something in AutoCAD or Maya and you want to make the best adaptation possible in to Second Life. You could load the OBJ file and resize/move it in-world, and then hand-create prims to match up to the original model as close as possible. Loading OBJ files in to vertex arrays isn't difficult, but any idea on how much work there would be to get client-side objects in to the rendering pipeline and be able to drag them around without sending any network updates out? John Hurliman From phoenix at secondlife.com Tue Jun 12 21:49:37 2007 From: phoenix at secondlife.com (Phoenix) Date: Tue Jun 12 21:49:45 2007 Subject: [sldev] LL_USE_KDU flag isn't used? In-Reply-To: <466F4813.8060902@ucsd.edu> References: <466F4813.8060902@ucsd.edu> Message-ID: <9D4BF5D4-63A2-4AF8-85CE-F30A2D943E5E@secondlife.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It appears to be a vestigial remnant of the many iterations we went through getting openjpeg to work alongside kdu in our various uses. On 2007-06-12, at 18:27 , Max Okumoto wrote: > I greped the viewer source tree and there appears to be no > reference to the LL_USE_KDU compiler flag. Can someone at LL > confirm that it is not used? If not I would like to remove > reference to it in the SConstruct, and the wiki > > Max > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFGb3dhwJCr4A9g8scRArjiAJ0V89yvBuP1Ueyqt3X0A2TL0vLEqACfWj6l mwZlb0BbzsOR/eZ9Xiw5IlU= =HJOa -----END PGP SIGNATURE----- From dzonatas at dzonux.net Tue Jun 12 21:55:12 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 12 21:54:54 2007 Subject: [sldev] [PATCH] VWR-1110: Scuplted Prims: Ability to Import .OBJ Files In-Reply-To: <466F6D53.6000208@wsu.edu> References: <466F48FD.7000503@dzonux.net> <466F6D53.6000208@wsu.edu> Message-ID: <466F78B0.8070605@dzonux.net> John Hurliman wrote: > Looks great, I put a vote on it. If this doesn't make it in to the > viewer I can at least implement something similar in sculptpreview, > and maybe a command-line version can be written that is > cross-platform. Taking OBJ importing a step further though, another > idea I had was to allow temporary OBJ models to be loaded in to the > Second Life world and moved around. No interaction with the server, > but the scenario is you have talented 3D architects or modelers that > construct something in AutoCAD or Maya and you want to make the best > adaptation possible in to Second Life. You could load the OBJ file and > resize/move it in-world, and then hand-create prims to match up to the > original model as close as possible. Loading OBJ files in to vertex > arrays isn't difficult, but any idea on how much work there would be > to get client-side objects in to the rendering pipeline and be able to > drag them around without sending any network updates out? Awesome ideas! Temporary objects appear to already exist, but they are just not used much. You know people have had a hell of a hard time to get sculpt objects imported into Second Life. I don't doubt it has just wasted a lot of their time. Perhaps, this is a fix for such time wasted mistakes that people make over and over as they struggle to make content in Second Life. I know I would be pissed if I bought a package worth about $400, like ZBrush, and found out it still doesn't work as easily as like Maya, worth $3000 and more. I've read lots of stories where they have just given up. Hmm. Based on (1) opinions of premium users and (2) the already popular format of the OBJ file format, Maya just seems unpopular. Kind-of reminds me of when the World Stock Exchange had troubles with it software and only certain people could buy and sell stock. Luke tried to leave it open by demand, but soon there was more demand to shut it down until fixed. People were pissed either rather it be open or closed at the time. Finally, Luke paid lots of his own personal money just to get it fixed. In such a wide-eyed allusion, two people that pay a premium membership do not appear to get equal support unless one has a modeler that directly outputs sculpt maps. How do you think the current state of the sculpt map feature, being only really supported with an expensive program, affects a business like the WSE? Dz -- From okumoto at ucsd.edu Tue Jun 12 22:08:56 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Tue Jun 12 22:09:03 2007 Subject: [sldev] LL_USE_KDU flag isn't used? In-Reply-To: <9D4BF5D4-63A2-4AF8-85CE-F30A2D943E5E@secondlife.com> References: <466F4813.8060902@ucsd.edu> <9D4BF5D4-63A2-4AF8-85CE-F30A2D943E5E@secondlife.com> Message-ID: <466F7BE8.3070004@ucsd.edu> Cool, I will submit a bug, and a patch. Was just checking that it wasn't still in use within LL. max Phoenix wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It appears to be a vestigial remnant of the many iterations we went > through getting openjpeg to work alongside kdu in our various uses. > > > On 2007-06-12, at 18:27 , Max Okumoto wrote: >> I greped the viewer source tree and there appears to be no reference >> to the LL_USE_KDU compiler flag. Can someone at LL confirm that it >> is not used? If not I would like to remove reference to it in the >> SConstruct, and the wiki >> >> Max >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > > iD8DBQFGb3dhwJCr4A9g8scRArjiAJ0V89yvBuP1Ueyqt3X0A2TL0vLEqACfWj6l > mwZlb0BbzsOR/eZ9Xiw5IlU= > =HJOa > -----END PGP SIGNATURE----- From jhurliman at wsu.edu Tue Jun 12 23:32:03 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Jun 12 23:30:43 2007 Subject: [sldev] [PATCH] VWR-1110: Scuplted Prims: Ability to Import .OBJ Files In-Reply-To: <466F78B0.8070605@dzonux.net> References: <466F48FD.7000503@dzonux.net> <466F6D53.6000208@wsu.edu> <466F78B0.8070605@dzonux.net> Message-ID: <466F8F63.5040507@wsu.edu> Dzonatas wrote: > John Hurliman wrote: >> Looks great, I put a vote on it. If this doesn't make it in to the >> viewer I can at least implement something similar in sculptpreview, >> and maybe a command-line version can be written that is >> cross-platform. Taking OBJ importing a step further though, another >> idea I had was to allow temporary OBJ models to be loaded in to the >> Second Life world and moved around. No interaction with the server, >> but the scenario is you have talented 3D architects or modelers that >> construct something in AutoCAD or Maya and you want to make the best >> adaptation possible in to Second Life. You could load the OBJ file >> and resize/move it in-world, and then hand-create prims to match up >> to the original model as close as possible. Loading OBJ files in to >> vertex arrays isn't difficult, but any idea on how much work there >> would be to get client-side objects in to the rendering pipeline and >> be able to drag them around without sending any network updates out? > > Awesome ideas! > > Temporary objects appear to already exist, but they are just not used > much. > > You know people have had a hell of a hard time to get sculpt objects > imported into Second Life. I don't doubt it has just wasted a lot of > their time. Perhaps, this is a fix for such time wasted mistakes that > people make over and over as they struggle to make content in Second > Life. I know I would be pissed if I bought a package worth about $400, > like ZBrush, and found out it still doesn't work as easily as like > Maya, worth $3000 and more. I've read lots of stories where they have > just given up. > > Hmm. Based on (1) opinions of premium users and (2) the already > popular format of the OBJ file format, Maya just seems unpopular. > > Kind-of reminds me of when the World Stock Exchange had troubles with > it software and only certain people could buy and sell stock. Luke > tried to leave it open by demand, but soon there was more demand to > shut it down until fixed. People were pissed either rather it be open > or closed at the time. Finally, Luke paid lots of his own personal > money just to get it fixed. In such a wide-eyed allusion, two people > that pay a premium membership do not appear to get equal support > unless one has a modeler that directly outputs sculpt maps. > > How do you think the current state of the sculpt map feature, being > only really supported with an expensive program, affects a business > like the WSE? > > Dz > I'm not sure about the connection between sculpted prims and your friend Luke, but I agree that there are some missing pieces in the content development workflow and I think this might be a decent band-aid or supplement. If anyone starts working on this let me know and I can try to lend a hand. John From dzonatas at dzonux.net Wed Jun 13 00:11:58 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 00:11:41 2007 Subject: [sldev] [PATCH] VWR-1110: Scuplted Prims: Ability to Import .OBJ Files In-Reply-To: <466F8F63.5040507@wsu.edu> References: <466F48FD.7000503@dzonux.net> <466F6D53.6000208@wsu.edu> <466F78B0.8070605@dzonux.net> <466F8F63.5040507@wsu.edu> Message-ID: <466F98BE.1020104@dzonux.net> John Hurliman wrote: > > I'm not sure about the connection between sculpted prims and your > friend Luke, but I agree that there are some missing pieces in the > content development workflow and I think this might be a decent > band-aid or supplement. If anyone starts working on this let me know > and I can try to lend a hand. Another idea-- you know, I wanted to put like SSE code in there, but like every time I mention SSE code now then someone bitches about copyright issues, especially with the work I did related to openjpeg. Fudge, can't the people who can read code tell the difference between a block decoder like KDU and a tile decoder like openjpeg? Heh. I couldn't tell you. I just know the command line options to KDU. I also know about PDFs that chart the difference between several DWT methods. Hmm. It would be cool to reduce sculpt maps... ack... I'm almost off topic on this. Yes, a band-aid approach might be at least helpful. I appreciate that offer! =) Oh, about Luke. Interesting... I'm apart of the SL-SEC, and I flash it in front of everybody at the WSE. Even after all that for whatever you think it could have done, Luke did trust me to have full modify permissions to all his objects. It was a temporary... band-aid... to get around the bug of putting the edit box up in the upper-right corner of the screen while he had tons of incoming freaking blue boxes with all kinds of strange messages and prompts that you can't move out of the way to even get to the edit box underneath. It especially makes it a fucking hard time when you are prompted "teleport, yes or no"... isn't there a third option... like to let someone know you received your message..."can you please wait." =) -- From gigstaggart at gmail.com Wed Jun 13 00:32:49 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 13 00:33:03 2007 Subject: [sldev] Triage Agenda Message-ID: <466F9DA1.2060508@gmail.com> https://wiki.secondlife.com/wiki/Bug_triage/Agenda I have done the triage agenda. 1. At the top of the list is issues with invalid crap in their Linden Lab issue ID field. These will never be triaged if we don't fix them, so we might as well triage them now. Many of them are old anyway. 2. Next is new patches that haven't been imported. 3. Last is the general query, all bugs by LL ID, enough to take up the remaining time. As always, feel free to resolve issues in this list and remove them from the list prior to triage if you are certain they are fixed or invalid, or if you are a Linden, mark bugs that are already in the system and not duplicates with the proper LL ID. From blakar at gmail.com Wed Jun 13 02:14:11 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jun 13 02:14:13 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <466F3D1E.605@blueflash.cc> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> Message-ID: <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> Nick, the small block heap is disabled as of win 2000 because of rewrites that started in 1999. See here: http://msdn2.microsoft.com/en-us/library/ms810466.aspx. It supposedly doesn't work in 64-bit mode either (not a big issue in SL for now). The main reason not to revert to it is the fact that it has been replaced by the Low Fragmentation Heap which works for larger blocks too (upto 16K). This is available as of Windows 2000 (updated in 2003 and XP and backported algorithm to 2000 is available.). For SL the LFH should have no issue doing a better job than the SBH. I'm at work now and did a quick search thru the source and I don't think the LFH is being enabled so I'll patch it up and see if it works this evening. Dirk aka Blakar Ogre On 6/13/07, Nicholaz Beresford wrote: > > Hi! > > I just added a > > _set_sbh_threshold(1016); > > near the top of WinMain and in one > situation it was like WOHAA! in others > I couldn't make out much difference. > > But if someone has test procedures or > more experience with performance testing, > it may be worth some efforts. > > I'll do a check tomorrow with counting > allocs of various sizes (categories) to > see if theory would back up usage of > this function. > > > Nick > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Nicholaz Beresford wrote: > > > > Through a wild series of hops while researching > > some crash dumps I stumbled over > > > > _set_sbh_threshold which seems to enable heap > > routines optimzed for many small allocations > > (just google for it). > > > > Did anyone ever try this so far? Given what I > > saw from my memory leak stuff, LL could be a nice > > candidate for that. > > > > > > Nick > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nicholaz at blueflash.cc Wed Jun 13 02:20:30 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 02:20:41 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> Message-ID: <466FB6DE.4040807@blueflash.cc> Dirk, > the small block heap is disabled as of win 2000 because of rewrites > that started in 1999. > See here: http://msdn2.microsoft.com/en-us/library/ms810466.aspx. It > supposedly doesn't work in 64-bit mode either (not a big issue in SL > for now). Are you sure about that? To me it seems to be a runtime library thing, that was disabled with VS2003 (sbb_threshold starts with zero there) and I'll be damned if that first result was coincidence or wishful thingking. I just counted allocs during a session and 2.9 million of 3.0 million allocs were 512 byes or less (with two of three million being 32 byes or less). Nick From nicholaz at blueflash.cc Wed Jun 13 03:15:05 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 03:15:26 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> Message-ID: <466FC3A9.9040507@blueflash.cc> I was looking around a bit more. The way I understand it from http://msdn2.microsoft.com/en-us/library/a6x53890(VS.71).aspx (( By default, the small-block heap is not used on Windows 2000 and later platforms, though _set_sbh_threshold can be called with a nonzero value to enable the small-block heap in those instances. )) They disabled it by default on W2000 and later but it can be enabled. Also, looking at this thread http://www.groupsrv.com/dotnet/about140748.html especially http://www.groupsrv.com/dotnet/post-465784.html#465784 it does seem to make an impact on applications with lots of small memory chunks. Nick From nicholaz at blueflash.cc Wed Jun 13 03:24:28 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 03:24:44 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> Message-ID: <466FC5DC.3000702@blueflash.cc> This one is interesting too: http://dotnetfire.com/news.aspx?newsID=106707 Nick From nicholaz at blueflash.cc Wed Jun 13 03:32:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 03:32:32 2007 Subject: [sldev] Extending the Mute List In-Reply-To: <7b3a84fb0706121252t7dd4443y2a2fe815361c0d41@mail.gmail.com> References: <7b3a84fb0706121252t7dd4443y2a2fe815361c0d41@mail.gmail.com> Message-ID: <466FC7B2.8070900@blueflash.cc> Wow, nice catch!! Kudos! Nick Able Whitman wrote: > While I was investigating how to extend the viewer's mute list > functionality, I discovered that the format for the mute list that the > viewer expects is actually different than the format that the service > provides. > > This hasn't caused a problem yet, but only because the viewer code which > parses the mute list just happens to do the right thing, even though it > is broken. The problem is that this bug precludes the viewer from making > use of the (currently unused) MuteFlags field in the mute entry list, > since if this field has a value other than the default of zero, the mute > list parser will be return an invalid value for the entry's MuteType field. > > It's sort of an odd, subtle bug, so I'll relegate the details to the > actual JIRA issues: > > SVC-309: Mute list files returned by the service are malformed > https://jira.secondlife.com/browse/SVC-309 > > VWR-1170: LLMuteList::loadFromFile() improperly parses the mute list > returned from the service > https://jira.secondlife.com/browse/VWR-1170 > > > I'm working on a wiki entry detailing how the mute list works in the > viewer, which I will (hopefully) post later today when it is done. > > --Able > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From blakar at gmail.com Wed Jun 13 03:50:37 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jun 13 03:50:42 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <466FB6DE.4040807@blueflash.cc> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> <466FB6DE.4040807@blueflash.cc> Message-ID: <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> Nicholaz, read this: http://msdn2.microsoft.com/En-US/library/aa366750.aspx As you can see the LFH covers this as it has 48 buckets of 128 for the sizes upto 512. The drawback of their decision to deprecate SBH is mostly that while SBH was a default in the past LFH is not. As a result the base performance has suddenly dropped for certain types of applications (if not all :) ) and you need to salvage that. As it's easier to find info on SBH than LFH many people still use it but it's not the future and I guess at some point it'll even disappear. Dirk aka Blakar Ogre On 6/13/07, Nicholaz Beresford wrote: > > Dirk, > > > the small block heap is disabled as of win 2000 because of rewrites > > that started in 1999. > > See here: http://msdn2.microsoft.com/en-us/library/ms810466.aspx. It > > supposedly doesn't work in 64-bit mode either (not a big issue in SL > > for now). > > Are you sure about that? To me it seems to be a runtime library thing, > that was disabled with VS2003 (sbb_threshold starts with zero there) and > I'll be damned if that first result was coincidence or wishful thingking. > > I just counted allocs during a session and 2.9 million of 3.0 million > allocs were 512 byes or less (with two of three million being 32 byes > or less). > > > Nick > From nicholaz at blueflash.cc Wed Jun 13 04:04:07 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 04:04:17 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> <466FB6DE.4040807@blueflash.cc> <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> Message-ID: <466FCF27.8040408@blueflash.cc> Dirk, > read this: http://msdn2.microsoft.com/En-US/library/aa366750.aspx > > As you can see the LFH covers this as it has 48 buckets of 128 for the > sizes upto 512. > > The drawback of their decision to deprecate SBH is mostly that while > SBH was a default in the past LFH is not. As a result the base > performance has suddenly dropped for certain types of applications (if > not all :) ) and you need to salvage that. As it's easier to find info > on SBH than LFH many people still use it but it's not the future and I > guess at some point it'll even disappear. I'm still not sure I understand the difference between the two, but this link below has two methods of speeding up things http://www.amanjit-gill.de/articles/vc7_stl.html and did not understand why there were two different ways of doing this. I'll dig a bit deeper along those lines. Thanks! Nick From blakar at gmail.com Wed Jun 13 04:17:16 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jun 13 04:17:19 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <466FCF27.8040408@blueflash.cc> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> <466FB6DE.4040807@blueflash.cc> <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> <466FCF27.8040408@blueflash.cc> Message-ID: <7992d0d60706130417n2bd02220nf1d88716f9f5226f@mail.gmail.com> Nick, note that only the second option on that page for activating LFH is correct. The first one just sets up a SBH with a limit at 128 bytes. While LFH uses 128 buckets that's not the same as being limited at 128 bytes. Note that using a custom allocator like it is mentioned there might be fun too :) But I doubt searching for the ideal library wouldn't yield a lot (a lot beyond using either SBH or LFH that is). Dirk aka Blakar Ogre On 6/13/07, Nicholaz Beresford wrote: > > Dirk, > > > read this: http://msdn2.microsoft.com/En-US/library/aa366750.aspx > > > > As you can see the LFH covers this as it has 48 buckets of 128 for the > > sizes upto 512. > > > > The drawback of their decision to deprecate SBH is mostly that while > > SBH was a default in the past LFH is not. As a result the base > > performance has suddenly dropped for certain types of applications (if > > not all :) ) and you need to salvage that. As it's easier to find info > > on SBH than LFH many people still use it but it's not the future and I > > guess at some point it'll even disappear. > > > I'm still not sure I understand the difference between the two, but > this link below has two methods of speeding up things > > http://www.amanjit-gill.de/articles/vc7_stl.html > > and did not understand why there were two different ways > of doing this. > > I'll dig a bit deeper along those lines. > > Thanks! > > > > Nick > > > > From nicholaz at blueflash.cc Wed Jun 13 04:28:51 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 04:29:04 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> <466FB6DE.4040807@blueflash.cc> <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> Message-ID: <466FD4F3.30406@blueflash.cc> Hmm.... am I getting this right? LFH is an improvement over SBH but needs to be activated and in order to promote it the turned off SBH by default? I'll test more in direction of activating LFH then ... Nick From nicholaz at blueflash.cc Wed Jun 13 04:34:23 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 04:34:30 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <7992d0d60706130417n2bd02220nf1d88716f9f5226f@mail.gmail.com> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> <466FB6DE.4040807@blueflash.cc> <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> <466FCF27.8040408@blueflash.cc> <7992d0d60706130417n2bd02220nf1d88716f9f5226f@mail.gmail.com> Message-ID: <466FD63F.9030202@blueflash.cc> > note that only the second option on that page for activating LFH is > correct. The first one just sets up a SBH with a limit at 128 bytes. > While LFH uses 128 buckets that's not the same as being limited at 128 > bytes. Yes, I think I understand that part. As I mentioned in the count, 66% of the allocations in SL were 32 bytes or less and even the small example of sbh with (128) would catch 83%. My own test was with the sbh(1016) example that seems to have been the default in VC6. Out of 3 Million allocs: 2 Million were less than 32 bytes and less 2.5 Million were less than 128 bytes 2.9 Million were less than 1024 bytes So mileage may differ between sbh and LFH ... SBH seems to have the benefit of being able to just catch the small stuff and let the bigger ones proceed as before (going to the normal heap). But I guess LBH sounds more promising in the long term. Nick From kerdezixe at gmail.com Wed Jun 13 04:54:30 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jun 13 04:54:31 2007 Subject: [sldev] Valve/Steam Hardware survey. Message-ID: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> Hi, it's mostly "gamer" hardware survey (steam is the platform for game like Half-life 2, etc). But i think it's still usefull for us, secondlifer, to read this one anyway : http://www.steampowered.com/status/survey.html I'm surprised that more than 50% of gamer have less than 1GB of RAM, and 25% with less than 512MB. Dual-core cpu are 22%, not bad, probably the same 22% with 1.5GB or more RAM. :) PS: the survey started 2 weeks ago, so it's not outdated. -- kerunix Flan From blakar at gmail.com Wed Jun 13 05:05:31 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jun 13 05:05:34 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <466FD4F3.30406@blueflash.cc> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> <466FB6DE.4040807@blueflash.cc> <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> <466FD4F3.30406@blueflash.cc> Message-ID: <7992d0d60706130505y2ba084d5nf2350a5bbf0a0d2d@mail.gmail.com> Nick, indeed. Although I doubt they disabled SBH to promote LFH. I think they figured SBH would no longer play a role in todays workloads. I'm hence not so sure that SBH holds up when facing heavy load. SBH's locking code and ability to handle huge heaps (containing megabytes of small items) may be bad as it was written in a different age. They started working on LFH when 64MB was considered a lot of RAM. And as they turned off SBH they must've figured it would be no longer applicable for software with big memory footprints. I'm for example not sure how SBH is doing alignment. For LFH it's clear that minimum size is 8 bytes and it's known to be ready for 64 bits environments. I'm pretty sure it'll align well to avoid performance hits. Dirk aka Blakar Ogre On 6/13/07, Nicholaz Beresford wrote: > > Hmm.... am I getting this right? > > LFH is an improvement over SBH but needs to be activated and > in order to promote it the turned off SBH by default? > > I'll test more in direction of activating LFH then ... > > > Nick > > > > > From nicholaz at blueflash.cc Wed Jun 13 05:07:16 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 05:07:28 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> Message-ID: <466FDDF4.9000607@blueflash.cc> Other settings: Dirk will like this: - 99% with SSE - 84% with SSE2 _set_SSE2_enable(true); :-) Nick Laurent Laborde wrote: > Hi, > > it's mostly "gamer" hardware survey (steam is the platform for game > like Half-life 2, etc). > But i think it's still usefull for us, secondlifer, to read this one > anyway : > > http://www.steampowered.com/status/survey.html > > I'm surprised that more than 50% of gamer have less than 1GB of RAM, > and 25% with less than 512MB. > Dual-core cpu are 22%, not bad, probably the same 22% with 1.5GB or more > RAM. :) > > PS: the survey started 2 weeks ago, so it's not outdated. > From nicholaz at blueflash.cc Wed Jun 13 05:16:55 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 05:17:01 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <7992d0d60706130505y2ba084d5nf2350a5bbf0a0d2d@mail.gmail.com> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> <466FB6DE.4040807@blueflash.cc> <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> <466FD4F3.30406@blueflash.cc> <7992d0d60706130505y2ba084d5nf2350a5bbf0a0d2d@mail.gmail.com> Message-ID: <466FE037.1050006@blueflash.cc> Dirk, in some of the threads about sbh I've read about occasional drops in performance, and given the LBH is the more modern version I'll definitely look into that direction. I'm glad you caught this difference/detail, I guess I would have missed that. Nick Dirk Moerenhout wrote: > Nick, > > indeed. Although I doubt they disabled SBH to promote LFH. I think > they figured SBH would no longer play a role in todays workloads. I'm > hence not so sure that SBH holds up when facing heavy load. SBH's > locking code and ability to handle huge heaps (containing megabytes of > small items) may be bad as it was written in a different age. They > started working on LFH when 64MB was considered a lot of RAM. And as > they turned off SBH they must've figured it would be no longer > applicable for software with big memory footprints. > > I'm for example not sure how SBH is doing alignment. For LFH it's > clear that minimum size is 8 bytes and it's known to be ready for 64 > bits environments. I'm pretty sure it'll align well to avoid > performance hits. > > Dirk aka Blakar Ogre > > On 6/13/07, Nicholaz Beresford wrote: >> >> Hmm.... am I getting this right? >> >> LFH is an improvement over SBH but needs to be activated and >> in order to promote it the turned off SBH by default? >> >> I'll test more in direction of activating LFH then ... >> >> >> Nick >> >> >> >> >> From blakar at gmail.com Wed Jun 13 07:03:39 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jun 13 07:03:42 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> Message-ID: <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> That info is great! I hope LL can come up with something similar for SL. It'd greatly benefit targeted performance coding. Based on the Steam info these would be the parameters: - Memory footprint should target 256MB systems and above - Video memory footprint should target 128MB cards and above - Windows OS target should be XP (for example the heap allocation handling) - RDTSC, CMOV and FCMOV are safe - SSE is safe - SSE2 can be used conditionally if the SSE2 code + checks is faster than SSE Memory foortprint is probably a good example of where things go wrong currently. Minimum for SL is 256MB and recommended is 512MB and we all know that 1GB doesn't hurt :) Dirk aka Blakar Ogre On 6/13/07, Laurent Laborde wrote: > Hi, > > it's mostly "gamer" hardware survey (steam is the platform for game > like Half-life 2, etc). > But i think it's still usefull for us, secondlifer, to read this one anyway : > > http://www.steampowered.com/status/survey.html > > I'm surprised that more than 50% of gamer have less than 1GB of RAM, > and 25% with less than 512MB. > Dual-core cpu are 22%, not bad, probably the same 22% with 1.5GB or more RAM. :) > > PS: the survey started 2 weeks ago, so it's not outdated. > > -- > kerunix Flan > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From kerdezixe at gmail.com Wed Jun 13 08:29:42 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jun 13 08:29:44 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> Message-ID: <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> On 6/13/07, Dirk Moerenhout wrote: > > Memory foortprint is probably a good example of where things go wrong > currently. Minimum for SL is 256MB and recommended is 512MB and we all > know that 1GB doesn't hurt :) I upgraded my AMD Barton 2600+ from 1GB to 3GB RAM. 1GB wasn't enough, swaping. Since i upgraded to 3GB, i have less freeze and slowdown. And when i was closing SL, it took many seconds to close, sometime for 30s at "cleaning up APR", with the hdd crying to death. Now with 3GB it's done very very quickly, i can't even read the log in the debug console while closing. 3GB is too much, i have 1.5GB of free memory. But my SL don't crash anymore. I'm planning to put the SL cache in a ramdisk, but i can't find a good and cheap ramdisk software. i'd recommand 1.5GB, not 512MB :) I couldn't play SL all day long like i do, with less than 1GB, for sure :) I don't follow this list anymore, just from time to time when i see an interesting topic. I hope the memory leak you fixed will save a lot of memory (i don't need it anymore since i have 3GB, but a lot of friends don't have that much memory :p ). PS: sorry for the very bad english. I'm not used to write good english (not my main langage) but it's worse when i'm tired like i am right now... mmm... patch-day, time to sleep. :) -- kerunix Flan From dzonatas at dzonux.net Wed Jun 13 09:44:32 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 09:44:14 2007 Subject: [sldev] Triage Agenda In-Reply-To: <466F9DA1.2060508@gmail.com> References: <466F9DA1.2060508@gmail.com> Message-ID: <46701EF0.1070808@dzonux.net> Thank you! I already took a first pass through the list... please -- remember to vote! =) Jason Giglio wrote: > https://wiki.secondlife.com/wiki/Bug_triage/Agenda > > > I have done the triage agenda. > > 1. At the top of the list is issues with invalid crap in their Linden > Lab issue ID field. These will never be triaged if we don't fix them, > so we might as well triage them now. Many of them are old anyway. > > 2. Next is new patches that haven't been imported. > > 3. Last is the general query, all bugs by LL ID, enough to take up the > remaining time. > > As always, feel free to resolve issues in this list and remove them > from the list prior to triage if you are certain they are fixed or > invalid, or if you are a Linden, mark bugs that are already in the > system and not duplicates with the proper LL ID. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- From nicholaz at blueflash.cc Wed Jun 13 10:29:45 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 10:33:12 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> Message-ID: <46702989.1050000@blueflash.cc> Laurent, >> Memory foortprint is probably a good example of where things go wrong >> currently. Minimum for SL is 256MB and recommended is 512MB and we all >> know that 1GB doesn't hurt :) > > I upgraded my AMD Barton 2600+ from 1GB to 3GB RAM. > 1GB wasn't enough, swaping. > > Since i upgraded to 3GB, i have less freeze and slowdown. > And when i was closing SL, it took many seconds to close, sometime for > 30s at "cleaning up APR", with the hdd crying to death. Now with 3GB > it's done very very quickly, i can't even read the log in the debug > console while closing. You probably just have not been running a viewer without memory leak. Hopefully by the end of today, 1GB will be more than enough to run SL well :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Wed Jun 13 11:57:32 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 11:57:14 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> Message-ID: <46703E1C.7030900@dzonux.net> Laurent Laborde wrote: > I couldn't play SL all day long like i do, with less than 1GB, for > sure :) Steam doesn't have any similar stats for those that can use laptops to connect to SL. Hmm, so those stats only represent a gamer audience and not pure business. -- Power to Change the Void From blakar at gmail.com Wed Jun 13 12:09:32 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jun 13 12:09:35 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <46703E1C.7030900@dzonux.net> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> Message-ID: <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> It does include people that play games on portables. This you can see from the graphic cards charts. Some of the chipsets: NVIDIA GeForce Go 7600 3,816 ATI Mobility Radeon 9600/9650/9700 2,386 Mobile Intel 945GM Express Chipset 2,215 NVIDIA GeForce Go 7300 2,114 ATI Mobility Radeon Xpress 200 2,036 ATI Mobility Radeon X1600 1,971 NVIDIA GeForce Go 7400 1,812 ATI Mobility Radeon X1400 1,681 NVIDIA GeForce Go 7900 1,581 And some more. I would guess in their case it's about 5%. Do you think that would be way off compared to SL? On steam there are several games available that run fine on systems on which SL is hardly playable. I'd love to see stats from SL but I don't think the Steam userbase is going to be extremely off. Dirk aka Blakar Ogre On 6/13/07, Dzonatas wrote: > Laurent Laborde wrote: > > I couldn't play SL all day long like i do, with less than 1GB, for > > sure :) > > Steam doesn't have any similar stats for those that can use laptops to > connect to SL. Hmm, so those stats only represent a gamer audience and > not pure business. > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dzonatas at dzonux.net Wed Jun 13 12:27:30 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 12:27:11 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> Message-ID: <46704522.3050502@dzonux.net> Dirk Moerenhout wrote: > And some more. I would guess in their case it's about 5%. Do you think > that would be way off compared to SL? Eh. Some of those chipsets are not being supported. One thing to note about SL that would make it different is that available cache. There are lots of threads that run chaotically alongside the main SL thread. -- Power to Change the Void From anthony at lindenlab.com Wed Jun 13 12:30:35 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Wed Jun 13 12:28:45 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <466DF8A0.1000600@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> Message-ID: <467045DB.7090407@lindenlab.com> Hello everyone, We're now into Branch_1-17-0. 1.17.0.12 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.0.12 Release notes: http://blog.secondlife.com/2007/06/13/grid-down-for-scheduled-maintenance/#more-1016 Checksums: efccb48971f6644020d8fe0560765cc2 slviewer-darwin-libs-1.17.0.12.tar.gz a0d97271bef07a4d97c01c1c69f61de8 slviewer-linux-libs-1.17.0.12.tar.gz e71e146cb4f1ba7e37a06fb4d66d34ae slviewer-src-1.17.0.12.tar.gz ba7f0c092f4e69cfb0b2990eff0b6f29 slviewer-artwork-1.17.0.12.zip 9156977c4ae12c43a28677b7a65a9bec slviewer-src-1.17.0.12.zip 3c3e49ee8b6d215e3e6dfab5ee423c81 slviewer-win32-libs-1.17.0.12.zip Enjoy. -Anthony From nicholaz at blueflash.cc Wed Jun 13 12:34:16 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 12:42:22 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <467045DB.7090407@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> Message-ID: <467046B8.8020605@blueflash.cc> Yay!! :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Anthony Foster wrote: > Hello everyone, > > We're now into Branch_1-17-0. > > 1.17.0.12 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.0.12 > > Release notes: > http://blog.secondlife.com/2007/06/13/grid-down-for-scheduled-maintenance/#more-1016 > > > Checksums: > > efccb48971f6644020d8fe0560765cc2 slviewer-darwin-libs-1.17.0.12.tar.gz > a0d97271bef07a4d97c01c1c69f61de8 slviewer-linux-libs-1.17.0.12.tar.gz > e71e146cb4f1ba7e37a06fb4d66d34ae slviewer-src-1.17.0.12.tar.gz > ba7f0c092f4e69cfb0b2990eff0b6f29 slviewer-artwork-1.17.0.12.zip > 9156977c4ae12c43a28677b7a65a9bec slviewer-src-1.17.0.12.zip > 3c3e49ee8b6d215e3e6dfab5ee423c81 slviewer-win32-libs-1.17.0.12.zip > > Enjoy. > -Anthony > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From able.whitman at gmail.com Wed Jun 13 12:53:52 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 13 12:53:53 2007 Subject: [sldev] Extending the Mute List In-Reply-To: <466FC7B2.8070900@blueflash.cc> References: <7b3a84fb0706121252t7dd4443y2a2fe815361c0d41@mail.gmail.com> <466FC7B2.8070900@blueflash.cc> Message-ID: <7b3a84fb0706131253v6557f46duf294f6070a9852f7@mail.gmail.com> My notes on how the viewer implements muting are available on the wiki: https://wiki.secondlife.com/wiki/Muting_Objects_and_Agents https://wiki.secondlife.com/wiki/Mute_List This is my first wiki entry, so if I've committed some horrible wikisins, please let me know so I can avoid them in the future :) --Able On 6/13/07, Nicholaz Beresford wrote: > > > Wow, nice catch!! Kudos! > > > Nick > > > > Able Whitman wrote: > > While I was investigating how to extend the viewer's mute list > > functionality, I discovered that the format for the mute list that the > > viewer expects is actually different than the format that the service > > provides. > > > > This hasn't caused a problem yet, but only because the viewer code which > > parses the mute list just happens to do the right thing, even though it > > is broken. The problem is that this bug precludes the viewer from making > > use of the (currently unused) MuteFlags field in the mute entry list, > > since if this field has a value other than the default of zero, the mute > > list parser will be return an invalid value for the entry's MuteType > field. > > > > It's sort of an odd, subtle bug, so I'll relegate the details to the > > actual JIRA issues: > > > > SVC-309: Mute list files returned by the service are malformed > > https://jira.secondlife.com/browse/SVC-309 > > > > VWR-1170: LLMuteList::loadFromFile() improperly parses the mute list > > returned from the service > > https://jira.secondlife.com/browse/VWR-1170 > > > > > > I'm working on a wiki entry detailing how the mute list works in the > > viewer, which I will (hopefully) post later today when it is done. > > > > --Able > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070613/7e13a4ce/attachment.htm From seg at haxxed.com Wed Jun 13 12:55:07 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jun 13 12:55:09 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> Message-ID: <1181764507.3933.6.camel@localhost> On Wed, 2007-06-13 at 21:09 +0200, Dirk Moerenhout wrote: > And some more. I would guess in their case it's about 5%. Do you think > that would be way off compared to SL? On steam there are several games > available that run fine on systems on which SL is hardly playable. > > I'd love to see stats from SL but I don't think the Steam userbase is > going to be extremely off. We've been over this. MMX has been around for a while, no one can reasonably expect to run SL on a CPU without MMX. But its those pesky 1-1.4ghz Athlon Thunderbirds that prevent us from requiring 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/20070613/2ac0c630/attachment.pgp From dzonatas at dzonux.net Wed Jun 13 13:07:34 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 13:08:31 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <1181764507.3933.6.camel@localhost> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> Message-ID: <46704E86.9060704@dzonux.net> Callum Lerwick wrote: > We've been over this. MMX has been around for a while, no one can > reasonably expect to run SL on a CPU without MMX. But its those pesky > 1-1.4ghz Athlon Thunderbirds that prevent us from requiring SSE. > Is there a jira task to support Thunderbirds? I didn't find any in the public jira. -- Power to Change the Void From gigstaggart at gmail.com Wed Jun 13 13:12:48 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 13 13:13:00 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <46704E86.9060704@dzonux.net> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> Message-ID: <46704FC0.2030608@gmail.com> Dzonatas wrote: > Callum Lerwick wrote: >> We've been over this. MMX has been around for a while, no one can >> reasonably expect to run SL on a CPU without MMX. But its those pesky >> 1-1.4ghz Athlon Thunderbirds that prevent us from requiring SSE. >> > > Is there a jira task to support Thunderbirds? I didn't find any in the > public jira. > It's in the official minimum requirements. But there's no requirement that SL run fast on those chips, so if it's just going to be slower on those chips, I say go for it. SL is probably already pretty horrible on such chips, making it a little worse isn't going to matter much. From dzonatas at dzonux.net Wed Jun 13 13:17:14 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 13:16:56 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <46704FC0.2030608@gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> Message-ID: <467050CA.2000303@dzonux.net> Jason Giglio wrote: > Dzonatas wrote: >> Callum Lerwick wrote: >>> We've been over this. MMX has been around for a while, no one can >>> reasonably expect to run SL on a CPU without MMX. But its those pesky >>> 1-1.4ghz Athlon Thunderbirds that prevent us from requiring SSE. >>> >> >> Is there a jira task to support Thunderbirds? I didn't find any in >> the public jira. >> > > It's in the official minimum requirements. But there's no requirement > that SL run fast on those chips, so if it's just going to be slower on > those chips, I say go for it. SL is probably already pretty horrible > on such chips, making it a little worse isn't going to matter much. > > I tried it on my 1.3ghz P-M Tablet PC.... it doesn't get too far past the first render screen. Those kind of start-up issues have been in jira for awhile. -- Power to Change the Void From chance at kalacia.com Wed Jun 13 14:22:04 2007 From: chance at kalacia.com (Chance Unknown) Date: Wed Jun 13 14:22:06 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <467045DB.7090407@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> Message-ID: <2925011a0706131422j4b031338n793d8156a3d13cda@mail.gmail.com> can you insert the SVN url with branch specifications in the release email too? thanks. On 6/13/07, Anthony Foster wrote: > > Hello everyone, > > We're now into Branch_1-17-0. > > 1.17.0.12 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.0.12 > > Release notes: > > http://blog.secondlife.com/2007/06/13/grid-down-for-scheduled-maintenance/#more-1016 > > Checksums: > > efccb48971f6644020d8fe0560765cc2 slviewer-darwin-libs-1.17.0.12.tar.gz > a0d97271bef07a4d97c01c1c69f61de8 slviewer-linux-libs-1.17.0.12.tar.gz > e71e146cb4f1ba7e37a06fb4d66d34ae slviewer-src-1.17.0.12.tar.gz > ba7f0c092f4e69cfb0b2990eff0b6f29 slviewer-artwork-1.17.0.12.zip > 9156977c4ae12c43a28677b7a65a9bec slviewer-src-1.17.0.12.zip > 3c3e49ee8b6d215e3e6dfab5ee423c81 slviewer-win32-libs-1.17.0.12.zip > > 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/20070613/7cd73b76/attachment.htm From gigstaggart at gmail.com Wed Jun 13 13:32:38 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 13 14:40:57 2007 Subject: [sldev] Triage Agenda In-Reply-To: <46701EF0.1070808@dzonux.net> References: <466F9DA1.2060508@gmail.com> <46701EF0.1070808@dzonux.net> Message-ID: <46705466.4000201@gmail.com> Dzonatas wrote: > Thank you! > > I already took a first pass through the list... please -- remember to > vote! =) > Since when does a bug with a solid reproduction need a lot of votes? We have never refused to triage bugs because they don't have votes in the past. -Jason From seg at haxxed.com Wed Jun 13 15:15:38 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jun 13 15:15:23 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <46704FC0.2030608@gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> Message-ID: <1181772938.3933.13.camel@localhost> On Wed, 2007-06-13 at 16:12 -0400, Jason Giglio wrote: > It's in the official minimum requirements. But there's no requirement > that SL run fast on those chips, so if it's just going to be slower on > those chips, I say go for it. SL is probably already pretty horrible on > such chips, making it a little worse isn't going to matter much. Yeah, that's a solid philosophy. Lets give tax breaks to the rich as well. (Dzonatas isn't the only one who can stretch a metaphor. :) -------------- 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/20070613/353af770/attachment.pgp From adam at gwala.net Wed Jun 13 15:28:37 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Jun 13 15:29:18 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <1181772938.3933.13.camel@localhost> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> <1181772938.3933.13.camel@localhost> Message-ID: <46706F95.4020908@gwala.net> I demand a C64 port of the SL viewer! Adam Callum Lerwick wrote: > On Wed, 2007-06-13 at 16:12 -0400, Jason Giglio wrote: > >>It's in the official minimum requirements. But there's no requirement >>that SL run fast on those chips, so if it's just going to be slower on >>those chips, I say go for it. SL is probably already pretty horrible on >>such chips, making it a little worse isn't going to matter much. > > > Yeah, that's a solid philosophy. Lets give tax breaks to the rich as > well. (Dzonatas isn't the only one who can stretch a metaphor. :) > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From robla at lindenlab.com Wed Jun 13 15:59:40 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Jun 13 15:59:50 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <2925011a0706131422j4b031338n793d8156a3d13cda@mail.gmail.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <2925011a0706131422j4b031338n793d8156a3d13cda@mail.gmail.com> Message-ID: <467076DC.3080208@lindenlab.com> I'll get this in a bit. Our release team (of which Anthony is a member) has taken over source tarball releases, but not (yet) svn snapshots. Note, the "yet" in that sentence is purely hypothetical...there's not yet a plan for them to take it on. Rob On 6/13/07 2:22 PM, Chance Unknown wrote: > can you insert the SVN url with branch specifications in the release > email too? thanks. > > On 6/13/07, *Anthony Foster* < anthony@lindenlab.com > > wrote: > > Hello everyone, > > We're now into Branch_1-17-0. > > 1.17.0.12 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.0.12 > > Release notes: > http://blog.secondlife.com/2007/06/13/grid-down-for-scheduled-maintenance/#more-1016 > > Checksums: > > efccb48971f6644020d8fe0560765cc2 slviewer-darwin-libs-1.17.0.12.tar.gz > a0d97271bef07a4d97c01c1c69f61de8 slviewer-linux-libs-1.17.0.12.tar.gz > e71e146cb4f1ba7e37a06fb4d66d34ae slviewer-src-1.17.0.12.tar.gz > ba7f0c092f4e69cfb0b2990eff0b6f29 slviewer-artwork-1.17.0.12.zip > 9156977c4ae12c43a28677b7a65a9bec slviewer-src-1.17.0.12.zip > 3c3e49ee8b6d215e3e6dfab5ee423c81 slviewer-win32-libs-1.17.0.12.zip > > 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/20070613/f21c5d9b/signature.pgp From dzonatas at dzonux.net Wed Jun 13 16:00:40 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 16:00:21 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <1181772938.3933.13.camel@localhost> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> <1181772938.3933.13.camel@localhost> Message-ID: <46707718.4040102@dzonux.net> Callum Lerwick wrote: > Yeah, that's a solid philosophy. Lets give tax breaks to the rich as > well. (Dzonatas isn't the only one who can stretch a metaphor. :) > k... noted. -- Power to Change the Void From dzonatas at dzonux.net Wed Jun 13 16:24:20 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 16:24:01 2007 Subject: [sldev] Triage Agenda In-Reply-To: <46705466.4000201@gmail.com> References: <466F9DA1.2060508@gmail.com> <46701EF0.1070808@dzonux.net> <46705466.4000201@gmail.com> Message-ID: <46707CA4.1060708@dzonux.net> Jason Giglio wrote: > Since when does a bug with a solid reproduction need a lot of votes? > We have never refused to triage bugs because they don't have votes in > the past. Metaphorically, of course, like when someone walks into a regular hospital triage with a cold. They won't get refused. -- Power to Change the Void From dzonatas at dzonux.net Wed Jun 13 16:51:45 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 16:51:27 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <467076DC.3080208@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <2925011a0706131422j4b031338n793d8156a3d13cda@mail.gmail.com> <467076DC.3080208@lindenlab.com> Message-ID: <46708311.6050307@dzonux.net> I second it. Rob Lanphier wrote: > I'll get this in a bit. Our release team (of which Anthony is a member) > has taken over source tarball releases, but not (yet) svn snapshots. > Note, the "yet" in that sentence is purely hypothetical...there's not > yet a plan for them to take it on. > > Rob > > On 6/13/07 2:22 PM, Chance Unknown wrote: > >> can you insert the SVN url with branch specifications in the release >> email too? thanks. >> >> On 6/13/07, *Anthony Foster* < anthony@lindenlab.com >> > wrote: >> >> Hello everyone, >> >> We're now into Branch_1-17-0. >> >> 1.17.0.12 source release available here: >> https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.0.12 >> >> Release notes: >> http://blog.secondlife.com/2007/06/13/grid-down-for-scheduled-maintenance/#more-1016 >> >> Checksums: >> >> efccb48971f6644020d8fe0560765cc2 slviewer-darwin-libs-1.17.0.12.tar.gz >> a0d97271bef07a4d97c01c1c69f61de8 slviewer-linux-libs-1.17.0.12.tar.gz >> e71e146cb4f1ba7e37a06fb4d66d34ae slviewer-src-1.17.0.12.tar.gz >> ba7f0c092f4e69cfb0b2990eff0b6f29 slviewer-artwork-1.17.0.12.zip >> 9156977c4ae12c43a28677b7a65a9bec slviewer-src-1.17.0.12.zip >> 3c3e49ee8b6d215e3e6dfab5ee423c81 slviewer-win32-libs-1.17.0.12.zip >> >> 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 >> >> > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20070613/3614e391/attachment-0001.htm From josh at lindenlab.com Wed Jun 13 17:35:00 2007 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jun 13 17:35:03 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <46702989.1050000@blueflash.cc> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46702989.1050000@blueflash.cc> Message-ID: <46708D34.5060804@lindenlab.com> Nicholaz Beresford wrote: > You probably just have not been running a viewer without memory > leak. Hopefully by the end of today, 1GB will be more than enough > to run SL well :-) In a really unfortunate "You suck, Lindens!" move, the big leak fix (updating to libcurl-7.16.2) was reverted before the release. I have no excuse. We screwed up. As penance, several of us spent the rest of the day (this was after the long deploy this morning) getting things back into shape. We're hoping to get that out in a SL 1.17.1 optional viewer update ASAP, probably early next week, along with a boatload of other viewer-side fixes. Sorry. :( Joshua From okumoto at ucsd.edu Wed Jun 13 17:40:40 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Wed Jun 13 17:40:56 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <46708D34.5060804@lindenlab.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46702989.1050000@blueflash.cc> <46708D34.5060804@lindenlab.com> Message-ID: <46708E88.8070400@ucsd.edu> Don't be to hard on yourselves. The client is getting better very week. :-) At least the linux client starts faster and is overall faster. There is alot of code in there. Max Joshua Bell wrote: > Nicholaz Beresford wrote: >> You probably just have not been running a viewer without memory >> leak. Hopefully by the end of today, 1GB will be more than enough >> to run SL well :-) > In a really unfortunate "You suck, Lindens!" move, the big leak fix > (updating to libcurl-7.16.2) was reverted before the release. I have > no excuse. We screwed up. As penance, several of us spent the rest of > the day (this was after the long deploy this morning) getting things > back into shape. > > We're hoping to get that out in a SL 1.17.1 optional viewer update > ASAP, probably early next week, along with a boatload of other > viewer-side fixes. > > Sorry. :( > > Joshua > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From okumoto at ucsd.edu Wed Jun 13 17:47:16 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Wed Jun 13 17:47:30 2007 Subject: [sldev] Is anyone using gcc -pg (profiling) to see where the CPU is being consumed? Message-ID: <46709014.8020704@ucsd.edu> I have a patch to enable builds of the linux client with profiling, and I'm trying to see what routines are eating the CPU. Is anyone else doing this. I would like to compare notes. Max From seg at haxxed.com Wed Jun 13 17:58:09 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jun 13 17:57:48 2007 Subject: [sldev] Is anyone using gcc -pg (profiling) to see where the CPU is being consumed? In-Reply-To: <46709014.8020704@ucsd.edu> References: <46709014.8020704@ucsd.edu> Message-ID: <1181782689.3933.22.camel@localhost> On Wed, 2007-06-13 at 17:47 -0700, Max Okumoto wrote: > I have a patch to enable builds of the linux client with profiling, and > I'm trying to see what > routines are eating the CPU. Is anyone else doing this. I would like > to compare notes. Profiling using oprofile on my rather low end laptop, (Celeron 1.3, Intel 830M video) OpenJPEG and the OpenGL drivers (in particular, lighting) dominate. So I've put quite a bit of time and effort into optimizing OpenJPEG. OpenJPEG 1.2 merged a few of them but I keep coming up with new ones. :) (And regression testing is painful and slowgoing...) -------------- 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/20070613/dcdfd334/attachment.pgp From nicholaz at blueflash.cc Wed Jun 13 18:07:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 13 18:07:30 2007 Subject: [sldev] Libcurl / VC8 Message-ID: <467094C6.2030500@blueflash.cc> If anyone needs the fixed libcurl.lib for their windows builds, it's on my server (just follow the download link on my blog). And as far as I can tell, the VC8 project files on VWR-1151 should work with 1.17.0.12 (couldn't test it though ... was too busy with other things this evening ... but if anyone tired, please let me know). Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Wed Jun 13 18:24:46 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 13 18:24:27 2007 Subject: OpenJPEG Re: [sldev] Is anyone using gcc -pg (profiling) to see where the CPU is being consumed? In-Reply-To: <1181782689.3933.22.camel@localhost> References: <46709014.8020704@ucsd.edu> <1181782689.3933.22.camel@localhost> Message-ID: <467098DE.9030008@dzonux.net> Callum, feel free to take my last floating point/SSE patch and do what you need to try to finish it if you want. It appears to work fine except for when there is 8 or more components. I just haven't had time to go through the whole process to get that last little bit done. =) You know who to e-mail if you need test samples. I'll get the msvc version done after that. Dz Callum Lerwick wrote: > On Wed, 2007-06-13 at 17:47 -0700, Max Okumoto wrote: > >> I have a patch to enable builds of the linux client with profiling, and >> I'm trying to see what >> routines are eating the CPU. Is anyone else doing this. I would like >> to compare notes. >> > > Profiling using oprofile on my rather low end laptop, (Celeron 1.3, > Intel 830M video) OpenJPEG and the OpenGL drivers (in particular, > lighting) dominate. So I've put quite a bit of time and effort into > optimizing OpenJPEG. OpenJPEG 1.2 merged a few of them but I keep coming > up with new ones. :) (And regression testing is painful and > slowgoing...) > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20070613/5d6bfdb9/attachment.htm From gigstaggart at gmail.com Wed Jun 13 20:07:28 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 13 20:07:31 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <1181772938.3933.13.camel@localhost> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> <1181772938.3933.13.camel@localhost> Message-ID: <4670B0F0.9000707@gmail.com> Callum Lerwick wrote: > On Wed, 2007-06-13 at 16:12 -0400, Jason Giglio wrote: >> It's in the official minimum requirements. But there's no requirement >> that SL run fast on those chips, so if it's just going to be slower on >> those chips, I say go for it. SL is probably already pretty horrible on >> such chips, making it a little worse isn't going to matter much. > > Yeah, that's a solid philosophy. Lets give tax breaks to the rich as > well. (Dzonatas isn't the only one who can stretch a metaphor. :) To abuse it even more, taking performance away from chips made in the last 5 years to support these platforms that can't realistically run SL anyway, is more like taxing everyone to make sure that only homeless bums on the street have $50,000 a year in income, even when the middle class is being taxed to well below that income. -Jason From seg at haxxed.com Wed Jun 13 22:14:19 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jun 13 22:14:02 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <4670B0F0.9000707@gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> <1181772938.3933.13.camel@localhost> <4670B0F0.9000707@gmail.com> Message-ID: <1181798060.3933.64.camel@localhost> On Wed, 2007-06-13 at 23:07 -0400, Jason Giglio wrote: > Callum Lerwick wrote: > > On Wed, 2007-06-13 at 16:12 -0400, Jason Giglio wrote: > >> It's in the official minimum requirements. But there's no requirement > >> that SL run fast on those chips, so if it's just going to be slower on > >> those chips, I say go for it. SL is probably already pretty horrible on > >> such chips, making it a little worse isn't going to matter much. > > > > Yeah, that's a solid philosophy. Lets give tax breaks to the rich as > > well. (Dzonatas isn't the only one who can stretch a metaphor. :) > > To abuse it even more, taking performance away from chips made in the > last 5 years to support these platforms that can't realistically run SL > anyway, is more like taxing everyone to make sure that only homeless > bums on the street have $50,000 a year in income, even when the middle > class is being taxed to well below that income. Back to the original topic, you were rather abstract to begin with. If you're talking about SSE, a 1.4ghz T-bird is a perfectly reasonable thing to run SL on. I'm not talking about benefiting "platforms that can't realistically run SL anyway". Though really, I couldn't give a rats ass if LL decides to require SSE or not in their builds, I have the source and my Fedora build will continue to support T-birds. Of course, this is all moot unless anyone can actually derive benefit from SSE. Lets see the code. In my experiments with OpenJPEG, its pretty much memory bandwidth bound, SSE actually slows things down if anything, due to the stricter alignment requirements. -------------- 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/20070614/1e39ec80/attachment.pgp From okumoto at ucsd.edu Thu Jun 14 02:31:55 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Thu Jun 14 02:32:01 2007 Subject: [sldev] Is anyone using gcc -pg (profiling) to see where the CPU is being consumed? In-Reply-To: <1181782689.3933.22.camel@localhost> References: <46709014.8020704@ucsd.edu> <1181782689.3933.22.camel@localhost> Message-ID: <46710B0B.1010406@ucsd.edu> Callum Lerwick wrote: > On Wed, 2007-06-13 at 17:47 -0700, Max Okumoto wrote: > >> I have a patch to enable builds of the linux client with profiling, and >> I'm trying to see what >> routines are eating the CPU. Is anyone else doing this. I would like >> to compare notes. >> > > Profiling using oprofile on my rather low end laptop, (Celeron 1.3, > Intel 830M video) OpenJPEG and the OpenGL drivers (in particular, > lighting) dominate. So I've put quite a bit of time and effort into > optimizing OpenJPEG. OpenJPEG 1.2 merged a few of them but I keep coming > up with new ones. :) (And regression testing is painful and > slowgoing...) > Wow, isn't that painful? Right now, I only have the slviewer source tree itself compiled with profiling. The top 5 routines are Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 4.00 5.23 5.23 753687 0.00 0.00 LLVOSky::calcSkyColorInDir(LLColor3&, LLColor3&, LLVector3 const&) const 3.34 9.59 4.36 4198499 0.00 0.00 LLFace::getGeometryVolume(LLVolume const&, int, LLStrider&, LLStrider&, LLStrider&, LLStrider&, LLStrider&, LLStrider&, LLMatrix4 const&, LLMatrix3 const&, unsigned int&) 3.30 13.90 4.31 1703493 0.00 0.00 LLVolumeFace::createSide() 3.07 17.91 4.01 1025310 0.00 0.00 LLViewerJointMesh::updateGeometry() 2.95 21.76 3.85 31594072 0.00 0.00 LLPipeline::calcPixelArea(LLVector3, LLVector3, LLCamera&) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070614/abcbfe64/attachment-0001.htm From kerdezixe at gmail.com Thu Jun 14 03:57:42 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Thu Jun 14 03:57:44 2007 Subject: [sldev] Accept notecard as a default option ? Message-ID: <8a1bfe660706140357h2d2560b4paeb5a3734eea834@mail.gmail.com> Hello. I run a french school and orientation island. I think the option to always accept notecard should be a default option. All our training are notecard based and it's confusing for newbie to have the blue popup for notecard. Telling them to edit their preference isn't something easy to do too. And using thoses blue popup for such trivial thing will make clicking on "accept" as a reflex. Which is very bad. (we all know the "money stealing" script abusing this reflex). Beside that, i think all the UI change like this one shouldn't be a default option. It's a very bad thing, i think, to change feature by default without any notice. I don't want to double-check all the new option at every update just because LL have the bad habit to enable stuff we don't even know it exist. You're not Microsoft(c)(r)(tm) isn't it ? :) thx -- kerunix Flan From blakar at gmail.com Thu Jun 14 06:17:37 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Jun 14 06:17:40 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <1181798060.3933.64.camel@localhost> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> <1181772938.3933.13.camel@localhost> <4670B0F0.9000707@gmail.com> <1181798060.3933.64.camel@localhost> Message-ID: <7992d0d60706140617w3d5743f1kd3392d2a05807e80@mail.gmail.com> > Of course, this is all moot unless anyone can actually derive benefit > from SSE. Lets see the code. In my experiments with OpenJPEG, its pretty > much memory bandwidth bound, SSE actually slows things down if anything, > due to the stricter alignment requirements. What about cvtss2si for float to integer casts/truncs? Even if you don't care about alignment it'll be faster (Off course assuming you do at the least align on 4 bytes). > Though really, I couldn't give a rats ass if LL decides to require SSE > or not in their builds, I have the source and my Fedora build will > continue to support T-birds. I think that's the best route to take. Even better, if building Thunderbird compatible code becomes an option at compile time, we could use 3DNow code. I think a solution using pf2id will be faster on Thunderbird than the current code. Downside would be seperate binaries, upside would be performance gains on all platforms. Dirk aka Blakar Ogre From secret.argent at gmail.com Thu Jun 14 08:00:20 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 14 08:00:17 2007 Subject: [sldev] Re: VWR-1110: Scuplted Prims: Ability to Import .OBJ Files In-Reply-To: <20070613105043.02ABF41B04B@stupor.lindenlab.com> References: <20070613105043.02ABF41B04B@stupor.lindenlab.com> Message-ID: <8874A1F4-6A33-4474-9282-A6FBD04A0EB4@gmail.com> Just a comment: I do most of my building at 32x32 and then upscale the resulting BMP to 64x64 or greater, since it's never going to be rendered at 64x64 anyway, and there's people working as low at 8x8... so you would need to accept at least any 2^Nx2^N spherical mesh. From secret.argent at gmail.com Thu Jun 14 08:05:15 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 14 08:05:11 2007 Subject: [sldev] Re: Valve/Steam Hardware survey. In-Reply-To: <20070613235127.928EC41B01E@stupor.lindenlab.com> References: <20070613235127.928EC41B01E@stupor.lindenlab.com> Message-ID: <703B18E8-C91A-4423-9E45-31BD0B015A2A@gmail.com> > I demand a C64 port of the SL viewer! Dude, you're gonna need at LEAST an Amiga, and it's gonna suck without a Video Toaster. From dzonatas at dzonux.net Thu Jun 14 08:08:03 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 14 08:07:42 2007 Subject: [sldev] Re: VWR-1110: Scuplted Prims: Ability to Import .OBJ Files In-Reply-To: <8874A1F4-6A33-4474-9282-A6FBD04A0EB4@gmail.com> References: <20070613105043.02ABF41B04B@stupor.lindenlab.com> <8874A1F4-6A33-4474-9282-A6FBD04A0EB4@gmail.com> Message-ID: <467159D3.40603@dzonux.net> You know, this issue just gained 6 votes as of yesterday besides the 7 it already had, I'll go ahead and put other things aside to work on this. I'll work on other formats besides 64x64, also. =) I like to see the option where you could make like an array of 16x16 divisions over a 1024x1024 bitmap. That way, each division contains a 64x64 sculpt map. That entire map could encode as one image. It would be awesome for very complex objects combined together with many sculpties. Argent Stonecutter wrote: > Just a comment: I do most of my building at 32x32 and then upscale the > resulting BMP to 64x64 or greater, since it's never going to be > rendered at 64x64 anyway, and there's people working as low at 8x8... > so you would need to accept at least any 2^Nx2^N spherical mesh. > _______________________________________________ > 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 Jun 14 08:14:56 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 14 08:14:52 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: <20070614093203.7EEC441B077@stupor.lindenlab.com> References: <20070614093203.7EEC441B077@stupor.lindenlab.com> Message-ID: <0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com> There seems to be a change in the way particles are handled in the new viewer. I'm seeing fewer particles, but fewer sources with no particles. I'm also occasionally seeing sources vanish when I get close and the field of view puts the centroid of the particle field off-screen, but the source is on-screen. I'd have put it down to my imagination except for that last point. Nicholaz? You want to poke at the code? :) From nicholaz at blueflash.cc Thu Jun 14 08:39:23 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 14 08:39:37 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: <0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com> References: <20070614093203.7EEC441B077@stupor.lindenlab.com> <0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com> Message-ID: <4671612B.4010904@blueflash.cc> Argent, I've diff'd the particle stuff (partsim and partsource) and the only changes there were pointer safety stuff. I have my own patches of course, let me know if you need a copy (or anyone else). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Argent Stonecutter wrote: > There seems to be a change in the way particles are handled in the new > viewer. > > I'm seeing fewer particles, but fewer sources with no particles. > > I'm also occasionally seeing sources vanish when I get close and the > field of view puts the centroid of the particle field off-screen, but > the source is on-screen. > > I'd have put it down to my imagination except for that last point. > > Nicholaz? You want to poke at the code? :) > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From scott at scottnorman.com Thu Jun 14 09:16:26 2007 From: scott at scottnorman.com (Scott T. Norman) Date: Thu Jun 14 09:16:31 2007 Subject: [sldev] Mac - Learning C++, Compiling & Snapshot to disk Message-ID: I'm interested in trying in playing around with the viewer and try some things, I'm not a C++ programmer, but have done other programming in the past, currently I do PHP with MySQL backend and occasionally dabble in Perl, any suggestions for learning C++ and for those on Mac any things I should know about in using XCode, etc.? If any suggestions, pointers, etc please email scott@scottnorman.com. I did download 1.15.x and was able to compile the viewer so I know I can at least do that much. Now I tried compiling all the libraries from scratch but that didn't work a couple of them had issues and since I really don't know C++, I just did the compile with the pre- compiled libraries. For learning experience, should I sit down and get all the libraries to compile and has anybody on Mac done it? I'm running on a PowerBook G4 (PPC) using 10.4.9 with 2GB RAM and the graphics card is ATI Mobility Radeon 9700. On Mac for Snapshot to disk on 1.17.0 (12), the shortcut key shows cmd-`, but that does not work, ctrl-`, so does anybody know was the short suppose to be cmd-`, if not then the menu text needs to be fixed. I looked in JIRA and could not find anything submitted on it before. So, is somebody can let me know what needs to be done, I'll post a report to JIRA. Blessings, Scott (ask Mokelembembe Mokeev) www.scottnorman.com God's covenant of revival fire has fallen upon Orange County, California, so that the Church of Orange County will become one and bring healing, salvation, and redemption to the county, and to take part in the harvest of one billion plus souls into the Kingdom of God. - Scott Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070614/3d2cf590/attachment.htm From sl at phoca.com Thu Jun 14 09:16:22 2007 From: sl at phoca.com (Second Life) Date: Thu Jun 14 09:16:40 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: <4671612B.4010904@blueflash.cc> References: <20070614093203.7EEC441B077@stupor.lindenlab.com><0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com> <4671612B.4010904@blueflash.cc> Message-ID: <524A62137D564F5BA3C05F3B4B1E91EA@SanMiguel> Last time I tried your viewer Nicholz, the "flashing particles" particle rendering bug was still there. Have you done any looking into that? Has anyone? This is something that LL broke in 1.15 or something and should have been fixed by them LONG ago. But apparently they really don't care about it. Not sure how specific to a certain video card it is but I'm not the only one seeing it and it has persisted through several driver updates. Its one of those really annoying bugs because, like the particles "running out" bug, it detracts considerably from the day to day visual enjoyment of SL. Farallon ----- Original Message ----- From: "Nicholaz Beresford" To: "Argent Stonecutter" Cc: "Second Life Developer Mailing List" Sent: Thursday, June 14, 2007 8:39 AM Subject: Re: [sldev] Particles in the new viewer. > > Argent, > > I've diff'd the particle stuff (partsim and partsource) and > the only changes there were pointer safety stuff. > > I have my own patches of course, let me know if you need a > copy (or anyone else). > > > Nick > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Argent Stonecutter wrote: >> There seems to be a change in the way particles are handled in the new >> viewer. >> >> I'm seeing fewer particles, but fewer sources with no particles. >> >> I'm also occasionally seeing sources vanish when I get close and the >> field of view puts the centroid of the particle field off-screen, but the >> source is on-screen. >> >> I'd have put it down to my imagination except for that last point. >> >> Nicholaz? You want to poke at the code? :) >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Thu Jun 14 09:23:49 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 14 09:24:04 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: <524A62137D564F5BA3C05F3B4B1E91EA@SanMiguel> References: <20070614093203.7EEC441B077@stupor.lindenlab.com><0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com> <4671612B.4010904@blueflash.cc> <524A62137D564F5BA3C05F3B4B1E91EA@SanMiguel> Message-ID: <46716B95.2030608@blueflash.cc> Fallaron, which bug is that exactly? Is there a JIRA for it, or repro or something? Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Second Life wrote: > Last time I tried your viewer Nicholz, the "flashing particles" particle > rendering bug was still there. > > Have you done any looking into that? Has anyone? This is something that > LL broke in 1.15 or something and should have been fixed by them LONG > ago. But apparently they really don't care about it. Not sure how > specific to a certain video card it is but I'm not the only one seeing > it and it has persisted through several driver updates. > > Its one of those really annoying bugs because, like the particles > "running out" bug, it detracts considerably from the day to day visual > enjoyment of SL. > > Farallon From xotmid at gmail.com Thu Jun 14 09:37:06 2007 From: xotmid at gmail.com (Brandon Husbands) Date: Thu Jun 14 09:40:30 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: <46716B95.2030608@blueflash.cc> References: <20070614093203.7EEC441B077@stupor.lindenlab.com> <0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com> <4671612B.4010904@blueflash.cc> <524A62137D564F5BA3C05F3B4B1E91EA@SanMiguel> <46716B95.2030608@blueflash.cc> Message-ID: https://jira.secondlife.com/browse/SVC-193 On 6/14/07, Nicholaz Beresford wrote: > > Fallaron, > > which bug is that exactly? Is there a JIRA for it, > or repro or something? > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Second Life wrote: > > Last time I tried your viewer Nicholz, the "flashing particles" particle > > rendering bug was still there. > > > > Have you done any looking into that? Has anyone? This is something that > > LL broke in 1.15 or something and should have been fixed by them LONG > > ago. But apparently they really don't care about it. Not sure how > > specific to a certain video card it is but I'm not the only one seeing > > it and it has persisted through several driver updates. > > > > Its one of those really annoying bugs because, like the particles > > "running out" bug, it detracts considerably from the day to day visual > > enjoyment of SL. > > > > Farallon > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From sl at phoca.com Thu Jun 14 09:54:19 2007 From: sl at phoca.com (Second Life) Date: Thu Jun 14 09:54:38 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: References: <20070614093203.7EEC441B077@stupor.lindenlab.com><0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com><4671612B.4010904@blueflash.cc><524A62137D564F5BA3C05F3B4B1E91EA@SanMiguel><46716B95.2030608@blueflash.cc> Message-ID: <50DBBB5AAE944151BB6D357BEB4468B5@SanMiguel> I have several particle scripts that repro it I can hand you on line if you like. Farallon ----- Original Message ----- From: "Brandon Husbands" To: "Nicholaz Beresford" Cc: "Second Life Developer Mailing List" ; "Second Life" Sent: Thursday, June 14, 2007 9:37 AM Subject: Re: [sldev] Particles in the new viewer. > https://jira.secondlife.com/browse/SVC-193 > > On 6/14/07, Nicholaz Beresford wrote: >> >> Fallaron, >> >> which bug is that exactly? Is there a JIRA for it, >> or repro or something? >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Second Life wrote: >> > Last time I tried your viewer Nicholz, the "flashing particles" >> > particle >> > rendering bug was still there. >> > >> > Have you done any looking into that? Has anyone? This is something that >> > LL broke in 1.15 or something and should have been fixed by them LONG >> > ago. But apparently they really don't care about it. Not sure how >> > specific to a certain video card it is but I'm not the only one seeing >> > it and it has persisted through several driver updates. >> > >> > Its one of those really annoying bugs because, like the particles >> > "running out" bug, it detracts considerably from the day to day visual >> > enjoyment of SL. >> > >> > Farallon >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Thu Jun 14 10:03:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 14 10:03:34 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: <50DBBB5AAE944151BB6D357BEB4468B5@SanMiguel> References: <20070614093203.7EEC441B077@stupor.lindenlab.com><0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com><4671612B.4010904@blueflash.cc><524A62137D564F5BA3C05F3B4B1E91EA@SanMiguel><46716B95.2030608@blueflash.cc> <50DBBB5AAE944151BB6D357BEB4468B5@SanMiguel> Message-ID: <467174D7.1000403@blueflash.cc> Yes, I'd be interested in checking this. But believe it or not, I'm a total particle noob, so if you have some demo for me and instructions on how the make the problem appear, I'll look into it. Also, as simple and with the longest lifetime possible for the particles (if possible), these real time things are very hard to debug. But if I get the details, yes I'll try to find and fix it (I was planning to visit the particle system again anyway) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Second Life wrote: > I have several particle scripts that repro it I can hand you on line if > you like. > > Farallon > > > >> https://jira.secondlife.com/browse/SVC-193 >> >> On 6/14/07, Nicholaz Beresford wrote: From dzonatas at dzonux.net Thu Jun 14 10:22:04 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 14 10:21:42 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <4670B0F0.9000707@gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> <1181772938.3933.13.camel@localhost> <4670B0F0.9000707@gmail.com> Message-ID: <4671793C.4030506@dzonux.net> Jason Giglio wrote: > Callum Lerwick wrote: >> On Wed, 2007-06-13 at 16:12 -0400, Jason Giglio wrote: >>> It's in the official minimum requirements. But there's no >>> requirement that SL run fast on those chips, so if it's just going >>> to be slower on those chips, I say go for it. SL is probably >>> already pretty horrible on such chips, making it a little worse >>> isn't going to matter much. >> >> Yeah, that's a solid philosophy. Lets give tax breaks to the rich as >> well. (Dzonatas isn't the only one who can stretch a metaphor. :) > > To abuse it even more, taking performance away from chips made in the > last 5 years to support these platforms that can't realistically run > SL anyway, is more like taxing everyone to make sure that only > homeless bums on the street have $50,000 a year in income, even when > the middle class is being taxed to well below that income. > That survey doesn't seem to even include hardware that has been purchased by educational grants or welfare checks. I mean there may be hardware on that survey was originally purchased purely for business reasons. It could create quite a, likewise, tax headache to really sort things out when you know it is not looked at straight across the board. -- Power to Change the Void From sl at phoca.com Thu Jun 14 10:32:23 2007 From: sl at phoca.com (Second Life) Date: Thu Jun 14 10:32:42 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: <467174D7.1000403@blueflash.cc> References: <20070614093203.7EEC441B077@stupor.lindenlab.com><0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com><4671612B.4010904@blueflash.cc><524A62137D564F5BA3C05F3B4B1E91EA@SanMiguel><46716B95.2030608@blueflash.cc> <50DBBB5AAE944151BB6D357BEB4468B5@SanMiguel> <467174D7.1000403@blueflash.cc> Message-ID: <06952930D96B433783F906EF14DB74BE@SanMiguel> I sent you a modded camp fire script in-world that shows the problem REALLY BAD. :D Seeing it should be no problem if your system is affected. It was "introduced" in the 1.15 release, most if not all through beta if I remember right (bug reported it then), but contrary to the jira entry it is not /entirely/ new. Particles did this before but in extremely rare circumstances and they were much more subtle. Something in 1.15 made this bug LEAP out. I know what you mean about finding this bug being a PITA, don't strain yourself over it. I was just wondering if you had looked at that as well since you had done some work with the particles. This would be far easier for LL to debug :/ Bugs like this /should/ be debugged internally the instant they are introduced as the coder that is responsible is closest to remembering exactly what he did at the time as opposed to weeks or months later, also easier to diff in the repository too, less clutter to sift through 2-3 version later trying to find the exact point that the break occurred. I've always subscripted to the theory that bugs should be handled in a LIFO fashion. Farallon ----- Original Message ----- From: "Nicholaz Beresford" To: "Second Life" Cc: "Second Life Developer Mailing List" Sent: Thursday, June 14, 2007 10:03 AM Subject: Re: [sldev] Particles in the new viewer. > > Yes, I'd be interested in checking this. But believe it > or not, I'm a total particle noob, so if you have some demo > for me and instructions on how the make the problem appear, > I'll look into it. > > Also, as simple and with the longest lifetime possible for > the particles (if possible), these real time things are very > hard to debug. > > But if I get the details, yes I'll try to find and fix it > (I was planning to visit the particle system again anyway) > > > Nick > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Second Life wrote: >> I have several particle scripts that repro it I can hand you on line if >> you like. >> >> Farallon >> >> >> >>> https://jira.secondlife.com/browse/SVC-193 >>> >>> On 6/14/07, Nicholaz Beresford wrote: > From tateru.nino at gmail.com Thu Jun 14 10:38:07 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 14 10:38:14 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <4671793C.4030506@dzonux.net> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> <1181772938.3933.13.camel@localhost> <4670B0F0.9000707@gmail.com> <4671793C.4030506@dzonux.net> Message-ID: <46717CFF.10600@gmail.com> Dzonatas wrote: > Jason Giglio wrote: >> Callum Lerwick wrote: >>> On Wed, 2007-06-13 at 16:12 -0400, Jason Giglio wrote: >>>> It's in the official minimum requirements. But there's no >>>> requirement that SL run fast on those chips, so if it's just going >>>> to be slower on those chips, I say go for it. SL is probably >>>> already pretty horrible on such chips, making it a little worse >>>> isn't going to matter much. >>> >>> Yeah, that's a solid philosophy. Lets give tax breaks to the rich as >>> well. (Dzonatas isn't the only one who can stretch a metaphor. :) >> >> To abuse it even more, taking performance away from chips made in the >> last 5 years to support these platforms that can't realistically run >> SL anyway, is more like taxing everyone to make sure that only >> homeless bums on the street have $50,000 a year in income, even when >> the middle class is being taxed to well below that income. >> > That survey doesn't seem to even include hardware that has been > purchased by educational grants or welfare checks. I mean there may be > hardware on that survey was originally purchased purely for business > reasons. It could create quite a, likewise, tax headache to really > sort things out when you know it is not looked at straight across the > board. > We have the viewer source code right here and can use it to sample the hardware. It wouldn't be too hard to arrange with LL to survey the SL userbase hardware with their cooperation (because that data should be posted centrally, and handled in aggregate away from us as individuals, IMO). That would give you a better picture of the capabilities of SL-user's hardware than the steam survey would. -- Tateru Nino http://dwellonit.blogspot.com/ From dzonatas at dzonux.net Thu Jun 14 10:39:56 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 14 10:39:34 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: <06952930D96B433783F906EF14DB74BE@SanMiguel> References: <20070614093203.7EEC441B077@stupor.lindenlab.com><0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com><4671612B.4010904@blueflash.cc><524A62137D564F5BA3C05F3B4B1E91EA@SanMiguel><46716B95.2030608@blueflash.cc> <50DBBB5AAE944151BB6D357BEB4468B5@SanMiguel> <467174D7.1000403@blueflash.cc> <06952930D96B433783F906EF14DB74BE@SanMiguel> Message-ID: <46717D6C.20406@dzonux.net> I still have the 1.13 and 1.14 First Look sources where the particles worked just fine. Someone could probably run a few comparisons between the different versions to find out exactly what changed. Second Life wrote: > I sent you a modded camp fire script in-world that shows the problem > REALLY BAD. :D Seeing it should be no problem if your system is > affected. It was "introduced" in the 1.15 release, most if not all > through beta if I remember right (bug reported it then), but contrary > to the jira entry it is not /entirely/ new. Particles did this before > but in extremely rare circumstances and they were much more subtle. > Something in 1.15 made this bug LEAP out. > > I know what you mean about finding this bug being a PITA, don't strain > yourself over it. I was just wondering if you had looked at that as > well since you had done some work with the particles. This would be > far easier for LL to debug :/ Bugs like this /should/ be debugged > internally the instant they are introduced as the coder that is > responsible is closest to remembering exactly what he did at the time > as opposed to weeks or months later, also easier to diff in the > repository too, less clutter to sift through 2-3 version later trying > to find the exact point that the break occurred. I've always > subscripted to the theory that bugs should be handled in a LIFO fashion. > > Farallon > > ----- Original Message ----- From: "Nicholaz Beresford" > > To: "Second Life" > Cc: "Second Life Developer Mailing List" > Sent: Thursday, June 14, 2007 10:03 AM > Subject: Re: [sldev] Particles in the new viewer. > > >> >> Yes, I'd be interested in checking this. But believe it >> or not, I'm a total particle noob, so if you have some demo >> for me and instructions on how the make the problem appear, >> I'll look into it. >> >> Also, as simple and with the longest lifetime possible for >> the particles (if possible), these real time things are very >> hard to debug. >> >> But if I get the details, yes I'll try to find and fix it >> (I was planning to visit the particle system again anyway) >> >> >> Nick >> >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Second Life wrote: >>> I have several particle scripts that repro it I can hand you on line >>> if you like. >>> >>> Farallon >>> >>> >>> >>>> https://jira.secondlife.com/browse/SVC-193 >>>> >>>> On 6/14/07, Nicholaz Beresford wrote: >> > > _______________________________________________ > 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 Thu Jun 14 10:45:57 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 14 10:45:35 2007 Subject: [sldev] Valve/Steam Hardware survey. In-Reply-To: <46717CFF.10600@gmail.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <7992d0d60706130703x79bfc27j4cec79361d385bf9@mail.gmail.com> <8a1bfe660706130829y5138d22fl30163245ff29ab99@mail.gmail.com> <46703E1C.7030900@dzonux.net> <7992d0d60706131209i2ebec916jc7ef9319e22044d3@mail.gmail.com> <1181764507.3933.6.camel@localhost> <46704E86.9060704@dzonux.net> <46704FC0.2030608@gmail.com> <1181772938.3933.13.camel@localhost> <4670B0F0.9000707@gmail.com> <4671793C.4030506@dzonux.net> <46717CFF.10600@gmail.com> Message-ID: <46717ED5.20503@dzonux.net> Tateru Nino wrote: > We have the viewer source code right here and can use it to sample the > hardware. It wouldn't be too hard to arrange with LL to survey the SL > userbase hardware with their cooperation (because that data should be > posted centrally, and handled in aggregate away from us as individuals, > IMO). That would give you a better picture of the capabilities of > SL-user's hardware than the steam survey would. > > You are right. We could actually make a volunteer survey. There are several petitions that already exist, which one could attach a lead to a binary that would send a survey to a central site. Via XMLRPC, it could be routed back in-world and provided as information for scripts to process. -- Power to Change the Void From nicholaz at blueflash.cc Thu Jun 14 10:58:59 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 14 10:59:14 2007 Subject: [sldev] Particles in the new viewer. In-Reply-To: <06952930D96B433783F906EF14DB74BE@SanMiguel> References: <20070614093203.7EEC441B077@stupor.lindenlab.com><0544EA2E-563B-44A0-86DC-9AC9E16DBB1D@gmail.com><4671612B.4010904@blueflash.cc><524A62137D564F5BA3C05F3B4B1E91EA@SanMiguel><46716B95.2030608@blueflash.cc> <50DBBB5AAE944151BB6D357BEB4468B5@SanMiguel> <467174D7.1000403@blueflash.cc> <06952930D96B433783F906EF14DB74BE@SanMiguel> Message-ID: <467181E3.2080801@blueflash.cc> > I sent you a modded camp fire script in-world that shows the problem > REALLY BAD. :D Seeing it should be no problem if your system is > affected. It was "introduced" in the 1.15 release, most if not all > through beta if I remember right (bug reported it then), but contrary to > the jira entry it is not /entirely/ new. Particles did this before but > in extremely rare circumstances and they were much more subtle. > Something in 1.15 made this bug LEAP out. Consider me being on it. > I still have the 1.13 and 1.14 First Look sources where the particles > worked just fine. Someone could probably run a few comparisons between > the different versions to find out exactly what changed. I have an 1.13.0.2 or something lying round here (and I think I know which files to look at), but Fallaron has sent me a very nice example, should be interesting to track those rouge buggers down, so probably I'll just try the traditional approach just for the fun of it ;-) Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From okumoto at ucsd.edu Thu Jun 14 11:44:50 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Thu Jun 14 11:44:55 2007 Subject: [sldev] Can we create a jira component called "Compile" or something similar? Message-ID: <46718CA2.4030909@ucsd.edu> There are issues in the "No Component" category, which are related to building the the client from source. Max From dzonatas at dzonux.net Thu Jun 14 12:12:27 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 14 12:12:05 2007 Subject: [sldev] Can we create a jira component called "Compile" or something similar? In-Reply-To: <46718CA2.4030909@ucsd.edu> References: <46718CA2.4030909@ucsd.edu> Message-ID: <4671931B.7020709@dzonux.net> If you check "Building" and "Source Release", or likewise, that has been enough to know what is meant. Max Okumoto wrote: > There are issues in the "No Component" category, which are related to > building the > the client from source. > > Max > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From okumoto at ucsd.edu Thu Jun 14 12:27:54 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Thu Jun 14 12:27:59 2007 Subject: [sldev] Can we create a jira component called "Compile" or something similar? In-Reply-To: <4671931B.7020709@dzonux.net> References: <46718CA2.4030909@ucsd.edu> <4671931B.7020709@dzonux.net> Message-ID: <467196BA.9040708@ucsd.edu> I sort of got the impression that "Building" was not about building from source, but building objects on the grid. So the issues that are in "No Component", that relate to building from source should be moved into "Building"? Max Dzonatas wrote: > If you check "Building" and "Source Release", or likewise, that has > been enough to know what is meant. > > Max Okumoto wrote: >> There are issues in the "No Component" category, which are related to >> building the >> the client from source. >> >> Max >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > From dzonatas at dzonux.net Thu Jun 14 12:31:57 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 14 12:31:36 2007 Subject: [sldev] Can we create a jira component called "Compile" or something similar? In-Reply-To: <467196BA.9040708@ucsd.edu> References: <46718CA2.4030909@ucsd.edu> <4671931B.7020709@dzonux.net> <467196BA.9040708@ucsd.edu> Message-ID: <467197AD.9050707@dzonux.net> In essence, it is the same. Yes, the items that are still labeled as "No Component" can be edited to select an appropriate component. Also note, you can select more than one, which really helps pin it down. Max Okumoto wrote: > I sort of got the impression that "Building" was not about building > from source, but building objects on the grid. > So the issues that are in "No Component", that relate to building from > source should be moved into "Building"? > > Max > Dzonatas wrote: >> If you check "Building" and "Source Release", or likewise, that has >> been enough to know what is meant. >> >> Max Okumoto wrote: >>> There are issues in the "No Component" category, which are related >>> to building the >>> the client from source. >>> >>> Max >>> _______________________________________________ >>> 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 Jun 14 13:23:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 14 13:23:08 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particles bug... In-Reply-To: <20070614173937.4E2F741B136@stupor.lindenlab.com> References: <20070614173937.4E2F741B136@stupor.lindenlab.com> Message-ID: <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> OK, I've been working with Farallon on this, and I've figured it out. The problem is that if you have "PSYS_PART_FOLLOW_SRC_MASK" then "PSYS_SRC_BURST_RADIUS" is ignored... you can't create a particle system that uses "PSYS_PART_FOLLOW_SRC_MASK" and starts the particle emission at a distance. Why not, I don't know, it's always been an annoyance to me, but I'd just gotten used to it. Farallon had some particle systems he'd modified that had a non-zero radius set, and he hadn't zeroed them out... Before 1.15 or so, it acted as if "PSYS_SRC_BURST_RADIUS" was zero. Now it seems to create the particles at "PSYS_SRC_BURST_RADIUS" then applies the "PSYS_PART_FOLLOW_SRC_MASK" rule on the following frame. The correct "fix" is uncertain. It seems to me that "PSYS_PART_FOLLOW_SRC_MASK" shouldn't prevent "PSYS_SRC_BURST_RADIUS" from working, and this should be fixed so that particles can be created at a distance and still follow source. that is, the original behavior is a bug. However, that would possibly make some existing particle systems act funny. Now me, I'd go ahead and say "well, you created an undefined particle system, it's legal for Second Life to make demons fly out of your nose" (nasal demons look like red sparks. Who knew?). There's precedent for this, and I've not seen these sparks outside Seal Cove so I suspect there's not that many particle systems out there with the problem. Plus, there's probably some systems out there where people have set this and figured that when the bug got fixed their particle systems would start working right. The alternate fix, simply zeroing out "PSYS_SRC_BURST_RADIUS" when "PSYS_PART_FOLLOW_SRC_MASK" is set, seems miserly to me. We should be looking for ways to fix old bugs like this. From tshephard at gmail.com Thu Jun 14 14:05:55 2007 From: tshephard at gmail.com (Tim Shephard) Date: Thu Jun 14 14:05:57 2007 Subject: [sldev] More plugin / platform harping.. Message-ID: <3b19a500706141405w45fc7768ha7d498349f052bb8@mail.gmail.com> It's been a while since the p-word has been used around here, but I thought this blog post from "yoick.tv" (backers of outback online, one of SL's supposed competitors) might be interesting reading from those who run screaming into the night whenever the p-bomb is dropped. http://yoick.tv/?p=439 Let me just say one thing - I can't wait for an open platform for virtual worlds where I can invest thousands of joy filled hours of engineering trying to extend (oh yeah, and still pay my bills). Cheers, Tim. From gwardell at ApprovalSystems.net Thu Jun 14 14:17:15 2007 From: gwardell at ApprovalSystems.net (Gary Wardell) Date: Thu Jun 14 14:17:43 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particlesbug... In-Reply-To: <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> Message-ID: <00c301c7aec9$624950e0$a4689943@gwsystems2.com> There is always the stance that if someone took advantage of an undocumented feature, shame on them when it gets "fixed" to work as documented. I suppose there then is a problem if there is no documentation on how it's "supposed" to work. If that's so, maybe it's time to write/design some? Gary > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Argent > Stonecutter > Sent: Thu, June 14, 2007 4:23 PM > To: sldev@lists.secondlife.com > Subject: [sldev] The "flashing particles" bug isn't a flashing > particlesbug... > > > OK, I've been working with Farallon on this, and I've figured it out. > > The problem is that if you have "PSYS_PART_FOLLOW_SRC_MASK" then > "PSYS_SRC_BURST_RADIUS" is ignored... you can't create a particle > system that uses "PSYS_PART_FOLLOW_SRC_MASK" and starts the particle > emission at a distance. Why not, I don't know, it's always been an > annoyance to me, but I'd just gotten used to it. Farallon had some > particle systems he'd modified that had a non-zero radius > set, and he > hadn't zeroed them out... > > Before 1.15 or so, it acted as if "PSYS_SRC_BURST_RADIUS" was zero. > > Now it seems to create the particles at "PSYS_SRC_BURST_RADIUS" then > applies the "PSYS_PART_FOLLOW_SRC_MASK" rule on the following frame. > > The correct "fix" is uncertain. > > It seems to me that "PSYS_PART_FOLLOW_SRC_MASK" shouldn't prevent > "PSYS_SRC_BURST_RADIUS" from working, and this should be fixed so > that particles can be created at a distance and still follow source. > that is, the original behavior is a bug. > > However, that would possibly make some existing particle systems act > funny. Now me, I'd go ahead and say "well, you created an undefined > particle system, it's legal for Second Life to make demons > fly out of > your nose" (nasal demons look like red sparks. Who knew?). There's > precedent for this, and I've not seen these sparks outside Seal Cove > so I suspect there's not that many particle systems out there with > the problem. Plus, there's probably some systems out there where > people have set this and figured that when the bug got fixed their > particle systems would start working right. > > The alternate fix, simply zeroing out "PSYS_SRC_BURST_RADIUS" when > "PSYS_PART_FOLLOW_SRC_MASK" is set, seems miserly to me. We > should be > looking for ways to fix old bugs like this. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From able.whitman at gmail.com Thu Jun 14 14:20:21 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 14 14:20:22 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <467045DB.7090407@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> Message-ID: <7b3a84fb0706141420k72f89048x8a4337662ff6d328@mail.gmail.com> Hi Anthony, Is there any particular reason the newview resource files under "linden\indra\newview\res" are still missing from the source archive? Maybe I'm rehasing an old question, but I didn't find an answer in the archives. Thanks! --Able On 6/13/07, Anthony Foster wrote: > > Hello everyone, > > We're now into Branch_1-17-0. > > 1.17.0.12 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.0.12 > > Release notes: > > http://blog.secondlife.com/2007/06/13/grid-down-for-scheduled-maintenance/#more-1016 > > Checksums: > > efccb48971f6644020d8fe0560765cc2 slviewer-darwin-libs-1.17.0.12.tar.gz > a0d97271bef07a4d97c01c1c69f61de8 slviewer-linux-libs-1.17.0.12.tar.gz > e71e146cb4f1ba7e37a06fb4d66d34ae slviewer-src-1.17.0.12.tar.gz > ba7f0c092f4e69cfb0b2990eff0b6f29 slviewer-artwork-1.17.0.12.zip > 9156977c4ae12c43a28677b7a65a9bec slviewer-src-1.17.0.12.zip > 3c3e49ee8b6d215e3e6dfab5ee423c81 slviewer-win32-libs-1.17.0.12.zip > > 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/20070614/95d4e73b/attachment.htm From labrat.hb at gmail.com Thu Jun 14 14:24:35 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Thu Jun 14 14:24:36 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <7b3a84fb0706141420k72f89048x8a4337662ff6d328@mail.gmail.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <7b3a84fb0706141420k72f89048x8a4337662ff6d328@mail.gmail.com> Message-ID: They should be in the artwork archive. On 6/14/07, Able Whitman wrote: > > Hi Anthony, > > Is there any particular reason the newview resource files under > "linden\indra\newview\res" are still missing from the source archive? Maybe > I'm rehasing an old question, but I didn't find an answer in the archives. > > Thanks! > --Able > > On 6/13/07, Anthony Foster wrote: > > > > Hello everyone, > > > > We're now into Branch_1-17-0. > > > > 1.17.0.12 source release available here: > > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.0.12 > > > > Release notes: > > > > http://blog.secondlife.com/2007/06/13/grid-down-for-scheduled-maintenance/#more-1016 > > > > Checksums: > > > > efccb48971f6644020d8fe0560765cc2 slviewer-darwin-libs-1.17.0.12.tar.gz > > a0d97271bef07a4d97c01c1c69f61de8 slviewer-linux-libs-1.17.0.12.tar.gz > > e71e146cb4f1ba7e37a06fb4d66d34ae slviewer-src-1.17.0.12.tar.gz > > ba7f0c092f4e69cfb0b2990eff0b6f29 slviewer-artwork-1.17.0.12.zip > > 9156977c4ae12c43a28677b7a65a9bec slviewer-src-1.17.0.12.zip > > 3c3e49ee8b6d215e3e6dfab5ee423c81 slviewer-win32-libs-1.17.0.12.zip > > > > 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 -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070614/44794900/attachment-0001.htm From able.whitman at gmail.com Thu Jun 14 14:24:43 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 14 14:24:44 2007 Subject: [sldev] Libcurl / VC8 In-Reply-To: <467094C6.2030500@blueflash.cc> References: <467094C6.2030500@blueflash.cc> Message-ID: <7b3a84fb0706141424v36aa445dy41d4b61a5256bab7@mail.gmail.com> Nick, Your VC8 project files work great with 1.17.0.12, thanks very much! On 6/13/07, Nicholaz Beresford wrote: > > > If anyone needs the fixed libcurl.lib for their > windows builds, it's on my server (just follow > the download link on my blog). > > And as far as I can tell, the VC8 project files > on VWR-1151 should work with 1.17.0.12 (couldn't > test it though ... was too busy with other things > this evening ... but if anyone tired, please let > me know). > > > Nick > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070614/1ae1f658/attachment.htm From nicholaz at blueflash.cc Thu Jun 14 14:26:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 14 14:26:34 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particles bug... In-Reply-To: <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> References: <20070614173937.4E2F741B136@stupor.lindenlab.com> <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> Message-ID: <4671B27E.9080905@blueflash.cc> Argent/Farallon, I'm pretty clueless about particles, and I'm glad you figured that out before I found it through hours of debugging, but here's my take on it. I'm not sure, but I'd follow the "code is law" approach (it never worked, it doesn't work now [just in a different way]), so let's keep it. Also, the wiki is pretty clear about it: PSYS_SRC_BURST_RADIUS Specifies the distance from the emitter where particles will be created. This rule is ignored when the PSYS_PART_FOLLOW_SRC_MASK flag is set. Given the Wiki and backward compatibility I'd vote for killing burst radius when FOLLOW_SRC is there. (Also I seem to remember a JIRA were someone said something about previously mutually exclusive parameters now having changed their behavior, I just could not find that one again when I was looking for it, maybe this one was involved). Btw, while we're at it there's also https://jira.secondlife.com/browse/VWR-1154 Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Argent Stonecutter wrote: > OK, I've been working with Farallon on this, and I've figured it out. > > The problem is that if you have "PSYS_PART_FOLLOW_SRC_MASK" then > "PSYS_SRC_BURST_RADIUS" is ignored... you can't create a particle system > that uses "PSYS_PART_FOLLOW_SRC_MASK" and starts the particle emission > at a distance. Why not, I don't know, it's always been an annoyance to > me, but I'd just gotten used to it. Farallon had some particle systems > he'd modified that had a non-zero radius set, and he hadn't zeroed them > out... > > Before 1.15 or so, it acted as if "PSYS_SRC_BURST_RADIUS" was zero. > > Now it seems to create the particles at "PSYS_SRC_BURST_RADIUS" then > applies the "PSYS_PART_FOLLOW_SRC_MASK" rule on the following frame. > > The correct "fix" is uncertain. > > It seems to me that "PSYS_PART_FOLLOW_SRC_MASK" shouldn't prevent > "PSYS_SRC_BURST_RADIUS" from working, and this should be fixed so that > particles can be created at a distance and still follow source. that is, > the original behavior is a bug. > > However, that would possibly make some existing particle systems act > funny. Now me, I'd go ahead and say "well, you created an undefined > particle system, it's legal for Second Life to make demons fly out of > your nose" (nasal demons look like red sparks. Who knew?). There's > precedent for this, and I've not seen these sparks outside Seal Cove so > I suspect there's not that many particle systems out there with the > problem. Plus, there's probably some systems out there where people have > set this and figured that when the bug got fixed their particle systems > would start working right. > > The alternate fix, simply zeroing out "PSYS_SRC_BURST_RADIUS" when > "PSYS_PART_FOLLOW_SRC_MASK" is set, seems miserly to me. We should be > looking for ways to fix old bugs like this. > _______________________________________________ > 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 Jun 14 14:26:58 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 14 14:26:58 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particlesbug... In-Reply-To: <00c301c7aec9$624950e0$a4689943@gwsystems2.com> References: <00c301c7aec9$624950e0$a4689943@gwsystems2.com> Message-ID: On 14-Jun-2007, at 16:17, Gary Wardell wrote: > There is always the stance that if someone took advantage of an > undocumented feature, shame on them when it gets "fixed" to work > as documented. That's the nasal demons option. http://www.hacker-dictionary.com/ terms/nasal-demons My stance is that even if it's documented somewhere that PSYS_PART_FOLLOW_SRC_MASK disables PSYS_SRC_BURST_RADIUS, that's the wrong behavior. There's no reason that you shouldn't be able to combine these options, like you can combine PSYS_PART_WIND_MASK and PSYS_PART_FOLLOW_SRC_MASK (think about that one for a while ^_^ ). From able.whitman at gmail.com Thu Jun 14 14:27:26 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 14 14:27:28 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <7b3a84fb0706141420k72f89048x8a4337662ff6d328@mail.gmail.com> Message-ID: <7b3a84fb0706141427v91d23b2saf1267e7fe606be@mail.gmail.com> Oh, duh. So they are! Next time I'll, you know, pay attention. :) On 6/14/07, Harold Brown wrote: > > They should be in the artwork archive. > > On 6/14/07, Able Whitman wrote: > > > > Hi Anthony, > > > > Is there any particular reason the newview resource files under > > "linden\indra\newview\res" are still missing from the source archive? Maybe > > I'm rehasing an old question, but I didn't find an answer in the archives. > > > > Thanks! > > --Able > > > > On 6/13/07, Anthony Foster wrote: > > > > > > Hello everyone, > > > > > > We're now into Branch_1-17-0. > > > > > > 1.17.0.12 source release available here: > > > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.0.12 > > > > > > Release notes: > > > http://blog.secondlife.com/2007/06/13/grid-down-for-scheduled-maintenance/#more-1016 > > > > > > > > > Checksums: > > > > > > efccb48971f6644020d8fe0560765cc2 > > > slviewer-darwin-libs-1.17.0.12.tar.gz > > > a0d97271bef07a4d97c01c1c69f61de8 slviewer-linux-libs-1.17.0.12.tar.gz > > > e71e146cb4f1ba7e37a06fb4d66d34ae slviewer-src-1.17.0.12.tar.gz > > > ba7f0c092f4e69cfb0b2990eff0b6f29 slviewer-artwork-1.17.0.12.zip > > > 9156977c4ae12c43a28677b7a65a9bec slviewer-src-1.17.0.12.zip > > > 3c3e49ee8b6d215e3e6dfab5ee423c81 slviewer-win32-libs-1.17.0.12.zip > > > > > > 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 -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070614/9fc614c5/attachment.htm From nicholaz at blueflash.cc Thu Jun 14 14:34:39 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 14 14:34:53 2007 Subject: [sldev] Libcurl / VC8 In-Reply-To: <7b3a84fb0706141424v36aa445dy41d4b61a5256bab7@mail.gmail.com> References: <467094C6.2030500@blueflash.cc> <7b3a84fb0706141424v36aa445dy41d4b61a5256bab7@mail.gmail.com> Message-ID: <4671B46F.5060901@blueflash.cc> Glad to hear. Saves me a lot of work trying to figure it out myself (and I'll have a V3 version soon with a small change in the Configuration Manager, but that's nothing really important) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Able Whitman wrote: > Nick, > > Your VC8 project files work great with 1.17.0.12 , > thanks very much! > > > > On 6/13/07, *Nicholaz Beresford* < nicholaz@blueflash.cc > > wrote: > > > If anyone needs the fixed libcurl.lib for their > windows builds, it's on my server (just follow > the download link on my blog). > > And as far as I can tell, the VC8 project files > on VWR-1151 should work with 1.17.0.12 (couldn't > test it though ... was too busy with other things > this evening ... but if anyone tired, please let > me know). > > > Nick > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From tshephard at gmail.com Thu Jun 14 14:36:27 2007 From: tshephard at gmail.com (Tim Shephard) Date: Thu Jun 14 14:36:28 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <3b19a500706141405w45fc7768ha7d498349f052bb8@mail.gmail.com> References: <3b19a500706141405w45fc7768ha7d498349f052bb8@mail.gmail.com> Message-ID: <3b19a500706141436w1396cd9bqa0a6c8a4ed0596ec@mail.gmail.com> "Open source Second Life add-ons still months away" http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ Interesting reading... No mention of the license though, which is the only thing that interests me. From nicholaz at blueflash.cc Thu Jun 14 14:58:03 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 14 14:58:17 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particles bug... In-Reply-To: <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> References: <20070614173937.4E2F741B136@stupor.lindenlab.com> <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> Message-ID: <4671B9EB.8010504@blueflash.cc> I just found the other issue again: https://jira.secondlife.com/browse/VWR-717 Also saw that SVC-193 has 54 votes. I'll zero out the Radius in my version but won't submit a patch (although I must say that this potential patch would probably be a one-liner and thus would have high chances of quick acceptance). I'll leave it to the particle gurus to figure out the right way to go (but will help with coding once a decision has been reached). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From robla at lindenlab.com Thu Jun 14 15:16:53 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Jun 14 15:16:59 2007 Subject: [sldev] Can we create a jira component called "Compile" or something similar? In-Reply-To: <467196BA.9040708@ucsd.edu> References: <46718CA2.4030909@ucsd.edu> <4671931B.7020709@dzonux.net> <467196BA.9040708@ucsd.edu> Message-ID: <4671BE55.3030304@lindenlab.com> Hi Max I just created a "Source Code" component. On 6/14/07 12:27 PM, Max Okumoto wrote: > I sort of got the impression that "Building" was not about building > from source, but building objects on the grid. > So the issues that are in "No Component", that relate to building from > source should be moved into "Building"? Correct. Sorry for the confusion there. I just renamed the component "Building (in-world)", and did a bulk change of eight issues previously marked "Building" that meant "building the source code" over to "Source Code" 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/20070614/caef1224/signature.pgp From nicholaz at blueflash.cc Thu Jun 14 15:48:41 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 14 15:48:54 2007 Subject: [sldev] Optimization via _set_sbh_threshold In-Reply-To: <466FE037.1050006@blueflash.cc> References: <466F3632.9070209@blueflash.cc> <466F3D1E.605@blueflash.cc> <7992d0d60706130214n240ba27bv9c29f08f04fc0e9e@mail.gmail.com> <466FB6DE.4040807@blueflash.cc> <7992d0d60706130350u3ca5338ev47e4186c636b894b@mail.gmail.com> <466FD4F3.30406@blueflash.cc> <7992d0d60706130505y2ba084d5nf2350a5bbf0a0d2d@mail.gmail.com> <466FE037.1050006@blueflash.cc> Message-ID: <4671C5C9.7050607@blueflash.cc> If someone under Windows wants to try the low fragmentation heap or sbv, attached is a bit of source from my viewer.cpp (the "// EXPERIMENTAL" part is the new stuff). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ -------------- next part -------------- // Set up SecondLife.log init_logging(); // // OK to write stuff to logs now, we've now crash reported if necessary // // EXPERIMENTAL [NB] // #if 1 ULONG heapfragparm = 2; // enable the low fragmentation heap // http://msdn2.microsoft.com/En-US/library/aa366750.aspx // (will only work *outside* the debugger) S32 rclfh= ::HeapSetInformation(GetProcessHeap(), HeapCompatibilityInformation, &heapfragparm,sizeof(heapfragparm)); llinfos << "running with" << (!rclfh ? "out" : "" ) << " low fragmentation heap " << llendl; #endif #if 0 // older semi-equivalent of low fragmentation heap S32 threshold = 1016; // enable sbv for allocs of less than xxx bytes (1026 default from VC6) // hit ratios (% of all SL allocs are under xxx bytes) // 99% < 1024 bytes // 97% < 512 bytes // 94% < 256 bytes // 84% < 128 bytes _set_sbh_threshold(1016); #endif // // ~EXPERIMENTAL [NB] // Set up some defaults... From secret.argent at gmail.com Thu Jun 14 16:45:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 14 16:45:20 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particles bug... In-Reply-To: <4671B27E.9080905@blueflash.cc> References: <20070614173937.4E2F741B136@stupor.lindenlab.com> <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> <4671B27E.9080905@blueflash.cc> Message-ID: > I'm not sure, but I'd follow the "code is law" approach (it never > worked, it doesn't work now [just in a different way]), so let's > keep it. You never fix anything if you take that to the limit. > Also, the wiki is pretty clear about it: > > PSYS_SRC_BURST_RADIUS > Specifies the distance from the emitter where particles will be > created. This rule is ignored when the PSYS_PART_FOLLOW_SRC_MASK > flag is set. The wiki is just whatever people figured out from how things worked. It's documentation, not specifications. It's possible there's some good reason for this limitation, but I've never heard one. I'd be interested in seeing Linden input. From nicholaz at blueflash.cc Thu Jun 14 17:04:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 14 17:04:32 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particles bug... In-Reply-To: References: <20070614173937.4E2F741B136@stupor.lindenlab.com> <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> <4671B27E.9080905@blueflash.cc> Message-ID: <4671D783.8080805@blueflash.cc> >> Also, the wiki is pretty clear about it: >> >> PSYS_SRC_BURST_RADIUS >> Specifies the distance from the emitter where particles will be >> created. This rule is ignored when the PSYS_PART_FOLLOW_SRC_MASK >> flag is set. > > The wiki is just whatever people figured out from how things worked. > It's documentation, not specifications. > > It's possible there's some good reason for this limitation, but I've > never heard one. I'd be interested in seeing Linden input. As said, I have an opinion on that but won't argue too hard either way because I'm hardly using particles anyway. From my point of view it was just an interesting bug and there's an end user workaround for it anyway, so mystery is solved, case closed from my point of view. The other issue with the particle system (the erratic generation and overflow) is something else entirely, this *needs* fixing IMHO and in no uncertain terms, but there again, I don't really care because I have it fixed in my viewer for Nicholaz&Friends and whoever else wants to use it. The source code for the fix is out there and for anybody to use also and I've recently learned that the rest is really not worth the effort. Nick From soft at lindenlab.com Thu Jun 14 17:27:15 2007 From: soft at lindenlab.com (Soft Linden) Date: Thu Jun 14 17:27:17 2007 Subject: [sldev] Any lex & yacc gurus? Looking at VWR-68 Message-ID: <9e6e5c9e0706141727p208e5b47k9d7866578d0ad4aa@mail.gmail.com> A lot of ya know we're busily catching up on old patches. Sorry this took as long as it did. :( One that's got me a bit stumped at the moment is VWR-68: https://jira.secondlife.com/browse/VWR-68 The patched grammar properly takes care of the following: integer i; integer x = 5; for( i = 0; i < x-1; i++ ) // SYNTAX ERROR llOwnerSay( (string)i ); The above gives a syntax error in current LSL scripts because the grammar greedily parses -1 as a constant, netting the token sequence "variable constant" instead of "variable operator constant." The new grammar fixes that. Unfortunately, the patched grammar is now too greedy when it tries to fold constant expressions: x = x - 5 - 5; // becomes x = x - (5-5) becomes x = x - 0 I haven't played with lex and yacc in ages. My initial inclination was to try the alternate fix of knocking '-' off the choice of D tokens in the unpatched lex and changing the yacc file to make '-' a unary operator instead of an optional constant integer prefix as it is in Argent's patch. But this would break initialization of negative global constants unless I hack the assignment operator to explicitly parse negative assignments. That's a gross hack. :/ Any chance a refinement to VWR-68 is a shallow problem for anyone on the list? From dzonatas at dzonux.net Thu Jun 14 17:49:21 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 14 17:48:59 2007 Subject: [sldev] Any lex & yacc gurus? Looking at VWR-68 In-Reply-To: <9e6e5c9e0706141727p208e5b47k9d7866578d0ad4aa@mail.gmail.com> References: <9e6e5c9e0706141727p208e5b47k9d7866578d0ad4aa@mail.gmail.com> Message-ID: <4671E211.60000@dzonux.net> Sounds like it does a read-ahead and parse before the left-to-right tokenization. Quick answer: precedence. Tweak the precedence. Split some of the lines in two or more. You want it to see scalars before operators, but allow for the unaries to be parsed under the scalars. Soft Linden wrote: > A lot of ya know we're busily catching up on old patches. Sorry this > took as long as it did. :( > > One that's got me a bit stumped at the moment is VWR-68: > https://jira.secondlife.com/browse/VWR-68 > > The patched grammar properly takes care of the following: > > integer i; > integer x = 5; > > for( i = 0; i < x-1; i++ ) // SYNTAX ERROR > llOwnerSay( (string)i ); > > The above gives a syntax error in current LSL scripts because the > grammar greedily parses -1 as a constant, netting the token sequence > "variable constant" instead of "variable operator constant." The new > grammar fixes that. > > Unfortunately, the patched grammar is now too greedy when it tries to > fold constant expressions: > > x = x - 5 - 5; // becomes x = x - (5-5) becomes x = x - 0 > > I haven't played with lex and yacc in ages. My initial inclination was > to try the alternate fix of knocking '-' off the choice of D tokens in > the unpatched lex and changing the yacc file to make '-' a unary > operator instead of an optional constant integer prefix as it is in > Argent's patch. But this would break initialization of negative global > constants unless I hack the assignment operator to explicitly parse > negative assignments. That's a gross hack. :/ > > Any chance a refinement to VWR-68 is a shallow problem for anyone on > the list? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From bridie at lindenlab.com Thu Jun 14 17:58:43 2007 From: bridie at lindenlab.com (Bridie Saccocio) Date: Thu Jun 14 17:58:37 2007 Subject: [sldev] Volunteer needed! Message-ID: Hey there- Good news -- many resolved PJIRA issues that went out with 1.17 this week! So - we're looking for a little clean-up help w/PJIRA... Would anyone be willing to volunteer to go through the following PJIRA issues marked as "Fixed Internally" and do the following: 1.) Re-open the issue 2.) Resolve the issue as "Fixed" 3.) Add a comment "Fixed in 1.17.0(112)" * VWR-1040: crash when opening several gestures quickly * VWR-966: Minor memory leak in llfloaterpreferences.cpp and a tiny leak in llstatup.cpp * VWR-908: Various memory leaks in the group dialog * VWR-871: More bad f00d: Two minor (or inconsequential) misses of initializing object members * VWR-870: Memory violation through uninitialized variable (invisible or unrendered flexis) * VWR-869: Possible hard-loop (endless, viewer-hang) in script editor * VWR-827: Toruses are borked after making/editing sculpted prims * VWR-823: Two unintialized variables in lltexturefetch.cpp * VWR-822: ?Create new?? clothing buttons don?t auto-wear items * VWR-810: Destructor forgets to delete mFloaterContros member in llui/llview.cpp * VWR-809: Destructor fails to clean up global menus in llviewermenu.cpp * VWR-808: Incorrect cleanup in message.cpp * VWR-807: Forgets to delete gToolInspect in lltoolmgr.cpp * VWR-804: Quirk in llviewerwindow.cpp * VWR-805: LLCurl not properly cleaned up * VWR-765: Cannot open embedded notecards in other notecards when Automatic preview of new notecards/textures/landmarks is off * VWR-409: New Feature -> UI -> Dialog -> Buy Copy/Contents -> Default Action -> Cancel * VWR-682: Text Editors should try to preserve X cursor position * VWR-671: Line editor history for recalling previously typed lines * VWR-648: Texture picker should highlight the texture in the swatch * VWR-412: Object editing arrows hidden but clickable on objects you can?t edit. * VWR-364: Viewer memory leak Ideally, the reported will notice the change and regress the issue -- but if you'd like to do that too, it would be most appreciated! Thanks! --Bridie From dzonatas at dzonux.net Thu Jun 14 18:08:27 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 14 18:08:05 2007 Subject: [sldev] Volunteer needed! In-Reply-To: References: Message-ID: <4671E68B.5080607@dzonux.net> I can start to do that pretty soon. I'm almost done with what I had to do for today. Bridie Saccocio wrote: > Hey there- > > Good news -- many resolved PJIRA issues that went out with 1.17 this > week! So - we're looking for a little clean-up help w/PJIRA... > > Would anyone be willing to volunteer to go through the following PJIRA > issues marked as "Fixed Internally" and do the following: > 1.) Re-open the issue > 2.) Resolve the issue as "Fixed" > 3.) Add a comment "Fixed in 1.17.0(112)" > > * VWR-1040: crash when opening several gestures quickly > * VWR-966: Minor memory leak in llfloaterpreferences.cpp and a tiny > leak in llstatup.cpp > * VWR-908: Various memory leaks in the group dialog > * VWR-871: More bad f00d: Two minor (or inconsequential) misses of > initializing object members > * VWR-870: Memory violation through uninitialized variable (invisible > or unrendered flexis) > * VWR-869: Possible hard-loop (endless, viewer-hang) in script editor > * VWR-827: Toruses are borked after making/editing sculpted prims > * VWR-823: Two unintialized variables in lltexturefetch.cpp > * VWR-822: ?Create new?? clothing buttons don?t auto-wear items > * VWR-810: Destructor forgets to delete mFloaterContros member in > llui/llview.cpp > * VWR-809: Destructor fails to clean up global menus in llviewermenu.cpp > * VWR-808: Incorrect cleanup in message.cpp > * VWR-807: Forgets to delete gToolInspect in lltoolmgr.cpp > * VWR-804: Quirk in llviewerwindow.cpp > * VWR-805: LLCurl not properly cleaned up > * VWR-765: Cannot open embedded notecards in other notecards when > Automatic preview of new notecards/textures/landmarks is off > * VWR-409: New Feature -> UI -> Dialog -> Buy Copy/Contents -> Default > Action -> Cancel > * VWR-682: Text Editors should try to preserve X cursor position > * VWR-671: Line editor history for recalling previously typed lines > * VWR-648: Texture picker should highlight the texture in the swatch > * VWR-412: Object editing arrows hidden but clickable on objects you > can?t edit. > * VWR-364: Viewer memory leak > > Ideally, the reported will notice the change and regress the issue -- > but if you'd like to do that too, it would be most appreciated! > > Thanks! > > --Bridie_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From Paul.Hampson at Pobox.com Thu Jun 14 18:15:51 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Thu Jun 14 18:16:00 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <467045DB.7090407@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> Message-ID: <20070615011551.GA13282@keitarou> On Wed, Jun 13, 2007 at 12:30:35PM -0700, Anthony Foster wrote: > Hello everyone, > We're now into Branch_1-17-0. > 1.17.0.12 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.0.12 Out of curiosity, is there a specific reason the google-perf-tools libraries are excluded from the amd64 build? -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070615/1536d5ae/attachment-0001.pgp From bos at lindenlab.com Thu Jun 14 18:23:10 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Jun 14 18:23:12 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <20070615011551.GA13282@keitarou> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <20070615011551.GA13282@keitarou> Message-ID: <4671E9FE.4000202@lindenlab.com> Paul TBBle Hampson wrote: > Out of curiosity, is there a specific reason the google-perf-tools > libraries are excluded from the amd64 build? Lack of time, so far. I've been concentrating on making the x86_64 build run at all on Fedora 7, which it sort of, kind of, doesn't. I'll worry about heap reporting when I can see a landscape that isn't a uniform grey colour :-) References: <46718CA2.4030909@ucsd.edu> <4671931B.7020709@dzonux.net> <467196BA.9040708@ucsd.edu> <4671BE55.3030304@lindenlab.com> Message-ID: <4671EBAD.6080506@ucsd.edu> Thanks, I just moved my two issues into the source code catagory. Max Rob Lanphier wrote: > Hi Max > > I just created a "Source Code" component. > > On 6/14/07 12:27 PM, Max Okumoto wrote: > >> I sort of got the impression that "Building" was not about building >> from source, but building objects on the grid. >> So the issues that are in "No Component", that relate to building from >> source should be moved into "Building"? >> > > Correct. Sorry for the confusion there. I just renamed the component > "Building (in-world)", and did a bulk change of eight issues previously > marked "Building" that meant "building the source code" over to "Source > Code" > > Rob > > > > From giff at electricsheepcompany.com Thu Jun 14 18:34:44 2007 From: giff at electricsheepcompany.com (Giff Constable) Date: Thu Jun 14 18:34:46 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <3b19a500706141436w1396cd9bqa0a6c8a4ed0596ec@mail.gmail.com> References: <3b19a500706141405w45fc7768ha7d498349f052bb8@mail.gmail.com> <3b19a500706141436w1396cd9bqa0a6c8a4ed0596ec@mail.gmail.com> Message-ID: <22f0f2220706141834x19ac3c2fv1d447a844d8b2ea1@mail.gmail.com> My hope is to see customizable UIs (skins) that don't get blown away upon update, and widget applications that don't compete for HUD slots and which would finally allow for efficient media and text display and entry into 3rd party apps, and oh a host of other stuff that allows for innovation in 3rd party apps and improved SL usability. The exact technical approach to get there, I am not dogmatic on. Giff On 6/14/07, Tim Shephard wrote: > > "Open source Second Life add-ons still months away" > > > http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ > > > Interesting reading... No mention of the license though, which is the > only thing that interests me. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Giff Constable GM, ESC Software The Electric Sheep Company Blog: http://blogs.electricsheepcompany.com/giff/ Email: giff@electricsheepcompany.com AIM/Skype: GiffForseti Second Life avatar name: Forseti Svarog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070614/bea3665f/attachment.htm From dzonatas at dzonux.net Thu Jun 14 19:35:07 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Thu Jun 14 19:34:43 2007 Subject: [sldev] Bug Triage: Time to Vote! Message-ID: <4671FADB.20604@dzonux.net> Spend a few moments to look over the items on the Bug Triage list, and vote on them if they are worthy of your vote! https://wiki.secondlife.com/wiki/Bug_triage/Agenda -- Power to Change the Void From scott at scottnorman.com Thu Jun 14 19:39:40 2007 From: scott at scottnorman.com (Scott T. Norman) Date: Thu Jun 14 19:39:46 2007 Subject: [sldev] Post first JIRA, VWR-1246, Is this right? Message-ID: <7413A6F5-1C89-4543-B05D-5AC2BDDF0CF2@scottnorman.com> I post my first JIRA VWR-1246, https://jira.secondlife.com/browse/ VWR-1246, I want to know if I posted enough information about the issue. Did I do it right? Blessings, Scott www.scottnorman.com God's covenant of revival fire has fallen upon Orange County, California, so that the Church of Orange County will become one and bring healing, salvation, and redemption to the county, and to take part in the harvest of one billion plus souls into the Kingdom of God. - Scott Norman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070614/c1d1f753/attachment.htm From seg at haxxed.com Thu Jun 14 20:21:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jun 14 20:20:57 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <4671E9FE.4000202@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <20070615011551.GA13282@keitarou> <4671E9FE.4000202@lindenlab.com> Message-ID: <1181877671.15983.12.camel@localhost> On Thu, 2007-06-14 at 18:23 -0700, Bryan O'Sullivan wrote: > Paul TBBle Hampson wrote: > > > Out of curiosity, is there a specific reason the google-perf-tools > > libraries are excluded from the amd64 build? > > Lack of time, so far. I've been concentrating on making the x86_64 > build run at all on Fedora 7, which it sort of, kind of, doesn't. I'll > worry about heap reporting when I can see a landscape that isn't a > uniform grey colour :-) Has worked fine here, since the initial source release. In fact I'm working on submitting slviewer into the "Fedora Collection". http://www.haxxed.com/rpms/secondlife/ (Note, I haven't uploaded 1.17.0.12 yet but I may have by the time you read this.) -------------- 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/20070614/e5f68eb9/attachment.pgp From seg at haxxed.com Thu Jun 14 20:44:11 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jun 14 20:43:39 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <466DFECE.9080805@gmail.com> References: <46677B4A.1010105@gmail.com> <1181606570.9159.17.camel@localhost> <466DFECE.9080805@gmail.com> Message-ID: <1181879051.15983.17.camel@localhost> On Tue, 2007-06-12 at 12:02 +1000, Tateru Nino wrote: > Callum Lerwick wrote: > > On Thu, 2007-06-07 at 13:28 +1000, Tateru Nino wrote: > > > >> What if.... on logout, the viewer wrote out a list of currently loaded > >> texture assets - the index of the memory cache? > >> > > > > Actually, after going over the audio engine, I'm beginning to think > > caching uncompressed textures on the filesystem really is a good idea. > > The audio engine currently caches uncompressed sounds on disk, but only > > as long as the session. > > > > Don't cache them in RAM at all, any more than necessary. Let the > > filesystem block cache do its job. I can't speak for windows, but on > > unix systems this would be quite efficient and effective. > > > You mean, basically, mmap() the whole lot and be done? I don't know how portable mmap() is, is windows at all capable of it? Plain old fopen should be plenty fast. At least on unix systems. -------------- 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/20070614/4d11a0db/attachment.pgp From tateru.nino at gmail.com Thu Jun 14 20:48:44 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 14 20:48:50 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <1181879051.15983.17.camel@localhost> References: <46677B4A.1010105@gmail.com> <1181606570.9159.17.camel@localhost> <466DFECE.9080805@gmail.com> <1181879051.15983.17.camel@localhost> Message-ID: <46720C1C.3030907@gmail.com> Callum Lerwick wrote: > On Tue, 2007-06-12 at 12:02 +1000, Tateru Nino wrote: > >> Callum Lerwick wrote: >> >>> On Thu, 2007-06-07 at 13:28 +1000, Tateru Nino wrote: >>> >>> >>>> What if.... on logout, the viewer wrote out a list of currently loaded >>>> texture assets - the index of the memory cache? >>>> >>>> >>> Actually, after going over the audio engine, I'm beginning to think >>> caching uncompressed textures on the filesystem really is a good idea. >>> The audio engine currently caches uncompressed sounds on disk, but only >>> as long as the session. >>> >>> Don't cache them in RAM at all, any more than necessary. Let the >>> filesystem block cache do its job. I can't speak for windows, but on >>> unix systems this would be quite efficient and effective. >>> >>> >> You mean, basically, mmap() the whole lot and be done? >> > > I don't know how portable mmap() is, is windows at all capable of it? > Plain old fopen should be plenty fast. At least on unix systems. > Win32 does mmap(), with the exception that you can't (I am told) grow the file while it's mapped as you can on other systems. You have to unmap it first, grow it, then remap it. -- Tateru Nino http://dwellonit.blogspot.com/ From seg at haxxed.com Thu Jun 14 20:50:46 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jun 14 20:50:14 2007 Subject: [sldev] Post first JIRA, VWR-1246, Is this right? In-Reply-To: <7413A6F5-1C89-4543-B05D-5AC2BDDF0CF2@scottnorman.com> References: <7413A6F5-1C89-4543-B05D-5AC2BDDF0CF2@scottnorman.com> Message-ID: <1181879447.15983.20.camel@localhost> On Thu, 2007-06-14 at 19:39 -0700, Scott T. Norman wrote: > I post my first > JIRA VWR-1246, https://jira.secondlife.com/browse/VWR-1246, I want to > know if I posted enough information about the issue. Did I do it > right? Seems like a straightforward enough bug. To describe that is, not necessarily to fix... -------------- 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/20070614/a9ee8e30/attachment-0001.pgp From secret.argent at gmail.com Thu Jun 14 23:26:48 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 14 23:26:46 2007 Subject: [sldev] Re: SLDev Digest, Vol 6, Issue 50 In-Reply-To: <20070615011604.01D2F41B1C1@stupor.lindenlab.com> References: <20070615011604.01D2F41B1C1@stupor.lindenlab.com> Message-ID: <7678615F-3483-4A44-B50C-AAD05C38DDD2@gmail.com> > > Unfortunately, the patched grammar is now too greedy when it tries to > fold constant expressions: > > x = x - 5 - 5; // becomes x = x - (5-5) becomes x = x - 0 Ah. There's not a clean fix for that, you need to have it create the parse tree and fold constant expressions at run time. Not as straightforward as I thought. Have to drop back to just handling the "-x" case. Don't discard the lex patch! The lex file has several wrong solutions to try and fix various symptoms in lex instead of yacc, and it basically comes down to "knocking '-' off and fixing the other broken stuff". Instead, drop most of the indra.y patch. Here's the minimum patch, try it. -------------- next part -------------- --- indra.y.orig 2007-06-15 01:22:24.000000000 -0500 +++ indra.y 2007-06-15 01:23:43.000000000 -0500 @@ -143,6 +143,8 @@ %type simple_assignable %type simple_assignable_no_list %type constant +%type integer_constant +%type fp_constant %type special_constant %type vector_constant %type quaternion_constant @@ -352,30 +354,50 @@ ; constant - : INTEGER_CONSTANT + : integer_constant { $$ = new LLScriptConstantInteger(gLine, gColumn, $1); gAllocationManager->addAllocation($$); } - | INTEGER_TRUE + | fp_constant { - $$ = new LLScriptConstantInteger(gLine, gColumn, $1); + $$ = new LLScriptConstantFloat(gLine, gColumn, $1); gAllocationManager->addAllocation($$); } - | INTEGER_FALSE + | STRING_CONSTANT { - $$ = new LLScriptConstantInteger(gLine, gColumn, $1); + $$ = new LLScriptConstantString(gLine, gColumn, $1); gAllocationManager->addAllocation($$); } - | FP_CONSTANT + ; + +fp_constant + : FP_CONSTANT { - $$ = new LLScriptConstantFloat(gLine, gColumn, $1); - gAllocationManager->addAllocation($$); + $$ = $1; } - | STRING_CONSTANT + | '-' FP_CONSTANT { - $$ = new LLScriptConstantString(gLine, gColumn, $1); - gAllocationManager->addAllocation($$); + $$ = -$1; + } + ; + +integer_constant + : INTEGER_CONSTANT + { + $$ = $1; + } + | INTEGER_TRUE + { + $$ = $1; + } + | INTEGER_FALSE + { + $$ = $1; + } + | '-' INTEGER_CONSTANT + { + $$ = -$2; } ; From Paul.Hampson at Pobox.com Fri Jun 15 07:16:26 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Fri Jun 15 07:16:41 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <4671E9FE.4000202@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <20070615011551.GA13282@keitarou> <4671E9FE.4000202@lindenlab.com> Message-ID: <20070615141626.GA21771@keitarou> On Thu, Jun 14, 2007 at 06:23:10PM -0700, Bryan O'Sullivan wrote: > Paul TBBle Hampson wrote: > >Out of curiosity, is there a specific reason the google-perf-tools > >libraries are excluded from the amd64 build? > Lack of time, so far. I've been concentrating on making the x86_64 > build run at all on Fedora 7, which it sort of, kind of, doesn't. > I'll worry about heap reporting when I can see a landscape that isn't > a uniform grey colour :-) Well, I can report that it seems to build and run fine on PowerPC, not sure mind you what advantage these libs are supposed to bring, so I can't say if they're working or not. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070616/82008a36/attachment.pgp From Paul.Hampson at Pobox.com Fri Jun 15 07:20:35 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Fri Jun 15 07:20:44 2007 Subject: [sldev] Debian preliminary packages In-Reply-To: <20070506234827.GB18130@keitarou> References: <20070506234827.GB18130@keitarou> Message-ID: <20070615142035.GB21771@keitarou> On Mon, May 07, 2007 at 09:48:27AM +1000, Paul TBBle Hampson wrote: > I've just posted the preliminary Debian packaging of > slviewer, to http://www.tbble.net/debian/ 1.17.0.12 packages uploaded, source and PowerPC sid binaries. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070616/757d838e/attachment.pgp From odysseus654 at gmail.com Fri Jun 15 09:14:03 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Fri Jun 15 09:14:06 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <46720C1C.3030907@gmail.com> References: <46677B4A.1010105@gmail.com> <1181606570.9159.17.camel@localhost> <466DFECE.9080805@gmail.com> <1181879051.15983.17.camel@localhost> <46720C1C.3030907@gmail.com> Message-ID: <1674f6c70706150914o119ba9e5s3fbea14070d8030c@mail.gmail.com> I have modified some windows applications of mine to do an mmap instead of fopen. One big thing you discover rather quickly is that you don't have to allocate memory for the files; it's also been described as the fastest way to access files on windows. The function isn't called mmap though, it's a combination of CreateFileMapping and MapViewOfFile. On 6/14/07, Tateru Nino wrote: > > > > Callum Lerwick wrote: > > On Tue, 2007-06-12 at 12:02 +1000, Tateru Nino wrote: > > > >> Callum Lerwick wrote: > >> > >>> On Thu, 2007-06-07 at 13:28 +1000, Tateru Nino wrote: > >>> > >>> > >>>> What if.... on logout, the viewer wrote out a list of currently > loaded > >>>> texture assets - the index of the memory cache? > >>>> > >>>> > >>> Actually, after going over the audio engine, I'm beginning to think > >>> caching uncompressed textures on the filesystem really is a good idea. > >>> The audio engine currently caches uncompressed sounds on disk, but > only > >>> as long as the session. > >>> > >>> Don't cache them in RAM at all, any more than necessary. Let the > >>> filesystem block cache do its job. I can't speak for windows, but on > >>> unix systems this would be quite efficient and effective. > >>> > >>> > >> You mean, basically, mmap() the whole lot and be done? > >> > > > > I don't know how portable mmap() is, is windows at all capable of it? > > Plain old fopen should be plenty fast. At least on unix systems. > > > Win32 does mmap(), with the exception that you can't (I am told) grow > the file while it's mapped as you can on other systems. > You have to unmap it first, grow it, then remap it. > > -- > 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/20070615/ccfa16bf/attachment.htm From tateru.nino at gmail.com Fri Jun 15 09:28:38 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 15 09:28:45 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <1674f6c70706150914o119ba9e5s3fbea14070d8030c@mail.gmail.com> References: <46677B4A.1010105@gmail.com> <1181606570.9159.17.camel@localhost> <466DFECE.9080805@gmail.com> <1181879051.15983.17.camel@localhost> <46720C1C.3030907@gmail.com> <1674f6c70706150914o119ba9e5s3fbea14070d8030c@mail.gmail.com> Message-ID: <4672BE36.2020407@gmail.com> Footnote....is it my imagination or is the viewer ALREADY writing that texture list out to disk on exit? Erik Anderson wrote: > I have modified some windows applications of mine to do an mmap > instead of fopen. One big thing you discover rather quickly is that > you don't have to allocate memory for the files; it's also been > described as the fastest way to access files on windows. The function > isn't called mmap though, it's a combination of CreateFileMapping and > MapViewOfFile. > > On 6/14/07, *Tateru Nino* > wrote: > > > > Callum Lerwick wrote: > > On Tue, 2007-06-12 at 12:02 +1000, Tateru Nino wrote: > > > >> Callum Lerwick wrote: > >> > >>> On Thu, 2007-06-07 at 13:28 +1000, Tateru Nino wrote: > >>> > >>> > >>>> What if.... on logout, the viewer wrote out a list of > currently loaded > >>>> texture assets - the index of the memory cache? > >>>> > >>>> > >>> Actually, after going over the audio engine, I'm beginning to > think > >>> caching uncompressed textures on the filesystem really is a > good idea. > >>> The audio engine currently caches uncompressed sounds on disk, > but only > >>> as long as the session. > >>> > >>> Don't cache them in RAM at all, any more than necessary. Let the > >>> filesystem block cache do its job. I can't speak for windows, > but on > >>> unix systems this would be quite efficient and effective. > >>> > >>> > >> You mean, basically, mmap() the whole lot and be done? > >> > > > > I don't know how portable mmap() is, is windows at all capable > of it? > > Plain old fopen should be plenty fast. At least on unix systems. > > > Win32 does mmap(), with the exception that you can't (I am told) grow > the file while it's mapped as you can on other systems. > You have to unmap it first, grow it, then remap it. > > -- > Tateru Nino > http://dwellonit.blogspot.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Tateru Nino http://dwellonit.blogspot.com/ From seg at haxxed.com Fri Jun 15 11:13:25 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 15 11:12:56 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particles bug... In-Reply-To: <4671B27E.9080905@blueflash.cc> References: <20070614173937.4E2F741B136@stupor.lindenlab.com> <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> <4671B27E.9080905@blueflash.cc> Message-ID: <1181931205.15983.49.camel@localhost> The open source way is to fix bugs, and to clean up and improve APIs whenever possible. The closed source way is to bend over backwards to retain bug-for-bug compatibility from now to the end of time, accumulating crufty hack upon hack, because there's no guarantee that third parties will bother to maintain their !@#$ing software. Choose your path. Unfortunately, in world, we're stuck with bling kiddies bitching about their purchased bling scripts breaking, who have not been given the freedom to just fix the damn script on their own (or with help). Really, LSL needs API versioning of some kind. -------------- 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/20070615/02b80571/attachment.pgp From seg at haxxed.com Fri Jun 15 11:27:32 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 15 11:26:58 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <3b19a500706141436w1396cd9bqa0a6c8a4ed0596ec@mail.gmail.com> References: <3b19a500706141405w45fc7768ha7d498349f052bb8@mail.gmail.com> <3b19a500706141436w1396cd9bqa0a6c8a4ed0596ec@mail.gmail.com> Message-ID: <1181932052.15983.55.camel@localhost> On Thu, 2007-06-14 at 14:36 -0700, Tim Shephard wrote: > "Open source Second Life add-ons still months away" > > http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ What that article doesn't mention, is re-basing patching upon a new release is *easy*... if you have access to upstream's SCM. I'm also failing to see much use in plugins unless you have the ability to extend the servers as well. Which we don't, in terms of communicating new datatypes and new bits of object metadata between client and server. (currently pondering how to implement 100% open source voice chat, without access to the sim source code. Its going to have to be a hack any way you slice it...) -------------- 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/20070615/c888642a/attachment-0001.pgp From bos at lindenlab.com Fri Jun 15 11:33:13 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Fri Jun 15 11:33:19 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <1181877671.15983.12.camel@localhost> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <20070615011551.GA13282@keitarou> <4671E9FE.4000202@lindenlab.com> <1181877671.15983.12.camel@localhost> Message-ID: <4672DB69.7040302@lindenlab.com> Callum Lerwick wrote: >> I've been concentrating on making the x86_64 >> build run at all on Fedora 7, which it sort of, kind of, doesn't. I'll >> worry about heap reporting when I can see a landscape that isn't a >> uniform grey colour :-) > > Has worked fine here, since the initial source release. Hmm. A 32-bit build works for me, but a 64-bit build gives me almost everything rendered in grey. It's possible that's due to a bug in the 64-bit version of Mesa or X.org i810 driver. What hardware and driver are you running the 64-bit viewer on? References: <3b19a500706141405w45fc7768ha7d498349f052bb8@mail.gmail.com> <3b19a500706141436w1396cd9bqa0a6c8a4ed0596ec@mail.gmail.com> <1181932052.15983.55.camel@localhost> Message-ID: <4672DE44.1080100@gwala.net> Linden Lab may be willing to accept "reference" code into the server if it is sufficiently modularised - vivox doesnt appear to be running on the SL simulators as is, so I do not know that's a specific requirement. You could do this purely clientside, with the clients reporting their positions (although this does need some careful analysis to make sure that you cant randomly enter someone elses conversation from afar using client mods) Adam Callum Lerwick wrote: > On Thu, 2007-06-14 at 14:36 -0700, Tim Shephard wrote: > >>"Open source Second Life add-ons still months away" >> >>http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ > > > What that article doesn't mention, is re-basing patching upon a new > release is *easy*... if you have access to upstream's SCM. > > I'm also failing to see much use in plugins unless you have the ability > to extend the servers as well. Which we don't, in terms of communicating > new datatypes and new bits of object metadata between client and server. > > (currently pondering how to implement 100% open source voice chat, > without access to the sim source code. Its going to have to be a hack > any way you slice it...) > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From tshephard at gmail.com Fri Jun 15 13:13:02 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Jun 15 13:13:05 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <4672DE44.1080100@gwala.net> References: <3b19a500706141405w45fc7768ha7d498349f052bb8@mail.gmail.com> <3b19a500706141436w1396cd9bqa0a6c8a4ed0596ec@mail.gmail.com> <1181932052.15983.55.camel@localhost> <4672DE44.1080100@gwala.net> Message-ID: <3b19a500706151313m2f78d47dy1c5ac5be963094e3@mail.gmail.com> There's no reason, that I can see, why our plugins can't hit our own servers. In the end, the discussion I think is academic unless LL is willing to open up the license - right now Microsoft is more open than Linden Lab. At least with Microsoft you can build and sell software extending their platform. On 6/15/07, Adam Frisby wrote: > Linden Lab may be willing to accept "reference" code into the server if > it is sufficiently modularised - vivox doesnt appear to be running on > the SL simulators as is, so I do not know that's a specific requirement. > > You could do this purely clientside, with the clients reporting their > positions (although this does need some careful analysis to make sure > that you cant randomly enter someone elses conversation from afar using > client mods) > > Adam > > Callum Lerwick wrote: > > On Thu, 2007-06-14 at 14:36 -0700, Tim Shephard wrote: > > > >>"Open source Second Life add-ons still months away" > >> > >>http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ > > > > > > What that article doesn't mention, is re-basing patching upon a new > > release is *easy*... if you have access to upstream's SCM. > > > > I'm also failing to see much use in plugins unless you have the ability > > to extend the servers as well. Which we don't, in terms of communicating > > new datatypes and new bits of object metadata between client and server. > > > > (currently pondering how to implement 100% open source voice chat, > > without access to the sim source code. Its going to have to be a hack > > any way you slice it...) > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Fri Jun 15 14:12:04 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 15 14:11:58 2007 Subject: [sldev] Re: The "flashing particles" bug isn't a flashing particles bug... (Callum Lerwick) In-Reply-To: <20070615182701.55C7941B1F0@stupor.lindenlab.com> References: <20070615182701.55C7941B1F0@stupor.lindenlab.com> Message-ID: <4D083F91-6925-4B6E-9DAA-F26A4F80398F@gmail.com> > Unfortunately, in world, we're stuck with bling kiddies bitching about > their purchased bling scripts breaking, who have not been given the > freedom to just fix the damn script on their own (or with help). > > Really, LSL needs API versioning of some kind. It's got it, kinda. You can change the constants used in the particle system, eg: PSYS_PART_SOURCE_POS_MASK (0x800) Particle's position is maintained relative to the source object's position. Then change the code so that PSYS_PART_FOLLOW_SOURCE_MASK is interpreted in the client by jamming BURST_RADIUS to zero and setting SOURCE_POS_MASK. The other thing I'd really like to change is to make it honor START_ALPHA < END_ALPHA. You could do this similarly, create new parameters PSYS_PART_ALPHA_BEGIN and PSYS_PART_ALPHA_END and retain compatibility by jamming START_ALPHA to the max of START and END. From seg at haxxed.com Fri Jun 15 16:42:42 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 15 16:42:12 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <46720C1C.3030907@gmail.com> References: <46677B4A.1010105@gmail.com> <1181606570.9159.17.camel@localhost> <466DFECE.9080805@gmail.com> <1181879051.15983.17.camel@localhost> <46720C1C.3030907@gmail.com> Message-ID: <1181950962.15983.68.camel@localhost> On Fri, 2007-06-15 at 13:48 +1000, Tateru Nino wrote: > Win32 does mmap(), with the exception that you can't (I am told) grow > the file while it's mapped as you can on other systems. > You have to unmap it first, grow it, then remap it. Shouldn't be a problem, one file per texture. Once decoded it won't change. -------------- 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/20070615/45b89153/attachment.pgp From bridie at lindenlab.com Fri Jun 15 16:43:19 2007 From: bridie at lindenlab.com (Bridie Linden) Date: Fri Jun 15 16:43:22 2007 Subject: [sldev] Volunteer needed! In-Reply-To: <4671E68B.5080607@dzonux.net> References: <4671E68B.5080607@dzonux.net> Message-ID: <537B5068-F63B-410C-A65B-B6CED782FAF0@lindenlab.com> Many thanks, Dzonatas! --Bridie On Jun 14, 2007, at 6:08 PM, Dzonatas wrote: > I can start to do that pretty soon. I'm almost done with what I > had to do for today. > > Bridie wrote: >> Hey there- >> >> Good news -- many resolved PJIRA issues that went out with 1.17 >> this week! So - we're looking for a little clean-up help w/PJIRA... >> >> Would anyone be willing to volunteer to go through the following >> PJIRA issues marked as "Fixed Internally" and do the following: >> 1.) Re-open the issue >> 2.) Resolve the issue as "Fixed" >> 3.) Add a comment "Fixed in 1.17.0(112)" >> >> * VWR-1040: crash when opening several gestures quickly >> * VWR-966: Minor memory leak in llfloaterpreferences.cpp and a >> tiny leak in llstatup.cpp >> * VWR-908: Various memory leaks in the group dialog >> * VWR-871: More bad f00d: Two minor (or inconsequential) misses of >> initializing object members >> * VWR-870: Memory violation through uninitialized variable >> (invisible or unrendered flexis) >> * VWR-869: Possible hard-loop (endless, viewer-hang) in script editor >> * VWR-827: Toruses are borked after making/editing sculpted prims >> * VWR-823: Two unintialized variables in lltexturefetch.cpp >> * VWR-822: ?Create new?? clothing buttons don?t auto-wear items >> * VWR-810: Destructor forgets to delete mFloaterContros member in >> llui/llview.cpp >> * VWR-809: Destructor fails to clean up global menus in >> llviewermenu.cpp >> * VWR-808: Incorrect cleanup in message.cpp >> * VWR-807: Forgets to delete gToolInspect in lltoolmgr.cpp >> * VWR-804: Quirk in llviewerwindow.cpp >> * VWR-805: LLCurl not properly cleaned up >> * VWR-765: Cannot open embedded notecards in other notecards when >> Automatic preview of new notecards/textures/landmarks is off >> * VWR-409: New Feature -> UI -> Dialog -> Buy Copy/Contents -> >> Default Action -> Cancel >> * VWR-682: Text Editors should try to preserve X cursor position >> * VWR-671: Line editor history for recalling previously typed lines >> * VWR-648: Texture picker should highlight the texture in the swatch >> * VWR-412: Object editing arrows hidden but clickable on objects >> you can?t edit. >> * VWR-364: Viewer memory leak >> >> Ideally, the reported will notice the change and regress the issue >> -- but if you'd like to do that too, it would be most appreciated! >> >> Thanks! >> >> --Bridie_______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> > > -- > Power to Change the Void From anthony at lindenlab.com Fri Jun 15 16:54:32 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Fri Jun 15 16:54:37 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <467045DB.7090407@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> Message-ID: <467326B8.2000307@lindenlab.com> Hello everyone, Sorry about the delay in dropping this, I'm still getting used to having this in the schedule. 1.18.0.0 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.0.0 Release note information here: http://blog.secondlife.com/2006/12/21/a-big-change-youll-barely-notice/ Checksums: 6196a5059acfcd66438ca4b3e72bab78 slviewer-darwin-libs-1.18.0.0.tar.gz 7e3dd9bf65abb77e4c30d73762fd0f09 slviewer-linux-libs-1.18.0.0.tar.gz 3ca525ec227bb49d80170112b3051399 slviewer-src-1.18.0.0.tar.gz 6aa3d8c117d9d051e0ff7c7fc3222600 slviewer-artwork-1.18.0.0.zip 479d66f6fc104b1ec2afbd79bd4cb38c slviewer-src-1.18.0.0.zip 073e44d25eeb607f881013cdf0680385 slviewer-win32-libs-1.18.0.0.zip SVN checkout: http://svn.lindenlab.com/svn/linden/branches/release-candidate/ Enjoy. -Anthony From robla at lindenlab.com Fri Jun 15 17:56:13 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jun 15 17:56:17 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <467326B8.2000307@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> Message-ID: <4673352D.9040107@lindenlab.com> Thanks, Anthony! (let's all hear it for him....he's doing this *way* faster than I've ever done). Correction on the svn URL: http://svn.secondlife.com/svn/linden/branches/release-candidate/ ...though it's probably more fun to go to this URL: https://svn.secondlife.com/trac/linden/timeline ...and more informative to go to this URL: https://wiki.secondlife.com/wiki/SVN Rob On 6/15/07 4:54 PM, Anthony Foster wrote: > Hello everyone, > > Sorry about the delay in dropping this, I'm still getting used to > having this in the schedule. > > 1.18.0.0 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.0.0 > > Release note information here: > http://blog.secondlife.com/2006/12/21/a-big-change-youll-barely-notice/ > > Checksums: > > 6196a5059acfcd66438ca4b3e72bab78 slviewer-darwin-libs-1.18.0.0.tar.gz > 7e3dd9bf65abb77e4c30d73762fd0f09 slviewer-linux-libs-1.18.0.0.tar.gz > 3ca525ec227bb49d80170112b3051399 slviewer-src-1.18.0.0.tar.gz > 6aa3d8c117d9d051e0ff7c7fc3222600 slviewer-artwork-1.18.0.0.zip > 479d66f6fc104b1ec2afbd79bd4cb38c slviewer-src-1.18.0.0.zip > 073e44d25eeb607f881013cdf0680385 slviewer-win32-libs-1.18.0.0.zip > > SVN checkout: > http://svn.lindenlab.com/svn/linden/branches/release-candidate/ > > 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/20070615/56265271/signature.pgp From jhurliman at wsu.edu Fri Jun 15 18:09:55 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Jun 15 18:10:01 2007 Subject: [sldev] Nicholaz edition? (was: Source release for 1.18.0.0) In-Reply-To: <4673352D.9040107@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> <4673352D.9040107@lindenlab.com> Message-ID: <46733863.7080406@wsu.edu> Nicholaz, are you going to be keeping binaries with your patchsets up to date against the latest releases? Do you think it would be possible to do this with a continuous integration server or automated build server? If you need hardware donations to make something like that happen e-mail me offlist and I can likely dig something up. John Hurliman From okumoto at ucsd.edu Fri Jun 15 18:24:44 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Fri Jun 15 18:24:57 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <4673352D.9040107@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> <4673352D.9040107@lindenlab.com> Message-ID: <46733BDC.5010401@ucsd.edu> Thanks Anthony. Keep them comming :-) Max (Stevex) Rob Lanphier wrote: > Thanks, Anthony! (let's all hear it for him....he's doing this *way* > faster than I've ever done). > > Correction on the svn URL: > http://svn.secondlife.com/svn/linden/branches/release-candidate/ > > ...though it's probably more fun to go to this URL: > https://svn.secondlife.com/trac/linden/timeline > > ...and more informative to go to this URL: > https://wiki.secondlife.com/wiki/SVN > > Rob > > On 6/15/07 4:54 PM, Anthony Foster wrote: > >> Hello everyone, >> >> Sorry about the delay in dropping this, I'm still getting used to >> having this in the schedule. >> >> 1.18.0.0 source release available here: >> https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.0.0 >> >> Release note information here: >> http://blog.secondlife.com/2006/12/21/a-big-change-youll-barely-notice/ >> >> Checksums: >> >> 6196a5059acfcd66438ca4b3e72bab78 slviewer-darwin-libs-1.18.0.0.tar.gz >> 7e3dd9bf65abb77e4c30d73762fd0f09 slviewer-linux-libs-1.18.0.0.tar.gz >> 3ca525ec227bb49d80170112b3051399 slviewer-src-1.18.0.0.tar.gz >> 6aa3d8c117d9d051e0ff7c7fc3222600 slviewer-artwork-1.18.0.0.zip >> 479d66f6fc104b1ec2afbd79bd4cb38c slviewer-src-1.18.0.0.zip >> 073e44d25eeb607f881013cdf0680385 slviewer-win32-libs-1.18.0.0.zip >> >> SVN checkout: >> http://svn.lindenlab.com/svn/linden/branches/release-candidate/ >> >> 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 -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070615/a9069534/attachment-0001.htm From Paul.Hampson at Pobox.com Fri Jun 15 18:40:02 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Fri Jun 15 18:40:11 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <467326B8.2000307@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> Message-ID: <20070616014002.GA31452@keitarou> On Fri, Jun 15, 2007 at 04:54:32PM -0700, Anthony Foster wrote: > 1.18.0.0 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.0.0 > 6196a5059acfcd66438ca4b3e72bab78 slviewer-darwin-libs-1.18.0.0.tar.gz > 7e3dd9bf65abb77e4c30d73762fd0f09 slviewer-linux-libs-1.18.0.0.tar.gz > 3ca525ec227bb49d80170112b3051399 slviewer-src-1.18.0.0.tar.gz > 6aa3d8c117d9d051e0ff7c7fc3222600 slviewer-artwork-1.18.0.0.zip > 479d66f6fc104b1ec2afbd79bd4cb38c slviewer-src-1.18.0.0.zip > 073e44d25eeb607f881013cdf0680385 slviewer-win32-libs-1.18.0.0.zip I see the non-releases have lost their -beta- (or -branch-) tags... Is there anyway we can have them back, or some other way to distinguish release filenames from betas/firstlooks/etc? The reason I ask is that Debian includes an up-to-date checker for package upstreams, which works off a regexp against urls on a page. The regexp that I've been using up until now is: http://secondlife.com/developers/opensource/downloads/.*/.*/slviewer-src[^-]*-(1\..*)\.tar.gz and for the artwork: http://secondlife.com/developers/opensource/downloads/.*/.*/slviewer-artwork[^-]*-(1\..*)\.zip which has happily avoided the -beta- and otherwise tagged versions, such as sculpties. Now it tells me that I'm out of date, and that 1.18.0.0 is out, but of course if I package that, people tracking my packages won't be able to connect to the main grid. ^_^ I do have a kind of loose, long-term plan to parallel-package the beta versions too, once I'm able to turn around builds faster. It'd be nice to be able to construct a regular expression that tells me when those are out of date. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070616/2f9bad83/attachment.pgp From seg at haxxed.com Fri Jun 15 19:31:17 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 15 19:30:47 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <20070616014002.GA31452@keitarou> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> <20070616014002.GA31452@keitarou> Message-ID: <1181961077.15983.74.camel@localhost> On Sat, 2007-06-16 at 11:40 +1000, Paul TBBle Hampson wrote: > I see the non-releases have lost their -beta- (or -branch-) tags... > > Is there anyway we can have them back, or some other way to distinguish > release filenames from betas/firstlooks/etc? I second this. Being unable to tell if you're looking at a beta or a final release from the filename makes things a bit painful for us downstream packagers. -------------- 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/20070615/5696b371/attachment.pgp From dzonatas at dzonux.net Fri Jun 15 20:22:48 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jun 15 20:22:22 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <1181961077.15983.74.camel@localhost> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> <20070616014002.GA31452@keitarou> <1181961077.15983.74.camel@localhost> Message-ID: <46735788.8020800@dzonux.net> Callum Lerwick wrote: > On Sat, 2007-06-16 at 11:40 +1000, Paul TBBle Hampson wrote: > >> I see the non-releases have lost their -beta- (or -branch-) tags... >> >> Is there anyway we can have them back, or some other way to distinguish >> release filenames from betas/firstlooks/etc? >> > > I second this. Being unable to tell if you're looking at a beta or a > final release from the filename makes things a bit painful for us > downstream packagers. > That is the way it was around 1.13 and 1.14. It was much harder to tell exactly where things went. I vote to make odd version numbers the beta, like the way Linux does it. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070615/a57ad240/attachment.htm From robla at lindenlab.com Fri Jun 15 21:12:11 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jun 15 21:12:27 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <20070616014002.GA31452@keitarou> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> <20070616014002.GA31452@keitarou> Message-ID: <4673631B.4020908@lindenlab.com> I'll update our internal source release documentation to reflect this. I had no idea that I was being so consistent such that my naming could be captured by a regexp, or that people were relying on it. Rob On 6/15/07 6:40 PM, Paul TBBle Hampson wrote: > On Fri, Jun 15, 2007 at 04:54:32PM -0700, Anthony Foster wrote: > >> 1.18.0.0 source release available here: >> https://wiki.secondlife.com/wiki/Source_downloads#ver_1.18.0.0 >> > > >> 6196a5059acfcd66438ca4b3e72bab78 slviewer-darwin-libs-1.18.0.0.tar.gz >> 7e3dd9bf65abb77e4c30d73762fd0f09 slviewer-linux-libs-1.18.0.0.tar.gz >> 3ca525ec227bb49d80170112b3051399 slviewer-src-1.18.0.0.tar.gz >> 6aa3d8c117d9d051e0ff7c7fc3222600 slviewer-artwork-1.18.0.0.zip >> 479d66f6fc104b1ec2afbd79bd4cb38c slviewer-src-1.18.0.0.zip >> 073e44d25eeb607f881013cdf0680385 slviewer-win32-libs-1.18.0.0.zip >> > > I see the non-releases have lost their -beta- (or -branch-) tags... > > Is there anyway we can have them back, or some other way to distinguish > release filenames from betas/firstlooks/etc? > > The reason I ask is that Debian includes an up-to-date checker for > package upstreams, which works off a regexp against urls on a page. > > The regexp that I've been using up until now is: > http://secondlife.com/developers/opensource/downloads/.*/.*/slviewer-src[^-]*-(1\..*)\.tar.gz > and for the artwork: > http://secondlife.com/developers/opensource/downloads/.*/.*/slviewer-artwork[^-]*-(1\..*)\.zip > which has happily avoided the -beta- and otherwise tagged versions, > such as sculpties. > > Now it tells me that I'm out of date, and that 1.18.0.0 is out, but of > course if I package that, people tracking my packages won't be able to > connect to the main grid. ^_^ > > I do have a kind of loose, long-term plan to parallel-package the beta > versions too, once I'm able to turn around builds faster. It'd be nice > to be able to construct a regular expression that tells me when those > are out of date. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20070615/312def22/signature.pgp From matthew.dowd at hotmail.co.uk Sat Jun 16 03:08:23 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jun 16 03:08:25 2007 Subject: [sldev] Re: More plugin / platform harping.. Message-ID: Mmmm, i personally think that this is a red herring. "A steep learning curve has led a large percentage of new users ? as many as 90 percent, according to Linden Lab?s own estimates ? to abandon the service within a few months of thier arrival in-world." I'm not convinced that many of this 90% who leave are because of UI issues - in any case anyone having trouble with the viewer UI would likely give up after a few hours, not months! Some of the 90% give up becaause they can't work out what they are supposed to do in SL or how to meet people - that is no different from RL, the feeling during the first few days is similar to when you start a new job, a new school, move to a new town/country where you aren't sure what you are doing, how things work, don't know people to talk to etc. This is a social problem requiring social solutions not technical ones, and the changes to the welcome programme would address this (whether the particular direction LL are currently taking is the correct one or not is a different debate) Some will just get bored when the novelty wears off - this is inevitable... The majority of the 90% who give up do so due to the various problems which cause them loss of time, effort and/or money. The most common one will be inventory loss. Regardless of what the TOS claim items in the inventory do have a value to their owner (either monetary, or time/effort in finding/building it). An inventory loss feels like a kick in the stomach, and the initial reaction is to want to never touch SL again - some get through it and return. Many do not. However, the other issues such as Lindex failing, search failing, asset server problems, are impacting on people either selling or creating, and even long timers are giving up that the return and frustration isn't worth the effort. This isn't meant to be a rant - but a steer that at the moment, in terms of improving the retention rate, effort would be better spent on dealing with the relability problems, particular those around inventory, then plugin or extensible API architectures. Matthew ---------------------------------------- > Date: Thu, 14 Jun 2007 14:36:27 -0700 > From: tshephard@gmail.com > To: sldev@lists.secondlife.com > Subject: [sldev] Re: More plugin / platform harping.. > > "Open source Second Life add-ons still months away" > > http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ > > > Interesting reading... No mention of the license though, which is the > only thing that interests me. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From tateru.nino at gmail.com Sat Jun 16 03:13:12 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Jun 16 03:13:19 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: References: Message-ID: <4673B7B8.4090607@gmail.com> Matthew Dowd wrote: > Mmmm, i personally think that this is a red herring. > > "A steep learning curve has led a large percentage of new users ? as many as 90 percent, according to Linden Lab?s own estimates ? to abandon the service within a few months of thier arrival in-world." > > I'm not convinced that many of this 90% who leave are because of UI issues - in any case anyone having trouble with the viewer UI would likely give up after a few hours, not months! I have to agree. Having ushered in around about 12,000 new residents, the UI isn't so much of a problem. For beginners there's just too *much* UI and you could hide 60% of it for them - but their problems are more about being overwhelmed and without direction or peer support. Any UI difficulties are just icing on that making the already difficult, just a little more difficult than it needs to be. That needs to be dealt with at some point, admittedly - but it's not the scary UI that's frightening people away. -- Tateru Nino http://dwellonit.blogspot.com/ From nicholaz at blueflash.cc Sat Jun 16 04:17:10 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 16 04:17:31 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <4673B7B8.4090607@gmail.com> References: <4673B7B8.4090607@gmail.com> Message-ID: <4673C6B6.6050002@blueflash.cc> > Matthew Dowd wrote: > However, the other issues such as Lindex failing, search failing, asset > server problems, are impacting on people either selling or creating, > and even long timers are giving up that the return and frustration > isn't worth the effort. not convinced that many of this 90% who leave > are because of UI issues - in any case anyone having trouble with the > viewer UI would likely give up after a few hours, not months! Tateru Nino wrote: > I have to agree. Having ushered in around about 12,000 new residents, > the UI isn't so much of a problem. For beginners there's just too *much* > UI and you could hide 60% of it for them - but their problems are more > about being overwhelmed and without direction or peer support. Any UI > difficulties are just icing on that making the already difficult, just a > little more difficult than it needs to be. That needs to be dealt with > at some point, admittedly - but it's not the scary UI that's frightening > people away. I have to agree here too. I have just introduced a handful of people to the program but I had my downs as well. The first hurdle (like the UI, not being able to complete orientation island, etc.) will make you quit within hours or a few days. After that, it will be a mixture of things. Either the whole thing getting stale (when novelty wears off) or the permanent crashes, outages, poor performance, etc. I've been at this place a couple of times myself, asking myself why the heck I'm enduring this, despite the efforts I put into the program (the last one was the inability to convert US$ to Linden for over a week with a perfectly valid credit card). The people I know who stay, do so because of the friends they met or things they found but this seems to be constantly counterbalanced by the problems with the software, service, etc. I think you see this on the blog. What people are complaining about are outages of service and bugs, and it may be just me seeing it that way, but bug fixes (or even the announcement that Windlight will be taken off for some time to get things right) are met with outright enthusiasm. Nick From nicholaz at blueflash.cc Sat Jun 16 05:01:35 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 16 05:01:52 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <467326B8.2000307@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> Message-ID: <4673D11F.70704@blueflash.cc> Did anyone try this yet under Windows? ------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ Executing pre-build batch file '"../../scripts/template_verifier.py"' is not recognized as an internal or external command, operable program or batch file. PREBUILD FAILED newview : error PRJ0002 : error result returned from 'w:\sl1_18_0_0\linden\indra\newview\ReleaseForDownload\BAT00002E.bat'. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Sat Jun 16 05:16:50 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 16 05:17:06 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <467326B8.2000307@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> Message-ID: <4673D4B2.4040705@blueflash.cc> I've seen a lot of changes in the message system (llmessage) and found this in the release notes: +Release Notes for Second Life 1.18.0(0) June 14, 2007 +===================================== +Changes: +* Message system changes to support transport via TCP (HTTP) as well as UDP. +** More details are available here: http://blog.secondlife.com/2006/12/21/a-big-change-youll-barely-notice/ + Release Notes for Second Life 1.17.0(12) June 13, 2007 ===================================== Changes: Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Sat Jun 16 07:29:27 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 16 07:29:47 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <4672BE36.2020407@gmail.com> References: <46677B4A.1010105@gmail.com> <1181606570.9159.17.camel@localhost> <466DFECE.9080805@gmail.com> <1181879051.15983.17.camel@localhost> <46720C1C.3030907@gmail.com> <1674f6c70706150914o119ba9e5s3fbea14070d8030c@mail.gmail.com> <4672BE36.2020407@gmail.com> Message-ID: <4673F3C7.6080700@blueflash.cc> Tateru Nino wrote: > Footnote....is it my imagination or is the viewer ALREADY writing that > texture list out to disk on exit? I didn't see anything new in the source that would like this. Nick From tateru.nino at gmail.com Sat Jun 16 07:34:04 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Jun 16 07:34:10 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <4673F3C7.6080700@blueflash.cc> References: <46677B4A.1010105@gmail.com> <1181606570.9159.17.camel@localhost> <466DFECE.9080805@gmail.com> <1181879051.15983.17.camel@localhost> <46720C1C.3030907@gmail.com> <1674f6c70706150914o119ba9e5s3fbea14070d8030c@mail.gmail.com> <4672BE36.2020407@gmail.com> <4673F3C7.6080700@blueflash.cc> Message-ID: <4673F4DC.4070509@gmail.com> I just discovered the existance of ...Application Data\SecondLife\Firstname_Lastname\texture_list_last.xml Which, on the surface of it would seem to be the data that we want. Nicholaz Beresford wrote: > Tateru Nino wrote: >> Footnote....is it my imagination or is the viewer ALREADY writing that >> texture list out to disk on exit? > > I didn't see anything new in the source that would like this. > > > Nick > -- Tateru Nino http://dwellonit.blogspot.com/ From nicholaz at blueflash.cc Sat Jun 16 10:15:32 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 16 10:15:56 2007 Subject: [sldev] Silly suggestion - improved initial rez time In-Reply-To: <4673F4DC.4070509@gmail.com> References: <46677B4A.1010105@gmail.com> <1181606570.9159.17.camel@localhost> <466DFECE.9080805@gmail.com> <1181879051.15983.17.camel@localhost> <46720C1C.3030907@gmail.com> <1674f6c70706150914o119ba9e5s3fbea14070d8030c@mail.gmail.com> <4672BE36.2020407@gmail.com> <4673F3C7.6080700@blueflash.cc> <4673F4DC.4070509@gmail.com> Message-ID: <46741AB4.2020909@blueflash.cc> Oops, could be I just missed it. :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Tateru Nino wrote: > I just discovered the existance of ...Application > Data\SecondLife\Firstname_Lastname\texture_list_last.xml > > Which, on the surface of it would seem to be the data that we want. > > Nicholaz Beresford wrote: >> Tateru Nino wrote: >>> Footnote....is it my imagination or is the viewer ALREADY writing that >>> texture list out to disk on exit? >> I didn't see anything new in the source that would like this. >> >> >> Nick >> > From giff at electricsheepcompany.com Sat Jun 16 11:14:05 2007 From: giff at electricsheepcompany.com (Giff Constable) Date: Sat Jun 16 11:14:08 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: References: Message-ID: <22f0f2220706161114t78719d50x32a6c627d9ccfe11@mail.gmail.com> I disagree. I think we do need more than a simpler UI - of course -- but I think just making performance improvements -- which are of course very important -- doesn't solve enough of the retention problem. It removes some frustration, but it doesn't enable a better way to work with a virtual world. It doesn't solve problems with what to do, who to meet, where to go, etc. Allowing 3rd party innovation in and on top of the client can do that. Maybe it's back to the old debate of immersionists versus platformists, but I'm amazed when people don't understand the power an extendable and programmable UI can bring SL. If this is supposed to be a metaverse platform, let's make it a great platform rather than just a cool world. Not trying to offend anyone here, but just sharing how I look at all of this. Giff Constable / Forseti Svarog On 6/16/07, Matthew Dowd wrote: > > > Mmmm, i personally think that this is a red herring. > > "A steep learning curve has led a large percentage of new users ? as many > as 90 percent, according to Linden Lab's own estimates ? to abandon the > service within a few months of thier arrival in-world." > > I'm not convinced that many of this 90% who leave are because of UI issues > - in any case anyone having trouble with the viewer UI would likely give up > after a few hours, not months! > > Some of the 90% give up becaause they can't work out what they are > supposed to do in SL or how to meet people - that is no different from RL, > the feeling during the first few days is similar to when you start a new > job, a new school, move to a new town/country where you aren't sure what you > are doing, how things work, don't know people to talk to etc. This is a > social problem requiring social solutions not technical ones, and the > changes to the welcome programme would address this (whether the particular > direction LL are currently taking is the correct one or not is a different > debate) > > Some will just get bored when the novelty wears off - this is > inevitable... > > The majority of the 90% who give up do so due to the various problems > which cause them loss of time, effort and/or money. The most common one will > be inventory loss. Regardless of what the TOS claim items in the inventory > do have a value to their owner (either monetary, or time/effort in > finding/building it). An inventory loss feels like a kick in the stomach, > and the initial reaction is to want to never touch SL again - some get > through it and return. Many do not. However, the other issues such as Lindex > failing, search failing, asset server problems, are impacting on people > either selling or creating, and even long timers are giving up that the > return and frustration isn't worth the effort. > > This isn't meant to be a rant - but a steer that at the moment, in terms > of improving the retention rate, effort would be better spent on dealing > with the relability problems, particular those around inventory, then plugin > or extensible API architectures. > > Matthew > > > ---------------------------------------- > > Date: Thu, 14 Jun 2007 14:36:27 -0700 > > From: tshephard@gmail.com > > To: sldev@lists.secondlife.com > > Subject: [sldev] Re: More plugin / platform harping.. > > > > "Open source Second Life add-ons still months away" > > > > > http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ > > > > > > Interesting reading... No mention of the license though, which is the > > only thing that interests me. > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _________________________________________________________________ > Feel like a local wherever you go with BackOfMyHand.com > http://www.backofmyhand.com_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070616/28dd1bf7/attachment.htm From tshephard at gmail.com Sat Jun 16 12:03:54 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Jun 16 12:03:55 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <4673C6B6.6050002@blueflash.cc> References: <4673B7B8.4090607@gmail.com> <4673C6B6.6050002@blueflash.cc> Message-ID: <3b19a500706161203l2adccb1j8333524e295508e9@mail.gmail.com> What will win people into the platform are scenarios. Apple is good at this, for example. iPhoto, Email, Garage Band, iWeb, iMovie, etc. What are the scenarios that win people into SL? Connecting with friends, Dressing Up Your Avatar, Immersive Education, Virtual Business Meetings, Games, Watching Virtual Sports, Community Gatherings, etc .. the list goes on. The key here is to enumerate the scenarios that bring out the value proposition of SL - what can SL do that you can not do elsewhere. Linden Lab's job is to provide a platform that enables us, as developers, to implement those scenarios. Lindex, Windlight, Voice .. these are all perfect examples and well done. That match that will light the wildfire will be plugins, an application API for SL / 3D platform so we (the sldev) can implement the software that will enable the scenarios, the killer apps that will create real value in SL. Pretty much every major applications has a plugin mechanism, and for good reason. None of them require a special license in order to develop those plugins. On 6/16/07, Nicholaz Beresford wrote: > > Matthew Dowd wrote: > > However, the other issues such as Lindex failing, search failing, asset > > server problems, are impacting on people either selling or creating, > > and even long timers are giving up that the return and frustration > > isn't worth the effort. not convinced that many of this 90% who leave > > are because of UI issues - in any case anyone having trouble with the > > viewer UI would likely give up after a few hours, not months! > > Tateru Nino wrote: > > I have to agree. Having ushered in around about 12,000 new residents, > > the UI isn't so much of a problem. For beginners there's just too *much* > > UI and you could hide 60% of it for them - but their problems are more > > about being overwhelmed and without direction or peer support. Any UI > > difficulties are just icing on that making the already difficult, just a > > little more difficult than it needs to be. That needs to be dealt with > > at some point, admittedly - but it's not the scary UI that's frightening > > people away. > > > I have to agree here too. I have just introduced a handful of people to > the program but I had my downs as well. > > The first hurdle (like the UI, not being able to complete orientation > island, etc.) will make you quit within hours or a few days. > > After that, it will be a mixture of things. Either the whole thing > getting stale (when novelty wears off) or the permanent crashes, outages, > poor performance, etc. I've been at this place a couple of times myself, > asking myself why the heck I'm enduring this, despite the efforts I put > into the program (the last one was the inability to convert US$ to Linden > for over a week with a perfectly valid credit card). > > The people I know who stay, do so because of the friends they met or > things they found but this seems to be constantly counterbalanced by > the problems with the software, service, etc. > > I think you see this on the blog. What people are complaining about are > outages of service and bugs, and it may be just me seeing it that way, > but bug fixes (or even the announcement that Windlight will be taken off > for some time to get things right) are met with outright enthusiasm. > > > Nick > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From seg at haxxed.com Sat Jun 16 13:16:43 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jun 16 13:17:11 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <3b19a500706161203l2adccb1j8333524e295508e9@mail.gmail.com> References: <4673B7B8.4090607@gmail.com> <4673C6B6.6050002@blueflash.cc> <3b19a500706161203l2adccb1j8333524e295508e9@mail.gmail.com> Message-ID: <1182025003.25245.4.camel@localhost.localdomain> On Sat, 2007-06-16 at 12:03 -0700, Tim Shephard wrote: > That match that will light the wildfire will be plugins, an > application API for SL / 3D platform so we (the sldev) can implement > the software that will enable the scenarios, the killer apps that will > create real value in SL. No one is preventing you from doing whatever the hell it is you're planning but yourself. Your income is not Linden Lab's problem. Unless maybe they hire you... Your overinflated sense of entitlement is getting tiring. -------------- 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/20070616/108f91f8/attachment.pgp From Paul.Hampson at Pobox.com Sat Jun 16 14:04:57 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Sat Jun 16 14:05:07 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <46735788.8020800@dzonux.net> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <467326B8.2000307@lindenlab.com> <20070616014002.GA31452@keitarou> <1181961077.15983.74.camel@localhost> <46735788.8020800@dzonux.net> Message-ID: <20070616210457.GA7729@keitarou> On Fri, Jun 15, 2007 at 08:22:48PM -0700, Dzonatas wrote: > Callum Lerwick wrote: > >On Sat, 2007-06-16 at 11:40 +1000, Paul TBBle Hampson wrote: > > > >>I see the non-releases have lost their -beta- (or -branch-) tags... > >>Is there anyway we can have them back, or some other way to distinguish > >>release filenames from betas/firstlooks/etc? > >> > >I second this. Being unable to tell if you're looking at a beta or a > >final release from the filename makes things a bit painful for us > >downstream packagers. > That is the way it was around 1.13 and 1.14. It was much harder to tell exactly where things went. > I vote to make odd version numbers the beta, like the way Linux does it. Uh, Linux stopped doing that about 2005, if I recall correctly part of the bitkeeper parting-of-ways changed it to every kernel is "stable enough", and downstream packagers get to worry about what level of stable they need to worry about. I guess GTK still does it though. And Gnome. I guess this'd be OK too, but it certainly makes things a little harder on the repository user, since the thing branches into, say, branch-for-1-18, but it's version is 1.17 until tagged stable. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070617/05b50086/attachment.pgp From gigstaggart at gmail.com Sat Jun 16 14:56:50 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jun 16 14:57:09 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <1181932052.15983.55.camel@localhost> References: <3b19a500706141405w45fc7768ha7d498349f052bb8@mail.gmail.com> <3b19a500706141436w1396cd9bqa0a6c8a4ed0596ec@mail.gmail.com> <1181932052.15983.55.camel@localhost> Message-ID: <46745CA2.4070705@gmail.com> Callum Lerwick wrote: > On Thu, 2007-06-14 at 14:36 -0700, Tim Shephard wrote: >> "Open source Second Life add-ons still months away" >> >> http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ > > What that article doesn't mention, is re-basing patching upon a new > release is *easy*... if you have access to upstream's SCM. That's irrelevant. I can't turn a customer loose on some libsl based project or even a patched client. I'd have to bill them an hour or so every two weeks when it breaks. People don't like software that breaks every two weeks. Upgrading from the official source they could handle, but relying on me to compile something for them every two weeks until the end of time isn't really viable. -Jason From dzonatas at dzonux.net Sat Jun 16 15:21:34 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jun 16 15:21:06 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <46745CA2.4070705@gmail.com> References: <3b19a500706141405w45fc7768ha7d498349f052bb8@mail.gmail.com> <3b19a500706141436w1396cd9bqa0a6c8a4ed0596ec@mail.gmail.com> <1181932052.15983.55.camel@localhost> <46745CA2.4070705@gmail.com> Message-ID: <4674626E.6010609@dzonux.net> Jason Giglio wrote: > Callum Lerwick wrote: >> On Thu, 2007-06-14 at 14:36 -0700, Tim Shephard wrote: >>> "Open source Second Life add-ons still months away" >>> >>> http://secondlife.reuters.com/stories/2007/06/14/open-source-second-life-add-ons-still-months-away/ >>> >> >> What that article doesn't mention, is re-basing patching upon a new >> release is *easy*... if you have access to upstream's SCM. > > That's irrelevant. I can't turn a customer loose on some libsl based > project or even a patched client. I'd have to bill them an hour or so > every two weeks when it breaks. People don't like software that > breaks every two weeks. Upgrading from the official source they could > handle, but relying on me to compile something for them every two > weeks until the end of time isn't really viable. > We learn that quite fast in this case. There is no simple solution at this time. The code, however, could be split-up as it is today. There are many parts of the viewer that could reside in a separate package, which is being subjective to a plug-in system. -- Power to Change the Void From seg at haxxed.com Sat Jun 16 19:41:27 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jun 16 19:40:53 2007 Subject: [sldev] Source release for 1.17.0.12 In-Reply-To: <4672DB69.7040302@lindenlab.com> References: <4668965B.8080400@lindenlab.com> <466DF8A0.1000600@lindenlab.com> <467045DB.7090407@lindenlab.com> <20070615011551.GA13282@keitarou> <4671E9FE.4000202@lindenlab.com> <1181877671.15983.12.camel@localhost> <4672DB69.7040302@lindenlab.com> Message-ID: <1182048087.17082.6.camel@localhost> On Fri, 2007-06-15 at 11:33 -0700, Bryan O'Sullivan wrote: > Hmm. A 32-bit build works for me, but a 64-bit build gives me almost > everything rendered in grey. It's possible that's due to a bug in the > 64-bit version of Mesa or X.org i810 driver. What hardware and driver > are you running the 64-bit viewer on? My wife's eMachines m6805 laptop. Mobile Radeon 9600. Used to run with fglrx, but fglrx seems to no likey F7 yet so its running with the open source r300 driver at the moment. Which apparently works now (!) but you don't get vertex or fragment programs yet. Or occlusion query... -------------- 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/20070616/e41d0a56/attachment.pgp From matthew.dowd at hotmail.co.uk Sun Jun 17 01:56:04 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Jun 17 01:56:06 2007 Subject: [sldev] Jira issue Message-ID: I've been trying to add some new entries to jira (things like being able to get at the new parcel voice flags from LSL), but keep gettng an error "docs out of order". I did some google and came across this - http://jira.atlassian.com/browse/JRA-11861 i.e. it is a known bug in 3.7.1 fixed in 3.7.2 to do with an index problem. The secondlife jira appears to be on 3.7.1 ! Of course, I suppose I should really report this on jira itself, but if I try I get an error "docs out of order", so I thought I'd post here in the hope one of the Lindens can pick this up. Matthew _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From matthew.dowd at hotmail.co.uk Sun Jun 17 02:31:52 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Jun 17 02:31:54 2007 Subject: [sldev] Re: More plugin / platform harping.. Message-ID: I'm not saying have a means to add extensions to the viewer which do not break every minor update isn't important, just that it isn't a priority. What you are describing may bring more people into SL, and may make more people see the potential and relevance once they get there, however, it doesn't matter how extensible or powerful or versatile the platform is, whe you are lost yet another days work due to inventory loss, or given up working in SL for the day yet again because it is too laggy, or xyz is broken etc. people aren't going to be motivated to continue using SL regardless how clever or impressive third party extensions are! Jason was saying that he doesn't want to build extensions around the the current sourcecode since it would break every few weeks until he recompiled the code and his customers would not be impressed as "People don't like software that breaks every two weeks." The same sentiment applies to SL itself, Jason probably doesn't want the same customers coming to him complaining of problems in his extension which are really SL reliability problems. To repeat that sentiment "People don't like software that breaks every two weeks.", which is a good description of SL at the moment, and I do believe that the bulk of the 90% of signups SL currently loses are due to reliability issues, not the lack of additional plugins and given the choice of having a reliable SL platform or some clever plugins would opt for the former. Also the lack of such tools isn't dampening the high interest rate or initial sign up at the moment, either. Successful platforms are both extensible and reliable, and at the moment my belief is that the emphasis should be on the reliability to retain the existing users before adding plugin APIs to allow third party extensions to attract and retain new users. Matthew ________________________________ > Date: Sat, 16 Jun 2007 14:14:05 -0400 > From: giff@electricsheepcompany.com > To: sldev@lists.secondlife.com > Subject: Re: [sldev] Re: More plugin / platform harping.. > > I disagree. I think we do need more than a simpler UI - of course -- but I think just making performance improvements -- which are of course very important -- doesn't solve enough of the retention problem. It removes some frustration, but it doesn't enable a better way to work with a virtual world. It doesn't solve problems with what to do, who to meet, where to go, etc. Allowing 3rd party innovation in and on top of the client can do that. > Maybe it's back to the old debate of immersionists versus platformists, but I'm amazed when people don't understand the power an extendable and programmable UI can bring SL. If this is supposed to be a metaverse platform, let's make it a great platform rather than just a cool world. > Not trying to offend anyone here, but just sharing how I look at all of this. _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk From jhurliman at wsu.edu Sun Jun 17 02:58:05 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Jun 17 02:58:10 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: References: Message-ID: <467505AD.7030505@wsu.edu> Matthew Dowd wrote: > I'm not saying have a means to add extensions to the viewer which do not break every minor update isn't important, just that it isn't a priority. > > What you are describing may bring more people into SL, and may make more people see the potential and relevance once they get there, however, it doesn't matter how extensible or powerful or versatile the platform is, whe you are lost yet another days work due to inventory loss, or given up working in SL for the day yet again because it is too laggy, or xyz is broken etc. people aren't going to be motivated to continue using SL regardless how clever or impressive third party extensions are! > > Jason was saying that he doesn't want to build extensions around the the current sourcecode since it would break every few weeks until he recompiled the code and his customers would not be impressed as "People don't like software that breaks every two weeks." The same sentiment applies to SL itself, Jason probably doesn't want the same customers coming to him complaining of problems in his extension which are really SL reliability problems. > > To repeat that sentiment "People don't like software that breaks every two weeks.", which is a good description of SL at the moment, and I do believe that the bulk of the 90% of signups SL currently loses are due to reliability issues, not the lack of additional plugins and given the choice of having a reliable SL platform or some clever plugins would opt for the former. Also the lack of such tools isn't dampening the high interest rate or initial sign up at the moment, either. > > Successful platforms are both extensible and reliable, and at the moment my belief is that the emphasis should be on the reliability to retain the existing users before adding plugin APIs to allow third party extensions to attract and retain new users. > > Matthew > I don't have access to the database clusters or the simulator source code to work on making the grid more reliable. If I see something in the client source code that could make things more stable or reliable I'll report it and/or submit a patch for it, so your request is going to the wrong audience here. Whether the open source developers on sldev choose to work on UI improvements or UI exensibility or something else entirely doesn't change the stability of the grid, so bringing that up is a bit of a red herring to the discussion. "Fix the grid" might be a trump card to throw at Linden developers (even if many of them are 3D programmers and have no idea how the backend services work? I never understood that part), but no one here can help grid stability other than posting bug reports with useful information and repros. John From nicholaz at blueflash.cc Sun Jun 17 03:23:48 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 17 03:24:07 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <467505AD.7030505@wsu.edu> References: <467505AD.7030505@wsu.edu> Message-ID: <46750BB4.2050304@blueflash.cc> >"Fix the grid" might be a trump card > to throw at Linden developers (even if many of them are 3D programmers > and have no idea how the backend services work? I never understood that > part), but no one here can help grid stability other than posting bug > reports with useful information and repros. I guess that's about in line with how I'd see it, that is plugins and skins are nice, but low priority as long as the grid rattles along it's upper limit of capacity anyway. I see no point in taking a huge part of the developers and deveop something that would take the whole thing to a level of load which it can't run anyway. So my priority list would be 1) fix the grid 2) fix the viewer 3) improve grid performance 4) improve viewer performance 5) add new features 6) fix the grid 7) fix the viewer 8) improve grid performance 9) improve viewer performance 10) add plugin, skins and bells and whistles (Voice would fall under 5 and Windlight under 10 in my personal list) However, one thing that may be helpful though, would be to make more viewer updates optional, I'm not sure if the changes between 16 and 17 would be really mandatory in terms of underlying protocol. Nick From signore at autistiche.org Sun Jun 17 05:46:50 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Sun Jun 17 05:47:03 2007 Subject: [sldev] compiling viewer with FMOD=no fails on Linux Message-ID: compiling the viewer with FMOD=no fails for me on Linux it complains about non-existent libfmod-3.75.so see http://pastebin.ca/570717 now I'm going to try again however these sources compiled correctly here if I let FMOD enabled and copy FMOD files according to the wiki page I'm quite sure FMOD=no worked for me with previous sources I'm on Linux Ubuntu Feisty, here are some info about my system http://signore.wordpress.com/2007/01/14/my-system-specs/ (please tell me what other info I should give about it) bye Signore Iredell From signore at autistiche.org Sun Jun 17 06:22:11 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Sun Jun 17 06:22:13 2007 Subject: [sldev] Re: updating "Compile the view (Linux)" on the wiki Message-ID: (sorry for breaking the thread) > I'm trying to update the wiki page on how to build > from source the secondlife client. Can people look > it over and see if the changes that I made, make sense? I hope someone else did it. I am not skilled enough to tell if the whole page is actually correct. I can say it looks less messy than before, though :-) * Most of the page is about Henri Beauchamp's script. I think we should move it to a new page. * The rest of the page mostly explains how to build the viewer without using the LL libraries bundle. We could reorganize these instructions in a better way? (I mean: separate the with-bundle build-process from the without-bundle one) * It would be interesting for me to know if this way (without using the libraries bundle) I can get (even slightly) better performances. I never managed to build the viewer this way so far (I can't build xmlrpc-epi). I can usually build the viewer from sources when using the LL prepackaged libraries bundle, though. * We should include some basic info about compiling from SVN too. If I'm not wrong, SVN is the only way to get a WindLight-enabled Linux viewer right now. bye Signore Iredell From dale at daleglass.net Sun Jun 17 06:51:46 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Jun 17 06:52:17 2007 Subject: [sldev] Re: updating "Compile the view (Linux)" on the wiki In-Reply-To: References: Message-ID: <200706171551.56368.dale@daleglass.net> ? ????????? ?? 17 ???? 2007 15:22 signore@autistiche.org ???????(a): > * We should include some basic info about compiling > from SVN too. If I'm not wrong, SVN is the only way to get > a WindLight-enabled Linux viewer right now. > Working on 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/20070617/d0a8018b/attachment.pgp From dale at daleglass.net Sun Jun 17 07:12:40 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Jun 17 07:12:51 2007 Subject: [sldev] Re: updating "Compile the view (Linux)" on the wiki In-Reply-To: <200706171551.56368.dale@daleglass.net> References: <200706171551.56368.dale@daleglass.net> Message-ID: <200706171612.45460.dale@daleglass.net> ? ????????? ?? 17 ???? 2007 15:51 Dale Glass ???????(a): > ? ????????? ?? 17 ???? 2007 15:22 signore@autistiche.org ???????(a): > > * We should include some basic info about compiling > > from SVN too. If I'm not wrong, SVN is the only way to get > > a WindLight-enabled Linux viewer right now. > > Working on it. Ok, made some changes, does it look good? -------------- 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/20070617/3bee1811/attachment.pgp From okumoto at ucsd.edu Sun Jun 17 12:06:02 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sun Jun 17 12:06:08 2007 Subject: [sldev] compiling viewer with FMOD=no fails on Linux In-Reply-To: References: Message-ID: <4675861A.7020701@ucsd.edu> Hi Signore, Even when you set FMOD=no you still have to comment out the libfmod line in indra/newview/viewer_manifest.py Max signore@autistiche.org wrote: > compiling the viewer with FMOD=no fails for me on Linux > > it complains about non-existent libfmod-3.75.so > > see http://pastebin.ca/570717 > > now I'm going to try again > > > however these sources compiled correctly here if I let > FMOD enabled and copy FMOD files according to the wiki page > > I'm quite sure FMOD=no worked for me with previous sources > > > I'm on Linux Ubuntu Feisty, here are some info about my system > http://signore.wordpress.com/2007/01/14/my-system-specs/ > (please tell me what other info I should give about it) > > bye > Signore Iredell > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From okumoto at ucsd.edu Sun Jun 17 12:14:14 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sun Jun 17 12:14:17 2007 Subject: [sldev] Re: updating "Compile the view (Linux)" on the wiki In-Reply-To: References: Message-ID: <46758806.60105@ucsd.edu> Thanks for looking it over. I'm glad that it is less messy too :-) And yes the bottom half still needs work. But I was first going to see if anyone had comments about how I was changing the page before I proceeded. Depending on how the rest of the page looks, I may split it into a few pages. But thanks for the feed back. Max signore@autistiche.org wrote: > (sorry for breaking the thread) > > >> I'm trying to update the wiki page on how to build >> from source the secondlife client. Can people look >> it over and see if the changes that I made, make sense? >> > > I hope someone else did it. I am not skilled enough to > tell if the whole page is actually correct. > I can say it looks less messy than before, though :-) > > * Most of the page is about Henri Beauchamp's script. > I think we should move it to a new page. > > * The rest of the page mostly explains how to build > the viewer without using the LL libraries bundle. > We could reorganize these instructions in a better way? > (I mean: separate the with-bundle build-process from > the without-bundle one) > > * It would be interesting for me to know if this way > (without using the libraries bundle) I can get (even > slightly) better performances. I never managed to > build the viewer this way so far (I can't build xmlrpc-epi). > I can usually build the viewer from sources when using > the LL prepackaged libraries bundle, though. > > * We should include some basic info about compiling > from SVN too. If I'm not wrong, SVN is the only way to get > a WindLight-enabled Linux viewer right now. > > bye > Signore Iredell > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From okumoto at ucsd.edu Sun Jun 17 12:28:58 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sun Jun 17 12:29:01 2007 Subject: [sldev] Re: updating "Compile the view (Linux)" on the wiki In-Reply-To: <200706171612.45460.dale@daleglass.net> References: <200706171551.56368.dale@daleglass.net> <200706171612.45460.dale@daleglass.net> Message-ID: <46758B7A.5080005@ucsd.edu> Dale Glass wrote: > ? ????????? ?? 17 ???? 2007 15:51 Dale Glass ???????(a): > >> ? ????????? ?? 17 ???? 2007 15:22 signore@autistiche.org ???????(a): >> >>> * We should include some basic info about compiling >>> from SVN too. If I'm not wrong, SVN is the only way to get >>> a WindLight-enabled Linux viewer right now. >>> >> Working on it. >> > > Ok, made some changes, does it look good? > Hi Dale, The changes look good to me. Max From dzonatas at dzonux.net Sun Jun 17 15:42:48 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jun 17 15:42:17 2007 Subject: [sldev] JIRA Message-ID: <4675B8E8.1020008@dzonux.net> Looks like public had a hiccup today. There are several duplicate issues created one after another by different residents. I linked the ones I found. I could not close them, however. -- Power to Change the Void From nicholaz at blueflash.cc Sun Jun 17 15:45:30 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 17 15:45:46 2007 Subject: [sldev] JIRA In-Reply-To: <4675B8E8.1020008@dzonux.net> References: <4675B8E8.1020008@dzonux.net> Message-ID: <4675B98A.6090409@blueflash.cc> It seems to do that on weekends (I think this is the 3rd week in a row). Had that myself, get an error on posting the issue, try again and there it is twice. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dzonatas wrote: > Looks like public had a hiccup today. There are several duplicate issues > created one after another by different residents. I linked the ones I > found. I could not close them, however. > From nicholaz at blueflash.cc Sun Jun 17 15:47:00 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 17 15:47:15 2007 Subject: [sldev] SSE2 on MSVC Message-ID: <4675B9E4.4000106@blueflash.cc> Dunno if the code bit below makes any sense (I haven't got much idea what SSE2 is, despite having read it on Wikipedia), but what do you think? // // enable MSFT SSE2 extensions // CProcessor cproc; const ProcessorInfo *pinfo= cproc.GetCPUInfo(); int sse2= FALSE; if (pinfo->_Ext.SSE2_StreamingSIMD2_Extensions) { // http://msdn2.microsoft.com/en-us/library/bthd138d(VS.80).aspx sse2= _set_SSE2_enable(TRUE); } llinfos << "running with" << (!sse2 ? "out" : "" ) << " _set_sse2_enabled " << llendl; Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From josh at lindenlab.com Sun Jun 17 15:51:16 2007 From: josh at lindenlab.com (josh@lindenlab.com) Date: Sun Jun 17 15:51:19 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <46750BB4.2050304@blueflash.cc> References: <467505AD.7030505@wsu.edu> <46750BB4.2050304@blueflash.cc> Message-ID: <6330.71.139.10.49.1182120676.squirrel@mail.lindenlab.com> > However, one thing that may be helpful though, would be to > make more viewer updates optional, I'm not sure if the changes > between 16 and 17 would be really mandatory in terms of > underlying protocol. The 1.16 --> 1.17 protocol changes were required to get the last bits of chat functionality in place to enable Voice First Look on the main grid. The 1.17 --> 1.18 protocol changes will enable the move to LLSD/HTTP based messaging, which should help reduce the need for mandatory viewer updates any time a messaging change is needed. There are a handful of other scenarios where new viewers will be required, but this will certainly make our lives easier. From dzonatas at dzonux.net Sun Jun 17 16:01:25 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jun 17 16:00:53 2007 Subject: [sldev] LLTemplateMessageBuilder: buildblock() difference between VS2005 and VS2003 causes crash in 1.18 Message-ID: <4675BD45.2060500@dzonux.net> I think I tracked down the difference, but still got to find the root cause. In buildblock(), the varible block_count gets set to an extremely large number in VS2005, like 136477312. That doesn't look right. That means the statement "S32 block_count = mbci->mBlockNumber;" on line 633 results in two different values, mBlockNumber is 43943744. As a result, the loop towards the end of the buildblock() counts down block_count and quickly gets into invalid memory pointers. -- Power to Change the Void From matthew.dowd at hotmail.co.uk Sun Jun 17 16:39:01 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Jun 17 16:39:02 2007 Subject: [sldev] JIRA Message-ID: Whoops looks like I've created loads - I kept getting a "docs out of order" error returning me to the create item page but not giving any clue it had created anything. As I e-mailed earlier this is a known bug in Jira 3.7.1 but fixed in 3.7.2 http://jira.atlassian.com/browse/JRA-11861 Matthew ---------------------------------------- > Date: Mon, 18 Jun 2007 00:45:30 +0200 > From: nicholaz@blueflash.cc > To: dzonatas@dzonux.net > Subject: Re: [sldev] JIRA > CC: sldev@lists.secondlife.com > > > It seems to do that on weekends (I think this is the > 3rd week in a row). Had that myself, get an error on > posting the issue, try again and there it is twice. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Dzonatas wrote: > > Looks like public had a hiccup today. There are several duplicate issues > > created one after another by different residents. I linked the ones I > > found. I could not close them, however. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Try Live.com - your fast, personalised homepage with all the things you care about in one place. http://www.live.com/?mkt=en-gb From robla at lindenlab.com Sun Jun 17 16:56:18 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sun Jun 17 16:56:29 2007 Subject: [sldev] JIRA In-Reply-To: References: Message-ID: <4675CA22.1000401@lindenlab.com> There was a problem with JIRA that was fixed earlier this afternoon. I'm glad to hear that the duplicate issue problem is likely the same problem as before, rather than some other problem. We're slated for an upgrade to the latest JIRA version sometime soon, but I don't have exact details yet. Rob On 6/17/07 4:39 PM, Matthew Dowd wrote: > Whoops looks like I've created loads - I kept getting a "docs out of order" error returning me to the create item page but not giving any clue it had created anything. > > As I e-mailed earlier this is a known bug in Jira 3.7.1 but fixed in 3.7.2 > > http://jira.atlassian.com/browse/JRA-11861 > > Matthew > > > ---------------------------------------- > >> Date: Mon, 18 Jun 2007 00:45:30 +0200 >> From: nicholaz@blueflash.cc >> To: dzonatas@dzonux.net >> Subject: Re: [sldev] JIRA >> CC: sldev@lists.secondlife.com >> >> >> It seems to do that on weekends (I think this is the >> 3rd week in a row). Had that myself, get an error on >> posting the issue, try again and there it is twice. >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Dzonatas wrote: >> >>> Looks like public had a hiccup today. There are several duplicate issues >>> created one after another by different residents. I linked the ones I >>> found. I could not close them, however. >>> >>> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > _________________________________________________________________ > Try Live.com - your fast, personalised homepage with all the things you care about in one place. > http://www.live.com/?mkt=en-gb _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- 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/20070617/b442d751/signature.pgp From nicholaz at blueflash.cc Sun Jun 17 17:02:13 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 17 17:02:35 2007 Subject: [sldev] LLTemplateMessageBuilder: buildblock() difference between VS2005 and VS2003 causes crash in 1.18 In-Reply-To: <4675BD45.2060500@dzonux.net> References: <4675BD45.2060500@dzonux.net> Message-ID: <4675CB85.2030004@blueflash.cc> I have not tried 2005, but that awfully looks like uninitialized member/variable to me. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Dzonatas wrote: > I think I tracked down the difference, but still got to find the root > cause. > > In buildblock(), the varible block_count gets set to an extremely large > number in VS2005, like 136477312. That doesn't look right. > > That means the statement "S32 block_count = mbci->mBlockNumber;" on line > 633 results in two different values, mBlockNumber is 43943744. > > As a result, the loop towards the end of the buildblock() counts down > block_count and quickly gets into invalid memory pointers. > From nicholaz at blueflash.cc Sun Jun 17 17:08:40 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 17 17:08:56 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <6330.71.139.10.49.1182120676.squirrel@mail.lindenlab.com> References: <467505AD.7030505@wsu.edu> <46750BB4.2050304@blueflash.cc> <6330.71.139.10.49.1182120676.squirrel@mail.lindenlab.com> Message-ID: <4675CD08.4070005@blueflash.cc> Hi Josh, thanks for the info ... appreciated! Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ josh@lindenlab.com wrote: >> However, one thing that may be helpful though, would be to >> make more viewer updates optional, I'm not sure if the changes >> between 16 and 17 would be really mandatory in terms of >> underlying protocol. > > The 1.16 --> 1.17 protocol changes were required to get the last bits of > chat functionality in place to enable Voice First Look on the main grid. > > The 1.17 --> 1.18 protocol changes will enable the move to LLSD/HTTP based > messaging, which should help reduce the need for mandatory viewer updates > any time a messaging change is needed. There are a handful of other > scenarios where new viewers will be required, but this will certainly make > our lives easier. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Sun Jun 17 17:37:33 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sun Jun 17 17:37:02 2007 Subject: [sldev] LLTemplateMessageBuilder: buildblock() difference between VS2005 and VS2003 causes crash in 1.18 In-Reply-To: <4675CB85.2030004@blueflash.cc> References: <4675BD45.2060500@dzonux.net> <4675CB85.2030004@blueflash.cc> Message-ID: <4675D3CD.10907@dzonux.net> Close to it. The message template is invalid when it is passed into buildBlock(). There is no assertion in buildBlock() to catch that, so it tries to work with the invalid data and crashes. Nicholaz Beresford wrote: > > I have not tried 2005, but that awfully looks like > uninitialized member/variable to me. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Dzonatas wrote: >> I think I tracked down the difference, but still got to find the root >> cause. >> >> In buildblock(), the varible block_count gets set to an extremely >> large number in VS2005, like 136477312. That doesn't look right. >> >> That means the statement "S32 block_count = mbci->mBlockNumber;" on >> line 633 results in two different values, mBlockNumber is 43943744. >> >> As a result, the loop towards the end of the buildblock() counts down >> block_count and quickly gets into invalid memory pointers. >> > > -- Power to Change the Void From odysseus654 at gmail.com Sun Jun 17 18:23:56 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Sun Jun 17 18:23:58 2007 Subject: [sldev] SSE2 on MSVC In-Reply-To: <4675B9E4.4000106@blueflash.cc> References: <4675B9E4.4000106@blueflash.cc> Message-ID: <1674f6c70706171823y1028e3b3ga3d770a7b6628647@mail.gmail.com> According to the docs, "By default, SSE2 implementation (using _set_SSE2_enable) is enabled on processors that support it". Does this change cause an improvement in performance at all? At this point I believe that SSE2 is a number of CPU instructions designed to "help speed 3D graphical calculations" or somesuch (or was that MMX?). If a program is compiled to use SSE2, then it (can) run faster on the SSE2-enabled processor than the original version would and cause spectacular crashes on the non-SSE2-enabled processor. Thus our discussion here about whether or not to support every CPU model. Does anyone have a good idea as to where these SSE2 commands would improve SL the most? Considering that the CRT appears to have multiple implementations of the math libraries, one that uses SSE2 and the other that doesn't, would it be helpful to have multiple implementations of some of our functions? On 6/17/07, Nicholaz Beresford wrote: > > > Dunno if the code bit below makes any sense (I haven't got > much idea what SSE2 is, despite having read it on Wikipedia), > but what do you think? > > // > // enable MSFT SSE2 extensions > // > CProcessor cproc; > const ProcessorInfo *pinfo= cproc.GetCPUInfo(); > int sse2= FALSE; > if (pinfo->_Ext.SSE2_StreamingSIMD2_Extensions) { > // > http://msdn2.microsoft.com/en-us/library/bthd138d(VS.80).aspx > sse2= _set_SSE2_enable(TRUE); > } > llinfos << "running with" << (!sse2 ? "out" : "" ) << " > _set_sse2_enabled " << llendl; > > > > Nick > > > -- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070617/9ada6f20/attachment.htm From gigstaggart at gmail.com Sun Jun 17 21:30:21 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Jun 17 21:30:53 2007 Subject: [sldev] recent patches Message-ID: <46760A5D.6010504@gmail.com> Here's a bunch of my recent patches for your testing and review. These are all against 1.17. The embedded notecard patch is more of a band-aid, it looks like something happened to server-side permissions on embedded objects. This patch just removes the extra unnecessary client-side permission check when opening a notecard and makes it as if you have "view admin options" on, which works around the issue somewhat. The crosseyed patch and animation fade patch are just rollbacks of recent linden changes to the old behavior that worked correctly. Note that the person looking at you needs to have these patches too, or they will continue to see some of the bad behavior. The newb spam patch kills the spam you get when you teleport away from help island public if you have a lot of landmarks and calling cards. This function is useful for newbs that might only have one calling card, but annoying to everyone else. This patch detects if you have more than 10 of the items in question, if so, it supresses the output. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: animation_fade_fixed.patch Type: text/x-patch Size: 886 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070618/01e39941/animation_fade_fixed.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: crosseyed.patch Type: text/x-patch Size: 1723 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070618/01e39941/crosseyed.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: embedded_notecards.patch Type: text/x-patch Size: 3485 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070618/01e39941/embedded_notecards.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: gigs_sticky_god_mode.patch Type: text/x-patch Size: 2664 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070618/01e39941/gigs_sticky_god_mode.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: newb_spam.patch Type: text/x-patch Size: 1968 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070618/01e39941/newb_spam.bin From blakar at gmail.com Mon Jun 18 01:15:40 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon Jun 18 01:15:43 2007 Subject: [sldev] SSE2 on MSVC In-Reply-To: <1674f6c70706171823y1028e3b3ga3d770a7b6628647@mail.gmail.com> References: <4675B9E4.4000106@blueflash.cc> <1674f6c70706171823y1028e3b3ga3d770a7b6628647@mail.gmail.com> Message-ID: <7992d0d60706180115i2d4bb609q248056cf9b44cdd1@mail.gmail.com> SSE2 is on by default when compiling with VS2005, the docs are right so the code is not needed. One example where it'll generate SSE code is when you cast float to int. Though as this has been replaced by lltrunc you won't benefit from SSE (SSE is faster than lltrunc). Besides that it'll insert some SSE instructions in your code but not a lot. I had a go at manually rewriting some functions in the viewer and in most cases writing optimised x87 code gave a 2 to 3 times speed increase for that specific function. I'm also going to check where we can use SSE (we don't need SSE2 as SSE2 mainly extends SSE to have 64bit floats which we don't use anyway.) An example of optimised x87 code can be found in VWR-1277 in JIRA. Dirk aka Blakar Ogre On 6/18/07, Erik Anderson wrote: > According to the docs, "By default, SSE2 implementation (using > _set_SSE2_enable) is enabled on processors that support it". Does this > change cause an improvement in performance at all? > > At this point I believe that SSE2 is a number of CPU instructions designed > to "help speed 3D graphical calculations" or somesuch (or was that MMX?). > If a program is compiled to use SSE2, then it (can) run faster on the > SSE2-enabled processor than the original version would and cause spectacular > crashes on the non-SSE2-enabled processor. Thus our discussion here about > whether or not to support every CPU model. > > Does anyone have a good idea as to where these SSE2 commands would improve > SL the most? Considering that the CRT appears to have multiple > implementations of the math libraries, one that uses SSE2 and the other that > doesn't, would it be helpful to have multiple implementations of some of our > functions? > > > On 6/17/07, Nicholaz Beresford wrote: > > > > Dunno if the code bit below makes any sense (I haven't got > > much idea what SSE2 is, despite having read it on Wikipedia), > > but what do you think? > > > > // > > // enable MSFT SSE2 extensions > > // > > CProcessor cproc; > > const ProcessorInfo *pinfo= cproc.GetCPUInfo(); > > int sse2= FALSE; > > if (pinfo->_Ext.SSE2_StreamingSIMD2_Extensions) { > > // > http://msdn2.microsoft.com/en-us/library/bthd138d(VS.80).aspx > > sse2= _set_SSE2_enable(TRUE); > > } > > llinfos << "running with" << (!sse2 ? "out" : "" ) << " > _set_sse2_enabled " << llendl; > > > > > > > > Nick > > > > > > -- > > Second Life from the inside out: > > http://nicholaz-beresford.blogspot.com/ > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > 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 Mon Jun 18 02:01:17 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jun 18 02:01:20 2007 Subject: [sldev] JIRA Message-ID: Mmmmm, it looks as if there is still some mess left behind - all of the ones I got the "docs out of order" error for seem to be missing the Workflow options. So as Dzonatas says they can't be closed even by the person who created them. Matthew ---------------------------------------- > Date: Sun, 17 Jun 2007 16:56:18 -0700 > From: robla@lindenlab.com > To: sldev@lists.secondlife.com > Subject: Re: [sldev] JIRA > > There was a problem with JIRA that was fixed earlier this afternoon. > I'm glad to hear that the duplicate issue problem is likely the same > problem as before, rather than some other problem. > > We're slated for an upgrade to the latest JIRA version sometime soon, > but I don't have exact details yet. > > Rob > > On 6/17/07 4:39 PM, Matthew Dowd wrote: > > Whoops looks like I've created loads - I kept getting a "docs out of order" error returning me to the create item page but not giving any clue it had created anything. > > > > As I e-mailed earlier this is a known bug in Jira 3.7.1 but fixed in 3.7.2 > > > > http://jira.atlassian.com/browse/JRA-11861 > > > > Matthew > > > > > > ---------------------------------------- > > > >> Date: Mon, 18 Jun 2007 00:45:30 +0200 > >> From: nicholaz@blueflash.cc > >> To: dzonatas@dzonux.net > >> Subject: Re: [sldev] JIRA > >> CC: sldev@lists.secondlife.com > >> > >> > >> It seems to do that on weekends (I think this is the > >> 3rd week in a row). Had that myself, get an error on > >> posting the issue, try again and there it is twice. > >> > >> > >> Nick > >> > >> > >> Second Life from the inside out: > >> http://nicholaz-beresford.blogspot.com/ > >> > >> > >> Dzonatas wrote: > >> > >>> Looks like public had a hiccup today. There are several duplicate issues > >>> created one after another by different residents. I linked the ones I > >>> found. I could not close them, however. > >>> > >>> > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > > > > _________________________________________________________________ > > Try Live.com - your fast, personalised homepage with all the things you care about in one place. > > http://www.live.com/?mkt=en-gb _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From kerdezixe at gmail.com Mon Jun 18 02:13:55 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Mon Jun 18 02:13:57 2007 Subject: [sldev] SSE2 on MSVC In-Reply-To: <7992d0d60706180115i2d4bb609q248056cf9b44cdd1@mail.gmail.com> References: <4675B9E4.4000106@blueflash.cc> <1674f6c70706171823y1028e3b3ga3d770a7b6628647@mail.gmail.com> <7992d0d60706180115i2d4bb609q248056cf9b44cdd1@mail.gmail.com> Message-ID: <8a1bfe660706180213q41f4a728p38ea5c0f0d7b3f1c@mail.gmail.com> Hi, it's not 100% in the topic but... i found an article about cpu detection, and a library named libxpl. It run on linux and Windows, and could probably easily ported on intel mac. http://www.arsoft-online.com/index.php?option=com_content&task=view&id=17#libxpl I don't know about the licencing, the wiki page about the licence is blank *sigh* -- kerunix Flan From jhurliman at wsu.edu Mon Jun 18 02:50:46 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Jun 18 02:50:44 2007 Subject: [sldev] Preferred CAPS timeouts and retries? In-Reply-To: <46673E15.9080901@lindenlab.com> References: <46522D45.9030103@wsu.edu> <465266DC.4070707@lindenlab.com> <46528D4D.4080708@wsu.edu> <4653391F.8000609@lindenlab.com> <465396B5.40303@wsu.edu> <46673E15.9080901@lindenlab.com> Message-ID: <46765576.2050109@wsu.edu> Ryan Williams wrote: > John Hurliman wrote: > >> Ryan Williams wrote: >> >>> I have a few more questions: >>> >>> -is this happening on socket open, or is it refusing to deliver data >>> over the open socket, or both? >>> - what are the logs from the official client that you're reading to >>> determine that it's occasionaly problematic there? >>> - have you noticed any pattern for which regions have the problem? >>> >>> Thanks for bringing this to our attention, BTW, we appreciate it. >>> >>> -RYaN >>> >>> >> I don't have any of the old log files from the official viewer so I'm >> going to start looking for it again and save the log when it happens so >> I can post. Translating .NET callbacks in libsecondlife to what is >> actually happening at the lower layer, lets see here: >> >> BeginGetRequestStream succeeds >> EndGetRequestStream succeeds >> BeginGetResponse hangs (indefinitely?) >> >> So it looks like the socket opens, the client sends a request, but the >> server never sends a response. I only go to three or four sims in SL >> usually, but out of those I've most often noticed it in Ahern on a busy >> night. The sim turns in to what I call a "blackhole sim" because you can >> teleport in just fine, but since CAPS is unavailable in that sim there >> is no way to walk or TP out, and you get trapped in the sim. >> > > Hi, sorry for the long delay on this, but we think we've identified one > issue that might cause this, and deployed the fix to the beta grid. > > The problem that we identified was that the caps server was not > responding when an invalid cap was invoked, it should have been > returning a 404. Now it returns a 404 instead of keeping the connection > open forever. > > Would you let me know if you still see the issues with connecting to the > caps server on the beta grid? > > -RYaN > > I've been monitoring this and haven't seen any more 404s (only get them in a semi-rare timing issue where the sim disconnects and the CAPS thread tries to reconnect before being told to shut down), but the initial CAPS connections appear to be much more reliable then 2-3 months ago. John From soft at lindenlab.com Mon Jun 18 08:13:16 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jun 18 08:13:19 2007 Subject: [sldev] SLDev-Traffic Late This Week Message-ID: <9e6e5c9e0706180813k5d935a3aj6a45180e55c145b2@mail.gmail.com> Spent the weekend catching up on First Life after two weeks out of town. SLDev-Traffic will be late this week - hopefully tonight! From bos at lindenlab.com Mon Jun 18 09:55:55 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 18 09:57:02 2007 Subject: [sldev] Re: updating "Compile the view (Linux)" on the wiki In-Reply-To: References: Message-ID: <4676B91B.4050605@lindenlab.com> signore@autistiche.org wrote: > * The rest of the page mostly explains how to build > the viewer without using the LL libraries bundle. I've made changes to the SConstruct script recently that should make it trivial to build without the bundled libraries, without needing to patch anything. Look for them in an upcoming source release. Hello, i have some Problems with the Windlight Branch, exactly these fatal errors under vc++ : llwindow: llgl.cpp(47) : fatal error C1083: Cannot open include file: 'glh/glh_linear.h': No such file or directory and in newview : llwlparammanager.cpp(34) : fatal error C1083: Cannot open include file: 'glh/glh_linear.h': No such file or directory has somebody an idea on that ? imho these two missing headers are soemthing from nvidia, but when i add tem per hand, the complete compile is borked. greetings Hawk From nicholaz at blueflash.cc Mon Jun 18 13:32:57 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 18 13:33:14 2007 Subject: [sldev] A mini-leak and a cleanup problem Message-ID: <4676EBF9.5060207@blueflash.cc> https://jira.secondlife.com/browse/VWR-1294 https://jira.secondlife.com/browse/VWR-1296 Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From secret.argent at gmail.com Mon Jun 18 14:48:00 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 18 14:48:14 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <20070618000236.6DE1A41AF63@stupor.lindenlab.com> References: <20070618000236.6DE1A41AF63@stupor.lindenlab.com> Message-ID: <94F226D8-A973-4DCA-A1DA-02D378A047BF@gmail.com> > The 1.17 --> 1.18 protocol changes will enable the move to LLSD/ > HTTP based > messaging, which should help reduce the need for mandatory viewer > updates > any time a messaging change is needed. There are a handful of other > scenarios where new viewers will be required, but this will > certainly make > our lives easier. Are you going to put in HTTP proxy support before going to HTTP for messages? From dale at daleglass.net Mon Jun 18 19:24:56 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Jun 18 19:25:14 2007 Subject: [sldev] Created page on source control Message-ID: <200706190425.05929.dale@daleglass.net> This is a very rough draft still, and possibly not the right name for the page (any better ideas?) https://wiki.secondlife.com/wiki/Source_version_control The basic idea here is explaining how to keep your own branch of the LL source, and do development on it, while keeping up with the LL source releases. It's written almost entirely from memory, and I'm very new to SVK, so probably there are quite a few wrong things there. SVK seemed to be just the thing to use for SL development, but unfortunately the documentation leaves a lot to be desired, so I thought it'd be useful to have a page explaining how to apply it to SL development. -------------- 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/20070619/5d3261a0/attachment.pgp From soft at lindenlab.com Mon Jun 18 22:45:50 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jun 18 22:45:52 2007 Subject: [sldev] Re: SLDev Digest, Vol 6, Issue 50 In-Reply-To: <7678615F-3483-4A44-B50C-AAD05C38DDD2@gmail.com> References: <20070615011604.01D2F41B1C1@stupor.lindenlab.com> <7678615F-3483-4A44-B50C-AAD05C38DDD2@gmail.com> Message-ID: <9e6e5c9e0706182245m3f12f105wa81a5f76928c0509@mail.gmail.com> Thanks, I'm putting this on my tasklist! On 6/14/07, Argent Stonecutter wrote: > > > > Unfortunately, the patched grammar is now too greedy when it tries to > > fold constant expressions: > > > > x = x - 5 - 5; // becomes x = x - (5-5) becomes x = x - 0 > > Ah. > > There's not a clean fix for that, you need to have it create the > parse tree and fold constant expressions at run time. Not as > straightforward as I thought. Have to drop back to just handling the > "-x" case. > > Don't discard the lex patch! The lex file has several wrong solutions > to try and fix various symptoms in lex instead of yacc, and it > basically comes down to "knocking '-' off and fixing the other broken > stuff". > > Instead, drop most of the indra.y patch. > > Here's the minimum patch, try it. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From soft at lindenlab.com Mon Jun 18 23:01:49 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jun 18 23:01:52 2007 Subject: [sldev] SLDev-Traffic #16 Message-ID: <9e6e5c9e0706182301k18294e6dvca82c4c2af9f9631@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_16 SLDev-Traffic number 16 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From dale at daleglass.net Tue Jun 19 01:37:35 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Jun 19 01:37:56 2007 Subject: [sldev] Created page on source control In-Reply-To: <2925011a0706182021n73e321e9yc7b8baff56e0cc8b@mail.gmail.com> References: <200706190425.05929.dale@daleglass.net> <2925011a0706182021n73e321e9yc7b8baff56e0cc8b@mail.gmail.com> Message-ID: <200706191037.41092.dale@daleglass.net> ? ????????? ?? 19 ???? 2007 05:21 ?? ????????: > SVK? i am thinking that SVN is pretty easy to find tutorials about, > all the dinosaurs have used RCS and CVS.... The idea isn't to make a SVN/SVK tutorial, rather explain how to apply it to SL source specifically. For example even though I had been using SVN for several years before I found about SL, I didn't know about svn-load-dirs until I needed to solve that problem for SL and found after some googling that SVN already comes with tools for that. Now the SVK explanation is there because it appears to be ideal as far as SL development is concerned: it can automatically mirror the SL repository, merge changes into your code, and publish your own branches with a minimum of inconvenience. It doesn't seem to have any of the disadvantages of SVN + svn-load-dirs, and the way it works means you get to the point where you can generate a new viewer update much faster. My previous way of doing things was SVN + svn-load-dirs. But my repository was hosted on dreamhost (shared hosting). Load average on that server can be about 5 normally. So svn-load-dirs was pain. The download source, load-dirs (which means a full checkout, processing, commit, tag, checkout) process could take more than an hour overall. In comparison, SVK changes that a lot: During an update I only need to pull the source from the LL server, which only requires downloading the changes. After that I can get back to work. Pushing the new version to my server also only requires sending the changes, which is reasonably fast. Longer term I plan to offer my version of the client to the people who want it. SVK seems to be much superior for getting a new version out quickly when it's needed. -------------- 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/20070619/66b09c50/attachment.pgp From nicholaz at blueflash.cc Tue Jun 19 05:10:28 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 19 05:10:47 2007 Subject: [sldev] Memory leaks/leftover almost completed Message-ID: <4677C7B4.3080602@blueflash.cc> http://nicholaz-beresford.blogspot.com/2007/06/memory-leaksleftover-almost-completed.html Nick From nicholaz at blueflash.cc Tue Jun 19 05:25:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 19 05:25:31 2007 Subject: [sldev] Pointers 0x3f800000 Message-ID: <4677CB32.6000007@blueflash.cc> I've been looking at crash dumps from users of my viewer lately and I'm seeing pointers with a value of 0x3f800000 in some of them (e.g. crashing on deletion of a refcounted object where the pointer has this value). It may be a memory overwrite, but does this particular value ring any bells with anyone? Nick From Paul.Hampson at Pobox.com Tue Jun 19 06:06:19 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Tue Jun 19 06:06:29 2007 Subject: [sldev] Created page on source control In-Reply-To: <200706190425.05929.dale@daleglass.net> References: <200706190425.05929.dale@daleglass.net> Message-ID: <20070619130619.GA5755@keitarou> On Tue, Jun 19, 2007 at 04:24:56AM +0200, Dale Glass wrote: > SVK seemed to be just the thing to use for SL development, but > unfortunately the documentation leaves a lot to be desired, so I > thought it'd be useful to have a page explaining how to apply it to > SL development. Having recently become enamoured of git, (and git-svn), I'd love to see either LL or someone publishing a git-svn (or git-svnimport since it'd be normally one-way) tree. I'll prolly play with it myself at some point, although just for myself, tracking upstream tarballs seems easiest to me from a packaging point of view. Especially since once I get slviewer into Debian, I hope to organise some team-maintenance around it, and as mentioned, I'm enamoured of git. ^_^ -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070619/34d241a9/attachment.pgp From jhurliman at wsu.edu Tue Jun 19 06:26:52 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Jun 19 06:26:42 2007 Subject: [sldev] Created page on source control In-Reply-To: <20070619130619.GA5755@keitarou> References: <200706190425.05929.dale@daleglass.net> <20070619130619.GA5755@keitarou> Message-ID: <4677D99C.1090107@wsu.edu> Paul TBBle Hampson wrote: > On Tue, Jun 19, 2007 at 04:24:56AM +0200, Dale Glass wrote: > > >> SVK seemed to be just the thing to use for SL development, but >> unfortunately the documentation leaves a lot to be desired, so I >> thought it'd be useful to have a page explaining how to apply it to >> SL development. >> > > Having recently become enamoured of git, (and git-svn), I'd love to > see either LL or someone publishing a git-svn (or git-svnimport since > it'd be normally one-way) tree. > > I'll prolly play with it myself at some point, although just for myself, > tracking upstream tarballs seems easiest to me from a packaging point of > view. > > Especially since once I get slviewer into Debian, I hope to organise > some team-maintenance around it, and as mentioned, I'm enamoured of git. > > ^_^ > > > When the GPL viewer was originally being discussed, the collection of people that was OpenSL at the time were pushing for a git setup over SVN and setup one of their own for a time, although it is no longer running or actively maintained. If a community actually kept up with it a git repo could be a useful resource for some of the client developers. John Hurliman From jhurliman at wsu.edu Tue Jun 19 06:30:29 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Jun 19 06:30:18 2007 Subject: [sldev] Live session dumps from the REST protocol In-Reply-To: <4677C7B4.3080602@blueflash.cc> References: <4677C7B4.3080602@blueflash.cc> Message-ID: <4677DA75.8080002@wsu.edu> I started a wiki page at https://wiki.secondlife.com/wiki/REST to save example protocol dumps for each type of REST message as they are added. A raw XML dump would be the best way to go, but right now I'm just using the tree format that libsecondlife outputs. Please feel free to add any that you don't see on the page already, or add extended documentation for the ones there. John Hurliman From dzonatas at dzonux.net Tue Jun 19 07:42:45 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 19 07:42:11 2007 Subject: [sldev] Bug Triage: Post-Mortem and Re-Birth... First Call Message-ID: <4677EB65.8030000@dzonux.net> I'll make the post-mortem quick: Woot! We've were successive to get through all the issues this week. That even includes ones that were piled on last-minute! There is discussion on how to improve the process a bit more. One significant step to note: we now depend more on the comments being made on the agenda under each issue to determine the best action. We still need to comment on the issues in JIRA to there resolution, but the details that affect importability to the internal JIRA being annotated on the agenda is essential for a successful triage session. Let's get the new agenda going. https://wiki.secondlife.com/wiki/Bug_triage/Agenda We'll move the previous agenda and start with a clean slate, again. Bring them on! First Call!!! -- Power to Change the Void From dereck at gmail.com Tue Jun 19 08:10:36 2007 From: dereck at gmail.com (Dereck Wonnacott) Date: Tue Jun 19 08:10:39 2007 Subject: [sldev] Re: SLDev Digest, Vol 6, Issue 62 In-Reply-To: <20070619132645.6E5E841AF81@stupor.lindenlab.com> References: <20070619132645.6E5E841AF81@stupor.lindenlab.com> Message-ID: <2d8148cd0706190810u1bd5f3e4o3c71e93a4866e052@mail.gmail.com> From: John Hurliman Paul TBBle Hampson wrote: > On Tue, Jun 19, 2007 at 04:24:56AM +0200, Dale Glass wrote: > > >> SVK seemed to be just the thing to use for SL development, but >> unfortunately the documentation leaves a lot to be desired, so I >> thought it'd be useful to have a page explaining how to apply it to >> SL development. >> > > Having recently become enamoured of git, (and git-svn), I'd love to > see either LL or someone publishing a git-svn (or git-svnimport since > it'd be normally one-way) tree. > > I'll prolly play with it myself at some point, although just for myself, > tracking upstream tarballs seems easiest to me from a packaging point of > view. > > Especially since once I get slviewer into Debian, I hope to organise > some team-maintenance around it, and as mentioned, I'm enamoured of git. > > ^_^ > > > When the GPL viewer was originally being discussed, the collection of people that was OpenSL at the time were pushing for a git setup over SVN and setup one of their own for a time, although it is no longer running or actively maintained. If a community actually kept up with it a git repo could be a useful resource for some of the client developers. John Hurliman I'm no pro, but I've been impressed with GIT and would love an official repo. Good enough for Linux Kernel, good enough for SL Client. :) ~Dereck Wonnacott -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070619/114d6cb4/attachment.htm From nicholaz at blueflash.cc Tue Jun 19 08:27:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 19 08:27:38 2007 Subject: [sldev] Re: SLDev Digest, Vol 6, Issue 62 In-Reply-To: <2d8148cd0706190810u1bd5f3e4o3c71e93a4866e052@mail.gmail.com> References: <20070619132645.6E5E841AF81@stupor.lindenlab.com> <2d8148cd0706190810u1bd5f3e4o3c71e93a4866e052@mail.gmail.com> Message-ID: <4677F5D7.6040805@blueflash.cc> > I'm no pro, but I've been impressed with GIT and would love an official > repo. Good enough for Linux Kernel, good enough for SL Client. :) and good enough to handle the open source traffic for Linux WINE ... Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Tue Jun 19 08:30:37 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 19 08:30:00 2007 Subject: [sldev] JIRA: Blockers Message-ID: <4677F69D.4030709@dzonux.net> Here is a list of currently open and reopened jira issues marked as blockers. VWR-559 SL freezes complete system SVC-177 Automated access to SL transaction logs or notification of transactions SVC-53 Login -> Freeze -> LLCircuit::addCircuitData VWR-568 Crashes after login VWR-728 Consistent lockups within 10 minutes of login MISC-124 'Move' Required tutorial doesn't work. VWR-1016 WindLight not usable due performance issue - WinXP - ATI MOBILITY RADEON VWR-729 Alpha client crashes because of a 'Segmentation Fault' and 'fails to get mutex for log' VWR-1002 Windlight Crashes on startup MISC-297 Keep Continuing to Crash a Few Seconds After Login VWR-913 Windlight crash on startp. WinXP, ATI card SVC-313 Saving of scripts being edited in-world sporadic at best. MISC-279 Logs off when TP fails WEB-162 Unable to update/Access Credit card Details or Pay by Paypal WEB-157 Support System is Broken VWR-1208 Mac Voice First Look Client borked VWR-1176 CLONE -unable to load invantory corrupted invantory or missing invantory VWR-1100 Unable to manage groups and inventory missing VWR-1089 Frequent Crashing of Voice Beta VWR-1068 Voice Beta Client Crashes on Startup. See https://jira.secondlife.com/browse/VWR-913 VWR-1006 Error in XML Parser prevents logon. SVC-294 Uninitiated Teleport causes AV freeze - Relog required to clear. Quick Licks: https://jira.secondlife.com/browse/VWR-559 https://jira.secondlife.com/browse/SVC-177 https://jira.secondlife.com/browse/SVC-53 https://jira.secondlife.com/browse/VWR-568 https://jira.secondlife.com/browse/VWR-728 https://jira.secondlife.com/browse/MISC-124 https://jira.secondlife.com/browse/VWR-1016 https://jira.secondlife.com/browse/VWR-729 https://jira.secondlife.com/browse/VWR-1002 https://jira.secondlife.com/browse/MISC-297 https://jira.secondlife.com/browse/VWR-913 https://jira.secondlife.com/browse/SVC-313 https://jira.secondlife.com/browse/MISC-279 https://jira.secondlife.com/browse/WEB-162 https://jira.secondlife.com/browse/WEB-157 https://jira.secondlife.com/browse/VWR-1208 https://jira.secondlife.com/browse/VWR-1176 https://jira.secondlife.com/browse/VWR-1100 https://jira.secondlife.com/browse/VWR-1089 https://jira.secondlife.com/browse/VWR-1068 https://jira.secondlife.com/browse/VWR-1006 https://jira.secondlife.com/browse/SVC-294 -- Power to Change the Void From dzonatas at dzonux.net Tue Jun 19 09:09:56 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 19 09:09:19 2007 Subject: [sldev] Created page on source control In-Reply-To: <20070619130619.GA5755@keitarou> References: <200706190425.05929.dale@daleglass.net> <20070619130619.GA5755@keitarou> Message-ID: <4677FFD4.40202@dzonux.net> Paul TBBle Hampson wrote: > Having recently become enamoured of git, (and git-svn), I'd love to > Torvalds has recently lobbied git as ready for mainstream, but he also noted that it doesn't have all the nice front-end features of other SCMs. If git can be used with tools like TortiseSVN/TortiseMerge, or anything like that, it may be worthwhile to review. One minor difference about git is that the merge process is pushed downstream rather than upstream like svn. The pulls are cleaner on git since the responsibility of merge is put more on those downstream. The major difference is that the repository has to be broken up into git-projects unlike where everything is put together in svn, being only delineated by directories. Torvalds tends to compare svn to cvs in the sense of a linear repository, which cvs is a major restriction of cvs. He doesn't seem to make any comparison to a svn repository that is setup more to a deep tree structure. You can easily recognized the branch level in svn. Most svn users still have their repository setup in a linear fashion with one branch level, being one branch directory with lots of version directories stuck under that one branch directory. The power of git can be still simulated in a svn-repository with the deeper tree structure, where you have branches that spawn more branch directories and each sub-branch level feeds into the super-branch level. At that point, git only does it in a more distributed fashion. -- Power to Change the Void From matthew.dowd at hotmail.co.uk Tue Jun 19 10:47:08 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jun 19 10:47:09 2007 Subject: [sldev] JIRA Message-ID: OK, as requested by Rob, I've pulled together all the issues in Jira which can't be closed/resolved due to hitting this Jira bug, which I know about into https://jira.secondlife.com/browse/WEB-180. If you come across any issue which doesn't have the close/resolve workflow options it may be worth link them to this. Matthew ---------------------------------------- > From: matthew.dowd@hotmail.co.uk > To: robla@lindenlab.com; sldev@lists.secondlife.com > Subject: RE: [sldev] JIRA > Date: Mon, 18 Jun 2007 09:01:17 +0000 > > > > Mmmmm, it looks as if there is still some mess left behind - all of the ones I got the "docs out of order" error for seem to be missing the Workflow options. So as Dzonatas says they can't be closed even by the person who created them. > > Matthew > > > > > > ---------------------------------------- > > Date: Sun, 17 Jun 2007 16:56:18 -0700 > > From: robla@lindenlab.com > > To: sldev@lists.secondlife.com > > Subject: Re: [sldev] JIRA > > > > There was a problem with JIRA that was fixed earlier this afternoon. > > I'm glad to hear that the duplicate issue problem is likely the same > > problem as before, rather than some other problem. > > > > We're slated for an upgrade to the latest JIRA version sometime soon, > > but I don't have exact details yet. > > > > Rob > > > > On 6/17/07 4:39 PM, Matthew Dowd wrote: > > > Whoops looks like I've created loads - I kept getting a "docs out of order" error returning me to the create item page but not giving any clue it had created anything. > > > > > > As I e-mailed earlier this is a known bug in Jira 3.7.1 but fixed in 3.7.2 > > > > > > http://jira.atlassian.com/browse/JRA-11861 > > > > > > Matthew > > > > > > > > > ---------------------------------------- > > > > > >> Date: Mon, 18 Jun 2007 00:45:30 +0200 > > >> From: nicholaz@blueflash.cc > > >> To: dzonatas@dzonux.net > > >> Subject: Re: [sldev] JIRA > > >> CC: sldev@lists.secondlife.com > > >> > > >> > > >> It seems to do that on weekends (I think this is the > > >> 3rd week in a row). Had that myself, get an error on > > >> posting the issue, try again and there it is twice. > > >> > > >> > > >> Nick > > >> > > >> > > >> Second Life from the inside out: > > >> http://nicholaz-beresford.blogspot.com/ > > >> > > >> > > >> Dzonatas wrote: > > >> > > >>> Looks like public had a hiccup today. There are several duplicate issues > > >>> created one after another by different residents. I linked the ones I > > >>> found. I could not close them, however. > > >>> > > >>> > > >> _______________________________________________ > > >> Click here to unsubscribe or manage your list subscription: > > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > >> > > > > > > _________________________________________________________________ > > > Try Live.com - your fast, personalised homepage with all the things you care about in one place. > > > http://www.live.com/?mkt=en-gb _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > _________________________________________________________________ > 100?s of Music vouchers to be won with MSN Music > https://www.musicmashup.co.uk/index.html_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com/index2.html From dzonatas at dzonux.net Tue Jun 19 11:21:30 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 19 11:20:59 2007 Subject: [sldev] SLDev-Traffic #16 In-Reply-To: <9e6e5c9e0706182301k18294e6dvca82c4c2af9f9631@mail.gmail.com> References: <9e6e5c9e0706182301k18294e6dvca82c4c2af9f9631@mail.gmail.com> Message-ID: <46781EAA.7070307@dzonux.net> I'll use this thread, then. In the SL-Dev, it says: ----- 1.17 PJIRA Cleanup Dzonatas Sol also volunteered to do some maintenance on the public JIRA following the 1.17 release. I love y'all so much. :) ----- I'm happy to volunteer, but I don't understand where this notion came from. Also, while we are on the topic of clean-up efforts... On SL-42561, it states the description in a way that I have already made a particular piece of code faster. That kinda gives a false impression that duly doesn't give me any justice. To clarify the credits, I only worked on the SSE code related to OpenJPEG before that. Soft, you have been given the proper orientation steps at Linden Lab to be formally familiarized, even with a new computer, with how to successfully complete tasks at LL and work well with others. So, something is just not clear here. What kind of maintenance? I just have a rink-a-dink computer, which is of no match to these other open source developers that can compile and test code much faster. The State has coined a term for interns they hire that struggle with their classes. The State calls them "flunky-aides," which do menial tasks that normal salaried state workers hand-off to make their work load easier -- at least for the salaried worker. Do corporations like LL do this? https://jira.secondlife.com/browse/MISC-187 Contact University of California Davis career placement office Okay.... I'll figure out how to do maintenance on those issue even though I haven't been given any orientation to do it. I hope you accept my efforts. Consider me on it. =) Soft Linden wrote: > https://wiki.secondlife.com/wiki/SLDev-Traffic_16 > > SLDev-Traffic number 16 is up. Feel free to edit as always. That's why > it's a wiki. > > Please use the original threads and talk pages if anything in the > summary encourages further discussion. > > Thanks! > _______________________________________________ > 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/20070619/08f99822/attachment-0001.htm From dzonatas at dzonux.net Tue Jun 19 12:01:21 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 19 12:00:45 2007 Subject: [sldev] [Fwd] Border Control Message-ID: <46782801.5020805@dzonux.net> For those that have HTML enabled... -- Power to Change the Void -------------- next part -------------- An embedded message was scrubbed... From: R Ballard Subject: [Fwd: FW: Maxine on Border Control] Date: Tue, 19 Jun 2007 09:13:03 -0700 Size: 48990 Url: http://lists.secondlife.com/pipermail/sldev/attachments/20070619/80e56563/MaxineonBorderControl-0001.eml From labrat.hb at gmail.com Tue Jun 19 12:00:45 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Jun 19 12:00:48 2007 Subject: [sldev] SLDev-Traffic #16 In-Reply-To: <46781EAA.7070307@dzonux.net> References: <9e6e5c9e0706182301k18294e6dvca82c4c2af9f9631@mail.gmail.com> <46781EAA.7070307@dzonux.net> Message-ID: He was referring to the following: >From Birdie: > Hey there- > > Good news -- many resolved PJIRA issues that went out with 1.17 this > week! So - we're looking for a little clean-up help w/PJIRA... > > Would anyone be willing to volunteer to go through the following > PJIRA issues marked as "Fixed Internally" and do the following: > 1.) Re-open the issue > 2.) Resolve the issue as "Fixed" > 3.) Add a comment "Fixed in 1.17.0(112)" > The rest of your mail just came of snide and as a personal stab at Soft. On 6/19/07, Dzonatas wrote: > > ----- > 1.17 PJIRA Cleanup Dzonatas Sol also volunteered to do some maintenance on > the public JIRA following the 1.17 release. I love y'all so much. :) > > ----- > > Soft, you have been given the proper orientation steps at Linden Lab to be > formally familiarized, even with a new computer, with how to successfully > complete tasks at LL and work well with others. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070619/aa1cef43/attachment.htm From dzonatas at dzonux.net Tue Jun 19 12:05:09 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 19 12:04:32 2007 Subject: [sldev] SLDev-Traffic #16 In-Reply-To: References: <9e6e5c9e0706182301k18294e6dvca82c4c2af9f9631@mail.gmail.com> <46781EAA.7070307@dzonux.net> Message-ID: <467828E5.9020705@dzonux.net> Harold Brown wrote: > > > The rest of your mail just came of snide and as a personal stab at Soft. Um. but... I really have nothing against Soft. Hmm. I'm just trying to work through controversial issues and clear up other matters. -- Power to Change the Void From monkowsk at watson.ibm.com Tue Jun 19 13:55:42 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Jun 19 13:55:21 2007 Subject: [sldev] Pointers 0x3f800000 In-Reply-To: <4677CB32.6000007@blueflash.cc> References: <4677CB32.6000007@blueflash.cc> Message-ID: <467842CE.5000509@watson.ibm.com> Nicholaz Beresford wrote: > > I've been looking at crash dumps from users of my viewer > lately and I'm seeing pointers with a value of 0x3f800000 > in some of them (e.g. crashing on deletion of a refcounted > object where the pointer has this value). > > It may be a memory overwrite, but does this particular value > ring any bells with anyone? float 1.0 Mike From gigstaggart at gmail.com Tue Jun 19 14:26:29 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Jun 19 14:27:17 2007 Subject: [sldev] JIRA: Blockers (crash after login) In-Reply-To: <4677F69D.4030709@dzonux.net> References: <4677F69D.4030709@dzonux.net> Message-ID: <46784A05.4000605@gmail.com> Dzonatas wrote: > > Here is a list of currently open and reopened jira issues marked as > blockers. > I have gone through these, resolved almost half of them, commented on most of them, voted on some. There is a big recurring theme though. "SL Crashes shortly after logging in" is a big problem still for a lot of people. It looks like it may have multiple causes, but seems to be video related generally. These bugs could be merged into one bug, but it's not clear it's all the same problem there. -Jason From dale at daleglass.net Tue Jun 19 14:35:16 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Tue Jun 19 14:35:21 2007 Subject: [sldev] SVN source merging script Message-ID: <20070619213516.GA16263@bruno.sbruno> I've uploaded the script I used for importing new versions of the source into my SVN repository. See comments in the source for usage instructions. http://daleglass.net/scripts/load_archive.pl -------------- 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/20070619/398bb6fb/attachment.pgp From rdw at lindenlab.com Tue Jun 19 15:21:48 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Tue Jun 19 15:21:50 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <94F226D8-A973-4DCA-A1DA-02D378A047BF@gmail.com> References: <20070618000236.6DE1A41AF63@stupor.lindenlab.com> <94F226D8-A973-4DCA-A1DA-02D378A047BF@gmail.com> Message-ID: <467856FC.9010303@lindenlab.com> Argent Stonecutter wrote: >> The 1.17 --> 1.18 protocol changes will enable the move to LLSD/HTTP >> based >> messaging, which should help reduce the need for mandatory viewer updates >> any time a messaging change is needed. There are a handful of other >> scenarios where new viewers will be required, but this will certainly >> make >> our lives easier. > > Are you going to put in HTTP proxy support before going to HTTP for > messages? No, because we'll still be using the UDP message system for most packets, so proxying wouldn't really make much of a difference. Even longer-term, we're likely to still keep using UDP for low-latency messages like ObjectUpdate. -RYaN From secret.argent at gmail.com Tue Jun 19 16:11:38 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 19 16:11:42 2007 Subject: [sldev] git vs svn In-Reply-To: <20070619182059.420B141B0A5@stupor.lindenlab.com> References: <20070619182059.420B141B0A5@stupor.lindenlab.com> Message-ID: I would note that there are a number of good GUI SVN client applications available for OSX and Windows. Git seems to have less widespread support. From dale at daleglass.net Tue Jun 19 16:36:00 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Tue Jun 19 16:36:07 2007 Subject: [sldev] git vs svn In-Reply-To: References: <20070619182059.420B141B0A5@stupor.lindenlab.com> Message-ID: <20070619233600.GB16263@bruno.sbruno> On Tue, Jun 19, 2007 at 06:11:38PM -0500, Argent Stonecutter wrote: > I would note that there are a number of good GUI SVN client > applications available for OSX and Windows. Git seems to have less > widespread support. I would completely agree here, but IMO it's a strange way to decide. SVN is nice but has the disadvantage of requiring svn-load-dirs. Yeah, TortoiseSVN is very nice, but it's not going to automate the importing of SL source for you (unless they added that and I didn't notice) SVK, Git, and other systems of the sort support a development model that's much more comfortable for SL development. Now, I really like SVN and been using it for years, but from my own experience, trying to use SVN and keeping up with LL development takes some effort and has quite significant disadvantages that a pretty GUI can't fully fix. -------------- 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/20070620/08266d98/attachment.pgp From secret.argent at gmail.com Tue Jun 19 17:05:47 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 19 17:05:52 2007 Subject: [sldev] git vs svn In-Reply-To: <20070619233600.GB16263@bruno.sbruno> References: <20070619182059.420B141B0A5@stupor.lindenlab.com> <20070619233600.GB16263@bruno.sbruno> Message-ID: <3995C3A0-A1FC-493C-B0DB-3E285C23C20B@gmail.com> On 19-Jun-2007, at 18:36, dale@daleglass.net wrote: > I would completely agree here, but IMO it's a strange way to decide. It's social. People are more likely to actually work with the latest code rather than snapshots if getting the latest code is easy. All other things being equal, going for the widely supported platform seems like a good idea. I have a habit of going for the technically superior design and getting clotheslined because everyone's running the other way, myself, so though I'm definitely more comfortable with command line tools I thought it was worth considering hoi polloi. Not saying that "all other things" ARE equal, now. I'm not familiar at all with git, except by reputation, so I'll take your word for its advantages. From rdw at lindenlab.com Tue Jun 19 17:24:42 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Tue Jun 19 17:24:49 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <6A0D0032-7D66-424C-9387-FA2F102C8A53@gmail.com> References: <20070618000236.6DE1A41AF63@stupor.lindenlab.com> <94F226D8-A973-4DCA-A1DA-02D378A047BF@gmail.com> <467856FC.9010303@lindenlab.com> <6A0D0032-7D66-424C-9387-FA2F102C8A53@gmail.com> Message-ID: <467873CA.3050802@lindenlab.com> Argent Stonecutter wrote: > On 19-Jun-2007, at 17:21, Ryan Williams wrote: >> Argent Stonecutter wrote: >>> Are you going to put in HTTP proxy support before going to HTTP for >>> messages? > >> No, because we'll still be using the UDP message system for most >> packets, so proxying wouldn't really make much of a difference. Even >> longer-term, we're likely to still keep using UDP for low-latency >> messages like ObjectUpdate. > > The problem is that if you don't have proxy support a number of people > (including myself) are going to have problems with firewalls (often not > under their control) that restrict communication on port 80 and 443 to > proxy-only. > > I have already had problems with this... I had to get the URLs of the > help files because the internal browser couldn't get to them, and the > first time we had to accept a change in the TOS I had to wait until I > could connect from outside the firewall before I could accept it. > > https://jira.secondlife.com/browse/VWR-1115 The HTTP message system goes over port 12043 so you probably have to fiddle with your firewall in any case. :-( Proxying other uses of HTTP in the viewer (login screen, help, TOS, updater, etc) is something of a different matter, made difficult mostly due to our various HTTP clients: curl, LLHTTPClient, Gecko, InternetOpen/. It's certainly a noble goal for whoever has the cycles to achieve it. -RYaN From dale at daleglass.net Tue Jun 19 17:39:51 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Tue Jun 19 17:39:56 2007 Subject: [sldev] git vs svn In-Reply-To: <3995C3A0-A1FC-493C-B0DB-3E285C23C20B@gmail.com> References: <20070619182059.420B141B0A5@stupor.lindenlab.com> <20070619233600.GB16263@bruno.sbruno> <3995C3A0-A1FC-493C-B0DB-3E285C23C20B@gmail.com> Message-ID: <20070620003951.GC16263@bruno.sbruno> On Tue, Jun 19, 2007 at 07:05:47PM -0500, Argent Stonecutter wrote: > On 19-Jun-2007, at 18:36, dale@daleglass.net wrote: > >I would completely agree here, but IMO it's a strange way to decide. > > It's social. People are more likely to actually work with the latest > code rather than snapshots if getting the latest code is easy. All > other things being equal, going for the widely supported platform > seems like a good idea. I have a habit of going for the technically > superior design and getting clotheslined because everyone's running > the other way, myself, so though I'm definitely more comfortable with > command line tools I thought it was worth considering hoi polloi. Completely agreed here. My point was that IMO, choosing a SCM system on the basis of that it has a nice GUI to it is probably not a very good idea for a project, as even a really great GUI like TortoiseCVS doesn't change the faults of the underlying system (such as the lack of changesets and problems with renaming). > Not saying that "all other things" ARE equal, now. I'm not familiar > at all with git, except by reputation, so I'll take your word for its > advantages. Actually I haven't used git, I'm using SVK here (which I understand is somewhat comparable feature-wise). SVN is a nice system but for this particular application it has the problem of that importing source into it is a pain. While svn-load-dirs helps it's still far from perfect, loses the history from the original repository, can't properly track renames, etc. Now SVK is pretty neat: it can very easily mirror a SVN repository with all its revisions, branches and all, integrate it into its own, and let you merge new changes very easily. Here's for example what I will do when the next version is released: svk sync //mirror/secondlife svk smerge //mirror/secondlife //dg/branches/buildfixes The really neat thing about smerge is that it automatically knows what was the last thing you merged, and continues from that point next time without requiring you to figure out which revision range you need to merge. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070620/2561e7b5/attachment.pgp From soft at lindenlab.com Tue Jun 19 17:55:44 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Jun 19 17:55:45 2007 Subject: [sldev] SLDev-Traffic #16 In-Reply-To: <46781EAA.7070307@dzonux.net> References: <9e6e5c9e0706182301k18294e6dvca82c4c2af9f9631@mail.gmail.com> <46781EAA.7070307@dzonux.net> Message-ID: <9e6e5c9e0706191755m43f54c8avfe4939cbfb761efb@mail.gmail.com> On 6/19/07, Dzonatas wrote: > ----- > > 1.17 PJIRA Cleanup Dzonatas Sol also volunteered to do some maintenance on > the public JIRA following the 1.17 release. I love y'all so much. :) > > ----- > > I'm happy to volunteer, but I don't understand where this notion came from. It was from the mail where Bridie asked for a volunteer to clean up the post-1.17 release JIRA issues. I'm not clear what happened with the rest of your response... but please don't suspect for even half a moment that I think poorly of ya or say anything one way while meaning it the other. I really was glad that you volunteered when Bridie needed help! I've got a tremendous amount of respect for you, flowing from how quickly you jump on board with some of these tasks, and the amount and deep level of information you bring to the table. (I can count on one hand the number of folks I know of who could've fielded a yacc question as clearly and quickly as you did!) If you (or any contributor) ever think you're not getting the kind of positive treatment you're *owed* as contributors, please please *please* don't be shy about pulling me aside in-world or in email to find out what's up. I'll always try to make good! From gwardell at gwsystems.co.il Tue Jun 19 17:57:54 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Tue Jun 19 17:58:02 2007 Subject: [sldev] JIRA: Blockers (crash after login) In-Reply-To: <46784A05.4000605@gmail.com> Message-ID: <045201c7b2d6$0929fa80$a4689943@gwsystems2.com> Hi, There is a common theme that I picked up. They seemed to either start or got worse with release 1.14, and got progressively worse with each new release to date. I am able to reproduce some of the problems, the hangs, on my workstation and I was going to try to work on them, but, alas, I'm swamped with RL work now and not able to finish getting my build environment to going. I agree that it could be video related. Gary > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Jason Giglio > Sent: Tue, June 19, 2007 5:26 PM > To: Dzonatas > Cc: sldev@lists.secondlife.com > Subject: Re: [sldev] JIRA: Blockers (crash after login) > > > Dzonatas wrote: > > > > Here is a list of currently open and reopened jira issues marked as > > blockers. > > > > I have gone through these, resolved almost half of them, commented on > most of them, voted on some. > > There is a big recurring theme though. > > "SL Crashes shortly after logging in" is a big problem still > for a lot > of people. It looks like it may have multiple causes, but > seems to be > video related generally. > > These bugs could be merged into one bug, but it's not clear > it's all the > same problem there. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From able.whitman at gmail.com Tue Jun 19 18:06:34 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jun 19 18:06:36 2007 Subject: [sldev] JIRA: Blockers (crash after login) In-Reply-To: <045201c7b2d6$0929fa80$a4689943@gwsystems2.com> References: <46784A05.4000605@gmail.com> <045201c7b2d6$0929fa80$a4689943@gwsystems2.com> Message-ID: <7b3a84fb0706191806s48b64466u606a423e41b555e5@mail.gmail.com> At least some of the crash-on-startup issues are related to certain ATI video chipsets. In some cases, disabling vertex shaders seems to fix the problem. For me, this issue only affects the WindLight firstlook viewer, and disabling vertex shaders didn't help. Of course, I tried the "update to the latest drivers" bit, but the latest ATI drivers caused my XPSP2 system to bluescreen about every hour or so, and even then, it didn't fix the WindLight viewer crash. Needless to say, I reverted to the previous version :) All of this is to say that I'd be cautious about lumping all the crash-on-startup bugs together without first gathering some data that indicates that they're similar in root cause, not just in repro. --Able On 6/19/07, Gary Wardell wrote: > > Hi, > > There is a common theme that I picked up. > > They seemed to either start or got worse with release 1.14, and got > progressively worse with each new release to date. > > I am able to reproduce some of the problems, the hangs, on my workstation > and I was going to try to work on them, but, alas, I'm > swamped with RL work now and not able to finish getting my build > environment to going. > > I agree that it could be video related. > > Gary > > > -----Original Message----- > > From: sldev-bounces@lists.secondlife.com > > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Jason Giglio > > Sent: Tue, June 19, 2007 5:26 PM > > To: Dzonatas > > Cc: sldev@lists.secondlife.com > > Subject: Re: [sldev] JIRA: Blockers (crash after login) > > > > > > Dzonatas wrote: > > > > > > Here is a list of currently open and reopened jira issues marked as > > > blockers. > > > > > > > I have gone through these, resolved almost half of them, commented on > > most of them, voted on some. > > > > There is a big recurring theme though. > > > > "SL Crashes shortly after logging in" is a big problem still > > for a lot > > of people. It looks like it may have multiple causes, but > > seems to be > > video related generally. > > > > These bugs could be merged into one bug, but it's not clear > > it's all the > > same problem there. > > > > -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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070619/1e3d865a/attachment.htm From tateru.nino at gmail.com Tue Jun 19 20:25:07 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Jun 19 20:25:14 2007 Subject: [sldev] Re: More plugin / platform harping.. In-Reply-To: <467873CA.3050802@lindenlab.com> References: <20070618000236.6DE1A41AF63@stupor.lindenlab.com> <94F226D8-A973-4DCA-A1DA-02D378A047BF@gmail.com> <467856FC.9010303@lindenlab.com> <6A0D0032-7D66-424C-9387-FA2F102C8A53@gmail.com> <467873CA.3050802@lindenlab.com> Message-ID: <46789E13.4040102@gmail.com> Ryan Williams wrote: > Argent Stonecutter wrote: > >> On 19-Jun-2007, at 17:21, Ryan Williams wrote: >> >>> Argent Stonecutter wrote: >>> >>>> Are you going to put in HTTP proxy support before going to HTTP for >>>> messages? >>>> >>> No, because we'll still be using the UDP message system for most >>> packets, so proxying wouldn't really make much of a difference. Even >>> longer-term, we're likely to still keep using UDP for low-latency >>> messages like ObjectUpdate. >>> >> The problem is that if you don't have proxy support a number of people >> (including myself) are going to have problems with firewalls (often not >> under their control) that restrict communication on port 80 and 443 to >> proxy-only. >> >> I have already had problems with this... I had to get the URLs of the >> help files because the internal browser couldn't get to them, and the >> first time we had to accept a change in the TOS I had to wait until I >> could connect from outside the firewall before I could accept it. >> >> https://jira.secondlife.com/browse/VWR-1115 >> > > The HTTP message system goes over port 12043 so you probably have to > fiddle with your firewall in any case. :-( > > Proxying other uses of HTTP in the viewer (login screen, help, TOS, > updater, etc) is something of a different matter, made difficult mostly > due to our various HTTP clients: curl, LLHTTPClient, Gecko, > InternetOpen/. It's certainly a noble goal for whoever has the cycles > to achieve it. > I already proxy the login-screen, and a variety of other things. Edit the prefs.js lurking in your Second Life's application data directories, and insert a standard mozilla set of proxy directives (heck, copy it straight out of your firefox prefs.js). Everything that uses mozilla for heavy HTTP lifting will run through your chosen proxy. I've been running that way since sometime last year. -- Tateru Nino http://dwellonit.blogspot.com/ From benglenn at lindenlab.com Tue Jun 19 20:51:26 2007 From: benglenn at lindenlab.com (Ben Glenn) Date: Tue Jun 19 20:51:38 2007 Subject: [sldev] Office Hours schedule change Message-ID: <04c301c7b2ee$477f63c0$d67e2b40$@com> Folks, Just wanted to let you know about a recent change in my office hours schedule. My office hours on Thursday have moved from 10am to 3pm. So the revised weekly schedule is: Tuesdays @ 10:00-11:00 AM SLT Thursdays @ 3:00-4:00 PM SLT Office hours are held at my office in Linden Village: http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village Thanks, Ben Ben Glenn User Experience Designer Linden Lab | Second Life -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070619/3994d1a4/attachment-0001.htm From kathycat at kol.co.nz Tue Jun 19 21:19:48 2007 From: kathycat at kol.co.nz (kathy) Date: Tue Jun 19 21:20:49 2007 Subject: [sldev] Mailing List add please Message-ID: <002901c7b2f2$5d702990$6b7796ca@yourn6spa3hc62> We have received a request from 202.150.111.41 for subscription of your email address,"kathycat@kol.co.nz", to the sldev@lists.secondlife.com mailing list. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070620/d655eb57/attachment.htm From labrat.hb at gmail.com Tue Jun 19 22:41:08 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Jun 19 22:41:09 2007 Subject: [sldev] JIRA: Blockers (crash after login) In-Reply-To: <7b3a84fb0706191806s48b64466u606a423e41b555e5@mail.gmail.com> References: <46784A05.4000605@gmail.com> <045201c7b2d6$0929fa80$a4689943@gwsystems2.com> <7b3a84fb0706191806s48b64466u606a423e41b555e5@mail.gmail.com> Message-ID: For crash issues like this, people really should be using the crash reporter tool as it can gather the information needed by LL's to isolate and fix the problems. A JIRA bug report on a random crash without a solid reproduction is not something that will be able to be diagnosed or fixed. On 6/19/07, Able Whitman wrote: > > At least some of the crash-on-startup issues are related to certain ATI > video chipsets. In some cases, disabling vertex shaders seems to fix the > problem. For me, this issue only affects the WindLight firstlook viewer, and > disabling vertex shaders didn't help. > > Of course, I tried the "update to the latest drivers" bit, but the latest > ATI drivers caused my XPSP2 system to bluescreen about every hour or so, and > even then, it didn't fix the WindLight viewer crash. Needless to say, I > reverted to the previous version :) > > All of this is to say that I'd be cautious about lumping all the > crash-on-startup bugs together without first gathering some data that > indicates that they're similar in root cause, not just in repro. > > --Able > > On 6/19/07, Gary Wardell wrote: > > > > Hi, > > > > There is a common theme that I picked up. > > > > They seemed to either start or got worse with release 1.14, and got > > progressively worse with each new release to date. > > > > I am able to reproduce some of the problems, the hangs, on my > > workstation and I was going to try to work on them, but, alas, I'm > > swamped with RL work now and not able to finish getting my build > > environment to going. > > > > I agree that it could be video related. > > > > Gary > > > > > -----Original Message----- > > > From: sldev-bounces@lists.secondlife.com > > > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Jason Giglio > > > Sent: Tue, June 19, 2007 5:26 PM > > > To: Dzonatas > > > Cc: sldev@lists.secondlife.com > > > Subject: Re: [sldev] JIRA: Blockers (crash after login) > > > > > > > > > Dzonatas wrote: > > > > > > > > Here is a list of currently open and reopened jira issues marked as > > > > blockers. > > > > > > > > > > I have gone through these, resolved almost half of them, commented on > > > most of them, voted on some. > > > > > > There is a big recurring theme though. > > > > > > "SL Crashes shortly after logging in" is a big problem still > > > for a lot > > > of people. It looks like it may have multiple causes, but > > > seems to be > > > video related generally. > > > > > > These bugs could be merged into one bug, but it's not clear > > > it's all the > > > same problem there. > > > > > > -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 > > > > > _______________________________________________ > 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/20070619/e4b42656/attachment.htm From dzonatas at dzonux.net Wed Jun 20 00:27:37 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 20 00:26:59 2007 Subject: [sldev] SLDev-Traffic #16 In-Reply-To: <9e6e5c9e0706191755m43f54c8avfe4939cbfb761efb@mail.gmail.com> References: <9e6e5c9e0706182301k18294e6dvca82c4c2af9f9631@mail.gmail.com> <46781EAA.7070307@dzonux.net> <9e6e5c9e0706191755m43f54c8avfe4939cbfb761efb@mail.gmail.com> Message-ID: <4678D6E9.7030805@dzonux.net> We like ya, Soft... no worries there. When I spot a bug, even if it is not directly in the source code, I'm pretty good to swat it. I don't always catch them all, but some of them bring out the grin on my face as they squash. =p Soft Linden wrote: > On 6/19/07, Dzonatas wrote: >> ----- >> >> 1.17 PJIRA Cleanup Dzonatas Sol also volunteered to do some >> maintenance on >> the public JIRA following the 1.17 release. I love y'all so much. :) >> >> ----- >> >> I'm happy to volunteer, but I don't understand where this notion >> came from. > > It was from the mail where Bridie asked for a volunteer to clean up > the post-1.17 release JIRA issues. > > I'm not clear what happened with the rest of your response... but > please don't suspect for even half a moment that I think poorly of ya > or say anything one way while meaning it the other. I really was glad > that you volunteered when Bridie needed help! I've got a tremendous > amount of respect for you, flowing from how quickly you jump on board > with some of these tasks, and the amount and deep level of information > you bring to the table. (I can count on one hand the number of folks I > know of who could've fielded a yacc question as clearly and quickly as > you did!) > > If you (or any contributor) ever think you're not getting the kind of > positive treatment you're *owed* as contributors, please please > *please* don't be shy about pulling me aside in-world or in email to > find out what's up. I'll always try to make good! > > -- Power to Change the Void From odysseus654 at gmail.com Wed Jun 20 00:34:34 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Wed Jun 20 00:34:36 2007 Subject: [sldev] JIRA: Blockers (crash after login) In-Reply-To: References: <46784A05.4000605@gmail.com> <045201c7b2d6$0929fa80$a4689943@gwsystems2.com> <7b3a84fb0706191806s48b64466u606a423e41b555e5@mail.gmail.com> Message-ID: <1674f6c70706200034j3813e724rab5a499b8960dff0@mail.gmail.com> While crash reports are great, they aren't the end-all of everything. We've already heard from LL that a majority of crash reports are effectively unusable, showing a crash report somewhere in the graphics core. A combination of both approaches is required. I have the crash reporter run automatically, but I doubt that half my reports do anything. On 6/19/07, Harold Brown wrote: > > For crash issues like this, people really should be using the crash > reporter tool as it can gather the information needed by LL's to isolate and > fix the problems. A JIRA bug report on a random crash without a solid > reproduction is not something that will be able to be diagnosed or fixed. > > > > > On 6/19/07, Able Whitman wrote: > > > > At least some of the crash-on-startup issues are related to certain ATI > > video chipsets. In some cases, disabling vertex shaders seems to fix the > > problem. For me, this issue only affects the WindLight firstlook viewer, and > > disabling vertex shaders didn't help. > > > > Of course, I tried the "update to the latest drivers" bit, but the > > latest ATI drivers caused my XPSP2 system to bluescreen about every hour or > > so, and even then, it didn't fix the WindLight viewer crash. Needless to > > say, I reverted to the previous version :) > > > > All of this is to say that I'd be cautious about lumping all the > > crash-on-startup bugs together without first gathering some data that > > indicates that they're similar in root cause, not just in repro. > > > > --Able > > > > On 6/19/07, Gary Wardell wrote: > > > > > > Hi, > > > > > > There is a common theme that I picked up. > > > > > > They seemed to either start or got worse with release 1.14, and got > > > progressively worse with each new release to date. > > > > > > I am able to reproduce some of the problems, the hangs, on my > > > workstation and I was going to try to work on them, but, alas, I'm > > > swamped with RL work now and not able to finish getting my build > > > environment to going. > > > > > > I agree that it could be video related. > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: sldev-bounces@lists.secondlife.com > > > > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Jason Giglio > > > > > > > Sent: Tue, June 19, 2007 5:26 PM > > > > To: Dzonatas > > > > Cc: sldev@lists.secondlife.com > > > > Subject: Re: [sldev] JIRA: Blockers (crash after login) > > > > > > > > > > > > Dzonatas wrote: > > > > > > > > > > Here is a list of currently open and reopened jira issues marked > > > as > > > > > blockers. > > > > > > > > > > > > > I have gone through these, resolved almost half of them, commented > > > on > > > > most of them, voted on some. > > > > > > > > There is a big recurring theme though. > > > > > > > > "SL Crashes shortly after logging in" is a big problem still > > > > for a lot > > > > of people. It looks like it may have multiple causes, but > > > > seems to be > > > > video related generally. > > > > > > > > These bugs could be merged into one bug, but it's not clear > > > > it's all the > > > > same problem there. > > > > > > > > -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 > > > > > > > > > _______________________________________________ > > 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/20070620/a955bb26/attachment-0001.htm From able.whitman at gmail.com Wed Jun 20 00:41:36 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 20 00:41:39 2007 Subject: [sldev] JIRA: Blockers (crash after login) In-Reply-To: <1674f6c70706200034j3813e724rab5a499b8960dff0@mail.gmail.com> References: <46784A05.4000605@gmail.com> <045201c7b2d6$0929fa80$a4689943@gwsystems2.com> <7b3a84fb0706191806s48b64466u606a423e41b555e5@mail.gmail.com> <1674f6c70706200034j3813e724rab5a499b8960dff0@mail.gmail.com> Message-ID: <7b3a84fb0706200041l3f64ce11oa0813b2339d45214@mail.gmail.com> Admittedly, I'm not very familiar with how the crash reporter works, so this may be a silly question: Is there anything we can do to improve the usefulness of the crash reports that are submitted? Or is their unusefulness simply a consequence of the crashes happening in graphics-card-specific code? On 6/20/07, Erik Anderson wrote: > > While crash reports are great, they aren't the end-all of everything. > We've already heard from LL that a majority of crash reports are effectively > unusable, showing a crash report somewhere in the graphics core. A > combination of both approaches is required. I have the crash reporter run > automatically, but I doubt that half my reports do anything. > > On 6/19/07, Harold Brown wrote: > > > > For crash issues like this, people really should be using the crash > > reporter tool as it can gather the information needed by LL's to isolate and > > fix the problems. A JIRA bug report on a random crash without a solid > > reproduction is not something that will be able to be diagnosed or fixed. > > > > > > > > > > On 6/19/07, Able Whitman wrote: > > > > > > At least some of the crash-on-startup issues are related to certain > > > ATI video chipsets. In some cases, disabling vertex shaders seems to fix the > > > problem. For me, this issue only affects the WindLight firstlook viewer, and > > > disabling vertex shaders didn't help. > > > > > > Of course, I tried the "update to the latest drivers" bit, but the > > > latest ATI drivers caused my XPSP2 system to bluescreen about every hour or > > > so, and even then, it didn't fix the WindLight viewer crash. Needless to > > > say, I reverted to the previous version :) > > > > > > All of this is to say that I'd be cautious about lumping all the > > > crash-on-startup bugs together without first gathering some data that > > > indicates that they're similar in root cause, not just in repro. > > > > > > --Able > > > > > > On 6/19/07, Gary Wardell wrote: > > > > > > > > Hi, > > > > > > > > There is a common theme that I picked up. > > > > > > > > They seemed to either start or got worse with release 1.14, and got > > > > progressively worse with each new release to date. > > > > > > > > I am able to reproduce some of the problems, the hangs, on my > > > > workstation and I was going to try to work on them, but, alas, I'm > > > > swamped with RL work now and not able to finish getting my build > > > > environment to going. > > > > > > > > I agree that it could be video related. > > > > > > > > Gary > > > > > > > > > -----Original Message----- > > > > > From: sldev-bounces@lists.secondlife.com > > > > > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Jason > > > > Giglio > > > > > Sent: Tue, June 19, 2007 5:26 PM > > > > > To: Dzonatas > > > > > Cc: sldev@lists.secondlife.com > > > > > Subject: Re: [sldev] JIRA: Blockers (crash after login) > > > > > > > > > > > > > > > Dzonatas wrote: > > > > > > > > > > > > Here is a list of currently open and reopened jira issues marked > > > > as > > > > > > blockers. > > > > > > > > > > > > > > > > I have gone through these, resolved almost half of them, commented > > > > on > > > > > most of them, voted on some. > > > > > > > > > > There is a big recurring theme though. > > > > > > > > > > "SL Crashes shortly after logging in" is a big problem still > > > > > for a lot > > > > > of people. It looks like it may have multiple causes, but > > > > > seems to be > > > > > video related generally. > > > > > > > > > > These bugs could be merged into one bug, but it's not clear > > > > > it's all the > > > > > same problem there. > > > > > > > > > > -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 > > > > > > > > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070620/6c648b5b/attachment.htm From able.whitman at gmail.com Wed Jun 20 01:09:20 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 20 01:09:22 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 Message-ID: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> I'm trying to build a Debug configuration of the 1.17.0.12 sources under VC8. Using Nicholasz's VC8 project files, just building the project as-is resulted in some linker errors because the Debug config hadn't been changed to use the VC8 versions of the APR and Mozilla libraries. Fixing this problem resulted in other linker errors, particularly a missing fmod library. So I copied the missing .libs from the "i686-win32\lib_release" folder to the "lib_debug" folder, which solved the fmod problem. Then I got linker errors about the VC8 Mozilla lib, indicating that there were a couple of cookie-related exported functions that (apparently) were in the release version of the VC8 Mozilla lib, but not in the debug version. So I copied the release Mozilla libs into the lib_debug folder. This nearly works, but now I keep getting the following linker error: "llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: unresolved external symbol __invalid_parameter_noinfo referenced in function "public: class std::list >::_Const_iterator<1> & __thiscall std::list >::_Const_iterator<1>::operator++(void)" (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$allocator@ PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@ QAEAAV012@XZ)" The symbol in question, "__invalid_parameter_noinfo" is related to checked STL iterators (see: http://msdn2.microsoft.com/En-US/library/aa985965(VS.80).aspx ), so I tried disabling them by setting the symbol _SECURE_SCL=0 (see: http://msdn2.microsoft.com/En-US/library/aa985896(VS.80).aspx). This didn't solve the problem. I thought the problem is that the "__invalid_parameter_noinfo" symbol is used in the non-debug CRT (msvcrt), but not the debug version (msvcrtd). But I built the Debug configuration against the non-debug multi-threaded CRT to see if this solves the problem. (Even though I'd much prefer to use msvcrtd in the Debug config.) This also did not solve the problem. At this point, I believe that the right solution is to get a version of the VC8 Mozilla lib that is built against the debug version of the VC8 CRT (msvcrtd). I don't think this is something I can produce myself, but if anyone else has some insight into how to solve this problem, please let me know. I'm hoping it's something simple and dumb that I've overlooked, because I would rather have a working Debug build and look foolish than not have one. :) --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070620/06e63ec4/attachment.htm From nicholaz at blueflash.cc Wed Jun 20 01:55:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 20 01:55:41 2007 Subject: [sldev] JIRA: Blockers (crash after login)] Message-ID: <4678EB76.4080305@blueflash.cc> I'm doing the crash report thing with the users of my version. The normal crash reports LL is using have probably outlived their usefulness because they show only where the crash happens with the stack (see the Wiki or JIRA). This IS helpful for simple situations, like not checking for a null pointer before doing something, but even if someone loaded them into a debugger and spent time on them, they just show the stack, the registers and that was it (you're lucky if you get a variable occacsionally). I'm justing the crash logger with MediumDumps (2MB- 8MB)and even there it is hard and time consuming. Someone with a reproduceable hard crashe is usually an excellent source for bug swatting, but it takes time and dedication to do so. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Wed Jun 20 01:57:37 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 20 01:57:55 2007 Subject: [sldev] JIRA: Blockers (crash after login) In-Reply-To: References: <46784A05.4000605@gmail.com> <045201c7b2d6$0929fa80$a4689943@gwsystems2.com> <7b3a84fb0706191806s48b64466u606a423e41b555e5@mail.gmail.com> Message-ID: <4678EC01.2040102@blueflash.cc> Harold Brown wrote: > For crash issues like this, people really should be using the crash > reporter tool as it can gather the information needed by LL's to isolate > and fix the problems. A JIRA bug report on a random crash without a > solid reproduction is not something that will be able to be diagnosed or > fixed. You can't even provide specifics with the crash reporter, like if it happens always or was just a stray crash on a laggy day. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From Paul.Hampson at Pobox.com Wed Jun 20 06:34:07 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Wed Jun 20 06:34:16 2007 Subject: [sldev] Created page on source control In-Reply-To: <4677FFD4.40202@dzonux.net> References: <200706190425.05929.dale@daleglass.net> <20070619130619.GA5755@keitarou> <4677FFD4.40202@dzonux.net> Message-ID: <20070620133407.GA15605@keitarou> On Tue, Jun 19, 2007 at 09:09:56AM -0700, Dzonatas wrote: > Paul TBBle Hampson wrote: > >Having recently become enamoured of git, (and git-svn), I'd love to > > > Torvalds has recently lobbied git as ready for mainstream, but he also > noted that it doesn't have all the nice front-end features of other > SCMs. If git can be used with tools like TortiseSVN/TortiseMerge, or > anything like that, it may be worthwhile to review. Indeed. I'm hoping TortoiseGIT is ready in time for the next project at work, since the size of the repositories we deal with makes an SVN checkout unneccesarily expensive. > The major difference is that the repository has to be broken up into > git-projects unlike where everything is put together in svn, being > only delineated by directories. I don't understand what you mean by this... If you're suggesting that SVN can have repos at both svn://server/bob and svn://server/bob/subbranch, that's actually a rather painful way of dealing with repositories, I think. If you're talking about being able to have branches named things like /branches/bob/beaver/firsttry, that turns out to still be a rather difficult way of dealing with things. I like that git has pulled branches and tags back out of the directory namespace, while keeping branching as cheap or cheaper than svn, with the added bonus of being able to throw away branches trivially. For example, my git-svn workflow involves frequent calls of: git-commit -m Shelf -a && git-svn rebase && git-reset HEAD^ which is neccessary because git-svn's rebase requires a clean tree, with nothing uncomitted, and this puts me back where I was before the rebase. This is the equivalent of svn update, except that it can merge files I've added with identical content, rather than aborting the update and complaining to me. > Torvalds tends to compare svn to cvs in the sense of a linear > repository, which cvs is a major restriction of cvs. He doesn't seem > to make any comparison to a svn repository that is setup more to a > deep tree structure. You can easily recognized the branch level in > svn. Most svn users still have their repository setup in a linear > fashion with one branch level, being one branch directory with lots of > version directories stuck under that one branch directory. The power > of git can be still simulated in a svn-repository with the deeper tree > structure, where you have branches that spawn more branch directories > and each sub-branch level feeds into the super-branch level. At that > point, git only does it in a more distributed fashion. The issues Linus raises with svn and cvs aren't to do with the namespace, but to do with the fundamentals of branching, merging and distribution. I would _love_ to be able to say to a non-programmer who's assets I'm programming for "Please pull and see if it works" rather than either comitting the code untested, getting the assets and committing them from my tree, pulling the assets into my working copy, testing the code and then purging the assets so the final assets don't conflict with them, or any other variation that SVN currently enforces upon me. The pain of a 'switch' against a large SVN repository, even if most files aren't changing, compounds upon the fact that if the non-programmer is dealing with assets that two different code branches use, it may be impossible to switch to something that'll allow testing. We've basically come to the conclusion that 'no branching' is the rule, at least for the projects that have to be in the always-usable state. I am looking forward to the subprojects support in git becoming more integrated in the porcelins, since juggling upstream source is a source of concern, which SVN externals have made roughly bearable. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070620/4a7f6877/attachment-0001.pgp From Paul.Hampson at Pobox.com Wed Jun 20 06:54:19 2007 From: Paul.Hampson at Pobox.com (Paul TBBle Hampson) Date: Wed Jun 20 06:54:21 2007 Subject: [sldev] git vs svn In-Reply-To: <20070620003951.GC16263@bruno.sbruno> References: <20070619182059.420B141B0A5@stupor.lindenlab.com> <20070619233600.GB16263@bruno.sbruno> <3995C3A0-A1FC-493C-B0DB-3E285C23C20B@gmail.com> <20070620003951.GC16263@bruno.sbruno> Message-ID: <20070620135419.GB15605@keitarou> On Wed, Jun 20, 2007 at 02:39:51AM +0200, dale@daleglass.net wrote: > On Tue, Jun 19, 2007 at 07:05:47PM -0500, Argent Stonecutter wrote: >> Not saying that "all other things" ARE equal, now. I'm not familiar >> at all with git, except by reputation, so I'll take your word for its >> advantages. > Actually I haven't used git, I'm using SVK here (which I understand is > somewhat comparable feature-wise). You might find [1] interesting, it's basically demonstrating svk and svn workflows using git-svn, as the first steps towards migrating to git. [1] http://utsl.gen.nz/talks/git-svn/intro.html -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ ----------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070620/9541377c/attachment.pgp From nicholaz at blueflash.cc Wed Jun 20 07:16:39 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 20 07:16:54 2007 Subject: [sldev] Pointers 0x3f800000 In-Reply-To: <467842CE.5000509@watson.ibm.com> References: <4677CB32.6000007@blueflash.cc> <467842CE.5000509@watson.ibm.com> Message-ID: <467936C7.6000004@blueflash.cc> Oh .. thanks' helpful ... thanks! Nick Mike Monkowski wrote: > Nicholaz Beresford wrote: >> >> I've been looking at crash dumps from users of my viewer >> lately and I'm seeing pointers with a value of 0x3f800000 >> in some of them (e.g. crashing on deletion of a refcounted >> object where the pointer has this value). >> >> It may be a memory overwrite, but does this particular value >> ring any bells with anyone? > > float 1.0 > > Mike > > From nicholaz at blueflash.cc Wed Jun 20 07:17:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 20 07:17:28 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> Message-ID: <467936EE.9010200@blueflash.cc> I'll try this later today ... will let you know what comes out. Nick Able Whitman wrote: > I'm trying to build a Debug configuration of the 1.17.0.12 > sources under VC8. Using Nicholasz's VC8 project > files, just building the project as-is resulted in some linker errors > because the Debug config hadn't been changed to use the VC8 versions of > the APR and Mozilla libraries. Fixing this problem resulted in other > linker errors, particularly a missing fmod library. So I copied the > missing .libs from the "i686-win32\lib_release" folder to the > "lib_debug" folder, which solved the fmod problem. From dale at daleglass.net Wed Jun 20 07:19:16 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Wed Jun 20 07:19:19 2007 Subject: [sldev] git vs svn In-Reply-To: <20070620135419.GB15605@keitarou> References: <20070619182059.420B141B0A5@stupor.lindenlab.com> <20070619233600.GB16263@bruno.sbruno> <3995C3A0-A1FC-493C-B0DB-3E285C23C20B@gmail.com> <20070620003951.GC16263@bruno.sbruno> <20070620135419.GB15605@keitarou> Message-ID: <20070620141916.GA32255@bruno.sbruno> On Wed, Jun 20, 2007 at 11:54:19PM +1000, Paul TBBle Hampson wrote: > > Actually I haven't used git, I'm using SVK here (which I understand is > > somewhat comparable feature-wise). > > You might find [1] interesting, it's basically demonstrating svk > and svn workflows using git-svn, as the first steps towards migrating > to git. > > [1] http://utsl.gen.nz/talks/git-svn/intro.html Will check it out, thanks, although I doubt I'll migrate to git unless SVK does something really nasty. I just finished figuring it out here and I'm itching to get back to coding instead of messing with SCMs. -------------- 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/20070620/84eb7dc8/attachment.pgp From alissa_sabre at yahoo.co.jp Wed Jun 20 08:28:50 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Jun 20 08:29:05 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> Message-ID: <1dsdfP46xwwkQ8r5ck66.alissa_sabre@yahoo.co.jp> > I'm trying to build a Debug configuration of the 1.17.0.12 sources under > VC8. Hmm. I've been thinking that ReleaseNoOpt and ReleaseForDownload are the only working build configuration and others (Debug, DebugMesaHeadless, Release) are just garbages, because the wiki says: Build either ReleaseNoOpt (for debugging) or ReleaseForDownload (for production.)" Of course, I may be wrong. Alissa -------------------------------------- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ From able.whitman at gmail.com Wed Jun 20 08:56:26 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 20 08:56:29 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <1dsdfP46xwwkQ8r5ck66.alissa_sabre@yahoo.co.jp> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> <1dsdfP46xwwkQ8r5ck66.alissa_sabre@yahoo.co.jp> Message-ID: <7b3a84fb0706200856o7eef3a97v664399fe3e0c99ba@mail.gmail.com> That's a good point, although if the Debug configuration is garbage, then I'll take the time to make it buildable. The Debug configuration is useful primarily because it additionally defines the "_DEBUG" symbol in conjunction with the debug version of MSVCRT. This combination is pretty useful, since it maps malloc calls to _malloc_dbg which keeps track of memory allocation information (e.g., the source line where the allocation occurred), which applies to the new and delete operators as well. It also enables the debug heap, which, since I'm currently trying to track down a memory corruption issue, would make my life a bit easier. :) The debug MSVCRT also includes asserts and other runtime validation that the release version does not and, crucially, using the _DEBUG symbol requires the debug MSVCRT since _malloc_dbg is not defined in the retail one. I'll have more time to investigate this issue later, and I'll pass along what I find out. On 6/20/07, Alissa Sabre wrote: > > > I'm trying to build a Debug configuration of the 1.17.0.12 sources under > > VC8. > > Hmm. > > I've been thinking that ReleaseNoOpt and ReleaseForDownload are the > only working build configuration and others (Debug, DebugMesaHeadless, > Release) are just garbages, because the wiki says: > > Build either ReleaseNoOpt (for debugging) or ReleaseForDownload (for > production.)" > > Of course, I may be wrong. > > Alissa > -------------------------------------- > Start Yahoo! Auction now! Check out the cool campaign > http://pr.mail.yahoo.co.jp/auction/ > _______________________________________________ > 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/20070620/174305fd/attachment.htm From nicholaz at blueflash.cc Wed Jun 20 09:24:02 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 20 09:24:22 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <1dsdfP46xwwkQ8r5ck66.alissa_sabre@yahoo.co.jp> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> <1dsdfP46xwwkQ8r5ck66.alissa_sabre@yahoo.co.jp> Message-ID: <467954A2.3080605@blueflash.cc> I have Debug running under VS2003 so I don't see a reason why it should not work under VS2005. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Alissa Sabre wrote: >> I'm trying to build a Debug configuration of the 1.17.0.12 sources under >> VC8. > > Hmm. > > I've been thinking that ReleaseNoOpt and ReleaseForDownload are the > only working build configuration and others (Debug, DebugMesaHeadless, > Release) are just garbages, because the wiki says: > > Build either ReleaseNoOpt (for debugging) or ReleaseForDownload (for > production.)" > > Of course, I may be wrong. > > Alissa > -------------------------------------- > Start Yahoo! Auction now! Check out the cool campaign > http://pr.mail.yahoo.co.jp/auction/ > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From josh at lindenlab.com Wed Jun 20 09:40:23 2007 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jun 20 09:40:03 2007 Subject: [sldev] git vs svn In-Reply-To: <20070619233600.GB16263@bruno.sbruno> References: <20070619182059.420B141B0A5@stupor.lindenlab.com> <20070619233600.GB16263@bruno.sbruno> Message-ID: <46795877.901@lindenlab.com> dale@daleglass.net wrote: > On Tue, Jun 19, 2007 at 06:11:38PM -0500, Argent Stonecutter wrote: > >> I would note that there are a number of good GUI SVN client >> applications available for OSX and Windows. Git seems to have less >> widespread support. >> > > I would completely agree here, but IMO it's a strange way to decide. > To throw something else into the mix: Mercurial is apparently quite similar in terms of usage patterns to git, is cross-platform, easily extensible, and there is a "tortoise-hg" project under way to create a TortoiseSVN-like GUI on top of Mercurial for Windows. I'm keeping an eye on that. (FWIW, I do most of my merges via command line SVN, but when I'm drilling through the history of a branch, trying to find a change, or wanting to diff two versions, I find the TortoiseSVN GUI is much faster. When doing a big merge I'll often have both a command-line merge and color-coded svn diff results up on one screen and TortoiseSVN up on another so I can cross-check the changes.) From nicholaz at blueflash.cc Wed Jun 20 10:53:36 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 20 10:53:57 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> Message-ID: <467969A0.4020507@blueflash.cc> I found a few quirks in my vc8 files and will make a V3.ZIP of it later. But meanwhile - newview, properties, linker, input, ignore specific library, and add "libcmt;" to exclude the non debug library from the build - newview, Source folder, right-click, Add existing It does compile ... didn't try if it runs but I hope that the function won't actually be called. Dunno if you have it already, but I can also send you my stuff to actually use the malloc_dbg functions. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Able Whitman wrote: > I'm trying to build a Debug configuration of the 1.17.0.12 > sources under VC8. Using Nicholasz's VC8 project > files, just building the project as-is resulted in some linker errors > because the Debug config hadn't been changed to use the VC8 versions of > the APR and Mozilla libraries. Fixing this problem resulted in other > linker errors, particularly a missing fmod library. So I copied the > missing .libs from the "i686-win32\lib_release" folder to the > "lib_debug" folder, which solved the fmod problem. -------------- next part -------------- #include // HACK [Nicholas Beresford] // // implement _invalid_parameter_noinfo to keep llmozlib-vc80 happy in debug mode // #ifdef _DEBUG extern "C" { extern void __cdecl _invalid_parameter( const wchar_t *pszExpression, const wchar_t *pszFunction, const wchar_t *pszFile, unsigned int nLine, uintptr_t pReserved ); // code below is borrowed from // C:\Program Files\Microsoft Visual Studio 8\VC\crt\src\invarg.c /* wrapper which passes no debug info; not available in debug * used in inline code: we don't pass the null params, so we gain some * speed and space in code generation */ void __cdecl _invalid_parameter_noinfo(void) { __asm int 3; // [NB] we don't expect to actually be called (if so, raise a user exception) _invalid_parameter(NULL, NULL, NULL, 0, 0); } } #endif // ~HACK [Nicholas Beresford] From nicholaz at blueflash.cc Wed Jun 20 10:57:38 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 20 10:57:57 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> Message-ID: <46796A92.8050307@blueflash.cc> Ouch, actually it doesn't seem to run. Dunno if I did something wrong with that piece of code, maybe it helps someone somehow anyway. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From able.whitman at gmail.com Wed Jun 20 11:08:56 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 20 11:08:57 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <46796A92.8050307@blueflash.cc> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> <46796A92.8050307@blueflash.cc> Message-ID: <7b3a84fb0706201108n214e97c0wc2fe55cf51955231@mail.gmail.com> Thanks, Nick. When I get some time later investigate further, I'll give your code a shot. On 6/20/07, Nicholaz Beresford wrote: > > > Ouch, actually it doesn't seem to run. Dunno if > I did something wrong with that piece of code, maybe > it helps someone somehow anyway. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070620/65197f5d/attachment.htm From able.whitman at gmail.com Wed Jun 20 15:39:32 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 20 15:39:35 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <46796A92.8050307@blueflash.cc> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> <46796A92.8050307@blueflash.cc> Message-ID: <7b3a84fb0706201539v2ca332e3rf3d12045654edcd5@mail.gmail.com> Okay, with Nick's clever hack, I managed to get the Debug configuration to build successfully. However, I'm hitting an access violation during startup: "Unhandled exception at 0x02d79179 in debugview.exe: 0xC0000005: Access violation writing location 0x0c368000." The culprit is "debugview.exe!LLMozLib::init() + 0x56 bytes", called from idle_startup() on line 536 of llstartup.cpp. Curiously, the call to idle_startup is missing from the debugger call stack, which jumps immediately from the call to idle() on line 3566 of viewer.cpp to the call to LLMozLib::init(). I suspect that something about linking the Debug build with the release version of llmozlib-vc80.lib is causing problems, even though __invalid_parameter() has been defined. Linking against the supplied debug version of llmozlib-vc80.lib doesn't work, and results in 3 unresolved externals: llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLMozLib::enableCookies(bool)" ... "public: virtual void __thiscall LLPanelWeb::refresh(void)" llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLMozLib::clearAllCookies(void)" ... referenced in function "private: static void __cdecl LLPanelWeb::callback_clear_cookies(int,void *)" llstartup.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLMozLib::init(class std::basic_string,class std::allocator >,class std::basic_string,class std::allocator >,class std::basic_string,class std::allocator >)" ... referenced in function "int __cdecl idle_startup(void)" It looks to me like these functions are related to the new cookie handling Preferences added in 1.17, and that someone forgot to rebuild the debug version of llmozlib-vc80.lib before the source went out the door. :) What are the reasons that the source for llmoz lib isn't included with the rest of the source? My next step is to build my own version of it, but is the version at http://www.ubrowser.com/downloads.php (dated 2006-11-06) the latest version? --Able On 6/20/07, Nicholaz Beresford wrote: > > > Ouch, actually it doesn't seem to run. Dunno if > I did something wrong with that piece of code, maybe > it helps someone somehow anyway. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070620/6026c98b/attachment.htm From nicholaz at blueflash.cc Wed Jun 20 16:10:09 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 20 16:10:29 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <7b3a84fb0706201539v2ca332e3rf3d12045654edcd5@mail.gmail.com> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> <46796A92.8050307@blueflash.cc> <7b3a84fb0706201539v2ca332e3rf3d12045654edcd5@mail.gmail.com> Message-ID: <4679B3D1.5000604@blueflash.cc> Able, have you tried to just #ifndef _DEBUG the calls to those two functions and use an MozLib::init from an older source? They sound as if the viewer could run without them. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Able Whitman wrote: > Okay, with Nick's clever hack, I managed to get the Debug configuration > to build successfully. However, I'm hitting an access violation during > startup: > > "Unhandled exception at 0x02d79179 in debugview.exe : 0xC0000005: Access > violation writing location 0x0c368000." > > The culprit is "debugview.exe!LLMozLib::init() + 0x56 bytes", called > from idle_startup() on line 536 of llstartup.cpp. Curiously, the call to > idle_startup is missing from the debugger call stack, which jumps > immediately from the call to idle() on line 3566 of viewer.cpp to the > call to LLMozLib::init(). > > I suspect that something about linking the Debug build with the release > version of llmozlib-vc80.lib is causing problems, even though > __invalid_parameter() has been defined. Linking against the supplied > debug version of llmozlib-vc80.lib doesn't work, and results in 3 > unresolved externals: > > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::enableCookies(bool)" ... "public: virtual void > __thiscall LLPanelWeb::refresh(void)" > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::clearAllCookies(void)" ... referenced in function > "private: static void __cdecl > LLPanelWeb::callback_clear_cookies(int,void *)" > llstartup.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::init(class std::basic_string std::char_traits,class std::allocator >,class > std::basic_string,class > std::allocator >,class std::basic_string std::char_traits,class std::allocator >)" ... referenced in > function "int __cdecl idle_startup(void)" > > It looks to me like these functions are related to the new cookie > handling Preferences added in 1.17, and that someone forgot to rebuild > the debug version of llmozlib-vc80.lib before the source went out the > door. :) > > What are the reasons that the source for llmoz lib isn't included with > the rest of the source? My next step is to build my own version of it, > but is the version at http://www.ubrowser.com/downloads.php (dated > 2006-11-06) the latest version? > > --Able > > > On 6/20/07, *Nicholaz Beresford* < nicholaz@blueflash.cc > > wrote: > > > Ouch, actually it doesn't seem to run. Dunno if > I did something wrong with that piece of code, maybe > it helps someone somehow anyway. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > From soft at lindenlab.com Wed Jun 20 16:14:32 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jun 20 16:14:37 2007 Subject: [sldev] CPU and GPU statistics Message-ID: <9e6e5c9e0706201614p44340c6ch72b3710c795d062a@mail.gmail.com> The question of what CPUs SL users have has come up a number of times, and I believe GPUs have been mentioned as well. Attached, please find statistics on CPUs and reported GPUs for all platforms over a similar one week period. I haven't made any attempt to consolidate similar CPUs and GPUs. I don't know enough about the models to know where I might omit something important, such as cache size or SIMD abilities varying between two clocks of a like part model. I did remove the labels from two graphic cards/drivers, where I wasn't sure that the name reported was accurate, or that it didn't reveal personal information. I formatted this as CSV, which should parse by Excel, OpenOffice, or your favorite perl script. Let me know if ya find any interesting surprises. If you want to take a swing at summarizing, grouping by capability, or the like, that would be awesome. If this message comes through without two attachments, then I've learned a lesson about utf-8 or attachment sizes :) -------------- next part -------------- "CPU","Unique Agents","% Uniq Agents" "Intel Pentium 4 (Unknown model) (2992 MHz)",11488,2.21% "Intel Pentium 4 (Unknown model) (2793 MHz)",9511,1.83% "Intel Pentium Pro (Unknown model) (1662 MHz)",9152,1.76% "Intel Pentium Pro (Unknown model) (1596 MHz)",8257,1.59% "Intel Pentium 4 (Unknown model) (3000 MHz)",8147,1.57% "Intel Pentium Pro (Unknown model) (1729 MHz)",7937,1.53% "Intel Pentium Pro (Unknown model) (1595 MHz)",6964,1.34% "Intel Pentium Pro (Unknown model) (1728 MHz)",5743,1.11% "Intel Pentium Pro (Unknown model) (1862 MHz)",5726,1.10% "AMD (Unknown model) (2009 MHz)",5664,1.09% "AMD (Unknown model) (1808 MHz)",5507,1.06% "Intel Pentium 4 (Unknown model) (3192 MHz)",5287,1.02% "Dual i386 (Unknown) (2160 MHz)",5071,0.98% "Intel Pentium Pro (Unknown model) (1828 MHz)",5051,0.97% "AMD (Unknown model) (1607 MHz)",4950,0.95% "AMD (Unknown model) (2210 MHz)",4925,0.95% "Intel Pentium Pro (Unknown model) (1994 MHz)",4900,0.94% "Intel Pentium 4 (Unknown model) (2800 MHz)",4721,0.91% "Dual i386 (Unknown) (2000 MHz)",4576,0.88% "Intel Pentium Pro (Unknown model) (1995 MHz)",4463,0.86% "AMD (Unknown model) (2211 MHz)",4316,0.83% "AMD (Unknown model) (2010 MHz)",4209,0.81% "Can't get terse CPU information",4050,0.78% "Intel Pentium 4 (Unknown model) (3200 MHz)",3647,0.70% "AMD (Unknown model) (1800 MHz)",3160,0.61% "Intel Pentium Pro (Unknown model) (1861 MHz)",3038,0.59% "Intel Pentium 4 (Unknown model) (3391 MHz)",3014,0.58% "Intel Pentium 4 (Unknown model) (2792 MHz)",3005,0.58% "AMD (Unknown model) (1790 MHz)",2985,0.58% "AMD (Unknown model) (2004 MHz)",2924,0.56% "Intel Pentium Pro (Unknown model) (598 MHz)",2886,0.56% "Intel Pentium 4 Northwood (2793 MHz)",2812,0.54% "Intel Pentium 4 Northwood (2992 MHz)",2809,0.54% "Intel Pentium Pro (Unknown model) (798 MHz)",2746,0.53% "Intel Pentium Pro (Unknown model) (797 MHz)",2693,0.52% "AMD (Unknown model) (2188 MHz)",2642,0.51% "AMD (Unknown model) (2000 MHz)",2613,0.50% "Dual i386 (Unknown) (2330 MHz)",2605,0.50% "Intel Pentium 4 (Unknown model) (2999 MHz)",2532,0.49% "Intel Pentium Pro (Unknown model) (1496 MHz)",2527,0.49% "Dual i386 (Unknown) (1830 MHz)",2464,0.47% "AMD (Unknown model) (2204 MHz)",2438,0.47% "Dual i386 (Unknown) (1990 MHz)",2403,0.46% "AMD (Unknown model) (1989 MHz)",2381,0.46% "Intel Pentium Pro (Unknown model) (2128 MHz)",2307,0.44% "AMD (Unknown model) (803 MHz)",2282,0.44% "Intel Pentium 4 (Unknown model) (2799 MHz)",2250,0.43% "AMD (Unknown model) (1803 MHz)",2140,0.41% "Intel Pentium Pro (Unknown model) (1600 MHz)",2140,0.41% "Intel Pentium 4 Northwood (2392 MHz)",2079,0.40% "Intel Pentium 4 Northwood (2800 MHz)",2075,0.40% "Intel Pentium Pro (Unknown model) (2400 MHz)",2025,0.39% "AMD (Unknown model) (1809 MHz)",1995,0.38% "AMD (Unknown model) (1595 MHz)",1961,0.38% "AMD (Unknown model) (1600 MHz)",1947,0.38% "Intel Pentium Pro (Unknown model) (2133 MHz)",1944,0.37% "AMD (Unknown model) (2200 MHz)",1930,0.37% "Intel Pentium 4 (Unknown model) (2666 MHz)",1915,0.37% "AMD (Unknown model) (1002 MHz)",1906,0.37% "Intel Pentium Pro (Unknown model) (1396 MHz)",1887,0.36% "Intel Pentium 4 (Unknown model) (3066 MHz)",1848,0.36% "AMD (Unknown model) (1999 MHz)",1753,0.34% "Intel Pentium Pro (Unknown model) (1594 MHz)",1723,0.33% "Intel Pentium 4 (Unknown model) (3059 MHz)",1699,0.33% "AMD (Unknown model) (1799 MHz)",1672,0.32% "AMD (Unknown model) (2412 MHz)",1631,0.31% "AMD (Unknown model) (1599 MHz)",1579,0.30% "AMD (Unknown model) (797 MHz)",1577,0.30% "Intel Pentium 4 Northwood (2400 MHz)",1565,0.30% "AMD K7 (Unknown model) (1666 MHz)",1549,0.30% "Intel Pentium Pro (Unknown model) (1866 MHz)",1537,0.30% "AMD (Unknown model) (2411 MHz)",1500,0.29% "Intel Pentium 4 (Unknown model) (3400 MHz)",1496,0.29% "Intel Pentium Pro (Unknown model) (1663 MHz)",1496,0.29% "AMD K7 (Unknown model) (1999 MHz)",1484,0.29% "Intel Pentium 4 (Unknown model) (3010 MHz)",1479,0.28% "AMD (Unknown model) (1994 MHz)",1478,0.28% "AMD (Unknown model) (2405 MHz)",1456,0.28% "Intel Pentium 4 Northwood (2593 MHz)",1421,0.27% "PowerPC 7450 (1500 MHz)",1420,0.27% "PowerPC 7450 (1333 MHz)",1390,0.27% "Intel Pentium Pro (Unknown model) (1598 MHz)",1381,0.27% "Intel Pentium 4 (Unknown model) (2660 MHz)",1372,0.26% "Intel Pentium Pro (Unknown model) (1997 MHz)",1371,0.26% "Intel Pentium 4 Northwood (2394 MHz)",1342,0.26% "Intel Pentium 4 Northwood (2399 MHz)",1325,0.26% "AMD K7 (Unknown model) (2079 MHz)",1315,0.25% "AMD (Unknown model) (1596 MHz)",1313,0.25% "Intel Pentium Pro (Unknown model) (599 MHz)",1307,0.25% "Intel Pentium Pro (Unknown model) (1733 MHz)",1303,0.25% "Intel Pentium Pro (Unknown model) (1395 MHz)",1268,0.24% "Intel Pentium Pro (Unknown model) (1666 MHz)",1264,0.24% "PowerPC 7450 (1666 MHz)",1251,0.24% "Intel Pentium 4 (Unknown model) (3014 MHz)",1242,0.24% "Intel Pentium Pro (Unknown model) (1695 MHz)",1240,0.24% "Intel Pentium Pro (Unknown model) (1694 MHz)",1221,0.24% "AMD (Unknown model) (994 MHz)",1211,0.23% "Intel Pentium 4 Northwood (1993 MHz)",1204,0.23% "Intel Pentium 4 (Unknown model) (2659 MHz)",1173,0.23% "Intel Pentium 4 Northwood (2405 MHz)",1165,0.22% "Dual PowerPC 970 (2000 MHz)",1141,0.22% "Intel Pentium Pro (Unknown model) (2394 MHz)",1140,0.22% "Intel Pentium 4 Northwood (2393 MHz)",1138,0.22% "Intel Pentium 4 Northwood (2600 MHz)",1116,0.22% "AMD K7 (Unknown model) (2000 MHz)",1112,0.21% "AMD (Unknown model) (2002 MHz)",1100,0.21% "AMD (Unknown model) (1794 MHz)",1098,0.21% "AMD (Unknown model) (2410 MHz)",1092,0.21% "Intel Pentium 4 (Unknown model) (2933 MHz)",1083,0.21% "AMD (Unknown model) (2199 MHz)",1067,0.21% "Intel Pentium 4 (Unknown model) (3199 MHz)",1063,0.20% "Intel Pentium Pro (Unknown model) (2161 MHz)",1056,0.20% "AMD (Unknown model) (800 MHz)",1050,0.20% "Intel Pentium Pro (Unknown model) (1495 MHz)",1047,0.20% "Intel Pentium 4 (Unknown model) (2998 MHz)",1039,0.20% "Intel Pentium Pro (Unknown model) (1398 MHz)",1038,0.20% "Intel Pentium Pro (Unknown model) (1196 MHz)",1032,0.20% "Intel Pentium 4 Northwood (2792 MHz)",1001,0.19% "AMD (Unknown model) (1795 MHz)",998,0.19% "Intel Pentium 4 (Unknown model) (3006 MHz)",973,0.19% "Intel Pentium 4 (Unknown model) (2526 MHz)",973,0.19% "Intel Pentium Pro (Unknown model) (2127 MHz)",960,0.18% "PowerPC 7450 (1250 MHz)",960,0.18% "PowerPC 970 (1800 MHz)",914,0.18% "Intel Pentium 4 Northwood (2666 MHz)",905,0.17% "Intel Pentium 4 (Unknown model) (3211 MHz)",893,0.17% "Intel Pentium Pro (Unknown model) (2000 MHz)",876,0.17% "Intel Pentium Pro (Unknown model) (1664 MHz)",865,0.17% "Intel Pentium 4 Northwood (2806 MHz)",861,0.17% "Intel Pentium 4 Northwood (3000 MHz)",852,0.16% "PowerPC 7450 (1000 MHz)",852,0.16% "Intel Pentium 4 Northwood (2660 MHz)",850,0.16% "Intel Pentium 4 (Unknown model) (2926 MHz)",842,0.16% "Intel Pentium 4 Northwood (2659 MHz)",841,0.16% "Intel Pentium 4 Northwood (2799 MHz)",827,0.16% "AMD (Unknown model) (1004 MHz)",825,0.16% "Intel Pentium 4 Northwood (2672 MHz)",823,0.16% "Intel Pentium Pro (Unknown model) (1830 MHz)",819,0.16% "AMD (Unknown model) (1802 MHz)",807,0.16% "Intel Pentium 4 (Unknown model) (2932 MHz)",797,0.15% "Intel Pentium 4 Northwood (3192 MHz)",790,0.15% "Intel Pentium Pro (Unknown model) (1498 MHz)",788,0.15% "Intel Pentium Pro (Unknown model) (1064 MHz)",784,0.15% "Intel Pentium 4 (Unknown model) (3065 MHz)",784,0.15% "Intel Pentium 4 (Unknown model) (3058 MHz)",773,0.15% "Intel Pentium Pro (Unknown model) (2399 MHz)",764,0.15% "PowerPC 970 (2000 MHz)",753,0.15% "Intel Pentium 4 (Unknown model) (2925 MHz)",752,0.14% "AMD (Unknown model) (798 MHz)",752,0.14% "AMD (Unknown model) (1995 MHz)",749,0.14% "Intel Pentium Pro (Unknown model) (1698 MHz)",743,0.14% "AMD (Unknown model) (1603 MHz)",743,0.14% "AMD (Unknown model) (1591 MHz)",721,0.14% "Intel Pentium 4 (Unknown model) (2393 MHz)",718,0.14% "Intel Pentium Pro (Unknown model) (1795 MHz)",711,0.14% "AMD K7 (Unknown model) (1991 MHz)",707,0.14% "Intel Pentium Pro (Unknown model) (1063 MHz)",706,0.14% "AMD K7 (Unknown model) (1996 MHz)",703,0.14% "AMD (Unknown model) (795 MHz)",684,0.13% "AMD (Unknown model) (2202 MHz)",682,0.13% "Intel Pentium Pro (Unknown model) (1330 MHz)",680,0.13% "AMD K7 (Unknown model) (1800 MHz)",676,0.13% "Intel Pentium 4 Northwood (2798 MHz)",661,0.13% "Intel Pentium Pro (Unknown model) (1296 MHz)",650,0.13% "AMD K7 (Unknown model) (1830 MHz)",648,0.12% "Intel Pentium 4 Northwood (2605 MHz)",645,0.12% "AMD K7 (Unknown model) (2088 MHz)",643,0.12% "4 x i386 (Unknown) (2660 MHz)",638,0.12% "Intel Pentium 4 (Unknown model) (3412 MHz)",616,0.12% "AMD (Unknown model) (2400 MHz)",614,0.12% "Intel Pentium Pro (Unknown model) (1864 MHz)",607,0.12% "AMD K7 (Unknown model) (2191 MHz)",600,0.12% "Intel Pentium 4 Northwood (1999 MHz)",594,0.11% "Intel Pentium 4 Northwood (2411 MHz)",594,0.11% "AMD (Unknown model) (2209 MHz)",593,0.11% "Intel Pentium 4 (Unknown model) (3201 MHz)",591,0.11% "Intel Pentium 4 (Unknown model) (3191 MHz)",583,0.11% "Intel Pentium Pro (Unknown model) (1833 MHz)",578,0.11% "Intel Pentium Pro (Unknown model) (1329 MHz)",575,0.11% "Intel Pentium Pro (Unknown model) (1466 MHz)",573,0.11% "Intel Pentium 4 (Unknown model) (3215 MHz)",573,0.11% "Intel Pentium 4 (Unknown model) (2527 MHz)",573,0.11% "Intel Pentium 4 Northwood (1992 MHz)",569,0.11% "AMD K7 (Unknown model) (2083 MHz)",566,0.11% "Intel Pentium 4 Northwood (3200 MHz)",564,0.11% "Intel Pentium 4 (Unknown model) (2994 MHz)",563,0.11% "AMD (Unknown model) (2611 MHz)",563,0.11% "Intel Pentium 4 Willamette (1594 MHz)",561,0.11% "AMD K7 (Unknown model) (2162 MHz)",561,0.11% "Intel Pentium Pro (Unknown model) (2666 MHz)",560,0.11% "AMD K7 (Unknown model) (2200 MHz)",559,0.11% "AMD K7 (Unknown model) (1913 MHz)",557,0.11% "AMD K7 (Unknown model) (1833 MHz)",553,0.11% "Intel Pentium 4 Northwood (2391 MHz)",547,0.11% "Intel Pentium Pro (Unknown model) (1197 MHz)",546,0.11% "Intel Pentium Pro (Unknown model) (1829 MHz)",540,0.10% "Intel Pentium 4 (Unknown model) (3591 MHz)",536,0.10% "AMD (Unknown model) (2605 MHz)",536,0.10% "AMD K7 (Unknown model) (1829 MHz)",530,0.10% "Intel Pentium Pro (Unknown model) (1500 MHz)",530,0.10% "Intel Pentium Pro (Unknown model) (2163 MHz)",526,0.10% "Intel Pentium 4 Northwood (2386 MHz)",526,0.10% "Intel Pentium Pro (Unknown model) (2401 MHz)",523,0.10% "AMD K7 (Unknown model) (2004 MHz)",523,0.10% "Intel Pentium 4 Willamette (1794 MHz)",519,0.10% "Intel Pentium 4 Northwood (2998 MHz)",518,0.10% "AMD K7 (Unknown model) (2171 MHz)",503,0.10% "AMD K7 (Unknown model) (1499 MHz)",500,0.10% "Intel Pentium 4 (Unknown model) (2394 MHz)",499,0.10% "Intel Pentium 4 Northwood (2390 MHz)",498,0.10% "AMD (Unknown model) (2399 MHz)",496,0.10% "Intel Pentium 4 Northwood (2790 MHz)",486,0.09% "Intel Pentium Pro (Unknown model) (600 MHz)",485,0.09% "Intel Pentium Pro (Unknown model) (1400 MHz)",483,0.09% "Intel Pentium 4 Northwood Xeon (1196 MHz)",481,0.09% "Intel Pentium 4 (Unknown model) (2794 MHz)",480,0.09% "PowerPC 7450 (1420 MHz)",479,0.09% "Intel Pentium Pro (Unknown model) (2404 MHz)",479,0.09% "Intel Pentium 4 Northwood (2000 MHz)",478,0.09% "Intel Pentium 4 Northwood (3006 MHz)",476,0.09% "Intel Pentium Pro (Unknown model) (1462 MHz)",475,0.09% "Intel Pentium 4 (Unknown model) (3198 MHz)",475,0.09% "AMD (Unknown model) (2008 MHz)",474,0.09% "Intel Pentium 4 Northwood (2524 MHz)",471,0.09% "AMD (Unknown model) (2387 MHz)",469,0.09% "Intel Pentium 4 Northwood (2657 MHz)",468,0.09% "AMD K7 (Unknown model) (2205 MHz)",466,0.09% "AMD K7 (Unknown model) (1837 MHz)",465,0.09% "Intel Pentium 4 (Unknown model) (2806 MHz)",454,0.09% "Intel Pentium Pro (Unknown model) (1599 MHz)",452,0.09% "Intel Pentium 4 (Unknown model) (2533 MHz)",451,0.09% "AMD K7 (Unknown model) (2166 MHz)",451,0.09% "Dual PowerPC 970 (1800 MHz)",442,0.09% "Dual i386 (Unknown) (1670 MHz)",442,0.09% "AMD K7 (Unknown model) (1916 MHz)",441,0.08% "Intel Pentium 4 (Unknown model) (2400 MHz)",438,0.08% "AMD K7 (Unknown model) (2204 MHz)",435,0.08% "AMD (Unknown model) (1804 MHz)",430,0.08% "PowerPC 970 (2100 MHz)",430,0.08% "Intel Pentium Pro (Unknown model) (1463 MHz)",427,0.08% "Intel Pentium 4 (Unknown model) (3399 MHz)",420,0.08% "AMD Athlon MP/Mobile Athlon (Palomino core) (1666 MHz)",418,0.08% "Intel Pentium 4 Willamette (1694 MHz)",418,0.08% "Intel Pentium Pro (Unknown model) (2131 MHz)",418,0.08% "Intel Pentium 4 (Unknown model) (2813 MHz)",413,0.08% "PowerPC 7450 (1200 MHz)",407,0.08% "Intel Pentium 4 (Unknown model) (2266 MHz)",406,0.08% "Intel Pentium Pro (Unknown model) (1700 MHz)",405,0.08% "Intel Pentium Pro (Unknown model) (1794 MHz)",404,0.08% "Intel Pentium 4 (Unknown model) (3060 MHz)",399,0.08% "PowerPC 7450 (1416 MHz)",395,0.08% "Intel Pentium 4 (Unknown model) (3401 MHz)",394,0.08% "Intel Pentium 4 Northwood (2523 MHz)",393,0.08% "Intel Pentium Pro (Unknown model) (1799 MHz)",393,0.08% "Intel Pentium Pro (Unknown model) (1800 MHz)",392,0.08% "Intel Pentium 4 (Unknown model) (2993 MHz)",390,0.08% "Intel Pentium Pro (Unknown model) (2393 MHz)",389,0.07% "Intel Pentium 4 (Unknown model) (3333 MHz)",388,0.07% "AMD Athlon MP/Mobile Athlon (Palomino core) (1533 MHz)",388,0.07% "Intel Pentium 4 Northwood (2533 MHz)",386,0.07% "PowerPC 7450 (800 MHz)",380,0.07% "Intel Pentium 4 (Unknown model) (2133 MHz)",379,0.07% "Intel Pentium Pro (Unknown model) (800 MHz)",378,0.07% "Intel Pentium Pro (Unknown model) (996 MHz)",377,0.07% "Intel Pentium 4 Northwood (3066 MHz)",377,0.07% "Intel Pentium 4 Northwood (1794 MHz)",376,0.07% "Intel Pentium 4 Northwood Xeon (1794 MHz)",375,0.07% "AMD K7 (Unknown model) (2100 MHz)",374,0.07% "Intel Pentium Pro (Unknown model) (2135 MHz)",374,0.07% "Intel Pentium Pro (Unknown model) (2327 MHz)",372,0.07% "Intel Pentium Pro (Unknown model) (2660 MHz)",371,0.07% "Intel Pentium Pro (Unknown model) (1798 MHz)",370,0.07% "Intel Pentium 4 Northwood (2813 MHz)",369,0.07% "AMD K7 (Unknown model) (1799 MHz)",367,0.07% "Intel Pentium 4 (Unknown model) (3207 MHz)",366,0.07% "Intel Pentium 4 Northwood (2192 MHz)",365,0.07% "AMD (Unknown model) (801 MHz)",364,0.07% "AMD K7 (Unknown model) (2158 MHz)",364,0.07% "Intel Pentium 4 (Unknown model) (2798 MHz)",363,0.07% "AMD (Unknown model) (1005 MHz)",362,0.07% "AMD K7 (Unknown model) (1998 MHz)",356,0.07% "AMD K7 (Unknown model) (1921 MHz)",354,0.07% "Intel Pentium 4 (Unknown model) (3013 MHz)",353,0.07% "Intel Pentium Pro (Unknown model) (1298 MHz)",344,0.07% "AMD (Unknown model) (799 MHz)",343,0.07% "Dual PowerPC 970 (2300 MHz)",343,0.07% "AMD (Unknown model) (2193 MHz)",338,0.07% "Intel Pentium 4 (Unknown model) (2665 MHz)",336,0.06% "Intel Pentium 4 Northwood (3059 MHz)",331,0.06% "AMD K7 (Unknown model) (2075 MHz)",329,0.06% "Intel Pentium 4 Northwood (2423 MHz)",327,0.06% "Intel Pentium Pro (Unknown model) (2006 MHz)",325,0.06% "Intel Pentium 4 Northwood (2591 MHz)",324,0.06% "Intel Pentium 4 (Unknown model) (2661 MHz)",324,0.06% "AMD (Unknown model) (2216 MHz)",322,0.06% "PowerPC 970 (1900 MHz)",319,0.06% "Intel Pentium Pro (Unknown model) (1699 MHz)",317,0.06% "Intel Pentium Pro (Unknown model) (997 MHz)",316,0.06% "AMD K7 (Unknown model) (1994 MHz)",313,0.06% "Intel Pentium Pro (Unknown model) (2397 MHz)",311,0.06% "Intel Pentium 4 Northwood (2598 MHz)",301,0.06% "Intel Pentium 4 Northwood (2599 MHz)",300,0.06% "Intel Pentium 4 Northwood (2398 MHz)",297,0.06% "Intel Pentium Pro (Unknown model) (1867 MHz)",294,0.06% "Intel Pentium 4 Northwood Xeon (1993 MHz)",294,0.06% "Intel Pentium 4 Northwood (2266 MHz)",293,0.06% "Intel Pentium Pro (Unknown model) (1499 MHz)",292,0.06% "Intel Pentium 4 Northwood (2539 MHz)",291,0.06% "AMD (Unknown model) (2613 MHz)",291,0.06% "Intel Pentium Pro (Unknown model) (1869 MHz)",290,0.06% "Intel Pentium Pro (Unknown model) (1399 MHz)",290,0.06% "AMD K7 (Unknown model) (1659 MHz)",289,0.06% "Intel Pentium 4 (Unknown model) (3416 MHz)",288,0.06% "AMD (Unknown model) (2194 MHz)",284,0.05% "AMD (Unknown model) (1602 MHz)",284,0.05% "Intel Pentium 4 Northwood (2519 MHz)",283,0.05% "Intel Pentium 4 Northwood (2019 MHz)",282,0.05% "Intel Pentium Pro (Unknown model) (1868 MHz)",280,0.05% "Intel Pentium 4 Northwood (2532 MHz)",277,0.05% "Dual PowerPC 970 (2500 MHz)",277,0.05% "AMD (Unknown model) (1000 MHz)",273,0.05% "4 x PowerPC 970 (2500 MHz)",272,0.05% "Intel Pentium 4 Northwood (2679 MHz)",270,0.05% "Intel Pentium 4 Northwood (1994 MHz)",269,0.05% "Intel Pentium 4 (Unknown model) (2672 MHz)",268,0.05% "Intel Pentium III (0.18 micron process) with internal L2 cache (996 MHz)",268,0.05% "AMD (Unknown model) (2612 MHz)",267,0.05% "Intel Pentium Pro (Unknown model) (1672 MHz)",267,0.05% "Intel Pentium 4 (Unknown model) (3001 MHz)",266,0.05% "AMD Athlon MP/Mobile Athlon (Palomino core) (1466 MHz)",264,0.05% "Intel Pentium 4 Northwood (2193 MHz)",263,0.05% "AMD (Unknown model) (1608 MHz)",263,0.05% "AMD K7 (Unknown model) (1670 MHz)",262,0.05% "Intel Pentium 4 Northwood (2004 MHz)",257,0.05% "Intel Pentium 4 Willamette (1800 MHz)",256,0.05% "Intel Pentium 4 (Unknown model) (3056 MHz)",253,0.05% "Intel Pentium 4 Northwood (3391 MHz)",251,0.05% "AMD (Unknown model) (997 MHz)",249,0.05% "Dual PowerPC 7450 (1250 MHz)",247,0.05% "AMD K7 (Unknown model) (1250 MHz)",245,0.05% "AMD K7 (Unknown model) (1500 MHz)",245,0.05% "Intel Pentium Pro (Unknown model) (1198 MHz)",245,0.05% "Intel Pentium 4 Northwood (3014 MHz)",244,0.05% "PowerPC 970 (1600 MHz)",244,0.05% "Intel Pentium 4 Northwood (1991 MHz)",243,0.05% "Intel Pentium Pro (Unknown model) (1295 MHz)",243,0.05% "Intel Pentium Pro (Unknown model) (799 MHz)",237,0.05% "Intel Pentium 4 (Unknown model) (2809 MHz)",236,0.05% "Intel Pentium 4 (Unknown model) (2399 MHz)",233,0.04% "Intel Pentium Pro (Unknown model) (1993 MHz)",232,0.04% "Intel Pentium Pro (Unknown model) (999 MHz)",232,0.04% "AMD K7 (Unknown model) (1665 MHz)",230,0.04% "Intel Pentium 4 Northwood (2017 MHz)",230,0.04% "Intel Pentium 4 (Unknown model) (2663 MHz)",229,0.04% "Intel Pentium Pro (Unknown model) (2137 MHz)",228,0.04% "AMD (Unknown model) (2403 MHz)",227,0.04% "AMD (Unknown model) (2015 MHz)",226,0.04% "AMD (Unknown model) (1908 MHz)",222,0.04% "Intel Pentium Pro (Unknown model) (2395 MHz)",221,0.04% "Dual PowerPC 970 (2700 MHz)",221,0.04% "AMD (Unknown model) (2586 MHz)",220,0.04% "Intel Pentium 4 Willamette (A-Step) (1495 MHz)",220,0.04% "AMD (Unknown model) (2812 MHz)",219,0.04% "AMD K7 (Unknown model) (1836 MHz)",219,0.04% "AMD K7 (Unknown model) (1533 MHz)",217,0.04% "Intel Pentium 4 (Unknown model) (2990 MHz)",216,0.04% "AMD K7 (Unknown model) (1583 MHz)",216,0.04% "AMD K7 (Unknown model) (1798 MHz)",216,0.04% "Intel Pentium 4 Northwood (3198 MHz)",214,0.04% "Intel Pentium 4 (Unknown model) (2923 MHz)",210,0.04% "AMD K7 (Unknown model) (1804 MHz)",209,0.04% "AMD (Unknown model) (1796 MHz)",209,0.04% "AMD K7 (Unknown model) (1662 MHz)",208,0.04% "AMD (Unknown model) (2205 MHz)",204,0.04% "AMD K7 (Unknown model) (1243 MHz)",201,0.04% "Intel Pentium 4 (Unknown model) (3064 MHz)",201,0.04% "Intel Pentium 4 (Unknown model) (2532 MHz)",200,0.04% "Intel Pentium 4 Northwood Xeon (1694 MHz)",200,0.04% "AMD K7 (Unknown model) (1792 MHz)",199,0.04% "Intel Pentium 4 (Unknown model) (2991 MHz)",198,0.04% "Intel Pentium 4 Northwood Xeon (3056 MHz)",198,0.04% "Intel Pentium 4 Northwood Xeon (1594 MHz)",198,0.04% "Dual PowerPC 7450 (1000 MHz)",195,0.04% "Intel Pentium 4 Northwood (2700 MHz)",195,0.04% "AMD K7 (Unknown model) (1797 MHz)",195,0.04% "AMD K7 (Unknown model) (1094 MHz)",195,0.04% "AMD K7 (Unknown model) (1466 MHz)",193,0.04% "AMD (Unknown model) (2014 MHz)",193,0.04% "Intel Pentium Pro (Unknown model) (1863 MHz)",191,0.04% "Intel Pentium 4 (Unknown model) (2810 MHz)",191,0.04% "Dual i386 (Unknown) (2400 MHz)",191,0.04% "AMD K7 (Unknown model) (1795 MHz)",189,0.04% "Intel Pentium 4 Northwood (2788 MHz)",188,0.04% "Intel Pentium 4 (Unknown model) (3007 MHz)",187,0.04% "Intel Pentium 4 Northwood (1799 MHz)",186,0.04% "AMD K7 (Unknown model) (1909 MHz)",186,0.04% "AMD K7 (Unknown model) (1794 MHz)",185,0.04% "AMD K7 (Unknown model) (1600 MHz)",184,0.04% "Intel Pentium 4 Willamette (1700 MHz)",184,0.04% "Intel Pentium 4 Northwood (1800 MHz)",184,0.04% "Intel Pentium 4 (Unknown model) (2796 MHz)",183,0.04% "AMD K7 (Unknown model) (2091 MHz)",183,0.04% "Intel Pentium 4 (Unknown model) (3194 MHz)",182,0.04% "Intel Pentium 4 Willamette Xeon (1694 MHz)",181,0.03% "AMD (Unknown model) (2393 MHz)",180,0.03% "AMD K7 (Unknown model) (1832 MHz)",179,0.03% "Intel Pentium 4 Northwood (2658 MHz)",178,0.03% "Intel Pentium 4 (Unknown model) (2797 MHz)",178,0.03% "Intel Pentium 4 Northwood (2791 MHz)",177,0.03% "Intel Pentium Pro (Unknown model) (1492 MHz)",177,0.03% "Intel Pentium 4 (Unknown model) (3600 MHz)",177,0.03% "AMD K7 (Unknown model) (2002 MHz)",176,0.03% "AMD K7 (Unknown model) (1664 MHz)",175,0.03% "AMD K7 (Unknown model) (1990 MHz)",175,0.03% "PowerPC 7450 (1066 MHz)",175,0.03% "Intel Pentium Pro (Unknown model) (1592 MHz)",174,0.03% "AMD (Unknown model) (2043 MHz)",173,0.03% "Intel Pentium 4 (Unknown model) (3067 MHz)",171,0.03% "AMD K7 (Unknown model) (1749 MHz)",169,0.03% "4 x i386 (Unknown) (2990 MHz)",166,0.03% "Intel Pentium 4 Northwood (2545 MHz)",166,0.03% "Intel Pentium 4 Northwood (2655 MHz)",165,0.03% "AMD (Unknown model) (2310 MHz)",165,0.03% "AMD K7 (Unknown model) (1825 MHz)",165,0.03% "Intel Pentium 4 Northwood Xeon (2392 MHz)",163,0.03% "Intel Pentium 4 (Unknown model) (3073 MHz)",163,0.03% "Intel Pentium 4 Willamette (1600 MHz)",163,0.03% "Intel Pentium 4 (Unknown model) (2791 MHz)",162,0.03% "AMD K7 (Unknown model) (2009 MHz)",161,0.03% "Intel Pentium Pro (Unknown model) (1998 MHz)",161,0.03% "AMD K7 (Unknown model) (2104 MHz)",161,0.03% "Intel Pentium 4 Northwood (2612 MHz)",159,0.03% "Intel Pentium 4 (Unknown model) (2667 MHz)",158,0.03% "Intel Pentium 4 (Unknown model) (3214 MHz)",158,0.03% "Intel Pentium 4 Willamette Xeon (1699 MHz)",157,0.03% "AMD K7 (Unknown model) (2074 MHz)",157,0.03% "Intel Pentium 4 (Unknown model) (2411 MHz)",157,0.03% "Intel Pentium Pro (Unknown model) (1097 MHz)",156,0.03% "Intel Pentium 4 (Unknown model) (2679 MHz)",156,0.03% "Intel Pentium 4 Willamette (1614 MHz)",155,0.03% "Intel Pentium 4 Willamette (1793 MHz)",154,0.03% "Intel Pentium 4 (Unknown model) (2812 MHz)",154,0.03% "AMD K7 (Unknown model) (1992 MHz)",153,0.03% "AMD K7 (Unknown model) (1200 MHz)",152,0.03% "Intel Pentium 4 Northwood Xeon (1994 MHz)",151,0.03% "Intel Pentium 4 Northwood (2491 MHz)",150,0.03% "Intel Pentium 4 Northwood (2260 MHz)",149,0.03% "Intel Pentium 4 Northwood (2526 MHz)",149,0.03% "Intel Pentium 4 Northwood (3073 MHz)",149,0.03% "AMD K7 (Unknown model) (2131 MHz)",147,0.03% "Intel Pentium Pro (Unknown model) (1860 MHz)",146,0.03% "Intel Pentium Pro (Unknown model) (1300 MHz)",146,0.03% "Intel Pentium Pro (Unknown model) (1691 MHz)",145,0.03% "AMD K7 (Unknown model) (2086 MHz)",145,0.03% "Intel Pentium 4 Northwood (3215 MHz)",142,0.03% "AMD K7 (Unknown model) (2082 MHz)",142,0.03% "AMD K7 (Unknown model) (1920 MHz)",141,0.03% "Intel Pentium Pro (Unknown model) (2129 MHz)",141,0.03% "Intel Pentium Pro (Unknown model) (1597 MHz)",141,0.03% "Intel Pentium 4 (Unknown model) (3057 MHz)",140,0.03% "AMD K7 (Unknown model) (1826 MHz)",140,0.03% "Intel Pentium 4 Willamette Xeon (1700 MHz)",140,0.03% "Intel Pentium 4 (Unknown model) (2127 MHz)",140,0.03% "Intel Pentium 4 Willamette (A-Step) (1694 MHz)",139,0.03% "AMD K7 (Unknown model) (1661 MHz)",138,0.03% "AMD K7 (Unknown model) (1493 MHz)",137,0.03% "Intel Pentium 4 (Unknown model) (3062 MHz)",137,0.03% "AMD (Unknown model) (2511 MHz)",136,0.03% "AMD K7 (Unknown model) (2157 MHz)",136,0.03% "Intel Pentium III (0.18 micron process) with internal L2 cache (997 MHz)",136,0.03% "Intel Pentium Pro (Unknown model) (1200 MHz)",135,0.03% "Intel Pentium III (0.18 micron process) with internal L2 cache (797 MHz)",135,0.03% "Intel Pentium 4 (Unknown model) (2790 MHz)",135,0.03% "AMD (Unknown model) (2420 MHz)",134,0.03% "AMD K7 (Unknown model) (1492 MHz)",134,0.03% "Intel Pentium 4 Northwood (1816 MHz)",134,0.03% "AMD K7 (Unknown model) (2165 MHz)",134,0.03% "Intel Pentium 4 Willamette (1495 MHz)",134,0.03% "Intel Pentium Pro (Unknown model) (1696 MHz)",133,0.03% "PowerPC 7450 (700 MHz)",132,0.03% "Intel Pentium 4 Willamette Xeon (1693 MHz)",132,0.03% "Intel Pentium 4 Northwood (2597 MHz)",132,0.03% "Intel Pentium III (0.18 micron process) with internal L2 cache (930 MHz)",132,0.03% "Intel Pentium 4 (Unknown model) (2405 MHz)",132,0.03% "Intel Pentium 4 (Unknown model) (2997 MHz)",131,0.03% "AMD K7 (Unknown model) (1350 MHz)",131,0.03% "Intel Pentium 4 (Unknown model) (2996 MHz)",130,0.03% "Intel Pentium Pro (Unknown model) (595 MHz)",130,0.03% "Intel Pentium 4 Northwood Xeon (2192 MHz)",130,0.03% "AMD K7 (Unknown model) (2164 MHz)",129,0.02% "AMD K7 (Unknown model) (2133 MHz)",129,0.02% "PowerPC 7450 (933 MHz)",128,0.02% "Intel Pentium 4 Northwood (2489 MHz)",128,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1529 MHz)",128,0.02% "Intel Pentium 4 Northwood Xeon (2797 MHz)",127,0.02% "Intel Pentium 4 Northwood Xeon (2793 MHz)",127,0.02% "AMD K7 (Unknown model) (1733 MHz)",127,0.02% "AMD K7 (Unknown model) (2099 MHz)",127,0.02% "Intel Pentium Pro (Unknown model) (1000 MHz)",127,0.02% "Intel Pentium Pro (Unknown model) (2330 MHz)",126,0.02% "Intel Pentium 4 Willamette Xeon (1794 MHz)",125,0.02% "PowerPC 7450 (867 MHz)",125,0.02% "Intel Pentium 4 Willamette (1693 MHz)",124,0.02% "Intel Pentium 4 (Unknown model) (3326 MHz)",124,0.02% "AMD (Unknown model) (1399 MHz)",124,0.02% "Dual i386 (Unknown) (2200 MHz)",123,0.02% "Intel Pentium 4 (Unknown model) (2940 MHz)",123,0.02% "Intel Pentium 4 Willamette (A-Step) (1296 MHz)",123,0.02% "Intel Pentium 4 Northwood (2784 MHz)",123,0.02% "AMD K7 (Unknown model) (1663 MHz)",120,0.02% "Intel Pentium 4 Northwood (2651 MHz)",119,0.02% "Intel Pentium 4 (Unknown model) (3415 MHz)",119,0.02% "Intel Pentium 4 Northwood (1804 MHz)",119,0.02% "AMD (Unknown model) (2247 MHz)",118,0.02% "Intel Pentium Pro (Unknown model) (597 MHz)",118,0.02% "Intel Pentium 4 (Unknown model) (3193 MHz)",118,0.02% "AMD K7 (Unknown model) (1150 MHz)",118,0.02% "Intel Pentium 4 Northwood (2589 MHz)",117,0.02% "Intel Pentium 4 Northwood (2200 MHz)",117,0.02% "Intel Pentium Pro (Unknown model) (2261 MHz)",116,0.02% "AMD (Unknown model) (1813 MHz)",116,0.02% "AMD K7 (Unknown model) (1100 MHz)",115,0.02% "AMD K7 (Unknown model) (1919 MHz)",115,0.02% "AMD (Unknown model) (2600 MHz)",115,0.02% "Intel Pentium Pro (Unknown model) (1394 MHz)",114,0.02% "AMD (Unknown model) (1801 MHz)",114,0.02% "Intel Pentium 4 Willamette (1816 MHz)",112,0.02% "Intel Pentium Pro (Unknown model) (2126 MHz)",112,0.02% "Intel Pentium 4 Northwood (1793 MHz)",111,0.02% "Intel Pentium Pro (Unknown model) (1808 MHz)",111,0.02% "Intel Pentium 4 (Unknown model) (3612 MHz)",111,0.02% "Intel Pentium 4 Northwood Xeon (2194 MHz)",111,0.02% "Intel Pentium 4 (Unknown model) (2676 MHz)",111,0.02% "AMD K7 (Unknown model) (2071 MHz)",111,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1670 MHz)",110,0.02% "AMD K7 (Unknown model) (1672 MHz)",110,0.02% "AMD K7 (Unknown model) (1791 MHz)",110,0.02% "Intel Pentium 4 Northwood (2396 MHz)",109,0.02% "Intel Pentium 4 Northwood (3207 MHz)",109,0.02% "AMD K7 (Unknown model) (2081 MHz)",108,0.02% "Intel Pentium 4 Northwood (2590 MHz)",108,0.02% "Intel Pentium 4 Willamette (1595 MHz)",107,0.02% "Intel Pentium 4 Northwood (1817 MHz)",107,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1733 MHz)",106,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1399 MHz)",106,0.02% "Intel Pentium 4 Northwood (2191 MHz)",106,0.02% "AMD (Unknown model) (2814 MHz)",106,0.02% "Intel Pentium 4 Northwood (1792 MHz)",106,0.02% "Intel Pentium Pro (Unknown model) (1661 MHz)",105,0.02% "Intel Pentium 4 Northwood (2410 MHz)",105,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1665 MHz)",105,0.02% "Intel Pentium 4 Northwood (2397 MHz)",105,0.02% "Intel Pentium Pro (Unknown model) (1389 MHz)",104,0.02% "Intel Pentium 4 Willamette (A-Step) (1395 MHz)",104,0.02% "AMD (Unknown model) (2418 MHz)",104,0.02% "Intel Pentium 4 Northwood (3049 MHz)",104,0.02% "Intel Pentium 4 (Unknown model) (3396 MHz)",104,0.02% "Intel Pentium 4 Northwood (2999 MHz)",104,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1400 MHz)",104,0.02% "AMD K7 (Unknown model) (1658 MHz)",103,0.02% "AMD (Unknown model) (1838 MHz)",103,0.02% "AMD Mobile Duron (Morgan core) (1200 MHz)",103,0.02% "Intel Pentium 4 Willamette (1699 MHz)",103,0.02% "AMD K7 (Unknown model) (1822 MHz)",102,0.02% "AMD K7 (Unknown model) (1102 MHz)",102,0.02% "Intel Pentium 4 (Unknown model) (3458 MHz)",101,0.02% "Intel Pentium Pro (Unknown model) (1796 MHz)",101,0.02% "AMD (Unknown model) (3013 MHz)",101,0.02% "Intel Pentium 4 (Unknown model) (3189 MHz)",100,0.02% "Intel Pentium 4 Willamette (1715 MHz)",100,0.02% "PowerPC 7450 (667 MHz)",99,0.02% "i386 (Unknown) (1500 MHz)",99,0.02% "Intel Pentium Pro (Unknown model) (2659 MHz)",99,0.02% "AMD K7 (Unknown model) (1679 MHz)",99,0.02% "Intel Pentium 4 (Unknown model) (3042 MHz)",99,0.02% "Intel Pentium 4 Northwood (2699 MHz)",99,0.02% "AMD K7 (Unknown model) (2087 MHz)",98,0.02% "Intel Pentium 4 Northwood (2625 MHz)",97,0.02% "Intel Pentium 4 Northwood (2421 MHz)",97,0.02% "Intel Pentium 4 Northwood (2827 MHz)",97,0.02% "Intel Pentium 4 Northwood (2261 MHz)",97,0.02% "Intel Pentium 4 Northwood (2525 MHz)",97,0.02% "Intel Pentium Pro (Unknown model) (1493 MHz)",96,0.02% "AMD K7 (Unknown model) (1905 MHz)",96,0.02% "AMD K7 (Unknown model) (1908 MHz)",95,0.02% "Intel Pentium 4 (Unknown model) (2260 MHz)",95,0.02% "Intel Pentium 4 Northwood Xeon (1998 MHz)",95,0.02% "Intel Pentium 4 (Unknown model) (2412 MHz)",95,0.02% "AMD (Unknown model) (2266 MHz)",94,0.02% "Intel Pentium Pro (Unknown model) (1333 MHz)",94,0.02% "Intel Pentium 4 (Unknown model) (3009 MHz)",94,0.02% "Intel Pentium Pro (Unknown model) (1294 MHz)",94,0.02% "AMD (Unknown model) (2100 MHz)",93,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1244 MHz)",93,0.02% "AMD K7 (Unknown model) (1503 MHz)",93,0.02% "AMD K7 (Unknown model) (2199 MHz)",93,0.02% "Intel Pentium Pro (Unknown model) (1793 MHz)",93,0.02% "Intel Pentium 4 Northwood (2490 MHz)",93,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1526 MHz)",93,0.02% "Intel Pentium Pro (Unknown model) (1299 MHz)",92,0.02% "Intel Pentium 4 (Unknown model) (3790 MHz)",92,0.02% "Intel Pentium 4 Northwood (2199 MHz)",92,0.02% "Intel Pentium 4 Willamette (1993 MHz)",92,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1250 MHz)",92,0.02% "AMD (Unknown model) (1406 MHz)",92,0.02% "Intel Pentium 4 (Unknown model) (2795 MHz)",91,0.02% "Intel Pentium Pro (Unknown model) (1066 MHz)",91,0.02% "Intel Pentium 4 Northwood (2271 MHz)",91,0.02% "AMD K7 (Unknown model) (1000 MHz)",91,0.02% "Intel Pentium 4 (Unknown model) (3407 MHz)",91,0.02% "AMD K7 (Unknown model) (1660 MHz)",91,0.02% "Intel Pentium 4 (Unknown model) (2939 MHz)",91,0.02% "AMD K7 (Unknown model) (1667 MHz)",91,0.02% "Intel Pentium 4 (Unknown model) (2528 MHz)",90,0.02% "Intel Pentium 4 Northwood Xeon (1595 MHz)",90,0.02% "Intel Pentium 4 (Unknown model) (3392 MHz)",90,0.02% "Intel Pentium Pro (Unknown model) (1731 MHz)",89,0.02% "Intel Pentium Pro (Unknown model) (1839 MHz)",89,0.02% "Intel Pentium Pro (Unknown model) (2933 MHz)",89,0.02% "Intel Pentium Pro (Unknown model) (1999 MHz)",89,0.02% "Intel Pentium 4 Northwood (3081 MHz)",88,0.02% "Intel Pentium 4 Northwood (2412 MHz)",88,0.02% "Intel Pentium 4 Northwood (2395 MHz)",88,0.02% "AMD K7 (Unknown model) (2005 MHz)",88,0.02% "AMD K7 (Unknown model) (2194 MHz)",87,0.02% "AMD K7 (Unknown model) (1462 MHz)",87,0.02% "AMD K7 (Unknown model) (1532 MHz)",87,0.02% "Intel Pentium 4 Northwood (2691 MHz)",87,0.02% "AMD (Unknown model) (1903 MHz)",87,0.02% "Intel Pentium Pro (Unknown model) (1593 MHz)",86,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1150 MHz)",86,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1662 MHz)",86,0.02% "Intel Pentium 4 Northwood (3400 MHz)",86,0.02% "Intel Pentium 4 (Unknown model) (3393 MHz)",86,0.02% "Intel Pentium 4 (Unknown model) (2814 MHz)",86,0.02% "Intel Pentium 4 (Unknown model) (3325 MHz)",86,0.02% "Intel Pentium Pro (Unknown model) (2402 MHz)",85,0.02% "Intel Pentium 4 Northwood (3064 MHz)",85,0.02% "Intel Pentium 4 Willamette Xeon (1799 MHz)",85,0.02% "Intel Pentium 4 (Unknown model) (3466 MHz)",85,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1536 MHz)",85,0.02% "Intel Pentium 4 Northwood Xeon (1198 MHz)",85,0.02% "Intel Pentium Pro (Unknown model) (897 MHz)",85,0.02% "Intel Pentium 4 (Unknown model) (2278 MHz)",84,0.02% "Intel Pentium 4 (Unknown model) (2398 MHz)",84,0.02% "AMD K7 (Unknown model) (900 MHz)",84,0.02% "Intel Pentium 4 Northwood (2500 MHz)",84,0.02% "Intel Pentium Pro (Unknown model) (992 MHz)",84,0.02% "Intel Pentium 4 Northwood (1996 MHz)",83,0.02% "Intel Pentium Pro (Unknown model) (1393 MHz)",83,0.02% "AMD K7 (Unknown model) (1244 MHz)",83,0.02% "Intel Pentium 4 Northwood (2253 MHz)",83,0.02% "AMD (Unknown model) (2060 MHz)",83,0.02% "Intel Pentium 4 Northwood (3056 MHz)",83,0.02% "Intel Pentium 4 Northwood (2422 MHz)",82,0.02% "Intel Pentium 4 (Unknown model) (3077 MHz)",82,0.02% "PowerPC 7450 (733 MHz)",82,0.02% "AMD K7 (Unknown model) (1143 MHz)",82,0.02% "AMD K7 (Unknown model) (1252 MHz)",81,0.02% "Intel Pentium 4 Northwood (2267 MHz)",81,0.02% "AMD K7 (Unknown model) (2006 MHz)",81,0.02% "Intel Pentium 4 Northwood (2797 MHz)",81,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1145 MHz)",80,0.02% "Intel Pentium 4 Northwood (2402 MHz)",80,0.02% "AMD K7 (Unknown model) (1674 MHz)",80,0.02% "AMD (Unknown model) (2109 MHz)",80,0.02% "AMD K7 (Unknown model) (1536 MHz)",79,0.02% "AMD Athlon MP/Mobile Athlon (Palomino core) (1659 MHz)",79,0.02% "Intel Pentium 4 Northwood Xeon (1598 MHz)",79,0.02% "Intel Pentium 4 (Unknown model) (3081 MHz)",79,0.02% "Intel Pentium 4 (Unknown model) (2934 MHz)",79,0.02% "Intel Pentium Pro (Unknown model) (2392 MHz)",79,0.02% "Intel Pentium Pro (Unknown model) (2671 MHz)",79,0.02% "AMD K7 (Unknown model) (2169 MHz)",79,0.02% "Dual PowerPC 7450 (866 MHz)",79,0.02% "Intel Pentium 4 (Unknown model) (3389 MHz)",79,0.02% "AMD (Unknown model) (3015 MHz)",78,0.02% "AMD Athlon (Thunderbird core) (1000 MHz)",78,0.02% "Intel Pentium 4 (Unknown model) (3463 MHz)",78,0.02% "Intel Pentium 4 (Unknown model) (3196 MHz)",78,0.02% "AMD Mobile Duron (Morgan core) (1300 MHz)",78,0.02% "Intel Pentium 4 Northwood (2259 MHz)",78,0.02% "Intel Pentium 4 Northwood (2994 MHz)",77,0.01% "Intel Pentium 4 Northwood Xeon (3064 MHz)",77,0.01% "AMD K7 (Unknown model) (1293 MHz)",77,0.01% "Intel Pentium Pro (Unknown model) (1191 MHz)",77,0.01% "AMD (Unknown model) (1904 MHz)",77,0.01% "AMD (Unknown model) (1998 MHz)",77,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (863 MHz)",77,0.01% "Intel Pentium 4 Northwood Xeon (3066 MHz)",77,0.01% "Intel Pentium 4 (Unknown model) (3118 MHz)",77,0.01% "Intel Pentium 4 Northwood (1995 MHz)",77,0.01% "AMD K7 (Unknown model) (2170 MHz)",76,0.01% "AMD K7 (Unknown model) (2127 MHz)",76,0.01% "AMD (Unknown model) (2417 MHz)",76,0.01% "Intel Pentium 4 Northwood Xeon (2191 MHz)",76,0.01% "AMD K7 (Unknown model) (1683 MHz)",75,0.01% "Intel Pentium 4 Northwood (2587 MHz)",75,0.01% "Intel Pentium 4 (Unknown model) (2545 MHz)",75,0.01% "Intel Pentium 4 Northwood (3191 MHz)",75,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1532 MHz)",75,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1600 MHz)",74,0.01% "Intel Pentium 4 Northwood (2527 MHz)",74,0.01% "Intel Pentium 4 Northwood Xeon (2800 MHz)",74,0.01% "AMD (Unknown model) (2198 MHz)",73,0.01% "AMD (Unknown model) (2599 MHz)",73,0.01% "Intel Pentium 4 Northwood (2795 MHz)",73,0.01% "AMD K7 (Unknown model) (1494 MHz)",73,0.01% "AMD K7 (Unknown model) (1496 MHz)",73,0.01% "Intel Pentium 4 (Unknown model) (2392 MHz)",73,0.01% "Intel Pentium 4 Willamette Xeon (1716 MHz)",72,0.01% "AMD K7 (Unknown model) (1668 MHz)",72,0.01% "Intel Pentium Pro (Unknown model) (2260 MHz)",72,0.01% "AMD K7 (Unknown model) (1400 MHz)",72,0.01% "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1196 MHz)",72,0.01% "AMD (Unknown model) (999 MHz)",71,0.01% "Intel Pentium 4 Northwood (3398 MHz)",71,0.01% "4 x i386 (Unknown) (1990 MHz)",71,0.01% "Intel Pentium 4 (Unknown model) (3398 MHz)",71,0.01% "AMD K7 (Unknown model) (1511 MHz)",71,0.01% "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1202 MHz)",71,0.01% "Intel Pentium 4 Northwood Xeon (2193 MHz)",71,0.01% "AMD K7 (Unknown model) (1988 MHz)",71,0.01% "Intel Pentium 4 (Unknown model) (2677 MHz)",71,0.01% "AMD K7 (Unknown model) (1993 MHz)",70,0.01% "AMD K7 (Unknown model) (1808 MHz)",70,0.01% "AMD (Unknown model) (1807 MHz)",70,0.01% "Intel Pentium Pro (Unknown model) (2166 MHz)",70,0.01% "AMD Athlon (Thunderbird core) (1200 MHz)",70,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (864 MHz)",69,0.01% "Intel Pentium 4 Northwood (2404 MHz)",69,0.01% "Intel Pentium 4 (Unknown model) (2653 MHz)",69,0.01% "Intel Pentium 4 Northwood (2690 MHz)",69,0.01% "Intel Pentium 4 Willamette (A-Step) (1494 MHz)",69,0.01% "Intel Pentium 4 Willamette (1799 MHz)",69,0.01% "Intel Pentium 4 (Unknown model) (3601 MHz)",69,0.01% "Intel Pentium 4 (Unknown model) (3213 MHz)",69,0.01% "Intel Pentium 4 (Unknown model) (3011 MHz)",69,0.01% "Intel Pentium 4 Northwood Xeon (2393 MHz)",69,0.01% "AMD (Unknown model) (2404 MHz)",69,0.01% "Intel Pentium 4 (Unknown model) (2680 MHz)",68,0.01% "Intel Pentium 4 Northwood Xeon (2394 MHz)",68,0.01% "Intel Pentium 4 Northwood Xeon (3059 MHz)",68,0.01% "Intel Pentium 4 (Unknown model) (3800 MHz)",67,0.01% "Intel Pentium 4 Willamette (1500 MHz)",67,0.01% "AMD K7 (Unknown model) (1344 MHz)",67,0.01% "Intel Pentium 4 Willamette (1894 MHz)",67,0.01% "AMD K7 (Unknown model) (1300 MHz)",67,0.01% "AMD (Unknown model) (2394 MHz)",66,0.01% "Intel Pentium 4 Willamette Xeon (1793 MHz)",66,0.01% "AMD (Unknown model) (2264 MHz)",66,0.01% "Intel Pentium Pro (Unknown model) (1875 MHz)",66,0.01% "Intel Pentium 4 Northwood (2664 MHz)",65,0.01% "Intel Pentium 4 Willamette (A-Step) (1500 MHz)",64,0.01% "AMD K7 (Unknown model) (2153 MHz)",64,0.01% "Intel Pentium Pro (Unknown model) (1199 MHz)",64,0.01% "AMD Mobile Duron (Morgan core) (1294 MHz)",64,0.01% "Intel Pentium 4 (Unknown model) (3590 MHz)",63,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1394 MHz)",63,0.01% "AMD K7 (Unknown model) (1505 MHz)",63,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1460 MHz)",63,0.01% "Intel Pentium 4 (Unknown model) (2539 MHz)",63,0.01% "PowerPC 7400 (400 MHz)",63,0.01% "Intel Pentium 4 Willamette Xeon (1715 MHz)",62,0.01% "Intel Pentium 4 Northwood (2592 MHz)",62,0.01% "Intel Pentium 4 Northwood (2665 MHz)",62,0.01% "Intel Pentium 4 Willamette (A-Step) (1700 MHz)",62,0.01% "Intel Pentium Pro (Unknown model) (1693 MHz)",62,0.01% "Intel Pentium Pro (Unknown model) (2405 MHz)",62,0.01% "AMD K7 (Unknown model) (1333 MHz)",61,0.01% "Intel Pentium 4 (Unknown model) (2987 MHz)",61,0.01% "Intel Pentium 4 Northwood (2667 MHz)",61,0.01% "AMD (Unknown model) (2104 MHz)",61,0.01% "AMD K7 (Unknown model) (1531 MHz)",61,0.01% "AMD K7 (Unknown model) (1839 MHz)",60,0.01% "Intel Pentium 4 Willamette (1703 MHz)",60,0.01% "AMD Athlon (Thunderbird core) (1333 MHz)",60,0.01% "Dual PowerPC 7450 (1416 MHz)",60,0.01% "AMD K7 (Unknown model) (1464 MHz)",60,0.01% "Intel Pentium 4 Northwood Xeon (2790 MHz)",60,0.01% "Intel Pentium 4 Northwood (2693 MHz)",60,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1544 MHz)",60,0.01% "AMD K7 (Unknown model) (1469 MHz)",60,0.01% "Intel Pentium 4 Northwood (2623 MHz)",60,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1668 MHz)",59,0.01% "Intel Pentium 4 Northwood (2018 MHz)",59,0.01% "Intel Pentium 4 Northwood (2429 MHz)",59,0.01% "AMD (Unknown model) (2195 MHz)",59,0.01% "Intel Pentium 4 (Unknown model) (2931 MHz)",59,0.01% "Intel Pentium 4 Willamette (1494 MHz)",58,0.01% "AMD K7 (Unknown model) (2130 MHz)",58,0.01% "AMD K7 (Unknown model) (1498 MHz)",58,0.01% "Intel Pentium 4 Willamette Xeon (1703 MHz)",58,0.01% "Intel Pentium 4 Willamette (1716 MHz)",58,0.01% "Intel Pentium 4 (Unknown model) (2927 MHz)",58,0.01% "AMD K7 (Unknown model) (1997 MHz)",58,0.01% "Intel Pentium Pro (Unknown model) (2143 MHz)",58,0.01% "Intel Pentium 4 Willamette (1992 MHz)",57,0.01% "Intel Pentium 4 (Unknown model) (3063 MHz)",57,0.01% "Intel Pentium 4 Northwood (2656 MHz)",57,0.01% "AMD K7 (Unknown model) (1656 MHz)",57,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (999 MHz)",57,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1333 MHz)",57,0.01% "AMD K7 (Unknown model) (2015 MHz)",57,0.01% "AMD K7 (Unknown model) (1595 MHz)",57,0.01% "AMD K7 (Unknown model) (2008 MHz)",57,0.01% "Intel Pentium 4 (Unknown model) (3051 MHz)",56,0.01% "AMD (Unknown model) (2500 MHz)",56,0.01% "Intel Pentium 4 Northwood (2505 MHz)",56,0.01% "AMD (Unknown model) (2250 MHz)",56,0.01% "AMD K7 (Unknown model) (1788 MHz)",56,0.01% "Intel Pentium 4 (Unknown model) (2678 MHz)",56,0.01% "AMD K7 (Unknown model) (1987 MHz)",56,0.01% "Intel Pentium Pro (Unknown model) (2049 MHz)",56,0.01% "Intel Pentium 4 Northwood Xeon (1600 MHz)",55,0.01% "AMD (Unknown model) (1872 MHz)",55,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (1000 MHz)",55,0.01% "Intel Pentium 4 (Unknown model) (3190 MHz)",55,0.01% "Intel Pentium Pro (Unknown model) (2448 MHz)",55,0.01% "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (996 MHz)",55,0.01% "AMD K7 (Unknown model) (1746 MHz)",55,0.01% "AMD (Unknown model) (1980 MHz)",55,0.01% "AMD (Unknown model) (2003 MHz)",55,0.01% "AMD (Unknown model) (2419 MHz)",55,0.01% "Intel Pentium Pro (Unknown model) (1195 MHz)",55,0.01% "Intel Pentium 4 (Unknown model) (2808 MHz)",55,0.01% "AMD K7 (Unknown model) (1497 MHz)",55,0.01% "AMD (Unknown model) (2249 MHz)",55,0.01% "Intel Pentium 4 (Unknown model) (3195 MHz)",54,0.01% "Intel Pentium 4 (Unknown model) (2655 MHz)",54,0.01% "AMD Mobile Duron (Morgan core) (1000 MHz)",54,0.01% "AMD (Unknown model) (804 MHz)",54,0.01% "Intel Pentium 4 Northwood (2497 MHz)",53,0.01% "AMD K7 (Unknown model) (2019 MHz)",53,0.01% "Intel Pentium 4 (Unknown model) (3457 MHz)",53,0.01% "Intel Pentium 4 Northwood (2604 MHz)",53,0.01% "AMD (Unknown model) (1890 MHz)",53,0.01% "AMD K7 (Unknown model) (2124 MHz)",53,0.01% "Intel Pentium 4 (Unknown model) (2658 MHz)",52,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1527 MHz)",52,0.01% "Intel Pentium 4 Willamette Xeon (1800 MHz)",52,0.01% "Intel Pentium Pro (Unknown model) (2050 MHz)",52,0.01% "PowerPC 7450 (866 MHz)",52,0.01% "Intel Pentium 4 Northwood (2204 MHz)",52,0.01% "Intel Pentium Pro (Unknown model) (1708 MHz)",51,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1469 MHz)",51,0.01% "AMD K7 (Unknown model) (1593 MHz)",51,0.01% "Intel Pentium 4 (Unknown model) (2534 MHz)",51,0.01% "Intel Pentium 4 Northwood (3054 MHz)",51,0.01% "Intel Pentium 4 (Unknown model) (2930 MHz)",51,0.01% "Intel Pentium Pro (Unknown model) (1996 MHz)",51,0.01% "AMD K7 (Unknown model) (1353 MHz)",51,0.01% "Intel Pentium 4 (Unknown model) (2786 MHz)",51,0.01% "PowerPC 7400 (450 MHz)",51,0.01% "Intel Pentium 4 Willamette (1599 MHz)",50,0.01% "Intel Pentium 4 Northwood Xeon (1893 MHz)",50,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (1005 MHz)",50,0.01% "Intel Pentium 4 Northwood (2558 MHz)",50,0.01% "Intel Pentium 4 (Unknown model) (3390 MHz)",50,0.01% "AMD K7 (Unknown model) (1599 MHz)",50,0.01% "AMD K7 (Unknown model) (2003 MHz)",50,0.01% "Intel Pentium 4 Northwood (2221 MHz)",50,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (730 MHz)",50,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1045 MHz)",50,0.01% "Intel Pentium 4 Northwood Xeon (1798 MHz)",50,0.01% "Intel Pentium 4 Northwood (3042 MHz)",50,0.01% "AMD K7 (Unknown model) (1730 MHz)",50,0.01% "Intel Pentium 4 Northwood (2499 MHz)",49,0.01% "Intel Pentium Pro (Unknown model) (2668 MHz)",49,0.01% "AMD K7 (Unknown model) (1502 MHz)",49,0.01% "Intel Pentium 4 Northwood (2219 MHz)",49,0.01% "Intel Pentium Pro (Unknown model) (1805 MHz)",49,0.01% "Intel Pentium 4 Northwood (2839 MHz)",49,0.01% "AMD K7 (Unknown model) (1995 MHz)",49,0.01% "Intel Pentium Pro (Unknown model) (1608 MHz)",49,0.01% "Intel Pentium Pro (Unknown model) (1697 MHz)",49,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1528 MHz)",49,0.01% "AMD K7 (Unknown model) (1915 MHz)",48,0.01% "Intel Pentium 4 (Unknown model) (3334 MHz)",48,0.01% "AMD (Unknown model) (2058 MHz)",48,0.01% "Intel Pentium 4 Northwood (1600 MHz)",48,0.01% "AMD Athlon (Thunderbird core) (1202 MHz)",48,0.01% "AMD K7 (Unknown model) (1835 MHz)",48,0.01% "AMD K7 (Unknown model) (950 MHz)",48,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (801 MHz)",48,0.01% "Intel Pentium 4 Northwood (2796 MHz)",48,0.01% "AMD (Unknown model) (2099 MHz)",48,0.01% "AMD (Unknown model) (2520 MHz)",48,0.01% "Intel Pentium 4 Willamette (A-Step) (1483 MHz)",48,0.01% "AMD Mobile Duron (Morgan core) (1194 MHz)",48,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1674 MHz)",48,0.01% "Intel Pentium Pro (Unknown model) (1096 MHz)",48,0.01% "AMD Athlon (Thunderbird core) (1002 MHz)",48,0.01% "Intel Pentium Pro (Unknown model) (1297 MHz)",47,0.01% "AMD K7 (Unknown model) (1831 MHz)",47,0.01% "Intel Pentium 4 Northwood (3067 MHz)",47,0.01% "Intel Pentium 4 (Unknown model) (2128 MHz)",47,0.01% "AMD K7 (Unknown model) (1603 MHz)",47,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1470 MHz)",47,0.01% "AMD (Unknown model) (2499 MHz)",47,0.01% "AMD (Unknown model) (1909 MHz)",47,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1673 MHz)",47,0.01% "AMD K7 (Unknown model) (1528 MHz)",47,0.01% "Intel Pentium Pro (Unknown model) (2664 MHz)",46,0.01% "AMD (Unknown model) (2309 MHz)",46,0.01% "Intel Pentium 4 (Unknown model) (3324 MHz)",46,0.01% "Intel Pentium 4 (Unknown model) (2396 MHz)",46,0.01% "Intel Pentium 4 Northwood (2663 MHz)",46,0.01% "AMD K7 (Unknown model) (1673 MHz)",46,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1396 MHz)",46,0.01% "Intel Pentium 4 (Unknown model) (3079 MHz)",46,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1531 MHz)",46,0.01% "AMD K7 (Unknown model) (1460 MHz)",46,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (799 MHz)",45,0.01% "AMD Athlon (Thunderbird core) (706 MHz)",45,0.01% "Intel Pentium 4 (Unknown model) (3072 MHz)",45,0.01% "Intel Pentium 4 (Unknown model) (2530 MHz)",45,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1664 MHz)",45,0.01% "Intel Pentium 4 Willamette Xeon (1792 MHz)",45,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1661 MHz)",45,0.01% "Intel Pentium 4 (Unknown model) (2788 MHz)",45,0.01% "Intel Pentium 4 (Unknown model) (3197 MHz)",45,0.01% "Intel Pentium Pro (Unknown model) (2162 MHz)",44,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1160 MHz)",44,0.01% "Intel Pentium 4 Northwood (3065 MHz)",44,0.01% "AMD Athlon (Thunderbird core) (1399 MHz)",44,0.01% "Intel Pentium Pro (Unknown model) (2992 MHz)",44,0.01% "Intel Pentium 4 Northwood (2595 MHz)",44,0.01% "Intel Pentium 4 Willamette (1695 MHz)",44,0.01% "Intel Pentium Pro (Unknown model) (2306 MHz)",44,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1403 MHz)",44,0.01% "Intel Pentium 4 (Unknown model) (2546 MHz)",44,0.01% "Intel Pentium 4 Northwood (3058 MHz)",44,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1599 MHz)",43,0.01% "AMD K7 (Unknown model) (2094 MHz)",43,0.01% "Intel Pentium 4 (Unknown model) (2277 MHz)",43,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (1002 MHz)",43,0.01% "Intel Pentium 4 Northwood (1997 MHz)",43,0.01% "Intel Pentium 4 Northwood (3199 MHz)",43,0.01% "AMD (Unknown model) (2805 MHz)",43,0.01% "AMD K7 (Unknown model) (1470 MHz)",43,0.01% "Intel Pentium Pro (Unknown model) (2662 MHz)",43,0.01% "Intel Pentium Pro (Unknown model) (3200 MHz)",43,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (866 MHz)",43,0.01% "AMD K7 (Unknown model) (1529 MHz)",43,0.01% "AMD K7 (Unknown model) (1050 MHz)",42,0.01% "AMD (Unknown model) (2472 MHz)",42,0.01% "Intel Pentium 4 (Unknown model) (3061 MHz)",42,0.01% "Intel Pentium 4 Northwood (3407 MHz)",42,0.01% "8 x i386 (Unknown) (2990 MHz)",42,0.01% "AMD Athlon (Thunderbird core) (1008 MHz)",42,0.01% "AMD (Unknown model) (2080 MHz)",42,0.01% "AMD K7 (Unknown model) (2173 MHz)",42,0.01% "AMD (Unknown model) (2160 MHz)",42,0.01% "Intel Pentium Pro (Unknown model) (1507 MHz)",42,0.01% "Intel Pentium 4 Northwood Xeon (2400 MHz)",42,0.01% "Intel Pentium 4 Northwood (2814 MHz)",42,0.01% "Intel Pentium Pro (Unknown model) (1218 MHz)",41,0.01% "AMD K7 (Unknown model) (2119 MHz)",41,0.01% "Intel Pentium 4 Northwood (2825 MHz)",41,0.01% "AMD K7 (Unknown model) (2014 MHz)",41,0.01% "Intel Pentium Pro (Unknown model) (1809 MHz)",41,0.01% "Intel Pentium Pro (Unknown model) (1313 MHz)",41,0.01% "AMD K7 (Unknown model) (1145 MHz)",41,0.01% "Intel Pentium 4 Northwood (2680 MHz)",41,0.01% "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1129 MHz)",40,0.01% "AMD K7 (Unknown model) (1396 MHz)",40,0.01% "Intel Pentium 4 (Unknown model) (3410 MHz)",40,0.01% "AMD K7 (Unknown model) (1152 MHz)",40,0.01% "Intel Pentium 4 Willamette Xeon (1697 MHz)",40,0.01% "Intel Pentium 4 Northwood (1594 MHz)",40,0.01% "AMD K7 (Unknown model) (1669 MHz)",40,0.01% "AMD K7 (Unknown model) (1847 MHz)",40,0.01% "Intel Pentium 4 (Unknown model) (2953 MHz)",40,0.01% "AMD Duron (Spitfire core) (801 MHz)",40,0.01% "AMD Athlon (Thunderbird core) (1400 MHz)",40,0.01% "AMD K7 (Unknown model) (1342 MHz)",40,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (701 MHz)",39,0.01% "Intel Pentium Pro (Unknown model) (1091 MHz)",39,0.01% "Intel Pentium 4 Willamette (1795 MHz)",39,0.01% "AMD K7 (Unknown model) (1582 MHz)",39,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1100 MHz)",39,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1539 MHz)",39,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1095 MHz)",39,0.01% "Intel Pentium Pro (Unknown model) (1293 MHz)",39,0.01% "AMD (Unknown model) (1606 MHz)",39,0.01% "AMD (Unknown model) (1852 MHz)",39,0.01% "AMD Athlon (Thunderbird core) (900 MHz)",39,0.01% "AMD K7 (Unknown model) (2209 MHz)",39,0.01% "Intel Pentium 4 Northwood (2789 MHz)",38,0.01% "AMD (Unknown model) (1001 MHz)",38,0.01% "Intel Pentium 4 (Unknown model) (3210 MHz)",38,0.01% "Intel Pentium 4 (Unknown model) (2397 MHz)",38,0.01% "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (501 MHz)",38,0.01% "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (730 MHz)",38,0.01% "AMD K7 (Unknown model) (1655 MHz)",38,0.01% "Intel Pentium 4 (Unknown model) (3150 MHz)",38,0.01% "AMD Mobile Duron (Morgan core) (1302 MHz)",38,0.01% "Intel Pentium Pro (Unknown model) (2700 MHz)",38,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1535 MHz)",38,0.01% "Intel Pentium Pro (Unknown model) (659 MHz)",37,0.01% "Intel Celeron (0.18 micron process) with internal L2 cache (1096 MHz)",37,0.01% "Intel Pentium 4 Willamette (1893 MHz)",37,0.01% "AMD (Unknown model) (2232 MHz)",37,0.01% "Intel Pentium Pro (Unknown model) (1488 MHz)",37,0.01% "Intel Pentium Pro (Unknown model) (919 MHz)",37,0.01% "AMD (Unknown model) (2208 MHz)",37,0.01% "Intel Pentium Pro (Unknown model) (893 MHz)",37,0.01% "AMD K7 (Unknown model) (1728 MHz)",37,0.01% "Intel Pentium 4 Northwood (2277 MHz)",37,0.01% "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1195 MHz)",37,0.01% "Intel Pentium Pro (Unknown model) (1806 MHz)",37,0.01% "Intel Pentium Pro (Unknown model) (2672 MHz)",37,0.01% "Intel Pentium 4 (Unknown model) (3005 MHz)",37,0.01% "Intel Pentium 4 Northwood (2812 MHz)",37,0.01% "AMD (Unknown model) (1900 MHz)",36,0.01% "AMD (Unknown model) (1990 MHz)",36,0.01% "AMD (Unknown model) (2640 MHz)",36,0.01% "AMD (Unknown model) (2512 MHz)",36,0.01% "Intel Pentium 4 Willamette (A-Step) (1693 MHz)",36,0.01% "AMD K7 (Unknown model) (1753 MHz)",36,0.01% "AMD K7 (Unknown model) (1743 MHz)",36,0.01% "AMD (Unknown model) (1899 MHz)",36,0.01% "Intel Pentium Pro (Unknown model) (918 MHz)",36,0.01% "AMD K7 (Unknown model) (1526 MHz)",36,0.01% "Intel Pentium 4 Northwood Xeon (1995 MHz)",36,0.01% "AMD K7 (Unknown model) (1817 MHz)",36,0.01% "Intel Pentium 4 (Unknown model) (2654 MHz)",36,0.01% "AMD K7 (Unknown model) (1917 MHz)",36,0.01% "Intel Pentium Pro (Unknown model) (1588 MHz)",36,0.01% "Intel Pentium Pro (Unknown model) (1312 MHz)",36,0.01% "Intel Pentium 4 Willamette (A-Step) (1400 MHz)",36,0.01% "Intel Pentium Pro (Unknown model) (1100 MHz)",35,0.01% "AMD (Unknown model) (2800 MHz)",35,0.01% "AMD (Unknown model) (2799 MHz)",35,0.01% "Intel Pentium 4 (Unknown model) (3264 MHz)",35,0.01% "Intel Pentium 4 Willamette (A-Step) (1513 MHz)",35,0.01% "AMD Mobile Duron (Morgan core) (995 MHz)",35,0.01% "Intel Pentium 4 (Unknown model) (2801 MHz)",35,0.01% "Intel Pentium 4 (Unknown model) (3299 MHz)",35,0.01% "AMD K7 (Unknown model) (999 MHz)",35,0.01% "AMD (Unknown model) (1854 MHz)",35,0.01% "Intel Pentium 4 (Unknown model) (2261 MHz)",35,0.01% "Intel Pentium Pro (Unknown model) (1497 MHz)",35,0.01% "Intel Pentium Pro (Unknown model) (2136 MHz)",35,0.01% "Intel Pentium 4 (Unknown model) (3029 MHz)",35,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1252 MHz)",35,0.01% "AMD (Unknown model) (1791 MHz)",34,0.01% "Intel Pentium 4 Northwood (2596 MHz)",34,0.01% "AMD K7 (Unknown model) (1742 MHz)",34,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1050 MHz)",34,0.01% "AMD Athlon (Thunderbird core) (1001 MHz)",34,0.01% "Intel Pentium 4 Northwood (2522 MHz)",34,0.01% "AMD K7 (Unknown model) (1193 MHz)",34,0.01% "AMD K7 (Unknown model) (2085 MHz)",34,0.01% "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1295 MHz)",34,0.01% "Intel Pentium 4 Northwood (2205 MHz)",34,0.01% "AMD K7 (Unknown model) (1095 MHz)",34,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1152 MHz)",34,0.01% "Intel Pentium 4 Northwood Xeon (2792 MHz)",34,0.01% "Intel Pentium 4 Northwood Xeon (2791 MHz)",34,0.01% "Intel Pentium Pro (Unknown model) (920 MHz)",34,0.01% "AMD (Unknown model) (2451 MHz)",34,0.01% "Intel Pentium 4 Northwood (2292 MHz)",34,0.01% "AMD (Unknown model) (1400 MHz)",34,0.01% "AMD K7 (Unknown model) (1465 MHz)",34,0.01% "Intel Pentium Pro (Unknown model) (923 MHz)",34,0.01% "Intel Pentium 4 Northwood (2194 MHz)",33,0.01% "AMD (Unknown model) (2813 MHz)",33,0.01% "Intel Pentium 4 (Unknown model) (2985 MHz)",33,0.01% "Intel Pentium Pro (Unknown model) (1610 MHz)",33,0.01% "Intel Pentium 4 Willamette (A-Step) (1285 MHz)",33,0.01% "Intel Pentium 4 Northwood (2389 MHz)",33,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (868 MHz)",33,0.01% "Dual PowerPC 7400 (450 MHz)",33,0.01% "Intel Pentium Pro (Unknown model) (1219 MHz)",33,0.01% "AMD (Unknown model) (1889 MHz)",33,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1477 MHz)",33,0.01% "Intel Pentium 4 Northwood (3079 MHz)",33,0.01% "AMD K7 (Unknown model) (1592 MHz)",33,0.01% "AMD K7 (Unknown model) (1737 MHz)",33,0.01% "Intel Pentium 4 Northwood (2993 MHz)",33,0.01% "AMD (Unknown model) (2311 MHz)",33,0.01% "Intel Pentium 4 Northwood (1796 MHz)",33,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1410 MHz)",33,0.01% "Intel Pentium 4 (Unknown model) (3417 MHz)",33,0.01% "Intel Pentium 4 Northwood (1599 MHz)",32,0.01% "AMD K7 (Unknown model) (1002 MHz)",32,0.01% "Intel Pentium 4 Northwood Xeon (3189 MHz)",32,0.01% "Intel Pentium 4 Willamette (1593 MHz)",32,0.01% "Intel Pentium 4 (Unknown model) (3599 MHz)",32,0.01% "Intel Pentium 4 Northwood Xeon (2493 MHz)",32,0.01% "AMD K7 (Unknown model) (1834 MHz)",32,0.01% "AMD K7 (Unknown model) (2168 MHz)",32,0.01% "AMD Athlon (Thunderbird core) (999 MHz)",32,0.01% "AMD K7 (Unknown model) (1840 MHz)",32,0.01% "Intel Pentium 4 Northwood (3013 MHz)",32,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (601 MHz)",32,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1728 MHz)",32,0.01% "AMD K7 (Unknown model) (1598 MHz)",32,0.01% "Intel Pentium 4 Northwood Xeon (1195 MHz)",32,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1462 MHz)",32,0.01% "AMD K7 (Unknown model) (1249 MHz)",32,0.01% "Intel Pentium Pro (Unknown model) (995 MHz)",32,0.01% "Intel Pentium 4 (Unknown model) (2811 MHz)",32,0.01% "Intel Pentium 4 (Unknown model) (3791 MHz)",32,0.01% "AMD (Unknown model) (1396 MHz)",32,0.01% "Intel Pentium Pro (Unknown model) (1217 MHz)",32,0.01% "AMD (Unknown model) (1985 MHz)",31,0.01% "AMD K7 (Unknown model) (2122 MHz)",31,0.01% "Intel Pentium 4 Willamette (1697 MHz)",31,0.01% "AMD K7 (Unknown model) (1750 MHz)",31,0.01% "Intel Pentium 4 Northwood (2430 MHz)",31,0.01% "Intel Pentium 4 Northwood (2493 MHz)",31,0.01% "Intel Pentium 4 Northwood (1615 MHz)",31,0.01% "AMD (Unknown model) (1979 MHz)",31,0.01% "AMD Athlon (Thunderbird core) (908 MHz)",31,0.01% "Intel Pentium Pro (Unknown model) (922 MHz)",31,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (731 MHz)",31,0.01% "Intel Pentium Pro (Unknown model) (921 MHz)",31,0.01% "AMD K7 (Unknown model) (1796 MHz)",31,0.01% "AMD (Unknown model) (2424 MHz)",31,0.01% "AMD K7 (Unknown model) (1348 MHz)",31,0.01% "AMD (Unknown model) (2304 MHz)",31,0.01% "Intel Pentium 4 (Unknown model) (3040 MHz)",31,0.01% "Intel Pentium 4 Willamette (1513 MHz)",31,0.01% "Intel Pentium Pro (Unknown model) (1609 MHz)",31,0.01% "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1063 MHz)",31,0.01% "Intel Pentium 4 (Unknown model) (3054 MHz)",31,0.01% "Intel Pentium 4 Northwood Xeon (1495 MHz)",31,0.01% "Intel Pentium Pro (Unknown model) (915 MHz)",31,0.01% "Intel Pentium 4 (Unknown model) (2267 MHz)",31,0.01% "Intel Pentium 4 Willamette (2000 MHz)",30,0.01% "Dual PowerPC 7400 (500 MHz)",30,0.01% "AMD K7 (Unknown model) (2189 MHz)",30,0.01% "AMD Athlon (Thunderbird core) (1195 MHz)",30,0.01% "Intel Pentium 4 Northwood Xeon (1695 MHz)",30,0.01% "Intel Pentium 4 Willamette (1615 MHz)",30,0.01% "AMD K7 (Unknown model) (2089 MHz)",30,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (800 MHz)",30,0.01% "Intel Pentium 4 Northwood (2003 MHz)",30,0.01% "AMD K7 (Unknown model) (2106 MHz)",30,0.01% "AMD K7 (Unknown model) (2030 MHz)",30,0.01% "PowerPC 7450 (533 MHz)",30,0.01% "AMD K7 (Unknown model) (2183 MHz)",30,0.01% "AMD K7 (Unknown model) (2010 MHz)",30,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1261 MHz)",30,0.01% "AMD K7 (Unknown model) (2090 MHz)",30,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1737 MHz)",30,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (1004 MHz)",30,0.01% "Intel Pentium 4 (Unknown model) (3414 MHz)",30,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1595 MHz)",30,0.01% "Intel Pentium Pro (Unknown model) (1397 MHz)",30,0.01% "AMD K7 (Unknown model) (1491 MHz)",30,0.01% "AMD Mobile Duron (Morgan core) (1202 MHz)",30,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1678 MHz)",30,0.01% "Intel Pentium Pro (Unknown model) (2173 MHz)",30,0.01% "Intel Pentium 4 Northwood Xeon (3073 MHz)",30,0.01% "AMD K7 (Unknown model) (1931 MHz)",30,0.01% "AMD K7 (Unknown model) (1302 MHz)",30,0.01% "Intel Pentium Pro (Unknown model) (3000 MHz)",30,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (803 MHz)",30,0.01% "Intel Pentium 4 Northwood (2534 MHz)",30,0.01% "Intel Pentium 4 Northwood Xeon (2657 MHz)",29,0.01% "AMD K7 (Unknown model) (1579 MHz)",29,0.01% "Intel Pentium 4 Northwood (1614 MHz)",29,0.01% "Intel Pentium Pro (Unknown model) (1827 MHz)",29,0.01% "Intel Pentium 4 (Unknown model) (2947 MHz)",29,0.01% "Intel Pentium 4 Northwood (2408 MHz)",29,0.01% "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1196 MHz)",29,0.01% "Intel Pentium Pro (Unknown model) (1220 MHz)",29,0.01% "AMD (Unknown model) (1993 MHz)",29,0.01% "AMD K7 (Unknown model) (1914 MHz)",29,0.01% "AMD K7 (Unknown model) (2167 MHz)",29,0.01% "Intel Pentium 4 Willamette (A-Step) (1496 MHz)",29,0.01% "AMD K7 (Unknown model) (1525 MHz)",29,0.01% "AMD K7 (Unknown model) (2097 MHz)",29,0.01% "Intel Pentium 4 Northwood (2804 MHz)",29,0.01% "Intel Pentium 4 (Unknown model) (3245 MHz)",29,0.01% "AMD (Unknown model) (2201 MHz)",29,0.01% "Intel Pentium 4 (Unknown model) (2674 MHz)",29,0.01% "Intel Pentium Pro (Unknown model) (1059 MHz)",28,0.01% "Intel Pentium 4 (Unknown model) (3243 MHz)",28,0.01% "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (451 MHz)",28,0.01% "Intel Pentium 4 Northwood Xeon (3200 MHz)",28,0.01% "Intel Pentium Pro (Unknown model) (1315 MHz)",28,0.01% "Intel Pentium Pro (Unknown model) (924 MHz)",28,0.01% "Intel Pentium 4 Northwood (1795 MHz)",28,0.01% "Intel Pentium 4 Northwood Xeon (2806 MHz)",28,0.01% "Intel Pentium 4 Northwood (1797 MHz)",28,0.01% "AMD K7 (Unknown model) (1248 MHz)",28,0.01% "AMD K7 (Unknown model) (2080 MHz)",28,0.01% "AMD K7 (Unknown model) (1576 MHz)",28,0.01% "AMD (Unknown model) (2110 MHz)",28,0.01% "Intel Pentium Pro (Unknown model) (2132 MHz)",28,0.01% "Intel Pentium 4 Willamette (A-Step) (1503 MHz)",28,0.01% "Intel Pentium Pro (Unknown model) (1904 MHz)",27,0.01% "Intel Pentium 4 Northwood (2257 MHz)",27,0.01% "Intel Pentium 4 (Unknown model) (2265 MHz)",27,0.01% "Intel Pentium Pro (Unknown model) (1831 MHz)",27,0.01% "Intel Pentium Pro (Unknown model) (1311 MHz)",27,0.01% "Intel Pentium Pro (Unknown model) (1216 MHz)",27,0.01% "Intel Pentium 4 (Unknown model) (3617 MHz)",27,0.01% "Intel Pentium 4 Northwood (2636 MHz)",27,0.01% "Intel Pentium 4 Willamette (1503 MHz)",27,0.01% "Dual PowerPC 7450 (800 MHz)",27,0.01% "Intel Pentium 4 Northwood (2805 MHz)",27,0.01% "Intel Pentium 4 Northwood Xeon (2397 MHz)",27,0.01% "AMD Athlon (Thunderbird core) (1101 MHz)",27,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1200 MHz)",27,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1472 MHz)",27,0.01% "AMD Athlon (Thunderbird core) (1302 MHz)",27,0.01% "Intel Pentium 4 Northwood (2265 MHz)",27,0.01% "AMD (Unknown model) (2470 MHz)",27,0.01% "Intel Pentium Pro (Unknown model) (1314 MHz)",27,0.01% "AMD K7 (Unknown model) (2186 MHz)",27,0.01% "Intel Pentium Pro (Unknown model) (916 MHz)",27,0.01% "AMD Athlon MP/Mobile Athlon (Palomino core) (1465 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (917 MHz)",26,0.01% "Intel Pentium 4 (Unknown model) (3209 MHz)",26,0.01% "Intel Pentium 4 Northwood (2196 MHz)",26,0.01% "AMD (Unknown model) (2059 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (609 MHz)",26,0.01% "AMD (Unknown model) (2189 MHz)",26,0.01% "Intel Pentium 4 Willamette (1792 MHz)",26,0.01% "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (797 MHz)",26,0.01% "AMD Duron (Spitfire core) (800 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (838 MHz)",26,0.01% "AMD Mobile Duron (Morgan core) (1095 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (1225 MHz)",26,0.01% "Intel Pentium 4 Willamette (1900 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (841 MHz)",26,0.01% "Intel Pentium III (0.18 micron process) with internal L2 cache (651 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (1727 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (1710 MHz)",26,0.01% "Intel Pentium 4 (Unknown model) (3606 MHz)",26,0.01% "AMD (Unknown model) (2206 MHz)",26,0.01% "Intel Pentium 4 Northwood (2520 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (1310 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (899 MHz)",26,0.01% "Intel Pentium Pro (Unknown model) (2333 MHz)",26,0.01% "AMD K7 (Unknown model) (1197 MHz)",26,0.01% "Intel Pentium 4 (Unknown model) (2138 MHz)",26,0.01% "Intel Pentium 4 Northwood Xeon (1793 MHz)",26,0.01% "AMD K7 (Unknown model) (1194 MHz)",26,0.01% "AMD K7 (Unknown model) (1739 MHz)",25,0.00% "Intel Pentium 4 Willamette (1892 MHz)",25,0.00% "AMD K7 (Unknown model) (2132 MHz)",25,0.00% "Intel Pentium Pro (Unknown model) (2667 MHz)",25,0.00% "Intel Pentium Pro (Unknown model) (2160 MHz)",25,0.00% "Intel Pentium 4 Northwood (2504 MHz)",25,0.00% "AMD K7 (Unknown model) (902 MHz)",25,0.00% "Intel Pentium 4 (Unknown model) (2789 MHz)",25,0.00% "Intel Pentium 4 (Unknown model) (2259 MHz)",25,0.00% "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1296 MHz)",25,0.00% "Intel Pentium Pro (Unknown model) (1423 MHz)",25,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1660 MHz)",25,0.00% "AMD (Unknown model) (2029 MHz)",25,0.00% "AMD K7 (Unknown model) (1828 MHz)",25,0.00% "AMD K7 (Unknown model) (1577 MHz)",25,0.00% "Intel Pentium 4 Northwood (2008 MHz)",25,0.00% "AMD (Unknown model) (2392 MHz)",25,0.00% "Intel Pentium 4 Northwood (2546 MHz)",25,0.00% "AMD K7 (Unknown model) (1198 MHz)",25,0.00% "AMD K7 (Unknown model) (1802 MHz)",25,0.00% "Intel Pentium 4 Northwood (2678 MHz)",25,0.00% "Intel Pentium 4 Northwood Xeon (2205 MHz)",25,0.00% "Intel Pentium 4 Northwood (2685 MHz)",25,0.00% "Intel Pentium Pro (Unknown model) (1667 MHz)",25,0.00% "AMD K7 (Unknown model) (1459 MHz)",25,0.00% "Intel Pentium 4 (Unknown model) (3322 MHz)",25,0.00% "Intel Pentium Pro (Unknown model) (2194 MHz)",25,0.00% "Intel Pentium 4 Willamette (A-Step) (1594 MHz)",25,0.00% "Intel Pentium Pro (Unknown model) (2926 MHz)",25,0.00% "Intel Pentium Pro (Unknown model) (845 MHz)",25,0.00% "AMD (Unknown model) (2131 MHz)",25,0.00% "AMD Mobile Duron (Morgan core) (1002 MHz)",25,0.00% "AMD K7 (Unknown model) (2163 MHz)",25,0.00% "Intel Pentium 4 (Unknown model) (3016 MHz)",25,0.00% "Intel Pentium Pro (Unknown model) (1687 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (998 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (3150 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (1422 MHz)",24,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (751 MHz)",24,0.00% "Intel Pentium 4 (Unknown model) (3012 MHz)",24,0.00% "AMD (Unknown model) (1743 MHz)",24,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1397 MHz)",24,0.00% "Intel Pentium 4 Northwood (3299 MHz)",24,0.00% "AMD (Unknown model) (2999 MHz)",24,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1300 MHz)",24,0.00% "AMD Athlon (Thunderbird core) (896 MHz)",24,0.00% "Intel Pentium 4 (Unknown model) (2664 MHz)",24,0.00% "AMD K7 (Unknown model) (1199 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (1224 MHz)",24,0.00% "AMD K7 (Unknown model) (1827 MHz)",24,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1262 MHz)",24,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (902 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (1223 MHz)",24,0.00% "PowerPC 7400 (466 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (2403 MHz)",24,0.00% "Intel Pentium 4 Willamette Xeon (1816 MHz)",24,0.00% "AMD K7 (Unknown model) (1918 MHz)",24,0.00% "AMD K7 (Unknown model) (1202 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (837 MHz)",24,0.00% "AMD (Unknown model) (2006 MHz)",24,0.00% "Intel Pentium 4 (Unknown model) (2144 MHz)",24,0.00% "AMD K7 (Unknown model) (1394 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (1732 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (1524 MHz)",24,0.00% "AMD Athlon (Thunderbird core) (1100 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (1215 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (1061 MHz)",24,0.00% "AMD K7 (Unknown model) (1731 MHz)",24,0.00% "AMD K7 (Unknown model) (1751 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (1062 MHz)",24,0.00% "Intel Pentium 4 Northwood Xeon (2660 MHz)",24,0.00% "Intel Pentium Pro (Unknown model) (1305 MHz)",24,0.00% "AMD (Unknown model) (2020 MHz)",24,0.00% "AMD (Unknown model) (2398 MHz)",23,0.00% "AMD K7 (Unknown model) (1615 MHz)",23,0.00% "Intel Pentium 4 Northwood (2258 MHz)",23,0.00% "AMD K7 (Unknown model) (2138 MHz)",23,0.00% "Intel Pentium 4 Northwood (2434 MHz)",23,0.00% "Intel Pentium Pro (Unknown model) (1660 MHz)",23,0.00% "Intel Pentium 4 Willamette (1499 MHz)",23,0.00% "AMD (Unknown model) (2402 MHz)",23,0.00% "Intel Pentium 4 Willamette (A-Step) (1499 MHz)",23,0.00% "Intel Pentium 4 (Unknown model) (3360 MHz)",23,0.00% "Intel Pentium Pro (Unknown model) (1222 MHz)",23,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (804 MHz)",23,0.00% "Intel Pentium 4 (Unknown model) (3186 MHz)",23,0.00% "Intel Pentium Pro (Unknown model) (886 MHz)",23,0.00% "Intel Pentium 4 Northwood (2991 MHz)",23,0.00% "Intel Pentium 4 Willamette (1597 MHz)",23,0.00% "AMD Athlon (Thunderbird core) (1050 MHz)",23,0.00% "AMD K7 (Unknown model) (1527 MHz)",23,0.00% "AMD K7 (Unknown model) (1900 MHz)",23,0.00% "Intel Pentium 4 Northwood (2099 MHz)",23,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1059 MHz)",23,0.00% "AMD K7 (Unknown model) (2001 MHz)",23,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1667 MHz)",23,0.00% "AMD K7 (Unknown model) (1262 MHz)",23,0.00% "Intel Pentium 4 Willamette Xeon (1695 MHz)",23,0.00% "AMD Athlon (Thunderbird core) (1300 MHz)",23,0.00% "Intel Pentium Pro (Unknown model) (842 MHz)",23,0.00% "Intel Pentium 4 Northwood Xeon (2204 MHz)",23,0.00% "Intel Pentium Pro (Unknown model) (1319 MHz)",23,0.00% "AMD K7 (Unknown model) (1044 MHz)",23,0.00% "Intel Pentium 4 Willamette Xeon (1817 MHz)",22,0.00% "AMD K7 (Unknown model) (1756 MHz)",22,0.00% "PowerPC 7450 (1400 MHz)",22,0.00% "AMD (Unknown model) (1826 MHz)",22,0.00% "Intel Pentium 4 Willamette (1917 MHz)",22,0.00% "Intel Pentium 4 Northwood (2624 MHz)",22,0.00% "AMD (Unknown model) (1997 MHz)",22,0.00% "Intel Pentium Pro (Unknown model) (2880 MHz)",22,0.00% "AMD K7 (Unknown model) (1513 MHz)",22,0.00% "Intel Pentium 4 Northwood (2486 MHz)",22,0.00% "AMD (Unknown model) (2454 MHz)",22,0.00% "AMD Athlon (Thunderbird core) (1394 MHz)",22,0.00% "AMD (Unknown model) (2300 MHz)",22,0.00% "Intel Pentium 4 (Unknown model) (3260 MHz)",22,0.00% "Intel Pentium 4 Northwood Xeon (2399 MHz)",22,0.00% "Intel Pentium 4 Willamette (1707 MHz)",22,0.00% "Intel Pentium Pro (Unknown model) (796 MHz)",22,0.00% "PowerPC 7450 (550 MHz)",22,0.00% "AMD Athlon (Thunderbird core) (1410 MHz)",22,0.00% "Intel Pentium Pro (Unknown model) (1226 MHz)",22,0.00% "Intel Pentium 4 Northwood Xeon (2664 MHz)",22,0.00% "AMD (Unknown model) (2045 MHz)",22,0.00% "Intel Pentium Pro (Unknown model) (418 MHz)",22,0.00% "AMD K7 (Unknown model) (1793 MHz)",22,0.00% "Intel Pentium Pro (Unknown model) (1730 MHz)",22,0.00% "Intel Pentium 4 Willamette (A-Step) (1396 MHz)",22,0.00% "Intel Pentium Pro (Unknown model) (2326 MHz)",22,0.00% "AMD K7 (Unknown model) (1261 MHz)",22,0.00% "Intel Pentium 4 (Unknown model) (3157 MHz)",22,0.00% "Intel Pentium 4 Northwood (2203 MHz)",22,0.00% "Intel Pentium 4 (Unknown model) (2929 MHz)",22,0.00% "Intel Pentium 4 (Unknown model) (2390 MHz)",22,0.00% "Intel Pentium 4 Willamette (1817 MHz)",22,0.00% "Intel Pentium 4 (Unknown model) (2856 MHz)",21,0.00% "Intel Pentium 4 (Unknown model) (3212 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (989 MHz)",21,0.00% "AMD K7 (Unknown model) (1936 MHz)",21,0.00% "Intel Pentium 4 Willamette (A-Step) (1794 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (843 MHz)",21,0.00% "AMD (Unknown model) (3000 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (794 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (1138 MHz)",21,0.00% "AMD K7 (Unknown model) (1855 MHz)",21,0.00% "AMD K7 (Unknown model) (1190 MHz)",21,0.00% "Intel Pentium 4 Northwood (2544 MHz)",21,0.00% "Intel Pentium 4 Northwood (3150 MHz)",21,0.00% "Intel Pentium 4 (Unknown model) (2422 MHz)",21,0.00% "AMD K7 (Unknown model) (2197 MHz)",21,0.00% "Intel Pentium 4 Northwood (2536 MHz)",21,0.00% "Intel Pentium 4 Northwood (1595 MHz)",21,0.00% "Intel Pentium 4 Northwood (2940 MHz)",21,0.00% "AMD (Unknown model) (2299 MHz)",21,0.00% "Intel Pentium 4 Willamette (1999 MHz)",21,0.00% "Intel Pentium 4 Northwood (2104 MHz)",21,0.00% "Intel Pentium 4 (Unknown model) (3216 MHz)",21,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (933 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (1525 MHz)",21,0.00% "AMD Athlon (Thunderbird core) (901 MHz)",21,0.00% "AMD (Unknown model) (1100 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (900 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (1320 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (1804 MHz)",21,0.00% "AMD Athlon (Thunderbird core) (995 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (844 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (3006 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (1826 MHz)",21,0.00% "AMD K7 (Unknown model) (1588 MHz)",21,0.00% "Intel Pentium 4 (Unknown model) (3184 MHz)",21,0.00% "AMD Athlon (Thunderbird core) (1199 MHz)",21,0.00% "AMD K7 (Unknown model) (1312 MHz)",21,0.00% "Intel Pentium 4 Northwood (3057 MHz)",21,0.00% "Intel Pentium Pro (Unknown model) (1533 MHz)",21,0.00% "AMD K7 (Unknown model) (2120 MHz)",20,0.00% "Intel Pentium 4 Northwood Xeon (2659 MHz)",20,0.00% "AMD K7 (Unknown model) (2125 MHz)",20,0.00% "Intel Pentium 4 (Unknown model) (2826 MHz)",20,0.00% "AMD K7 (Unknown model) (1597 MHz)",20,0.00% "AMD Mobile Duron (Morgan core) (999 MHz)",20,0.00% "Intel Pentium 4 Northwood (2688 MHz)",20,0.00% "AMD Duron (Spitfire core) (701 MHz)",20,0.00% "Intel Pentium 4 Willamette (A-Step) (1514 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (1307 MHz)",20,0.00% "Intel Pentium 4 (Unknown model) (3015 MHz)",20,0.00% "AMD K7 (Unknown model) (1807 MHz)",20,0.00% "AMD K7 (Unknown model) (1196 MHz)",20,0.00% "Intel Pentium 4 Willamette (1603 MHz)",20,0.00% "Intel Pentium 4 Northwood (2009 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (914 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (840 MHz)",20,0.00% "AMD (Unknown model) (2700 MHz)",20,0.00% "Intel Pentium 4 (Unknown model) (3411 MHz)",20,0.00% "AMD (Unknown model) (2376 MHz)",20,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1658 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (3192 MHz)",20,0.00% "Intel Pentium 4 (Unknown model) (3017 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (1221 MHz)",20,0.00% "AMD K7 (Unknown model) (1923 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (928 MHz)",20,0.00% "AMD Athlon (Thunderbird core) (1328 MHz)",20,0.00% "AMD (Unknown model) (2530 MHz)",20,0.00% "AMD Athlon (Thunderbird core) (996 MHz)",20,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1593 MHz)",20,0.00% "Intel Pentium 4 Northwood (2811 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (2093 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (1137 MHz)",20,0.00% "AMD (Unknown model) (2203 MHz)",20,0.00% "AMD K7 (Unknown model) (994 MHz)",20,0.00% "AMD K7 (Unknown model) (1326 MHz)",20,0.00% "Intel Pentium 4 Northwood (3062 MHz)",20,0.00% "Intel Pentium 4 (Unknown model) (3383 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (1060 MHz)",20,0.00% "Intel Pentium Pro (Unknown model) (2240 MHz)",19,0.00% "AMD (Unknown model) (2025 MHz)",19,0.00% "AMD (Unknown model) (2005 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (1143 MHz)",19,0.00% "AMD K7 (Unknown model) (1349 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (991 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (1321 MHz)",19,0.00% "AMD K7 (Unknown model) (1473 MHz)",19,0.00% "Intel Pentium 4 (Unknown model) (2271 MHz)",19,0.00% "AMD (Unknown model) (1937 MHz)",19,0.00% "Intel Pentium 4 Northwood (2495 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (1870 MHz)",19,0.00% "AMD (Unknown model) (1840 MHz)",19,0.00% "AMD K7 (Unknown model) (2174 MHz)",19,0.00% "Intel Pentium 4 Northwood (2564 MHz)",19,0.00% "Intel Pentium 4 (Unknown model) (3319 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (3599 MHz)",19,0.00% "AMD K7 (Unknown model) (1110 MHz)",19,0.00% "AMD (Unknown model) (2007 MHz)",19,0.00% "AMD (Unknown model) (2034 MHz)",19,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1464 MHz)",19,0.00% "AMD (Unknown model) (1403 MHz)",19,0.00% "AMD K7 (Unknown model) (1852 MHz)",19,0.00% "Intel Pentium 4 Willamette (1798 MHz)",19,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (851 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (1526 MHz)",19,0.00% "Intel Pentium 4 Northwood (2803 MHz)",19,0.00% "AMD K7 (Unknown model) (1347 MHz)",19,0.00% "AMD K7 (Unknown model) (530 MHz)",19,0.00% "AMD (Unknown model) (2019 MHz)",19,0.00% "Intel Pentium 4 (Unknown model) (2807 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (3199 MHz)",19,0.00% "Intel Pentium 4 (Unknown model) (2839 MHz)",19,0.00% "AMD (Unknown model) (1401 MHz)",19,0.00% "Intel Pentium 4 Northwood (2388 MHz)",19,0.00% "Intel Pentium 4 Willamette (A-Step) (1703 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (927 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (2800 MHz)",19,0.00% "Intel Pentium Pro (Unknown model) (1665 MHz)",18,0.00% "Intel Pentium 4 Northwood Xeon (1593 MHz)",18,0.00% "AMD (Unknown model) (1818 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (1099 MHz)",18,0.00% "AMD (Unknown model) (2222 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (2100 MHz)",18,0.00% "AMD K7 (Unknown model) (1247 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (891 MHz)",18,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1109 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (3001 MHz)",18,0.00% "Intel Pentium 4 (Unknown model) (2995 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (1194 MHz)",18,0.00% "Intel Pentium 4 Willamette (1899 MHz)",18,0.00% "Intel Pentium 4 (Unknown model) (2406 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (1686 MHz)",18,0.00% "Intel Pentium 4 (Unknown model) (2262 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (929 MHz)",18,0.00% "Intel Pentium 4 Northwood Xeon (1999 MHz)",18,0.00% "AMD (Unknown model) (2001 MHz)",18,0.00% "Intel Pentium 4 (Unknown model) (3724 MHz)",18,0.00% "Intel Pentium 4 Northwood (2492 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (848 MHz)",18,0.00% "AMD K7 (Unknown model) (2105 MHz)",18,0.00% "Intel Pentium 4 Willamette (1804 MHz)",18,0.00% "AMD (Unknown model) (2519 MHz)",18,0.00% "Intel Pentium 4 Willamette (A-Step) (1715 MHz)",18,0.00% "AMD (Unknown model) (1759 MHz)",18,0.00% "AMD K7 (Unknown model) (1362 MHz)",18,0.00% "Intel Pentium 4 Northwood Xeon (1590 MHz)",18,0.00% "AMD K7 (Unknown model) (1838 MHz)",18,0.00% "AMD K7 (Unknown model) (1506 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (1067 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (793 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (1627 MHz)",18,0.00% "Intel Pentium 4 Northwood (3194 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (839 MHz)",18,0.00% "AMD Athlon (Thunderbird core) (1401 MHz)",18,0.00% "AMD K7 (Unknown model) (2073 MHz)",18,0.00% "AMD Athlon (Thunderbird core) (1210 MHz)",18,0.00% "AMD Athlon (Thunderbird core) (1343 MHz)",18,0.00% "AMD K7 (Unknown model) (1399 MHz)",18,0.00% "Intel Pentium 4 Willamette Xeon (1804 MHz)",18,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1405 MHz)",18,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1243 MHz)",18,0.00% "AMD Duron (Spitfire core) (851 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (1865 MHz)",18,0.00% "Intel Pentium Pro (Unknown model) (835 MHz)",18,0.00% "Intel Pentium 4 Willamette (A-Step) (1680 MHz)",18,0.00% "Intel Pentium 4 (Unknown model) (2948 MHz)",18,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (698 MHz)",18,0.00% "Intel Pentium 4 (Unknown model) (3813 MHz)",18,0.00% "AMD K7 (Unknown model) (1809 MHz)",18,0.00% "AMD K7 (Unknown model) (1907 MHz)",18,0.00% "Intel Pentium 4 Northwood (2671 MHz)",18,0.00% "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (863 MHz)",18,0.00% "AMD K7 (Unknown model) (1523 MHz)",17,0.00% "AMD K7 (Unknown model) (1824 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (846 MHz)",17,0.00% "AMD K7 (Unknown model) (1099 MHz)",17,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (1001 MHz)",17,0.00% "AMD K7 (Unknown model) (2078 MHz)",17,0.00% "AMD (Unknown model) (1760 MHz)",17,0.00% "AMD K7 (Unknown model) (2188 MHz)",17,0.00% "AMD (Unknown model) (2024 MHz)",17,0.00% "AMD K7 (Unknown model) (1675 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (984 MHz)",17,0.00% "Intel Pentium 4 Northwood (3080 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (1832 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (1726 MHz)",17,0.00% "Intel Pentium 4 Willamette (A-Step) (1699 MHz)",17,0.00% "AMD (Unknown model) (1806 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (1420 MHz)",17,0.00% "Intel Pentium 4 Northwood (2756 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (1065 MHz)",17,0.00% "Intel Pentium 4 (Unknown model) (3231 MHz)",17,0.00% "Intel Pentium 4 Northwood (3458 MHz)",17,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1194 MHz)",17,0.00% "Intel Pentium 4 (Unknown model) (2852 MHz)",17,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (733 MHz)",17,0.00% "AMD K7 (Unknown model) (2190 MHz)",17,0.00% "Intel Pentium 4 Northwood (2197 MHz)",17,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1735 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (1607 MHz)",17,0.00% "AMD (Unknown model) (1944 MHz)",17,0.00% "Intel Pentium 4 Northwood (2289 MHz)",17,0.00% "AMD (Unknown model) (2159 MHz)",17,0.00% "AMD Mobile Duron (Morgan core) (1312 MHz)",17,0.00% "Intel Pentium 4 Willamette (1514 MHz)",17,0.00% "Intel Pentium 4 Northwood (2530 MHz)",17,0.00% "Intel Pentium 4 Northwood (2826 MHz)",17,0.00% "AMD (Unknown model) (2265 MHz)",17,0.00% "AMD Mobile Duron (Morgan core) (1299 MHz)",17,0.00% "AMD K7 (Unknown model) (1763 MHz)",17,0.00% "Intel Pentium 4 (Unknown model) (3313 MHz)",17,0.00% "AMD K7 (Unknown model) (2305 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (1527 MHz)",17,0.00% "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (497 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (988 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (983 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (926 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (2411 MHz)",17,0.00% "Intel Pentium 4 Willamette (1797 MHz)",17,0.00% "Intel Pentium 4 Northwood (2014 MHz)",17,0.00% "Intel Celeron (0.18 micron process) with internal L2 cache (902 MHz)",17,0.00% "Intel Pentium 4 (Unknown model) (2756 MHz)",17,0.00% "Intel Pentium 4 Northwood (2300 MHz)",17,0.00% "Intel Pentium 4 Northwood (2755 MHz)",17,0.00% "AMD Athlon (Thunderbird core) (902 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (1068 MHz)",17,0.00% "Intel Pentium Pro (Unknown model) (1214 MHz)",17,0.00% "AMD (Unknown model) (1845 MHz)",17,0.00% "AMD K7 (Unknown model) (1861 MHz)",17,0.00% "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1063 MHz)",17,0.00% "AMD (Unknown model) (2288 MHz)",17,0.00% "AMD Mobile Duron (Morgan core) (1100 MHz)",17,0.00% "Intel Pentium 4 Northwood (2498 MHz)",17,0.00% "Intel Pentium 4 Northwood (2676 MHz)",17,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (931 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1142 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1213 MHz)",16,0.00% "AMD K7 (Unknown model) (1678 MHz)",16,0.00% "AMD K7 (Unknown model) (1052 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (2164 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (990 MHz)",16,0.00% "Intel Pentium 4 Northwood Xeon (1193 MHz)",16,0.00% "AMD K7 (Unknown model) (1144 MHz)",16,0.00% "Intel Pentium 4 (Unknown model) (3519 MHz)",16,0.00% "AMD Duron (Spitfire core) (797 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1139 MHz)",16,0.00% "Intel Pentium 4 Northwood Xeon (2298 MHz)",16,0.00% "Intel Pentium 4 Willamette (A-Step) (1600 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1317 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1227 MHz)",16,0.00% "Intel Pentium 4 Northwood (3007 MHz)",16,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1248 MHz)",16,0.00% "Intel Pentium 4 Northwood (1302 MHz)",16,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1691 MHz)",16,0.00% "Intel Pentium 4 Northwood (1813 MHz)",16,0.00% "Intel Pentium 4 Northwood (2611 MHz)",16,0.00% "AMD K7 (Unknown model) (1363 MHz)",16,0.00% "Intel Pentium 4 Northwood (2472 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1424 MHz)",16,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1731 MHz)",16,0.00% "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (551 MHz)",16,0.00% "Intel Pentium 4 Willamette (1598 MHz)",16,0.00% "AMD (Unknown model) (2255 MHz)",16,0.00% "Intel Pentium 4 (Unknown model) (2556 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (885 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (610 MHz)",16,0.00% "AMD K7 (Unknown model) (796 MHz)",16,0.00% "AMD K7 (Unknown model) (1477 MHz)",16,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (736 MHz)",16,0.00% "Intel Pentium 4 (Unknown model) (3459 MHz)",16,0.00% "AMD K7 (Unknown model) (1741 MHz)",16,0.00% "Intel Pentium 4 Northwood (1807 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1405 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (608 MHz)",16,0.00% "Intel Pentium 4 Northwood (2606 MHz)",16,0.00% "AMD K7 (Unknown model) (2109 MHz)",16,0.00% "AMD Mobile Duron (Morgan core) (1297 MHz)",16,0.00% "Intel Pentium 4 (Unknown model) (3397 MHz)",16,0.00% "Intel Pentium 4 (Unknown model) (3053 MHz)",16,0.00% "Intel Pentium 4 (Unknown model) (2683 MHz)",16,0.00% "AMD Athlon (Thunderbird core) (1208 MHz)",16,0.00% "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1129 MHz)",16,0.00% "Intel Celeron (0.18 micron process) with internal L2 cache (1002 MHz)",16,0.00% "Intel Pentium 4 Northwood Xeon (1789 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1605 MHz)",16,0.00% "Intel Pentium 4 Northwood (3028 MHz)",16,0.00% "AMD (Unknown model) (2050 MHz)",16,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1210 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (836 MHz)",16,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1401 MHz)",16,0.00% "AMD (Unknown model) (2022 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1140 MHz)",16,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1601 MHz)",16,0.00% "AMD K7 (Unknown model) (1960 MHz)",16,0.00% "Intel Pentium Pro (Unknown model) (1587 MHz)",16,0.00% "Intel Pentium 4 Northwood (2786 MHz)",16,0.00% "AMD Mobile Duron (Morgan core) (1199 MHz)",15,0.00% "Intel Pentium 4 Willamette (A-Step) (1506 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1058 MHz)",15,0.00% "AMD (Unknown model) (2471 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1528 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (847 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (851 MHz)",15,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1730 MHz)",15,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (870 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (2999 MHz)",15,0.00% "AMD K7 (Unknown model) (1393 MHz)",15,0.00% "Intel Pentium 4 (Unknown model) (2130 MHz)",15,0.00% "Dual PowerPC 7400 (533 MHz)",15,0.00% "AMD Duron (Spitfire core) (892 MHz)",15,0.00% "AMD Duron (Spitfire core) (751 MHz)",15,0.00% "AMD K7 (Unknown model) (1488 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1523 MHz)",15,0.00% "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (398 MHz)",15,0.00% "Intel Pentium 4 (Unknown model) (3615 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1309 MHz)",15,0.00% "Intel Pentium 4 Northwood (1791 MHz)",15,0.00% "Intel Pentium 4 (Unknown model) (2815 MHz)",15,0.00% "AMD K7 (Unknown model) (1255 MHz)",15,0.00% "Intel Pentium 4 (Unknown model) (3306 MHz)",15,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1611 MHz)",15,0.00% "AMD (Unknown model) (2860 MHz)",15,0.00% "Intel Pentium 4 Northwood (1892 MHz)",15,0.00% "Intel Pentium 4 Northwood (2856 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1141 MHz)",15,0.00% "AMD K7 (Unknown model) (1463 MHz)",15,0.00% "AMD Athlon (Thunderbird core) (1311 MHz)",15,0.00% "Intel Pentium 4 (Unknown model) (3208 MHz)",15,0.00% "AMD Athlon (Thunderbird core) (1009 MHz)",15,0.00% "Intel Pentium 4 (Unknown model) (3218 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (2669 MHz)",15,0.00% "AMD K7 (Unknown model) (2255 MHz)",15,0.00% "Intel Pentium 4 Willamette (A-Step) (1599 MHz)",15,0.00% "AMD K7 (Unknown model) (1813 MHz)",15,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (737 MHz)",15,0.00% "AMD K7 (Unknown model) (1149 MHz)",15,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1249 MHz)",15,0.00% "AMD (Unknown model) (2639 MHz)",15,0.00% "AMD (Unknown model) (2730 MHz)",15,0.00% "Intel Pentium 4 Northwood Xeon (3057 MHz)",15,0.00% "AMD (Unknown model) (1851 MHz)",15,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1102 MHz)",15,0.00% "AMD K7 (Unknown model) (1854 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1421 MHz)",15,0.00% "AMD K7 (Unknown model) (2231 MHz)",15,0.00% "Intel Pentium 4 Northwood (3416 MHz)",15,0.00% "Intel Celeron (0.18 micron process) with internal L2 cache (797 MHz)",15,0.00% "Intel Pentium 4 Northwood (2953 MHz)",15,0.00% "AMD Athlon (Thunderbird core) (1007 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (930 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1603 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1725 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1290 MHz)",15,0.00% "AMD K7 (Unknown model) (1472 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1406 MHz)",15,0.00% "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (448 MHz)",15,0.00% "Intel Pentium 4 Northwood (2713 MHz)",15,0.00% "Intel Pentium Pro (Unknown model) (1530 MHz)",15,0.00% "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1302 MHz)",15,0.00% "Intel Pentium 4 (Unknown model) (2520 MHz)",14,0.00% "Intel Pentium 4 (Unknown model) (2804 MHz)",14,0.00% "PowerPC 7450 (1800 MHz)",14,0.00% "Intel Pentium 4 Northwood Xeon (1792 MHz)",14,0.00% "Intel Pentium 4 Northwood (3060 MHz)",14,0.00% "Intel Pentium 4 Willamette (A-Step) (1406 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (1601 MHz)",14,0.00% "Intel Pentium 4 Northwood (3210 MHz)",14,0.00% "Intel Pentium 4 Willamette (A-Step) (1695 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (419 MHz)",14,0.00% "AMD K7 (Unknown model) (1457 MHz)",14,0.00% "AMD (Unknown model) (1601 MHz)",14,0.00% "AMD K7 (Unknown model) (1160 MHz)",14,0.00% "Intel Pentium 4 Northwood (2264 MHz)",14,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1597 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (2995 MHz)",14,0.00% "AMD (Unknown model) (2603 MHz)",14,0.00% "Intel Pentium 4 Northwood (2299 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (611 MHz)",14,0.00% "Intel Pentium 4 Northwood (2586 MHz)",14,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1525 MHz)",14,0.00% "AMD (Unknown model) (1805 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (1415 MHz)",14,0.00% "Intel Pentium 4 (Unknown model) (3468 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (2009 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (1316 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (1425 MHz)",14,0.00% "AMD K7 (Unknown model) (1540 MHz)",14,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1603 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (987 MHz)",14,0.00% "AMD Athlon (Thunderbird core) (850 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (459 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (1232 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (422 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (1529 MHz)",14,0.00% "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1392 MHz)",14,0.00% "Intel Pentium III (0.18 micron process) with internal L2 cache (598 MHz)",14,0.00% "Intel Pentium 4 Northwood (2100 MHz)",14,0.00% "AMD K7 (Unknown model) (1419 MHz)",14,0.00% "Intel Pentium 4 (Unknown model) (2410 MHz)",14,0.00% "AMD (Unknown model) (2430 MHz)",14,0.00% "AMD Athlon MP/Mobile Athlon (Palomino core) (1161 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (2134 MHz)",14,0.00% "Intel Pentium Pro (Unknown model) (2176 MHz)",14,0.00% "Intel Pentium 4 Northwood (2794 MHz)",14,0.00% "Intel Pentium 4 Northwood (2542 MHz)",14,0.00% "Intel Celeron (0.18 micron process) with internal L2 cache (701 MHz)",14,0.00% "AMD Duron (Spitfire core) (896 MHz)",14,0.00% "Intel Pentium 4 Northwood Xeon (3065 MHz)",14,0.00% "Intel Pentium 4 Northwood (3095 MHz)",14, "Intel Pentium 4 Northwood (3075 MHz)",14, "AMD K7 (Unknown model) (1539 MHz)",14, "Intel Pentium 4 Willamette (1498 MHz)",14, "Intel Pentium 4 Northwood (2880 MHz)",14, "AMD K7 (Unknown model) (1748 MHz)",14, "AMD (Unknown model) (2191 MHz)",14, "AMD (Unknown model) (2213 MHz)",14, "Intel Pentium 4 Willamette (A-Step) (1697 MHz)",14, "Intel Pentium 4 (Unknown model) (2339 MHz)",14, "AMD (Unknown model) (2407 MHz)",14, "Intel Pentium Pro (Unknown model) (1308 MHz)",14, "Intel Pentium 4 Northwood Xeon (1894 MHz)",14, "Intel Pentium Pro (Unknown model) (1494 MHz)",14, "Intel Pentium Pro (Unknown model) (1641 MHz)",14, "Intel Pentium Pro (Unknown model) (1145 MHz)",14, "AMD Athlon MP/Mobile Athlon (Palomino core) (1740 MHz)",14, "Intel Celeron (0.18 micron process) with internal L2 cache (801 MHz)",14, "Intel Pentium Pro (Unknown model) (1404 MHz)",14, "Intel Pentium Pro (Unknown model) (1070 MHz)",14, "Intel Pentium Pro (Unknown model) (1703 MHz)",14, "AMD K7 (Unknown model) (1752 MHz)",13, "Intel Pentium Pro (Unknown model) (2341 MHz)",13, "AMD Athlon (Thunderbird core) (1109 MHz)",13, "AMD Athlon MP/Mobile Athlon (Palomino core) (1540 MHz)",13, "Intel Pentium 4 Northwood (2859 MHz)",13, "AMD Athlon MP/Mobile Athlon (Palomino core) (1732 MHz)",13, "AMD K7 (Unknown model) (1929 MHz)",13, "AMD Mobile Duron (Morgan core) (1102 MHz)",13, "Intel Pentium Pro (Unknown model) (1622 MHz)",13, "AMD (Unknown model) (1679 MHz)",13, "Intel Pentium Pro (Unknown model) (2098 MHz)",13, "Intel Pentium 4 (Unknown model) (3187 MHz)",13, "AMD K7 (Unknown model) (2144 MHz)",13, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1193 MHz)",13, "Intel Pentium 4 Northwood (2809 MHz)",13, "AMD (Unknown model) (2401 MHz)",13, "AMD K7 (Unknown model) (1397 MHz)",13, "AMD K7 (Unknown model) (2076 MHz)",13, "AMD Duron (Spitfire core) (756 MHz)",13, "Intel Pentium 4 Northwood Xeon (2405 MHz)",13, "AMD (Unknown model) (1895 MHz)",13, "Intel Pentium 4 (Unknown model) (3395 MHz)",13, "Intel Pentium 4 (Unknown model) (2404 MHz)",13, "Intel Pentium 4 Northwood (2418 MHz)",13, "Intel Pentium Pro (Unknown model) (1419 MHz)",13, "Intel Pentium 4 Northwood Xeon (2658 MHz)",13, "Intel Pentium 4 Northwood (2704 MHz)",13, "Intel Pentium 4 Willamette (A-Step) (1707 MHz)",13, "PowerPC 7400 (533 MHz)",13, "Intel Pentium 4 (Unknown model) (3672 MHz)",13, "AMD K7 (Unknown model) (1912 MHz)",13, "Intel Pentium Pro (Unknown model) (1147 MHz)",13, "Intel Pentium III (0.18 micron process) with internal L2 cache (938 MHz)",13, "Intel Pentium 4 Northwood Xeon (1599 MHz)",13, "Intel Pentium 4 Northwood (3245 MHz)",13, "Intel Celeron (0.18 micron process) with internal L2 cache (1102 MHz)",13, "Intel Pentium Pro (Unknown model) (850 MHz)",13, "Intel Pentium Pro (Unknown model) (1228 MHz)",13, "AMD K7 (Unknown model) (1725 MHz)",13, "AMD K7 (Unknown model) (2161 MHz)",13, "Intel Pentium Pro (Unknown model) (1073 MHz)",13, "Intel Pentium Pro (Unknown model) (1304 MHz)",13, "AMD Mobile Duron (Morgan core) (1311 MHz)",13, "AMD K7 (Unknown model) (1403 MHz)",13, "AMD K7 (Unknown model) (1104 MHz)",13, "AMD Athlon MP/Mobile Athlon (Palomino core) (1463 MHz)",13, "Intel Pentium 4 Willamette (1611 MHz)",13, "AMD K7 (Unknown model) (1586 MHz)",13, "AMD K7 (Unknown model) (908 MHz)",13, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1196 MHz)",13, "AMD K7 (Unknown model) (1211 MHz)",13, "Intel Pentium Pro (Unknown model) (896 MHz)",13, "Intel Pentium Pro (Unknown model) (994 MHz)",13, "Intel Pentium 4 Northwood Xeon (1991 MHz)",13, "AMD Duron (Spitfire core) (908 MHz)",13, "Intel Pentium Pro (Unknown model) (1626 MHz)",13, "AMD Athlon MP/Mobile Athlon (Palomino core) (1327 MHz)",13, "Intel Pentium Pro (Unknown model) (1144 MHz)",13, "AMD Athlon (Thunderbird core) (807 MHz)",13, "Intel Pentium 4 Northwood (2639 MHz)",13, "AMD K7 (Unknown model) (1691 MHz)",13, "Dual PowerPC 7450 (1800 MHz)",13, "AMD (Unknown model) (1648 MHz)",13, "AMD (Unknown model) (2592 MHz)",12, "AMD Athlon MP/Mobile Athlon (Palomino core) (1148 MHz)",12, "Intel Pentium Pro (Unknown model) (1306 MHz)",12, "Intel Pentium 4 Northwood (2689 MHz)",12, "Intel Pentium Pro (Unknown model) (1052 MHz)",12, "Intel Pentium 4 Northwood (2729 MHz)",12, "Intel Pentium 4 Northwood (2646 MHz)",12, "Intel Pentium Pro (Unknown model) (1522 MHz)",12, "Intel Pentium Pro (Unknown model) (932 MHz)",12, "AMD (Unknown model) (2505 MHz)",12, "AMD (Unknown model) (796 MHz)",12, "Intel Pentium 4 (Unknown model) (3405 MHz)",12, "Intel Pentium 4 Northwood (2403 MHz)",12, "Intel Pentium Pro (Unknown model) (890 MHz)",12, "Intel Pentium Pro (Unknown model) (1625 MHz)",12, "Intel Pentium 4 Willamette Xeon (1702 MHz)",12, "AMD Athlon (Thunderbird core) (1327 MHz)",12, "AMD (Unknown model) (1200 MHz)",12, "AMD (Unknown model) (2450 MHz)",12, "AMD Athlon (Thunderbird core) (899 MHz)",12, "Intel Pentium Pro (Unknown model) (3600 MHz)",12, "AMD Athlon (Thunderbird core) (1060 MHz)",12, "Intel Pentium Pro (Unknown model) (2165 MHz)",12, "AMD K7 (Unknown model) (1892 MHz)",12, "Intel Pentium Pro (Unknown model) (612 MHz)",12, "Intel Pentium Pro (Unknown model) (1531 MHz)",12, "Intel Pentium Pro (Unknown model) (2398 MHz)",12, "Intel Pentium 4 Northwood Xeon (1992 MHz)",12, "AMD K7 (Unknown model) (400 MHz)",12, "Intel Pentium 4 Northwood Xeon (1898 MHz)",12, "Intel Pentium 4 Northwood Xeon (2799 MHz)",12, "AMD (Unknown model) (2207 MHz)",12, "Intel Pentium 4 (Unknown model) (2699 MHz)",12, "AMD Duron (Spitfire core) (807 MHz)",12, "AMD K7 (Unknown model) (1398 MHz)",12, "Intel Pentium 4 Northwood Xeon (1799 MHz)",12, "Intel Pentium 4 (Unknown model) (3078 MHz)",12, "Intel Pentium 4 Northwood (2834 MHz)",12, "Intel Pentium 4 (Unknown model) (2728 MHz)",12, "AMD K7 (Unknown model) (1004 MHz)",12, "AMD K7 (Unknown model) (1009 MHz)",12, "Intel Pentium III (0.18 micron process) with internal L2 cache (871 MHz)",12, "AMD K7 (Unknown model) (1677 MHz)",12, "Intel Pentium III (0.18 micron process) with internal L2 cache (1003 MHz)",12, "Intel Celeron (0.18 micron process) with internal L2 cache (697 MHz)",12, "Intel Pentium Pro (Unknown model) (910 MHz)",12, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (930 MHz)",12, "Intel Pentium 4 (Unknown model) (3527 MHz)",12, "AMD (Unknown model) (1847 MHz)",12, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (547 MHz)",12, "Intel Pentium 4 Northwood (1603 MHz)",12, "AMD K7 (Unknown model) (1726 MHz)",12, "AMD (Unknown model) (2224 MHz)",12, "Intel Pentium 4 Northwood (1803 MHz)",12, "AMD Athlon MP/Mobile Athlon (Palomino core) (1596 MHz)",12, "AMD (Unknown model) (1850 MHz)",12, "Intel Pentium Pro (Unknown model) (1521 MHz)",12, "AMD (Unknown model) (1007 MHz)",12, "AMD K7 (Unknown model) (1109 MHz)",12, "Intel Pentium Pro (Unknown model) (1931 MHz)",12, "AMD K7 (Unknown model) (1535 MHz)",12, "Intel Pentium 4 (Unknown model) (1500 MHz)",12, "AMD K7 (Unknown model) (1299 MHz)",12, "Intel Pentium Pro (Unknown model) (1624 MHz)",12, "AMD K7 (Unknown model) (2210 MHz)",12, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (498 MHz)",12, "Intel Pentium 4 (Unknown model) (2263 MHz)",12, "Intel Pentium Pro (Unknown model) (1659 MHz)",12, "AMD Mobile Duron (Morgan core) (1293 MHz)",12, "AMD (Unknown model) (2808 MHz)",12, "Intel Pentium 4 (Unknown model) (2143 MHz)",12, "AMD (Unknown model) (2750 MHz)",12, "Intel Pentium 4 Willamette (2008 MHz)",12, "AMD (Unknown model) (2340 MHz)",12, "Intel Pentium III (0.18 micron process) with internal L2 cache (998 MHz)",12, "Intel Pentium Pro (Unknown model) (460 MHz)",12, "Intel Pentium 4 (Unknown model) (3332 MHz)",11, "Intel Pentium 4 Willamette (2004 MHz)",11, "AMD Duron (Spitfire core) (945 MHz)",11, "Intel Pentium 4 Northwood Xeon (1395 MHz)",11, "Intel Pentium 4 (Unknown model) (2129 MHz)",11, "AMD (Unknown model) (2435 MHz)",11, "Intel Pentium 4 Northwood Xeon (2492 MHz)",11, "AMD (Unknown model) (2442 MHz)",11, "Intel Pentium 4 Northwood Xeon (2592 MHz)",11, "AMD (Unknown model) (2699 MHz)",11, "Intel Pentium Pro (Unknown model) (1303 MHz)",11, "Intel Pentium 4 (Unknown model) (2943 MHz)",11, "AMD Athlon (Thunderbird core) (750 MHz)",11, "Intel Pentium Pro (Unknown model) (887 MHz)",11, "Intel Pentium 4 Northwood (1998 MHz)",11, "AMD (Unknown model) (1952 MHz)",11, "AMD K7 (Unknown model) (1692 MHz)",11, "Intel Pentium 4 (Unknown model) (3206 MHz)",11, "AMD (Unknown model) (2215 MHz)",11, "Intel Pentium 4 Willamette Xeon (1796 MHz)",11, "Intel Pentium Pro (Unknown model) (1072 MHz)",11, "AMD K7 (Unknown model) (1724 MHz)",11, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1102 MHz)",11, "Intel Pentium 4 (Unknown model) (3052 MHz)",11, "Intel Pentium 4 (Unknown model) (2124 MHz)",11, "Intel Pentium Pro (Unknown model) (1373 MHz)",11, "AMD K7 (Unknown model) (797 MHz)",11, "AMD Athlon MP/Mobile Athlon (Palomino core) (1048 MHz)",11, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1133 MHz)",11, "AMD (Unknown model) (2221 MHz)",11, "Intel Pentium Pro (Unknown model) (1002 MHz)",11, "Intel Pentium 4 Northwood (2220 MHz)",11, "Intel Pentium 4 Northwood Xeon (1804 MHz)",11, "AMD (Unknown model) (2608 MHz)",11, "Intel Pentium 4 Northwood (2447 MHz)",11, "Intel Pentium Pro (Unknown model) (1190 MHz)",11, "AMD Athlon MP/Mobile Athlon (Palomino core) (1592 MHz)",11, "Intel Pentium Pro (Unknown model) (1671 MHz)",11, "AMD (Unknown model) (2293 MHz)",11, "Intel Pentium 4 Northwood (1808 MHz)",11, "Intel Pentium Pro (Unknown model) (854 MHz)",11, "Intel Pentium 4 Northwood (2531 MHz)",11, "AMD Mobile Duron (Morgan core) (1210 MHz)",11, "Intel Pentium 4 (Unknown model) (3445 MHz)",11, "AMD K7 (Unknown model) (1266 MHz)",11, "Intel Pentium 4 Northwood (1597 MHz)",11, "AMD K7 (Unknown model) (1336 MHz)",11, "AMD Athlon MP/Mobile Athlon (Palomino core) (1467 MHz)",11, "Intel Pentium 4 Willamette (1994 MHz)",11, "AMD K7 (Unknown model) (1098 MHz)",11, "AMD K7 (Unknown model) (2180 MHz)",11, "Intel Pentium 4 Northwood Xeon (2198 MHz)",11, "AMD (Unknown model) (1811 MHz)",11, "Intel Pentium 4 Northwood (2585 MHz)",11, "Intel Pentium Pro (Unknown model) (1792 MHz)",11, "Intel Pentium III (0.18 micron process) with internal L2 cache (1096 MHz)",11, "Intel Pentium 4 (Unknown model) (2523 MHz)",11, "Intel Pentium Pro (Unknown model) (2640 MHz)",11, "AMD K7 (Unknown model) (1729 MHz)",11, "AMD K7 (Unknown model) (1922 MHz)",11, "AMD (Unknown model) (1798 MHz)",11, "AMD Athlon MP/Mobile Athlon (Palomino core) (1110 MHz)",11, "Intel Pentium Pro (Unknown model) (1623 MHz)",11, "Intel Celeron (0.18 micron process) with internal L2 cache (996 MHz)",11, "AMD K7 (Unknown model) (1650 MHz)",11, "AMD K7 (Unknown model) (2096 MHz)",11, "Intel Pentium Pro (Unknown model) (1734 MHz)",11, "AMD K7 (Unknown model) (2290 MHz)",11, "Intel Pentium 4 Northwood (2190 MHz)",11, "AMD Athlon MP/Mobile Athlon (Palomino core) (1393 MHz)",11, "AMD (Unknown model) (1792 MHz)",11, "Intel Pentium Pro (Unknown model) (933 MHz)",11, "Intel Pentium 4 (Unknown model) (2827 MHz)",11, "AMD Athlon MP/Mobile Athlon (Palomino core) (1734 MHz)",11, "Intel Pentium 4 Northwood (1990 MHz)",11, "AMD K7 (Unknown model) (1148 MHz)",11, "AMD K7 (Unknown model) (2021 MHz)",11, "Intel Pentium Pro (Unknown model) (1322 MHz)",11, "Intel Pentium Pro (Unknown model) (2938 MHz)",11, "Intel Pentium 4 Northwood (2815 MHz)",11, "AMD (Unknown model) (2593 MHz)",11, "Intel Pentium Pro (Unknown model) (852 MHz)",11, "Intel Pentium 4 Northwood Xeon (3058 MHz)",11, "AMD (Unknown model) (2940 MHz)",10, "Intel Pentium Pro (Unknown model) (1233 MHz)",10, "Intel Pentium Pro (Unknown model) (1324 MHz)",10, "Intel Pentium 4 Northwood (1503 MHz)",10, "Intel Pentium 4 (Unknown model) (2541 MHz)",10, "Intel Celeron (0.18 micron process) with internal L2 cache (1009 MHz)",10, "Intel Pentium 4 (Unknown model) (2805 MHz)",10, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1266 MHz)",10, "Intel Pentium Pro (Unknown model) (2639 MHz)",10, "Intel Pentium 4 (Unknown model) (3733 MHz)",10, "Intel Pentium 4 Northwood (2686 MHz)",10, "AMD K7 (Unknown model) (2193 MHz)",10, "Intel Pentium Pro (Unknown model) (2007 MHz)",10, "AMD Athlon MP/Mobile Athlon (Palomino core) (1468 MHz)",10, "Intel Pentium Pro (Unknown model) (1692 MHz)",10, "Intel Pentium 4 Northwood (2020 MHz)",10, "AMD (Unknown model) (1021 MHz)",10, "Intel Pentium Pro (Unknown model) (1770 MHz)",10, "Intel Pentium 4 Northwood (2291 MHz)",10, "Intel Pentium Pro (Unknown model) (417 MHz)",10, "AMD (Unknown model) (2350 MHz)",10, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1302 MHz)",10, "Intel Pentium III (0.18 micron process) with internal L2 cache (666 MHz)",10, "Intel Pentium 4 (Unknown model) (2668 MHz)",10, "Intel Pentium 4 Northwood Xeon (1200 MHz)",10, "AMD Athlon MP/Mobile Athlon (Palomino core) (1329 MHz)",10, "AMD Duron (Spitfire core) (799 MHz)",10, "AMD K7 (Unknown model) (2101 MHz)",10, "Intel Pentium 4 Northwood (2557 MHz)",10, "Intel Pentium Pro (Unknown model) (1136 MHz)",10, "Intel Pentium Pro (Unknown model) (1428 MHz)",10, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (999 MHz)",10, "Intel Pentium Pro (Unknown model) (1403 MHz)",10, "Intel Pentium Pro (Unknown model) (3240 MHz)",10, "Intel Pentium Pro (Unknown model) (908 MHz)",10, "AMD Athlon (Thunderbird core) (1194 MHz)",10, "Intel Pentium 4 Northwood (2279 MHz)",10, "Intel Pentium Pro (Unknown model) (2703 MHz)",10, "Intel Pentium Pro (Unknown model) (1991 MHz)",10, "AMD K7 (Unknown model) (1205 MHz)",10, "AMD (Unknown model) (2223 MHz)",10, "AMD Mobile Duron (Morgan core) (1298 MHz)",10, "Intel Pentium Pro (Unknown model) (3149 MHz)",10, "Intel Pentium 4 Willamette (1995 MHz)",10, "Intel Pentium 4 Northwood Xeon (2372 MHz)",10, "Intel Pentium Pro (Unknown model) (1658 MHz)",10, "Intel Pentium Pro (Unknown model) (318 MHz)",10, "Intel Pentium 4 Northwood Xeon (1795 MHz)",10, "AMD (Unknown model) (1597 MHz)",10, "Intel Pentium 4 Northwood (3005 MHz)",10, "Intel Pentium 4 Northwood (2278 MHz)",10, "Intel Pentium 4 (Unknown model) (3221 MHz)",10, "Intel Pentium 4 Northwood Xeon (2159 MHz)",10, "Intel Pentium Pro (Unknown model) (2658 MHz)",10, "Intel Pentium Pro (Unknown model) (849 MHz)",10, "Intel Pentium Pro (Unknown model) (1323 MHz)",10, "Intel Pentium Pro (Unknown model) (3024 MHz)",10, "Intel Pentium 4 (Unknown model) (2924 MHz)",10, "Intel Pentium III (0.18 micron process) with internal L2 cache (648 MHz)",10, "Intel Pentium Pro (Unknown model) (912 MHz)",10, "AMD Athlon MP/Mobile Athlon (Palomino core) (1052 MHz)",10, "Intel Pentium III (0.18 micron process) with internal L2 cache (697 MHz)",10, "Intel Pentium Pro (Unknown model) (2799 MHz)",10, "AMD K7 (Unknown model) (2098 MHz)",10, "Intel Pentium 4 Northwood (3029 MHz)",10, "AMD (Unknown model) (2587 MHz)",10, "AMD Athlon MP/Mobile Athlon (Palomino core) (1149 MHz)",10, "Intel Pentium Pro (Unknown model) (1185 MHz)",10, "AMD K7 (Unknown model) (1514 MHz)",10, "Intel Pentium Pro (Unknown model) (869 MHz)",10, "Intel Pentium Pro (Unknown model) (1204 MHz)",10, "Intel Pentium Pro (Unknown model) (2130 MHz)",10, "Intel Pentium 4 (Unknown model) (2000 MHz)",10, "Intel Pentium 4 (Unknown model) (3080 MHz)",10, "AMD (Unknown model) (1839 MHz)",10, "AMD K7 (Unknown model) (1580 MHz)",10, "Intel Pentium 4 Northwood (3360 MHz)",10, "Intel Pentium 4 Northwood (2407 MHz)",10, "AMD K7 (Unknown model) (1949 MHz)",10, "Intel Pentium Pro (Unknown model) (1503 MHz)",10, "AMD (Unknown model) (1407 MHz)",10, "AMD K7 (Unknown model) (2070 MHz)",10, "AMD K7 (Unknown model) (2084 MHz)",10, "Intel Pentium 4 Willamette (1908 MHz)",10, "Intel Pentium Pro (Unknown model) (2699 MHz)",10, "AMD K7 (Unknown model) (1954 MHz)",10, "Intel Pentium Pro (Unknown model) (424 MHz)",10, "Intel Pentium 4 Willamette (1807 MHz)",10, "Intel Pentium 4 Northwood Xeon (2200 MHz)",10, "Intel Pentium 4 Northwood (2706 MHz)",10, "AMD (Unknown model) (2217 MHz)",10, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (451 MHz)",10, "AMD (Unknown model) (2070 MHz)",10, "Intel Pentium Pro (Unknown model) (1003 MHz)",10, "AMD K7 (Unknown model) (1161 MHz)",10, "Intel Pentium Pro (Unknown model) (1426 MHz)",10, "Intel Pentium Pro (Unknown model) (931 MHz)",10, "Intel Pentium 4 Northwood (2987 MHz)",10, "AMD Athlon MP/Mobile Athlon (Palomino core) (1406 MHz)",10, "Intel Pentium 4 Northwood (1593 MHz)",10, "AMD (Unknown model) (1592 MHz)",10, "Intel Pentium Pro (Unknown model) (461 MHz)",10, "AMD (Unknown model) (2496 MHz)",10, "Intel Pentium Pro (Unknown model) (420 MHz)",10, "AMD (Unknown model) (2220 MHz)",10, "AMD Athlon MP/Mobile Athlon (Palomino core) (1459 MHz)",10, "AMD (Unknown model) (2018 MHz)",10, "Intel Pentium 4 (Unknown model) (3386 MHz)",10, "AMD Athlon (Thunderbird core) (1045 MHz)",10, "Intel Pentium Pro (Unknown model) (789 MHz)",10, "Intel Pentium 4 Northwood Xeon (1596 MHz)",10, "AMD K7 (Unknown model) (1467 MHz)",10, "AMD K7 (Unknown model) (899 MHz)",10, "AMD Athlon (Thunderbird core) (756 MHz)",9, "Intel Pentium 4 Northwood (2326 MHz)",9, "AMD Athlon MP/Mobile Athlon (Palomino core) (1672 MHz)",9, "AMD (Unknown model) (1991 MHz)",9, "Intel Pentium Pro (Unknown model) (1960 MHz)",9, "AMD K7 (Unknown model) (600 MHz)",9, "AMD (Unknown model) (2475 MHz)",9, "AMD Athlon MP/Mobile Athlon (Palomino core) (1655 MHz)",9, "AMD K7 (Unknown model) (1048 MHz)",9, "AMD K7 (Unknown model) (1332 MHz)",9, "Intel Celeron (0.18 micron process) with internal L2 cache (1001 MHz)",9, "Intel Pentium 4 Northwood (2939 MHz)",9, "AMD Athlon (Thunderbird core) (1099 MHz)",9, "Intel Pentium 4 Willamette (1991 MHz)",9, "Intel Pentium Pro (Unknown model) (1408 MHz)",9, "Intel Pentium Pro (Unknown model) (2138 MHz)",9, "AMD Athlon MP/Mobile Athlon (Palomino core) (1332 MHz)",9, "Intel Pentium Pro (Unknown model) (1069 MHz)",9, "AMD (Unknown model) (2408 MHz)",9, "Intel Pentium Pro (Unknown model) (2010 MHz)",9, "Intel Pentium Pro (Unknown model) (3206 MHz)",9, "AMD (Unknown model) (2598 MHz)",9, "AMD (Unknown model) (2140 MHz)",9, "AMD K7 (Unknown model) (1805 MHz)",9, "Intel Pentium 4 (Unknown model) (3008 MHz)",9, "AMD (Unknown model) (2161 MHz)",9, "Intel Pentium Pro (Unknown model) (1602 MHz)",9, "Intel Pentium 4 (Unknown model) (3406 MHz)",9, "Intel Pentium 4 Northwood (2426 MHz)",9, "Intel Pentium 4 (Unknown model) (3235 MHz)",9, "AMD (Unknown model) (2409 MHz)",9, "AMD (Unknown model) (1789 MHz)",9, "AMD K7 (Unknown model) (1325 MHz)",9, "Intel Pentium Pro (Unknown model) (2243 MHz)",9, "Intel Pentium Pro (Unknown model) (1004 MHz)",9, "Intel Pentium Pro (Unknown model) (2520 MHz)",9, "Intel Pentium Pro (Unknown model) (860 MHz)",9, "Intel Pentium 4 Northwood (1989 MHz)",9, "AMD (Unknown model) (1934 MHz)",9, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (400 MHz)",9, "Intel Pentium Pro (Unknown model) (1362 MHz)",9, "AMD Mobile Duron (Morgan core) (1211 MHz)",9, "Unknown (1200 MHz)",9, "Intel Pentium Pro (Unknown model) (320 MHz)",9, "Intel Pentium Pro (Unknown model) (421 MHz)",9, "AMD K7 (Unknown model) (1343 MHz)",9, "AMD K7 (Unknown model) (1732 MHz)",9, "Intel Pentium 4 Northwood (2263 MHz)",9, "Intel Pentium Pro (Unknown model) (1053 MHz)",9, "Intel Pentium 4 (Unknown model) (1997 MHz)",9, "Intel Pentium 4 Northwood (2305 MHz)",9, "AMD (Unknown model) (2712 MHz)",9, "Intel Pentium Pro (Unknown model) (982 MHz)",9, "Intel Pentium Pro (Unknown model) (1640 MHz)",9, "Intel Pentium Pro (Unknown model) (1301 MHz)",9, "Intel Pentium Pro (Unknown model) (1292 MHz)",9, "Intel Pentium Pro (Unknown model) (853 MHz)",9, "AMD K7 (Unknown model) (1984 MHz)",9, "Intel Pentium Pro (Unknown model) (1280 MHz)",9, "Intel Pentium Pro (Unknown model) (1438 MHz)",9, "Intel Pentium Pro (Unknown model) (892 MHz)",9, "Intel Pentium 4 Willamette (1895 MHz)",9, "AMD Athlon (Thunderbird core) (951 MHz)",9, "AMD Athlon MP/Mobile Athlon (Palomino core) (1675 MHz)",9, "AMD Mobile Duron (Morgan core) (1198 MHz)",9, "AMD K7 (Unknown model) (1155 MHz)",9, "AMD Mobile Duron (Morgan core) (1197 MHz)",9, "AMD K7 (Unknown model) (1091 MHz)",9, "AMD K7 (Unknown model) (1290 MHz)",9, "AMD K7 (Unknown model) (1845 MHz)",9, "Intel Pentium 4 Willamette (A-Step) (1713 MHz)",9, "Intel Pentium Pro (Unknown model) (1318 MHz)",9, "Intel Pentium Pro (Unknown model) (986 MHz)",9, "Intel Pentium 4 (Unknown model) (3082 MHz)",9, "AMD Athlon MP/Mobile Athlon (Palomino core) (1098 MHz)",9, "Intel Pentium 4 Willamette (A-Step) (1384 MHz)",9, "Intel Pentium Pro (Unknown model) (458 MHz)",9, "Intel Pentium Pro (Unknown model) (827 MHz)",9, "Intel Pentium III (0.18 micron process) with internal L2 cache (734 MHz)",9, "AMD (Unknown model) (2678 MHz)",9, "Intel Pentium Pro (Unknown model) (805 MHz)",9, "Intel Pentium 4 (Unknown model) (3593 MHz)",9, "Intel Pentium 4 Willamette (A-Step) (1297 MHz)",9, "Intel Pentium 4 (Unknown model) (2837 MHz)",9, "Intel Pentium 4 (Unknown model) (3799 MHz)",9, "AMD (Unknown model) (995 MHz)",9, "Intel Pentium 4 Northwood Xeon (1800 MHz)",9, "Intel Pentium 4 (Unknown model) (3801 MHz)",9, "AMD (Unknown model) (2415 MHz)",9, "Intel Pentium Pro (Unknown model) (925 MHz)",9, "Intel Pentium III (0.18 micron process) with internal L2 cache (994 MHz)",9, "Intel Pentium 4 (Unknown model) (3033 MHz)",9, "Intel Pentium Pro (Unknown model) (804 MHz)",9, "Intel Pentium 4 (Unknown model) (2671 MHz)",9, "Intel Pentium 4 Northwood (2669 MHz)",9, "AMD Duron (Spitfire core) (944 MHz)",9, "Intel Pentium 4 Northwood Xeon (1199 MHz)",9, "AMD Athlon MP/Mobile Athlon (Palomino core) (1538 MHz)",9, "Intel Pentium Pro (Unknown model) (702 MHz)",9, "AMD (Unknown model) (2474 MHz)",9, "AMD (Unknown model) (1926 MHz)",9, "AMD (Unknown model) (1853 MHz)",9, "Intel Pentium Pro (Unknown model) (1015 MHz)",9, "Intel Pentium Pro (Unknown model) (1642 MHz)",9, "Intel Pentium 4 (Unknown model) (2132 MHz)",9, "PowerPC 7400 (500 MHz)",9, "Intel Pentium Pro (Unknown model) (1229 MHz)",9, "Intel Pentium Pro (Unknown model) (1628 MHz)",9, "Intel Pentium III (0.18 micron process) with internal L2 cache (1102 MHz)",9, "Intel Pentium 4 (Unknown model) (2544 MHz)",9, "Intel Pentium Pro (Unknown model) (1574 MHz)",9, "AMD Duron (Spitfire core) (850 MHz)",9, "Intel Pentium Pro (Unknown model) (863 MHz)",9, "Intel Pentium Pro (Unknown model) (934 MHz)",9, "Intel Pentium 4 Northwood Xeon (1192 MHz)",9, "Intel Pentium 4 Northwood (2670 MHz)",9, "Intel Pentium 4 Northwood (2387 MHz)",9, "AMD (Unknown model) (2280 MHz)",9, "Intel Pentium Pro (Unknown model) (2517 MHz)",9, "Intel Pentium 4 (Unknown model) (3667 MHz)",9, "Intel Pentium 4 (Unknown model) (3506 MHz)",9, "AMD (Unknown model) (2604 MHz)",9, "Intel Pentium 4 Northwood Xeon (2175 MHz)",9, "AMD (Unknown model) (1680 MHz)",9, "Intel Pentium 4 Willamette (2017 MHz)",9, "Intel Pentium 4 (Unknown model) (2542 MHz)",9, "Intel Pentium 4 Northwood (2645 MHz)",9, "Intel Pentium 4 Willamette (1607 MHz)",9, "Intel Pentium Pro (Unknown model) (1150 MHz)",9, "AMD (Unknown model) (1816 MHz)",9, "AMD (Unknown model) (1825 MHz)",9, "Intel Pentium Pro (Unknown model)",9, "AMD (Unknown model) (2362 MHz)",9, "Intel Pentium 4 Willamette (A-Step) (1413 MHz)",9, "Intel Pentium Pro (Unknown model) (1589 MHz)",9, "Intel Pentium Pro (Unknown model) (977 MHz)",9, "Intel Pentium Pro (Unknown model) (985 MHz)",9, "Unknown (1496 MHz)",9, "Intel Pentium 4 Northwood (2673 MHz)",9, "Intel Pentium Pro (Unknown model) (980 MHz)",9, "AMD K7 (Unknown model) (1329 MHz)",9, "AMD (Unknown model) (2165 MHz)",9, "Intel Pentium Pro (Unknown model) (776 MHz)",9, "AMD K7 (Unknown model) (2035 MHz)",8, "AMD (Unknown model) (2260 MHz)",8, "Intel Pentium Pro (Unknown model) (826 MHz)",8, "AMD K7 (Unknown model) (2300 MHz)",8, "Intel Pentium 4 Northwood (2816 MHz)",8, "Intel Pentium 4 Northwood (2565 MHz)",8, "AMD Athlon (Thunderbird core) (846 MHz)",8, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (449 MHz)",8, "Intel Pentium Pro (Unknown model) (1071 MHz)",8, "Intel Pentium Pro (Unknown model) (1535 MHz)",8, "AMD K7 (Unknown model) (1591 MHz)",8, "Intel Pentium 4 (Unknown model) (2700 MHz)",8, "AMD Duron (Spitfire core) (899 MHz)",8, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (447 MHz)",8, "Intel Pentium 4 Northwood Xeon (1698 MHz)",8, "AMD (Unknown model) (2449 MHz)",8, "Intel Pentium Pro (Unknown model) (1540 MHz)",8, "Intel Pentium 4 Willamette (A-Step) (1595 MHz)",8, "AMD K7 (Unknown model) (1537 MHz)",8, "Intel Pentium 4 Willamette (1796 MHz)",8, "AMD K7 (Unknown model) (2201 MHz)",8, "AMD (Unknown model) (2012 MHz)",8, "Intel Pentium Pro (Unknown model) (2996 MHz)",8, "Intel Pentium 4 (Unknown model) (3739 MHz)",8, "Intel Pentium 4 (Unknown model) (3616 MHz)",8, "AMD (Unknown model) (2497 MHz)",8, "Intel Celeron (0.18 micron process) with internal L2 cache (897 MHz)",8, "AMD Athlon MP/Mobile Athlon (Palomino core) (1461 MHz)",8, "Intel Pentium 4 Northwood (2819 MHz)",8, "Intel Pentium III (0.18 micron process) with internal L2 cache (929 MHz)",8, "Intel Pentium 4 Northwood (2855 MHz)",8, "AMD Athlon (Thunderbird core) (748 MHz)",8, "Intel Pentium 4 Northwood (2821 MHz)",8, "Intel Pentium 4 Northwood Xeon (2065 MHz)",8, "AMD K7 (Unknown model) (2129 MHz)",8, "AMD (Unknown model) (2414 MHz)",8, "Intel Pentium 4 (Unknown model) (3340 MHz)",8, "AMD K7 (Unknown model) (1049 MHz)",8, "Intel Pentium Pro (Unknown model) (1001 MHz)",8, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1126 MHz)",8, "AMD (Unknown model) (2295 MHz)",8, "Intel Pentium Pro (Unknown model) (1520 MHz)",8, "AMD (Unknown model) (1844 MHz)",8, "AMD K7 (Unknown model) (662 MHz)",8, "AMD K7 (Unknown model) (1841 MHz)",8, "Intel Pentium 4 Northwood Xeon (1791 MHz)",8, "Intel Pentium Pro (Unknown model) (1474 MHz)",8, "Intel Pentium 4 (Unknown model) (3003 MHz)",8, "AMD Athlon (Thunderbird core) (998 MHz)",8, "AMD K7 (Unknown model) (1061 MHz)",8, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (448 MHz)",8, "AMD (Unknown model) (2619 MHz)",8, "Intel Pentium Pro (Unknown model) (1469 MHz)",8, "AMD K7 (Unknown model) (1866 MHz)",8, "AMD (Unknown model) (1992 MHz)",8, "Intel Pentium Pro (Unknown model) (1057 MHz)",8, "Intel Pentium III (0.18 micron process) with internal L2 cache (869 MHz)",8, "Unknown (1499 MHz)",8, "Intel Pentium Pro (Unknown model) (1511 MHz)",8, "Intel Pentium 4 Northwood (2549 MHz)",8, "Intel Pentium 4 (Unknown model) (2525 MHz)",8, "AMD (Unknown model) (3014 MHz)",8, "AMD (Unknown model) (1919 MHz)",8, "Intel Pentium 4 (Unknown model) (3204 MHz)",8, "AMD (Unknown model) (2049 MHz)",8, "AMD K7 (Unknown model) (864 MHz)",8, "AMD (Unknown model) (2365 MHz)",8, "Intel Pentium Pro (Unknown model) (935 MHz)",8, "Intel Pentium Pro (Unknown model) (606 MHz)",8, "Intel Pentium Pro (Unknown model) (1302 MHz)",8, "Intel Pentium Pro (Unknown model) (2097 MHz)",8, "Intel Pentium Pro (Unknown model) (782 MHz)",8, "Intel Pentium 4 Northwood (2594 MHz)",8, "Intel Pentium Pro (Unknown model) (1412 MHz)",8, "Intel Pentium Pro (Unknown model) (2005 MHz)",8, "Intel Pentium Pro (Unknown model) (1442 MHz)",8, "AMD K7 (Unknown model) (1544 MHz)",8, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1200 MHz)",8, "Intel Pentium 4 Northwood (2210 MHz)",8, "Intel Pentium Pro (Unknown model) (1331 MHz)",8, "AMD (Unknown model) (1836 MHz)",8, "Intel Pentium Pro (Unknown model) (1230 MHz)",8, "Intel Pentium 4 Northwood Xeon (2256 MHz)",8, "Intel Pentium Pro (Unknown model) (1392 MHz)",8, "Intel Pentium Pro (Unknown model) (1368 MHz)",8, "AMD (Unknown model) (2011 MHz)",8, "Intel Pentium Pro (Unknown model) (616 MHz)",8, "AMD (Unknown model) (2460 MHz)",8, "Intel Pentium 4 (Unknown model) (3467 MHz)",8, "AMD K7 (Unknown model) (1894 MHz)",8, "AMD (Unknown model) (2062 MHz)",8, "Intel Pentium 4 (Unknown model) (3349 MHz)",8, "Intel Pentium 4 Willamette (1813 MHz)",8, "AMD K7 (Unknown model) (1703 MHz)",8, "Intel Pentium Pro (Unknown model) (1212 MHz)",8, "AMD Mobile Duron (Morgan core) (1295 MHz)",8, "Intel Pentium 4 Northwood (2632 MHz)",8, "Intel Pentium Pro (Unknown model) (1644 MHz)",8, "Intel Pentium Pro (Unknown model) (993 MHz)",8, "Intel Pentium Pro (Unknown model) (613 MHz)",8, "AMD K7 (Unknown model) (800 MHz)",8, "AMD (Unknown model) (2656 MHz)",8, "Intel Pentium Pro (Unknown model) (1148 MHz)",8, "Intel Pentium Pro (Unknown model) (660 MHz)",8, "PowerPC 7400 (350 MHz)",8, "Intel Pentium 4 Northwood (2040 MHz)",8, "Intel Pentium Pro (Unknown model) (1992 MHz)",8, "Intel Pentium 4 (Unknown model) (3465 MHz)",8, "AMD (Unknown model) (1862 MHz)",8, "Intel Pentium Pro (Unknown model) (1591 MHz)",8, "AMD (Unknown model) (1819 MHz)",8, "Intel Pentium Pro (Unknown model) (1014 MHz)",8, "AMD (Unknown model) (1857 MHz)",8, "Intel Pentium Pro (Unknown model) (856 MHz)",8, "Intel Pentium Pro (Unknown model) (795 MHz)",8, "AMD (Unknown model) (996 MHz)",8, "AMD K7 (Unknown model) (952 MHz)",8, "Intel Pentium Pro (Unknown model) (1903 MHz)",8, "Intel Pentium 4 Northwood (2448 MHz)",8, "Intel Pentium II with internal L2 cache (501 MHz)",8, "Intel Pentium Pro (Unknown model) (2637 MHz)",8, "AMD K7 (Unknown model) (1501 MHz)",8, "Intel Pentium 4 (Unknown model) (2802 MHz)",8, "Intel Pentium 4 Willamette (1712 MHz)",8, "AMD Athlon MP/Mobile Athlon (Palomino core) (1202 MHz)",8, "AMD K7 (Unknown model) (1814 MHz)",8, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (598 MHz)",8, "Intel Pentium 4 Northwood (2276 MHz)",8, "Intel Pentium 4 Northwood Xeon (1977 MHz)",8, "AMD (Unknown model) (2386 MHz)",8, "PowerPC 7450 (1466 MHz)",8, "Intel Pentium 4 (Unknown model) (2729 MHz)",8, "AMD (Unknown model) (2749 MHz)",8, "AMD K7 (Unknown model) (1857 MHz)",8, "AMD Athlon MP/Mobile Athlon (Palomino core) (995 MHz)",8, "Intel Pentium 4 (Unknown model) (3570 MHz)",8, "Intel Pentium 4 Willamette (1698 MHz)",8, "AMD K7 (Unknown model) (2159 MHz)",8, "AMD Athlon MP/Mobile Athlon (Palomino core) (1404 MHz)",8, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (350 MHz)",8, "Intel Pentium 4 Willamette (A-Step) (1497 MHz)",8, "Intel Pentium Pro (Unknown model) (2884 MHz)",8, "Intel Pentium 4 Northwood (2695 MHz)",8, "Intel Pentium 4 Northwood (2601 MHz)",8, "Intel Pentium Pro (Unknown model) (1552 MHz)",8, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1133 MHz)",8, "AMD (Unknown model) (2508 MHz)",8, "Intel Pentium 4 Northwood (1938 MHz)",8, "Intel Pentium 4 Northwood (2746 MHz)",8, "AMD (Unknown model) (2051 MHz)",8, "Intel Pentium Pro (Unknown model) (3005 MHz)",8, "AMD (Unknown model) (2596 MHz)",8, "Intel Pentium 4 Northwood (2013 MHz)",8, "Intel Pentium Pro (Unknown model) (725 MHz)",8, "AMD Athlon (Thunderbird core) (1205 MHz)",8, "AMD K7 (Unknown model) (1360 MHz)",8, "Intel Pentium 4 Willamette (1493 MHz)",8, "AMD Athlon MP/Mobile Athlon (Palomino core) (1683 MHz)",8, "Intel Pentium 4 (Unknown model) (3474 MHz)",8, "AMD (Unknown model) (2494 MHz)",8, "AMD K7 (Unknown model) (1910 MHz)",8, "AMD Athlon (Thunderbird core) (1396 MHz)",8, "Intel Pentium Pro (Unknown model) (1012 MHz)",8, "AMD Athlon MP/Mobile Athlon (Palomino core) (1541 MHz)",8, "Intel Pentium Pro (Unknown model) (1543 MHz)",8, "Intel Pentium III (0.18 micron process) with internal L2 cache (664 MHz)",8, "AMD K7 (Unknown model) (1195 MHz)",8, "Intel Pentium 4 Willamette (1395 MHz)",8, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1449 MHz)",8, "Intel Pentium Pro (Unknown model) (790 MHz)",8, "Intel Pentium 4 (Unknown model) (3203 MHz)",7, "Intel Pentium 4 Northwood Xeon (1603 MHz)",7, "AMD (Unknown model) (2038 MHz)",7, "AMD (Unknown model) (2806 MHz)",7, "Intel Pentium 4 Northwood Xeon (1690 MHz)",7, "Intel Pentium III (0.18 micron process) with internal L2 cache (802 MHz)",7, "Intel Pentium Pro (Unknown model) (457 MHz)",7, "Intel Pentium 4 (Unknown model) (3068 MHz)",7, "Intel Pentium 4 Northwood Xeon (2300 MHz)",7, "Intel Pentium 4 (Unknown model) (3462 MHz)",7, "AMD (Unknown model) (1605 MHz)",7, "Intel Celeron (0.18 micron process) with internal L2 cache (634 MHz)",7, "Intel Pentium Pro (Unknown model) (1539 MHz)",7, "AMD K7 (Unknown model) (1294 MHz)",7, "AMD (Unknown model) (2069 MHz)",7, "Intel Pentium 4 (Unknown model) (2825 MHz)",7, "Intel Pentium 4 Northwood (2652 MHz)",7, "Intel Pentium Pro (Unknown model) (2743 MHz)",7, "Intel Pentium Pro (Unknown model) (828 MHz)",7, "Intel Pentium 4 Northwood (3072 MHz)",7, "Intel Pentium 4 Northwood (3020 MHz)",7, "Intel Pentium Pro (Unknown model) (1639 MHz)",7, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (865 MHz)",7, "Intel Pentium Pro (Unknown model) (1638 MHz)",7, "AMD K7 (Unknown model) (2172 MHz)",7, "AMD Athlon (Thunderbird core) (801 MHz)",7, "AMD Athlon (Thunderbird core) (800 MHz)",7, "Intel Pentium Pro (Unknown model) (1771 MHz)",7, "AMD (Unknown model) (2246 MHz)",7, "Intel Pentium Pro (Unknown model) (764 MHz)",7, "Dual PowerPC 7450 (1600 MHz)",7, "AMD (Unknown model) (2368 MHz)",7, "Intel Pentium Pro (Unknown model) (1131 MHz)",7, "Intel Pentium 4 Willamette (A-Step) (1779 MHz)",7, "Intel Pentium 4 Northwood (1607 MHz)",7, "Intel Pentium Pro (Unknown model) (1465 MHz)",7, "Intel Pentium 4 Northwood (3055 MHz)",7, "Intel Pentium 4 (Unknown model) (3511 MHz)",7, "AMD (Unknown model) (1946 MHz)",7, "AMD (Unknown model) (2096 MHz)",7, "Intel Pentium 4 Northwood (3087 MHz)",7, "AMD (Unknown model) (2149 MHz)",7, "Intel Pentium 4 Willamette (A-Step) (1698 MHz)",7, "AMD Duron (Spitfire core) (796 MHz)",7, "AMD K7 (Unknown model) (1740 MHz)",7, "AMD Athlon MP/Mobile Athlon (Palomino core) (1198 MHz)",7, "AMD Athlon MP/Mobile Athlon (Palomino core) (1537 MHz)",7, "AMD (Unknown model) (2042 MHz)",7, "AMD (Unknown model) (2312 MHz)",7, "AMD Athlon (Thunderbird core) (1297 MHz)",7, "Intel Pentium 4 Willamette Xeon (1803 MHz)",7, "Intel Pentium Pro (Unknown model) (1146 MHz)",7, "Intel Pentium 4 (Unknown model) (4156 MHz)",7, "Intel Pentium 4 Northwood (2401 MHz)",7, "AMD Athlon MP/Mobile Athlon (Palomino core) (1530 MHz)",7, "AMD K7 (Unknown model) (1745 MHz)",7, "AMD (Unknown model) (2079 MHz)",7, "AMD (Unknown model) (2706 MHz)",7, "Intel Pentium 4 (Unknown model) (3408 MHz)",7, "Intel Pentium Pro (Unknown model) (1632 MHz)",7, "AMD (Unknown model) (2421 MHz)",7, "Intel Pentium Pro (Unknown model) (979 MHz)",7, "AMD (Unknown model) (2498 MHz)",7, "AMD K7 (Unknown model) (1260 MHz)",7, "Intel Pentium 4 Northwood (2769 MHz)",7, "Intel Pentium 4 (Unknown model) (3347 MHz)",7, "Intel Pentium 4 (Unknown model) (3205 MHz)",7, "AMD K7 (Unknown model) (1911 MHz)",7, "Intel Pentium 4 (Unknown model) (3385 MHz)",7, "Intel Pentium Pro (Unknown model) (3117 MHz)",7, "AMD K7 (Unknown model) (2092 MHz)",7, "Intel Pentium Pro (Unknown model) (1328 MHz)",7, "Intel Pentium Pro (Unknown model) (895 MHz)",7, "AMD (Unknown model) (2441 MHz)",7, "Intel Pentium Pro (Unknown model) (3204 MHz)",7, "Intel Pentium 4 Northwood (2092 MHz)",7, "AMD (Unknown model) (2268 MHz)",7, "Intel Pentium Pro (Unknown model) (2698 MHz)",7, "AMD (Unknown model) (2601 MHz)",7, "AMD (Unknown model) (2214 MHz)",7, "Intel Pentium III (0.18 micron process) with internal L2 cache (861 MHz)",7, "Intel Pentium 4 Willamette (A-Step) (1716 MHz)",7, "Intel Pentium 4 (Unknown model)",7, "Intel Pentium 4 Northwood (2160 MHz)",7, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1197 MHz)",7, "AMD K7 (Unknown model) (1108 MHz)",7, "AMD K7 (Unknown model) (2017 MHz)",7, "AMD K7 (Unknown model) (2108 MHz)",7, "Intel Pentium Pro (Unknown model) (1129 MHz)",7, "Intel Pentium Pro (Unknown model) (2001 MHz)",7, "Intel Pentium 4 (Unknown model) (3055 MHz)",7, "AMD Athlon MP/Mobile Athlon (Palomino core) (1099 MHz)",7, "AMD K7 (Unknown model) (2192 MHz)",7, "AMD K7 (Unknown model) (2012 MHz)",7, "AMD (Unknown model) (2729 MHz)",7, "AMD (Unknown model) (1812 MHz)",7, "AMD Athlon (Thunderbird core) (1404 MHz)",7, "Intel Pentium 4 Northwood (2662 MHz)",7, "AMD (Unknown model) (1858 MHz)",7, "Intel Pentium Pro (Unknown model) (1024 MHz)",7, "Intel Pentium Pro (Unknown model) (1606 MHz)",7, "Intel Pentium Pro (Unknown model) (1669 MHz)",7, "AMD (Unknown model) (1930 MHz)",7, "Intel Pentium Pro (Unknown model) (1859 MHz)",7, "Intel Pentium 4 (Unknown model) (3086 MHz)",7, "Intel Pentium Pro (Unknown model) (1417 MHz)",7, "Intel Pentium 4 (Unknown model) (3004 MHz)",7, "AMD Mobile Duron (Morgan core) (1195 MHz)",7, "Intel Pentium Pro (Unknown model) (2407 MHz)",7, "Intel Pentium 4 (Unknown model) (3002 MHz)",7, "Intel Pentium 4 Northwood (2810 MHz)",7, "AMD K7 (Unknown model) (2145 MHz)",7, "Intel Pentium Pro (Unknown model) (3375 MHz)",7, "AMD Athlon (Thunderbird core) (799 MHz)",7, "Intel Pentium Pro (Unknown model) (855 MHz)",7, "Intel Pentium 4 Willamette Xeon (1680 MHz)",7, "AMD (Unknown model) (2098 MHz)",7, "Intel Pentium 4 Northwood Xeon (1779 MHz)",7, "Intel Pentium III (0.18 micron process) with internal L2 cache (669 MHz)",7, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (996 MHz)",7, "Intel Pentium Pro (Unknown model) (1470 MHz)",7, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (601 MHz)",7, "Intel Pentium 4 Willamette Xeon (1795 MHz)",7, "AMD (Unknown model) (2106 MHz)",7, "Intel Pentium 4 Northwood (2159 MHz)",7, "AMD (Unknown model) (1940 MHz)",7, "AMD (Unknown model) (1886 MHz)",7, "Intel Pentium Pro (Unknown model) (1551 MHz)",7, "AMD (Unknown model) (2061 MHz)",7, "AMD K7 (Unknown model) (1060 MHz)",7, "AMD K7 (Unknown model) (1937 MHz)",7, "Intel Pentium Pro (Unknown model) (1259 MHz)",7, "Intel Pentium 4 (Unknown model) (3219 MHz)",7, "Intel Pentium II with internal L2 cache (432 MHz)",7, "AMD (Unknown model) (1144 MHz)",7, "AMD (Unknown model) (1920 MHz)",7, "AMD K7 (Unknown model) (1770 MHz)",7, "AMD Athlon (Thunderbird core) (1052 MHz)",7, "AMD (Unknown model) (1634 MHz)",7, "Intel Pentium Pro (Unknown model) (1873 MHz)",7, "Intel Pentium Pro (Unknown model) (1553 MHz)",7, "Intel Pentium Pro (Unknown model) (2329 MHz)",7, "Intel Pentium Pro (Unknown model) (2524 MHz)",7, "Intel Pentium III (0.18 micron process) with internal L2 cache (935 MHz)",7, "AMD K7 (Unknown model) (2216 MHz)",7, "AMD Athlon MP/Mobile Athlon (Palomino core) (1473 MHz)",7, "AMD (Unknown model) (2320 MHz)",7, "Intel Pentium Pro (Unknown model) (1239 MHz)",7, "Intel Pentium Pro (Unknown model) (1825 MHz)",7, "Intel Pentium Pro (Unknown model) (1932 MHz)",7, "Intel Pentium Pro (Unknown model) (1107 MHz)",7, "Intel Pentium 4 Northwood (2995 MHz)",7, "Intel Pentium Pro (Unknown model) (658 MHz)",7, "AMD (Unknown model) (1793 MHz)",7, "Intel Pentium 4 Northwood (2820 MHz)",7, "Intel Pentium 4 (Unknown model) (2459 MHz)",7, "Intel Pentium 4 Northwood (1200 MHz)",7, "AMD K7 (Unknown model) (533 MHz)",7, "AMD (Unknown model) (1987 MHz)",7, "Intel Pentium 4 Northwood Xeon (1988 MHz)",7, "Intel Pentium Pro (Unknown model) (607 MHz)",7, "Intel Pentium Pro (Unknown model) (3203 MHz)",7, "AMD K7 (Unknown model) (1530 MHz)",7, "Intel Pentium 4 Northwood (2661 MHz)",7, "Intel Pentium Pro (Unknown model) (1231 MHz)",7, "AMD K7 (Unknown model) (2388 MHz)",7, "AMD (Unknown model) (1604 MHz)",7, "Intel Pentium Pro (Unknown model) (705 MHz)",7, "Intel Pentium 4 Northwood (2707 MHz)",7, "Intel Pentium Pro (Unknown model) (1074 MHz)",7, "Intel Pentium Pro (Unknown model) (1834 MHz)",7, "AMD (Unknown model) (2185 MHz)",7, "Intel Pentium Pro (Unknown model) (1735 MHz)",7, "AMD (Unknown model) (2083 MHz)",7, "AMD (Unknown model) (1828 MHz)",7, "AMD (Unknown model) (1988 MHz)",7, "Intel Pentium 4 Northwood (2238 MHz)",7, "AMD (Unknown model) (1842 MHz)",7, "Intel Pentium Pro (Unknown model) (1235 MHz)",7, "Intel Pentium III (0.18 micron process) with internal L2 cache (937 MHz)",7, "Intel Pentium Pro (Unknown model) (904 MHz)",7, "Intel Pentium 4 Northwood (1818 MHz)",7, "Intel Pentium Pro (Unknown model) (1120 MHz)",7, "Intel Celeron (0.18 micron process) with internal L2 cache (851 MHz)",7, "AMD (Unknown model) (1695 MHz)",7, "Intel Pentium 4 (Unknown model) (2959 MHz)",7, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1002 MHz)",7, "Intel Pentium Pro (Unknown model) (859 MHz)",7, "Intel Pentium Pro (Unknown model) (791 MHz)",7, "Intel Pentium Pro (Unknown model) (1487 MHz)",7, "Intel Pentium 4 Northwood (2759 MHz)",7, "Intel Pentium Pro (Unknown model) (2099 MHz)",7, "AMD (Unknown model) (2114 MHz)",7, "AMD Athlon (Thunderbird core) (1204 MHz)",7, "PowerPC 7450",7, "AMD (Unknown model) (2375 MHz)",7, "Intel Pentium 4 Northwood (3097 MHz)",7, "Intel Pentium 4 Northwood (2133 MHz)",7, "AMD K7 (Unknown model) (1298 MHz)",7, "Intel Pentium 4 Willamette Xeon (1691 MHz)",7, "AMD (Unknown model) (2332 MHz)",7, "Intel Celeron (0.18 micron process) with internal L2 cache (734 MHz)",7, "AMD Athlon MP/Mobile Athlon (Palomino core) (1471 MHz)",7, "Intel Pentium 4 (Unknown model) (3394 MHz)",7, "AMD Mobile Duron (Morgan core) (850 MHz)",7, "AMD K7 (Unknown model) (1875 MHz)",7, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1208 MHz)",7, "Intel Pentium Pro (Unknown model) (2925 MHz)",7, "Intel Pentium 4 Northwood Xeon (2500 MHz)",7, "Intel Pentium 4 (Unknown model) (2391 MHz)",7, "Intel Pentium 4 Northwood (2339 MHz)",7, "AMD K7 (Unknown model) (1899 MHz)",7, "Intel Pentium 4 (Unknown model) (3456 MHz)",7, "Intel Pentium Pro (Unknown model) (2144 MHz)",6, "AMD Duron (Spitfire core) (949 MHz)",6, "AMD K7 (Unknown model) (1761 MHz)",6, "Intel Pentium Pro (Unknown model) (825 MHz)",6, "Intel Pentium Pro (Unknown model) (1346 MHz)",6, "Intel Pentium Pro (Unknown model) (1265 MHz)",6, "AMD (Unknown model) (1609 MHz)",6, "Intel Pentium 4 (Unknown model) (3202 MHz)",6, "AMD K7 (Unknown model) (1263 MHz)",6, "AMD (Unknown model) (2254 MHz)",6, "Intel Pentium Pro (Unknown model) (1546 MHz)",6, "AMD (Unknown model) (1810 MHz)",6, "Intel Pentium Pro (Unknown model) (1585 MHz)",6, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1405 MHz)",6, "Intel Pentium 4 Northwood (3021 MHz)",6, "Intel Pentium Pro (Unknown model) (1236 MHz)",6, "Intel Pentium 4 Northwood (1988 MHz)",6, "Intel Pentium Pro (Unknown model) (1381 MHz)",6, "Intel Pentium Pro (Unknown model) (1078 MHz)",6, "Intel Pentium Pro (Unknown model) (1027 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1390 MHz)",6, "Intel Pentium 4 Willamette Xeon (1614 MHz)",6, "Intel Pentium Pro (Unknown model) (1047 MHz)",6, "Intel Pentium Pro (Unknown model) (1172 MHz)",6, "Intel Pentium Pro (Unknown model) (1149 MHz)",6, "Intel Pentium Pro (Unknown model) (1327 MHz)",6, "Intel Pentium 4 Northwood (1611 MHz)",6, "Intel Pentium Pro (Unknown model) (1170 MHz)",6, "Intel Pentium Pro (Unknown model) (1158 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1663 MHz)",6, "AMD (Unknown model) (2026 MHz)",6, "Intel Pentium 4 Willamette Xeon (1790 MHz)",6, "Intel Pentium 4 Northwood (2406 MHz)",6, "Intel Pentium 4 (Unknown model) (3419 MHz)",6, "Intel Pentium Pro (Unknown model) (1836 MHz)",6, "AMD (Unknown model) (1846 MHz)",6, "Intel Pentium Pro (Unknown model) (857 MHz)",6, "AMD (Unknown model) (1888 MHz)",6, "Intel Pentium 4 Northwood Xeon (2768 MHz)",6, "Intel Pentium 4 Northwood (3361 MHz)",6, "Intel Pentium Pro (Unknown model) (1275 MHz)",6, "AMD K7 (Unknown model) (1889 MHz)",6, "AMD (Unknown model) (1797 MHz)",6, "Intel Pentium Pro (Unknown model) (1124 MHz)",6, "Intel Pentium 4 (Unknown model) (2407 MHz)",6, "Intel Pentium 4 Willamette (1810 MHz)",6, "AMD K7 (Unknown model) (2142 MHz)",6, "Intel Pentium 4 (Unknown model) (3328 MHz)",6, "Intel Pentium 4 (Unknown model) (3071 MHz)",6, "Intel Pentium 4 (Unknown model) (2760 MHz)",6, "Intel Pentium 4 (Unknown model) (3666 MHz)",6, "Intel Pentium Pro (Unknown model) (833 MHz)",6, "AMD (Unknown model) (2219 MHz)",6, "AMD K7 (Unknown model) (1687 MHz)",6, "Intel Pentium Pro (Unknown model) (1820 MHz)",6, "Intel Pentium 4 Northwood (2808 MHz)",6, "Intel Pentium 4 Northwood (2687 MHz)",6, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (994 MHz)",6, "Intel Pentium Pro (Unknown model) (1629 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1607 MHz)",6, "Intel Pentium Pro (Unknown model) (1803 MHz)",6, "AMD (Unknown model) (2097 MHz)",6, "AMD Duron (Spitfire core) (746 MHz)",6, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (664 MHz)",6, "Intel Pentium III (0.18 micron process) with internal L2 cache (600 MHz)",6, "Intel Pentium III (0.18 micron process) with internal L2 cache (923 MHz)",6, "Intel Pentium 4 Northwood (1836 MHz)",6, "AMD (Unknown model) (2294 MHz)",6, "AMD (Unknown model) (2186 MHz)",6, "AMD (Unknown model) (1664 MHz)",6, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1193 MHz)",6, "Intel Pentium Pro (Unknown model) (1241 MHz)",6, "AMD (Unknown model) (1882 MHz)",6, "Intel Celeron (0.18 micron process) with internal L2 cache (795 MHz)",6, "Intel Pentium 4 (Unknown model) (2522 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1407 MHz)",6, "AMD (Unknown model) (2397 MHz)",6, "AMD K7 (Unknown model) (1509 MHz)",6, "Intel Pentium Pro (Unknown model) (2168 MHz)",6, "AMD K7 (Unknown model) (1735 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1144 MHz)",6, "AMD (Unknown model) (2122 MHz)",6, "AMD (Unknown model) (2486 MHz)",6, "AMD (Unknown model) (2609 MHz)",6, "AMD Duron (Spitfire core) (846 MHz)",6, "AMD K7 (Unknown model) (1575 MHz)",6, "Intel Pentium 4 Willamette (1977 MHz)",6, "AMD (Unknown model) (1636 MHz)",6, "AMD K7 (Unknown model) (2024 MHz)",6, "Unknown (1396 MHz)",6, "Intel Pentium III (0.18 micron process) with internal L2 cache (993 MHz)",6, "AMD K7 (Unknown model) (2219 MHz)",6, "Intel Pentium 4 Northwood Xeon (2390 MHz)",6, "AMD (Unknown model) (1932 MHz)",6, "Intel Pentium 4 Willamette (1904 MHz)",6, "AMD (Unknown model) (2527 MHz)",6, "AMD K7 (Unknown model) (995 MHz)",6, "Intel Pentium Pro (Unknown model) (601 MHz)",6, "Intel Pentium 4 Willamette Xeon (1813 MHz)",6, "AMD Athlon (Thunderbird core) (1407 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1722 MHz)",6, "Intel Pentium 4 Willamette (1914 MHz)",6, "Intel Pentium 4 Northwood Xeon (3061 MHz)",6, "AMD Athlon (Thunderbird core) (1059 MHz)",6, "Intel Pentium Pro (Unknown model) (2987 MHz)",6, "Intel Pentium 4 (Unknown model) (3069 MHz)",6, "Intel Pentium 4 (Unknown model) (3598 MHz)",6, "AMD K7 (Unknown model) (2185 MHz)",6, "Intel Pentium 4 (Unknown model) (3608 MHz)",6, "AMD (Unknown model) (2120 MHz)",6, "Intel Pentium Pro (Unknown model) (1040 MHz)",6, "Intel Pentium Pro (Unknown model) (416 MHz)",6, "Intel Pentium 4 Northwood (2610 MHz)",6, "AMD (Unknown model) (1029 MHz)",6, "Intel Pentium Pro (Unknown model) (1041 MHz)",6, "Intel Pentium Pro (Unknown model) (767 MHz)",6, "Intel Pentium Pro (Unknown model) (1325 MHz)",6, "AMD (Unknown model) (1821 MHz)",6, "AMD K7 (Unknown model) (2135 MHz)",6, "AMD (Unknown model) (2859 MHz)",6, "Intel Pentium 4 Willamette Xeon (A-Step) (1694 MHz)",6, "AMD (Unknown model) (2434 MHz)",6, "AMD K7 (Unknown model) (1812 MHz)",6, "Intel Pentium 4 Northwood (2294 MHz)",6, "AMD K7 (Unknown model) (2196 MHz)",6, "Intel Pentium 4 Northwood (2209 MHz)",6, "Intel Pentium 4 (Unknown model) (3587 MHz)",6, "AMD (Unknown model) (2529 MHz)",6, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1198 MHz)",6, "Intel Pentium 4 (Unknown model) (3074 MHz)",6, "AMD K7 (Unknown model) (1870 MHz)",6, "Intel Pentium 4 (Unknown model) (3236 MHz)",6, "Intel Pentium Pro (Unknown model) (2940 MHz)",6, "Intel Pentium Pro (Unknown model) (906 MHz)",6, "AMD (Unknown model) (1841 MHz)",6, "Intel Pentium 4 Northwood (2091 MHz)",6, "AMD Mobile Duron (Morgan core) (1001 MHz)",6, "Intel Pentium Pro (Unknown model) (1237 MHz)",6, "Intel Pentium 4 Willamette (A-Step) (1795 MHz)",6, "AMD (Unknown model) (1824 MHz)",6, "AMD (Unknown model) (2567 MHz)",6, "Intel Pentium 4 (Unknown model) (2142 MHz)",6, "AMD (Unknown model) (2151 MHz)",6, "Intel Pentium Pro (Unknown model) (907 MHz)",6, "AMD (Unknown model) (1623 MHz)",6, "Intel Pentium Pro (Unknown model) (423 MHz)",6, "Intel Pentium 4 Northwood (1918 MHz)",6, "AMD (Unknown model) (1949 MHz)",6, "Intel Pentium 4 Northwood (2096 MHz)",6, "AMD Athlon (Thunderbird core) (851 MHz)",6, "Intel Pentium 4 (Unknown model) (2742 MHz)",6, "Intel Pentium 4 (Unknown model) (2531 MHz)",6, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1325 MHz)",6, "Intel Pentium Pro (Unknown model) (1431 MHz)",6, "Intel Pentium 4 Northwood (2375 MHz)",6, "Intel Pentium Pro (Unknown model) (704 MHz)",6, "AMD (Unknown model) (2212 MHz)",6, "Intel Pentium Pro (Unknown model) (894 MHz)",6, "Intel Pentium Pro (Unknown model) (1630 MHz)",6, "Intel Pentium 4 Willamette (2018 MHz)",6, "Intel Pentium III (0.18 micron process) with internal L2 cache (548 MHz)",6, "Intel Pentium Pro (Unknown model) (1823 MHz)",6, "Intel Pentium 4 Northwood Xeon (2794 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1299 MHz)",6, "AMD (Unknown model) (1827 MHz)",6, "AMD Duron (Spitfire core) (950 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1328 MHz)",6, "Intel Pentium 4 (Unknown model) (3842 MHz)",6, "AMD K7 (Unknown model) (1816 MHz)",6, "Intel Pentium Pro (Unknown model) (3060 MHz)",6, "Intel Pentium 4 (Unknown model) (3740 MHz)",6, "Intel Pentium Pro (Unknown model) (1427 MHz)",6, "AMD K7 (Unknown model) (2400 MHz)",6, "Intel Pentium Pro (Unknown model) (2930 MHz)",6, "AMD (Unknown model) (1843 MHz)",6, "AMD K7 (Unknown model) (2154 MHz)",6, "Intel Pentium Pro (Unknown model) (1178 MHz)",6, "Intel Pentium Pro (Unknown model) (788 MHz)",6, "Intel Pentium Pro (Unknown model) (1123 MHz)",6, "AMD (Unknown model) (2453 MHz)",6, "Intel Pentium 4 (Unknown model) (2524 MHz)",6, "AMD K7 (Unknown model) (1700 MHz)",6, "AMD (Unknown model) (1855 MHz)",6, "Intel Pentium 4 (Unknown model) (3277 MHz)",6, "Intel Pentium Pro (Unknown model) (726 MHz)",6, "Intel Pentium Pro (Unknown model) (1590 MHz)",6, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1300 MHz)",6, "AMD (Unknown model) (2313 MHz)",6, "AMD K7 (Unknown model) (2040 MHz)",6, "AMD (Unknown model) (1986 MHz)",6, "AMD (Unknown model) (2113 MHz)",6, "AMD (Unknown model) (2259 MHz)",6, "AMD Duron (Spitfire core) (706 MHz)",6, "Intel Pentium 4 Willamette (1808 MHz)",6, "Intel Pentium 4 Northwood (2376 MHz)",6, "Intel Pentium Pro (Unknown model) (1959 MHz)",6, "AMD Athlon (Thunderbird core) (1102 MHz)",6, "Intel Pentium 4 Willamette (1596 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1294 MHz)",6, "Intel Pentium 4 Northwood Xeon (2665 MHz)",6, "Intel Pentium Pro (Unknown model) (868 MHz)",6, "AMD K7 (Unknown model) (1680 MHz)",6, "Intel Pentium 4 (Unknown model) (3107 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1679 MHz)",6, "AMD K7 (Unknown model) (2236 MHz)",6, "AMD K7 (Unknown model) (1609 MHz)",6, "Intel Pentium 4 (Unknown model) (2867 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1311 MHz)",6, "AMD (Unknown model) (2066 MHz)",6, "AMD (Unknown model) (2298 MHz)",6, "Intel Pentium 4 (Unknown model) (2662 MHz)",6, "Intel Pentium Pro (Unknown model) (743 MHz)",6, "Intel Pentium Pro (Unknown model) (1205 MHz)",6, "AMD (Unknown model) (2287 MHz)",6, "AMD (Unknown model) (2021 MHz)",6, "Intel Pentium Pro (Unknown model) (1536 MHz)",6, "AMD K7 (Unknown model) (2020 MHz)",6, "AMD (Unknown model) (2030 MHz)",6, "Intel Pentium 4 Willamette (1918 MHz)",6, "AMD (Unknown model) (2406 MHz)",6, "Intel Pentium 4 Northwood (2270 MHz)",6, "Intel Pentium 4 Northwood (1893 MHz)",6, "AMD (Unknown model) (2364 MHz)",6, "AMD K7 (Unknown model) (1747 MHz)",6, "Intel Pentium 4 Northwood (2535 MHz)",6, "Intel Pentium 4 Willamette (A-Step) (1498 MHz)",6, "Intel Pentium 4 Northwood (2015 MHz)",6, "AMD K7 (Unknown model) (998 MHz)",6, "AMD (Unknown model) (1935 MHz)",6, "Intel Pentium Pro (Unknown model) (1484 MHz)",6, "Intel Pentium Pro (Unknown model) (1401 MHz)",6, "Intel Pentium 4 Northwood (2198 MHz)",6, "Intel Pentium Pro (Unknown model) (1289 MHz)",6, "Intel Pentium III (0.18 micron process) with internal L2 cache (839 MHz)",6, "Intel Pentium Pro (Unknown model) (730 MHz)",6, "Intel Pentium 4 Northwood (3009 MHz)",6, "AMD Athlon (Thunderbird core) (945 MHz)",6, "Intel Pentium 4 Northwood (2620 MHz)",6, "AMD Duron (Spitfire core) (997 MHz)",6, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (548 MHz)",6, "Intel Pentium Pro (Unknown model) (1234 MHz)",6, "Intel Pentium III (0.18 micron process) with internal L2 cache (1035 MHz)",6, "Intel Pentium 4 Northwood Xeon (1197 MHz)",6, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (996 MHz)",6, "AMD K7 (Unknown model) (1904 MHz)",6, "AMD Athlon (Thunderbird core) (1325 MHz)",6, "AMD K7 (Unknown model) (2230 MHz)",6, "Intel Pentium 4 Northwood (2697 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1312 MHz)",6, "AMD (Unknown model) (1971 MHz)",6, "Intel Pentium Pro (Unknown model) (1245 MHz)",6, "AMD Mobile Duron (Morgan core) (1008 MHz)",6, "Intel Pentium 4 (Unknown model) (3402 MHz)",6, "AMD (Unknown model) (2319 MHz)",6, "Intel Pentium Pro (Unknown model) (1202 MHz)",6, "Intel Pentium Pro (Unknown model) (1429 MHz)",6, "AMD Mobile Duron (Morgan core) (800 MHz)",6, "Intel Pentium 4 (Unknown model) (3075 MHz)",6, "Intel Pentium 4 Northwood (3193 MHz)",6, "Intel Pentium 4 (Unknown model) (2415 MHz)",6, "Intel Pentium III (0.18 micron process) with internal L2 cache (936 MHz)",6, "AMD (Unknown model) (1060 MHz)",6, "AMD Athlon MP/Mobile Athlon (Palomino core) (1608 MHz)",6, "Intel Pentium 4 Northwood Xeon (2788 MHz)",6, "Intel Pentium 4 (Unknown model) (1995 MHz)",6, "Intel Pentium 4 Northwood (2653 MHz)",6, "Intel Pentium 4 (Unknown model) (2900 MHz)",6, "Intel Pentium Pro (Unknown model) (2879 MHz)",6, "Intel Pentium Pro (Unknown model) (898 MHz)",6, "Intel Pentium Pro (Unknown model) (2004 MHz)",6, "Intel Pentium Pro (Unknown model) (1126 MHz)",5, "AMD (Unknown model) (1746 MHz)",5, "Intel Pentium 4 Northwood (2469 MHz)",5, "AMD (Unknown model) (2792 MHz)",5, "AMD K7 (Unknown model) (2143 MHz)",5, "Intel Pentium 4 Willamette (A-Step) (1793 MHz)",5, "Intel Pentium 4 Willamette Xeon (1500 MHz)",5, "Intel Pentium 4 Northwood (3070 MHz)",5, "AMD (Unknown model) (1918 MHz)",5, "Intel Pentium 4 Northwood (3392 MHz)",5, "AMD (Unknown model) (1817 MHz)",5, "Intel Pentium 4 Willamette (1803 MHz)",5, "AMD (Unknown model) (1848 MHz)",5, "Intel Pentium 4 Northwood Xeon (2666 MHz)",5, "AMD K7 (Unknown model) (2114 MHz)",5, "Intel Pentium Pro (Unknown model) (1188 MHz)",5, "Intel Pentium Pro (Unknown model) (2344 MHz)",5, "Intel Pentium Pro (Unknown model) (1025 MHz)",5, "AMD K7 (Unknown model) (1147 MHz)",5, "AMD (Unknown model) (2574 MHz)",5, "AMD K7 (Unknown model) (1607 MHz)",5, "Intel Pentium Pro (Unknown model) (1364 MHz)",5, "Intel Pentium 4 Northwood (2828 MHz)",5, "AMD (Unknown model) (2553 MHz)",5, "Intel Pentium Pro (Unknown model) (1277 MHz)",5, "AMD (Unknown model) (2503 MHz)",5, "Intel Pentium 4 Northwood (2120 MHz)",5, "Intel Pentium Pro (Unknown model) (1264 MHz)",5, "AMD K7 (Unknown model) (1007 MHz)",5, "Intel Pentium 4 Northwood (2996 MHz)",5, "AMD (Unknown model) (2065 MHz)",5, "Intel Pentium Pro (Unknown model) (1103 MHz)",5, "Intel Pentium Pro (Unknown model) (1538 MHz)",5, "AMD (Unknown model) (2507 MHz)",5, "Intel Pentium 4 Northwood (2459 MHz)",5, "Intel Pentium Pro (Unknown model) (1517 MHz)",5, "Intel Pentium Pro (Unknown model) (1184 MHz)",5, "Intel Pentium 4 Northwood (3120 MHz)",5, "Intel Pentium 4 Willamette Xeon (1483 MHz)",5, "Intel Pentium 4 Northwood Xeon (1990 MHz)",5, "AMD K7 (Unknown model) (1192 MHz)",5, "AMD (Unknown model) (1869 MHz)",5, "Intel Pentium 4 Northwood (2094 MHz)",5, "AMD K7 (Unknown model) (2149 MHz)",5, "Intel Pentium 4 Northwood (2997 MHz)",5, "AMD (Unknown model) (2183 MHz)",5, "Intel Pentium 4 (Unknown model) (2464 MHz)",5, "AMD Duron (Spitfire core) (699 MHz)",5, "AMD (Unknown model) (2279 MHz)",5, "Intel Pentium 4 (Unknown model) (3747 MHz)",5, "Intel Pentium Pro (Unknown model) (1678 MHz)",5, "Intel Pentium Pro (Unknown model) (319 MHz)",5, "Intel Pentium 4 Northwood (2322 MHz)",5, "Intel Pentium 4 Northwood (2562 MHz)",5, "Intel Pentium 4 Northwood (2287 MHz)",5, "AMD K7 (Unknown model) (1981 MHz)",5, "AMD K7 (Unknown model) (1352 MHz)",5, "Intel Pentium 4 Northwood Xeon (3053 MHz)",5, "AMD (Unknown model) (2483 MHz)",5, "Intel Pentium 4 (Unknown model) (3367 MHz)",5, "AMD (Unknown model) (2385 MHz)",5, "AMD K7 (Unknown model) (1596 MHz)",5, "AMD (Unknown model) (2378 MHz)",5, "AMD (Unknown model) (2426 MHz)",5, "Intel Pentium Pro (Unknown model) (1576 MHz)",5, "AMD (Unknown model) (2190 MHz)",5, "AMD (Unknown model) (2150 MHz)",5, "Intel Pentium 4 Northwood (2424 MHz)",5, "AMD Athlon (Thunderbird core) (1133 MHz)",5, "Intel Pentium Pro (Unknown model) (1180 MHz)",5, "Intel Pentium Pro (Unknown model) (936 MHz)",5, "Intel Pentium Pro (Unknown model) (756 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1143 MHz)",5, "AMD (Unknown model) (1863 MHz)",5, "Intel Pentium 4 Northwood (1596 MHz)",5, "AMD (Unknown model) (2436 MHz)",5, "AMD Mobile Duron (Morgan core) (1271 MHz)",5, "AMD K7 (Unknown model) (1133 MHz)",5, "AMD (Unknown model) (1687 MHz)",5, "AMD K7 (Unknown model) (1686 MHz)",5, "AMD K7 (Unknown model) (1474 MHz)",5, "AMD (Unknown model) (2388 MHz)",5, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (933 MHz)",5, "AMD Athlon (Thunderbird core) (1095 MHz)",5, "Intel Pentium Pro (Unknown model) (736 MHz)",5, "AMD Duron (Spitfire core) (900 MHz)",5, "Intel Pentium 4 (Unknown model) (2829 MHz)",5, "Intel Pentium Pro (Unknown model) (1755 MHz)",5, "Intel Pentium 4 (Unknown model) (3679 MHz)",5, "Intel Pentium Pro (Unknown model) (883 MHz)",5, "AMD (Unknown model) (2413 MHz)",5, "AMD (Unknown model) (2302 MHz)",5, "Intel Pentium Pro (Unknown model) (792 MHz)",5, "AMD Duron (Spitfire core) (857 MHz)",5, "Intel Pentium 4 (Unknown model) (3362 MHz)",5, "AMD Mobile Duron (Morgan core) (1006 MHz)",5, "Intel Pentium Pro (Unknown model) (971 MHz)",5, "AMD Athlon (Thunderbird core) (1110 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1747 MHz)",5, "Intel Pentium II with internal L2 cache (465 MHz)",5, "Intel Pentium 4 (Unknown model) (3345 MHz)",5, "AMD (Unknown model) (2510 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1598 MHz)",5, "Intel Pentium Pro (Unknown model) (889 MHz)",5, "AMD (Unknown model) (1003 MHz)",5, "Intel Pentium 4 Northwood Xeon (2798 MHz)",5, "AMD K7 (Unknown model) (1874 MHz)",5, "Intel Pentium 4 (Unknown model) (3300 MHz)",5, "Intel Pentium Pro (Unknown model) (1440 MHz)",5, "Intel Pentium 4 Northwood Xeon (2497 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1610 MHz)",5, "Intel Pentium Pro (Unknown model) (703 MHz)",5, "AMD K7 (Unknown model) (1977 MHz)",5, "Intel Pentium Pro (Unknown model) (1098 MHz)",5, "Intel Pentium Pro (Unknown model) (1575 MHz)",5, "Intel Pentium 4 (Unknown model) (2759 MHz)",5, "Intel Pentium 4 (Unknown model) (3818 MHz)",5, "Intel Pentium Pro (Unknown model) (2406 MHz)",5, "Intel Pentium 4 Northwood (1866 MHz)",5, "Intel Pentium Pro (Unknown model) (2784 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1049 MHz)",5, "Intel Pentium Pro (Unknown model) (3603 MHz)",5, "Intel Pentium 4 Northwood (1904 MHz)",5, "AMD Duron (Spitfire core) (1016 MHz)",5, "Intel Pentium 4 (Unknown model) (3022 MHz)",5, "Intel Pentium 4 Northwood Xeon (3054 MHz)",5, "Intel Pentium Pro (Unknown model) (978 MHz)",5, "AMD (Unknown model) (2760 MHz)",5, "AMD K7 (Unknown model) (2221 MHz)",5, "AMD (Unknown model) (2133 MHz)",5, "Intel Pentium Pro (Unknown model) (415 MHz)",5, "Intel Pentium 4 Northwood (3082 MHz)",5, "Intel Pentium Pro (Unknown model) (2632 MHz)",5, "Intel Pentium Pro (Unknown model) (1125 MHz)",5, "AMD K7 (Unknown model) (1890 MHz)",5, "Intel Pentium Pro (Unknown model) (1050 MHz)",5, "Intel Pentium Pro (Unknown model) (829 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1253 MHz)",5, "AMD (Unknown model) (2354 MHz)",5, "Intel Pentium Pro (Unknown model) (913 MHz)",5, "Intel Pentium 4 Northwood (1715 MHz)",5, "Intel Pentium 4 (Unknown model) (3611 MHz)",5, "Intel Pentium 4 Northwood (3071 MHz)",5, "Intel Pentium Pro (Unknown model) (1402 MHz)",5, "AMD (Unknown model) (2196 MHz)",5, "Intel Pentium 4 Northwood (3124 MHz)",5, "AMD Athlon (Thunderbird core) (997 MHz)",5, "AMD Athlon (Thunderbird core) (1206 MHz)",5, "Intel Pentium 4 (Unknown model) (1502 MHz)",5, "AMD (Unknown model) (2438 MHz)",5, "Intel Pentium Pro (Unknown model) (747 MHz)",5, "Intel Pentium Pro (Unknown model) (1048 MHz)",5, "Intel Pentium Pro (Unknown model) (2591 MHz)",5, "Intel Pentium 4 Northwood (1733 MHz)",5, "Intel Pentium Pro (Unknown model) (903 MHz)",5, "Intel Pentium III (0.18 micron process) with internal L2 cache (704 MHz)",5, "Intel Pentium Pro (Unknown model) (944 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1256 MHz)",5, "Intel Pentium 4 (Unknown model) (2919 MHz)",5, "Intel Pentium 4 (Unknown model) (2418 MHz)",5, "Intel Celeron (0.18 micron process) with internal L2 cache (664 MHz)",5, "Intel Pentium Pro (Unknown model) (1643 MHz)",5, "Intel Pentium Pro (Unknown model) (820 MHz)",5, "Intel Pentium Pro (Unknown model) (2803 MHz)",5, "Intel Pentium 4 Willamette (A-Step) (1403 MHz)",5, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1328 MHz)",5, "Intel Pentium Pro (Unknown model) (832 MHz)",5, "Intel Pentium 4 Northwood (1598 MHz)",5, "Intel Pentium Pro (Unknown model) (757 MHz)",5, "Dual i386 (Unknown) (2170 MHz)",5, "Intel Pentium 4 (Unknown model) (2944 MHz)",5, "Intel Pentium Pro (Unknown model) (1413 MHz)",5, "Intel Pentium Pro (Unknown model) (1082 MHz)",5, "Intel Pentium Pro (Unknown model) (867 MHz)",5, "Intel Pentium 4 (Unknown model) (3481 MHz)",5, "AMD Athlon (Thunderbird core) (1402 MHz)",5, "AMD K7 (Unknown model) (1305 MHz)",5, "Intel Pentium 4 Northwood (2039 MHz)",5, "Intel Pentium 4 Northwood (1798 MHz)",5, "Intel Pentium Pro (Unknown model) (911 MHz)",5, "Intel Pentium 4 (Unknown model) (3404 MHz)",5, "AMD (Unknown model) (2610 MHz)",5, "AMD K7 (Unknown model) (1989 MHz)",5, "Intel Pentium 4 Willamette Xeon (2008 MHz)",5, "Intel Pentium 4 (Unknown model) (2429 MHz)",5, "Intel Pentium 4 Northwood (2484 MHz)",5, "AMD K7 (Unknown model) (1339 MHz)",5, "Intel Pentium Pro (Unknown model) (777 MHz)",5, "AMD (Unknown model) (2523 MHz)",5, "AMD (Unknown model) (1887 MHz)",5, "AMD (Unknown model) (2132 MHz)",5, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1066 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1741 MHz)",5, "AMD (Unknown model) (2353 MHz)",5, "Intel Pentium Pro (Unknown model) (661 MHz)",5, "Intel Pentium Pro (Unknown model) (1554 MHz)",5, "Intel Pentium Pro (Unknown model) (2096 MHz)",5, "Intel Pentium 4 Willamette (A-Step) (1399 MHz)",5, "Intel Pentium III (0.18 micron process) with internal L2 cache (647 MHz)",5, "Intel Pentium Pro (Unknown model) (749 MHz)",5, "Intel Pentium 4 (Unknown model) (3472 MHz)",5, "AMD (Unknown model) (2032 MHz)",5, "Intel Pentium Pro (Unknown model) (1737 MHz)",5, "AMD (Unknown model) (2550 MHz)",5, "Intel Pentium Pro (Unknown model) (2771 MHz)",5, "Intel Pentium 4 (Unknown model) (2549 MHz)",5, "AMD (Unknown model) (2883 MHz)",5, "Intel Pentium 4 Northwood (3187 MHz)",5, "Unknown (1492 MHz)",5, "Intel Pentium 4 Northwood (3015 MHz)",5, "Intel Pentium Pro (Unknown model) (751 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1474 MHz)",5, "Intel Pentium Pro (Unknown model) (2560 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1199 MHz)",5, "AMD (Unknown model) (2463 MHz)",5, "Intel Pentium 4 Northwood (3218 MHz)",5, "AMD (Unknown model) (1982 MHz)",5, "AMD (Unknown model) (2880 MHz)",5, "Intel Pentium Pro (Unknown model) (3009 MHz)",5, "AMD K7 (Unknown model) (1323 MHz)",5, "Intel Pentium Pro (Unknown model) (1386 MHz)",5, "Intel Pentium Pro (Unknown model) (2988 MHz)",5, "Intel Pentium 4 (Unknown model) (3755 MHz)",5, "Intel Pentium 4 (Unknown model) (2942 MHz)",5, "Intel Pentium Pro (Unknown model) (2663 MHz)",5, "Intel Pentium Pro (Unknown model) (737 MHz)",5, "AMD (Unknown model) (2591 MHz)",5, "AMD (Unknown model) (2455 MHz)",5, "Intel Pentium 4 Northwood (3090 MHz)",5, "AMD Athlon (Thunderbird core) (1275 MHz)",5, "Intel Pentium 4 Northwood (3016 MHz)",5, "AMD (Unknown model) (1832 MHz)",5, "Intel Pentium Pro (Unknown model) (428 MHz)",5, "PowerPC 7450 (1600 MHz)",5, "Intel Pentium Pro (Unknown model) (748 MHz)",5, "AMD K7 (Unknown model) (1264 MHz)",5, "AMD Athlon (0.25 micron) (499 MHz)",5, "AMD (Unknown model) (2720 MHz)",5, "Intel Pentium Pro (Unknown model) (1005 MHz)",5, "AMD (Unknown model) (2542 MHz)",5, "Intel Pentium 4 (Unknown model) (2691 MHz)",5, "Intel Pentium Pro (Unknown model) (1416 MHz)",5, "Intel Pentium Pro (Unknown model) (1513 MHz)",5, "AMD Athlon (Thunderbird core) (1393 MHz)",5, "Intel Pentium Pro (Unknown model) (504 MHz)",5, "Intel Pentium Pro (Unknown model) (1037 MHz)",5, "Intel Pentium 4 (Unknown model) (3687 MHz)",5, "Intel Pentium 4 Northwood (2726 MHz)",5, "Intel Pentium 4 Northwood (1980 MHz)",5, "AMD (Unknown model) (2506 MHz)",5, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (493 MHz)",5, "Intel Pentium Pro (Unknown model) (1161 MHz)",5, "AMD (Unknown model) (2396 MHz)",5, "AMD (Unknown model) (1830 MHz)",5, "Intel Pentium Pro (Unknown model) (322 MHz)",5, "AMD K7 (Unknown model) (1327 MHz)",5, "AMD (Unknown model) (1876 MHz)",5, "Intel Pentium 4 Willamette (A-Step) (1397 MHz)",5, "Intel Pentium 4 (Unknown model) (3613 MHz)",5, "AMD K7 (Unknown model) (1860 MHz)",5, "Intel Pentium Pro (Unknown model) (2758 MHz)",5, "AMD (Unknown model) (1902 MHz)",5, "AMD (Unknown model) (2072 MHz)",5, "AMD K7 (Unknown model) (2029 MHz)",5, "Intel Pentium Pro (Unknown model) (1580 MHz)",5, "AMD (Unknown model) (2580 MHz)",5, "Intel Pentium 4 Northwood Xeon (2004 MHz)",5, "Intel Pentium Pro (Unknown model) (1356 MHz)",5, "Intel Pentium Pro (Unknown model) (1077 MHz)",5, "Dual i386 (Unknown) (3000 MHz)",5, "AMD (Unknown model) (1616 MHz)",5, "Intel Pentium Pro (Unknown model) (1032 MHz)",5, "Intel Pentium 4 (Unknown model) (2965 MHz)",5, "Intel Pentium Pro (Unknown model) (1509 MHz)",5, "Intel Pentium Pro (Unknown model) (1391 MHz)",5, "Intel Pentium 4 (Unknown model) (3464 MHz)",5, "AMD (Unknown model) (1968 MHz)",5, "Intel Pentium 4 Northwood (2730 MHz)",5, "AMD (Unknown model) (2464 MHz)",5, "Intel Pentium Pro (Unknown model) (1206 MHz)",5, "Intel Pentium Pro (Unknown model) (877 MHz)",5, "AMD (Unknown model) (1835 MHz)",5, "Intel Pentium Pro (Unknown model) (786 MHz)",5, "Intel Pentium Pro (Unknown model) (1164 MHz)",5, "AMD Mobile Duron (Morgan core) (996 MHz)",5, "Intel Pentium Pro (Unknown model) (787 MHz)",5, "AMD (Unknown model) (1868 MHz)",5, "Intel Pentium 4 Northwood (2288 MHz)",5, "Intel Pentium 4 (Unknown model) (2005 MHz)",5, "Intel Pentium Pro (Unknown model) (888 MHz)",5, "AMD (Unknown model) (1594 MHz)",5, "Intel Pentium Pro (Unknown model) (3384 MHz)",5, "Intel Pentium Pro (Unknown model) (1447 MHz)",5, "Intel Pentium Pro (Unknown model) (830 MHz)",5, "AMD K7 (Unknown model) (1719 MHz)",5, "Intel Pentium 4 Northwood (2443 MHz)",5, "AMD (Unknown model) (1996 MHz)",5, "Intel Pentium Pro (Unknown model) (2718 MHz)",5, "Intel Pentium Pro (Unknown model) (1963 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1247 MHz)",5, "Intel Pentium 4 Willamette (A-Step) (1300 MHz)",5, "AMD K7 (Unknown model) (1601 MHz)",5, "Intel Pentium Pro (Unknown model) (696 MHz)",5, "Intel Pentium Pro (Unknown model) (1128 MHz)",5, "Intel Pentium III (0.18 micron process) with internal L2 cache (1007 MHz)",5, "AMD Athlon (Thunderbird core) (1332 MHz)",5, "Intel Pentium Pro (Unknown model) (824 MHz)",5, "AMD (Unknown model) (2526 MHz)",5, "AMD K7 (Unknown model) (1950 MHz)",5, "Intel Pentium 4 Northwood (2240 MHz)",5, "AMD (Unknown model) (2416 MHz)",5, "Intel Pentium Pro (Unknown model) (317 MHz)",5, "AMD Athlon (Thunderbird core) (1330 MHz)",5, "Intel Pentium Pro (Unknown model) (1326 MHz)",5, "Intel Pentium Pro (Unknown model) (1034 MHz)",5, "AMD Athlon (0.18 micron) (700 MHz)",5, "AMD (Unknown model) (2094 MHz)",5, "Intel Pentium Pro (Unknown model) (1985 MHz)",5, "Intel Pentium 4 Northwood (3023 MHz)",5, "Intel Pentium 4 Northwood (2626 MHz)",5, "AMD (Unknown model) (2459 MHz)",5, "Intel Pentium Pro (Unknown model) (699 MHz)",5, "Intel Pentium Pro (Unknown model) (1618 MHz)",5, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1395 MHz)",5, "Intel Celeron (0.18 micron process) with internal L2 cache (1110 MHz)",5, "Intel Pentium II with internal L2 cache (400 MHz)",5, "Intel Pentium 4 (Unknown model) (3320 MHz)",5, "Intel Pentium Pro (Unknown model) (1033 MHz)",5, "AMD K7 (Unknown model) (1240 MHz)",5, "AMD Athlon (Thunderbird core) (1336 MHz)",5, "Intel Pentium 4 (Unknown model) (2720 MHz)",5, "AMD (Unknown model) (1786 MHz)",5, "Intel Pentium Pro (Unknown model) (697 MHz)",5, "AMD (Unknown model) (2238 MHz)",5, "AMD (Unknown model) (1849 MHz)",5, "AMD K7 (Unknown model) (2198 MHz)",5, "Intel Pentium 4 Northwood (3101 MHz)",5, "Intel Pentium 4 (Unknown model) (3090 MHz)",5, "AMD Athlon MP/Mobile Athlon (Palomino core) (1060 MHz)",5, "Intel Pentium Pro (Unknown model) (2592 MHz)",5, "AMD (Unknown model) (2585 MHz)",5, "Intel Pentium Pro (Unknown model) (3003 MHz)",5, "Intel Pentium Pro (Unknown model) (657 MHz)",5, "Intel Pentium Pro (Unknown model) (746 MHz)",5, "AMD (Unknown model) (1386 MHz)",5, "Intel Pentium Pro (Unknown model) (1532 MHz)",5, "Intel Pentium Pro (Unknown model) (1291 MHz)",5, "AMD (Unknown model) (1099 MHz)",5, "Intel Pentium Pro (Unknown model) (1566 MHz)",5, "Intel Pentium Pro (Unknown model) (3466 MHz)",5, "Intel Pentium III (0.18 micron process) with internal L2 cache (501 MHz)",5, "AMD (Unknown model) (575 MHz)",5, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (499 MHz)",5, "Intel Pentium 4 Willamette (A-Step) (1696 MHz)",5, "Intel Pentium 4 (Unknown model) (3027 MHz)",5, "Intel Pentium Pro (Unknown model) (2783 MHz)",5, "Intel Pentium 4 Northwood (3264 MHz)",5, "AMD (Unknown model) (1901 MHz)",5, "Intel Pentium 4 (Unknown model) (2609 MHz)",5, "Intel Pentium 4 (Unknown model) (3240 MHz)",4, "Intel Pentium 4 (Unknown model) (2848 MHz)",4, "AMD Athlon (Thunderbird core) (848 MHz)",4, "AMD (Unknown model) (1859 MHz)",4, "AMD K7 (Unknown model) (1208 MHz)",4, "Intel Pentium Pro (Unknown model) (1418 MHz)",4, "Intel Pentium 4 Willamette (A-Step) (1596 MHz)",4, "Intel Pentium Pro (Unknown model) (954 MHz)",4, "Intel Pentium Pro (Unknown model) (816 MHz)",4, "Intel Pentium 4 (Unknown model) (2946 MHz)",4, "Intel Pentium Pro (Unknown model) (1652 MHz)",4, "Intel Pentium Pro (Unknown model) (2790 MHz)",4, "AMD (Unknown model) (2023 MHz)",4, "Intel Pentium Pro (Unknown model) (624 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (400 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1746 MHz)",4, "AMD K7 (Unknown model) (2156 MHz)",4, "Intel Pentium 4 Northwood Xeon (1699 MHz)",4, "AMD Duron (Spitfire core) (858 MHz)",4, "AMD (Unknown model) (1974 MHz)",4, "Intel Pentium 4 Northwood (2637 MHz)",4, "AMD (Unknown model) (2518 MHz)",4, "Intel Pentium 4 Northwood Xeon (3207 MHz)",4, "Intel Pentium 4 Northwood (2835 MHz)",4, "Intel Pentium 4 Willamette (1497 MHz)",4, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1395 MHz)",4, "AMD (Unknown model) (802 MHz)",4, "Intel Pentium 4 Northwood (2118 MHz)",4, "Intel Pentium Pro (Unknown model) (1450 MHz)",4, "Intel Pentium Pro (Unknown model) (1108 MHz)",4, "AMD K7 (Unknown model) (2027 MHz)",4, "AMD (Unknown model) (2016 MHz)",4, "Intel Pentium Pro (Unknown model) (862 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (662 MHz)",4, "Intel Pentium Pro (Unknown model) (2611 MHz)",4, "Intel Pentium Pro (Unknown model) (1902 MHz)",4, "Intel Pentium Pro (Unknown model) (1026 MHz)",4, "Intel Pentium 4 Northwood (3399 MHz)",4, "AMD (Unknown model) (1984 MHz)",4, "AMD (Unknown model) (2458 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1302 MHz)",4, "Intel Pentium Pro (Unknown model) (1457 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1343 MHz)",4, "Intel Pentium Pro (Unknown model) (950 MHz)",4, "AMD (Unknown model) (1962 MHz)",4, "Dual PowerPC 7450 (1333 MHz)",4, "AMD K7 (Unknown model) (1574 MHz)",4, "AMD (Unknown model) (2081 MHz)",4, "AMD (Unknown model) (1856 MHz)",4, "AMD K7 (Unknown model) (2175 MHz)",4, "Intel Pentium Pro (Unknown model) (2456 MHz)",4, "Intel Pentium 4 Northwood (1815 MHz)",4, "AMD K7 (Unknown model) (1322 MHz)",4, "AMD (Unknown model) (2192 MHz)",4, "Intel Pentium Pro (Unknown model) (1045 MHz)",4, "AMD (Unknown model) (2071 MHz)",4, "AMD K7 (Unknown model) (1413 MHz)",4, "Intel Pentium 4 Northwood Xeon (2391 MHz)",4, "Intel Pentium Pro (Unknown model) (1338 MHz)",4, "AMD Duron (Spitfire core) (901 MHz)",4, "Intel Pentium 4 Northwood Xeon (2000 MHz)",4, "AMD K7 (Unknown model) (2299 MHz)",4, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1328 MHz)",4, "Intel Pentium Pro (Unknown model) (1013 MHz)",4, "Intel Pentium Pro (Unknown model) (698 MHz)",4, "Intel Pentium Pro (Unknown model) (1261 MHz)",4, "Intel Pentium Pro (Unknown model) (2559 MHz)",4, "Intel Pentium 4 Willamette (1602 MHz)",4, "AMD (Unknown model) (2481 MHz)",4, "AMD (Unknown model) (2328 MHz)",4, "AMD (Unknown model) (1925 MHz)",4, "Intel Pentium 4 (Unknown model) (3223 MHz)",4, "Intel Pentium Pro (Unknown model) (1906 MHz)",4, "Intel Pentium 4 Willamette (1717 MHz)",4, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1202 MHz)",4, "Intel Pentium Pro (Unknown model) (706 MHz)",4, "AMD (Unknown model) (2314 MHz)",4, "AMD K7 (Unknown model) (1573 MHz)",4, "Intel Pentium Pro (Unknown model) (1042 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1094 MHz)",4, "Intel Pentium 4 (Unknown model) (3076 MHz)",4, "Intel Pentium 4 (Unknown model) (2395 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (696 MHz)",4, "AMD (Unknown model) (1917 MHz)",4, "AMD (Unknown model) (1969 MHz)",4, "AMD (Unknown model) (1896 MHz)",4, "Intel Pentium 4 (Unknown model) (4087 MHz)",4, "Intel Pentium Pro (Unknown model) (1786 MHz)",4, "AMD K7 (Unknown model) (1391 MHz)",4, "Intel Pentium Pro (Unknown model) (735 MHz)",4, "Intel Pentium Pro (Unknown model) (615 MHz)",4, "Intel Pentium Pro (Unknown model) (745 MHz)",4, "AMD (Unknown model) (1894 MHz)",4, "Intel Pentium Pro (Unknown model) (1751 MHz)",4, "Intel Pentium Pro (Unknown model) (802 MHz)",4, "AMD (Unknown model) (1050 MHz)",4, "Intel Pentium Pro (Unknown model) (858 MHz)",4, "Intel Pentium Pro (Unknown model) (1110 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1325 MHz)",4, "Intel Pentium Pro (Unknown model) (2408 MHz)",4, "Intel Pentium Pro (Unknown model) (969 MHz)",4, "AMD K7 (Unknown model) (1282 MHz)",4, "AMD K7 (Unknown model) (1696 MHz)",4, "Intel Pentium Pro (Unknown model) (1456 MHz)",4, "Intel Pentium 4 Northwood (1403 MHz)",4, "Intel Pentium 4 Northwood (1199 MHz)",4, "AMD K7 (Unknown model) (2249 MHz)",4, "Intel Pentium Pro (Unknown model) (1089 MHz)",4, "Intel Pentium 4 (Unknown model) (3592 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (980 MHz)",4, "AMD (Unknown model) (2157 MHz)",4, "Intel Pentium 4 (Unknown model) (3443 MHz)",4, "AMD Mobile Duron (Morgan core) (1290 MHz)",4, "Intel Pentium 4 (Unknown model) (3025 MHz)",4, "Intel Pentium 4 (Unknown model) (2428 MHz)",4, "Intel Pentium Pro (Unknown model) (963 MHz)",4, "AMD (Unknown model) (2031 MHz)",4, "AMD (Unknown model) (2102 MHz)",4, "Intel Pentium 4 (Unknown model) (3089 MHz)",4, "AMD K7 (Unknown model) (2332 MHz)",4, "Intel Pentium 4 (Unknown model) (3149 MHz)",4, "Intel Pentium Pro (Unknown model) (1407 MHz)",4, "AMD K7 (Unknown model) (2034 MHz)",4, "AMD (Unknown model) (2278 MHz)",4, "Intel Pentium 4 Northwood Xeon (2350 MHz)",4, "Intel Pentium 4 Northwood Xeon (2297 MHz)",4, "AMD (Unknown model) (2271 MHz)",4, "Intel Celeron (0.18 micron process) with internal L2 cache (730 MHz)",4, "Intel Pentium 4 Willamette (1708 MHz)",4, "Intel Pentium 4 (Unknown model) (3428 MHz)",4, "Intel Pentium 4 (Unknown model) (3292 MHz)",4, "AMD (Unknown model) (1754 MHz)",4, "AMD (Unknown model) (1892 MHz)",4, "Intel Pentium 4 (Unknown model) (3438 MHz)",4, "Intel Pentium Pro (Unknown model) (1090 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (599 MHz)",4, "AMD K7 (Unknown model) (1259 MHz)",4, "AMD (Unknown model) (2197 MHz)",4, "Intel Pentium Pro (Unknown model) (2450 MHz)",4, "AMD (Unknown model) (2465 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (748 MHz)",4, "Intel Pentium 4 Northwood (2537 MHz)",4, "AMD (Unknown model) (2324 MHz)",4, "Intel Pentium Pro (Unknown model) (1361 MHz)",4, "Intel Pentium 4 (Unknown model) (3585 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1583 MHz)",4, "Intel Pentium 4 Willamette Xeon (1603 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (928 MHz)",4, "Intel Pentium Pro (Unknown model) (2745 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (1012 MHz)",4, "Intel Pentium 4 (Unknown model) (2656 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1044 MHz)",4, "AMD (Unknown model) (1877 MHz)",4, "Intel Pentium 4 (Unknown model) (2445 MHz)",4, "Intel Pentium Pro (Unknown model) (1075 MHz)",4, "Intel Pentium 4 (Unknown model) (3217 MHz)",4, "AMD (Unknown model) (2089 MHz)",4, "AMD K7 (Unknown model) (2245 MHz)",4, "Intel Pentium Pro (Unknown model) (1049 MHz)",4, "AMD K7 (Unknown model) (1806 MHz)",4, "Intel Pentium Pro (Unknown model) (1360 MHz)",4, "Intel Pentium Pro (Unknown model) (321 MHz)",4, "Intel Pentium 4 Northwood (1500 MHz)",4, "Intel Pentium 4 Northwood Xeon (3003 MHz)",4, "Intel Pentium Pro (Unknown model) (1056 MHz)",4, "AMD K7 (Unknown model) (1126 MHz)",4, "Intel Pentium 4 (Unknown model) (3847 MHz)",4, "Intel Pentium 4 Northwood (2802 MHz)",4, "Intel Pentium 4 Willamette (1897 MHz)",4, "Intel Pentium 4 Northwood (2127 MHz)",4, "AMD (Unknown model) (2170 MHz)",4, "Intel Pentium 4 Willamette (A-Step) (1800 MHz)",4, "Intel Pentium Pro (Unknown model) (426 MHz)",4, "AMD K7 (Unknown model) (1979 MHz)",4, "Intel Pentium 4 (Unknown model) (1492 MHz)",4, "AMD (Unknown model) (2087 MHz)",4, "AMD K7 (Unknown model) (1253 MHz)",4, "Unknown (1002 MHz)",4, "Intel Pentium Pro (Unknown model) (1719 MHz)",4, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (729 MHz)",4, "Intel Pentium Pro (Unknown model) (1897 MHz)",4, "AMD K7 (Unknown model) (928 MHz)",4, "Intel Pentium Pro (Unknown model) (3208 MHz)",4, "AMD K7 (Unknown model) (1471 MHz)",4, "AMD (Unknown model) (2626 MHz)",4, "Intel Pentium Pro (Unknown model) (1754 MHz)",4, "Intel Pentium Pro (Unknown model) (905 MHz)",4, "Intel Pentium Pro (Unknown model) (1434 MHz)",4, "AMD K7 (Unknown model) (1767 MHz)",4, "AMD Athlon (0.18 micron) (598 MHz)",4, "Intel Pentium Pro (Unknown model) (939 MHz)",4, "Intel Pentium 4 Northwood Xeon (2379 MHz)",4, "Intel Pentium 4 Northwood Xeon (1693 MHz)",4, "Intel Pentium Pro (Unknown model) (1357 MHz)",4, "Intel Pentium 4 Northwood Xeon (2292 MHz)",4, "Intel Pentium 4 (Unknown model) (2988 MHz)",4, "AMD K7 (Unknown model) (1606 MHz)",4, "Intel Pentium 4 (Unknown model) (2706 MHz)",4, "AMD K7 (Unknown model) (1720 MHz)",4, "Intel Pentium Pro (Unknown model) (1720 MHz)",4, "AMD K7 (Unknown model) (802 MHz)",4, "AMD (Unknown model) (2690 MHz)",4, "Intel Pentium 4 Northwood (2417 MHz)",4, "AMD (Unknown model) (2290 MHz)",4, "Intel Pentium 4 Willamette (1702 MHz)",4, "AMD Athlon (Thunderbird core) (950 MHz)",4, "AMD K7 (Unknown model) (2039 MHz)",4, "Intel Pentium Pro (Unknown model) (951 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (865 MHz)",4, "AMD K7 (Unknown model) (2022 MHz)",4, "AMD (Unknown model) (1593 MHz)",4, "Intel Pentium Pro (Unknown model) (1837 MHz)",4, "Intel Pentium 4 (Unknown model) (2803 MHz)",4, "AMD (Unknown model) (927 MHz)",4, "Intel Pentium 4 (Unknown model) (3323 MHz)",4, "AMD (Unknown model) (1820 MHz)",4, "Intel Pentium Pro (Unknown model) (1007 MHz)",4, "AMD (Unknown model) (2105 MHz)",4, "Intel Pentium 4 Northwood (3206 MHz)",4, "AMD (Unknown model) (2811 MHz)",4, "Intel Pentium 4 Willamette Xeon (2036 MHz)",4, "AMD Athlon (Thunderbird core) (1299 MHz)",4, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1004 MHz)",4, "Intel Pentium Pro (Unknown model) (1811 MHz)",4, "AMD (Unknown model) (1893 MHz)",4, "AMD (Unknown model) (2168 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1534 MHz)",4, "Intel Pentium 4 Northwood (2573 MHz)",4, "Intel Pentium 4 Northwood (2496 MHz)",4, "Intel Pentium 4 Northwood (1202 MHz)",4, "Intel Pentium Pro (Unknown model) (1031 MHz)",4, "AMD K7 (Unknown model) (2069 MHz)",4, "Intel Pentium 4 Northwood (1694 MHz)",4, "Intel Pentium Pro (Unknown model) (1455 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1154 MHz)",4, "AMD (Unknown model) (2135 MHz)",4, "AMD (Unknown model) (1936 MHz)",4, "AMD (Unknown model) (2793 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (847 MHz)",4, "Intel Pentium 4 Northwood (3017 MHz)",4, "Intel Pentium Pro (Unknown model) (864 MHz)",4, "Intel Pentium Pro (Unknown model) (1382 MHz)",4, "Intel Pentium 4 Willamette Xeon (1690 MHz)",4, "AMD (Unknown model) (2379 MHz)",4, "Intel Pentium Pro (Unknown model) (1092 MHz)",4, "AMD (Unknown model) (1977 MHz)",4, "AMD (Unknown model) (2541 MHz)",4, "AMD (Unknown model) (2142 MHz)",4, "Intel Pentium Pro (Unknown model) (1721 MHz)",4, "AMD (Unknown model) (2391 MHz)",4, "Intel Pentium Pro (Unknown model) (1910 MHz)",4, "AMD Athlon (0.18 micron) (704 MHz)",4, "Intel Pentium Pro (Unknown model) (1029 MHz)",4, "AMD (Unknown model) (2017 MHz)",4, "AMD Athlon (0.18 micron) (800 MHz)",4, "AMD K7 (Unknown model) (1405 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1106 MHz)",4, "Intel Pentium Pro (Unknown model) (1102 MHz)",4, "Intel Pentium 4 (Unknown model) (3588 MHz)",4, "AMD K7 (Unknown model) (1853 MHz)",4, "Intel Pentium 4 (Unknown model) (3225 MHz)",4, "Intel Pentium Pro (Unknown model) (1752 MHz)",4, "AMD K7 (Unknown model) (1608 MHz)",4, "Intel Pentium Pro (Unknown model) (1179 MHz)",4, "AMD (Unknown model) (2607 MHz)",4, "Intel Pentium Pro (Unknown model) (1483 MHz)",4, "AMD (Unknown model) (2524 MHz)",4, "AMD Mobile Duron (Morgan core) (1009 MHz)",4, "Intel Pentium 4 Northwood (2518 MHz)",4, "AMD Duron (Spitfire core) (700 MHz)",4, "AMD Athlon (Thunderbird core) (1198 MHz)",4, "Intel Pentium Pro (Unknown model) (1132 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1193 MHz)",4, "Intel Pentium 4 (Unknown model) (3433 MHz)",4, "AMD Mobile Duron (Morgan core) (1096 MHz)",4, "Intel Pentium 4 Willamette Xeon (1977 MHz)",4, "Intel Pentium Pro (Unknown model) (2997 MHz)",4, "AMD (Unknown model) (1897 MHz)",4, "Intel Pentium 4 (Unknown model) (2453 MHz)",4, "Intel Pentium 4 Northwood (2010 MHz)",4, "Intel Pentium Pro (Unknown model) (1858 MHz)",4, "Intel Pentium Pro (Unknown model) (1163 MHz)",4, "Intel Pentium 4 Willamette Xeon (1797 MHz)",4, "AMD (Unknown model) (1010 MHz)",4, "AMD K7 (Unknown model) (2214 MHz)",4, "AMD Mobile Duron (Morgan core) (1303 MHz)",4, "AMD (Unknown model) (1874 MHz)",4, "AMD K7 (Unknown model) (1903 MHz)",4, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (733 MHz)",4, "AMD K7 (Unknown model) (1127 MHz)",4, "AMD K7 (Unknown model) (2140 MHz)",4, "Intel Pentium Pro (Unknown model) (3207 MHz)",4, "AMD Athlon (Thunderbird core) (857 MHz)",4, "Intel Pentium Pro (Unknown model) (1558 MHz)",4, "Intel Pentium 4 (Unknown model) (2938 MHz)",4, "Intel Pentium Pro (Unknown model) (2447 MHz)",4, "Intel Celeron (0.18 micron process) with internal L2 cache (952 MHz)",4, "AMD K7 (Unknown model) (2013 MHz)",4, "Intel Pentium Pro (Unknown model) (1518 MHz)",4, "Intel Pentium 4 (Unknown model) (3278 MHz)",4, "AMD (Unknown model) (1084 MHz)",4, "AMD K7 (Unknown model) (1346 MHz)",4, "Intel Pentium Pro (Unknown model) (909 MHz)",4, "Intel Pentium Pro (Unknown model) (938 MHz)",4, "Intel Pentium 4 (Unknown model) (2822 MHz)",4, "Intel Pentium 4 (Unknown model) (2922 MHz)",4, "AMD (Unknown model) (2325 MHz)",4, "Intel Pentium Pro (Unknown model) (1238 MHz)",4, "AMD (Unknown model) (2803 MHz)",4, "AMD K7 (Unknown model) (1303 MHz)",4, "Intel Pentium III (0.18 micron process) with internal L2 cache (795 MHz)",4, "AMD (Unknown model) (1947 MHz)",4, "AMD (Unknown model) (2152 MHz)",4, "AMD (Unknown model) (2234 MHz)",4, "AMD (Unknown model) (2334 MHz)",4, "Intel Pentium 4 (Unknown model) (2816 MHz)",4, "Intel Pentium Pro (Unknown model) (1990 MHz)",4, "Intel Pentium 4 (Unknown model) (3451 MHz)",4, "Intel Pentium Pro (Unknown model) (1019 MHz)",4, "Intel Pentium Pro (Unknown model) (1872 MHz)",4, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1193 MHz)",4, "AMD (Unknown model) (1866 MHz)",4, "Intel Pentium Pro (Unknown model) (1649 MHz)",4, "Intel Pentium Pro (Unknown model) (1122 MHz)",4, "Intel Pentium Pro (Unknown model) (3002 MHz)",4, "Intel Pentium 4 Willamette (A-Step) (1816 MHz)",4, "AMD (Unknown model) (1873 MHz)",4, "Intel Pentium 4 (Unknown model) (2873 MHz)",4, "Intel Pentium Pro (Unknown model) (668 MHz)",4, "Intel Pentium Pro (Unknown model) (1009 MHz)",4, "AMD (Unknown model) (2533 MHz)",4, "Intel Pentium Pro (Unknown model) (2158 MHz)",4, "AMD (Unknown model) (2253 MHz)",4, "Intel Pentium 4 Northwood (1862 MHz)",4, "Intel Pentium Pro (Unknown model) (1036 MHz)",4, "AMD Athlon (Thunderbird core) (1197 MHz)",4, "Intel Pentium 4 Northwood Xeon (2357 MHz)",4, "AMD (Unknown model) (1864 MHz)",4, "AMD Duron (Spitfire core) (750 MHz)",4, "Intel Pentium Pro (Unknown model) (741 MHz)",4, "Intel Pentium Pro (Unknown model) (510 MHz)",4, "Intel Pentium 4 (Unknown model) (2673 MHz)",4, "Intel Pentium 4 Northwood (2416 MHz)",4, "Intel Pentium Pro (Unknown model) (754 MHz)",4, "Intel Pentium 4 (Unknown model) (2935 MHz)",4, "Intel Pentium Pro (Unknown model) (734 MHz)",4, "Intel Pentium 4 (Unknown model) (2519 MHz)",4, "Intel Pentium 4 (Unknown model) (3043 MHz)",4, "Intel Pentium Pro (Unknown model) (1266 MHz)",4, "Intel Pentium Pro (Unknown model) (3023 MHz)",4, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1263 MHz)",4, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1262 MHz)",4, "Intel Pentium Pro (Unknown model) (831 MHz)",4, "Intel Pentium 4 (Unknown model) (3648 MHz)",4, "Intel Pentium Pro (Unknown model) (429 MHz)",4, "Intel Pentium Pro (Unknown model) (1516 MHz)",4, "Intel Celeron (0.18 micron process) with internal L2 cache (564 MHz)",4, "Intel Pentium 4 (Unknown model) (1799 MHz)",4, "Intel Pentium 4 Northwood (1890 MHz)",4, "Intel Pentium Pro (Unknown model) (1545 MHz)",4, "Intel Pentium 4 (Unknown model) (2434 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1002 MHz)",4, "Intel Pentium 4 (Unknown model) (3788 MHz)",4, "Intel Pentium 4 Northwood (3105 MHz)",4, "AMD K7 (Unknown model) (1925 MHz)",4, "Intel Pentium 4 Northwood (2293 MHz)",4, "AMD Athlon (Thunderbird core) (746 MHz)",4, "AMD K7 (Unknown model) (1245 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1524 MHz)",4, "AMD (Unknown model) (2242 MHz)",4, "Intel Pentium Pro (Unknown model) (2051 MHz)",4, "AMD (Unknown model) (2229 MHz)",4, "Intel Pentium Pro (Unknown model) (1011 MHz)",4, "Intel Pentium 4 (Unknown model) (3501 MHz)",4, "AMD (Unknown model) (1960 MHz)",4, "Intel Pentium 4 (Unknown model) (2886 MHz)",4, "AMD (Unknown model) (2339 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1687 MHz)",4, "AMD Duron (Spitfire core) (902 MHz)",4, "AMD K7 (Unknown model) (1891 MHz)",4, "AMD (Unknown model) (993 MHz)",4, "Intel Pentium Pro (Unknown model) (981 MHz)",4, "Intel Celeron (0.18 micron process) with internal L2 cache (1000 MHz)",4, "AMD (Unknown model) (2347 MHz)",4, "AMD (Unknown model) (1978 MHz)",4, "Intel Pentium Pro (Unknown model) (1797 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1255 MHz)",4, "Intel Pentium 4 (Unknown model) (2139 MHz)",4, "Intel Pentium 4 Northwood (2529 MHz)",4, "Intel Pentium 4 (Unknown model) (3507 MHz)",4, "Intel Pentium 4 (Unknown model) (2687 MHz)",4, "AMD Athlon (Thunderbird core) (1329 MHz)",4, "Intel Pentium Pro (Unknown model) (1962 MHz)",4, "AMD K7 (Unknown model) (1541 MHz)",4, "AMD K7 (Unknown model) (2266 MHz)",4, "Intel Pentium Pro (Unknown model) (1890 MHz)",4, "Intel Pentium Pro (Unknown model) (1877 MHz)",4, "Intel Pentium 4 Northwood Xeon (2180 MHz)",4, "AMD (Unknown model) (1970 MHz)",4, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1130 MHz)",4, "Intel Pentium 4 Northwood Xeon (2796 MHz)",4, "Intel Pentium Pro (Unknown model) (1657 MHz)",4, "AMD Athlon (Thunderbird core) (1403 MHz)",4, "Intel Pentium 4 Willamette (1647 MHz)",4, "Intel Pentium Pro (Unknown model) (2600 MHz)",4, "AMD (Unknown model) (2153 MHz)",4, "AMD K7 (Unknown model) (1671 MHz)",4, "AMD (Unknown model) (2484 MHz)",4, "AMD K7 (Unknown model) (1815 MHz)",4, "Intel Pentium Pro (Unknown model) (1267 MHz)",4, "AMD K7 (Unknown model) (2016 MHz)",4, "AMD (Unknown model) (2088 MHz)",4, "AMD (Unknown model) (1730 MHz)",4, "Intel Pentium 4 (Unknown model) (2869 MHz)",4, "Intel Pentium Pro (Unknown model) (1433 MHz)",4, "Unknown (1507 MHz)",4, "Intel Pentium Pro (Unknown model) (961 MHz)",4, "AMD (Unknown model) (1030 MHz)",4, "Intel Pentium Pro (Unknown model) (1343 MHz)",4, "AMD (Unknown model) (1822 MHz)",4, "Intel Pentium 4 Northwood Xeon (1202 MHz)",4, "AMD Duron (Spitfire core) (952 MHz)",4, "AMD K7 (Unknown model) (2137 MHz)",4, "AMD (Unknown model) (1871 MHz)",4, "Intel Pentium 4 (Unknown model) (2824 MHz)",4, "AMD K7 (Unknown model) (895 MHz)",4, "Intel Pentium Pro (Unknown model) (937 MHz)",4, "AMD Mobile Duron (Morgan core) (1154 MHz)",4, "Intel Pentium Pro (Unknown model) (2142 MHz)",4, "Intel Pentium Pro (Unknown model) (1475 MHz)",4, "Intel Pentium Pro (Unknown model) (1409 MHz)",4, "AMD K7 (Unknown model) (1448 MHz)",4, "AMD (Unknown model) (2584 MHz)",4, "AMD (Unknown model) (2136 MHz)",4, "Intel Pentium Pro (Unknown model) (2993 MHz)",4, "AMD K7 (Unknown model) (1585 MHz)",4, "AMD K7 (Unknown model) (2123 MHz)",4, "Intel Pentium 4 Northwood (2384 MHz)",4, "AMD (Unknown model) (2456 MHz)",4, "AMD (Unknown model) (2479 MHz)",4, "AMD (Unknown model) (2345 MHz)",4, "AMD (Unknown model) (2262 MHz)",4, "Intel Pentium Pro (Unknown model) (1117 MHz)",4, "Intel Pentium 4 Willamette Xeon (A-Step) (1495 MHz)",4, "Intel Pentium 4 Northwood (3142 MHz)",4, "AMD K7 (Unknown model) (1481 MHz)",4, "AMD (Unknown model) (2308 MHz)",4, "Intel Pentium Pro (Unknown model) (1534 MHz)",4, "Intel Pentium Pro (Unknown model) (728 MHz)",4, "Intel Pentium 4 Northwood (2807 MHz)",4, "Intel Pentium Pro (Unknown model) (813 MHz)",4, "Intel Pentium 4 Willamette (A-Step) (1614 MHz)",4, "Intel Pentium 4 (Unknown model) (3488 MHz)",4, "Intel Pentium 4 (Unknown model) (2908 MHz)",4, "Intel Pentium Pro (Unknown model) (1690 MHz)",4, "Intel Pentium Pro (Unknown model) (902 MHz)",4, "Intel Pentium Pro (Unknown model) (1668 MHz)",4, "AMD Athlon MP/Mobile Athlon (Palomino core) (1336 MHz)",4, "Intel Pentium Pro (Unknown model) (1104 MHz)",4, "Intel Pentium Pro (Unknown model) (2204 MHz)",4, "AMD (Unknown model) (2389 MHz)",4, "Intel Pentium 4 Willamette Xeon (1696 MHz)",4, "AMD K7 (Unknown model) (663 MHz)",4, "Intel Pentium Pro (Unknown model) (957 MHz)",4, "Intel Pentium Pro (Unknown model) (1336 MHz)",4, "AMD (Unknown model) (2551 MHz)",4, "Intel Pentium Pro (Unknown model) (1355 MHz)",4, "Intel Pentium Pro (Unknown model) (1561 MHz)",4, "Intel Pentium Pro (Unknown model) (1655 MHz)",4, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (494 MHz)",4, "AMD K7 (Unknown model) (2225 MHz)",4, "AMD K7 (Unknown model) (2203 MHz)",4, "Intel Pentium 4 Northwood (2226 MHz)",4, "Intel Pentium 4 (Unknown model) (3413 MHz)",4, "AMD (Unknown model) (2423 MHz)",4, "Intel Pentium 4 Northwood Xeon (3055 MHz)",4, "AMD K7 (Unknown model) (1589 MHz)",4, "Intel Celeron (0.18 micron process) with internal L2 cache (994 MHz)",4, "Intel Pentium 4 Northwood Xeon (2455 MHz)",4, "Intel Pentium Pro (Unknown model) (1345 MHz)",4, "Intel Pentium Pro (Unknown model) (2717 MHz)",4, "Intel Pentium Pro (Unknown model) (1016 MHz)",4, "AMD Duron (Spitfire core) (755 MHz)",4, "Intel Pentium 4 Northwood (2296 MHz)",4, "Intel Pentium 4 Northwood Xeon (1691 MHz)",4, "Intel Pentium 4 Northwood (2750 MHz)",4, "Intel Pentium Pro (Unknown model) (1724 MHz)",4, "AMD K7 (Unknown model) (2064 MHz)",4, "AMD (Unknown model) (1837 MHz)",4, "Intel Pentium 4 Northwood (3201 MHz)",4, "Intel Pentium Pro (Unknown model) (596 MHz)",4, "AMD K7 (Unknown model) (1934 MHz)",4, "AMD (Unknown model) (2218 MHz)",4, "Intel Pentium Pro (Unknown model) (2720 MHz)",4, "Intel Pentium 4 (Unknown model) (2669 MHz)",4, "Intel Pentium Pro (Unknown model) (1738 MHz)",4, "Intel Pentium II with internal L2 cache (534 MHz)",3, "AMD Athlon (Thunderbird core) (1196 MHz)",3, "Intel Celeron (0.18 micron process) with internal L2 cache (600 MHz)",3, "AMD (Unknown model) (2428 MHz)",3, "Intel Pentium Pro (Unknown model) (1112 MHz)",3, "AMD (Unknown model) (2124 MHz)",3, "AMD (Unknown model) (1914 MHz)",3, "AMD (Unknown model) (2537 MHz)",3, "AMD (Unknown model) (1967 MHz)",3, "Intel Pentium Pro (Unknown model) (1030 MHz)",3, "Intel Pentium Pro (Unknown model) (1716 MHz)",3, "Intel Pentium 4 (Unknown model) (1403 MHz)",3, "Intel Pentium Pro (Unknown model) (1023 MHz)",3, "AMD (Unknown model) (2063 MHz)",3, "AMD (Unknown model) (1921 MHz)",3, "Intel Pentium 4 Northwood (2295 MHz)",3, "AMD K7 (Unknown model) (1955 MHz)",3, "AMD (Unknown model) (1598 MHz)",3, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1063 MHz)",3, "AMD (Unknown model) (1955 MHz)",3, "Intel Pentium 4 Northwood (2128 MHz)",3, "AMD (Unknown model) (2528 MHz)",3, "Intel Pentium Pro (Unknown model) (506 MHz)",3, "Intel Pentium Pro (Unknown model) (619 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1197 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (853 MHz)",3, "AMD K7 (Unknown model) (897 MHz)",3, "AMD (Unknown model) (2577 MHz)",3, "Intel Pentium 4 (Unknown model) (4020 MHz)",3, "Intel Pentium 4 Northwood (2615 MHz)",3, "AMD (Unknown model) (2383 MHz)",3, "AMD (Unknown model) (2351 MHz)",3, "AMD (Unknown model) (2292 MHz)",3, "Intel Pentium Pro (Unknown model) (882 MHz)",3, "AMD K7 (Unknown model) (1701 MHz)",3, "AMD Athlon (Thunderbird core) (1406 MHz)",3, "AMD Athlon (Thunderbird core) (1339 MHz)",3, "Intel Pentium Pro (Unknown model) (1055 MHz)",3, "Intel Pentium Pro (Unknown model) (1515 MHz)",3, "Intel Pentium Pro (Unknown model) (801 MHz)",3, "AMD (Unknown model) (1906 MHz)",3, "Intel Pentium 4 (Unknown model) (3110 MHz)",3, "AMD K7 (Unknown model) (1404 MHz)",3, "Intel Pentium Pro (Unknown model) (1857 MHz)",3, "Intel Pentium 4 Willamette Xeon (1692 MHz)",3, "AMD (Unknown model) (2468 MHz)",3, "AMD (Unknown model) (1590 MHz)",3, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1300 MHz)",3, "Intel Pentium 4 Northwood (1899 MHz)",3, "AMD Mobile Duron (Morgan core) (1259 MHz)",3, "AMD (Unknown model) (2446 MHz)",3, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (398 MHz)",3, "Intel Pentium 4 (Unknown model) (2758 MHz)",3, "Intel Pentium Pro (Unknown model) (1774 MHz)",3, "Intel Pentium Pro (Unknown model) (1006 MHz)",3, "Intel Pentium Pro (Unknown model) (557 MHz)",3, "Intel Pentium Pro (Unknown model) (1105 MHz)",3, "Intel Pentium Pro (Unknown model) (1464 MHz)",3, "AMD K7 (Unknown model) (1330 MHz)",3, "AMD (Unknown model) (2180 MHz)",3, "Intel Pentium Pro (Unknown model) (2928 MHz)",3, "AMD (Unknown model) (2068 MHz)",3, "AMD K7 (Unknown model) (2111 MHz)",3, "AMD Athlon (0.25 micron) (598 MHz)",3, "AMD (Unknown model) (1907 MHz)",3, "AMD (Unknown model) (2184 MHz)",3, "AMD K7 (Unknown model) (1045 MHz)",3, "Intel Pentium Pro (Unknown model) (3198 MHz)",3, "Dual i386 (Unknown) (1860 MHz)",3, "Intel Pentium Pro (Unknown model) (1471 MHz)",3, "Intel Pentium Pro (Unknown model) (1181 MHz)",3, "Intel Pentium Pro (Unknown model) (1449 MHz)",3, "Intel Pentium Pro (Unknown model) (1736 MHz)",3, "Intel Pentium Pro (Unknown model) (1157 MHz)",3, "AMD (Unknown model) (2493 MHz)",3, "AMD (Unknown model) (1763 MHz)",3, "Intel Pentium Pro (Unknown model) (823 MHz)",3, "Intel Pentium Pro (Unknown model) (2396 MHz)",3, "Intel Pentium 4 Northwood (1979 MHz)",3, "Intel Pentium 4 Willamette (2019 MHz)",3, "AMD K7 (Unknown model) (1727 MHz)",3, "Intel Pentium 4 (Unknown model) (3618 MHz)",3, "Intel Pentium Pro (Unknown model) (1750 MHz)",3, "AMD K7 (Unknown model) (1311 MHz)",3, "AMD (Unknown model) (2439 MHz)",3, "Intel Pentium 4 (Unknown model) (6861 MHz)",3, "Intel Pentium Pro (Unknown model) (1490 MHz)",3, "Intel Pentium Pro (Unknown model) (1486 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1605 MHz)",3, "Intel Pentium 4 (Unknown model) (2529 MHz)",3, "AMD (Unknown model) (1205 MHz)",3, "AMD (Unknown model) (1263 MHz)",3, "Intel Pentium Pro (Unknown model) (508 MHz)",3, "Intel Pentium Pro (Unknown model) (2931 MHz)",3, "Intel Pentium 4 Northwood (2739 MHz)",3, "Intel Pentium 4 (Unknown model) (2818 MHz)",3, "Intel Pentium 4 Willamette Xeon (1708 MHz)",3, "Intel Pentium Pro (Unknown model) (1766 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1141 MHz)",3, "PowerPC 7450 (2000 MHz)",3, "Intel Pentium 4 Northwood (2269 MHz)",3, "Intel Pentium 4 (Unknown model) (3050 MHz)",3, "AMD (Unknown model) (2370 MHz)",3, "Intel Pentium 4 (Unknown model) (3586 MHz)",3, "Intel Pentium Pro (Unknown model) (1256 MHz)",3, "Intel Pentium Pro (Unknown model) (1109 MHz)",3, "Intel Pentium Pro (Unknown model) (742 MHz)",3, "Intel Pentium Pro (Unknown model) (3330 MHz)",3, "Intel Pentium 4 Willamette (1998 MHz)",3, "AMD Athlon (Thunderbird core) (1057 MHz)",3, "Intel Pentium Pro (Unknown model) (1767 MHz)",3, "Intel Pentium Pro (Unknown model) (1651 MHz)",3, "Intel Pentium 4 Northwood Xeon (3192 MHz)",3, "AMD K7 (Unknown model) (2226 MHz)",3, "AMD (Unknown model) (2261 MHz)",3, "Intel Pentium Pro (Unknown model) (1028 MHz)",3, "AMD Mobile Duron (Morgan core) (1208 MHz)",3, "Intel Pentium Pro (Unknown model) (1645 MHz)",3, "Intel Pentium Pro (Unknown model) (2266 MHz)",3, "Intel Pentium Pro (Unknown model) (1127 MHz)",3, "AMD (Unknown model) (2321 MHz)",3, "Intel Pentium Pro (Unknown model) (2688 MHz)",3, "AMD (Unknown model) (1089 MHz)",3, "Intel Pentium Pro (Unknown model) (771 MHz)",3, "Intel Pentium Pro (Unknown model) (1351 MHz)",3, "AMD (Unknown model) (1104 MHz)",3, "Intel Pentium 4 Northwood (2327 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (498 MHz)",3, "AMD (Unknown model) (2783 MHz)",3, "Intel Pentium 4 (Unknown model) (2640 MHz)",3, "AMD (Unknown model) (1129 MHz)",3, "Intel Pentium 4 (Unknown model) (3321 MHz)",3, "Intel Pentium Pro (Unknown model) (974 MHz)",3, "Intel Pentium Pro (Unknown model) (861 MHz)",3, "Intel Pentium Pro (Unknown model) (1211 MHz)",3, "Intel Pentium Pro (Unknown model) (1473 MHz)",3, "AMD K7 (Unknown model) (1986 MHz)",3, "Intel Pentium Pro (Unknown model) (1349 MHz)",3, "Intel Pentium Pro (Unknown model) (1017 MHz)",3, "Intel Pentium Pro (Unknown model) (834 MHz)",3, "Intel Pentium Pro (Unknown model) (1209 MHz)",3, "Intel Pentium Pro (Unknown model) (2939 MHz)",3, "AMD K7 (Unknown model) (1569 MHz)",3, "Intel Pentium Pro (Unknown model) (3010 MHz)",3, "AMD (Unknown model) (2179 MHz)",3, "Intel Pentium 4 Northwood (2060 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1499 MHz)",3, "AMD (Unknown model) (1080 MHz)",3, "Intel Pentium Pro (Unknown model) (2031 MHz)",3, "Intel Pentium Pro (Unknown model) (2424 MHz)",3, "Intel Pentium Pro (Unknown model) (644 MHz)",3, "AMD K7 (Unknown model) (1754 MHz)",3, "AMD (Unknown model) (1415 MHz)",3, "AMD (Unknown model) (2013 MHz)",3, "Intel Pentium Pro (Unknown model) (1548 MHz)",3, "Intel Pentium 4 (Unknown model) (2740 MHz)",3, "Intel Pentium 4 (Unknown model) (2945 MHz)",3, "AMD K7 (Unknown model) (1760 MHz)",3, "AMD Athlon (0.18 micron) (801 MHz)",3, "AMD K7 (Unknown model) (1709 MHz)",3, "Intel Pentium 4 Northwood (2379 MHz)",3, "AMD Athlon (Thunderbird core) (1405 MHz)",3, "Intel Pentium 4 (Unknown model) (3329 MHz)",3, "Intel Pentium Pro (Unknown model) (1240 MHz)",3, "AMD (Unknown model) (1322 MHz)",3, "Intel Pentium 4 (Unknown model) (3485 MHz)",3, "Intel Pentium 4 (Unknown model) (3403 MHz)",3, "AMD (Unknown model) (2431 MHz)",3, "AMD Athlon (0.18 micron) (701 MHz)",3, "AMD K7 (Unknown model) (1331 MHz)",3, "AMD Athlon (0.18 micron) (648 MHz)",3, "Intel Pentium 4 Northwood (2556 MHz)",3, "Intel Pentium Pro (Unknown model) (1441 MHz)",3, "Intel Pentium Pro (Unknown model) (480 MHz)",3, "Intel Pentium Pro (Unknown model) (1701 MHz)",3, "AMD (Unknown model) (1965 MHz)",3, "Intel Pentium 4 Northwood (2462 MHz)",3, "AMD (Unknown model) (1891 MHz)",3, "AMD K7 (Unknown model) (1178 MHz)",3, "AMD (Unknown model) (2473 MHz)",3, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1108 MHz)",3, "Intel Pentium Pro (Unknown model) (431 MHz)",3, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1132 MHz)",3, "Intel Pentium Pro (Unknown model) (1929 MHz)",3, "Intel Pentium Pro (Unknown model) (434 MHz)",3, "Intel Pentium 4 Willamette (1996 MHz)",3, "Intel Pentium Pro (Unknown model) (3294 MHz)",3, "AMD (Unknown model) (1959 MHz)",3, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (333 MHz)",3, "Intel Pentium Pro (Unknown model) (1675 MHz)",3, "Intel Pentium 4 Northwood (2867 MHz)",3, "AMD (Unknown model) (2504 MHz)",3, "AMD (Unknown model) (1941 MHz)",3, "AMD (Unknown model) (2169 MHz)",3, "Intel Pentium 4 Northwood (2362 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1293 MHz)",3, "Intel Pentium Pro (Unknown model) (803 MHz)",3, "AMD (Unknown model) (2578 MHz)",3, "AMD (Unknown model) (2433 MHz)",3, "AMD (Unknown model) (1615 MHz)",3, "AMD (Unknown model) (1953 MHz)",3, "AMD K7 (Unknown model) (2187 MHz)",3, "AMD (Unknown model) (2556 MHz)",3, "AMD Athlon (Thunderbird core) (858 MHz)",3, "Intel Pentium 4 Northwood (2608 MHz)",3, "Intel Pentium Pro (Unknown model) (1563 MHz)",3, "Intel Pentium Pro (Unknown model) (582 MHz)",3, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1135 MHz)",3, "AMD (Unknown model) (1910 MHz)",3, "Intel Pentium Pro (Unknown model) (695 MHz)",3, "AMD (Unknown model) (1698 MHz)",3, "AMD (Unknown model) (2187 MHz)",3, "Intel Pentium 4 (Unknown model) (3455 MHz)",3, "Intel Pentium Pro (Unknown model) (1446 MHz)",3, "AMD (Unknown model) (1938 MHz)",3, "Intel Pentium Pro (Unknown model) (605 MHz)",3, "Intel Pentium Pro (Unknown model) (1704 MHz)",3, "Intel Pentium 4 Northwood (2415 MHz)",3, "Intel Pentium 4 Willamette (A-Step) (1804 MHz)",3, "AMD K7 (Unknown model) (944 MHz)",3, "Intel Pentium Pro (Unknown model) (1620 MHz)",3, "Intel Pentium Pro (Unknown model) (2157 MHz)",3, "Intel Pentium Pro (Unknown model) (1208 MHz)",3, "Intel Pentium Pro (Unknown model) (456 MHz)",3, "Intel Pentium 4 Northwood (3107 MHz)",3, "AMD (Unknown model) (2291 MHz)",3, "Intel Pentium 4 (Unknown model) (2725 MHz)",3, "Intel Pentium Pro (Unknown model) (870 MHz)",3, "Intel Pentium Pro (Unknown model) (1166 MHz)",3, "Intel Pentium 4 Willamette (1496 MHz)",3, "Intel Pentium Pro (Unknown model) (1377 MHz)",3, "AMD Duron (Spitfire core) (847 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1337 MHz)",3, "Intel Pentium Pro (Unknown model) (1106 MHz)",3, "Intel Pentium Pro (Unknown model) (876 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (885 MHz)",3, "Intel Pentium Pro (Unknown model) (1054 MHz)",3, "AMD (Unknown model) (1617 MHz)",3, "Intel Pentium 4 (Unknown model) (3841 MHz)",3, "Intel Pentium Pro (Unknown model) (812 MHz)",3, "Intel Pentium 4 Northwood (3012 MHz)",3, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1205 MHz)",3, "Intel Pentium 4 (Unknown model) (3610 MHz)",3, "AMD K7 (Unknown model) (1605 MHz)",3, "Intel Pentium Pro (Unknown model) (871 MHz)",3, "Intel Pentium Pro (Unknown model) (3015 MHz)",3, "AMD (Unknown model) (2033 MHz)",3, "Intel Pentium 4 Northwood (2627 MHz)",3, "AMD (Unknown model) (2429 MHz)",3, "Intel Pentium Pro (Unknown model) (733 MHz)",3, "Intel Pentium Pro (Unknown model) (2339 MHz)",3, "Intel Pentium 4 Northwood (1870 MHz)",3, "Intel Pentium Pro (Unknown model) (2807 MHz)",3, "Intel Pentium Pro (Unknown model) (763 MHz)",3, "Intel Pentium 4 (Unknown model) (1499 MHz)",3, "AMD K7 (Unknown model) (933 MHz)",3, "Intel Pentium Pro (Unknown model) (1559 MHz)",3, "Intel Pentium 4 (Unknown model) (2982 MHz)",3, "Intel Pentium Pro (Unknown model) (773 MHz)",3, "Intel Pentium 4 Northwood (1399 MHz)",3, "Intel Pentium Pro (Unknown model) (1359 MHz)",3, "Intel Pentium Pro (Unknown model) (1879 MHz)",3, "Intel Pentium Pro (Unknown model) (1905 MHz)",3, "AMD Athlon (0.18 micron) (798 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1729 MHz)",3, "Intel Pentium Pro (Unknown model) (2491 MHz)",3, "Intel Pentium 4 Willamette Xeon (1698 MHz)",3, "Intel Pentium 4 (Unknown model) (2126 MHz)",3, "Intel Pentium 4 Willamette (1791 MHz)",3, "AMD (Unknown model) (989 MHz)",3, "AMD (Unknown model) (1815 MHz)",3, "Intel Pentium Pro (Unknown model) (1979 MHz)",3, "Intel Pentium Pro (Unknown model) (1723 MHz)",3, "AMD (Unknown model) (2422 MHz)",3, "AMD K7 (Unknown model) (997 MHz)",3, "AMD (Unknown model) (2514 MHz)",3, "Intel Pentium 4 Willamette (A-Step) (1412 MHz)",3, "Intel Pentium 4 Northwood (2274 MHz)",3, "Intel Pentium 4 Northwood (2290 MHz)",3, "Intel Pentium 4 (Unknown model) (3018 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (982 MHz)",3, "AMD (Unknown model) (2258 MHz)",3, "Intel Pentium 4 (Unknown model) (3582 MHz)",3, "Intel Pentium Pro (Unknown model) (1835 MHz)",3, "Intel Pentium Pro (Unknown model) (781 MHz)",3, "AMD K7 (Unknown model) (1879 MHz)",3, "Intel Pentium 4 Northwood (2188 MHz)",3, "Intel Pentium 4 Northwood (3514 MHz)",3, "AMD (Unknown model) (829 MHz)",3, "AMD (Unknown model) (2597 MHz)",3, "Intel Pentium Pro (Unknown model) (729 MHz)",3, "Intel Pentium Pro (Unknown model) (1711 MHz)",3, "Intel Pentium Pro (Unknown model) (1702 MHz)",3, "AMD K7 (Unknown model) (1869 MHz)",3, "Intel Pentium 4 Northwood (1400 MHz)",3, "Intel Pentium Pro (Unknown model) (1648 MHz)",3, "Intel Pentium Pro (Unknown model) (1018 MHz)",3, "AMD K7 (Unknown model) (1515 MHz)",3, "Intel Pentium Pro (Unknown model) (1365 MHz)",3, "AMD (Unknown model) (3006 MHz)",3, "AMD (Unknown model) (992 MHz)",3, "Intel Pentium 4 Willamette (A-Step) (1295 MHz)",3, "Intel Pentium 4 Northwood (2933 MHz)",3, "AMD K7 (Unknown model) (1863 MHz)",3, "AMD (Unknown model) (1739 MHz)",3, "Intel Pentium Pro (Unknown model) (1335 MHz)",3, "AMD (Unknown model) (1736 MHz)",3, "Intel Pentium 4 (Unknown model) (3567 MHz)",3, "Intel Pentium Pro (Unknown model) (772 MHz)",3, "Intel Pentium Pro (Unknown model) (1432 MHz)",3, "AMD (Unknown model) (2488 MHz)",3, "AMD K7 (Unknown model) (2067 MHz)",3, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (450 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1240 MHz)",3, "AMD (Unknown model) (2252 MHz)",3, "Intel Pentium 4 (Unknown model) (1515 MHz)",3, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (994 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1594 MHz)",3, "AMD K7 (Unknown model) (2047 MHz)",3, "Intel Pentium Pro (Unknown model) (1631 MHz)",3, "AMD Athlon (Thunderbird core) (1397 MHz)",3, "AMD (Unknown model) (2040 MHz)",3, "AMD K7 (Unknown model) (1690 MHz)",3, "AMD K7 (Unknown model) (2063 MHz)",3, "Intel Pentium Pro (Unknown model) (632 MHz)",3, "AMD Duron (Spitfire core) (757 MHz)",3, "Intel Pentium 4 (Unknown model) (3409 MHz)",3, "Intel Pentium Pro (Unknown model) (1192 MHz)",3, "Intel Pentium 4 (Unknown model) (2657 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (746 MHz)",3, "AMD Mobile Duron (Morgan core) (1099 MHz)",3, "AMD K7 (Unknown model) (1779 MHz)",3, "Intel Pentium Pro (Unknown model) (1537 MHz)",3, "Intel Pentium 4 Northwood (1693 MHz)",3, "Intel Pentium Pro (Unknown model) (4000 MHz)",3, "Intel Pentium 4 Northwood Xeon (1979 MHz)",3, "Intel Pentium Pro (Unknown model) (1921 MHz)",3, "AMD (Unknown model) (936 MHz)",3, "Intel Pentium Pro (Unknown model) (690 MHz)",3, "Intel Pentium 4 (Unknown model) (4384 MHz)",3, "AMD (Unknown model) (2349 MHz)",3, "Intel Pentium Pro (Unknown model) (1087 MHz)",3, "AMD K7 (Unknown model) (2060 MHz)",3, "AMD (Unknown model) (1860 MHz)",3, "Intel Pentium 4 (Unknown model) (2134 MHz)",3, "Intel Pentium 4 Northwood (2431 MHz)",3, "AMD (Unknown model) (2827 MHz)",3, "AMD (Unknown model) (2538 MHz)",3, "AMD K7 (Unknown model) (2405 MHz)",3, "AMD (Unknown model) (2233 MHz)",3, "Dual PowerPC 7450 (1500 MHz)",3, "Dual i386 (Unknown) (1870 MHz)",3, "Intel Pentium Pro (Unknown model) (1519 MHz)",3, "Unknown (1599 MHz)",3, "AMD (Unknown model) (1163 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1398 MHz)",3, "Intel Pentium 4 Northwood (2463 MHz)",3, "AMD (Unknown model) (1164 MHz)",3, "AMD (Unknown model) (884 MHz)",3, "Intel Pentium 4 Northwood (1499 MHz)",3, "Intel Pentium 4 Northwood (2216 MHz)",3, "Intel Pentium Pro (Unknown model) (712 MHz)",3, "AMD K7 (Unknown model) (1468 MHz)",3, "AMD (Unknown model) (1174 MHz)",3, "Intel Pentium Pro (Unknown model) (707 MHz)",3, "Intel Pentium 4 (Unknown model) (3840 MHz)",3, "AMD (Unknown model) (1053 MHz)",3, "AMD (Unknown model) (2316 MHz)",3, "Intel Pentium 4 (Unknown model) (3188 MHz)",3, "AMD (Unknown model) (2343 MHz)",3, "Intel Pentium Pro (Unknown model) (2670 MHz)",3, "Intel Pentium 4 (Unknown model) (1999 MHz)",3, "Intel Pentium Pro (Unknown model) (1581 MHz)",3, "Intel Pentium 4 (Unknown model) (1862 MHz)",3, "Intel Pentium 4 (Unknown model) (3723 MHz)",3, "AMD (Unknown model) (1024 MHz)",3, "Unknown (997 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (807 MHz)",3, "Intel Pentium 4 (Unknown model) (3607 MHz)",3, "AMD K7 (Unknown model) (2128 MHz)",3, "Intel Pentium Pro (Unknown model) (1479 MHz)",3, "AMD (Unknown model) (1223 MHz)",3, "AMD (Unknown model) (1011 MHz)",3, "AMD (Unknown model) (2531 MHz)",3, "Intel Pentium Pro (Unknown model) (3195 MHz)",3, "Intel Pentium 4 (Unknown model) (3431 MHz)",3, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (504 MHz)",3, "AMD (Unknown model) (2573 MHz)",3, "AMD (Unknown model) (1027 MHz)",3, "Intel Pentium Pro (Unknown model) (2475 MHz)",3, "AMD (Unknown model) (1589 MHz)",3, "AMD (Unknown model) (2377 MHz)",3, "Intel Pentium 4 Willamette (2024 MHz)",3, "AMD (Unknown model) (2103 MHz)",3, "Intel Pentium Pro (Unknown model) (1038 MHz)",3, "AMD K7 (Unknown model) (1842 MHz)",3, "Dual PowerPC 7400 (2000 MHz)",3, "AMD (Unknown model) (823 MHz)",3, "Intel Pentium Pro (Unknown model) (1761 MHz)",3, "AMD (Unknown model) (1731 MHz)",3, "AMD (Unknown model) (2028 MHz)",3, "Intel Pentium 4 (Unknown model) (3565 MHz)",3, "Intel Pentium Pro (Unknown model) (2609 MHz)",3, "Intel Pentium Pro (Unknown model) (673 MHz)",3, "Intel Pentium Pro (Unknown model) (427 MHz)",3, "Intel Pentium Pro (Unknown model) (662 MHz)",3, "Intel Pentium Pro (Unknown model) (1276 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1297 MHz)",3, "AMD K7 (Unknown model) (1985 MHz)",3, "Intel Pentium 4 Northwood (2374 MHz)",3, "AMD (Unknown model) (1082 MHz)",3, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1407 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1334 MHz)",3, "Intel Pentium Pro (Unknown model) (1182 MHz)",3, "AMD (Unknown model) (1179 MHz)",3, "AMD Mobile Duron (Morgan core) (1109 MHz)",3, "Intel Pentium Pro (Unknown model) (1504 MHz)",3, "Intel Pentium 4 Northwood (1917 MHz)",3, "AMD K7 (Unknown model) (738 MHz)",3, "Intel Pentium Pro (Unknown model) (2486 MHz)",3, "AMD K7 (Unknown model) (2160 MHz)",3, "Intel Pentium Pro (Unknown model) (1083 MHz)",3, "AMD (Unknown model) (1141 MHz)",3, "AMD K7 (Unknown model) (1926 MHz)",3, "AMD K7 (Unknown model) (1768 MHz)",3, "Intel Pentium Pro (Unknown model) (2139 MHz)",3, "Intel Pentium 4 (Unknown model) (3044 MHz)",3, "Intel Pentium 4 Northwood (2817 MHz)",3, "Intel Pentium Pro (Unknown model) (1116 MHz)",3, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1351 MHz)",3, "AMD K7 (Unknown model) (2323 MHz)",3, "Intel Pentium Pro (Unknown model) (1411 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (1049 MHz)",3, "AMD (Unknown model) (1875 MHz)",3, "Intel Pentium 4 Northwood (2189 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1000 MHz)",3, "Intel Pentium 4 Willamette (1713 MHz)",3, "AMD (Unknown model) (2269 MHz)",3, "AMD (Unknown model) (2809 MHz)",3, "Intel Pentium Pro (Unknown model) (1046 MHz)",3, "AMD (Unknown model) (2035 MHz)",3, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1100 MHz)",3, "Intel Pentium II with internal L2 cache (434 MHz)",3, "Intel Pentium Pro (Unknown model) (1901 MHz)",3, "Intel Pentium Pro (Unknown model) (1186 MHz)",3, "AMD (Unknown model) (2118 MHz)",3, "Intel Pentium Pro (Unknown model) (3064 MHz)",3, "Intel Pentium Pro (Unknown model) (2002 MHz)",3, "Intel Pentium 4 Northwood (3010 MHz)",3, "AMD (Unknown model) (2134 MHz)",3, "Intel Pentium Pro (Unknown model) (1155 MHz)",3, "Intel Pentium Pro (Unknown model) (942 MHz)",3, "Intel Pentium Pro (Unknown model) (617 MHz)",3, "Intel Pentium 4 Northwood",3, "Intel Celeron (0.18 micron process) with internal L2 cache (798 MHz)",3, "Intel Pentium Pro (Unknown model) (956 MHz)",3, "Intel Pentium Pro (Unknown model) (1332 MHz)",3, "Intel Pentium Pro (Unknown model) (1505 MHz)",3, "Intel Pentium 4 (Unknown model) (3388 MHz)",3, "AMD (Unknown model) (1130 MHz)",3, "Intel Pentium 4 Northwood (1495 MHz)",3, "Intel Pentium 4 Willamette (A-Step) (1685 MHz)",3, "AMD (Unknown model) (2448 MHz)",3, "AMD (Unknown model) (2513 MHz)",3, "AMD (Unknown model) (2181 MHz)",3, "Intel Pentium 4 Northwood (2097 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1215 MHz)",3, "AMD (Unknown model) (2130 MHz)",3, "AMD (Unknown model) (1646 MHz)",3, "Intel Pentium 4 (Unknown model) (2318 MHz)",3, "Intel Pentium Pro (Unknown model) (656 MHz)",3, "Intel Pentium Pro (Unknown model) (3420 MHz)",3, "AMD K7 (Unknown model) (2007 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1047 MHz)",3, "AMD (Unknown model) (1148 MHz)",3, "Intel Pentium Pro (Unknown model) (2224 MHz)",3, "AMD K7 (Unknown model) (2095 MHz)",3, "AMD (Unknown model) (1735 MHz)",3, "AMD Athlon (Thunderbird core) (948 MHz)",3, "AMD K7 (Unknown model) (1978 MHz)",3, "AMD (Unknown model) (2090 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (646 MHz)",3, "Intel Pentium Pro (Unknown model) (3374 MHz)",3, "AMD K7 (Unknown model) (2333 MHz)",3, "AMD K7 (Unknown model) (1508 MHz)",3, "Intel Pentium Pro (Unknown model) (1242 MHz)",3, "Intel Pentium Pro (Unknown model) (821 MHz)",3, "Intel Pentium 4 (Unknown model) (2521 MHz)",3, "Intel Pentium 4 Willamette Xeon (A-Step) (1395 MHz)",3, "Intel Pentium Pro (Unknown model) (2238 MHz)",3, "Intel Pentium 4 (Unknown model) (3917 MHz)",3, "Intel Pentium Pro (Unknown model) (1958 MHz)",3, "Intel Pentium 4 (Unknown model) (3503 MHz)",3, "Intel Pentium 4 Northwood (2036 MHz)",3, "AMD (Unknown model) (2796 MHz)",3, "AMD K7 (Unknown model) (1267 MHz)",3, "Intel Pentium 4 (Unknown model) (3173 MHz)",3, "Intel Pentium Pro (Unknown model) (1255 MHz)",3, "Intel Pentium Pro (Unknown model) (966 MHz)",3, "AMD (Unknown model) (2390 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1205 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1204 MHz)",3, "AMD (Unknown model) (2606 MHz)",3, "Intel Pentium 4 Northwood (1300 MHz)",3, "Intel Celeron (0.18 micron process) with internal L2 cache (787 MHz)",3, "AMD K7 (Unknown model) (1437 MHz)",3, "Intel Pentium 4 Northwood (2232 MHz)",3, "Intel Pentium Pro (Unknown model) (1354 MHz)",3, "Intel Pentium Pro (Unknown model) (2187 MHz)",3, "Intel Pentium 4 Northwood (1502 MHz)",3, "Intel Pentium 4 Northwood (3457 MHz)",3, "AMD (Unknown model) (1018 MHz)",3, "Intel Pentium Pro (Unknown model) (1646 MHz)",3, "AMD (Unknown model) (1950 MHz)",3, "AMD (Unknown model) (2257 MHz)",3, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1259 MHz)",3, "Intel Pentium Pro (Unknown model) (2899 MHz)",3, "AMD (Unknown model) (2452 MHz)",3, "AMD (Unknown model) (1948 MHz)",3, "AMD K7 (Unknown model) (992 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (979 MHz)",3, "Intel Pentium 4 Willamette (1483 MHz)",3, "Intel Pentium 4 Northwood (3001 MHz)",3, "Intel Pentium Pro (Unknown model) (775 MHz)",3, "Intel Pentium 4 Northwood (2016 MHz)",3, "Intel Pentium Pro (Unknown model) (1352 MHz)",3, "AMD (Unknown model) (1943 MHz)",3, "AMD (Unknown model) (1913 MHz)",3, "Intel Pentium 4 (Unknown model) (1410 MHz)",3, "Intel Pentium Pro (Unknown model) (1759 MHz)",3, "AMD K7 (Unknown model) (1054 MHz)",3, "Intel Pentium Pro (Unknown model) (630 MHz)",3, "Intel Pentium 4 Northwood (3024 MHz)",3, "AMD (Unknown model) (1101 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1395 MHz)",3, "AMD (Unknown model) (2579 MHz)",3, "Intel Pentium Pro (Unknown model) (2449 MHz)",3, "Intel Pentium 4 (Unknown model) (3450 MHz)",3, "AMD (Unknown model) (842 MHz)",3, "Intel Pentium 4 Northwood (2696 MHz)",3, "Intel Pentium 4 Willamette (1854 MHz)",3, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (391 MHz)",3, "Intel Pentium Pro (Unknown model) (1119 MHz)",3, "Intel Pentium Pro (Unknown model) (1458 MHz)",3, "Intel Celeron (0.18 micron process) with internal L2 cache (631 MHz)",3, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1211 MHz)",3, "AMD (Unknown model) (1442 MHz)",3, "Intel Pentium Pro (Unknown model) (689 MHz)",3, "Intel Pentium Pro (Unknown model) (1673 MHz)",3, "Intel Pentium Pro (Unknown model) (3500 MHz)",3, "AMD (Unknown model) (2119 MHz)",3, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1402 MHz)",3, "AMD K7 (Unknown model) (1759 MHz)",3, "Intel Pentium 4 Willamette (1506 MHz)",3, "Intel Pentium Pro (Unknown model) (2141 MHz)",3, "Intel Pentium Pro (Unknown model) (1379 MHz)",3, "AMD (Unknown model) (1191 MHz)",3, "AMD K7 (Unknown model) (1898 MHz)",3, "AMD (Unknown model) (2244 MHz)",3, "Intel Pentium Pro (Unknown model) (765 MHz)",3, "Intel Pentium 4 (Unknown model) (2762 MHz)",3, "Intel Pentium 4 Northwood (2457 MHz)",3, "AMD (Unknown model) (2163 MHz)",3, "Intel Pentium Pro (Unknown model) (2092 MHz)",3, "AMD (Unknown model) (2303 MHz)",3, "Intel Pentium 4 Northwood (2141 MHz)",3, "Intel Pentium 4 Willamette (1612 MHz)",3, "Intel Pentium Pro (Unknown model) (2934 MHz)",3, "AMD Athlon (Thunderbird core) (949 MHz)",3, "Intel Pentium Pro (Unknown model) (692 MHz)",3, "AMD (Unknown model) (1014 MHz)",3, "Intel Pentium 4 (Unknown model) (2290 MHz)",3, "AMD (Unknown model) (1266 MHz)",3, "Intel Pentium Pro (Unknown model) (3510 MHz)",3, "AMD K7 (Unknown model) (1906 MHz)",3, "Intel Pentium 4 Northwood (2563 MHz)",3, "Intel Pentium Pro (Unknown model) (2835 MHz)",3, "AMD (Unknown model) (1210 MHz)",3, "Intel Pentium Pro (Unknown model) (1436 MHz)",3, "AMD (Unknown model) (2992 MHz)",3, "Intel Pentium 4 (Unknown model) (2469 MHz)",3, "AMD (Unknown model) (2277 MHz)",3, "Intel Pentium 4 (Unknown model) (3990 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1556 MHz)",3, "Intel Pentium Pro (Unknown model) (1271 MHz)",3, "AMD Athlon (0.25 micron) (494 MHz)",3, "Intel Pentium 4 Willamette (A-Step) (1574 MHz)",3, "AMD (Unknown model) (2274 MHz)",3, "Intel Pentium Pro (Unknown model) (631 MHz)",3, "AMD (Unknown model) (1898 MHz)",3, "Intel Pentium Pro (Unknown model) (2044 MHz)",3, "Intel Pentium 4 (Unknown model) (2675 MHz)",3, "Intel Pentium Pro (Unknown model) (2018 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1545 MHz)",3, "AMD (Unknown model) (1610 MHz)",3, "Intel Pentium 4 Northwood (1782 MHz)",3, "Intel Pentium Pro (Unknown model) (2239 MHz)",3, "Intel Pentium Pro (Unknown model) (1568 MHz)",3, "AMD (Unknown model) (2602 MHz)",3, "Intel Pentium 4 Northwood Xeon (1982 MHz)",3, "AMD K7 (Unknown model) (1309 MHz)",3, "AMD (Unknown model) (2884 MHz)",3, "Intel Pentium 4 (Unknown model) (3024 MHz)",3, "AMD (Unknown model) (2595 MHz)",3, "AMD (Unknown model) (2108 MHz)",3, "AMD (Unknown model) (815 MHz)",3, "Intel Pentium 4 (Unknown model) (2989 MHz)",3, "AMD (Unknown model) (2480 MHz)",3, "Intel Pentium 4 Willamette (1400 MHz)",3, "Intel Pentium Pro (Unknown model) (1353 MHz)",3, "Intel Pentium Pro (Unknown model) (682 MHz)",3, "Intel Pentium 4 (Unknown model) (2472 MHz)",3, "AMD Mobile Duron (Morgan core) (497 MHz)",3, "AMD Mobile Duron (Morgan core) (1097 MHz)",3, "Intel Pentium Pro (Unknown model) (1819 MHz)",3, "Intel Pentium 4 (Unknown model) (2319 MHz)",3, "AMD K7 (Unknown model) (1273 MHz)",3, "Intel Pentium Pro (Unknown model) (818 MHz)",3, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1312 MHz)",3, "AMD Athlon (Thunderbird core) (1004 MHz)",3, "AMD (Unknown model) (2660 MHz)",3, "AMD K7 (Unknown model) (2051 MHz)",3, "AMD K7 (Unknown model) (1504 MHz)",3, "Intel Pentium 4 (Unknown model) (3479 MHz)",3, "Intel Pentium Pro (Unknown model) (1133 MHz)",3, "Intel Pentium 4 Northwood (2850 MHz)",3, "AMD (Unknown model) (1976 MHz)",3, "Intel Pentium 4 Northwood (2747 MHz)",3, "Intel Pentium 4 (Unknown model) (3023 MHz)",3, "AMD Athlon (Thunderbird core) (1398 MHz)",3, "AMD Athlon (Thunderbird core) (1211 MHz)",3, "Intel Pentium Pro (Unknown model) (1637 MHz)",3, "Intel Pentium Pro (Unknown model) (2425 MHz)",3, "AMD (Unknown model) (2039 MHz)",3, "AMD (Unknown model) (2095 MHz)",3, "Intel Pentium Pro (Unknown model) (1095 MHz)",3, "AMD (Unknown model) (1632 MHz)",3, "Intel Pentium 4 Northwood (2268 MHz)",3, "Intel Pentium 4 Northwood (2059 MHz)",3, "Intel Pentium Pro (Unknown model) (1079 MHz)",3, "Intel Pentium 4 (Unknown model) (2567 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1564 MHz)",3, "Intel Pentium Pro (Unknown model) (2346 MHz)",3, "AMD (Unknown model) (1788 MHz)",3, "Intel Pentium Pro (Unknown model) (959 MHz)",3, "Intel Pentium Pro (Unknown model) (528 MHz)",3, "Intel Pentium 4 Northwood (2801 MHz)",3, "Intel Pentium 4 Northwood (2570 MHz)",3, "Intel Pentium Pro (Unknown model) (623 MHz)",3, "AMD K7 (Unknown model) (2253 MHz)",3, "AMD (Unknown model) (2677 MHz)",3, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (599 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1259 MHz)",3, "AMD K7 (Unknown model) (1269 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (899 MHz)",3, "AMD Athlon (Thunderbird core) (994 MHz)",3, "AMD (Unknown model) (2093 MHz)",3, "Intel Pentium Pro (Unknown model) (1021 MHz)",3, "AMD (Unknown model) (1973 MHz)",3, "Intel Pentium 4 (Unknown model) (2738 MHz)",3, "AMD K7 (Unknown model) (1158 MHz)",3, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1394 MHz)",3, "AMD K7 (Unknown model) (1649 MHz)",3, "Intel Pentium 4 Northwood Xeon (2160 MHz)",3, "Intel Pentium 4 Willamette (1696 MHz)",3, "Intel Pentium Pro (Unknown model) (1118 MHz)",3, "AMD K7 (Unknown model) (1461 MHz)",3, "AMD K7 (Unknown model) (1256 MHz)",3, "AMD (Unknown model) (1690 MHz)",3, "AMD (Unknown model) (2296 MHz)",3, "Intel Pentium 4 (Unknown model) (2690 MHz)",3, "Intel Pentium Pro (Unknown model) (1084 MHz)",3, "AMD (Unknown model) (2445 MHz)",3, "Intel Pentium Pro (Unknown model) (622 MHz)",3, "AMD (Unknown model) (2075 MHz)",3, "AMD (Unknown model) (1966 MHz)",3, "Intel Pentium 4 (Unknown model) (2921 MHz)",3, "Intel Pentium Pro (Unknown model) (1051 MHz)",3, "Intel Pentium Pro (Unknown model) (1569 MHz)",3, "AMD (Unknown model) (2166 MHz)",3, "Intel Pentium Pro (Unknown model) (3013 MHz)",3, "AMD Athlon (0.18 micron) (656 MHz)",3, "Intel Pentium Pro (Unknown model) (808 MHz)",3, "Intel Pentium Pro (Unknown model) (649 MHz)",3, "Intel Pentium 4 Northwood (3394 MHz)",3, "Intel Pentium 4 Northwood (1987 MHz)",3, "Intel Pentium III (0.18 micron process) with internal L2 cache (798 MHz)",3, "Intel Pentium 4 (Unknown model) (3871 MHz)",3, "AMD (Unknown model) (2482 MHz)",3, "AMD K7 (Unknown model) (1534 MHz)",3, "AMD K7 (Unknown model) (1699 MHz)",3, "Intel Pentium Pro (Unknown model) (1709 MHz)",3, "Intel Pentium Pro (Unknown model) (425 MHz)",3, "AMD (Unknown model) (1552 MHz)",3, "Intel Pentium Pro (Unknown model) (1741 MHz)",3, "Intel Pentium Pro (Unknown model) (2510 MHz)",3, "AMD K7 (Unknown model) (1851 MHz)",3, "Intel Pentium 4 (Unknown model) (3359 MHz)",3, "AMD Athlon (Thunderbird core) (1048 MHz)",3, "Intel Pentium Pro (Unknown model) (691 MHz)",3, "AMD Athlon (Thunderbird core) (958 MHz)",3, "Intel Pentium 4 (Unknown model) (2599 MHz)",3, "Intel Pentium Pro (Unknown model) (1549 MHz)",3, "Intel Pentium 4 (Unknown model) (2899 MHz)",3, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1096 MHz)",3, "Intel Pentium Pro (Unknown model) (1130 MHz)",3, "AMD (Unknown model) (2329 MHz)",3, "Intel Pentium 4 Northwood (2419 MHz)",3, "AMD Mobile Duron (Morgan core) (1260 MHz)",3, "AMD (Unknown model) (2115 MHz)",3, "Intel Pentium Pro (Unknown model) (721 MHz)",3, "Intel Pentium Pro (Unknown model) (1076 MHz)",3, "AMD (Unknown model) (2691 MHz)",3, "AMD (Unknown model) (632 MHz)",3, "Intel Pentium Pro (Unknown model) (1707 MHz)",3, "Intel Pentium 4 Northwood (2471 MHz)",3, "AMD Athlon MP/Mobile Athlon (Palomino core) (1742 MHz)",3, "Intel Pentium 4 (Unknown model) (3596 MHz)",3, "AMD (Unknown model) (2240 MHz)",3, "Intel Pentium Pro (Unknown model) (1571 MHz)",3, "Intel Pentium 4 (Unknown model) (3421 MHz)",3, "Intel Pentium Pro (Unknown model) (499 MHz)",3, "AMD (Unknown model) (1345 MHz)",3, "Intel Pentium 4 (Unknown model) (2276 MHz)",3, "Intel Pentium Pro (Unknown model) (1501 MHz)",3, "AMD (Unknown model) (2477 MHz)",3, "Intel Pentium 4 (Unknown model) (3227 MHz)",3, "Intel Pentium Pro (Unknown model) (866 MHz)",3, "AMD K7 (Unknown model) (1538 MHz)",3, "AMD K7 (Unknown model) (1281 MHz)",3, "AMD (Unknown model) (1072 MHz)",3, "Intel Celeron (0.18 micron process) with internal L2 cache (668 MHz)",3, "Intel Pentium Pro (Unknown model) (667 MHz)",3, "AMD (Unknown model) (2256 MHz)",3, "Intel Pentium Pro (Unknown model) (674 MHz)",3, "Intel Pentium 4 Northwood (3335 MHz)",3, "AMD (Unknown model) (1335 MHz)",3, "Intel Pentium 4 Northwood (3390 MHz)",3, "Intel Pentium 4 Northwood (2318 MHz)",3, "Intel Pentium 4 Northwood (3217 MHz)",3, "Intel Pentium 4 (Unknown model) (4048 MHz)",3, "AMD (Unknown model) (1945 MHz)",3, "Intel Pentium Pro (Unknown model) (1111 MHz)",3, "Intel Pentium Pro (Unknown model) (2471 MHz)",3, "AMD (Unknown model) (813 MHz)",3, "AMD (Unknown model) (1028 MHz)",3, "AMD Duron (Spitfire core) (959 MHz)",3, "Intel Pentium 4 (Unknown model) (2834 MHz)",3, "Intel Pentium 4 Northwood (1294 MHz)",3, "AMD (Unknown model) (2625 MHz)",3, "AMD (Unknown model) (2178 MHz)",3, "AMD (Unknown model) (1612 MHz)",3, "AMD (Unknown model) (1310 MHz)",3, "Intel Pentium 4 (Unknown model) (3440 MHz)",3, "Dual PowerPC 7400 (2160 MHz)",3, "AMD (Unknown model) (1019 MHz)",3, "AMD (Unknown model) (2437 MHz)",3, "Intel Pentium Pro (Unknown model) (1286 MHz)",3, "AMD (Unknown model) (1912 MHz)",3, "AMD (Unknown model) (847 MHz)",3, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1100 MHz)",3, "AMD (Unknown model) (1052 MHz)",3, "AMD (Unknown model) (1512 MHz)",2, "Intel Pentium Pro (Unknown model) (1173 MHz)",2, "AMD (Unknown model) (2741 MHz)",2, "AMD (Unknown model) (2284 MHz)",2, "Intel Pentium Pro (Unknown model) (2016 MHz)",2, "AMD (Unknown model) (1023 MHz)",2, "Intel Pentium Pro (Unknown model) (1604 MHz)",2, "AMD (Unknown model) (2283 MHz)",2, "Intel Pentium Pro (Unknown model) (1039 MHz)",2, "AMD (Unknown model) (890 MHz)",2, "Intel Pentium Pro (Unknown model) (1371 MHz)",2, "AMD (Unknown model) (2621 MHz)",2, "AMD (Unknown model) (1431 MHz)",2, "AMD (Unknown model) (1472 MHz)",2, "Intel Pentium Pro (Unknown model) (1374 MHz)",2, "AMD K7 (Unknown model) (2061 MHz)",2, "Intel Pentium Pro (Unknown model) (1044 MHz)",2, "Intel Pentium 4 (Unknown model) (2956 MHz)",2, "AMD (Unknown model) (1161 MHz)",2, "AMD K7 (Unknown model) (1704 MHz)",2, "Intel Pentium Pro (Unknown model) (1249 MHz)",2, "Intel Pentium Pro (Unknown model) (1086 MHz)",2, "Intel Pentium Pro (Unknown model) (1113 MHz)",2, "AMD (Unknown model) (1172 MHz)",2, "AMD K7 (Unknown model) (1975 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (786 MHz)",2, "AMD (Unknown model) (1883 MHz)",2, "AMD (Unknown model) (2155 MHz)",2, "Intel Pentium 4 Northwood (3415 MHz)",2, "AMD (Unknown model) (1280 MHz)",2, "AMD (Unknown model) (849 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (932 MHz)",2, "AMD (Unknown model) (2355 MHz)",2, "AMD K7 (Unknown model) (1204 MHz)",2, "Intel Pentium Pro (Unknown model) (1348 MHz)",2, "AMD (Unknown model) (2162 MHz)",2, "AMD (Unknown model) (2457 MHz)",2, "AMD (Unknown model) (1779 MHz)",2, "AMD (Unknown model) (1456 MHz)",2, "Intel Pentium Pro (Unknown model) (1114 MHz)",2, "Intel Pentium Pro (Unknown model) (973 MHz)",2, "PowerPC 7450 (997 MHz)",2, "AMD (Unknown model) (1770 MHz)",2, "AMD (Unknown model) (2725 MHz)",2, "AMD (Unknown model) (1125 MHz)",2, "Intel Pentium Pro (Unknown model) (714 MHz)",2, "AMD (Unknown model) (1113 MHz)",2, "Intel Pentium Pro (Unknown model) (815 MHz)",2, "AMD (Unknown model) (1139 MHz)",2, "AMD (Unknown model) (1452 MHz)",2, "AMD (Unknown model) (2228 MHz)",2, "AMD (Unknown model) (2338 MHz)",2, "AMD K7 (Unknown model) (1790 MHz)",2, "AMD (Unknown model) (1981 MHz)",2, "Intel Pentium Pro (Unknown model) (1984 MHz)",2, "AMD (Unknown model) (1473 MHz)",2, "Intel Pentium Pro (Unknown model) (874 MHz)",2, "Intel Pentium 4 (Unknown model) (2600 MHz)",2, "Intel Pentium 4 Northwood (3190 MHz)",2, "Intel Pentium Pro (Unknown model) (2601 MHz)",2, "AMD (Unknown model) (1639 MHz)",2, "Intel Pentium 4 (Unknown model) (3594 MHz)",2, "Intel Pentium Pro (Unknown model) (1674 MHz)",2, "Intel Pentium 4 (Unknown model) (3239 MHz)",2, "Intel Pentium 4 Northwood (2885 MHz)",2, "AMD K7 (Unknown model) (1881 MHz)",2, "Intel Pentium 4 (Unknown model) (4239 MHz)",2, "AMD (Unknown model) (2581 MHz)",2, "Intel Pentium Pro (Unknown model) (1366 MHz)",2, "AMD (Unknown model) (2564 MHz)",2, "Intel Pentium Pro (Unknown model) (1896 MHz)",2, "AMD (Unknown model) (2360 MHz)",2, "AMD K7 (Unknown model) (1803 MHz)",2, "AMD (Unknown model) (1250 MHz)",2, "Intel Pentium 4 (Unknown model) (3337 MHz)",2, "AMD (Unknown model) (1214 MHz)",2, "AMD (Unknown model) (2143 MHz)",2, "Intel Pentium Pro (Unknown model) (1684 MHz)",2, "Intel Pentium Pro (Unknown model) (1439 MHz)",2, "Intel Pentium 4 Willamette (1818 MHz)",2, "Intel Pentium Pro (Unknown model) (1410 MHz)",2, "Intel Pentium Pro (Unknown model) (769 MHz)",2, "AMD (Unknown model) (1723 MHz)",2, "AMD (Unknown model) (1315 MHz)",2, "AMD (Unknown model) (1083 MHz)",2, "Intel Pentium 4 Northwood Xeon (3017 MHz)",2, "AMD (Unknown model) (1757 MHz)",2, "AMD (Unknown model) (1185 MHz)",2, "AMD (Unknown model) (956 MHz)",2, "Intel Pentium 4 (Unknown model) (2974 MHz)",2, "AMD (Unknown model) (1675 MHz)",2, "AMD (Unknown model) (1667 MHz)",2, "Intel Pentium Pro (Unknown model) (1435 MHz)",2, "AMD (Unknown model) (831 MHz)",2, "Intel Pentium Pro (Unknown model) (344 MHz)",2, "AMD (Unknown model) (1184 MHz)",2, "AMD (Unknown model) (1047 MHz)",2, "Intel Pentium Pro (Unknown model) (2976 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (795 MHz)",2, "AMD (Unknown model) (1613 MHz)",2, "Intel Pentium II with internal L2 cache (467 MHz)",2, "Intel Pentium Pro (Unknown model) (1562 MHz)",2, "Intel Pentium 4 Northwood Xeon (3060 MHz)",2, "AMD (Unknown model) (1534 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1753 MHz)",2, "Intel Pentium Pro (Unknown model) (1461 MHz)",2, "Intel Pentium Pro (Unknown model) (750 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1328 MHz)",2, "AMD (Unknown model) (1622 MHz)",2, "AMD (Unknown model) (2154 MHz)",2, "AMD (Unknown model) (1271 MHz)",2, "AMD (Unknown model) (1357 MHz)",2, "Intel Pentium Pro (Unknown model) (1445 MHz)",2, "Intel Pentium Pro (Unknown model) (901 MHz)",2, "Intel Pentium 4 Northwood (2065 MHz)",2, "AMD (Unknown model) (2085 MHz)",2, "AMD (Unknown model) (1264 MHz)",2, "AMD (Unknown model) (2384 MHz)",2, "AMD (Unknown model) (1299 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1395 MHz)",2, "Intel Pentium Pro (Unknown model) (1451 MHz)",2, "AMD (Unknown model) (2369 MHz)",2, "AMD (Unknown model) (1031 MHz)",2, "AMD (Unknown model) (1328 MHz)",2, "Intel Pentium 4 (Unknown model) (6293 MHz)",2, "AMD (Unknown model) (2177 MHz)",2, "Intel Pentium Pro (Unknown model) (505 MHz)",2, "Intel Pentium 4 Northwood Xeon (1607 MHz)",2, "Intel Pentium 4 Northwood (2272 MHz)",2, "Intel Pentium Pro (Unknown model) (968 MHz)",2, "AMD K7 (Unknown model) (2257 MHz)",2, "Intel Pentium Pro (Unknown model) (567 MHz)",2, "Intel Pentium 4 (Unknown model) (3032 MHz)",2, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (503 MHz)",2, "AMD (Unknown model) (957 MHz)",2, "AMD K7 (Unknown model) (2233 MHz)",2, "Intel Pentium Pro (Unknown model) (875 MHz)",2, "AMD (Unknown model) (1727 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1296 MHz)",2, "AMD (Unknown model) (2172 MHz)",2, "AMD (Unknown model) (2850 MHz)",2, "Intel Pentium Pro (Unknown model) (433 MHz)",2, "Intel Pentium 4 Northwood Xeon (1997 MHz)",2, "Intel Pentium Pro (Unknown model) (1081 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1457 MHz)",2, "AMD K7 (Unknown model) (2115 MHz)",2, "Intel Pentium Pro (Unknown model) (1035 MHz)",2, "Intel Pentium Pro (Unknown model) (1491 MHz)",2, "Intel Pentium Pro (Unknown model) (1472 MHz)",2, "Intel Pentium Pro (Unknown model) (1570 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (948 MHz)",2, "AMD (Unknown model) (1069 MHz)",2, "Intel Pentium Pro (Unknown model) (1383 MHz)",2, "Intel Pentium Pro (Unknown model) (1653 MHz)",2, "Intel Pentium Pro (Unknown model) (1557 MHz)",2, "AMD (Unknown model) (2064 MHz)",2, "Intel Pentium Pro (Unknown model) (488 MHz)",2, "AMD (Unknown model) (2536 MHz)",2, "AMD (Unknown model) (1319 MHz)",2, "AMD (Unknown model) (1681 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (800 MHz)",2, "Intel Pentium Pro (Unknown model) (1094 MHz)",2, "AMD (Unknown model) (2549 MHz)",2, "Intel Pentium Pro (Unknown model) (1634 MHz)",2, "AMD (Unknown model) (1425 MHz)",2, "Intel Pentium Pro (Unknown model) (1633 MHz)",2, "AMD (Unknown model) (1323 MHz)",2, "AMD (Unknown model) (1055 MHz)",2, "Intel Pentium 4 Northwood (2703 MHz)",2, "Intel Pentium Pro (Unknown model) (1388 MHz)",2, "Intel Pentium Pro (Unknown model) (1363 MHz)",2, "Intel Pentium Pro (Unknown model) (1169 MHz)",2, "Intel Pentium Pro (Unknown model) (1894 MHz)",2, "AMD (Unknown model) (1414 MHz)",2, "AMD (Unknown model) (2589 MHz)",2, "Intel Pentium Pro (Unknown model) (326 MHz)",2, "AMD (Unknown model) (1111 MHz)",2, "Intel Pentium 4 (Unknown model) (3892 MHz)",2, "Intel Pentium 4 (Unknown model) (2553 MHz)",2, "Intel Pentium Pro (Unknown model) (814 MHz)",2, "Intel Pentium Pro (Unknown model) (1414 MHz)",2, "Intel Pentium Pro (Unknown model) (677 MHz)",2, "Intel Pentium 4 (Unknown model) (2864 MHz)",2, "Intel Pentium 4 (Unknown model) (2425 MHz)",2, "AMD K7 (Unknown model) (1081 MHz)",2, "Intel Pentium Pro (Unknown model) (1949 MHz)",2, "Intel Pentium 4 Northwood (3022 MHz)",2, "Intel Pentium Pro (Unknown model) (731 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (439 MHz)",2, "Intel Pentium Pro (Unknown model) (1948 MHz)",2, "Intel Pentium Pro (Unknown model) (1253 MHz)",2, "Intel Pentium 4 Northwood (2868 MHz)",2, "AMD (Unknown model) (1642 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (940 MHz)",2, "AMD Duron (Spitfire core) (946 MHz)",2, "Intel Pentium Pro (Unknown model) (234 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1489 MHz)",2, "Intel Pentium 4 Northwood (2494 MHz)",2, "AMD (Unknown model) (1071 MHz)",2, "AMD (Unknown model) (2515 MHz)",2, "AMD (Unknown model) (1234 MHz)",2, "AMD Athlon (Thunderbird core) (703 MHz)",2, "Intel Pentium Pro (Unknown model) (2275 MHz)",2, "AMD Duron (Spitfire core) (747 MHz)",2, "Intel Pentium 4 (Unknown model) (2389 MHz)",2, "Intel Pentium 4 Northwood (3002 MHz)",2, "Intel Pentium 4 (Unknown model) (2684 MHz)",2, "Intel Pentium 4 (Unknown model) (2682 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (998 MHz)",2, "Intel Pentium 4 (Unknown model) (3087 MHz)",2, "Intel Pentium Pro (Unknown model) (1187 MHz)",2, "Intel Pentium 4 (Unknown model) (2272 MHz)",2, "Intel Pentium Pro (Unknown model) (744 MHz)",2, "AMD (Unknown model) (985 MHz)",2, "AMD (Unknown model) (2054 MHz)",2, "Intel Pentium Pro (Unknown model) (817 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1530 MHz)",2, "AMD Mobile Duron (Morgan core) (1308 MHz)",2, "AMD (Unknown model) (1939 MHz)",2, "Intel Pentium 4 (Unknown model) (3750 MHz)",2, "Intel Pentium Pro (Unknown model) (1171 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (908 MHz)",2, "Intel Pentium 4 (Unknown model) (3597 MHz)",2, "Intel Pentium Pro (Unknown model) (1656 MHz)",2, "Intel Pentium Pro (Unknown model) (650 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1481 MHz)",2, "Intel Pentium Pro (Unknown model) (1614 MHz)",2, "Intel Pentium 4 (Unknown model) (3938 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1671 MHz)",2, "Intel Pentium 4 (Unknown model) (4319 MHz)",2, "Intel Pentium 4 Northwood (2823 MHz)",2, "AMD K7 (Unknown model) (2028 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (848 MHz)",2, "AMD K7 (Unknown model) (2280 MHz)",2, "AMD Athlon (0.18 micron) (748 MHz)",2, "Intel Pentium 4 Northwood Xeon (3006 MHz)",2, "Intel Pentium Pro (Unknown model) (1619 MHz)",2, "AMD (Unknown model) (1042 MHz)",2, "Intel Pentium 4 Northwood (1931 MHz)",2, "Intel Pentium Pro (Unknown model) (1934 MHz)",2, "AMD K7 (Unknown model) (2283 MHz)",2, "AMD (Unknown model) (1957 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (899 MHz)",2, "Intel Pentium 4 Northwood Xeon (3063 MHz)",2, "Intel Pentium Pro (Unknown model) (1773 MHz)",2, "AMD (Unknown model) (1327 MHz)",2, "Intel Pentium Pro (Unknown model) (1849 MHz)",2, "AMD (Unknown model) (1249 MHz)",2, "Intel Pentium Pro (Unknown model) (1907 MHz)",2, "AMD K7 (Unknown model) (1328 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (499 MHz)",2, "AMD (Unknown model) (1313 MHz)",2, "Intel Pentium 4 (Unknown model) (2968 MHz)",2, "Intel Pentium Pro (Unknown model) (548 MHz)",2, "Intel Pentium Pro (Unknown model) (755 MHz)",2, "Intel Pentium 4 (Unknown model) (3232 MHz)",2, "Intel Pentium 4 (Unknown model) (2928 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1305 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1492 MHz)",2, "Intel Pentium Pro (Unknown model) (2936 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1498 MHz)",2, "Intel Pentium Pro (Unknown model) (1895 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1000 MHz)",2, "Intel Pentium Pro (Unknown model) (760 MHz)",2, "Intel Pentium 4 Northwood (1613 MHz)",2, "Intel Pentium Pro (Unknown model) (387 MHz)",2, "AMD (Unknown model) (2333 MHz)",2, "Intel Pentium Pro (Unknown model) (522 MHz)",2, "AMD (Unknown model) (1751 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (882 MHz)",2, "AMD Athlon (Thunderbird core) (751 MHz)",2, "AMD (Unknown model) (1344 MHz)",2, "AMD Duron (Spitfire core) (798 MHz)",2, "Intel Pentium 4 Northwood (2858 MHz)",2, "Intel Pentium Pro (Unknown model) (1337 MHz)",2, "AMD Duron (Spitfire core) (780 MHz)",2, "Intel Pentium Pro (Unknown model) (1807 MHz)",2, "Intel Pentium Pro (Unknown model) (1384 MHz)",2, "Intel Pentium 4 Willamette Xeon (1599 MHz)",2, "Intel Pentium Pro (Unknown model) (1957 MHz)",2, "Intel Pentium 4 (Unknown model) (2380 MHz)",2, "Intel Pentium 4 (Unknown model) (2374 MHz)",2, "Intel Pentium Pro (Unknown model) (1881 MHz)",2, "AMD Mobile Duron (Morgan core) (1098 MHz)",2, "Intel Pentium 4 Northwood (2698 MHz)",2, "Intel Pentium Pro (Unknown model) (3300 MHz)",2, "AMD (Unknown model) (1954 MHz)",2, "Intel Pentium III Xeon (0.18 micron process) with internal L2 cache (993 MHz)",2, "Intel Pentium 4 (Unknown model) (2009 MHz)",2, "AMD K7 (Unknown model) (1962 MHz)",2, "AMD (Unknown model) (2702 MHz)",2, "Intel Pentium 4 (Unknown model) (3632 MHz)",2, "Intel Pentium Pro (Unknown model) (1467 MHz)",2, "Intel Pentium Pro (Unknown model) (1964 MHz)",2, "Intel Pentium Pro (Unknown model) (783 MHz)",2, "AMD K7 (Unknown model) (1167 MHz)",2, "AMD (Unknown model) (2695 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (884 MHz)",2, "AMD (Unknown model) (2053 MHz)",2, "Intel Pentium Pro (Unknown model) (642 MHz)",2, "Intel Pentium Pro (Unknown model) (2167 MHz)",2, "AMD K7 (Unknown model) (2110 MHz)",2, "Intel Pentium Pro (Unknown model) (462 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1515 MHz)",2, "Intel Pentium 4 Northwood (2487 MHz)",2, "AMD K7 (Unknown model) (1421 MHz)",2, "AMD K7 (Unknown model) (500 MHz)",2, "AMD (Unknown model) (1867 MHz)",2, "Intel Pentium 4 (Unknown model) (4121 MHz)",2, "Intel Pentium Pro (Unknown model) (2391 MHz)",2, "Intel Pentium Pro (Unknown model) (2205 MHz)",2, "Intel Pentium Pro (Unknown model) (2574 MHz)",2, "Unknown (995 MHz)",2, "Intel Pentium 4 Northwood (2925 MHz)",2, "AMD Athlon (0.18 micron) (650 MHz)",2, "AMD (Unknown model) (1870 MHz)",2, "Intel Pentium Pro (Unknown model) (2249 MHz)",2, "AMD (Unknown model) (2057 MHz)",2, "Intel Pentium Pro (Unknown model) (2615 MHz)",2, "Intel Pentium Pro (Unknown model) (873 MHz)",2, "Intel Pentium Pro (Unknown model) (1284 MHz)",2, "Intel Pentium 4 (Unknown model) (4139 MHz)",2, "AMD (Unknown model) (2330 MHz)",2, "AMD K7 (Unknown model) (1624 MHz)",2, "AMD (Unknown model) (1881 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1724 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (892 MHz)",2, "AMD (Unknown model) (1956 MHz)",2, "AMD K7 (Unknown model) (1789 MHz)",2, "AMD K7 (Unknown model) (1522 MHz)",2, "Intel Pentium 4 Northwood (2618 MHz)",2, "Intel Pentium Pro (Unknown model) (1193 MHz)",2, "AMD Athlon (Thunderbird core) (906 MHz)",2, "Intel Pentium Pro (Unknown model) (1288 MHz)",2, "Intel Pentium 4 Northwood (3164 MHz)",2, "Intel Pentium Pro (Unknown model) (3824 MHz)",2, "AMD (Unknown model) (1834 MHz)",2, "AMD (Unknown model) (1094 MHz)",2, "Intel Pentium 4 (Unknown model) (3108 MHz)",2, "Intel Pentium 4 Northwood (2107 MHz)",2, "Intel Pentium 4 Northwood (2818 MHz)",2, "Intel Pentium 4 (Unknown model) (2270 MHz)",2, "Intel Pentium Pro (Unknown model) (2563 MHz)",2, "Intel Pentium 4 (Unknown model) (3418 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1307 MHz)",2, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1001 MHz)",2, "Intel Pentium 4 Northwood (2069 MHz)",2, "Intel Pentium Pro (Unknown model) (3456 MHz)",2, "AMD (Unknown model) (1951 MHz)",2, "Intel Pentium 4 (Unknown model) (3810 MHz)",2, "Dual i386 (Unknown) (2790 MHz)",2, "AMD (Unknown model) (2495 MHz)",2, "AMD (Unknown model) (1016 MHz)",2, "AMD (Unknown model) (2534 MHz)",2, "AMD Athlon (Thunderbird core) (898 MHz)",2, "AMD (Unknown model) (2036 MHz)",2, "AMD (Unknown model) (1091 MHz)",2, "AMD (Unknown model) (897 MHz)",2, "Intel Pentium Pro (Unknown model) (1705 MHz)",2, "Intel Pentium 4 (Unknown model) (2881 MHz)",2, "Intel Pentium 4 (Unknown model) (3160 MHz)",2, "Intel Pentium Pro (Unknown model) (1020 MHz)",2, "AMD (Unknown model) (1057 MHz)",2, "Intel Pentium Pro (Unknown model) (1201 MHz)",2, "Intel Pentium Pro (Unknown model) (785 MHz)",2, "Intel Pentium 4 Willamette (1679 MHz)",2, "AMD (Unknown model) (2742 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1002 MHz)",2, "AMD K7 (Unknown model) (1545 MHz)",2, "Intel Pentium Pro (Unknown model) (1244 MHz)",2, "Intel Pentium Pro (Unknown model) (768 MHz)",2, "Intel Pentium 4 (Unknown model) (3811 MHz)",2, "Intel Pentium Pro (Unknown model) (684 MHz)",2, "Intel Pentium Pro (Unknown model) (1880 MHz)",2, "Intel Pentium Pro (Unknown model) (880 MHz)",2, "Intel Pentium III Xeon (0.18 micron process) with internal L2 cache (996 MHz)",2, "Intel Pentium Pro (Unknown model) (507 MHz)",2, "AMD (Unknown model) (1025 MHz)",2, "Intel Pentium Pro (Unknown model) (3329 MHz)",2, "AMD (Unknown model) (2614 MHz)",2, "AMD (Unknown model) (1865 MHz)",2, "Intel Pentium Pro (Unknown model) (1252 MHz)",2, "AMD K7 (Unknown model) (1093 MHz)",2, "AMD (Unknown model) (2569 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1488 MHz)",2, "Intel Pentium Pro (Unknown model) (780 MHz)",2, "Intel Pentium 4 (Unknown model) (4439 MHz)",2, "AMD (Unknown model) (2037 MHz)",2, "Intel Pentium 4 (Unknown model) (3448 MHz)",2, "AMD (Unknown model) (2074 MHz)",2, "Intel Pentium Pro (Unknown model) (1468 MHz)",2, "AMD K7 (Unknown model) (1771 MHz)",2, "AMD (Unknown model) (2041 MHz)",2, "AMD K7 (Unknown model) (1738 MHz)",2, "Intel Pentium 4 (Unknown model) (2734 MHz)",2, "Intel Pentium Pro (Unknown model) (1153 MHz)",2, "AMD (Unknown model) (1467 MHz)",2, "AMD K7 (Unknown model) (1694 MHz)",2, "Intel Pentium Pro (Unknown model) (521 MHz)",2, "AMD Mobile Duron (Morgan core) (998 MHz)",2, "Intel Pentium 4 Northwood Xeon (2187 MHz)",2, "AMD (Unknown model) (1618 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (1097 MHz)",2, "Intel Pentium 4 (Unknown model) (3041 MHz)",2, "Intel Pentium Pro (Unknown model) (2474 MHz)",2, "Intel Pentium Pro (Unknown model) (708 MHz)",2, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1399 MHz)",2, "Intel Pentium Pro (Unknown model) (2482 MHz)",2, "Intel Pentium Pro (Unknown model) (627 MHz)",2, "Intel Pentium Pro (Unknown model) (1339 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (1101 MHz)",2, "Intel Pentium Pro (Unknown model) (566 MHz)",2, "Intel Pentium 4 Northwood Xeon (1398 MHz)",2, "Intel Pentium 4 (Unknown model) (2961 MHz)",2, "AMD (Unknown model) (1348 MHz)",2, "AMD (Unknown model) (1916 MHz)",2, "Intel Pentium Pro (Unknown model) (3487 MHz)",2, "Intel Pentium 4 Northwood (2222 MHz)",2, "Intel Pentium 4 (Unknown model) (3436 MHz)",2, "Intel Pentium Pro (Unknown model) (1961 MHz)",2, "Intel Pentium Pro (Unknown model) (1257 MHz)",2, "Intel Pentium 4 (Unknown model) (2918 MHz)",2, "Intel Pentium 4 (Unknown model) (3578 MHz)",2, "AMD K7 (Unknown model) (2348 MHz)",2, "AMD K7 (Unknown model) (930 MHz)",2, "Intel Pentium Pro (Unknown model) (1952 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1207 MHz)",2, "AMD Athlon (Thunderbird core) (1193 MHz)",2, "Intel Pentium 4 Northwood (3231 MHz)",2, "Intel Pentium 4 Northwood (2720 MHz)",2, "Intel Pentium 4 (Unknown model) (3915 MHz)",2, "Intel Pentium Pro (Unknown model) (1753 MHz)",2, "AMD (Unknown model) (1829 MHz)",2, "AMD (Unknown model) (2759 MHz)",2, "Intel Pentium Pro (Unknown model) (945 MHz)",2, "Intel Pentium Pro (Unknown model) (1900 MHz)",2, "Intel Pentium 4 (Unknown model) (2470 MHz)",2, "AMD (Unknown model) (2845 MHz)",2, "AMD K7 (Unknown model) (1407 MHz)",2, "AMD (Unknown model) (2267 MHz)",2, "Intel Pentium Pro (Unknown model) (1151 MHz)",2, "AMD (Unknown model) (1022 MHz)",2, "Intel Pentium Pro (Unknown model) (1243 MHz)",2, "Intel Pentium Pro (Unknown model) (976 MHz)",2, "Intel Pentium Pro (Unknown model) (1635 MHz)",2, "AMD K7 (Unknown model) (1008 MHz)",2, "AMD (Unknown model) (1958 MHz)",2, "AMD Mobile Duron (Morgan core) (1261 MHz)",2, "AMD (Unknown model) (1775 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1611 MHz)",2, "AMD Mobile Duron (Morgan core) (1234 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (481 MHz)",2, "AMD (Unknown model) (2352 MHz)",2, "AMD (Unknown model) (1983 MHz)",2, "Intel Pentium Pro (Unknown model) (774 MHz)",2, "Intel Pentium 4 Willamette (1399 MHz)",2, "Intel Pentium Pro (Unknown model) (884 MHz)",2, "AMD K7 (Unknown model) (2048 MHz)",2, "AMD (Unknown model) (2685 MHz)",2, "Intel Pentium 4 Willamette (1631 MHz)",2, "AMD (Unknown model) (1879 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (596 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1649 MHz)",2, "Intel Pentium 4 Willamette (1709 MHz)",2, "AMD (Unknown model) (460 MHz)",2, "AMD K7 (Unknown model) (861 MHz)",2, "Intel Pentium Pro (Unknown model) (693 MHz)",2, "AMD (Unknown model) (2044 MHz)",2, "PowerPC 7400 (349 MHz)",2, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1259 MHz)",2, "Intel Pentium 4 (Unknown model) (3097 MHz)",2, "AMD K7 (Unknown model) (1439 MHz)",2, "Intel Pentium 4 Northwood (2510 MHz)",2, "AMD K7 (Unknown model) (1272 MHz)",2, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1403 MHz)",2, "Intel Pentium Pro (Unknown model) (1953 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (950 MHz)",2, "AMD (Unknown model) (1823 MHz)",2, "Intel Pentium Pro (Unknown model) (1989 MHz)",2, "Intel Pentium Pro (Unknown model) (1154 MHz)",2, "Intel Pentium 4 (Unknown model) (3500 MHz)",2, "AMD (Unknown model) (2137 MHz)",2, "Intel Pentium 4 (Unknown model) (2649 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1568 MHz)",2, "AMD Mobile Duron (Morgan core) (1307 MHz)",2, "Intel Pentium Pro (Unknown model) (2932 MHz)",2, "Intel Pentium Pro (Unknown model) (1791 MHz)",2, "AMD (Unknown model) (1611 MHz)",2, "AMD K7 (Unknown model) (1552 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (860 MHz)",2, "AMD (Unknown model) (2882 MHz)",2, "AMD (Unknown model) (2944 MHz)",2, "AMD (Unknown model) (1334 MHz)",2, "Intel Pentium 4 (Unknown model) (3422 MHz)",2, "Intel Pentium 4 (Unknown model) (1908 MHz)",2, "Intel Pentium 4 Northwood (2879 MHz)",2, "Intel Pentium 4 (Unknown model) (2312 MHz)",2, "Intel Pentium Pro (Unknown model) (1189 MHz)",2, "AMD K7 (Unknown model) (1324 MHz)",2, "Intel Pentium 4 (Unknown model) (3751 MHz)",2, "AMD (Unknown model) (2447 MHz)",2, "AMD (Unknown model) (2270 MHz)",2, "Intel Pentium 4 Willamette (1683 MHz)",2, "Intel Pentium Pro (Unknown model) (1769 MHz)",2, "AMD (Unknown model) (2111 MHz)",2, "Intel Pentium Pro (Unknown model) (1854 MHz)",2, "Intel Pentium 4 Northwood (2622 MHz)",2, "AMD K7 (Unknown model) (2077 MHz)",2, "AMD (Unknown model) (1012 MHz)",2, "Intel Pentium Pro (Unknown model) (654 MHz)",2, "Intel Pentium 4 Northwood (2309 MHz)",2, "Intel Pentium Pro (Unknown model) (3250 MHz)",2, "Intel Pentium 4 Northwood (3178 MHz)",2, "AMD Athlon (0.18 micron) (651 MHz)",2, "Intel Pentium 4 Willamette (2025 MHz)",2, "AMD (Unknown model) (2374 MHz)",2, "AMD Athlon (0.18 micron) (807 MHz)",2, "Intel Pentium Pro (Unknown model) (3851 MHz)",2, "Intel Pentium 4 Northwood (2385 MHz)",2, "Unknown (1500 MHz)",2, "Intel Pentium Pro (Unknown model) (1822 MHz)",2, "Intel Pentium Pro (Unknown model) (1775 MHz)",2, "AMD (Unknown model) (962 MHz)",2, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (348 MHz)",2, "AMD Duron (Spitfire core) (805 MHz)",2, "Intel Pentium 4 (Unknown model) (2903 MHz)",2, "AMD (Unknown model) (1781 MHz)",2, "AMD (Unknown model) (1624 MHz)",2, "Intel Pentium 4 Northwood (1197 MHz)",2, "AMD (Unknown model) (2363 MHz)",2, "Intel Pentium 4 Northwood Xeon (2195 MHz)",2, "AMD K7 (Unknown model) (2037 MHz)",2, "AMD (Unknown model) (1326 MHz)",2, "Intel Pentium 4 (Unknown model) (3270 MHz)",2, "AMD (Unknown model) (1787 MHz)",2, "Intel Pentium 4 Northwood (2725 MHz)",2, "Intel Pentium 4 (Unknown model) (3330 MHz)",2, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1139 MHz)",2, "Intel Pentium 4 (Unknown model) (2439 MHz)",2, "Dual PowerPC 7450 (1300 MHz)",2, "AMD (Unknown model) (1440 MHz)",2, "Intel Pentium Pro (Unknown model) (1555 MHz)",2, "Intel Pentium Pro (Unknown model) (1679 MHz)",2, "Intel Pentium Pro (Unknown model) (1547 MHz)",2, "Intel Pentium Pro (Unknown model) (3059 MHz)",2, "Intel Pentium 4 (Unknown model) (3048 MHz)",2, "AMD (Unknown model) (877 MHz)",2, "Intel Pentium Pro (Unknown model) (2415 MHz)",2, "Intel Pentium Pro (Unknown model) (2029 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1394 MHz)",2, "Intel Pentium 4 (Unknown model) (3651 MHz)",2, "AMD (Unknown model) (3029 MHz)",2, "Intel Pentium Pro (Unknown model) (570 MHz)",2, "Intel Pentium 4 (Unknown model) (3505 MHz)",2, "AMD Athlon (Thunderbird core) (1005 MHz)",2, "Intel Pentium 4 Northwood (3099 MHz)",2, "Intel Pentium Pro (Unknown model) (638 MHz)",2, "Intel Pentium Pro (Unknown model) (2797 MHz)",2, "AMD (Unknown model) (2939 MHz)",2, "Intel Pentium 4 Northwood (2211 MHz)",2, "Intel Pentium 4 (Unknown model) (4205 MHz)",2, "AMD (Unknown model) (2440 MHz)",2, "AMD (Unknown model) (2127 MHz)",2, "AMD Mobile Duron (Morgan core) (1186 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1108 MHz)",2, "Intel Pentium 4 Northwood (1920 MHz)",2, "Intel Pentium Pro (Unknown model) (1909 MHz)",2, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (493 MHz)",2, "Intel Pentium Pro (Unknown model) (3465 MHz)",2, "Intel Pentium 4 Northwood (3063 MHz)",2, "Intel Pentium Pro (Unknown model) (547 MHz)",2, "AMD (Unknown model) (866 MHz)",2, "Intel Pentium 4 Northwood Xeon (2115 MHz)",2, "Intel Pentium Pro (Unknown model) (546 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (944 MHz)",2, "Intel Pentium 4 Willamette (1692 MHz)",2, "AMD K7 (Unknown model) (1485 MHz)",2, "AMD K7 (Unknown model) (2181 MHz)",2, "AMD K7 (Unknown model) (1610 MHz)",2, "Intel Pentium Pro (Unknown model) (1582 MHz)",2, "Intel Pentium 4 Northwood (2990 MHz)",2, "Intel Pentium 4 (Unknown model) (3906 MHz)",2, "AMD K7 (Unknown model) (1614 MHz)",2, "Intel Pentium 4 Northwood Xeon (2600 MHz)",2, "AMD K7 (Unknown model) (2330 MHz)",2, "Intel Pentium Pro (Unknown model) (1838 MHz)",2, "AMD K7 (Unknown model) (1612 MHz)",2, "Intel Pentium 4 (Unknown model) (4407 MHz)",2, "Intel Pentium Pro (Unknown model) (574 MHz)",2, "Intel Pentium Pro (Unknown model) (2958 MHz)",2, "Intel Pentium Pro (Unknown model) (700 MHz)",2, "AMD K7 (Unknown model) (1141 MHz)",2, "AMD K7 (Unknown model) (1401 MHz)",2, "Intel Pentium 4 (Unknown model) (3823 MHz)",2, "Intel Pentium Pro (Unknown model) (1010 MHz)",2, "AMD (Unknown model) (2230 MHz)",2, "Intel Pentium 4 (Unknown model) (2131 MHz)",2, "AMD (Unknown model) (2344 MHz)",2, "AMD (Unknown model) (1175 MHz)",2, "Intel Pentium Pro (Unknown model) (3244 MHz)",2, "Intel Pentium Pro (Unknown model) (770 MHz)",2, "Intel Pentium Pro (Unknown model) (479 MHz)",2, "Intel Pentium 4 Northwood (2465 MHz)",2, "Intel Pentium Pro (Unknown model) (559 MHz)",2, "Intel Pentium Pro (Unknown model) (3360 MHz)",2, "Intel Pentium Pro (Unknown model) (621 MHz)",2, "Intel Pentium 4 (Unknown model) (4079 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1494 MHz)",2, "Intel Pentium Pro (Unknown model) (2706 MHz)",2, "Intel Pentium Pro (Unknown model) (2929 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1560 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (985 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1696 MHz)",2, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1205 MHz)",2, "Intel Pentium Pro (Unknown model) (1247 MHz)",2, "AMD K7 (Unknown model) (2041 MHz)",2, "AMD (Unknown model) (868 MHz)",2, "Intel Pentium Pro (Unknown model) (3293 MHz)",2, "Intel Pentium 4 Northwood Xeon (2398 MHz)",2, "AMD (Unknown model) (986 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1507 MHz)",2, "AMD (Unknown model) (2509 MHz)",2, "Intel Pentium 4 Willamette (1561 MHz)",2, "Intel Pentium 4 Northwood (2070 MHz)",2, "Intel Pentium 4 (Unknown model) (2251 MHz)",2, "AMD (Unknown model) (809 MHz)",2, "Intel Pentium 4 (Unknown model) (2861 MHz)",2, "AMD (Unknown model) (1814 MHz)",2, "Intel Pentium 4 (Unknown model) (2697 MHz)",2, "Intel Pentium Pro (Unknown model) (3148 MHz)",2, "Intel Pentium Pro (Unknown model) (2241 MHz)",2, "AMD K7 (Unknown model) (1604 MHz)",2, "Intel Pentium Pro (Unknown model) (1514 MHz)",2, "Dual PowerPC 7400 (2400 MHz)",2, "Intel Pentium Pro (Unknown model) (766 MHz)",2, "Intel Pentium Pro (Unknown model) (2596 MHz)",2, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (397 MHz)",2, "AMD K7 (Unknown model) (1924 MHz)",2, "PowerPC 7450 (1300 MHz)",2, "Intel Pentium 4 (Unknown model) (3614 MHz)",2, "AMD (Unknown model) (1964 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (862 MHz)",2, "Intel Pentium 4 (Unknown model) (4027 MHz)",2, "Intel Pentium Pro (Unknown model) (1762 MHz)",2, "AMD Athlon (Thunderbird core) (952 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (947 MHz)",2, "AMD (Unknown model) (1162 MHz)",2, "AMD (Unknown model) (2925 MHz)",2, "PowerPC 7400 (498 MHz)",2, "Intel Pentium Pro (Unknown model) (967 MHz)",2, "AMD (Unknown model) (806 MHz)",2, "Intel Pentium Pro (Unknown model) (2829 MHz)",2, "Intel Pentium 4 Northwood (2377 MHz)",2, "AMD (Unknown model) (2664 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (995 MHz)",2, "Intel Pentium 4 Northwood (2647 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (900 MHz)",2, "Intel Pentium Pro (Unknown model) (2900 MHz)",2, "Intel Pentium 4 Willamette Xeon (A-Step) (1384 MHz)",2, "Intel Pentium 4 Northwood (4767 MHz)",2, "AMD K7 (Unknown model) (2505 MHz)",2, "AMD (Unknown model) (830 MHz)",2, "AMD (Unknown model) (2322 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1288 MHz)",2, "AMD K7 (Unknown model) (1320 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (799 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (1020 MHz)",2, "AMD (Unknown model) (2795 MHz)",2, "Intel Pentium 4 Northwood (1729 MHz)",2, "AMD K7 (Unknown model) (1716 MHz)",2, "Intel Pentium 4 Northwood (1814 MHz)",2, "Intel Pentium 4 Northwood (3529 MHz)",2, "AMD (Unknown model) (2164 MHz)",2, "AMD K7 (Unknown model) (2212 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (857 MHz)",2, "Intel Pentium 4 Northwood (2869 MHz)",2, "AMD Duron (Spitfire core) (849 MHz)",2, "AMD K7 (Unknown model) (1943 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (932 MHz)",2, "Intel Pentium 4 (Unknown model) (2920 MHz)",2, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1292 MHz)",2, "AMD K7 (Unknown model) (1548 MHz)",2, "Intel Pentium Pro (Unknown model) (1358 MHz)",2, "Intel Pentium 4 Northwood (2540 MHz)",2, "Intel Pentium Pro (Unknown model) (1636 MHz)",2, "Intel Pentium Pro (Unknown model) (3099 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (834 MHz)",2, "Intel Pentium Pro (Unknown model) (3109 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1101 MHz)",2, "Intel Pentium 4 (Unknown model) (3640 MHz)",2, "Intel Pentium 4 Northwood (2822 MHz)",2, "Intel Pentium 4 Northwood (1744 MHz)",2, "AMD K7 (Unknown model) (2265 MHz)",2, "AMD (Unknown model) (973 MHz)",2, "Intel Pentium Pro (Unknown model) (2924 MHz)",2, "AMD (Unknown model) (902 MHz)",2, "Intel Pentium 4 Northwood (2561 MHz)",2, "AMD (Unknown model) (1831 MHz)",2, "Intel Pentium 4 (Unknown model) (4186 MHz)",2, "Intel Pentium Pro (Unknown model) (2690 MHz)",2, "AMD K7 (Unknown model) (1602 MHz)",2, "AMD (Unknown model) (2427 MHz)",2, "Intel Pentium Pro (Unknown model) (1556 MHz)",2, "AMD Athlon (0.18 micron)",2, "AMD (Unknown model) (2661 MHz)",2, "AMD K7 (Unknown model) (597 MHz)",2, "AMD K7 (Unknown model) (501 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (769 MHz)",2, "Intel Pentium 4 Northwood (2555 MHz)",2, "Intel Pentium 4 Northwood (2049 MHz)",2, "AMD (Unknown model) (1878 MHz)",2, "AMD Athlon (Thunderbird core) (1044 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1075 MHz)",2, "AMD (Unknown model) (1372 MHz)",2, "Intel Pentium Pro (Unknown model) (663 MHz)",2, "AMD K7 (Unknown model) (850 MHz)",2, "Intel Pentium Pro (Unknown model) (3501 MHz)",2, "Intel Pentium 4 (Unknown model) (3020 MHz)",2, "Intel Pentium 4 (Unknown model) (2466 MHz)",2, "AMD (Unknown model) (2724 MHz)",2, "AMD K7 (Unknown model) (1578 MHz)",2, "AMD Duron (Spitfire core) (696 MHz)",2, "Intel Pentium 4 Northwood (2125 MHz)",2, "AMD (Unknown model) (2461 MHz)",2, "AMD (Unknown model) (2285 MHz)",2, "Intel Pentium Pro (Unknown model) (4049 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (796 MHz)",2, "AMD (Unknown model) (1783 MHz)",2, "Intel Pentium 4 (Unknown model) (2300 MHz)",2, "Intel Pentium 4 (Unknown model) (2732 MHz)",2, "Intel Pentium 4 Northwood (1943 MHz)",2, "AMD Duron (Spitfire core) (697 MHz)",2, "Intel Pentium Pro (Unknown model) (1980 MHz)",2, "Dual PowerPC 7400 (1830 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1211 MHz)",2, "Intel Pentium 4 Northwood (2195 MHz)",2, "Intel Pentium 4 Northwood (2480 MHz)",2, "Intel Pentium 4 (Unknown model) (2299 MHz)",2, "AMD (Unknown model) (1038 MHz)",2, "Intel Pentium 4 (Unknown model) (2719 MHz)",2, "Intel Pentium 4 (Unknown model) (3966 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (1004 MHz)",2, "Intel Pentium 4 (Unknown model) (3447 MHz)",2, "AMD Mobile Duron (Morgan core) (1173 MHz)",2, "Intel Pentium 4 (Unknown model) (2817 MHz)",2, "Intel Pentium Pro (Unknown model) (3333 MHz)",2, "Intel Pentium 4 Northwood Xeon (2591 MHz)",2, "Intel Pentium 4 Willamette Xeon (2040 MHz)",2, "AMD (Unknown model) (2540 MHz)",2, "Intel Pentium 4 Willamette (1592 MHz)",2, "Intel Pentium 4 Northwood (3052 MHz)",2, "AMD Mobile Duron (Morgan core) (900 MHz)",2, "Intel Pentium 4 (Unknown model) (3550 MHz)",2, "Intel Pentium 4 (Unknown model) (3019 MHz)",2, "AMD Duron (Spitfire core) (948 MHz)",2, "Intel Pentium Pro (Unknown model) (2047 MHz)",2, "Intel Pentium 4 (Unknown model) (2423 MHz)",2, "Intel Pentium 4 (Unknown model) (2285 MHz)",2, "AMD K7 (Unknown model) (2179 MHz)",2, "Intel Pentium 4 (Unknown model) (3269 MHz)",2, "Intel Pentium 4 Willamette (1413 MHz)",2, "Intel Pentium Pro (Unknown model) (1712 MHz)",2, "Intel Pentium Pro (Unknown model) (3239 MHz)",2, "AMD Athlon (Thunderbird core) (805 MHz)",2, "Intel Pentium Pro (Unknown model) (1448 MHz)",2, "AMD (Unknown model) (2638 MHz)",2, "Intel Pentium Pro (Unknown model) (2789 MHz)",2, "Intel Pentium Pro (Unknown model) (1380 MHz)",2, "AMD K7 (Unknown model) (2023 MHz)",2, "Intel Pentium 4 (Unknown model) (3361 MHz)",2, "Intel Pentium 4 (Unknown model) (3633 MHz)",2, "Intel Pentium Pro (Unknown model) (648 MHz)",2, "AMD (Unknown model) (2562 MHz)",2, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1133 MHz)",2, "Intel Pentium Pro (Unknown model) (1281 MHz)",2, "AMD (Unknown model) (2968 MHz)",2, "AMD (Unknown model) (1377 MHz)",2, "Intel Pentium Pro (Unknown model) (2802 MHz)",2, "Dual PowerPC 7400 (2330 MHz)",2, "AMD Athlon (Thunderbird core) (1391 MHz)",2, "Intel Pentium 4 Willamette (1470 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1453 MHz)",2, "Intel Pentium Pro (Unknown model) (1745 MHz)",2, "Intel Pentium Pro (Unknown model) (3834 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (702 MHz)",2, "AMD K7 (Unknown model) (2276 MHz)",2, "Intel Pentium 4 Northwood (1760 MHz)",2, "AMD (Unknown model) (2765 MHz)",2, "Intel Pentium 4 Northwood (1601 MHz)",2, "Intel Pentium Pro (Unknown model) (1121 MHz)",2, "Intel Pentium 4 (Unknown model) (3093 MHz)",2, "AMD (Unknown model) (1138 MHz)",2, "Intel Pentium 4 Willamette (1812 MHz)",2, "AMD Athlon (Thunderbird core) (1412 MHz)",2, "AMD (Unknown model) (2425 MHz)",2, "AMD K7 (Unknown model) (2365 MHz)",2, "Intel Pentium 4 (Unknown model) (3708 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1759 MHz)",2, "Intel Pentium 4 Northwood (2068 MHz)",2, "AMD K7 (Unknown model) (1948 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (984 MHz)",2, "Intel Pentium 4 (Unknown model) (3021 MHz)",2, "Intel Pentium II with internal L2 cache (333 MHz)",2, "i386 (Unknown) (1600 MHz)",2, "Intel Pentium Pro (Unknown model) (1370 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1749 MHz)",2, "Intel Pentium 4 (Unknown model) (3524 MHz)",2, "AMD (Unknown model) (2804 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1206 MHz)",2, "Intel Pentium 4 (Unknown model) (1503 MHz)",2, "AMD Duron (Spitfire core) (958 MHz)",2, "Intel Pentium Pro (Unknown model) (323 MHz)",2, "AMD (Unknown model) (2121 MHz)",2, "Intel Pentium 4 Northwood (3086 MHz)",2, "Intel Pentium 4 (Unknown model) (1514 MHz)",2, "Intel Pentium Pro (Unknown model) (1871 MHz)",2, "Intel Pentium 4 Northwood (3203 MHz)",2, "Intel Pentium Pro (Unknown model) (1763 MHz)",2, "Intel Pentium 4 (Unknown model) (2897 MHz)",2, "Intel Pentium 4 Northwood (3448 MHz)",2, "Intel Pentium 4 Northwood (2900 MHz)",2, "Intel Pentium Pro (Unknown model) (3833 MHz)",2, "AMD K7 (Unknown model) (2336 MHz)",2, "Intel Pentium 4 Willamette (1680 MHz)",2, "Intel Pentium Pro (Unknown model) (1210 MHz)",2, "PowerPC 7450 (798 MHz)",2, "Intel Pentium 4 (Unknown model) (2781 MHz)",2, "AMD Athlon (Thunderbird core) (757 MHz)",2, "Intel Pentium 4 Northwood (1900 MHz)",2, "Intel Pentium 4 Northwood (1839 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1548 MHz)",2, "AMD K7 (Unknown model) (1484 MHz)",2, "Intel Pentium 4 Northwood (1977 MHz)",2, "AMD K7 (Unknown model) (1878 MHz)",2, "AMD K7 (Unknown model) (1358 MHz)",2, "Intel Pentium Pro (Unknown model) (811 MHz)",2, "AMD K7 (Unknown model) (2315 MHz)",2, "AMD K7 (Unknown model) (1620 MHz)",2, "AMD (Unknown model) (2705 MHz)",2, "Intel Pentium 4 (Unknown model) (2838 MHz)",2, "Intel Pentium Pro (Unknown model) (2090 MHz)",2, "Intel Pentium Pro (Unknown model) (1621 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (731 MHz)",2, "Intel Pentium Pro (Unknown model) (2562 MHz)",2, "Intel Pentium 4 (Unknown model) (3172 MHz)",2, "AMD (Unknown model) (2643 MHz)",2, "Intel Pentium 4 Northwood (2711 MHz)",2, "PowerPC 7400 (598 MHz)",2, "Intel Pentium 4 (Unknown model) (3228 MHz)",2, "Intel Pentium Pro (Unknown model) (1460 MHz)",2, "Intel Pentium 4 (Unknown model) (3835 MHz)",2, "Intel Pentium 4 (Unknown model) (2831 MHz)",2, "Intel Pentium 4 (Unknown model) (2538 MHz)",2, "Intel Pentium 4 (Unknown model) (3843 MHz)",2, "Intel Pentium Pro (Unknown model) (3397 MHz)",2, "Intel Pentium 4 (Unknown model) (2849 MHz)",2, "Dual PowerPC 7450 (600 MHz)",2, "AMD K7 (Unknown model) (1864 MHz)",2, "AMD (Unknown model) (865 MHz)",2, "Intel Pentium 4 Willamette Xeon (1600 MHz)",2, "AMD K7 (Unknown model) (1944 MHz)",2, "Intel Pentium 4 (Unknown model) (3381 MHz)",2, "Intel Pentium Pro (Unknown model) (2220 MHz)",2, "AMD K7 (Unknown model) (1657 MHz)",2, "AMD (Unknown model) (2870 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (796 MHz)",2, "Intel Pentium Pro (Unknown model) (2772 MHz)",2, "Intel Pentium 4 Willamette (1869 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (790 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (840 MHz)",2, "AMD (Unknown model) (882 MHz)",2, "AMD (Unknown model) (2171 MHz)",2, "Intel Pentium Pro (Unknown model) (2516 MHz)",2, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1110 MHz)",2, "Intel Pentium Pro (Unknown model) (2834 MHz)",2, "Intel Pentium Pro (Unknown model) (2199 MHz)",2, "Intel Pentium 4 Willamette (1984 MHz)",2, "AMD K7 (Unknown model) (1902 MHz)",2, "Intel Pentium Pro (Unknown model) (1279 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1417 MHz)",2, "Intel Pentium 4 (Unknown model) (2430 MHz)",2, "AMD (Unknown model) (2576 MHz)",2, "Intel Pentium Pro (Unknown model) (1369 MHz)",2, "AMD (Unknown model) (2791 MHz)",2, "AMD Athlon (0.18 micron) (750 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1726 MHz)",2, "Intel Pentium 4 Northwood (3300 MHz)",2, "Intel Pentium 4 (Unknown model) (2670 MHz)",2, "Intel Pentium 4 (Unknown model) (3508 MHz)",2, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1299 MHz)",2, "Intel Pentium 4 (Unknown model) (2438 MHz)",2, "Intel Pentium Pro (Unknown model) (3401 MHz)",2, "Intel Pentium 4 Northwood (2002 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1199 MHz)",2, "AMD (Unknown model) (2359 MHz)",2, "Intel Pentium 4 Willamette (1728 MHz)",2, "Intel Pentium 4 Northwood Xeon (2207 MHz)",2, "AMD (Unknown model) (1476 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1329 MHz)",2, "AMD Athlon (0.18 micron) (698 MHz)",2, "AMD (Unknown model) (1009 MHz)",2, "Intel Pentium Pro (Unknown model) (664 MHz)",2, "AMD K7 (Unknown model) (2150 MHz)",2, "Intel Pentium Pro (Unknown model) (625 MHz)",2, "Intel Pentium 4 Northwood (3401 MHz)",2, "Intel Pentium 4 (Unknown model) (4483 MHz)",2, "Intel Pentium 4 Northwood (2584 MHz)",2, "Intel Pentium Pro (Unknown model) (2170 MHz)",2, "Intel Pentium Pro (Unknown model) (560 MHz)",2, "AMD (Unknown model) (1239 MHz)",2, "Intel Pentium 4 (Unknown model) (2970 MHz)",2, "Intel Pentium 4 (Unknown model) (2895 MHz)",2, "Intel Pentium 4 Willamette (2052 MHz)",2, "AMD (Unknown model) (1737 MHz)",2, "AMD K7 (Unknown model) (2152 MHz)",2, "Intel Pentium 4 Northwood (3061 MHz)",2, "AMD (Unknown model) (1922 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (794 MHz)",2, "Intel Pentium Pro (Unknown model) (1246 MHz)",2, "Intel Pentium 4 (Unknown model) (3968 MHz)",2, "AMD (Unknown model) (2782 MHz)",2, "AMD (Unknown model) (2175 MHz)",2, "Intel Pentium Pro (Unknown model) (509 MHz)",2, "AMD (Unknown model) (3009 MHz)",2, "Intel Pentium Pro (Unknown model) (655 MHz)",2, "AMD (Unknown model) (2762 MHz)",2, "Intel Pentium Pro (Unknown model) (636 MHz)",2, "Intel Pentium 4 (Unknown model) (3484 MHz)",2, "Intel Pentium 4 (Unknown model) (2983 MHz)",2, "Intel Pentium Pro (Unknown model) (3201 MHz)",2, "Intel Pentium Pro (Unknown model) (1174 MHz)",2, "Intel Pentium Pro (Unknown model) (1758 MHz)",2, "Intel Pentium 4 Northwood (2324 MHz)",2, "Intel Pentium 4 Northwood Xeon (2655 MHz)",2, "Intel Pentium 4 Northwood (3412 MHz)",2, "Intel Pentium Pro (Unknown model) (1764 MHz)",2, "AMD (Unknown model) (1395 MHz)",2, "Intel Pentium 4 Northwood (2559 MHz)",2, "Intel Pentium 4 Northwood (3115 MHz)",2, "AMD (Unknown model) (1201 MHz)",2, "Intel Pentium 4 (Unknown model) (2913 MHz)",2, "AMD (Unknown model) (2469 MHz)",2, "Intel Pentium 4 (Unknown model) (3026 MHz)",2, "Intel Pentium 4 Northwood (2877 MHz)",2, "AMD (Unknown model) (2091 MHz)",2, "AMD (Unknown model) (876 MHz)",2, "Intel Pentium 4 (Unknown model) (3307 MHz)",2, "Intel Pentium Pro (Unknown model) (2429 MHz)",2, "AMD K7 (Unknown model) (2068 MHz)",2, "AMD (Unknown model) (2076 MHz)",2, "AMD (Unknown model) (945 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (939 MHz)",2, "Intel Pentium 4 Northwood (1716 MHz)",2, "AMD K7 (Unknown model) (927 MHz)",2, "AMD K7 (Unknown model) (1710 MHz)",2, "Intel Pentium 4 (Unknown model) (2454 MHz)",2, "AMD K7 (Unknown model) (1280 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1271 MHz)",2, "Intel Pentium Pro (Unknown model) (2566 MHz)",2, "AMD (Unknown model) (2082 MHz)",2, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1311 MHz)",2, "AMD (Unknown model) (1885 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1515 MHz)",2, "Intel Pentium Pro (Unknown model) (2719 MHz)",2, "AMD Athlon (Thunderbird core) (1337 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (981 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1643 MHz)",2, "Intel Pentium 4 (Unknown model) (3819 MHz)",2, "AMD (Unknown model) (2380 MHz)",2, "AMD K7 (Unknown model) (2118 MHz)",2, "AMD (Unknown model) (2156 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache",2, "AMD Athlon (0.25 micron) (698 MHz)",2, "Intel Pentium Pro (Unknown model) (2015 MHz)",2, "Intel Pentium Pro (Unknown model) (3298 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (551 MHz)",2, "AMD Athlon (0.25 micron) (604 MHz)",2, "Intel Pentium 4 Northwood (3096 MHz)",2, "Intel Pentium Pro (Unknown model) (3019 MHz)",2, "Intel Pentium 4 Northwood (2538 MHz)",2, "AMD (Unknown model) (2341 MHz)",2, "Intel Pentium 4 Northwood (1921 MHz)",2, "Unknown (796 MHz)",2, "Intel Pentium Pro (Unknown model) (2960 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (735 MHz)",2, "AMD (Unknown model) (895 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (986 MHz)",2, "Intel Pentium 4 Northwood (2119 MHz)",2, "Intel Pentium Pro (Unknown model) (1101 MHz)",2, "Intel Pentium 4 (Unknown model) (2313 MHz)",2, "AMD K7 (Unknown model) (1424 MHz)",2, "AMD (Unknown model) (1483 MHz)",2, "AMD (Unknown model) (2704 MHz)",2, "Intel Pentium Pro (Unknown model) (3464 MHz)",2, "Intel Pentium Pro (Unknown model) (1043 MHz)",2, "AMD K7 (Unknown model) (1383 MHz)",2, "Intel Pentium 4 (Unknown model) (2437 MHz)",2, "Intel Pentium 4 (Unknown model) (2877 MHz)",2, "Intel Pentium Pro (Unknown model) (1779 MHz)",2, "Intel Pentium Pro (Unknown model) (2151 MHz)",2, "AMD (Unknown model) (1721 MHz)",2, "AMD K7 (Unknown model) (1440 MHz)",2, "Intel Pentium Pro (Unknown model) (2519 MHz)",2, "Intel Pentium Pro (Unknown model) (665 MHz)",2, "AMD (Unknown model) (2490 MHz)",2, "AMD (Unknown model) (2173 MHz)",2, "AMD K7 (Unknown model) (2277 MHz)",2, "AMD K7 (Unknown model) (2224 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1156 MHz)",2, "Intel Pentium Pro (Unknown model) (2295 MHz)",2, "AMD K6-2",2, "Intel Pentium 4 (Unknown model) (2978 MHz)",2, "AMD K7 (Unknown model) (801 MHz)",2, "Intel Pentium 4 (Unknown model) (2906 MHz)",2, "Intel Pentium Pro (Unknown model) (1542 MHz)",2, "AMD Athlon (Thunderbird core) (1049 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1512 MHz)",2, "Intel Pentium Pro (Unknown model) (1647 MHz)",2, "Intel Pentium 4 (Unknown model) (3706 MHz)",2, "Intel Pentium 4 Northwood (1984 MHz)",2, "Intel Pentium 4 Northwood (2719 MHz)",2, "AMD (Unknown model) (2563 MHz)",2, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (801 MHz)",2, "Intel Pentium Pro (Unknown model) (520 MHz)",2, "Intel Pentium Pro (Unknown model) (1260 MHz)",2, "Intel Pentium 4 (Unknown model) (3781 MHz)",2, "Intel Pentium 4 (Unknown model) (3559 MHz)",2, "AMD (Unknown model) (1026 MHz)",2, "Intel Pentium 4 (Unknown model) (2273 MHz)",2, "Intel Pentium 4 Northwood Xeon (1700 MHz)",2, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1007 MHz)",2, "Intel Pentium Pro (Unknown model) (762 MHz)",2, "AMD K7 (Unknown model) (1758 MHz)",2, "Intel Pentium Pro (Unknown model) (3007 MHz)",2, "Intel Pentium 4 Northwood (2973 MHz)",2, "AMD (Unknown model) (1728 MHz)",2, "AMD (Unknown model) (1176 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1478 MHz)",2, "Intel Pentium 4 Northwood (3220 MHz)",2, "Intel Pentium 4 (Unknown model) (2980 MHz)",2, "Intel Pentium 4 Northwood (2613 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (896 MHz)",2, "AMD (Unknown model) (2144 MHz)",2, "AMD (Unknown model) (2331 MHz)",2, "Intel Pentium Pro (Unknown model) (964 MHz)",2, "Intel Pentium 4 Northwood (2614 MHz)",2, "AMD K7 (Unknown model) (1782 MHz)",2, "AMD K7 (Unknown model) (1641 MHz)",2, "Intel Pentium 4 Willamette Xeon (1870 MHz)",2, "AMD K7 (Unknown model) (1395 MHz)",2, "AMD (Unknown model) (2478 MHz)",2, "Intel Pentium Pro (Unknown model) (2159 MHz)",2, "Intel Pentium 4 (Unknown model) (3331 MHz)",2, "AMD (Unknown model) (1931 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1298 MHz)",2, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1000 MHz)",2, "AMD (Unknown model) (1430 MHz)",2, "Unknown (800 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (549 MHz)",2, "AMD K7 (Unknown model) (1868 MHz)",2, "AMD K7 (Unknown model) (1953 MHz)",2, "Intel Pentium 4 Northwood (1914 MHz)",2, "Intel Pentium 4 Northwood Xeon (1604 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1575 MHz)",2, "Intel Pentium 4 (Unknown model) (2110 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (654 MHz)",2, "Intel Pentium 4 (Unknown model) (3449 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1539 MHz)",2, "AMD (Unknown model) (2823 MHz)",2, "Intel Pentium 4 Willamette Xeon (1714 MHz)",2, "Intel Pentium Pro (Unknown model) (652 MHz)",2, "AMD Athlon (Thunderbird core) (798 MHz)",2, "Intel Pentium Pro (Unknown model) (759 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (399 MHz)",2, "Intel Pentium 4 Northwood (3043 MHz)",2, "AMD K7 (Unknown model) (1433 MHz)",2, "Intel Pentium 4 Northwood (2511 MHz)",2, "AMD (Unknown model) (1074 MHz)",2, "Intel Pentium Pro (Unknown model) (724 MHz)",2, "Intel Pentium 4 Willamette Xeon (1836 MHz)",2, "Intel Pentium Pro (Unknown model) (2074 MHz)",2, "AMD (Unknown model) (2145 MHz)",2, "Intel Pentium Pro (Unknown model) (316 MHz)",2, "Intel Pentium 4 Northwood (2023 MHz)",2, "AMD (Unknown model) (2489 MHz)",2, "Intel Pentium Pro (Unknown model) (1654 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (1007 MHz)",2, "Intel Pentium 4 (Unknown model) (3566 MHz)",2, "Intel Pentium III Xeon (0.18 micron process) with internal L2 cache (731 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (602 MHz)",2, "Intel Pentium 4 (Unknown model) (3516 MHz)",2, "AMD (Unknown model) (1782 MHz)",2, "Intel Pentium Pro (Unknown model) (1177 MHz)",2, "Intel Pentium 4 (Unknown model) (2595 MHz)",2, "Intel Pentium Pro (Unknown model) (641 MHz)",2, "Intel Pentium 4 (Unknown model) (2726 MHz)",2, "AMD K7 (Unknown model) (1611 MHz)",2, "Intel Pentium 4 Northwood (2414 MHz)",2, "Intel Pentium 4 Northwood (2550 MHz)",2, "Intel Pentium Pro (Unknown model) (238 MHz)",2, "AMD Athlon (Thunderbird core) (895 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1725 MHz)",2, "AMD (Unknown model) (2126 MHz)",2, "Intel Pentium 4 (Unknown model) (2723 MHz)",2, "Intel Pentium 4 Northwood Xeon (2489 MHz)",2, "Intel Pentium Pro (Unknown model) (3424 MHz)",2, "Intel Pentium 4 (Unknown model) (3521 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1403 MHz)",2, "Intel Pentium 4 (Unknown model) (4179 MHz)",2, "Intel Pentium Pro (Unknown model) (1489 MHz)",2, "AMD Athlon (Thunderbird core) (1203 MHz)",2, "Intel Pentium Pro (Unknown model) (711 MHz)",2, "AMD (Unknown model) (2235 MHz)",2, "AMD (Unknown model) (934 MHz)",2, "Intel Pentium 4 Northwood (2005 MHz)",2, "Intel Pentium 4 Willamette (A-Step) (1597 MHz)",2, "Intel Pentium 4 Northwood (1196 MHz)",2, "AMD (Unknown model) (2366 MHz)",2, "AMD K7 (Unknown model) (2296 MHz)",2, "AMD K7 (Unknown model) (1177 MHz)",2, "Intel Pentium Pro (Unknown model) (1159 MHz)",2, "Intel Celeron (0.18 micron process) with internal L2 cache (906 MHz)",2, "AMD (Unknown model) (2568 MHz)",2, "AMD K7 (Unknown model) (2195 MHz)",2, "Intel Pentium Pro (Unknown model) (2380 MHz)",2, "AMD Mobile Duron (Morgan core) (1328 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core)",2, "Intel Pentium 4 (Unknown model) (3482 MHz)",2, "AMD (Unknown model) (935 MHz)",2, "Intel Pentium 4 Northwood (2413 MHz)",2, "Intel Pentium Pro (Unknown model) (2578 MHz)",2, "Intel Pentium 4 (Unknown model) (3897 MHz)",2, "AMD Athlon (Thunderbird core) (1331 MHz)",2, "Intel Pentium 4 Northwood Xeon (1549 MHz)",2, "Intel Pentium Pro (Unknown model) (2008 MHz)",2, "Intel Pentium 4 Northwood (1395 MHz)",2, "AMD K7 (Unknown model) (2025 MHz)",2, "Intel Pentium Pro (Unknown model) (2063 MHz)",2, "AMD K7 (Unknown model) (1566 MHz)",2, "AMD (Unknown model) (2879 MHz)",2, "AMD (Unknown model) (1255 MHz)",2, "Intel Pentium 4 (Unknown model) (1398 MHz)",2, "Intel Pentium Pro (Unknown model) (2661 MHz)",2, "Intel Pentium 4 Northwood (2760 MHz)",2, "Intel Pentium 4 (Unknown model) (3765 MHz)",2, "AMD (Unknown model)",2, "AMD (Unknown model) (1336 MHz)",2, "Intel Pentium 4 (Unknown model) (3605 MHz)",2, "AMD (Unknown model) (838 MHz)",2, "Intel Pentium 4 (Unknown model) (3098 MHz)",2, "AMD K7 (Unknown model) (1512 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1606 MHz)",2, "Intel Pentium III (0.18 micron process) with internal L2 cache (793 MHz)",2, "AMD (Unknown model) (2950 MHz)",2, "Intel Pentium Pro (Unknown model) (686 MHz)",2, "AMD K7 (Unknown model) (954 MHz)",2, "Intel Pentium Pro (Unknown model) (2975 MHz)",2, "Intel Pentium 4 (Unknown model) (3338 MHz)",2, "Intel Pentium 4 Northwood (3091 MHz)",2, "AMD K7 (Unknown model) (2326 MHz)",2, "Intel Pentium Pro (Unknown model) (602 MHz)",2, "Intel Pentium 4 (Unknown model) (3036 MHz)",2, "Intel Pentium Pro (Unknown model) (3400 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1700 MHz)",2, "Intel Pentium 4 (Unknown model) (1800 MHz)",2, "Intel Pentium Pro (Unknown model) (518 MHz)",2, "Intel Pentium 4 (Unknown model) (3631 MHz)",2, "AMD Athlon MP/Mobile Athlon (Palomino core) (1680 MHz)",2, "AMD K7 (Unknown model) (1203 MHz)",2, "AMD (Unknown model) (1942 MHz)",2, "Intel Pentium 4 Northwood (3123 MHz)",2, "Intel Pentium 4 Northwood (2474 MHz)",2, "Intel Pentium Pro (Unknown model) (1876 MHz)",2, "AMD K7 (Unknown model) (2220 MHz)",2, "AMD (Unknown model) (1972 MHz)",2, "Intel Pentium Pro (Unknown model) (2304 MHz)",2, "Intel Pentium 4 Northwood (3601 MHz)",2, "Intel Pentium Pro (Unknown model) (1207 MHz)",2, "Intel Pentium 4 (Unknown model) (2958 MHz)",2, "AMD (Unknown model) (939 MHz)",2, "AMD (Unknown model) (2055 MHz)",2, "Intel Pentium Pro (Unknown model) (2812 MHz)",2, "AMD (Unknown model) (1620 MHz)",2, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1512 MHz)",2, "Intel Pentium 4 (Unknown model) (3420 MHz)",2, "Intel Pentium 4 Northwood Xeon (2895 MHz)",1, "Intel Pentium 4 (Unknown model) (3806 MHz)",1, "Intel Pentium Pro (Unknown model) (562 MHz)",1, "AMD (Unknown model) (855 MHz)",1, "AMD K7 (Unknown model) (2223 MHz)",1, "Intel Pentium Pro (Unknown model) (1682 MHz)",1, "Intel Pentium 4 (Unknown model) (4266 MHz)",1, "Intel Pentium Pro (Unknown model) (1437 MHz)",1, "Intel Pentium 4 Northwood Xeon (2987 MHz)",1, "AMD K7 (Unknown model) (2134 MHz)",1, "AMD Athlon (Thunderbird core) (1259 MHz)",1, "AMD K7 (Unknown model) (2213 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1146 MHz)",1, "Intel Pentium 4 (Unknown model) (4154 MHz)",1, "AMD Athlon (Thunderbird core) (1094 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1165 MHz)",1, "AMD Athlon (Thunderbird core) (1320 MHz)",1, "AMD Athlon (Thunderbird core) (1298 MHz)",1, "AMD (Unknown model) (2552 MHz)",1, "AMD (Unknown model) (1015 MHz)",1, "AMD K7 (Unknown model) (1183 MHz)",1, "Intel Pentium Pro (Unknown model) (1485 MHz)",1, "Intel Pentium Pro (Unknown model) (2991 MHz)",1, "Intel Pentium Pro (Unknown model) (579 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (453 MHz)",1, "AMD K7 (Unknown model) (1242 MHz)",1, "Intel Pentium 4 (Unknown model) (4347 MHz)",1, "Intel Pentium Pro (Unknown model) (540 MHz)",1, "Intel Pentium Pro (Unknown model) (553 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1081 MHz)",1, "Intel Pentium 4 Northwood (3205 MHz)",1, "AMD K7 (Unknown model) (1239 MHz)",1, "AMD Athlon (Thunderbird core) (741 MHz)",1, "Intel Pentium Pro (Unknown model) (556 MHz)",1, "Intel Pentium Pro (Unknown model) (578 MHz)",1, "AMD K7 (Unknown model) (2062 MHz)",1, "AMD K7 (Unknown model) (2147 MHz)",1, "AMD K7 (Unknown model) (2339 MHz)",1, "Intel Pentium Pro (Unknown model) (3252 MHz)",1, "AMD K7 (Unknown model) (1939 MHz)",1, "Intel Pentium Pro (Unknown model) (2195 MHz)",1, "Intel Pentium Pro (Unknown model) (3004 MHz)",1, "AMD (Unknown model) (1273 MHz)",1, "AMD K7 (Unknown model) (2304 MHz)",1, "AMD K7 (Unknown model) (1279 MHz)",1, "Intel Pentium Pro (Unknown model) (544 MHz)",1, "Intel Pentium Pro (Unknown model) (2229 MHz)",1, "Intel Pentium Pro (Unknown model) (1459 MHz)",1, "Intel Pentium Pro (Unknown model) (2183 MHz)",1, "Intel Pentium Pro (Unknown model) (1977 MHz)",1, "Intel Pentium 4 (Unknown model) (4183 MHz)",1, "Intel Pentium 4 (Unknown model) (4184 MHz)",1, "Intel Pentium Pro (Unknown model) (3008 MHz)",1, "Intel Pentium Pro (Unknown model) (2011 MHz)",1, "Intel Pentium Pro (Unknown model) (539 MHz)",1, "Intel Pentium 4 Northwood (2445 MHz)",1, "AMD K7 (Unknown model) (2298 MHz)",1, "AMD (Unknown model) (1464 MHz)",1, "Intel Pentium Pro (Unknown model) (1689 MHz)",1, "AMD K7 (Unknown model) (1356 MHz)",1, "Intel Pentium 4 Northwood Xeon (1860 MHz)",1, "AMD K7 (Unknown model) (2102 MHz)",1, "Intel Pentium Pro (Unknown model) (3115 MHz)",1, "Intel Pentium Pro (Unknown model) (2323 MHz)",1, "Intel Pentium 4 (Unknown model) (2619 MHz)",1, "Intel Pentium Pro (Unknown model) (1718 MHz)",1, "AMD Athlon (Thunderbird core) (934 MHz)",1, "Intel Pentium 4 (Unknown model) (4298 MHz)",1, "Intel Pentium Pro (Unknown model) (537 MHz)",1, "AMD K7 (Unknown model) (1030 MHz)",1, "Intel Pentium Pro (Unknown model) (3096 MHz)",1, "Intel Pentium Pro (Unknown model) (614 MHz)",1, "AMD Athlon (Thunderbird core) (1308 MHz)",1, "Intel Pentium Pro (Unknown model) (1340 MHz)",1, "AMD K7 (Unknown model) (2151 MHz)",1, "AMD K7 (Unknown model) (1157 MHz)",1, "AMD (Unknown model) (2555 MHz)",1, "AMD (Unknown model) (2928 MHz)",1, "AMD (Unknown model) (1565 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (761 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1281 MHz)",1, "AMD Athlon (Thunderbird core) (947 MHz)",1, "AMD (Unknown model) (1581 MHz)",1, "AMD Duron (Spitfire core) (650 MHz)",1, "Intel Pentium Pro (Unknown model) (541 MHz)",1, "AMD (Unknown model) (814 MHz)",1, "AMD (Unknown model) (943 MHz)",1, "AMD (Unknown model) (2141 MHz)",1, "Intel Pentium Pro (Unknown model) (3458 MHz)",1, "AMD K7 (Unknown model) (2256 MHz)",1, "Intel Pentium Pro (Unknown model) (1986 MHz)",1, "Intel Pentium Pro (Unknown model) (1982 MHz)",1, "Intel Pentium 4 (Unknown model) (4081 MHz)",1, "Intel Pentium 4 (Unknown model) (4466 MHz)",1, "Intel Pentium Pro (Unknown model) (2457 MHz)",1, "Intel Pentium Pro (Unknown model) (550 MHz)",1, "Intel Pentium 4 Northwood (2012 MHz)",1, "Intel Pentium Pro (Unknown model) (1508 MHz)",1, "Intel Pentium 4 Northwood (2132 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1058 MHz)",1, "AMD (Unknown model) (1206 MHz)",1, "AMD (Unknown model) (1515 MHz)",1, "AMD K7 (Unknown model) (2275 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (594 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1004 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1054 MHz)",1, "AMD K7 (Unknown model) (399 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1048 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1093 MHz)",1, "AMD (Unknown model) (2676 MHz)",1, "AMD Athlon (Thunderbird core) (1144 MHz)",1, "Intel Pentium 4 (Unknown model) (4246 MHz)",1, "Intel Pentium 4 (Unknown model) (3817 MHz)",1, "AMD (Unknown model) (871 MHz)",1, "Intel Pentium Pro (Unknown model) (2192 MHz)",1, "Intel Pentium Pro (Unknown model) (952 MHz)",1, "Intel Pentium Pro (Unknown model) (1512 MHz)",1, "AMD (Unknown model) (3179 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (666 MHz)",1, "Intel Pentium 4 (Unknown model) (3935 MHz)",1, "AMD (Unknown model) (1222 MHz)",1, "AMD Athlon (Thunderbird core) (1058 MHz)",1, "AMD K7 (Unknown model) (1392 MHz)",1, "AMD (Unknown model) (2819 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1607 MHz)",1, "AMD (Unknown model) (3740 MHz)",1, "Intel Pentium 4 Northwood Xeon (2162 MHz)",1, "AMD (Unknown model) (3149 MHz)",1, "AMD (Unknown model) (1282 MHz)",1, "AMD K7 (Unknown model) (1078 MHz)",1, "AMD (Unknown model) (2432 MHz)",1, "Intel Pentium 4 Willamette (1550 MHz)",1, "Intel Pentium Pro (Unknown model) (953 MHz)",1, "Intel Pentium Pro (Unknown model) (2501 MHz)",1, "AMD (Unknown model) (941 MHz)",1, "Intel Pentium 4 (Unknown model) (6021 MHz)",1, "AMD (Unknown model) (2466 MHz)",1, "AMD (Unknown model) (1303 MHz)",1, "AMD (Unknown model) (834 MHz)",1, "Intel Pentium 4 (Unknown model) (4470 MHz)",1, "AMD (Unknown model) (1568 MHz)",1, "AMD K7 (Unknown model) (1042 MHz)",1, "Intel Pentium 4 (Unknown model) (4215 MHz)",1, "AMD (Unknown model) (3334 MHz)",1, "AMD (Unknown model) (827 MHz)",1, "Intel Pentium 4 (Unknown model) (2783 MHz)",1, "AMD (Unknown model) (1376 MHz)",1, "AMD (Unknown model) (864 MHz)",1, "AMD (Unknown model) (1171 MHz)",1, "Intel Pentium Pro (Unknown model) (1183 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1109 MHz)",1, "AMD (Unknown model) (889 MHz)",1, "AMD (Unknown model) (906 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (916 MHz)",1, "Intel Pentium 4 Northwood Xeon (2505 MHz)",1, "Intel Pentium Pro (Unknown model) (618 MHz)",1, "AMD K7 (Unknown model) (2321 MHz)",1, "AMD (Unknown model) (904 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (927 MHz)",1, "Intel Pentium Pro (Unknown model) (972 MHz)",1, "AMD Mobile Duron (Morgan core) (1104 MHz)",1, "AMD K7 (Unknown model) (596 MHz)",1, "AMD Mobile Duron (Morgan core) (1155 MHz)",1, "AMD Athlon (0.18 micron) (899 MHz)",1, "Dual i386 (Unknown) (3300 MHz)",1, "Intel Pentium 4 Northwood Xeon (2917 MHz)",1, "Intel Pentium 4 (Unknown model) (4492 MHz)",1, "Intel Pentium 4 (Unknown model) (4047 MHz)",1, "AMD (Unknown model) (817 MHz)",1, "Intel Pentium 4 Northwood (3252 MHz)",1, "Intel Pentium Pro (Unknown model) (2246 MHz)",1, "AMD K7 (Unknown model) (4823 MHz)",1, "AMD Athlon (0.18 micron) (749 MHz)",1, "AMD K7 (Unknown model) (4565 MHz)",1, "AMD (Unknown model) (2372 MHz)",1, "AMD (Unknown model) (577 MHz)",1, "AMD (Unknown model) (653 MHz)",1, "AMD K7 (Unknown model) (688 MHz)",1, "AMD K7 (Unknown model) (735 MHz)",1, "Intel Pentium 4 (Unknown model) (3946 MHz)",1, "AMD K7 (Unknown model) (629 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (803 MHz)",1, "Intel Pentium 4 Willamette Xeon (1615 MHz)",1, "AMD (Unknown model) (3080 MHz)",1, "AMD (Unknown model) (1428 MHz)",1, "Intel Pentium Pro (Unknown model) (591 MHz)",1, "Intel Pentium Pro (Unknown model) (603 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1099 MHz)",1, "Intel Pentium 4 Northwood (2080 MHz)",1, "Intel Pentium 4 (Unknown model) (2413 MHz)",1, "Intel Pentium Pro (Unknown model) (2804 MHz)",1, "AMD (Unknown model) (3038 MHz)",1, "AMD (Unknown model) (3432 MHz)",1, "AMD K7 (Unknown model) (1345 MHz)",1, "AMD Athlon (0.18 micron) (757 MHz)",1, "AMD K7 (Unknown model) (1556 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1562 MHz)",1, "AMD K7 (Unknown model) (666 MHz)",1, "AMD Mobile Duron (Morgan core) (1052 MHz)",1, "AMD Athlon (0.18 micron) (659 MHz)",1, "AMD (Unknown model) (1157 MHz)",1, "Intel Pentium 4 Northwood Xeon (2789 MHz)",1, "Intel Pentium Pro (Unknown model) (722 MHz)",1, "Intel Pentium 4 (Unknown model) (4061 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (978 MHz)",1, "AMD (Unknown model) (2628 MHz)",1, "AMD (Unknown model) (826 MHz)",1, "AMD Mobile Duron (Morgan core) (1110 MHz)",1, "Intel Pentium Pro (Unknown model) (2618 MHz)",1, "AMD (Unknown model) (1391 MHz)",1, "AMD (Unknown model) (946 MHz)",1, "Intel Pentium 4 (Unknown model) (3933 MHz)",1, "AMD (Unknown model) (980 MHz)",1, "AMD (Unknown model) (977 MHz)",1, "AMD K7 (Unknown model) (1040 MHz)",1, "Intel Pentium 4 (Unknown model) (3120 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1704 MHz)",1, "AMD K7 (Unknown model) (2232 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (966 MHz)",1, "Intel Pentium Pro (Unknown model) (651 MHz)",1, "Intel Pentium Pro (Unknown model) (3514 MHz)",1, "Intel Pentium 4 (Unknown model) (2557 MHz)",1, "AMD Duron (Spitfire core) (905 MHz)",1, "Intel Pentium 4 (Unknown model) (3302 MHz)",1, "Intel Pentium Pro (Unknown model) (604 MHz)",1, "AMD Mobile Duron (Morgan core) (801 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1391 MHz)",1, "Intel Pentium 4 Northwood Xeon (2802 MHz)",1, "Intel Pentium Pro (Unknown model) (634 MHz)",1, "AMD (Unknown model) (968 MHz)",1, "Intel Pentium 4 (Unknown model) (5145 MHz)",1, "AMD Mobile Duron (Morgan core) (994 MHz)",1, "AMD (Unknown model) (1389 MHz)",1, "AMD Duron (Spitfire core) (803 MHz)",1, "AMD Athlon (Thunderbird core) (1360 MHz)",1, "AMD Athlon (Thunderbird core) (1334 MHz)",1, "AMD Athlon (Thunderbird core) (797 MHz)",1, "AMD (Unknown model) (931 MHz)",1, "Intel Pentium 4 Northwood (2166 MHz)",1, "AMD Athlon (Thunderbird core) (1413 MHz)",1, "AMD (Unknown model) (1193 MHz)",1, "AMD K7 (Unknown model) (2235 MHz)",1, "AMD Athlon (Thunderbird core) (724 MHz)",1, "AMD Athlon (Thunderbird core) (732 MHz)",1, "Intel Pentium Pro (Unknown model) (2271 MHz)",1, "Intel Pentium Pro (Unknown model) (1975 MHz)",1, "Intel Pentium 4 Northwood (1915 MHz)",1, "AMD Duron (Spitfire core) (918 MHz)",1, "Dual i386 (Unknown) (3200 MHz)",1, "AMD Duron (Spitfire core) (793 MHz)",1, "AMD (Unknown model) (1150 MHz)",1, "AMD (Unknown model) (1364 MHz)",1, "Intel Pentium 4 (Unknown model) (4401 MHz)",1, "AMD (Unknown model) (2047 MHz)",1, "Intel Pentium Pro (Unknown model) (590 MHz)",1, "AMD (Unknown model) (1354 MHz)",1, "Intel Pentium Pro (Unknown model) (2180 MHz)",1, "Intel Pentium 4 Northwood (2852 MHz)",1, "AMD K7 (Unknown model) (1023 MHz)",1, "Intel Pentium Pro (Unknown model) (1160 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (973 MHz)",1, "AMD (Unknown model) (919 MHz)",1, "Intel Pentium 4 (Unknown model) (5163 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1149 MHz)",1, "Intel Pentium Pro (Unknown model) (1430 MHz)",1, "Intel Pentium 4 Northwood (2252 MHz)",1, "Intel Pentium 4 Northwood (1195 MHz)",1, "AMD (Unknown model) (2681 MHz)",1, "AMD (Unknown model) (909 MHz)",1, "AMD Duron (Spitfire core) (698 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1475 MHz)",1, "Intel Pentium Pro (Unknown model) (1777 MHz)",1, "AMD K7 (Unknown model) (1321 MHz)",1, "Intel Pentium 4 Northwood (2926 MHz)",1, "AMD (Unknown model) (857 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (1011 MHz)",1, "Intel Pentium 4 Northwood (3678 MHz)",1, "Intel Pentium Pro (Unknown model) (2654 MHz)",1, "AMD K7 (Unknown model) (1517 MHz)",1, "Intel Pentium 4 (Unknown model) (4051 MHz)",1, "Intel Pentium 4 (Unknown model) (3689 MHz)",1, "Intel Pentium Pro (Unknown model) (2810 MHz)",1, "AMD (Unknown model) (901 MHz)",1, "AMD (Unknown model) (845 MHz)",1, "Intel Pentium 4 (Unknown model) (4253 MHz)",1, "AMD (Unknown model) (1298 MHz)",1, "Intel Pentium 4 Willamette Xeon (1689 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1303 MHz)",1, "Intel Pentium Pro (Unknown model) (2123 MHz)",1, "Intel Pentium 4 (Unknown model) (2446 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1389 MHz)",1, "Intel Pentium 4 (Unknown model) (4694 MHz)",1, "Intel Pentium 4 (Unknown model) (4704 MHz)",1, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (997 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1426 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache",1, "AMD (Unknown model) (969 MHz)",1, "AMD (Unknown model) (4209 MHz)",1, "AMD (Unknown model) (930 MHz)",1, "Dual i386 (Unknown) (2140 MHz)",1, "AMD (Unknown model) (988 MHz)",1, "AMD K7 (Unknown model) (1969 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1552 MHz)",1, "AMD (Unknown model) (925 MHz)",1, "Intel Pentium 4 Northwood (3402 MHz)",1, "AMD Athlon (0.18 micron) (525 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (622 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1381 MHz)",1, "AMD (Unknown model) (982 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1107 MHz)",1, "AMD K7 (Unknown model) (1441 MHz)",1, "Intel Pentium 4 Northwood Xeon (2419 MHz)",1, "Intel Pentium 4 (Unknown model) (3241 MHz)",1, "AMD (Unknown model) (2317 MHz)",1, "Intel Pentium Pro (Unknown model) (1167 MHz)",1, "Intel Pentium Pro (Unknown model) (1282 MHz)",1, "AMD Athlon (Thunderbird core) (1012 MHz)",1, "Intel Pentium 4 Northwood (2785 MHz)",1, "AMD Athlon (Thunderbird core) (1003 MHz)",1, "Intel Pentium Pro (Unknown model) (1583 MHz)",1, "Intel Pentium Pro (Unknown model) (2550 MHz)",1, "Intel Pentium Pro (Unknown model) (1586 MHz)",1, "Intel Pentium Pro (Unknown model) (672 MHz)",1, "Intel Pentium 4 Northwood Xeon (3194 MHz)",1, "Intel Pentium Pro (Unknown model) (1443 MHz)",1, "Intel Pentium 4 Northwood (2621 MHz)",1, "Intel Pentium Pro (Unknown model) (1342 MHz)",1, "Intel Pentium Pro (Unknown model) (647 MHz)",1, "Intel Pentium 4 (Unknown model) (3661 MHz)",1, "Intel Pentium 4 (Unknown model) (2937 MHz)",1, "Intel Pentium Pro (Unknown model) (1378 MHz)",1, "AMD (Unknown model) (1181 MHz)",1, "Intel Pentium Pro (Unknown model) (1573 MHz)",1, "Intel Pentium Pro (Unknown model) (1350 MHz)",1, "AMD (Unknown model) (2297 MHz)",1, "AMD (Unknown model) (1586 MHz)",1, "Intel Pentium Pro (Unknown model) (1482 MHz)",1, "Intel Pentium 4 Northwood Xeon (3078 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (222 MHz)",1, "Intel Pentium Pro (Unknown model) (1085 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (602 MHz)",1, "Intel Pentium 4 Northwood (2140 MHz)",1, "AMD (Unknown model) (950 MHz)",1, "Intel Pentium 4 (Unknown model) (4282 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (589 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (596 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (481 MHz)",1, "Intel Pentium 4 (Unknown model) (4000 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (429 MHz)",1, "AMD K7 (Unknown model) (1958 MHz)",1, "Intel Pentium Pro (Unknown model) (2227 MHz)",1, "Intel Pentium 4 (Unknown model) (6624 MHz)",1, "Intel Pentium 4 Northwood (3100 MHz)",1, "Intel Pentium Pro (Unknown model) (1478 MHz)",1, "Intel Pentium Pro (Unknown model) (1480 MHz)",1, "Intel Pentium Pro (Unknown model) (576 MHz)",1, "AMD Athlon (Thunderbird core)",1, "AMD (Unknown model) (1915 MHz)",1, "AMD (Unknown model) (1638 MHz)",1, "AMD (Unknown model) (1196 MHz)",1, "Intel Pentium 4 (Unknown model) (3256 MHz)",1, "Intel Pentium 4 Northwood Xeon (2305 MHz)",1, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (880 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (724 MHz)",1, "Intel Pentium 4 Willamette Xeon (1791 MHz)",1, "AMD (Unknown model) (2618 MHz)",1, "AMD (Unknown model) (1487 MHz)",1, "Intel Pentium 4 Northwood (2440 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1676 MHz)",1, "Intel Pentium 4 Willamette Xeon (1688 MHz)",1, "AMD (Unknown model) (1706 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1712 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1581 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (983 MHz)",1, "Intel Pentium 4 (Unknown model) (2949 MHz)",1, "Intel Pentium Pro (Unknown model) (2030 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (943 MHz)",1, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1269 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (304 MHz)",1, "Intel Pentium 4 (Unknown model) (2465 MHz)",1, "Intel Pentium 4 Willamette Xeon (1781 MHz)",1, "Intel Pentium 4 (Unknown model) (3520 MHz)",1, "Intel Pentium Pro (Unknown model) (2565 MHz)",1, "Intel Pentium 4 Willamette Xeon (1798 MHz)",1, "Intel Pentium 4 Willamette Xeon (1808 MHz)",1, "Intel Pentium 4 Northwood (2501 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (703 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (1095 MHz)",1, "Intel Pentium Pro (Unknown model) (3689 MHz)",1, "Intel Pentium 4 Northwood Xeon (2188 MHz)",1, "Intel Pentium Pro (Unknown model) (565 MHz)",1, "Intel Pentium Pro (Unknown model) (865 MHz)",1, "Intel Pentium 4 Northwood (2682 MHz)",1, "Intel Pentium Pro (Unknown model) (2727 MHz)",1, "Intel Pentium Pro (Unknown model) (1453 MHz)",1, "Intel Pentium 4 (Unknown model) (4074 MHz)",1, "Intel Pentium 4 (Unknown model) (5012 MHz)",1, "Intel Pentium Pro (Unknown model) (1387 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (500 MHz)",1, "Intel Pentium Pro (Unknown model) (1577 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (706 MHz)",1, "AMD K7 (Unknown model) (904 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (753 MHz)",1, "Intel Pentium 4 (Unknown model) (2743 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (1021 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (1064 MHz)",1, "Intel Pentium 4 Willamette Xeon (1597 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (720 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (990 MHz)",1, "AMD (Unknown model) (2107 MHz)",1, "Intel Pentium Pro (Unknown model) (778 MHz)",1, "Intel Pentium 4 Northwood (2838 MHz)",1, "AMD (Unknown model) (1671 MHz)",1, "Intel Pentium 4 (Unknown model) (2819 MHz)",1, "Intel Pentium 4 Northwood (2716 MHz)",1, "AMD Athlon (Thunderbird core) (1324 MHz)",1, "Intel Pentium 4 Northwood (2733 MHz)",1, "Intel Pentium 4 Willamette (1871 MHz)",1, "Intel Pentium 4 (Unknown model) (2904 MHz)",1, "Intel Pentium 4 Northwood (2643 MHz)",1, "Intel Pentium 4 Northwood (2409 MHz)",1, "AMD K7 (Unknown model) (2370 MHz)",1, "Intel Pentium 4 Northwood (2668 MHz)",1, "Intel Pentium 4 Northwood (3221 MHz)",1, "Intel Pentium 4 Northwood (5967 MHz)",1, "Intel Pentium 4 Northwood Xeon (1439 MHz)",1, "AMD (Unknown model) (2654 MHz)",1, "i386 (Unknown) (1660 MHz)",1, "AMD (Unknown model) (846 MHz)",1, "Intel Pentium 4 Northwood Xeon (1429 MHz)",1, "Intel Pentium 4 Northwood (2738 MHz)",1, "Intel Pentium 4 Northwood (2751 MHz)",1, "AMD (Unknown model) (1058 MHz)",1, "Intel Pentium 4 Northwood Xeon (1446 MHz)",1, "AMD (Unknown model) (1924 MHz)",1, "Intel Pentium 4 Northwood (2649 MHz)",1, "Intel Pentium 4 Northwood (2929 MHz)",1, "Intel Pentium 4 Northwood (2709 MHz)",1, "Intel Pentium 4 (Unknown model) (3900 MHz)",1, "Intel Pentium 4 Northwood (3048 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (708 MHz)",1, "Intel Pentium 4 Northwood (2381 MHz)",1, "Intel Pentium 4 Willamette (1690 MHz)",1, "Intel Pentium 4 Willamette (1711 MHz)",1, "AMD (Unknown model) (1160 MHz)",1, "AMD (Unknown model) (1833 MHz)",1, "Intel Pentium Pro (Unknown model) (1981 MHz)",1, "Intel Pentium 4 Northwood (2960 MHz)",1, "Intel Pentium 4 (Unknown model) (2891 MHz)",1, "AMD K7 (Unknown model) (1337 MHz)",1, "AMD (Unknown model) (1275 MHz)",1, "AMD K7 (Unknown model) (1787 MHz)",1, "Intel Pentium 4 Northwood (2989 MHz)",1, "Intel Pentium 4 Northwood Xeon (1985 MHz)",1, "Intel Pentium Pro (Unknown model) (2196 MHz)",1, "Intel Pentium 4 Northwood (2425 MHz)",1, "AMD Athlon (Thunderbird core) (840 MHz)",1, "Intel Pentium 4 Northwood (3034 MHz)",1, "Intel Pentium 4 Northwood (2433 MHz)",1, "Intel Pentium 4 Northwood (3011 MHz)",1, "Intel Pentium Pro (Unknown model) (1134 MHz)",1, "AMD K7 (Unknown model) (1447 MHz)",1, "Intel Pentium Pro (Unknown model) (1176 MHz)",1, "Intel Pentium 4 Northwood (2603 MHz)",1, "Intel Pentium 4 (Unknown model) (3296 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (917 MHz)",1, "Intel Pentium Pro (Unknown model) (1168 MHz)",1, "AMD Duron (Spitfire core) (626 MHz)",1, "Intel Pentium 4 Northwood (3570 MHz)",1, "Intel Pentium Pro (Unknown model) (3558 MHz)",1, "AMD (Unknown model) (867 MHz)",1, "AMD (Unknown model) (1479 MHz)",1, "Intel Pentium 4 Northwood (3296 MHz)",1, "Intel Pentium 4 Northwood (2554 MHz)",1, "Intel Pentium 4 (Unknown model) (3974 MHz)",1, "Intel Pentium Pro (Unknown model) (1156 MHz)",1, "Intel Pentium Pro (Unknown model) (483 MHz)",1, "Intel Pentium Pro (Unknown model) (1250 MHz)",1, "Intel Pentium 4 Northwood Xeon (2189 MHz)",1, "Intel Pentium Pro (Unknown model) (1254 MHz)",1, "Intel Pentium Pro (Unknown model) (1135 MHz)",1, "Intel Pentium 4 Northwood (2329 MHz)",1, "Intel Pentium Pro (Unknown model) (1258 MHz)",1, "Intel Pentium Pro (Unknown model) (1270 MHz)",1, "AMD Athlon (0.18 micron) (601 MHz)",1, "Intel Pentium 4 Northwood (2654 MHz)",1, "Intel Pentium Pro (Unknown model) (2916 MHz)",1, "Intel Pentium 4 Northwood Xeon (1565 MHz)",1, "Intel Pentium 4 Northwood (2582 MHz)",1, "Intel Pentium 4 Northwood (3758 MHz)",1, "Intel Pentium 4 Northwood (2256 MHz)",1, "AMD Athlon (Thunderbird core) (946 MHz)",1, "Intel Pentium Pro (Unknown model) (3058 MHz)",1, "Intel Pentium 4 Northwood Xeon (1577 MHz)",1, "AMD K7 (Unknown model) (2334 MHz)",1, "Intel Pentium 4 Northwood Xeon (1457 MHz)",1, "AMD (Unknown model) (1167 MHz)",1, "Intel Pentium Pro (Unknown model) (628 MHz)",1, "Intel Pentium 4 Northwood (4213 MHz)",1, "Intel Pentium 4 Northwood (4480 MHz)",1, "Intel Pentium 4 Northwood (3358 MHz)",1, "Intel Pentium 4 Northwood (3524 MHz)",1, "Intel Pentium 4 Northwood (2341 MHz)",1, "Intel Pentium 4 (Unknown model) (4001 MHz)",1, "Intel Pentium 4 (Unknown model) (2685 MHz)",1, "Intel Pentium 4 Northwood (3093 MHz)",1, "Intel Pentium 4 Northwood (3637 MHz)",1, "Intel Pentium 4 Northwood (3144 MHz)",1, "Intel Pentium 4 Northwood (3159 MHz)",1, "Intel Pentium 4 Northwood (1889 MHz)",1, "Intel Pentium 4 (Unknown model) (1599 MHz)",1, "Intel Pentium 4 (Unknown model) (2004 MHz)",1, "AMD K7 (Unknown model) (1627 MHz)",1, "Intel Pentium 4 (Unknown model) (1894 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1616 MHz)",1, "Intel Pentium 4 (Unknown model) (1564 MHz)",1, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (488 MHz)",1, "Intel Pentium 4 Northwood (3307 MHz)",1, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (881 MHz)",1, "Intel Pentium 4 Northwood (2727 MHz)",1, "Intel Pentium 4 (Unknown model) (2421 MHz)",1, "AMD (Unknown model) (2052 MHz)",1, "Intel Pentium 4 Northwood Xeon (2259 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (816 MHz)",1, "Intel Pentium 4 Willamette (1806 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (831 MHz)",1, "Intel Pentium Pro (Unknown model) (3624 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1319 MHz)",1, "Intel Pentium 4 Northwood (2938 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (845 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (995 MHz)",1, "AMD (Unknown model) (2848 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1009 MHz)",1, "Intel Pentium Pro (Unknown model) (513 MHz)",1, "Intel Pentium Pro (Unknown model) (491 MHz)",1, "Intel Pentium 4 (Unknown model) (3154 MHz)",1, "Intel Pentium 4 (Unknown model) (3125 MHz)",1, "AMD (Unknown model) (2665 MHz)",1, "Intel Pentium 4 (Unknown model) (3083 MHz)",1, "AMD K7 (Unknown model) (1632 MHz)",1, "Intel Pentium 4 (Unknown model) (3152 MHz)",1, "Intel Pentium 4 (Unknown model) (2975 MHz)",1, "Intel Pentium 4 (Unknown model) (2284 MHz)",1, "Intel Pentium 4 (Unknown model) (2986 MHz)",1, "Intel Pentium 4 Northwood (1194 MHz)",1, "Intel Pentium 4 Northwood Xeon (1883 MHz)",1, "AMD (Unknown model) (924 MHz)",1, "Intel Pentium 4 Northwood Xeon (2002 MHz)",1, "Intel Pentium 4 Northwood (3219 MHz)",1, "Intel Pentium 4 (Unknown model) (1154 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (997 MHz)",1, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1129 MHz)",1, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1199 MHz)",1, "Intel Pentium 4 (Unknown model) (3121 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1222 MHz)",1, "Intel Pentium Pro (Unknown model) (1452 MHz)",1, "Intel Pentium 4 Northwood (2113 MHz)",1, "Intel Pentium 4 (Unknown model) (3095 MHz)",1, "Intel Pentium 4 (Unknown model) (3115 MHz)",1, "Intel Pentium 4 Northwood (1895 MHz)",1, "Intel Pentium 4 (Unknown model) (2157 MHz)",1, "Intel Pentium Pro (Unknown model) (2328 MHz)",1, "Intel Pentium 4 (Unknown model) (1824 MHz)",1, "Intel Pentium Pro (Unknown model) (254 MHz)",1, "Intel Pentium 4 (Unknown model) (2287 MHz)",1, "Intel Pentium 4 (Unknown model) (4161 MHz)",1, "Intel Pentium 4 (Unknown model) (2226 MHz)",1, "Intel Pentium 4 (Unknown model) (2202 MHz)",1, "Intel Pentium 4 (Unknown model) (2174 MHz)",1, "Intel Pentium 4 (Unknown model) (2029 MHz)",1, "Intel Pentium 4 Northwood (2640 MHz)",1, "AMD (Unknown model) (1276 MHz)",1, "Intel Pentium 4 Northwood (1962 MHz)",1, "Intel Pentium 4 Northwood (1968 MHz)",1, "Intel Pentium 4 Northwood (1861 MHz)",1, "PowerPC 7400 (550 MHz)",1, "Intel Pentium 4 Northwood (2142 MHz)",1, "Intel Pentium 4 (Unknown model) (2252 MHz)",1, "Intel Pentium 4 (Unknown model) (2303 MHz)",1, "Intel Pentium 4 (Unknown model) (2321 MHz)",1, "Intel Pentium 4 (Unknown model) (2275 MHz)",1, "Intel Pentium 4 (Unknown model) (3581 MHz)",1, "Intel Pentium 4 (Unknown model) (2280 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (769 MHz)",1, "Intel Pentium 4 Northwood (2824 MHz)",1, "AMD Mobile Duron (Morgan core) (1012 MHz)",1, "Intel Pentium Pro (Unknown model) (2898 MHz)",1, "Intel Pentium 4 Northwood (2515 MHz)",1, "Intel Pentium 4 Northwood (2254 MHz)",1, "AMD (Unknown model) (1106 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1107 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1132 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1396 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1148 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1201 MHz)",1, "AMD (Unknown model) (954 MHz)",1, "Intel Pentium 4 Northwood Xeon (1784 MHz)",1, "Intel Pentium 4 (Unknown model) (2540 MHz)",1, "Intel Pentium 4 (Unknown model) (2384 MHz)",1, "Intel Pentium 4 (Unknown model) (2535 MHz)",1, "Intel Pentium 4 (Unknown model) (2443 MHz)",1, "Intel Pentium 4 (Unknown model) (2570 MHz)",1, "Intel Pentium Pro (Unknown model) (732 MHz)",1, "Intel Pentium Pro (Unknown model) (3080 MHz)",1, "AMD (Unknown model) (2443 MHz)",1, "Intel Pentium 4 Willamette (1997 MHz)",1, "Intel Pentium 4 (Unknown model) (3809 MHz)",1, "Intel Pentium 4 Northwood Xeon (1612 MHz)",1, "AMD (Unknown model) (2837 MHz)",1, "Intel Pentium Pro (Unknown model) (1510 MHz)",1, "Intel Pentium 4 (Unknown model) (2835 MHz)",1, "Intel Pentium 4 Northwood (1703 MHz)",1, "Intel Pentium 4 Willamette (1916 MHz)",1, "Intel Pentium Pro (Unknown model) (2154 MHz)",1, "Intel Pentium 4 (Unknown model) (2887 MHz)",1, "Intel Pentium 4 (Unknown model) (3681 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (858 MHz)",1, "Intel Pentium 4 Northwood (1428 MHz)",1, "Intel Pentium 4 Northwood (1695 MHz)",1, "Intel Pentium 4 (Unknown model) (3886 MHz)",1, "AMD (Unknown model) (1043 MHz)",1, "Intel Pentium 4 Northwood (2361 MHz)",1, "Intel Pentium 4 (Unknown model) (2964 MHz)",1, "AMD (Unknown model) (1424 MHz)",1, "Intel Pentium Pro (Unknown model) (1676 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (670 MHz)",1, "Intel Pentium 4 (Unknown model) (2963 MHz)",1, "Intel Pentium 4 (Unknown model) (2823 MHz)",1, "Intel Pentium 4 Northwood Xeon (3080 MHz)",1, "Intel Pentium 4 (Unknown model) (2689 MHz)",1, "Intel Pentium 4 (Unknown model) (2950 MHz)",1, "Intel Pentium 4 Northwood (1592 MHz)",1, "Intel Pentium 4 (Unknown model) (2820 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (920 MHz)",1, "AMD Athlon (Thunderbird core) (1141 MHz)",1, "Intel Pentium 4 Northwood (3393 MHz)",1, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1469 MHz)",1, "AMD (Unknown model) (1445 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1192 MHz)",1, "Intel Pentium 4 Willamette Xeon (1709 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (975 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (977 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (810 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (397 MHz)",1, "Unknown (1389 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1405 MHz)",1, "Intel Pentium 4 Northwood (1327 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (781 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (789 MHz)",1, "AMD K7 (Unknown model) (605 MHz)",1, "Intel Pentium Pro (Unknown model) (1743 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (887 MHz)",1, "Intel Pentium 4 Willamette Xeon (1593 MHz)",1, "Intel Pentium 4 Northwood (1496 MHz)",1, "Intel Pentium 4 Northwood (3357 MHz)",1, "Intel Pentium 4 (Unknown model) (2644 MHz)",1, "AMD (Unknown model) (1928 MHz)",1, "Intel Pentium 4 Northwood (1514 MHz)",1, "Intel Pentium 4 (Unknown model) (3039 MHz)",1, "Intel Pentium 4 (Unknown model) (3162 MHz)",1, "AMD K7 (Unknown model) (1642 MHz)",1, "Intel Pentium 4 (Unknown model) (3289 MHz)",1, "Intel Pentium 4 (Unknown model) (3164 MHz)",1, "Intel Pentium 4 (Unknown model) (3177 MHz)",1, "Intel Pentium 4 (Unknown model) (3181 MHz)",1, "Intel Pentium 4 (Unknown model) (2749 MHz)",1, "Intel Pentium 4 (Unknown model) (2755 MHz)",1, "Intel Pentium 4 (Unknown model) (3034 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (918 MHz)",1, "AMD Mobile Duron (Morgan core) (989 MHz)",1, "AMD Athlon (Thunderbird core) (1295 MHz)",1, "Intel Pentium 4 Northwood (1632 MHz)",1, "Intel Pentium 4 (Unknown model) (3249 MHz)",1, "Intel Pentium 4 Northwood Xeon (2428 MHz)",1, "Intel Pentium 4 Northwood (3173 MHz)",1, "Intel Pentium 4 Northwood Xeon (1547 MHz)",1, "AMD (Unknown model) (1346 MHz)",1, "Intel Pentium 4 (Unknown model) (3310 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1565 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1456 MHz)",1, "Intel Pentium 4 (Unknown model) (3222 MHz)",1, "Intel Pentium 4 (Unknown model) (3301 MHz)",1, "Intel Pentium 4 Northwood Xeon (1418 MHz)",1, "AMD K7 (Unknown model) (1059 MHz)",1, "AMD Mobile Duron (Morgan core) (846 MHz)",1, "Intel Pentium Pro (Unknown model) (2646 MHz)",1, "Intel Pentium 4 (Unknown model) (2620 MHz)",1, "Intel Pentium Pro (Unknown model) (5348 MHz)",1, "Intel Pentium 4 (Unknown model) (3268 MHz)",1, "Intel Pentium 4 (Unknown model) (2917 MHz)",1, "Intel Pentium 4 (Unknown model) (2896 MHz)",1, "Intel Pentium 4 (Unknown model) (8770 MHz)",1, "Intel Pentium 4 (Unknown model) (3682 MHz)",1, "Intel Pentium 4 (Unknown model) (9031 MHz)",1, "AMD K7 (Unknown model) (2285 MHz)",1, "Intel Pentium 4 Northwood (2047 MHz)",1, "Intel Pentium 4 (Unknown model) (4420 MHz)",1, "Intel Pentium 4 (Unknown model) (2776 MHz)",1, "Intel Pentium 4 Northwood (1269 MHz)",1, "AMD (Unknown model) (861 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (742 MHz)",1, "AMD Athlon (0.25 micron) (493 MHz)",1, "Intel Pentium 4 (Unknown model) (1497 MHz)",1, "AMD K7 (Unknown model) (1292 MHz)",1, "Intel Pentium 4 (Unknown model) (3583 MHz)",1, "Intel Pentium 4 (Unknown model) (2643 MHz)",1, "Intel Pentium 4 (Unknown model) (6422 MHz)",1, "Intel Pentium 4 (Unknown model) (4998 MHz)",1, "AMD (Unknown model) (1107 MHz)",1, "AMD (Unknown model) (1109 MHz)",1, "Intel Pentium 4 (Unknown model) (2652 MHz)",1, "AMD (Unknown model) (1049 MHz)",1, "Intel Pentium 4 (Unknown model) (1706 MHz)",1, "AMD (Unknown model) (1102 MHz)",1, "AMD (Unknown model) (1085 MHz)",1, "AMD (Unknown model) (1133 MHz)",1, "Intel Pentium 4 Northwood (1707 MHz)",1, "AMD (Unknown model) (1092 MHz)",1, "AMD (Unknown model) (1098 MHz)",1, "AMD (Unknown model) (1062 MHz)",1, "Intel Pentium 4 Northwood (2334 MHz)",1, "AMD (Unknown model) (1183 MHz)",1, "Intel Pentium Pro (Unknown model) (1878 MHz)",1, "AMD (Unknown model) (1039 MHz)",1, "AMD (Unknown model) (1054 MHz)",1, "Intel Pentium 4 Northwood Xeon (2847 MHz)",1, "Intel Pentium 4 Northwood Xeon (2494 MHz)",1, "Intel Pentium Pro (Unknown model) (533 MHz)",1, "AMD (Unknown model) (1048 MHz)",1, "AMD (Unknown model) (2820 MHz)",1, "Intel Pentium 4 (Unknown model) (2315 MHz)",1, "Intel Pentium 4 (Unknown model) (3346 MHz)",1, "AMD (Unknown model) (1562 MHz)",1, "AMD K7 (Unknown model) (1974 MHz)",1, "AMD (Unknown model) (1635 MHz)",1, "AMD (Unknown model) (1583 MHz)",1, "Intel Pentium 4 (Unknown model) (3096 MHz)",1, "AMD (Unknown model) (2863 MHz)",1, "Intel Pentium 4 Northwood Xeon (2672 MHz)",1, "AMD (Unknown model) (1496 MHz)",1, "AMD (Unknown model) (1470 MHz)",1, "AMD K7 (Unknown model) (1846 MHz)",1, "AMD (Unknown model) (1629 MHz)",1, "AMD (Unknown model) (1488 MHz)",1, "AMD (Unknown model) (1077 MHz)",1, "Intel Pentium Pro (Unknown model) (718 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1092 MHz)",1, "AMD (Unknown model) (1116 MHz)",1, "Intel Pentium 4 (Unknown model) (2746 MHz)",1, "AMD (Unknown model) (1076 MHz)",1, "AMD (Unknown model) (976 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (656 MHz)",1, "Intel Pentium Pro (Unknown model) (975 MHz)",1, "AMD (Unknown model) (1132 MHz)",1, "Intel Pentium Pro (Unknown model) (2496 MHz)",1, "AMD (Unknown model) (1086 MHz)",1, "AMD (Unknown model) (1173 MHz)",1, "AMD (Unknown model) (1178 MHz)",1, "AMD (Unknown model) (1209 MHz)",1, "Intel Pentium 4 Willamette Xeon (1750 MHz)",1, "AMD K7 (Unknown model) (1867 MHz)",1, "AMD (Unknown model) (1471 MHz)",1, "AMD (Unknown model) (1151 MHz)",1, "Intel Pentium 4 (Unknown model) (2564 MHz)",1, "AMD (Unknown model) (1159 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (650 MHz)",1, "AMD (Unknown model) (1199 MHz)",1, "AMD (Unknown model) (1202 MHz)",1, "AMD (Unknown model) (2560 MHz)",1, "Intel Pentium 4 (Unknown model) (3784 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1496 MHz)",1, "AMD K7 (Unknown model) (1495 MHz)",1, "AMD K7 (Unknown model) (2316 MHz)",1, "AMD (Unknown model) (2559 MHz)",1, "Intel Pentium Pro (Unknown model) (1022 MHz)",1, "Intel Pentium 4 (Unknown model) (2591 MHz)",1, "AMD (Unknown model) (2770 MHz)",1, "Intel Pentium 4 Northwood (1874 MHz)",1, "AMD (Unknown model) (2571 MHz)",1, "AMD (Unknown model) (2572 MHz)",1, "AMD (Unknown model) (1135 MHz)",1, "AMD (Unknown model) (1235 MHz)",1, "AMD (Unknown model) (1236 MHz)",1, "AMD (Unknown model) (1238 MHz)",1, "AMD (Unknown model) (1304 MHz)",1, "AMD (Unknown model) (1287 MHz)",1, "Intel Pentium 4 (Unknown model) (8336 MHz)",1, "AMD (Unknown model) (1044 MHz)",1, "AMD (Unknown model) (1046 MHz)",1, "AMD (Unknown model) (1034 MHz)",1, "AMD (Unknown model) (1291 MHz)",1, "AMD (Unknown model) (1244 MHz)",1, "AMD (Unknown model) (1252 MHz)",1, "AMD (Unknown model) (1203 MHz)",1, "AMD (Unknown model) (2818 MHz)",1, "Intel Pentium 4 Northwood (3030 MHz)",1, "Intel Pentium 4 Northwood (2763 MHz)",1, "Intel Pentium 4 (Unknown model) (3576 MHz)",1, "AMD (Unknown model) (905 MHz)",1, "AMD (Unknown model) (1274 MHz)",1, "AMD K7 (Unknown model) (1434 MHz)",1, "AMD (Unknown model) (1301 MHz)",1, "AMD (Unknown model) (1281 MHz)",1, "AMD (Unknown model) (1267 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (732 MHz)",1, "AMD (Unknown model) (1475 MHz)",1, "AMD K7 (Unknown model) (692 MHz)",1, "AMD K7 (Unknown model) (1717 MHz)",1, "AMD K7 (Unknown model) (1780 MHz)",1, "AMD K7 (Unknown model) (1774 MHz)",1, "Intel Pentium 4 Northwood Xeon (2333 MHz)",1, "Intel Pentium 4 Northwood (1608 MHz)",1, "Intel Pentium 4 (Unknown model) (2282 MHz)",1, "AMD K7 (Unknown model) (1581 MHz)",1, "AMD K7 (Unknown model) (1584 MHz)",1, "Intel Pentium 4 Northwood (2873 MHz)",1, "Intel Pentium 4 (Unknown model) (4357 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (399 MHz)",1, "AMD (Unknown model) (1405 MHz)",1, "AMD (Unknown model) (1392 MHz)",1, "Intel Pentium Pro (Unknown model) (3055 MHz)",1, "Intel Pentium 4 (Unknown model) (3130 MHz)",1, "AMD (Unknown model) (2735 MHz)",1, "AMD (Unknown model) (1404 MHz)",1, "AMD (Unknown model) (1409 MHz)",1, "AMD (Unknown model) (1725 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (763 MHz)",1, "AMD (Unknown model) (1393 MHz)",1, "Intel Pentium 4 (Unknown model) (2769 MHz)",1, "AMD (Unknown model) (1463 MHz)",1, "Intel Pentium Pro (Unknown model) (740 MHz)",1, "AMD (Unknown model) (1195 MHz)",1, "AMD K7 (Unknown model) (1843 MHz)",1, "AMD K7 (Unknown model) (1850 MHz)",1, "Intel Pentium 4 Northwood (2089 MHz)",1, "AMD K7 (Unknown model) (1810 MHz)",1, "AMD (Unknown model) (2281 MHz)",1, "AMD Athlon (Thunderbird core) (718 MHz)",1, "AMD K7 (Unknown model) (1210 MHz)",1, "AMD K7 (Unknown model) (1246 MHz)",1, "Intel Pentium 4 (Unknown model) (4285 MHz)",1, "AMD K7 (Unknown model) (1212 MHz)",1, "AMD K7 (Unknown model) (1237 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1338 MHz)",1, "AMD K7 (Unknown model) (1947 MHz)",1, "AMD K7 (Unknown model) (1901 MHz)",1, "AMD K7 (Unknown model) (1285 MHz)",1, "AMD K7 (Unknown model) (1351 MHz)",1, "Intel Pentium 4 (Unknown model) (4412 MHz)",1, "Intel Pentium 4 (Unknown model) (2880 MHz)",1, "Intel Pentium Pro (Unknown model) (430 MHz)",1, "AMD K7 (Unknown model) (2262 MHz)",1, "PowerPC 7450 (1833 MHz)",1, "AMD K7 (Unknown model) (1983 MHz)",1, "Intel Pentium 4 (Unknown model) (2871 MHz)",1, "Intel Pentium Pro (Unknown model) (2288 MHz)",1, "AMD Mobile Duron (Morgan core) (1040 MHz)",1, "AMD (Unknown model) (2382 MHz)",1, "AMD (Unknown model) (1652 MHz)",1, "AMD (Unknown model) (1658 MHz)",1, "AMD (Unknown model) (1659 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (595 MHz)",1, "AMD (Unknown model) (1361 MHz)",1, "Intel Pentium 4 Northwood (1273 MHz)",1, "Intel Pentium 4 (Unknown model) (3603 MHz)",1, "Intel Pentium 4 (Unknown model) (2401 MHz)",1, "AMD (Unknown model) (1662 MHz)",1, "AMD (Unknown model) (1630 MHz)",1, "AMD (Unknown model) (1508 MHz)",1, "Intel Pentium 4 (Unknown model) (2241 MHz)",1, "Intel Pentium 4 Northwood Xeon (1432 MHz)",1, "AMD (Unknown model) (1516 MHz)",1, "AMD (Unknown model) (1525 MHz)",1, "AMD (Unknown model) (1749 MHz)",1, "AMD (Unknown model) (1726 MHz)",1, "Intel Pentium Pro (Unknown model) (241 MHz)",1, "AMD (Unknown model) (1722 MHz)",1, "AMD (Unknown model) (1410 MHz)",1, "AMD K7 (Unknown model) (1688 MHz)",1, "AMD (Unknown model) (1349 MHz)",1, "AMD (Unknown model) (1320 MHz)",1, "AMD (Unknown model) (1444 MHz)",1, "AMD (Unknown model) (1447 MHz)",1, "AMD (Unknown model) (1325 MHz)",1, "AMD (Unknown model) (1339 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (457 MHz)",1, "Intel Pentium 4 (Unknown model) (2828 MHz)",1, "AMD (Unknown model) (1683 MHz)",1, "AMD (Unknown model) (1457 MHz)",1, "AMD (Unknown model) (1436 MHz)",1, "AMD (Unknown model) (1433 MHz)",1, "AMD (Unknown model) (1443 MHz)",1, "AMD (Unknown model) (1373 MHz)",1, "Intel Pentium Pro (Unknown model) (2905 MHz)",1, "AMD (Unknown model) (1379 MHz)",1, "AMD (Unknown model) (1385 MHz)",1, "AMD Mobile Duron (Morgan core) (1351 MHz)",1, "AMD (Unknown model) (1121 MHz)",1, "Intel Pentium 4 (Unknown model) (3298 MHz)",1, "AMD (Unknown model) (1305 MHz)",1, "Intel Pentium 4 (Unknown model) (3475 MHz)",1, "AMD (Unknown model) (1309 MHz)",1, "AMD (Unknown model) (1317 MHz)",1, "AMD (Unknown model) (1306 MHz)",1, "Intel Pentium 4 Willamette (1616 MHz)",1, "Intel Pentium 4 Northwood Xeon (2860 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1716 MHz)",1, "Intel Pentium 4 (Unknown model) (3825 MHz)",1, "Intel Pentium 4 Northwood Xeon (2897 MHz)",1, "Intel Pentium 4 Northwood Xeon (2995 MHz)",1, "Intel Pentium 4 Northwood Xeon (1921 MHz)",1, "AMD (Unknown model) (2236 MHz)",1, "AMD (Unknown model) (2241 MHz)",1, "AMD (Unknown model) (2245 MHz)",1, "Intel Pentium Pro (Unknown model) (247 MHz)",1, "AMD (Unknown model) (2182 MHz)",1, "Intel Pentium Pro (Unknown model) (2883 MHz)",1, "Intel Pentium 4 Northwood Xeon (2939 MHz)",1, "Intel Pentium 4 Northwood Xeon (2965 MHz)",1, "Intel Pentium 4 Northwood Xeon (2930 MHz)",1, "Intel Pentium 4 Northwood Xeon (1830 MHz)",1, "AMD (Unknown model) (1514 MHz)",1, "Intel Pentium 4 (Unknown model) (3460 MHz)",1, "Intel Pentium Pro (Unknown model) (3508 MHz)",1, "Intel Pentium Pro (Unknown model) (645 MHz)",1, "i386 (Unknown) (3070 MHz)",1, "Intel Pentium 4 Northwood Xeon (3204 MHz)",1, "AMD (Unknown model) (1380 MHz)",1, "Intel Pentium 4 Northwood Xeon (2151 MHz)",1, "Intel Pentium 4 (Unknown model) (1565 MHz)",1, "AMD (Unknown model) (2373 MHz)",1, "Intel Pentium 4 Northwood (2741 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1004 MHz)",1, "Intel Pentium Pro (Unknown model) (2237 MHz)",1, "AMD K7 (Unknown model) (1736 MHz)",1, "AMD (Unknown model) (2335 MHz)",1, "AMD (Unknown model) (2286 MHz)",1, "AMD (Unknown model) (2125 MHz)",1, "Intel Pentium 4 Willamette Xeon (A-Step) (1288 MHz)",1, "AMD (Unknown model) (2356 MHz)",1, "Intel Pentium Pro (Unknown model) (1502 MHz)",1, "AMD (Unknown model) (2282 MHz)",1, "AMD (Unknown model) (2077 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1561 MHz)",1, "AMD (Unknown model) (2078 MHz)",1, "AMD Athlon (Thunderbird core) (824 MHz)",1, "Intel Pentium 4 Willamette Xeon (1596 MHz)",1, "AMD (Unknown model) (2073 MHz)",1, "Intel Pentium Pro (Unknown model) (1390 MHz)",1, "AMD (Unknown model) (1742 MHz)",1, "AMD (Unknown model) (2348 MHz)",1, "AMD (Unknown model) (1724 MHz)",1, "AMD (Unknown model) (2116 MHz)",1, "Intel Pentium Pro (Unknown model) (1748 MHz)",1, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process) (349 MHz)",1, "Intel Pentium 4 (Unknown model) (2878 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1398 MHz)",1, "Intel Pentium 4 Northwood (2372 MHz)",1, "Intel Pentium 4 Willamette (1786 MHz)",1, "Intel Pentium 4 (Unknown model) (3117 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1504 MHz)",1, "AMD (Unknown model) (1073 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1404 MHz)",1, "Intel Pentium 4 Willamette (2034 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1493 MHz)",1, "AMD (Unknown model) (2305 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (793 MHz)",1, "Intel Pentium 4 Willamette (1714 MHz)",1, "AMD (Unknown model) (1707 MHz)",1, "Intel Pentium 4 Willamette (1619 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (400 MHz)",1, "Intel Pentium 4 Willamette (1805 MHz)",1, "Intel Pentium 4 Northwood Xeon (874 MHz)",1, "Intel Pentium 4 Willamette (1388 MHz)",1, "Intel Pentium 4 Willamette (1591 MHz)",1, "AMD (Unknown model) (3079 MHz)",1, "Intel Pentium 4 Willamette (1488 MHz)",1, "Intel Pentium 4 (Unknown model) (3094 MHz)",1, "Intel Pentium 4 Northwood (1872 MHz)",1, "Intel Pentium 4 Northwood Xeon (2681 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (364 MHz)",1, "Intel Pentium Pro (Unknown model) (2052 MHz)",1, "Intel Pentium 4 Willamette Xeon (1705 MHz)",1, "Intel Pentium 4 Northwood Xeon (2199 MHz)",1, "Intel Pentium 4 Northwood Xeon (2249 MHz)",1, "Intel Pentium 4 Northwood Xeon (1745 MHz)",1, "Intel Pentium 4 (Unknown model) (6798 MHz)",1, "AMD (Unknown model) (1137 MHz)",1, "Intel Pentium Pro (Unknown model) (947 MHz)",1, "Intel Pentium Pro (Unknown model) (2259 MHz)",1, "Intel Pentium 4 Northwood Xeon (1707 MHz)",1, "Intel Pentium 4 Willamette (1815 MHz)",1, "Intel Pentium Pro (Unknown model) (1789 MHz)",1, "Intel Pentium 4 (Unknown model) (3354 MHz)",1, "Intel Pentium 4 Northwood (2715 MHz)",1, "AMD (Unknown model) (2645 MHz)",1, "Intel Pentium Pro (Unknown model) (669 MHz)",1, "Intel Pentium 4 Northwood Xeon (2299 MHz)",1, "Intel Pentium 4 Northwood Xeon (2329 MHz)",1, "Intel Pentium 4 Northwood (9455 MHz)",1, "AMD K7 (Unknown model) (2136 MHz)",1, "AMD (Unknown model) (1123 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (693 MHz)",1, "Intel Pentium 4 Willamette (1583 MHz)",1, "AMD Mobile Duron (Morgan core) (1101 MHz)",1, "Intel Pentium Pro (Unknown model) (588 MHz)",1, "Intel Pentium 4 (Unknown model) (3715 MHz)",1, "Intel Pentium 4 Northwood (2779 MHz)",1, "AMD (Unknown model) (2987 MHz)",1, "AMD (Unknown model) (2898 MHz)",1, "Intel Pentium 4 (Unknown model) (3342 MHz)",1, "AMD (Unknown model) (2840 MHz)",1, "AMD (Unknown model) (1531 MHz)",1, "AMD Athlon (Thunderbird core) (354 MHz)",1, "AMD (Unknown model) (2717 MHz)",1, "Intel Pentium Pro (Unknown model) (257 MHz)",1, "Intel Pentium Pro (Unknown model) (1927 MHz)",1, "AMD (Unknown model) (2710 MHz)",1, "AMD (Unknown model) (2892 MHz)",1, "AMD (Unknown model) (2658 MHz)",1, "AMD (Unknown model) (2663 MHz)",1, "AMD (Unknown model) (2723 MHz)",1, "AMD (Unknown model) (1237 MHz)",1, "AMD (Unknown model) (2875 MHz)",1, "AMD (Unknown model) (2888 MHz)",1, "Intel Pentium 4 Northwood (2103 MHz)",1, "AMD (Unknown model) (2893 MHz)",1, "AMD (Unknown model) (2897 MHz)",1, "AMD (Unknown model) (2816 MHz)",1, "AMD Duron (Spitfire core) (897 MHz)",1, "Intel Pentium 4 (Unknown model) (3767 MHz)",1, "Intel Pentium Pro (Unknown model) (2809 MHz)",1, "Intel Pentium 4 (Unknown model) (3783 MHz)",1, "AMD (Unknown model) (2395 MHz)",1, "Intel Pentium 4 (Unknown model) (2205 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1209 MHz)",1, "AMD (Unknown model) (2583 MHz)",1, "AMD (Unknown model) (2641 MHz)",1, "AMD (Unknown model) (2467 MHz)",1, "Intel Pentium Pro (Unknown model) (1928 MHz)",1, "AMD (Unknown model) (2594 MHz)",1, "AMD K7 (Unknown model) (1289 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (909 MHz)",1, "AMD (Unknown model) (2544 MHz)",1, "AMD (Unknown model) (2517 MHz)",1, "Intel Pentium 4 Northwood Xeon (3079 MHz)",1, "AMD (Unknown model) (2522 MHz)",1, "AMD K7 (Unknown model) (1773 MHz)",1, "AMD (Unknown model) (1096 MHz)",1, "Intel Pentium Pro (Unknown model) (558 MHz)",1, "AMD (Unknown model) (2545 MHz)",1, "AMD (Unknown model) (2548 MHz)",1, "AMD (Unknown model) (2532 MHz)",1, "Intel Pentium Pro (Unknown model) (2643 MHz)",1, "Intel Pentium 4 (Unknown model) (4250 MHz)",1, "AMD (Unknown model) (1764 MHz)",1, "AMD (Unknown model) (1880 MHz)",1, "AMD (Unknown model) (1766 MHz)",1, "AMD (Unknown model) (1767 MHz)",1, "Intel Pentium 4 (Unknown model) (3795 MHz)",1, "Intel Pentium 4 (Unknown model) (3526 MHz)",1, "Intel Pentium 4 (Unknown model) (2293 MHz)",1, "Intel Pentium Pro (Unknown model) (2290 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (897 MHz)",1, "AMD (Unknown model) (1884 MHz)",1, "Intel Pentium 4 Northwood (1198 MHz)",1, "AMD K7 (Unknown model) (1297 MHz)",1, "AMD (Unknown model) (2306 MHz)",1, "Intel Pentium 4 (Unknown model) (3630 MHz)",1, "AMD (Unknown model) (2243 MHz)",1, "Intel Pentium 4 (Unknown model) (3629 MHz)",1, "Intel Pentium 4 Northwood Xeon (2956 MHz)",1, "Intel Pentium 4 (Unknown model) (3622 MHz)",1, "AMD (Unknown model) (1905 MHz)",1, "Intel Pentium 4 (Unknown model) (1907 MHz)",1, "AMD (Unknown model) (1166 MHz)",1, "AMD K7 (Unknown model) (4682 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (680 MHz)",1, "AMD (Unknown model) (2745 MHz)",1, "Intel Pentium 4 Northwood (2439 MHz)",1, "AMD (Unknown model) (2784 MHz)",1, "Intel Pentium Pro (Unknown model) (2332 MHz)",1, "AMD Duron (Spitfire core) (862 MHz)",1, "Intel Pentium Pro (Unknown model) (3111 MHz)",1, "Intel Pentium Pro (Unknown model) (2094 MHz)",1, "Intel Pentium 4 (Unknown model) (3760 MHz)",1, "Intel Pentium 4 (Unknown model) (3546 MHz)",1, "AMD (Unknown model) (2788 MHz)",1, "Intel Pentium 4 Northwood (2635 MHz)",1, "Intel Pentium Pro (Unknown model) (3472 MHz)",1, "AMD (Unknown model) (2307 MHz)",1, "AMD (Unknown model) (2027 MHz)",1, "PowerPC 7450 (1467 MHz)",1, "Intel Pentium Pro (Unknown model) (2466 MHz)",1, "AMD (Unknown model) (1975 MHz)",1, "AMD Duron (Spitfire core) (651 MHz)",1, "Intel Pentium 4 (Unknown model) (2503 MHz)",1, "Intel Pentium 4 (Unknown model) (3922 MHz)",1, "AMD (Unknown model) (1927 MHz)",1, "Intel Pentium 4 Northwood (2502 MHz)",1, "AMD (Unknown model) (1933 MHz)",1, "AMD (Unknown model) (1369 MHz)",1, "AMD (Unknown model) (938 MHz)",1, "Intel Pentium 4 (Unknown model) (4409 MHz)",1, "Intel Pentium 4 Northwood (2723 MHz)",1, "AMD Mobile Duron (Morgan core) (1140 MHz)",1, "AMD K7 (Unknown model) (1613 MHz)",1, "Intel Pentium Pro (Unknown model) (2552 MHz)",1, "AMD K7 (Unknown model) (2057 MHz)",1, "AMD (Unknown model) (2755 MHz)",1, "AMD K7 (Unknown model) (2355 MHz)",1, "Intel Pentium Pro (Unknown model) (626 MHz)",1, "AMD (Unknown model) (2323 MHz)",1, "AMD (Unknown model) (1114 MHz)",1, "AMD K7 (Unknown model) (1124 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (652 MHz)",1, "AMD K7 (Unknown model) (2011 MHz)",1, "AMD (Unknown model) (1550 MHz)",1, "AMD (Unknown model) (965 MHz)",1, "AMD K7 (Unknown model) (2250 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1309 MHz)",1, "Intel Pentium Pro (Unknown model) (1757 MHz)",1, "Intel Pentium Pro (Unknown model) (3062 MHz)",1, "Intel Pentium Pro (Unknown model) (1175 MHz)",1, "Intel Pentium 4 Northwood (3230 MHz)",1, "AMD Athlon (0.25 micron) (500 MHz)",1, "Intel Pentium Pro (Unknown model) (1344 MHz)",1, "AMD K7 (Unknown model) (1166 MHz)",1, "Intel Pentium 4 Northwood (1416 MHz)",1, "AMD K7 (Unknown model) (1187 MHz)",1, "AMD Athlon (0.18 micron) (1000 MHz)",1, "Intel Pentium 4 (Unknown model) (3255 MHz)",1, "Intel Pentium Pro (Unknown model) (2416 MHz)",1, "Intel Pentium 4 (Unknown model) (1607 MHz)",1, "Intel Pentium Pro (Unknown model) (2184 MHz)",1, "Intel Pentium Pro (Unknown model) (2452 MHz)",1, "Intel Pentium 4 (Unknown model) (3854 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1714 MHz)",1, "AMD K7 (Unknown model) (2182 MHz)",1, "Intel Pentium Pro (Unknown model) (2567 MHz)",1, "Intel Pentium Pro (Unknown model) (245 MHz)",1, "Intel Pentium 4 Northwood Xeon (2663 MHz)",1, "Intel Pentium 4 Northwood (2110 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1260 MHz)",1, "Intel Pentium 4 Willamette (1511 MHz)",1, "Intel Pentium 4 Willamette Xeon (1701 MHz)",1, "Intel Pentium Pro (Unknown model) (2478 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (601 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1424 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (550 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (933 MHz)",1, "AMD Athlon (Thunderbird core) (1218 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1008 MHz)",1, "Intel Pentium 4 (Unknown model) (4862 MHz)",1, "Intel Pentium 4 (Unknown model) (3070 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1608 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (618 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1096 MHz)",1, "Intel Pentium 4 Northwood (3053 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1773 MHz)",1, "Intel Pentium 4 Northwood (1811 MHz)",1, "Intel Pentium 4 (Unknown model) (2902 MHz)",1, "Intel Pentium 4 (Unknown model) (3620 MHz)",1, "Intel Pentium 4 (Unknown model) (3179 MHz)",1, "Intel Pentium 4 Northwood (2063 MHz)",1, "Intel Pentium Pro (Unknown model) (2107 MHz)",1, "Intel Pentium 4 (Unknown model) (1990 MHz)",1, "Intel Pentium 4 (Unknown model) (2336 MHz)",1, "AMD (Unknown model) (3037 MHz)",1, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1333 MHz)",1, "Intel Pentium 4 Northwood Xeon (1751 MHz)",1, "AMD Athlon (Thunderbird core) (704 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (533 MHz)",1, "AMD (Unknown model) (3005 MHz)",1, "Intel Pentium 4 Northwood (3204 MHz)",1, "AMD K7 (Unknown model) (734 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1339 MHz)",1, "Intel Pentium Pro (Unknown model) (2808 MHz)",1, "Intel Pentium 4 (Unknown model) (4038 MHz)",1, "Intel Pentium Pro (Unknown model) (2943 MHz)",1, "Intel Pentium 4 (Unknown model) (3226 MHz)",1, "Intel Pentium Pro (Unknown model) (1916 MHz)",1, "Intel Pentium Pro (Unknown model) (3338 MHz)",1, "Intel Pentium 4 Northwood (2303 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (540 MHz)",1, "Intel Pentium 4 Northwood (2948 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1511 MHz)",1, "AMD K7 (Unknown model) (694 MHz)",1, "Intel Pentium Pro (Unknown model) (2014 MHz)",1, "Intel Pentium 4 Northwood (3482 MHz)",1, "Intel Pentium 4 Northwood (1299 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1027 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1338 MHz)",1, "AMD K7 (Unknown model) (949 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1246 MHz)",1, "AMD K7 (Unknown model) (1685 MHz)",1, "Intel Pentium 4 Willamette (2013 MHz)",1, "Intel Pentium 4 (Unknown model) (2417 MHz)",1, "Intel Pentium 4 Northwood (2528 MHz)",1, "Intel Pentium Pro (Unknown model) (2994 MHz)",1, "Intel Pentium 4 (Unknown model) (2724 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1066 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (1101 MHz)",1, "AMD K7 (Unknown model) (2050 MHz)",1, "AMD (Unknown model) (2872 MHz)",1, "Intel Pentium 4 (Unknown model) (3128 MHz)",1, "PowerMac (1333.333000MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1374 MHz)",1, "Intel Pentium 4 (Unknown model) (3452 MHz)",1, "Intel Pentium Pro (Unknown model) (2413 MHz)",1, "Intel Pentium 4 Northwood Xeon (3198 MHz)",1, "AMD (Unknown model) (1008 MHz)",1, "Intel Pentium 4 Northwood (3077 MHz)",1, "Intel Pentium 4 (Unknown model) (3595 MHz)",1, "Intel Pentium 4 (Unknown model) (2703 MHz)",1, "Intel Pentium 4 (Unknown model) (3281 MHz)",1, "Intel Pentium 4 (Unknown model) (2559 MHz)",1, "Intel Pentium 4 Willamette (1349 MHz)",1, "Unknown (1448 MHz)",1, "Intel Pentium 4 Northwood (3382 MHz)",1, "Intel Pentium 4 (Unknown model) (3568 MHz)",1, "AMD K7 (Unknown model) (1635 MHz)",1, "AMD K7 (Unknown model) (2018 MHz)",1, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1272 MHz)",1, "Intel Pentium 4 (Unknown model) (3351 MHz)",1, "Intel Pentium Pro (Unknown model) (3220 MHz)",1, "AMD (Unknown model) (3010 MHz)",1, "AMD Duron (Spitfire core) (978 MHz)",1, "Intel(R) Pentium(R) M processor 1.73GHz",1, "Intel Celeron (0.18 micron process) with internal L2 cache (951 MHz)",1, "Intel Pentium Pro (Unknown model) (3290 MHz)",1, "Intel Pentium 4 (Unknown model) (2436 MHz)",1, "Intel Pentium 4 (Unknown model) (4381 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (597 MHz)",1, "Intel Pentium 4 (Unknown model) (4437 MHz)",1, "AMD K7 (Unknown model) (1066 MHz)",1, "Intel Pentium Pro (Unknown model) (2414 MHz)",1, "Intel Pentium 4 Northwood (2464 MHz)",1, "AMD (Unknown model) (2138 MHz)",1, "AMD (Unknown model) (2590 MHz)",1, "Intel Pentium Pro (Unknown model) (3140 MHz)",1, "AMD (Unknown model) (824 MHz)",1, "Intel Pentium Pro (Unknown model) (2169 MHz)",1, "AMD Mobile Duron (Morgan core) (1309 MHz)",1, "Intel Pentium 4 Northwood (2984 MHz)",1, "AMD K7 (Unknown model) (1643 MHz)",1, "Intel Pentium 4 Northwood (3247 MHz)",1, "Intel Pentium 4 Northwood (2154 MHz)",1, "Intel Pentium 4 Willamette Xeon (1734 MHz)",1, "Intel Pentium Pro (Unknown model) (534 MHz)",1, "Intel Pentium Pro (Unknown model) (806 MHz)",1, "Intel Pentium Pro (Unknown model) (1915 MHz)",1, "Intel Pentium 4 Willamette (1604 MHz)",1, "Intel Pentium Pro (Unknown model) (2117 MHz)",1, "AMD (Unknown model) (2843 MHz)",1, "Intel Pentium 4 (Unknown model) (3749 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (905 MHz)",1, "Intel Pentium Pro (Unknown model) (710 MHz)",1, "AMD (Unknown model) (2913 MHz)",1, "AMD (Unknown model) (1311 MHz)",1, "AMD (Unknown model) (2492 MHz)",1, "Intel Pentium Pro (Unknown model) (1983 MHz)",1, "AMD Athlon (Thunderbird core) (910 MHz)",1, "Intel Pentium 4 (Unknown model) (2305 MHz)",1, "Intel Pentium Pro (Unknown model) (2759 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1502 MHz)",1, "Intel Pentium 4 (Unknown model) (5158 MHz)",1, "AMD Mobile Duron (Morgan core) (1172 MHz)",1, "Intel Pentium 4 Northwood (3031 MHz)",1, "PowerPC 7450 (735 MHz)",1, "Intel Pentium Pro (Unknown model) (3436 MHz)",1, "Intel Pentium 4 (Unknown model) (2727 MHz)",1, "Intel Pentium 4 Northwood (1853 MHz)",1, "Intel Pentium Pro (Unknown model) (2308 MHz)",1, "AMD (Unknown model) (2737 MHz)",1, "Intel Pentium 4 (Unknown model) (3365 MHz)",1, "Intel Pentium 4 (Unknown model) (2774 MHz)",1, "AMD Athlon (Thunderbird core) (1201 MHz)",1, "Intel Pentium 4 Northwood (2451 MHz)",1, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (634 MHz)",1, "Dual PowerPC 7450 (1253 MHz)",1, "Intel Pentium 4 Northwood (2056 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (728 MHz)",1, "Intel Pentium 4 Northwood (1731 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (1071 MHz)",1, "AMD (Unknown model) (1293 MHz)",1, "Intel Pentium 4 Northwood Xeon (1500 MHz)",1, "Intel Pentium Pro (Unknown model) (2428 MHz)",1, "AMD (Unknown model) (2101 MHz)",1, "Intel Pentium 4 (Unknown model) (3233 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (630 MHz)",1, "Intel(R) Pentium(R) 4 CPU 2.53GHz",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1500 MHz)",1, "AMD (Unknown model) (1961 MHz)",1, "Intel Pentium 4 Northwood (2954 MHz)",1, "Intel Pentium 4 (Unknown model) (2468 MHz)",1, "Intel Pentium 4 (Unknown model) (2901 MHz)",1, "AMD K7 (Unknown model) (1819 MHz)",1, "AMD K7 (Unknown model) (1941 MHz)",1, "Intel Pentium Pro (Unknown model) (222 MHz)",1, "Intel Pentium 4 (Unknown model) (3230 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1299 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1098 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (334 MHz)",1, "AMD K7 (Unknown model) (1490 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (566 MHz)",1, "Intel Pentium Pro (Unknown model) (2555 MHz)",1, "Intel Pentium Pro (Unknown model) (640 MHz)",1, "AMD (Unknown model) (2117 MHz)",1, "Intel Pentium Pro (Unknown model) (3038 MHz)",1, "AMD (Unknown model) (2516 MHz)",1, "AMD (Unknown model) (2227 MHz)",1, "Intel Pentium Pro (Unknown model) (2114 MHz)",1, "Intel Pentium 4 (Unknown model) (8060 MHz)",1, "AMD (Unknown model) (1079 MHz)",1, "Intel Pentium Pro (Unknown model) (2390 MHz)",1, "AMD (Unknown model) (1362 MHz)",1, "AMD K7 (Unknown model) (1775 MHz)",1, "AMD (Unknown model) (948 MHz)",1, "Intel Pentium 4 (Unknown model) (1402 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (665 MHz)",1, "Intel Pentium 4 (Unknown model) (2960 MHz)",1, "Intel Pentium 4 Northwood Xeon (1571 MHz)",1, "AMD Athlon (Thunderbird core) (849 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1689 MHz)",1, "AMD (Unknown model) (3159 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (757 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (545 MHz)",1, "Intel Pentium Pro (Unknown model) (1756 MHz)",1, "Intel Pentium Pro (Unknown model) (2345 MHz)",1, "AMD (Unknown model) (3899 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (806 MHz)",1, "Intel Pentium Pro (Unknown model) (2453 MHz)",1, "AMD (Unknown model) (2622 MHz)",1, "AMD (Unknown model) (287 MHz)",1, "Intel Pentium 4 Northwood (2629 MHz)",1, "Dual i386 (Unknown) (2810 MHz)",1, "Intel Pentium 4 (Unknown model) (2752 MHz)",1, "Intel Pentium 4 Northwood Xeon (2787 MHz)",1, "Intel Pentium 4 Willamette Xeon (1982 MHz)",1, "Intel Pentium Pro (Unknown model) (2756 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (903 MHz)",1, "AMD (Unknown model) (1190 MHz)",1, "Intel Pentium 4 (Unknown model) (2863 MHz)",1, "Intel Pentium 4 (Unknown model) (2981 MHz)",1, "AMD (Unknown model) (1481 MHz)",1, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1130 MHz)",1, "AMD K7 (Unknown model) (1489 MHz)",1, "AMD (Unknown model) (1734 MHz)",1, "Intel Pentium Pro (Unknown model) (2892 MHz)",1, "Intel Pentium Pro (Unknown model) (3147 MHz)",1, "Unknown (598 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (836 MHz)",1, "Intel Pentium II with internal L2 cache (453 MHz)",1, "Intel Pentium 4 Northwood (2702 MHz)",1, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1273 MHz)",1, "Intel Pentium 4 Northwood (2007 MHz)",1, "Intel Pentium 4 Northwood Xeon (2826 MHz)",1, "Intel Pentium 4 (Unknown model) (2508 MHz)",1, "AMD Athlon (Thunderbird core) (1024 MHz)",1, "Dual i386 (Unknown) (2670 MHz)",1, "AMD (Unknown model) (1261 MHz)",1, "Intel Pentium Pro (Unknown model) (3555 MHz)",1, "Intel Pentium Pro (Unknown model) (1768 MHz)",1, "Intel Pentium 4 Northwood (3323 MHz)",1, "Intel Pentium Pro (Unknown model) (2125 MHz)",1, "Intel Pentium Pro (Unknown model) (2309 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (752 MHz)",1, "Intel Pentium Pro (Unknown model) (3258 MHz)",1, "Intel Pentium 4 Northwood Xeon (2864 MHz)",1, "Intel Pentium 4 Northwood (2840 MHz)",1, "Intel Pentium Pro (Unknown model) (3431 MHz)",1, "Intel Pentium 4 Northwood Xeon (2253 MHz)",1, "Intel Pentium 4 Northwood Xeon (2562 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1414 MHz)",1, "Intel Pentium Pro (Unknown model) (2190 MHz)",1, "Intel Pentium 4 (Unknown model) (3621 MHz)",1, "AMD K7 (Unknown model) (1718 MHz)",1, "Intel Pentium 4 (Unknown model) (3671 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (997 MHz)",1, "AMD K7 (Unknown model) (1458 MHz)",1, "Intel Pentium 4 (Unknown model) (3084 MHz)",1, "Intel Pentium 4 (Unknown model) (3282 MHz)",1, "Intel Pentium 4 Northwood (3208 MHz)",1, "Intel Pentium 4 Northwood (3019 MHz)",1, "AMD Athlon (Thunderbird core) (733 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (850 MHz)",1, "Intel Pentium 4 Northwood (2650 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1005 MHz)",1, "Intel Pentium 4 Northwood Xeon (2908 MHz)",1, "Intel Pentium 4 Northwood (3125 MHz)",1, "Intel Pentium 4 (Unknown model) (2515 MHz)",1, "AMD Athlon (Thunderbird core) (1268 MHz)",1, "AMD (Unknown model) (3095 MHz)",1, "Intel Pentium Pro (Unknown model) (564 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (658 MHz)",1, "AMD K7 (Unknown model) (2329 MHz)",1, "AMD (Unknown model) (3959 MHz)",1, "Intel Pentium 4 (Unknown model) (4093 MHz)",1, "Intel Pentium 4 (Unknown model) (3336 MHz)",1, "Intel Pentium 4 (Unknown model) (3646 MHz)",1, "AMD Mobile Duron (Morgan core) (946 MHz)",1, "Intel Pentium Pro (Unknown model) (455 MHz)",1, "Intel Pentium 4 (Unknown model) (6888 MHz)",1, "Intel Pentium 4 Willamette (1878 MHz)",1, "Intel Pentium 4 Northwood (3254 MHz)",1, "Intel Pentium 4 (Unknown model) (3161 MHz)",1, "Intel Pentium 4 Northwood (2588 MHz)",1, "Intel Pentium Pro (Unknown model) (511 MHz)",1, "Intel Pentium Pro (Unknown model) (2324 MHz)",1, "Intel Pentium 4 (Unknown model) (2311 MHz)",1, "Intel Pentium Pro (Unknown model) (810 MHz)",1, "Intel Pentium 4 Willamette Xeon (A-Step) (1685 MHz)",1, "Intel Pentium 4 Northwood (2959 MHz)",1, "Intel Pentium Pro (Unknown model) (1891 MHz)",1, "Intel Pentium 4 Northwood (1986 MHz)",1, "Intel Pentium 4 Northwood (2728 MHz)",1, "Intel Pentium Pro (Unknown model) (629 MHz)",1, "Intel Pentium Pro (Unknown model) (3088 MHz)",1, "AMD Duron (Spitfire core) (754 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1511 MHz)",1, "Intel Pentium 4 (Unknown model) (2855 MHz)",1, "Intel Pentium 4 Northwood (724 MHz)",1, "Intel Pentium 4 Northwood (2773 MHz)",1, "Intel Pentium Pro (Unknown model) (2203 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1339 MHz)",1, "AMD K7 (Unknown model) (2351 MHz)",1, "AMD (Unknown model) (1217 MHz)",1, "AMD (Unknown model) (1257 MHz)",1, "Intel Pentium Pro (Unknown model) (3197 MHz)",1, "Unknown (534 MHz)",1, "Intel Pentium 4 Northwood (2521 MHz)",1, "Intel Pentium 4 Northwood (2638 MHz)",1, "Intel Pentium 4 Willamette (1819 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (699 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (791 MHz)",1, "Intel Pentium 4 (Unknown model) (1703 MHz)",1, "Intel Pentium Pro (Unknown model) (1251 MHz)",1, "AMD (Unknown model) (1499 MHz)",1, "Unknown (398 MHz)",1, "Intel Pentium 4 Northwood Xeon (2978 MHz)",1, "AMD (Unknown model) (2582 MHz)",1, "AMD (Unknown model) (1259 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (996 MHz)",1, "Intel Pentium 4 Northwood (2157 MHz)",1, "AMD (Unknown model) (690 MHz)",1, "Intel Pentium Pro (Unknown model) (2286 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (558 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1071 MHz)",1, "AMD Athlon (Thunderbird core) (1097 MHz)",1, "Intel Pentium 4 Northwood (3608 MHz)",1, "AMD Athlon (Thunderbird core) (1346 MHz)",1, "Intel Pentium Pro (Unknown model) (694 MHz)",1, "Intel Pentium Pro (Unknown model) (3212 MHz)",1, "AMD Duron (Spitfire core) (906 MHz)",1, "Intel Pentium 4 Northwood (2924 MHz)",1, "Intel Pentium 4 Willamette (1394 MHz)",1, "Intel Pentium 4 (Unknown model) (3478 MHz)",1, "Intel Pentium Pro (Unknown model) (365 MHz)",1, "AMD K7 (Unknown model) (1653 MHz)",1, "AMD (Unknown model) (1112 MHz)",1, "Intel Pentium 4 Northwood (2860 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (669 MHz)",1, "AMD (Unknown model) (2525 MHz)",1, "AMD (Unknown model) (2743 MHz)",1, "AMD (Unknown model) (1923 MHz)",1, "Intel Pentium 4 (Unknown model) (2246 MHz)",1, "Intel Pentium 4 Northwood (3240 MHz)",1, "Intel Pentium 4 Northwood (3519 MHz)",1, "Intel Pentium 4 Northwood (2217 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1631 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1330 MHz)",1, "Intel Pentium Pro (Unknown model) (2853 MHz)",1, "AMD Athlon (Thunderbird core) (1046 MHz)",1, "Intel Pentium 4 (Unknown model) (3876 MHz)",1, "AMD K7 (Unknown model) (1722 MHz)",1, "AMD Athlon (0.25 micron) (700 MHz)",1, "AMD Athlon (Thunderbird core) (1395 MHz)",1, "Intel Pentium 4 Northwood (1973 MHz)",1, "AMD (Unknown model) (1747 MHz)",1, "AMD (Unknown model) (2634 MHz)",1, "Intel Pentium 4 Northwood (2772 MHz)",1, "Intel Pentium 4 (Unknown model) (3265 MHz)",1, "Intel Pentium 4 Northwood (3004 MHz)",1, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1128 MHz)",1, "AMD K7 (Unknown model) (1849 MHz)",1, "AMD Mobile Duron (Morgan core) (1193 MHz)",1, "Intel Pentium Pro (Unknown model) (1093 MHz)",1, "AMD (Unknown model) (2056 MHz)",1, "Intel Pentium 4 Northwood Xeon (1442 MHz)",1, "Intel Pentium 4 Willamette (1682 MHz)",1, "AMD (Unknown model) (1539 MHz)",1, "Intel Pentium Pro (Unknown model) (1812 MHz)",1, "Intel Pentium 4 (Unknown model) (4411 MHz)",1, "Intel Pentium 4 (Unknown model) (5103 MHz)",1, "AMD (Unknown model) (1090 MHz)",1, "Intel Pentium Pro (Unknown model) (3474 MHz)",1, "AMD K7 (Unknown model) (2260 MHz)",1, "Dual PowerPC 7450 (1200 MHz)",1, "AMD K7 (Unknown model) (1897 MHz)",1, "Intel Pentium 4 Northwood Xeon (2388 MHz)",1, "AMD (Unknown model) (918 MHz)",1, "Intel Pentium Pro (Unknown model) (4050 MHz)",1, "AMD (Unknown model) (1352 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1650 MHz)",1, "Intel Pentium 4 Northwood (3535 MHz)",1, "Intel Pentium 4 Willamette (2133 MHz)",1, "AMD (Unknown model) (1700 MHz)",1, "Intel Pentium Pro (Unknown model) (3257 MHz)",1, "Intel Pentium 4 Northwood (2162 MHz)",1, "Intel Pentium 4 (Unknown model) (3153 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1625 MHz)",1, "AMD Athlon (Thunderbird core) (944 MHz)",1, "Intel Pentium 4 Northwood (3185 MHz)",1, "Intel Pentium 4 Willamette (1705 MHz)",1, "Intel Pentium 4 (Unknown model) (3242 MHz)",1, "Intel Pentium Pro (Unknown model) (383 MHz)",1, "Intel Pentium Pro (Unknown model) (2968 MHz)",1, "Intel Pentium 4 Northwood (1518 MHz)",1, "Intel Pentium Pro (Unknown model) (2927 MHz)",1, "AMD K7 (Unknown model) (1063 MHz)",1, "AMD (Unknown model) (1040 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1429 MHz)",1, "Intel Pentium 4 (Unknown model) (2554 MHz)",1, "AMD (Unknown model) (3196 MHz)",1, "Intel Pentium 4 (Unknown model) (3728 MHz)",1, "Intel Pentium Pro (Unknown model) (1341 MHz)",1, "Intel Pentium 4 (Unknown model) (4690 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (705 MHz)",1, "AMD K7 (Unknown model) (1714 MHz)",1, "AMD (Unknown model) (1491 MHz)",1, "Intel Pentium 4 (Unknown model) (3822 MHz)",1, "Intel Pentium Pro (Unknown model) (2325 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1386 MHz)",1, "Intel Pentium 4 Northwood Xeon (2807 MHz)",1, "AMD K7 (Unknown model) (1959 MHz)",1, "Intel Pentium 4 (Unknown model) (1867 MHz)",1, "Intel Pentium Pro (Unknown model) (512 MHz)",1, "AMD K7 (Unknown model) (1560 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (797 MHz)",1, "AMD (Unknown model) (1719 MHz)",1, "Intel Pentium 4 (Unknown model) (3561 MHz)",1, "AMD (Unknown model) (1286 MHz)",1, "Intel Pentium 4 (Unknown model) (3815 MHz)",1, "AMD (Unknown model) (1321 MHz)",1, "AMD (Unknown model) (2679 MHz)",1, "Intel Pentium 4 (Unknown model) (2243 MHz)",1, "AMD K7 (Unknown model) (1476 MHz)",1, "Intel Pentium 4 (Unknown model) (4280 MHz)",1, "AMD (Unknown model) (1426 MHz)",1, "AMD (Unknown model) (1528 MHz)",1, "Intel Pentium 4 (Unknown model) (3604 MHz)",1, "AMD (Unknown model) (1124 MHz)",1, "Intel Pentium 4 (Unknown model) (3327 MHz)",1, "AMD (Unknown model) (1711 MHz)",1, "Intel Pentium 4 Willamette (1784 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1020 MHz)",1, "AMD Athlon (0.18 micron) (791 MHz)",1, "AMD (Unknown model) (1353 MHz)",1, "Intel Pentium 4 Northwood Xeon (2440 MHz)",1, "AMD K7 (Unknown model) (1085 MHz)",1, "Intel Pentium 4 Northwood Xeon (1506 MHz)",1, "Intel Pentium Pro (Unknown model) (2628 MHz)",1, "Intel Pentium 4 Northwood (1295 MHz)",1, "Intel Pentium Pro (Unknown model) (447 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (999 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (773 MHz)",1, "Intel Pentium 4 Northwood (2420 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1755 MHz)",1, "Intel Pentium Pro (Unknown model) (2982 MHz)",1, "Intel Pentium Pro (Unknown model) (3222 MHz)",1, "AMD (Unknown model) (1383 MHz)",1, "AMD (Unknown model) (940 MHz)",1, "Intel Pentium Pro (Unknown model) (2947 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (793 MHz)",1, "AMD (Unknown model) (2686 MHz)",1, "Intel Pentium 4 Northwood (3531 MHz)",1, "AMD (Unknown model) (2830 MHz)",1, "AMD (Unknown model) (1776 MHz)",1, "AMD (Unknown model) (1963 MHz)",1, "Intel Pentium 4 Northwood (2262 MHz)",1, "AMD (Unknown model) (6467 MHz)",1, "AMD (Unknown model) (2915 MHz)",1, "AMD (Unknown model) (1708 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1127 MHz)",1, "AMD (Unknown model) (1572 MHz)",1, "Intel Pentium Pro (Unknown model) (493 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (807 MHz)",1, "AMD (Unknown model) (853 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (265 MHz)",1, "Intel Pentium 4 (Unknown model) (1909 MHz)",1, "Intel Pentium Pro (Unknown model) (680 MHz)",1, "AMD (Unknown model) (2647 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1097 MHz)",1, "Intel Pentium 4 (Unknown model) (5705 MHz)",1, "Intel Pentium 4 (Unknown model) (4410 MHz)",1, "Intel Pentium 4 Northwood Xeon (2900 MHz)",1, "Intel Pentium 4 Willamette (1896 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (557 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1365 MHz)",1, "Intel Pentium 4 Willamette Xeon (1685 MHz)",1, "AMD (Unknown model) (1037 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1431 MHz)",1, "AMD (Unknown model) (841 MHz)",1, "AMD K7 (Unknown model) (2126 MHz)",1, "Intel Pentium 4 (Unknown model) (3174 MHz)",1, "Intel Pentium 4 (Unknown model) (3182 MHz)",1, "Intel Pentium 4 Northwood (2731 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (531 MHz)",1, "Intel Pentium 4 Northwood (2870 MHz)",1, "Intel Pentium 4 (Unknown model) (2560 MHz)",1, "AMD (Unknown model) (1226 MHz)",1, "Intel Pentium 4 (Unknown model) (4042 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (792 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1557 MHz)",1, "AMD (Unknown model) (2139 MHz)",1, "Intel Pentium Pro (Unknown model) (1824 MHz)",1, "AMD (Unknown model) (1169 MHz)",1, "Intel Pentium 4 Northwood (3904 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (714 MHz)",1, "AMD K7 (Unknown model) (2390 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1609 MHz)",1, "AMD (Unknown model) (1045 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1147 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (534 MHz)",1, "Intel Pentium 4 (Unknown model) (1803 MHz)",1, "i386 (Unknown) (2520 MHz)",1, "Intel Pentium Pro (Unknown model) (2907 MHz)",1, "Intel Pentium 4 (Unknown model) (3686 MHz)",1, "AMD K7 (Unknown model) (1626 MHz)",1, "Intel Pentium 4 Northwood (3158 MHz)",1, "Intel Pentium Pro (Unknown model) (1115 MHz)",1, "AMD (Unknown model) (1006 MHz)",1, "Intel Pentium 4 Northwood (1610 MHz)",1, "Intel Pentium 4 (Unknown model) (3513 MHz)",1, "AMD K7 (Unknown model) (1769 MHz)",1, "Intel Pentium 4 (Unknown model) (3502 MHz)",1, "AMD (Unknown model) (2713 MHz)",1, "Intel Pentium 4 Willamette Xeon (1704 MHz)",1, "AMD Athlon (Thunderbird core) (1459 MHz)",1, "Intel Pentium Pro (Unknown model) (1506 MHz)",1, "Intel Pentium 4 (Unknown model) (3163 MHz)",1, "Intel Pentium Pro (Unknown model) (3151 MHz)",1, "AMD (Unknown model) (1020 MHz)",1, "AMD Duron (Spitfire core) (802 MHz)",1, "Intel Pentium Pro (Unknown model) (2105 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1799 MHz)",1, "AMD (Unknown model) (1120 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1424 MHz)",1, "Intel Pentium 4 (Unknown model) (2408 MHz)",1, "AMD K7 (Unknown model) (1554 MHz)",1, "AMD (Unknown model) (1347 MHz)",1, "AMD (Unknown model) (1247 MHz)",1, "AMD (Unknown model) (1640 MHz)",1, "Intel Pentium Pro (Unknown model) (2748 MHz)",1, "Intel Pentium 4 Northwood (1655 MHz)",1, "AMD K7 (Unknown model) (893 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1488 MHz)",1, "AMD (Unknown model) (886 MHz)",1, "Intel Pentium 4 (Unknown model) (3839 MHz)",1, "Intel Pentium II/Xeon/Celeron (Model 5 core, 0.25 micron process)",1, "Intel Pentium 4 Willamette (A-Step) (1360 MHz)",1, "AMD (Unknown model) (1705 MHz)",1, "Intel Pentium Pro (Unknown model) (2352 MHz)",1, "AMD (Unknown model) (1460 MHz)",1, "PowerPC 7450 (1867 MHz)",1, "Intel Pentium 4 Northwood Xeon (2969 MHz)",1, "Intel Pentium 4 Northwood (2847 MHz)",1, "Intel Pentium Pro (Unknown model) (2959 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (535 MHz)",1, "Intel Pentium Pro (Unknown model) (1889 MHz)",1, "Intel Pentium 4 (Unknown model) (4427 MHz)",1, "Intel Pentium 4 (Unknown model) (3446 MHz)",1, "Intel Pentium Pro (Unknown model) (2767 MHz)",1, "Intel Pentium Pro (Unknown model) (3042 MHz)",1, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (952 MHz)",1, "Intel Pentium 4 Northwood Xeon (2331 MHz)",1, "Intel Pentium 4 Northwood Xeon (2982 MHz)",1, "AMD K7 (Unknown model) (1865 MHz)",1, "Intel Pentium 4 Northwood (2955 MHz)",1, "AMD K7 (Unknown model) (2399 MHz)",1, "AMD (Unknown model) (1254 MHz)",1, "AMD Mobile Duron (Morgan core) (1319 MHz)",1, "AMD Mobile Duron (Morgan core) (1196 MHz)",1, "Intel Pentium Pro (Unknown model) (2687 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (901 MHz)",1, "AMD Athlon (Thunderbird core) (1006 MHz)",1, "Intel Pentium 4 Willamette (1980 MHz)",1, "Intel Pentium 4 Northwood (2956 MHz)",1, "AMD (Unknown model) (966 MHz)",1, "Intel Pentium 4 Northwood (2761 MHz)",1, "AMD (Unknown model) (2289 MHz)",1, "Intel Pentium 4 Northwood (2340 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (988 MHz)",1, "AMD Mobile Duron (Morgan core) (1224 MHz)",1, "Intel Pentium Pro (Unknown model) (2331 MHz)",1, "Intel Pentium 4 Northwood Xeon (1063 MHz)",1, "Intel Pentium Pro (Unknown model) (2897 MHz)",1, "Intel Pentium 4 (Unknown model) (8977 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (283 MHz)",1, "Intel Pentium 4 Northwood (3104 MHz)",1, "Intel Pentium 4 (Unknown model) (3552 MHz)",1, "Intel Pentium 4 (Unknown model) (3808 MHz)",1, "AMD K7 (Unknown model) (795 MHz)",1, "Intel Pentium 4 (Unknown model) (2693 MHz)",1, "AMD K7 (Unknown model) (497 MHz)",1, "AMD K7 (Unknown model) (2385 MHz)",1, "AMD Athlon (Thunderbird core) (1128 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (877 MHz)",1, "Intel Pentium Pro (Unknown model) (1740 MHz)",1, "Intel Pentium Pro (Unknown model) (1688 MHz)",1, "Intel Pentium 4 Northwood (3092 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1584 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1284 MHz)",1, "AMD (Unknown model) (2895 MHz)",1, "AMD (Unknown model) (2501 MHz)",1, "Intel Pentium Pro (Unknown model) (758 MHz)",1, "Intel Pentium Pro (Unknown model) (2527 MHz)",1, "Intel Pentium 4 Northwood (2370 MHz)",1, "Intel Pentium 4 Northwood (1210 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1302 MHz)",1, "PowerPC 7450 (350 MHz)",1, "Intel Pentium 4 Northwood (2714 MHz)",1, "AMD (Unknown model) (2899 MHz)",1, "Intel Pentium 4 Willamette (1469 MHz)",1, "Intel Pentium 4 (Unknown model) (3730 MHz)",1, "Intel Pentium 4 (Unknown model) (3295 MHz)",1, "Intel Pentium 4 Northwood Xeon (1399 MHz)",1, "AMD Athlon (Thunderbird core) (782 MHz)",1, "Intel Pentium Pro (Unknown model) (3405 MHz)",1, "Intel Pentium Pro (Unknown model) (2935 MHz)",1, "Intel Pentium 4 (Unknown model) (2100 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1104 MHz)",1, "AMD Duron (Spitfire core) (655 MHz)",1, "Intel Pentium 4 (Unknown model) (2971 MHz)",1, "Intel Pentium 4 Willamette (1485 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1609 MHz)",1, "AMD (Unknown model) (952 MHz)",1, "Intel Pentium 4 Northwood Xeon (3240 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (768 MHz)",1, "AMD (Unknown model) (1532 MHz)",1, "AMD (Unknown model) (1075 MHz)",1, "Intel Pentium Pro (Unknown model) (2285 MHz)",1, "Intel Pentium 4 Northwood (2609 MHz)",1, "Intel Pentium 4 Northwood Xeon (1428 MHz)",1, "Intel Pentium Pro (Unknown model) (2763 MHz)",1, "Intel Pentium Pro (Unknown model) (2019 MHz)",1, "AMD K7 (Unknown model) (2364 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1615 MHz)",1, "Intel Pentium Pro (Unknown model) (2967 MHz)",1, "Intel Pentium Pro (Unknown model) (3443 MHz)",1, "AMD (Unknown model) (1119 MHz)",1, "AMD (Unknown model) (2924 MHz)",1, "Intel Pentium Pro (Unknown model) (492 MHz)",1, "AMD Athlon (0.18 micron) (900 MHz)",1, "Intel Pentium Pro (Unknown model) (3336 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1158 MHz)",1, "Intel Pentium 4 (Unknown model) (3753 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1690 MHz)",1, "AMD (Unknown model) (1761 MHz)",1, "AMD (Unknown model) (2807 MHz)",1, "AMD (Unknown model) (1571 MHz)",1, "Intel Pentium Pro (Unknown model) (970 MHz)",1, "AMD (Unknown model) (872 MHz)",1, "AMD (Unknown model) (1625 MHz)",1, "AMD (Unknown model) (879 MHz)",1, "Intel Pentium Pro (Unknown model) (2696 MHz)",1, "Intel Pentium 4 (Unknown model) (3185 MHz)",1, "AMD (Unknown model) (1750 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (679 MHz)",1, "AMD K7 (Unknown model) (1957 MHz)",1, "Intel Pentium 4 Northwood (1412 MHz)",1, "AMD Athlon (Thunderbird core) (1303 MHz)",1, "Intel Pentium Pro (Unknown model) (3297 MHz)",1, "AMD (Unknown model) (1165 MHz)",1, "Intel Pentium 4 (Unknown model) (3707 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1738 MHz)",1, "Intel Pentium 4 Willamette Xeon (855 MHz)",1, "Intel Pentium 4 Northwood (1097 MHz)",1, "Intel Pentium Pro (Unknown model) (2733 MHz)",1, "Intel Pentium 4 Northwood Xeon (2735 MHz)",1, "AMD K7 (Unknown model) (1880 MHz)",1, "AMD K7 (Unknown model) (2240 MHz)",1, "Intel Pentium Pro (Unknown model) (2864 MHz)",1, "Intel Pentium 4 Northwood (2946 MHz)",1, "Intel Pentium 4 (Unknown model) (1895 MHz)",1, "AMD (Unknown model) (1715 MHz)",1, "Intel Pentium 4 (Unknown model) (2976 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1139 MHz)",1, "Intel Pentium 4 (Unknown model) (3311 MHz)",1, "Intel Pentium 4 Northwood (3428 MHz)",1, "Intel Pentium Pro (Unknown model) (1722 MHz)",1, "AMD (Unknown model) (2367 MHz)",1, "Intel Pentium Pro (Unknown model) (1248 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1751 MHz)",1, "Intel Pentium 4 Willamette Xeon (1869 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (896 MHz)",1, "Intel Pentium Pro (Unknown model) (2948 MHz)",1, "AMD K7 (Unknown model) (2384 MHz)",1, "Intel Pentium 4 Northwood Xeon (2932 MHz)",1, "Intel Pentium 4 (Unknown model) (2209 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1364 MHz)",1, "Intel Pentium 4 Northwood (3076 MHz)",1, "AMD (Unknown model) (1684 MHz)",1, "Intel Pentium 4 (Unknown model) (3981 MHz)",1, "Intel Pentium Pro (Unknown model) (878 MHz)",1, "AMD (Unknown model) (870 MHz)",1, "Intel Pentium Pro (Unknown model) (2175 MHz)",1, "AMD K7 (Unknown model) (1230 MHz)",1, "AMD (Unknown model) (1013 MHz)",1, "AMD K7 (Unknown model) (1968 MHz)",1, "Intel Pentium Pro (Unknown model) (1481 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (997 MHz)",1, "AMD (Unknown model) (1329 MHz)",1, "AMD K7 (Unknown model) (1125 MHz)",1, "Intel Pentium Pro (Unknown model) (3406 MHz)",1, "Intel Pentium 4 Northwood Xeon (2765 MHz)",1, "AMD (Unknown model) (1645 MHz)",1, "Intel Pentium Pro (Unknown model) (2350 MHz)",1, "AMD K7 (Unknown model) (1562 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (431 MHz)",1, "Intel Pentium 4 Northwood Xeon (1773 MHz)",1, "Intel Pentium 4 Northwood (2692 MHz)",1, "AMD (Unknown model) (2703 MHz)",1, "Intel Pentium 4 Northwood Xeon (1597 MHz)",1, "Intel Pentium II with internal L2 cache (498 MHz)",1, "Intel Pentium 4 Northwood (3641 MHz)",1, "Intel Pentium Pro (Unknown model) (3319 MHz)",1, "AMD Athlon (Thunderbird core) (749 MHz)",1, "AMD (Unknown model) (2969 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1034 MHz)",1, "Intel Pentium 4 (Unknown model) (2787 MHz)",1, "Intel Pentium 4 Willamette Xeon (A-Step) (1684 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1297 MHz)",1, "Intel Pentium 4 (Unknown model) (3366 MHz)",1, "AMD (Unknown model) (1146 MHz)",1, "AMD K7 (Unknown model) (1587 MHz)",1, "Intel Pentium 4 (Unknown model) (2416 MHz)",1, "AMD K7 (Unknown model) (2307 MHz)",1, "AMD (Unknown model) (2648 MHz)",1, "Intel Pentium 4 Northwood (3289 MHz)",1, "Intel Pentium 4 (Unknown model) (3694 MHz)",1, "Intel Pentium 4 Northwood (3146 MHz)",1, "Intel Pentium 4 Willamette (1613 MHz)",1, "AMD K7 (Unknown model) (2363 MHz)",1, "Intel Pentium Pro (Unknown model) (2434 MHz)",1, "AMD (Unknown model) (2226 MHz)",1, "AMD (Unknown model) (1272 MHz)",1, "Intel Pentium 4 (Unknown model) (1930 MHz)",1, "Intel Pentium 4 (Unknown model) (1994 MHz)",1, "Intel Pentium Pro (Unknown model) (1930 MHz)",1, "Intel Pentium 4 (Unknown model) (1944 MHz)",1, "Intel Pentium Pro (Unknown model) (2065 MHz)",1, "Intel Pentium 4 (Unknown model) (3636 MHz)",1, "Intel Pentium 4 (Unknown model) (3637 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (805 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (628 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1095 MHz)",1, "Intel Pentium 4 (Unknown model) (3821 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1364 MHz)",1, "AMD (Unknown model) (2688 MHz)",1, "Intel Pentium Pro (Unknown model) (2970 MHz)",1, "Intel Pentium 4 (Unknown model) (2329 MHz)",1, "Intel Pentium Pro (Unknown model) (1888 MHz)",1, "Intel Pentium Pro (Unknown model) (2801 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1403 MHz)",1, "AMD (Unknown model) (2698 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1413 MHz)",1, "Intel Pentium 4 Northwood (1894 MHz)",1, "Intel Pentium 4 Northwood (2284 MHz)",1, "Intel Pentium 4 (Unknown model) (4187 MHz)",1, "Intel Pentium 4 Northwood Xeon (3068 MHz)",1, "Intel Pentium Pro (Unknown model) (3442 MHz)",1, "PowerPC 7400 (398 MHz)",1, "AMD K7 (Unknown model) (1888 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (927 MHz)",1, "Intel Pentium 4 (Unknown model) (3380 MHz)",1, "Intel Pentium Pro (Unknown model) (2558 MHz)",1, "AMD Mobile Duron (Morgan core) (1089 MHz)",1, "Intel Pentium 4 (Unknown model) (3924 MHz)",1, "Intel Pentium 4 (Unknown model) (4077 MHz)",1, "Intel Pentium 4 (Unknown model) (3742 MHz)",1, "Intel Pentium 4 (Unknown model) (3899 MHz)",1, "Intel Pentium 4 Northwood (2857 MHz)",1, "Intel Pentium 4 (Unknown model) (3864 MHz)",1, "Intel Pentium Pro (Unknown model) (2710 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1441 MHz)",1, "Intel Pentium Pro (Unknown model) (2585 MHz)",1, "AMD K7 (Unknown model) (1228 MHz)",1, "Intel Pentium Pro (Unknown model) (2614 MHz)",1, "Intel Pentium Pro (Unknown model) (3852 MHz)",1, "Intel Pentium 4 Northwood (2736 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1567 MHz)",1, "AMD (Unknown model) (983 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (916 MHz)",1, "Intel Pentium 4 (Unknown model) (3650 MHz)",1, "Intel Pentium 4 (Unknown model) (2780 MHz)",1, "AMD Athlon (Thunderbird core) (1216 MHz)",1, "Intel Pentium 4 (Unknown model) (2622 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1292 MHz)",1, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (834 MHz)",1, "Intel Pentium 4 (Unknown model) (1507 MHz)",1, "Intel Pentium Pro (Unknown model) (1760 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1487 MHz)",1, "Intel Pentium Pro (Unknown model) (5349 MHz)",1, "Intel Pentium 4 Willamette (2002 MHz)",1, "AMD (Unknown model) (1216 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (844 MHz)",1, "Intel Pentium Pro (Unknown model) (685 MHz)",1, "AMD Athlon (Thunderbird core) (790 MHz)",1, "Intel Pentium 4 (Unknown model) (3965 MHz)",1, "Intel Pentium 4 (Unknown model) (4238 MHz)",1, "Intel Pentium 4 (Unknown model) (2698 MHz)",1, "Intel Pentium 4 (Unknown model) (3540 MHz)",1, "Intel Pentium 4 (Unknown model) (3674 MHz)",1, "Intel Pentium 4 Northwood (3227 MHz)",1, "Intel Pentium 4 (Unknown model) (4440 MHz)",1, "Intel Pentium 4 (Unknown model) (2518 MHz)",1, "Intel Pentium 4 (Unknown model) (3424 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (971 MHz)",1, "Intel Pentium 4 Northwood (2428 MHz)",1, "Intel Pentium 4 (Unknown model) (1866 MHz)",1, "Intel Pentium 4 (Unknown model) (4300 MHz)",1, "Intel Pentium Pro (Unknown model) (3280 MHz)",1, "Intel Pentium 4 Northwood (2641 MHz)",1, "Intel Pentium Pro (Unknown model) (1385 MHz)",1, "Intel Pentium 4 Northwood (2310 MHz)",1, "AMD (Unknown model) (1227 MHz)",1, "AMD Athlon (0.18 micron) (706 MHz)",1, "Intel Pentium 4 (Unknown model) (1713 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1692 MHz)",1, "Intel Pentium 4 (Unknown model) (4479 MHz)",1, "AMD (Unknown model) (922 MHz)",1, "Intel Pentium 4 (Unknown model) (2747 MHz)",1, "Intel Pentium 4 Northwood Xeon (1499 MHz)",1, "Intel Pentium 4 Northwood (1859 MHz)",1, "Intel Pentium 4 Northwood (2861 MHz)",1, "Intel Pentium 4 Northwood (2030 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1722 MHz)",1, "AMD K7 (Unknown model) (894 MHz)",1, "AMD K7 (Unknown model) (2184 MHz)",1, "Intel Pentium Pro (Unknown model) (314 MHz)",1, "Intel Pentium 4 Willamette (2061 MHz)",1, "Intel Pentium Pro (Unknown model) (676 MHz)",1, "Intel Pentium Pro (Unknown model) (1951 MHz)",1, "Intel Pentium 4 (Unknown model) (4380 MHz)",1, "AMD K7 (Unknown model) (531 MHz)",1, "Intel Pentium 4 (Unknown model) (3512 MHz)",1, "Intel Pentium 4 Northwood Xeon (2645 MHz)",1, "Intel Pentium 4 (Unknown model) (2915 MHz)",1, "Intel Pentium Pro (Unknown model) (3185 MHz)",1, "Intel Pentium Pro (Unknown model) (1914 MHz)",1, "Intel Pentium 4 (Unknown model) (6346 MHz)",1, "Intel Pentium 4 Northwood (3248 MHz)",1, "Intel Pentium 4 (Unknown model) (4068 MHz)",1, "AMD (Unknown model) (1051 MHz)",1, "AMD K7 (Unknown model) (2397 MHz)",1, "Intel Pentium 4 Northwood (3174 MHz)",1, "AMD (Unknown model) (2336 MHz)",1, "Intel Pentium 4 (Unknown model) (6244 MHz)",1, "AMD K7 (Unknown model) (2148 MHz)",1, "AMD K7 (Unknown model) (2387 MHz)",1, "Intel Pentium Pro (Unknown model) (1851 MHz)",1, "Intel Pentium 4 (Unknown model) (2038 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (434 MHz)",1, "Intel Pentium 4 (Unknown model) (2865 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (427 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (619 MHz)",1, "Intel Pentium 4 (Unknown model) (2320 MHz)",1, "Intel Pentium III (Tualatin core, 0.13 micron process) with internal L2 cache (1396 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (444 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1750 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (824 MHz)",1, "Intel Pentium Pro (Unknown model) (411 MHz)",1, "Intel Pentium 4 Northwood (2437 MHz)",1, "Intel Pentium Pro (Unknown model) (1152 MHz)",1, "Intel Pentium Pro (Unknown model) (1203 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (805 MHz)",1, "Intel Pentium 4 (Unknown model) (4644 MHz)",1, "Intel Pentium 4 (Unknown model) (3246 MHz)",1, "Intel Pentium 4 Northwood Xeon (1574 MHz)",1, "Intel Pentium Pro (Unknown model) (2193 MHz)",1, "Intel Pentium Pro (Unknown model) (527 MHz)",1, "Dual i386 (Unknown) (2450 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1279 MHz)",1, "Intel Pentium 4 Northwood (2121 MHz)",1, "AMD K7 (Unknown model) (2054 MHz)",1, "AMD (Unknown model) (2715 MHz)",1, "AMD K7 (Unknown model) (2038 MHz)",1, "AMD K7 (Unknown model) (1446 MHz)",1, "Dual i386 (Unknown) (3010 MHz)",1, "AMD (Unknown model) (1081 MHz)",1, "Intel Pentium Pro (Unknown model) (363 MHz)",1, "Intel Pentium Pro (Unknown model) (3040 MHz)",1, "Intel Pentium Pro (Unknown model) (3825 MHz)",1, "Intel Pentium Pro (Unknown model) (580 MHz)",1, "Intel Pentium 4 Northwood Xeon (2250 MHz)",1, "Intel Pentium 4 Northwood (2116 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (794 MHz)",1, "Intel Pentium 4 (Unknown model) (2419 MHz)",1, "Intel Pentium 4 Northwood (1507 MHz)",1, "Intel Pentium Pro (Unknown model) (2620 MHz)",1, "AMD K7 (Unknown model) (1092 MHz)",1, "AMD K7 (Unknown model) (1270 MHz)",1, "Intel Pentium Pro (Unknown model) (1967 MHz)",1, "AMD (Unknown model) (1017 MHz)",1, "AMD K7 (Unknown model) (1976 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (858 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (894 MHz)",1, "AMD (Unknown model) (1312 MHz)",1, "Intel Pentium 4 Northwood (3578 MHz)",1, "Intel Pentium 4 Northwood (3346 MHz)",1, "AMD Duron (Spitfire core) (597 MHz)",1, "Intel Pentium 4 (Unknown model) (1714 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (824 MHz)",1, "Intel Pentium 4 Northwood (3197 MHz)",1, "AMD (Unknown model) (1059 MHz)",1, "Intel Pentium 4 Northwood (3288 MHz)",1, "Intel Pentium Pro (Unknown model) (3552 MHz)",1, "Intel Pentium 4 Northwood (3754 MHz)",1, "AMD Athlon (Thunderbird core) (701 MHz)",1, "AMD K7 (Unknown model) (1130 MHz)",1, "Intel Pentium 4 (Unknown model) (3798 MHz)",1, "Intel Pentium 4 Northwood Xeon (2742 MHz)",1, "AMD (Unknown model) (1186 MHz)",1, "i386 (Unknown) (1800 MHz)",1, "Intel Pentium 4 Northwood (3716 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (900 MHz)",1, "Dual i386 (Unknown) (2600 MHz)",1, "AMD (Unknown model) (2801 MHz)",1, "Intel Pentium Pro (Unknown model) (881 MHz)",1, "Intel Pentium Pro (Unknown model) (532 MHz)",1, "Intel Pentium 4 (Unknown model) (2294 MHz)",1, "Intel Pentium Pro (Unknown model) (1650 MHz)",1, "Intel Pentium Pro (Unknown model) (315 MHz)",1, "Intel Pentium Pro (Unknown model) (943 MHz)",1, "Intel Pentium Pro (Unknown model) (503 MHz)",1, "Intel Pentium Pro (Unknown model) (495 MHz)",1, "Intel Pentium Pro (Unknown model) (2358 MHz)",1, "AMD K7 (Unknown model) (996 MHz)",1, "Intel Pentium Pro (Unknown model) (500 MHz)",1, "AMD K7 (Unknown model) (906 MHz)",1, "Intel Pentium Pro (Unknown model) (523 MHz)",1, "Intel Pentium Pro (Unknown model) (525 MHz)",1, "AMD (Unknown model) (885 MHz)",1, "Intel Pentium 4 (Unknown model) (3127 MHz)",1, "Intel Pentium Pro (Unknown model) (1840 MHz)",1, "Intel Pentium Pro (Unknown model) (1841 MHz)",1, "Intel Pentium Pro (Unknown model) (324 MHz)",1, "AMD (Unknown model) (1145 MHz)",1, "Intel Pentium 4 Northwood (2607 MHz)",1, "AMD (Unknown model) (887 MHz)",1, "AMD K7 (Unknown model) (1334 MHz)",1, "AMD (Unknown model) (1285 MHz)",1, "Intel Pentium Pro (Unknown model) (2538 MHz)",1, "Intel Pentium Pro (Unknown model) (1706 MHz)",1, "Intel Pentium Pro (Unknown model) (2511 MHz)",1, "Intel Pentium Pro (Unknown model) (1612 MHz)",1, "Intel Pentium Pro (Unknown model) (683 MHz)",1, "Intel Pentium Pro (Unknown model) (2485 MHz)",1, "AMD (Unknown model) (1215 MHz)",1, "AMD (Unknown model) (1152 MHz)",1, "Intel Pentium Pro (Unknown model) (2480 MHz)",1, "Intel Pentium Pro (Unknown model) (1742 MHz)",1, "AMD (Unknown model) (1277 MHz)",1, "AMD (Unknown model) (2624 MHz)",1, "Intel Pentium Pro (Unknown model) (3255 MHz)",1, "Intel Pentium Pro (Unknown model) (3159 MHz)",1, "Intel Pentium Pro (Unknown model) (1842 MHz)",1, "AMD (Unknown model) (805 MHz)",1, "AMD (Unknown model) (2998 MHz)",1, "Intel Pentium Pro (Unknown model) (715 MHz)",1, "AMD (Unknown model) (1070 MHz)",1, "Intel Pentium Pro (Unknown model) (1813 MHz)",1, "AMD Duron (Spitfire core) (831 MHz)",1, "Intel Pentium 4 (Unknown model) (1746 MHz)",1, "Intel Pentium Pro (Unknown model) (1818 MHz)",1, "Intel Pentium 4 Northwood Xeon (1372 MHz)",1, "Intel Pentium Pro (Unknown model) (435 MHz)",1, "Intel Pentium Pro (Unknown model) (941 MHz)",1, "Intel Pentium Pro (Unknown model) (1613 MHz)",1, "AMD (Unknown model) (2275 MHz)",1, "AMD (Unknown model) (1502 MHz)",1, "AMD Mobile Duron (Morgan core) (1094 MHz)",1, "Intel Pentium Pro (Unknown model) (402 MHz)",1, "Intel Pentium Pro (Unknown model) (1884 MHz)",1, "Intel Pentium 4 (Unknown model) (865 MHz)",1, "Intel Pentium Pro (Unknown model) (432 MHz)",1, "Intel Pentium Pro (Unknown model) (1680 MHz)",1, "Intel Pentium 4 (Unknown model) (9973 MHz)",1, "Intel Pentium Pro (Unknown model) (587 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (976 MHz)",1, "AMD (Unknown model) (1685 MHz)",1, "Intel Pentium Pro (Unknown model) (3593 MHz)",1, "Intel Pentium Pro (Unknown model) (2833 MHz)",1, "AMD (Unknown model) (1290 MHz)",1, "AMD (Unknown model) (1308 MHz)",1, "AMD (Unknown model) (2487 MHz)",1, "Dual i386 (Unknown) (1730 MHz)",1, "Intel Pentium Pro (Unknown model) (1165 MHz)",1, "Intel Pentium 4 (Unknown model) (3124 MHz)",1, "Intel Pentium 4 (Unknown model) (1906 MHz)",1, "Intel Pentium Pro (Unknown model) (413 MHz)",1, "Intel Pentium Pro (Unknown model) (3761 MHz)",1, "Intel Pentium Pro (Unknown model) (1852 MHz)",1, "AMD (Unknown model) (1153 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (642 MHz)",1, "Intel Pentium Pro (Unknown model) (364 MHz)",1, "Intel Pentium 4 (Unknown model) (3638 MHz)",1, "Intel Pentium 4 Northwood Xeon (1494 MHz)",1, "Intel Pentium Pro (Unknown model) (3437 MHz)",1, "Intel Pentium Pro (Unknown model) (466 MHz)",1, "Intel Pentium Pro (Unknown model) (822 MHz)",1, "Intel Pentium Pro (Unknown model) (3402 MHz)",1, "AMD Athlon (Thunderbird core) (1047 MHz)",1, "Intel Pentium 4 (Unknown model) (3984 MHz)",1, "Intel Pentium Pro (Unknown model) (489 MHz)",1, "AMD (Unknown model) (2756 MHz)",1, "Intel Pentium Pro (Unknown model) (408 MHz)",1, "Intel Pentium Pro (Unknown model) (414 MHz)",1, "Intel Pentium 4 (Unknown model) (3680 MHz)",1, "Intel Pentium 4 Northwood (2553 MHz)",1, "Intel Pentium Pro (Unknown model) (3454 MHz)",1, "Intel Pentium Pro (Unknown model) (2792 MHz)",1, "AMD Duron (Spitfire core) (749 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1764 MHz)",1, "AMD K7 (Unknown model) (1872 MHz)",1, "Intel Pentium Pro (Unknown model) (3285 MHz)",1, "Intel Pentium Pro (Unknown model) (2118 MHz)",1, "AMD (Unknown model) (3012 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1619 MHz)",1, "AMD K7 (Unknown model) (2274 MHz)",1, "Intel Pentium 4 Northwood (1728 MHz)",1, "AMD (Unknown model) (1755 MHz)",1, "Intel Pentium 4 Northwood (2575 MHz)",1, "Intel Pentium Pro (Unknown model) (2782 MHz)",1, "Intel Pentium 4 (Unknown model) (3122 MHz)",1, "Intel Pentium Pro (Unknown model) (2665 MHz)",1, "AMD K7 (Unknown model) (2139 MHz)",1, "Intel Pentium 4 (Unknown model) (3126 MHz)",1, "AMD (Unknown model) (1288 MHz)",1, "AMD (Unknown model) (1451 MHz)",1, "Intel Pentium Pro (Unknown model) (1611 MHz)",1, "Intel Pentium Pro (Unknown model) (2645 MHz)",1, "Intel Pentium Pro (Unknown model) (784 MHz)",1, "Intel Pentium Pro (Unknown model) (2043 MHz)",1, "Intel Pentium Pro (Unknown model) (960 MHz)",1, "Intel Pentium II (Model 3 core, 0.28 micron process) (299 MHz)",1, "Intel Pentium 4 (Unknown model) (2317 MHz)",1, "AMD (Unknown model) (2828 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (828 MHz)",1, "Intel Pentium 4 Northwood (2006 MHz)",1, "Intel Pentium 4 Willamette (1624 MHz)",1, "Intel Pentium 4 (Unknown model) (2847 MHz)",1, "Intel Pentium 4 Northwood Xeon (1191 MHz)",1, "AMD (Unknown model) (2853 MHz)",1, "Intel Pentium 4 Willamette (1710 MHz)",1, "AMD K7 (Unknown model) (1097 MHz)",1, "Intel Pentium 4 Northwood Xeon (2633 MHz)",1, "Intel Pentium 4 Northwood (2576 MHz)",1, "Intel Pentium Pro (Unknown model) (1578 MHz)",1, "Intel Pentium 4 Northwood Xeon (1692 MHz)",1, "Intel Pentium Pro (Unknown model) (3049 MHz)",1, "PowerPC 7450 (1580 MHz)",1, "AMD (Unknown model) (2821 MHz)",1, "AMD (Unknown model) (2822 MHz)",1, "AMD Athlon (0.18 micron) (644 MHz)",1, "AMD K7 (Unknown model) (1214 MHz)",1, "AMD (Unknown model) (1065 MHz)",1, "Intel Pentium Pro (Unknown model) (1670 MHz)",1, "Intel Pentium Pro (Unknown model) (1717 MHz)",1, "AMD (Unknown model) (1265 MHz)",1, "AMD (Unknown model) (786 MHz)",1, "Intel Pentium Pro (Unknown model) (2071 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1669 MHz)",1, "Intel Pentium Pro (Unknown model) (723 MHz)",1, "Intel Pentium 4 Northwood (1981 MHz)",1, "Intel Pentium 4 Willamette (1721 MHz)",1, "AMD Duron (Spitfire core) (866 MHz)",1, "AMD K7 (Unknown model) (1287 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (531 MHz)",1, "Intel Pentium Pro (Unknown model) (2636 MHz)",1, "Intel Pentium 4 (Unknown model) (3826 MHz)",1, "AMD K7 (Unknown model) (1295 MHz)",1, "AMD K7 (Unknown model) (2044 MHz)",1, "Intel Pentium Pro (Unknown model) (671 MHz)",1, "Intel Pentium Pro (Unknown model) (2089 MHz)",1, "AMD (Unknown model) (1318 MHz)",1, "Intel Pentium Pro (Unknown model) (2347 MHz)",1, "AMD Athlon (Thunderbird core) (1090 MHz)",1, "Intel Pentium III Xeon (0.18 micron process) with internal L2 cache (930 MHz)",1, "Intel Pentium Pro (Unknown model) (2568 MHz)",1, "Intel Pentium Pro (Unknown model) (1617 MHz)",1, "AMD (Unknown model) (2546 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (403 MHz)",1, "Intel Pentium Pro (Unknown model) (2461 MHz)",1, "AMD (Unknown model) (2615 MHz)",1, "Intel Pentium Pro (Unknown model) (444 MHz)",1, "Intel Pentium Pro (Unknown model) (2027 MHz)",1, "Intel Pentium Pro (Unknown model) (779 MHz)",1, "Intel Pentium Pro (Unknown model) (2711 MHz)",1, "Intel Pentium Pro (Unknown model) (2111 MHz)",1, "Intel Pentium Pro (Unknown model) (2441 MHz)",1, "AMD Athlon (Thunderbird core) (1424 MHz)",1, "AMD (Unknown model) (2789 MHz)",1, "Intel Pentium 4 Northwood (1724 MHz)",1, "Intel Pentium 4 (Unknown model) (3757 MHz)",1, "Unknown (998 MHz)",1, "AMD (Unknown model) (910 MHz)",1, "Unknown (1513 MHz)",1, "AMD (Unknown model) (944 MHz)",1, "Intel Pentium Pro (Unknown model) (2467 MHz)",1, "Intel Pentium 4 (Unknown model) (3776 MHz)",1, "Intel Pentium Pro (Unknown model) (739 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1191 MHz)",1, "Intel Pentium Pro (Unknown model) (701 MHz)",1, "Intel Pentium 4 Northwood (2207 MHz)",1, "Intel Pentium 4 Northwood Xeon (1689 MHz)",1, "PowerMac (1499.999000MHz)",1, "Intel Pentium Pro (Unknown model) (1713 MHz)",1, "AMD K7 (Unknown model) (1932 MHz)",1, "Intel Pentium 4 Northwood (2280 MHz)",1, "AMD Athlon (Thunderbird core) (630 MHz)",1, "Intel Pentium 4 Northwood (2164 MHz)",1, "Intel Pentium Pro (Unknown model) (727 MHz)",1, "AMD (Unknown model) (1229 MHz)",1, "AMD K7 (Unknown model) (1982 MHz)",1, "Intel Pentium 4 Northwood (1854 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1024 MHz)",1, "AMD Duron (Spitfire core) (951 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (687 MHz)",1, "Intel Pentium 4 (Unknown model) (6393 MHz)",1, "Intel Pentium Pro (Unknown model) (1273 MHz)",1, "Intel Pentium Pro (Unknown model) (2056 MHz)",1, "AMD K7 (Unknown model) (957 MHz)",1, "Intel Pentium 4 Northwood (1622 MHz)",1, "Intel Pentium 4 (Unknown model) (4297 MHz)",1, "Intel Pentium 4 (Unknown model) (3100 MHz)",1, "Intel Pentium Pro (Unknown model) (2502 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1521 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (557 MHz)",1, "Intel Pentium 4 Northwood (1700 MHz)",1, "AMD (Unknown model) (2856 MHz)",1, "AMD (Unknown model) (2738 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1072 MHz)",1, "Intel Pentium 4 (Unknown model) (2911 MHz)",1, "Intel Pentium 4 (Unknown model) (4974 MHz)",1, "AMD (Unknown model) (2733 MHz)",1, "Intel Pentium 4 (Unknown model) (3375 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (1027 MHz)",1, "Intel Pentium 4 Northwood (3151 MHz)",1, "AMD (Unknown model) (1168 MHz)",1, "AMD (Unknown model) (2963 MHz)",1, "Intel Pentium 4 (Unknown model) (4059 MHz)",1, "Intel Pentium 4 (Unknown model) (2537 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1331 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (541 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1124 MHz)",1, "AMD Mobile Duron (Morgan core) (1005 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1575 MHz)",1, "Intel Pentium Pro (Unknown model) (1821 MHz)",1, "Intel Pentium 4 (Unknown model) (3910 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1014 MHz)",1, "AMD Athlon (Thunderbird core) (1149 MHz)",1, "AMD (Unknown model) (1437 MHz)",1, "AMD (Unknown model) (2337 MHz)",1, "Intel Pentium 4 Northwood Xeon (3199 MHz)",1, "Intel Pentium 4 Willamette (1874 MHz)",1, "Intel Pentium 4 (Unknown model) (3932 MHz)",1, "Intel Pentium 4 Northwood Xeon (2491 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1807 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (893 MHz)",1, "Intel Pentium 4 (Unknown model) (3989 MHz)",1, "Intel Pentium 4 Northwood Xeon (2190 MHz)",1, "Intel Pentium 4 (Unknown model) (3956 MHz)",1, "AMD K7 (Unknown model) (2320 MHz)",1, "AMD (Unknown model) (856 MHz)",1, "AMD Athlon (Thunderbird core) (1386 MHz)",1, "Intel Pentium 4 (Unknown model) (4358 MHz)",1, "Intel Pentium Pro (Unknown model) (3105 MHz)",1, "AMD K7 (Unknown model) (2234 MHz)",1, "Intel Pentium 4 Willamette (2003 MHz)",1, "AMD K7 (Unknown model) (1640 MHz)",1, "Intel Pentium 4 Northwood (1619 MHz)",1, "Unknown (668 MHz)",1, "AMD K7 (Unknown model) (1776 MHz)",1, "AMD K7 (Unknown model) (1711 MHz)",1, "Intel Pentium Pro (Unknown model) (2147 MHz)",1, "AMD K6-2 (499 MHz)",1, "Intel Pentium Pro (Unknown model) (542 MHz)",1, "Intel Pentium 4 (Unknown model) (2244 MHz)",1, "AMD (Unknown model) (2231 MHz)",1, "Intel Pentium 4 Willamette (1962 MHz)",1, "AMD (Unknown model) (1771 MHz)",1, "Intel Pentium 4 Northwood (1835 MHz)",1, "Intel Pentium 4 Willamette (1990 MHz)",1, "AMD (Unknown model) (2949 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1763 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (775 MHz)",1, "AMD K7 (Unknown model) (1258 MHz)",1, "AMD Athlon (Thunderbird core) (796 MHz)",1, "AMD (Unknown model) (1260 MHz)",1, "Intel Pentium 4 (Unknown model) (2580 MHz)",1, "AMD K7 (Unknown model) (2238 MHz)",1, "AMD (Unknown model) (2858 MHz)",1, "Intel Pentium 4 Northwood (399 MHz)",1, "Intel Pentium 4 Northwood (1709 MHz)",1, "AMD K7 (Unknown model) (1001 MHz)",1, "Intel Pentium 4 (Unknown model) (4415 MHz)",1, "Intel Pentium 4 (Unknown model) (4129 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1412 MHz)",1, "AMD (Unknown model) (816 MHz)",1, "AMD K7 (Unknown model) (1594 MHz)",1, "Intel Pentium 4 (Unknown model) (4160 MHz)",1, "Intel Pentium 4 (Unknown model) (2731 MHz)",1, "AMD (Unknown model) (2381 MHz)",1, "Intel Pentium 4 (Unknown model) (2638 MHz)",1, "Intel Pentium Pro (Unknown model) (2334 MHz)",1, "Intel Pentium 4 Northwood (2963 MHz)",1, "AMD (Unknown model) (2652 MHz)",1, "Intel Pentium 4 (Unknown model) (1871 MHz)",1, "AMD K7 (Unknown model) (1873 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (597 MHz)",1, "AMD (Unknown model) (1627 MHz)",1, "Intel Pentium 4 (Unknown model) (3291 MHz)",1, "AMD Athlon (Thunderbird core) (1294 MHz)",1, "Intel Pentium 4 (Unknown model) (3102 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1629 MHz)",1, "Intel Pentium 4 (Unknown model) (2006 MHz)",1, "Intel Pentium Pro (Unknown model) (3077 MHz)",1, "Intel Pentium 4 Northwood (3149 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1638 MHz)",1, "Intel Pentium 4 (Unknown model) (3369 MHz)",1, "Intel Pentium 4 (Unknown model) (3975 MHz)",1, "AMD (Unknown model) (2701 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (2217 MHz)",1, "Intel Pentium 4 (Unknown model) (5785 MHz)",1, "AMD K7 (Unknown model) (1218 MHz)",1, "AMD (Unknown model) (4422 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1754 MHz)",1, "Intel Pentium Pro (Unknown model) (2625 MHz)",1, "AMD K7 (Unknown model) (1137 MHz)",1, "Intel Pentium 4 Northwood (2025 MHz)",1, "Intel Pentium Pro (Unknown model) (687 MHz)",1, "Intel Pentium 4 (Unknown model) (3028 MHz)",1, "AMD (Unknown model) (1500 MHz)",1, "Intel Pentium Pro (Unknown model) (2904 MHz)",1, "Intel Pentium Pro (Unknown model) (515 MHz)",1, "AMD Athlon (0.25 micron) (489 MHz)",1, "AMD (Unknown model) (2112 MHz)",1, "AMD (Unknown model) (2739 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1397 MHz)",1, "AMD (Unknown model) (2945 MHz)",1, "Intel Pentium 4 Northwood (3008 MHz)",1, "4 x Dual-Core AMD Opteron(tm) Processor 2214 (2200 MHz)",1, "Intel Pentium Pro (Unknown model) (2676 MHz)",1, "Intel Pentium 4 (Unknown model) (2966 MHz)",1, "Intel Pentium 4 Northwood Xeon (2886 MHz)",1, "AMD K7 (Unknown model) (2308 MHz)",1, "Intel Pentium 4 Willamette Xeon (1724 MHz)",1, "AMD (Unknown model) (2744 MHz)",1, "AMD Athlon (Thunderbird core) (1340 MHz)",1, "AMD Athlon (0.18 micron) (906 MHz)",1, "Intel Pentium 4 Northwood (2225 MHz)",1, "AMD K7 (Unknown model) (2239 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1650 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1600 MHz)",1, "AMD Athlon (Thunderbird core) (1312 MHz)",1, "Intel Pentium 4 Northwood Xeon (3014 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (467 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (847 MHz)",1, "Intel Pentium 4 Northwood (3222 MHz)",1, "AMD Mobile Duron (Morgan core) (1004 MHz)",1, "Intel Pentium 4 Northwood (3239 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (674 MHz)",1, "AMD (Unknown model) (1713 MHz)",1, "Intel Pentium 4 Northwood Xeon (2423 MHz)",1, "Intel Pentium 4 (Unknown model) (4522 MHz)",1, "Intel Pentium 4 (Unknown model) (4283 MHz)",1, "Intel Pentium Pro (Unknown model) (409 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (618 MHz)",1, "Intel Pentium 4 Willamette (1519 MHz)",1, "AMD (Unknown model) (1653 MHz)",1, "Intel Pentium 4 (Unknown model) (4220 MHz)",1, "Intel Pentium 4 Northwood (2757 MHz)",1, "Intel Pentium Pro (Unknown model) (2822 MHz)",1, "Intel Pentium Pro (Unknown model) (2702 MHz)",1, "AMD (Unknown model) (1435 MHz)",1, "Intel Pentium 4 (Unknown model) (4332 MHz)",1, "Intel Pentium 4 Willamette Xeon (1900 MHz)",1, "Intel Pentium 4 (Unknown model) (6238 MHz)",1, "Intel Pentium 4 Northwood (2139 MHz)",1, "Intel Pentium Pro (Unknown model) (635 MHz)",1, "AMD (Unknown model) (2786 MHz)",1, "Intel Pentium Pro (Unknown model) (451 MHz)",1, "Intel Pentium 4 Northwood (3223 MHz)",1, "Intel Pentium Pro (Unknown model) (583 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (755 MHz)",1, "Intel Pentium 4 Northwood (2971 MHz)",1, "Intel Pentium 4 Northwood Xeon (2795 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (462 MHz)",1, "Intel Pentium Pro (Unknown model) (752 MHz)",1, "Intel Pentium 4 (Unknown model) (2204 MHz)",1, "Intel Pentium 4 (Unknown model) (9000 MHz)",1, "Intel Pentium 4 (Unknown model) (4977 MHz)",1, "AMD K7 (Unknown model) (1429 MHz)",1, "AMD (Unknown model) (2684 MHz)",1, "Intel Pentium 4 (Unknown model) (4428 MHz)",1, "Intel Pentium 4 Northwood (3211 MHz)",1, "AMD K7 (Unknown model) (5377 MHz)",1, "Intel Pentium 4 Northwood (2243 MHz)",1, "Intel Pentium 4 Northwood (3209 MHz)",1, "AMD (Unknown model) (852 MHz)",1, "AMD Athlon (Thunderbird core) (1338 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (1406 MHz)",1, "AMD K7 (Unknown model) (936 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1057 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (1108 MHz)",1, "Intel Pentium 4 (Unknown model) (3376 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (883 MHz)",1, "Intel Pentium 4 Northwood (1875 MHz)",1, "AMD K7 (Unknown model) (1410 MHz)",1, "AMD K7 (Unknown model) (2254 MHz)",1, "Intel Pentium 4 (Unknown model) (3664 MHz)",1, "Intel Pentium 4 Northwood (2297 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1259 MHz)",1, "AMD K7 (Unknown model) (2241 MHz)",1, "Intel Pentium 4 (Unknown model) (2858 MHz)",1, "AMD (Unknown model) (1911 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (659 MHz)",1, "Intel Pentium Pro (Unknown model) (490 MHz)",1, "Intel Pentium 4 Northwood (2978 MHz)",1, "AMD K7 (Unknown model) (2269 MHz)",1, "Intel Pentium 4 Northwood Xeon (1900 MHz)",1, "AMD K7 (Unknown model) (2264 MHz)",1, "Intel Pentium 4 Northwood (2024 MHz)",1, "Intel Pentium 4 (Unknown model) (1600 MHz)",1, "Intel Pentium Pro (Unknown model) (2564 MHz)",1, "AMD Athlon (0.18 micron) (855 MHz)",1, "Intel Pentium 4 Northwood (2516 MHz)",1, "Intel Pentium 4 Northwood (2136 MHz)",1, "AMD Athlon (0.25 micron) (600 MHz)",1, "Intel Pentium 4 (Unknown model) (2108 MHz)",1, "Intel Pentium 4 (Unknown model) (2883 MHz)",1, "AMD (Unknown model) (1497 MHz)",1, "Intel Pentium 4 Northwood (1867 MHz)",1, "Intel Pentium 4 (Unknown model) (2123 MHz)",1, "Intel Pentium 4 (Unknown model) (2104 MHz)",1, "Intel Pentium 4 (Unknown model) (4033 MHz)",1, "Intel Pentium 4 (Unknown model) (3498 MHz)",1, "Intel Celeron mobile (Tualatin core, 0.13 micron process) with internal L2 cache (1066 MHz)",1, "AMD (Unknown model) (2616 MHz)",1, "4 x PowerPC 7400 (2660 MHz)",1, "Intel Pentium Pro (Unknown model) (3153 MHz)",1, "Intel Pentium Pro (Unknown model) (1856 MHz)",1, "AMD (Unknown model) (1289 MHz)",1, "Intel Pentium 4 (Unknown model) (2250 MHz)",1, "Intel Pentium Pro (Unknown model) (753 MHz)",1, "2 x AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2010 MHz)",1, "AMD K7 (Unknown model) (1106 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (589 MHz)",1, "Intel Pentium III Xeon (0.18 micron process) with internal L2 cache (933 MHz)",1, "AMD (Unknown model) (2371 MHz)",1, "AMD (Unknown model) (2566 MHz)",1, "Intel Pentium 4 Northwood (2348 MHz)",1, "Intel Pentium Pro (Unknown model) (4271 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (567 MHz)",1, "Intel Pentium 4 Northwood (1930 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (560 MHz)",1, "Intel Pentium Pro (Unknown model) (242 MHz)",1, "AMD K7 (Unknown model) (1844 MHz)",1, "AMD (Unknown model) (1752 MHz)",1, "AMD K7 (Unknown model) (512 MHz)",1, "Intel Pentium Pro (Unknown model) (2760 MHz)",1, "Intel Pentium 4 (Unknown model) (3678 MHz)",1, "PowerPC 7450 (1350 MHz)",1, "Intel Celeron (Tualatin core, 0.13 micron process) with internal L2 cache (1340 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (904 MHz)",1, "Intel Pentium 4 Northwood Xeon (3271 MHz)",1, "Intel Pentium Pro (Unknown model) (3217 MHz)",1, "Intel Pentium III Tualatin core (unknown model, 0.13 micron process) with internal L2 cache (998 MHz)",1, "Intel Pentium Pro (Unknown model) (2245 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1393 MHz)",1, "Intel Pentium Pro (Unknown model) (1616 MHz)",1, "AMD (Unknown model) (1466 MHz)",1, "AMD K7 (Unknown model) (2293 MHz)",1, "Intel Pentium 4 Northwood (2173 MHz)",1, "AMD (Unknown model) (1390 MHz)",1, "Intel Pentium Pro (Unknown model) (2055 MHz)",1, "Intel Pentium 4 (Unknown model) (5985 MHz)",1, "Intel Pentium 4 Willamette Xeon (2048 MHz)",1, "Intel Pentium II with internal L2 cache (331 MHz)",1, "Intel Pentium Pro (Unknown model) (3509 MHz)",1, "Intel Pentium 4 (Unknown model) (2702 MHz)",1, "AMD (Unknown model) (2694 MHz)",1, "AMD (Unknown model) (1559 MHz)",1, "Intel Pentium 4 Northwood (3145 MHz)",1, "AMD (Unknown model) (1225 MHz)",1, "Intel Pentium 4 (Unknown model) (3357 MHz)",1, "AMD K7 (Unknown model)",1, "AMD (Unknown model) (699 MHz)",1, "AMD Mobile Duron (Morgan core) (1329 MHz)",1, "AMD (Unknown model) (2301 MHz)",1, "Intel Pentium III/Pentium III Xeon (0.25 micron process) with external L2 cache (533 MHz)",1, "Intel Pentium Pro (Unknown model) (2681 MHz)",1, "Intel Pentium Pro (Unknown model) (235 MHz)",1, "AMD (Unknown model) (1745 MHz)",1, "Intel Pentium 4 (Unknown model) (2379 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1589 MHz)",1, "Intel Pentium 4 Willamette (A-Step) (1482 MHz)",1, "AMD (Unknown model) (2491 MHz)",1, "Intel Pentium 4 (Unknown model) (2316 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (768 MHz)",1, "Intel Pentium Pro (Unknown model) (2060 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (890 MHz)",1, "Intel Pentium 4 (Unknown model) (2314 MHz)",1, "Intel Pentium 4 Northwood (2058 MHz)",1, "Intel Pentium 4 (Unknown model) (3425 MHz)",1, "Intel Pentium 4 Northwood (2512 MHz)",1, "Intel Pentium Pro (Unknown model) (1882 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1518 MHz)",1, "AMD (Unknown model) (2521 MHz)",1, "AMD K7 (Unknown model) (1801 MHz)",1, "AMD K7 (Unknown model) (1884 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1694 MHz)",1, "Intel Pentium 4 (Unknown model) (231 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1388 MHz)",1, "Intel Pentium 4 (Unknown model) (4289 MHz)",1, "AMD K7 (Unknown model) (1786 MHz)",1, "AMD (Unknown model) (1501 MHz)",1, "Intel Pentium 4 Northwood (2239 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1497 MHz)",1, "AMD K7 (Unknown model) (1521 MHz)",1, "Intel Pentium 4 (Unknown model) (4303 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (690 MHz)",1, "Intel Pentium 4 Northwood (2273 MHz)",1, "Intel Pentium Pro (Unknown model) (2250 MHz)",1, "AMD (Unknown model) (1748 MHz)",1, "Intel Pentium 4 (Unknown model) (3626 MHz)",1, "AMD (Unknown model) (791 MHz)",1, "Intel Pentium Pro (Unknown model) (949 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (934 MHz)",1, "Intel Pentium 4 Willamette (1502 MHz)",1, "Intel Pentium 4 Northwood Xeon (2050 MHz)",1, "AMD (Unknown model) (1333 MHz)",1, "AMD Athlon (Thunderbird core) (1176 MHz)",1, "Intel Pentium Pro (Unknown model) (2145 MHz)",1, "Intel Pentium 4 (Unknown model) (3373 MHz)",1, "Intel Pentium Pro (Unknown model) (1974 MHz)",1, "Intel Pentium Pro (Unknown model) (531 MHz)",1, "Intel Pentium 4 Northwood (2438 MHz)",1, "Intel Pentium Pro (Unknown model) (2155 MHz)",1, "Intel Pentium 4 Willamette Xeon (1594 MHz)",1, "Dual PowerPC 7400 (1990 MHz)",1, "AMD (Unknown model) (1718 MHz)",1, "AMD (Unknown model) (913 MHz)",1, "Intel Pentium 4 Northwood (2051 MHz)",1, "Intel Pentium III (0.18 micron process) with internal L2 cache (1197 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (599 MHz)",1, "Intel Pentium 4 (Unknown model) (3454 MHz)",1, "Intel Pentium 4 Northwood Xeon (2395 MHz)",1, "Intel Pentium 4 Northwood (2248 MHz)",1, "Intel Pentium 4 (Unknown model) (3977 MHz)",1, "Intel Celeron (0.18 micron process) with internal L2 cache (598 MHz)",1, "Intel Pentium Pro (Unknown model) (1926 MHz)",1, "Intel Pentium 4 (Unknown model) (5669 MHz)",1, "Intel Pentium 4 (Unknown model) (3820 MHz)",1, "AMD (Unknown model) (2721 MHz)",1, "Intel Pentium 4 (Unknown model) (3824 MHz)",1, "Intel Pentium Pro (Unknown model) (561 MHz)",1, "Intel Pentium Pro (Unknown model) (2708 MHz)",1, "Intel Pentium 4 Northwood (1864 MHz)",1, "AMD (Unknown model) (1134 MHz)",1, "AMD (Unknown model) (1712 MHz)",1, "AMD Athlon (Thunderbird core) (992 MHz)",1, "Intel Pentium 4 Northwood (2602 MHz)",1, "Intel Pentium Pro (Unknown model) (2104 MHz)",1, "AMD Athlon MP/Mobile Athlon (Palomino core) (1580 MHz)",1, "Intel Pentium 4 (Unknown model) (3091 MHz)",1, "Intel Pentium Pro (Unknown model) (1887 MHz)",1, "Intel Pentium 4 (Unknown model) (3510 MHz)",1, "Intel Pentium 4 (Unknown model) (4387 MHz)",1, "Intel Pentium Pro (Unknown model) (592 MHz)",1, "Intel Pentium 4 (Unknown model) (3286 MHz)",1, "Intel Pentium Pro (Unknown model) (965 MHz)",1, "AMD Mobile Duron (Morgan core) (1332 MHz)",1, "Intel Pentium Pro (Unknown model) (4103 MHz)",1, ,518971, -------------- next part -------------- "GPU","Unique Agents","% Uniq Agents" "INTEL Class 0 Intel 945G",24952,5.60% "NVIDIA Class 1 NVIDIA GeForce FX 5200",23283,5.23% "INTEL Class 0 Intel 915G",20432,4.59% "ATI Class 1 ATI Radeon 9600",18610,4.18% "ATI Class 1 ATI Radeon Xpress",18599,4.18% "ATI Class 1 ATI Radeon 9200",18482,4.15% "NVIDIA Class 0 NVIDIA GeForce 4 MX",18407,4.13% "ATI Class 3 ATI Radeon X1600",17158,3.85% "NVIDIA Class 3 NVIDIA GeForce 7600",16476,3.70% "NVIDIA Class 2 NVIDIA GeForce 6600",14355,3.22% "NVIDIA Class 2 NVIDIA GeForce 6200",13596,3.05% "NVIDIA Class 3 NVIDIA GeForce 7300",13119,2.95% "NVIDIA Class 0 NVIDIA Generic",13093,2.94% "NVIDIA Class 2 NVIDIA GeForce 6100",8600,1.93% "ATI Class 2 ATI Radeon X300",8115,1.82% "NVIDIA Class 3 NVIDIA GeForce 7900",7988,1.79% "NVIDIA Class 0 NVIDIA GeForce 2",7348,1.65% "NVIDIA Class 2 NVIDIA GeForce 6800",7248,1.63% "INTEL Class 0 Intel 865G",7105,1.59% "NVIDIA Class 1 NVIDIA GeForce FX 5500",7074,1.59% "ATI Class 2 ATI Mobility Radeon X1xxx",6895,1.55% "MISC Class 0 SiS",6652,1.49% "INTEL Class 0 Intel 950",6389,1.43% "ATI Class 1 ATI Radeon 9500",6255,1.40% "ATI Class 3 ATI Radeon X1300",6100,1.37% "ATI Class 1 ATI Radeon 9000",5981,1.34% "NVIDIA Class 3 NVIDIA GeForce Go 7600",5463,1.23% "ATI Class 2 ATI Radeon X600",5333,1.20% "ATI Class 2 ATI Radeon X800",5174,1.16% "INTEL Class 0 Intel 855GM",5009,1.12% "ATI Class 1 ATI Radeon 9800",4890,1.10% "MISC Class 0 S3",4817,1.08% "NVIDIA Class 3 NVIDIA GeForce Go 7400",4536,1.02% "INTEL Class 0 Intel 845G",4474,1.00% "NVIDIA Class 3 NVIDIA GeForce Go 7300",4409,0.99% "NVIDIA Class 0 NVIDIA GeForce 4 Ti",4158,0.93% "NVIDIA Class 3 NVIDIA GeForce 7800",4064,0.91% "ATI Class 0 ATI Radeon 7000",3870,0.87% "NVIDIA Class 3 NVIDIA GeForce 8800",3794,0.85% "NVIDIA Class 2 NVIDIA GeForce Go 6100",3779,0.85% "ATI Class 1 ATI Radeon 9700",3695,0.83% "INTEL Class 0 Intel Montara",3674,0.82% "ATI Class 3 ATI Radeon X1900",3605,0.81% "INTEL Class 0 Intel Brookdale",3421,0.77% "ATI Class 1 ATI Mobility Radeon X3xx",3164,0.71% "NVIDIA Class 1 NVIDIA GeForce FX 5700",3137,0.70% "ATI Class 1 ATI Mobility Radeon X6xx",2903,0.65% "ATI Class 1 ATI Mobility Radeon X7xx",2701,0.61% "NVIDIA Class 0 NVIDIA GeForce 4 Go",2665,0.60% "ATI Class 2 ATI Radeon X700",2622,0.59% "NVIDIA Class 1 NVIDIA GeForce FX 5600",2376,0.53% "NVIDIA Class 1 NVIDIA GeForce FX Go5200",2032,0.46% "NVIDIA Class 3 NVIDIA GeForce Go 7900",1861,0.42% "INTEL Class 0 Intel Springdale",1841,0.41% "ATI Class 2 ATI Radeon X500",1805,0.41% "NVIDIA Class 1 NVIDIA GeForce FX 5900",1334,0.30% "NVIDIA Class 0 NVIDIA GeForce 3",1206,0.27% "ATI Class 0 ATI FireMV",1130,0.25% "NVIDIA Class 2 NVIDIA GeForce Go 6800",925,0.21% "ATI Class 0 ATI FireGL",836,0.19% "NVIDIA Class 2 NVIDIA GeForce Go 6600",826,0.19% "NVIDIA Class 2 NVIDIA GeForce 6500",713,0.16% "ATI Class 3 ATI Radeon X1500",664,0.15% "INTEL Class 0 Intel Intel Broadwater G",637,0.14% "NVIDIA Class 1 NVIDIA GeForce FX Go5600",631,0.14% "ATI Class 3 ATI FireGL 5xxx",625,0.14% "NVIDIA Class 2 NVIDIA GeForce 6700",602,0.14% "ATI Class 0 ATI ASUS X1xxx",580,0.13% "NVIDIA Class 2 NVIDIA GeForce Go 6200",565,0.13% "ATI Class 0 ATI Radeon 8000",474,0.11% "ATI Class 1 ATI Radeon 9100",441,0.10% "MISC Class 0 Tungsten Graphics",439,0.10% "ATI Class 3 ATI Radeon X1800",427,0.10% "NVIDIA Class 2 NVIDIA GeForce Go 6",427,0.10% "NVIDIA Class 1 NVIDIA GeForce PCX",350,0.08% "NVIDIA Class 1 NVIDIA GeForce FX Go5700",335,0.08% "INTEL Class 0 Intel Intel 965/963 Graphics Media Accelerator",321,0.07% "INTEL Class 0 Intel 830M",313,0.07% "NVIDIA Class 3 NVIDIA GeForce Go 7800",286,0.06% "MISC Class 0 Intel 945G",227,0.05% "ATI Class 0 ATI Rage 128",217,0.05% "NVIDIA Class 1 NVIDIA GeForce FX Go5300",146,0.03% "MISC Class 0 Intel 915G",146,0.03% "ATI Class 3 ATI Diamond X1xxx",106,0.02% "NVIDIA Class 1 NVIDIA GeForce FX Go5100",98,0.02% "MISC Class 0 Matrox",97,0.02% "NVIDIA Class 0 NVIDIA GeForce",93,0.02% "NVIDIA Class 1 NVIDIA GeForce FX 5100",88,0.02% "ATI Class 0 ATI Generic",79,0.02% "ATI Class 1 ATI All-in-Wonder PCI-E",76,0.02% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9600 SERIES x86/SSE2",63,0.01% "ATI Class 0 ATI Technologies Inc. RV250 DDR x86/SSE2",60,0.01% "ATI Class 0 ATI Technologies Inc. RADEON IGP 340M DDR x86/SSE2",58,0.01% "MISC Class 0 Intel 855GM",51,0.01% "ATI Class 2 ATI All-in-Wonder X800",49,0.01% "NVIDIA Class 1 NVIDIA GeForce FX 5800",35,0.01% "ATI Class 0 ATI Technologies Inc. RV530 PRO x86/SSE2",34,0.01% "ATI Class 3 ATI All-in-Wonder X1900",33,0.01% "ATI Class 0 ATI Technologies Inc. ATI Radeon HD 2900 XT",30,0.01% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9600 SERIES x86/MMX/3DNow!/SSE",30,0.01% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1050",29,0.01% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X300SE x86/SSE2",28,0.01% "ATI Class 0 ATI Technologies Inc. Radeon X1300XT/X1600 Pro Series x86/SSE2",28,0.01% "ATI Class 0 ATI Technologies Inc. RV530 PRO x86/MMX/3DNow!/SSE2",27,0.01% "MISC Class 0 Intel 865G",27,0.01% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9800 SERIES x86/SSE2",27,0.01% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1050 x86/SSE2",26,0.01% "INTEL Class 0 Intel 3D-Analyze v2.3 - http://www.tommti-systems.com",25,0.01% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9600 SERIES x86/MMX/3DNow!/SSE2",22,0.00% "ATI Class 3 ATI All-in-Wonder X1800",20,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9800 SERIES x86/MMX/3DNow!/SSE",20,0.00% "ATI Class 3 ATI Radeon X1700",17,0.00% "ATI Class 0 ATI Technologies Inc. RV250 DDR x86/MMX/3DNow!/SSE",17,0.00% "ATI Class 0 ATI Technologies Inc. Radeon X1300XT/X1600 Pro Series",16,0.00% "ATI Class 0 ATI Technologies Inc. ATI Mobility Radeon X2300",16,0.00% "ATI Class 0 ATI Technologies Inc. M56 x86/SSE2",15,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER X600 Series x86/MMX/3DNow!/SSE2",15,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1200 Series x86/MMX/3DNow!/SSE2",15,0.00% "MISC Class 0 Mesa project: www.mesa3d.org Mesa GLX Indirect",15,0.00% "MISC Class 0 Intel 845G",14,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1200 Series",14,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9700 SERIES x86/SSE2",14,0.00% "ATI Class 0 ATI Technologies Inc. ATI Mobility Radeon X2300 x86/SSE2",13,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER X600 Series x86/SSE2",13,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9800 SERIES x86/MMX/3DNow!/SSE2",13,0.00% "ATI Class 0 ATI Technologies Inc. Radeon VE DDR x86/SSE",13,0.00% "ATI Class 0 ATI Technologies Inc. Radeon VE SDR x86/SSE2",13,0.00% "ATI Class 0 ATI Technologies Inc. 3D-Analyze v2.3 - http://www.tommti-systems.com",12,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X1600 Series x86/MMX/3DNow!/SSE2",12,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1050 x86/MMX/3DNow!/SSE2",12,0.00% "ATI Class 0 ATI Technologies Inc. x86/SSE2",12,0.00% "MISC Class 0 3Dlabs",11,0.00% "ATI Class 3 ATI Radeon OpenGL",11,0.00% "ATI Class 0 ATI Technologies Inc. Radeon X1300XT/X1600 Pro Series x86/MMX/3DNow!/SSE2",11,0.00% "ATI Class 0 ATI Technologies Inc. RV530 LE (Omega 3.8.330) x86/SSE2",10,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1250 x86/MMX/3DNow!/SSE2",10,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X1300 Series x86/SSE2",10,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X300SE x86/MMX/3DNow!/SSE2",8,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X600 PRO x86/SSE2",8,0.00% "ATI Class 0 ATI Technologies Inc. Radeon X1300XT/X1600 Pro Series x86/MMX/3DNow!/SSE",8,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1050 x86/MMX/3DNow!/SSE",8,0.00% "MISC Class 0 (Redacted ??? Soft) Mesa X11",8,0.00% "ATI Class 0 ATI Technologies Inc. HERCULES 3D PROPHET 9800 XT Classic x86/SSE2",7,0.00% "ATI Class 0 ATI Technologies Inc. M54 x86/SSE2",7,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X1300 Series x86/MMX/3DNow!/SSE2",7,0.00% "ATI Class 0 ATI Technologies Inc. RV530 VE (Omega 3.8.330) x86/SSE2",6,0.00% "ATI Class 0 ATI Technologies Inc. RADEON X1600 Series x86/MMX/3DNow!/SSE2",6,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9700 SERIES x86/MMX/3DNow!/SSE",5,0.00% "ATI Class 0 ATI Technologies Inc. MSI RX9550SE x86/SSE2",5,0.00% "ATI Class 0 ATI Technologies Inc. M52 x86/SSE2",5,0.00% "MISC Class 0 ATI FireGL",5,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X300 x86/SSE2",5,0.00% "ATI Class 0 ATI Technologies Inc. RV250 Prototype DDR x86/SSE2",5,0.00% "ATI Class 0 ATI Technologies Inc. RADEON 9250/9200 Series DDR x86/SSE2",5,0.00% "ATI Class 0 ATI Technologies Inc. Radeon VE SDR x86/MMX/3DNow!/SSE",5,0.00% "ATI Class 0 ATI Technologies Inc. ASUS Extreme AX300SE/T x86/SSE2",5,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER X600 Series",4,0.00% "ATI Class 0 ATI Technologies Inc. RV530 LE (Omega 3.8.330) x86/MMX/3DNow!/SSE2",4,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X600 PRO x86/MMX/3DNow!/SSE2",4,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 6200/AGP/SSE2",4,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1200",4,0.00% "ATI Class 0 ATI Technologies Inc. ASUS Extreme AX600XT-TD x86/SSE2",4,0.00% "INTEL Class 0 Intel 900",4,0.00% "MISC Class 0 Intel 830M",4,0.00% "ATI Class 0 ATI Technologies Inc. MSI RX9550SE x86/MMX/3DNow!/SSE",4,0.00% "INTEL Class 0 Intel Intel 915GM",4,0.00% "ATI Class 0 ATI Technologies Inc. RV530 PRO x86/MMX/3DNow!/SSE",3,0.00% "ATI Class 0 ATI Technologies Inc. MSI RX700PRO x86/MMX/3DNow!/SSE2",3,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce Go 7300/PCI/SSE2",3,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1270 x86/MMX/3DNow!/SSE2",3,0.00% "ATI Class 0 ATI Technologies Inc. Radeon VE DDR x86/MMX/3DNow!/SSE",3,0.00% "ATI Class 0 ATI Technologies Inc. RV530 PRO x86/MMX/3DNow!",3,0.00% "ATI Class 0 ATI Mobility Radeon X1xxx",3,0.00% "ATI Class 0 ATI Technologies Inc. X1600 PRO x86/SSE2",3,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 8800 GTX/PCI/SSE2/3DNOW!",3,0.00% "ATI Class 0 ATI Technologies Inc. ASUS EAH2900 Series",3,0.00% "ATI Class 0 ATI Technologies Inc. Radeon SDR x86/SSE",3,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7300 GT/AGP/SSE2",3,0.00% "ATI Class 0 ATI Technologies Inc. RV530 LE Secondary (Omega 3.8.330) x86/MMX/3DNow!/SSE2",3,0.00% "ATI Class 0 ATI Technologies Inc. Radeon VE DDR x86/SSE2",3,0.00% "NVIDIA Class 3 NVIDIA GeForce 6800",2,0.00% "ATI Class 0 ATI Technologies Inc. HIGHTECH EXCALIBUR X700 PRO x86/SSE2",2,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7600 GT/PCI/SSE2/3DNOW!",2,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 6600 GT/PCI/SSE2",2,0.00% "ATI Class 0 ATI Technologies Inc. RV530 XT x86/SSE2",2,0.00% "NVIDIA Class 3 NVIDIA GeForce 8600",2,0.00% "ATI Class 0 ATI Technologies Inc. RV530 XT x86/MMX/3DNow!/SSE2",2,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce Go 6150/PCI/SSE2/3DNOW!",2,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9700 SERIES x86/MMX/3DNow!/SSE2",2,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce Go 7600/PCI/SSE2/3DNOW!",2,0.00% "MISC Class 0 Intergraph Corporation wcgdrv 06.06.01.14",2,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9800 SERIES - x86/MMX/3DNow!/SSE",2,0.00% "INTEL Class 0 Intel Intel Bear Lake B",2,0.00% "ATI Class 0 ATI Technologies Inc. RV250 DDR x86/MMX/3DNow!",2,0.00% "ATI Class 0 ATI Technologies Inc. Radeon X1900 GT x86/MMX/3DNow!/SSE2",2,0.00% "ATI Class 0 ATI Technologies Inc. ATI display adapter Pentium 4 (SSE2)",2,0.00% "INTEL Class 0 Intel Intel Calistoga",2,0.00% "MISC Class 0 Trident",2,0.00% "ATI Class 0 ATI Technologies Inc. MSI RX9550SE x86/MMX/3DNow!/SSE2",2,0.00% "ATI Class 0 ATI Technologies Inc. ATI Mobility Radeon X2500",2,0.00% "ATI Class 0 ATI Technologies Inc. ASUS Extreme AX300SE/T x86",2,0.00% "ATI Class 0 ATI Technologies Inc. RADEON 9700 x86/SSE2",2,0.00% "ATI Class 0 ATI Technologies Inc. Diamond X300SEHM-PCIE 256MB x86/SSE2",2,0.00% "MISC Class 0 Humper Chromium",2,0.00% "ATI Class 0 ATI Technologies Inc. RV250 Prototype DDR x86/MMX/3DNow!/SSE",2,0.00% "ATI Class 0 ATI Technologies Inc. RADEON XPRESS 200M Series SW TCL x86/MMX/3DNow!/SSE2",2,0.00% "INTEL Class 0 Intel Intel 945GM",1,0.00% "ATI Class 0 ATI Technologies Inc. HIGHTECH EXCALIBUR X600 PRO VIVO Edition x86/MMX/3DNow!/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X1600 Series x86",1,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon 9550 / X1050 Series x86/MMX/3DNow!/SSE",1,0.00% "ATI Class 0 ATI Technologies Inc. RADEON X600 x86/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce FX 5700LE/AGP/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. RADEON 9800 XT x86/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 6150 LE/PCI/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. RV530 VE (Omega 3.8.291) x86/MMX/3DNow!/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RV530 LE (Omega 3.8.330) x86/MMX/3DNow!/SSE",1,0.00% "ATI Class 0 ATI Technologies Inc. ASUS Extreme AX550 Series x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RV410 Pro x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RADEON X850 XT x86/MMX/3DNow!/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RADEON 9500 Pro x86/MMX/3DNow!/SSE",1,0.00% "ATI Class 0 ATI Technologies Inc. XTreme-G WarCat Radeon X1300 Series x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RADEON 9600 x86/MMX/3DNow!/SSE",1,0.00% "ATI Class 3 ATI Radeon Xpress",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7600 GS/PCI/SSE2/3DNOW!",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7900 GT/PCI/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. Radeon X1950 Series",1,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9800 SERIES - Secondary x86/SSE2",1,0.00% "MISC Class 0 Intergraph Corporation wcgdrv 05.05.03.33",1,0.00% "ATI Class 0 ATI Technologies Inc. MSI RX9550SE x86",1,0.00% "ATI Class 0 ATI Technologies Inc. VisionTek RADEON X1300 (Omega 3.8.330) x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9600 SERIES x86/MMX/3DNow!",1,0.00% "ATI Class 0 ATI Technologies Inc. ATI MOBILITY RADEON 9XXX x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. ASUS Extreme AX300SE/T - Secondary x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc.",1,0.00% "NVIDIA Class 1 NVIDIA GeForce ??????????o5200",1,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9600 SERIES - Secondary x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RADEON X600/X550 Series x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. ASUS Extreme AX300SE/T x86/MMX/3DNow!/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 6800/AGP/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. HERCULES 3D PROPHET 9800 XT Classic x86/MMX/3DNow!/SSE",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7300 LE/PCI/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. RV530 LE (Omega 3.8.252) x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RV530 VE (Omega 3.8.330) x86/MMX/3DNow!/SSE",1,0.00% "ATI Class 0 ATI Technologies Inc. RADEON 9500 PRO / 9700 x86/SSE2",1,0.00% "MISC Class 0 VIA Technology Mesa DRI UniChrome (KM400) 20050526",1,0.00% "ATI Class 0 ATI Technologies Inc. RADEON 9600 Series (Omega 3.8.360) x86/MMX/3DNow!/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7900 GS/PCI/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. Diamond X550-PCIE OC 256MB x86/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 8800 GTS/PCI/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER 9600 SERIES x86",1,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X700 PRO x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. MOBILITY RADEON X600 x86/SSE2",1,0.00% "INTEL Class 0 Intel Intel Grantsdale-G",1,0.00% "ATI Class 0 ATI Technologies Inc. x86",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7300 GS/PCI/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. Radeon X1600 Series x86/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 6600 GT/PCI/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X700 PRO x86/MMX/3DNow!/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. MOBILITY RADEON 9000 DDR x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. Radeon DDR x86/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce4 Ti 4200 with AGP8X/AGP/SSE/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. HIGHTECH EXCALIBUR RADEON 9600 x86/MMX/3DNow!/SSE",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce FX 5500/AGP/SSE/3DNOW!",1,0.00% "NVIDIA Class 1 NVIDIA GeForce ????a????????o5200",1,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1050 x86/SSE",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7950 GX2/PCI/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. (DNA-ATi 5.1.7.5x32) ATI Radeon HD 2900 XT",1,0.00% "ATI Class 0 ATI Technologies Inc. R480 Pro x86/MMX/3DNow!/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. Radeon X1800 GTO x86/MMX/3DNow!/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce FX 5500/AGP/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 8800 GTX/PCI/SSE2",1,0.00% "NVIDIA Class 1 NVIDIA GeForce H????????o5200",1,0.00% "ATI Class 0 ATI Technologies Inc. HERCULES 3D PROPHET 9800 XT Classic (Omega 3. x86/MMX/3DNow!/SSE",1,0.00% "ATI Class 0 ATI Technologies Inc. RV530 LE Secondary (Omega 3.8.360) x86/MMX/3DNow!/SSE2",1,0.00% "MISC Class 0 DRI R300 Project Mesa DRI R300 20060815 AGP 8x x86/MMX/SSE2 TCL",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7900 GT/GTO/PCI/SSE2/3DNOW!",1,0.00% "ATI Class 0 ATI Technologies Inc. Tul Corporation, RADEON X600 PRO (Omega 3.8. x86/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce Go 7400/PCI/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RV530 LE (Omega 3.8.330) x86/SSE",1,0.00% "ATI Class 0 ATI Technologies Inc. Radeon",1,0.00% "ATI Class 0 ATI Technologies Inc. ASUS Extreme AX600XT-TD x86/MMX/3DNow!/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RV530 LE (Omega 3.8.291) x86/SSE2",1,0.00% "MISC Class 0 DRI R300 Project Mesa DRI R300 20060815 AGP 4x TCL",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 7900 GT/GTO/PCI/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. XTreme-G WarCat ASUS Extreme AX600XT-TD x86/SSE2",1,0.00% "MISC Class 0 Intergraph Corporation wcgdrv 06.05.03.33",1,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon HD 2600 PRO OpenGL Engine",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce Go 7800 GTX/PCI/SSE2",1,0.00% "NVIDIA Class 0 NVIDIA Corporation GeForce 8800 GTS/PCI/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RV250 DDR x86/SSE",1,0.00% "ATI Class 0 ATI Technologies Inc. ASUS X700 Series x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. RV530 LE (Omega 3.8.360) x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon X1050 x86/MMX/3DNow!",1,0.00% "ATI Class 0 ATI Technologies Inc. Radeon VE SDR x86/SSE",1,0.00% "ATI Class 0 ATI Technologies Inc. ASUS X800 Series x86/MMX/3DNow!/SSE2",1,0.00% "MISC (Redacted ??? Soft)",1,0.00% "ATI Class 0 ATI Technologies Inc. Radeon X1300 Series x86/MMX/3DNow!/SSE2",1,0.00% "ATI Class 3 ATI Radeon X800",1,0.00% "ATI Class 0 ATI Technologies Inc. Radeon DDR x86/SSE",1,0.00% "ATI Class 0 ATI Technologies Inc. ATI Radeon???? Xpress 1150 (Omega 3.8.330) x86/SSE2",1,0.00% "ATI Class 0 ATI Technologies Inc. ALL-IN-WONDER X600 Series x86",1,0.00% ,445457,100.00% From able.whitman at gmail.com Wed Jun 20 16:30:14 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 20 16:30:15 2007 Subject: [sldev] Linker error building a Debug viewer from 1.17.0.12 sources under VC8 In-Reply-To: <4679B3D1.5000604@blueflash.cc> References: <7b3a84fb0706200109p18cef446w69eed376e8efa220@mail.gmail.com> <46796A92.8050307@blueflash.cc> <7b3a84fb0706201539v2ca332e3rf3d12045654edcd5@mail.gmail.com> <4679B3D1.5000604@blueflash.cc> Message-ID: <7b3a84fb0706201630r4d24b51ej210ac76f2eac5ba6@mail.gmail.com> That was my plan if tracking down the latest llmozlib source turned out to be a big hassle. :) I figured if I built the debug libs myself, at least I could share them with other folks. On 6/20/07, Nicholaz Beresford wrote: > > > Able, > > have you tried to just #ifndef _DEBUG the calls to those > two functions and use an MozLib::init from an older > source? They sound as if the viewer could run > without them. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Able Whitman wrote: > > Okay, with Nick's clever hack, I managed to get the Debug configuration > > to build successfully. However, I'm hitting an access violation during > > startup: > > > > "Unhandled exception at 0x02d79179 in debugview.exe : 0xC0000005: Access > > violation writing location 0x0c368000." > > > > The culprit is "debugview.exe!LLMozLib::init() + 0x56 bytes", called > > from idle_startup() on line 536 of llstartup.cpp. Curiously, the call to > > idle_startup is missing from the debugger call stack, which jumps > > immediately from the call to idle() on line 3566 of viewer.cpp to the > > call to LLMozLib::init(). > > > > I suspect that something about linking the Debug build with the release > > version of llmozlib-vc80.lib is causing problems, even though > > __invalid_parameter() has been defined. Linking against the supplied > > debug version of llmozlib-vc80.lib doesn't work, and results in 3 > > unresolved externals: > > > > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > > __thiscall LLMozLib::enableCookies(bool)" ... "public: virtual void > > __thiscall LLPanelWeb::refresh(void)" > > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > > __thiscall LLMozLib::clearAllCookies(void)" ... referenced in function > > "private: static void __cdecl > > LLPanelWeb::callback_clear_cookies(int,void *)" > > llstartup.obj : error LNK2019: unresolved external symbol "public: bool > > __thiscall LLMozLib::init(class std::basic_string > std::char_traits,class std::allocator >,class > > std::basic_string,class > > std::allocator >,class std::basic_string > std::char_traits,class std::allocator >)" ... referenced in > > function "int __cdecl idle_startup(void)" > > > > It looks to me like these functions are related to the new cookie > > handling Preferences added in 1.17, and that someone forgot to rebuild > > the debug version of llmozlib-vc80.lib before the source went out the > > door. :) > > > > What are the reasons that the source for llmoz lib isn't included with > > the rest of the source? My next step is to build my own version of it, > > but is the version at http://www.ubrowser.com/downloads.php (dated > > 2006-11-06) the latest version? > > > > --Able > > > > > > On 6/20/07, *Nicholaz Beresford* < nicholaz@blueflash.cc > > > wrote: > > > > > > Ouch, actually it doesn't seem to run. Dunno if > > I did something wrong with that piece of code, maybe > > it helps someone somehow anyway. > > > > > > Nick > > > > > > Second Life from the inside out: > > http://nicholaz-beresford.blogspot.com/ > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070620/2978e5be/attachment.htm From able.whitman at gmail.com Wed Jun 20 16:35:33 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 20 16:35:36 2007 Subject: [sldev] CPU and GPU statistics In-Reply-To: <9e6e5c9e0706201614p44340c6ch72b3710c795d062a@mail.gmail.com> References: <9e6e5c9e0706201614p44340c6ch72b3710c795d062a@mail.gmail.com> Message-ID: <7b3a84fb0706201635p558f457bgb557a07f93c31a85@mail.gmail.com> Hi, Soft, Thanks for the data! I have a suggestion though -- for the "unique percent" column, could you expand the field's precision so that less popular CPU and GPU entries don't show up as "0.00%"? (Or, in the case of the CPU list, show upas blank.) Cheers, --Able On 6/20/07, Soft Linden wrote: > > The question of what CPUs SL users have has come up a number of times, > and I believe GPUs have been mentioned as well. Attached, please find > statistics on CPUs and reported GPUs for all platforms over a similar > one week period. > > I haven't made any attempt to consolidate similar CPUs and GPUs. I > don't know enough about the models to know where I might omit > something important, such as cache size or SIMD abilities varying > between two clocks of a like part model. I did remove the labels from > two graphic cards/drivers, where I wasn't sure that the name reported > was accurate, or that it didn't reveal personal information. > > I formatted this as CSV, which should parse by Excel, OpenOffice, or > your favorite perl script. > > Let me know if ya find any interesting surprises. If you want to take > a swing at summarizing, grouping by capability, or the like, that > would be awesome. > > If this message comes through without two attachments, then I've > learned a lesson about utf-8 or attachment sizes :) > > _______________________________________________ > 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/20070620/cc12f487/attachment.htm From soft at lindenlab.com Wed Jun 20 16:41:58 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jun 20 16:42:00 2007 Subject: [sldev] CPU and GPU statistics In-Reply-To: <7b3a84fb0706201635p558f457bgb557a07f93c31a85@mail.gmail.com> References: <9e6e5c9e0706201614p44340c6ch72b3710c795d062a@mail.gmail.com> <7b3a84fb0706201635p558f457bgb557a07f93c31a85@mail.gmail.com> Message-ID: <9e6e5c9e0706201641x3fab5731ie8943bdcbc92039d@mail.gmail.com> The field before the percentage is the raw count. You can regenerate the percentage by dividing it into the sum on the last line of each file for much deeper precision if ya want all those leading zeros. But really, we're just poking fun at the lonely Pentium III users by this point. :) On 6/20/07, Able Whitman wrote: > Hi, Soft, > > Thanks for the data! I have a suggestion though -- for the "unique percent" > column, could you expand the field's precision so that less popular CPU and > GPU entries don't show up as " 0.00%"? (Or, in the case of the CPU list, > show upas blank.) > > Cheers, > --Able > > > On 6/20/07, Soft Linden < soft@lindenlab.com> wrote: > > > > The question of what CPUs SL users have has come up a number of times, > > and I believe GPUs have been mentioned as well. Attached, please find > > statistics on CPUs and reported GPUs for all platforms over a similar > > one week period. > > > > I haven't made any attempt to consolidate similar CPUs and GPUs. I > > don't know enough about the models to know where I might omit > > something important, such as cache size or SIMD abilities varying > > between two clocks of a like part model. I did remove the labels from > > two graphic cards/drivers, where I wasn't sure that the name reported > > was accurate, or that it didn't reveal personal information. > > > > I formatted this as CSV, which should parse by Excel, OpenOffice, or > > your favorite perl script. > > > > Let me know if ya find any interesting surprises. If you want to take > > a swing at summarizing, grouping by capability, or the like, that > > would be awesome. > > > > If this message comes through without two attachments, then I've > > learned a lesson about utf-8 or attachment sizes :) > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > From kerdezixe at gmail.com Wed Jun 20 17:06:04 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jun 20 17:06:06 2007 Subject: [sldev] CPU and GPU statistics In-Reply-To: <9e6e5c9e0706201641x3fab5731ie8943bdcbc92039d@mail.gmail.com> References: <9e6e5c9e0706201614p44340c6ch72b3710c795d062a@mail.gmail.com> <7b3a84fb0706201635p558f457bgb557a07f93c31a85@mail.gmail.com> <9e6e5c9e0706201641x3fab5731ie8943bdcbc92039d@mail.gmail.com> Message-ID: <8a1bfe660706201706u7f469440ke1012cf806cff24f@mail.gmail.com> There is some interesting drivers/cards coming from some huge visualisation station/cluster/... (VR room ?) and some total craps like SiS or Trident ... The CPU frenquency identification seems weird ... I spotted a "Intel Pentium 4 (Unknown model) (5669 MHz)" ... 5.66Ghz ? And what about all thoses "Pentium Pro" ? As far as i know the Pentium Pro are really old (is isn't it in the golden age of pentium 2 ?) and i never heard about Pentium Pro running at 2Ghz ? The latest pentium Pro i owned ran at 233Mhz ... and it was pretty fast :) and "Dual i386 (Unknown) (2160 MHz)",5071,0.98%" <- Core (2) Duo ? most core (2) duo run at 2Ghz, or 2.16Ghz. And the bad Identification (it's certainly not the very old 386) could come from Intel Powered Mac ? -- kerunix Flan From nicholaz at blueflash.cc Wed Jun 20 17:09:52 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 20 17:10:19 2007 Subject: [sldev] CPU and GPU statistics Message-ID: <4679C1D0.2060005@blueflash.cc> Nice amount of Intel GPUs for a brand that isn't supported ... Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From soft at lindenlab.com Wed Jun 20 17:12:12 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jun 20 17:12:14 2007 Subject: [sldev] CPU and GPU statistics In-Reply-To: <8a1bfe660706201706u7f469440ke1012cf806cff24f@mail.gmail.com> References: <9e6e5c9e0706201614p44340c6ch72b3710c795d062a@mail.gmail.com> <7b3a84fb0706201635p558f457bgb557a07f93c31a85@mail.gmail.com> <9e6e5c9e0706201641x3fab5731ie8943bdcbc92039d@mail.gmail.com> <8a1bfe660706201706u7f469440ke1012cf806cff24f@mail.gmail.com> Message-ID: <9e6e5c9e0706201712p65f6db67u2f6056f4ebee8b82@mail.gmail.com> I wouldn't be surprised at *all* if some of the oddball chips like the VIA Joshua and Samuel were misidentified or generically categorized as Pentium Pro. I know Intel and AMD both have islands and endeavor to reach out to OSS developers on SL. If anyone's curious enough to try to make inroads and find preferred recognition techniques, that could be a good vector if their developer docs or *nix kernel sources aren't enough. On 6/20/07, Laurent Laborde wrote: > There is some interesting drivers/cards coming from some huge > visualisation station/cluster/... (VR room ?) > > and some total craps like SiS or Trident ... > > The CPU frenquency identification seems weird ... > I spotted a "Intel Pentium 4 (Unknown model) (5669 MHz)" ... 5.66Ghz ? > > And what about all thoses "Pentium Pro" ? As far as i know the Pentium > Pro are really old (is isn't it in the golden age of pentium 2 ?) and > i never heard about Pentium Pro running at 2Ghz ? The latest pentium > Pro i owned ran at 233Mhz ... and it was pretty fast :) > > and "Dual i386 (Unknown) (2160 MHz)",5071,0.98%" <- Core (2) Duo ? > most core (2) duo run at 2Ghz, or 2.16Ghz. And the bad Identification > (it's certainly not the very old 386) could come from Intel Powered > Mac ? > > -- > kerunix Flan > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Wed Jun 20 17:16:48 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jun 20 17:16:49 2007 Subject: [sldev] CPU and GPU statistics In-Reply-To: <7992d0d60706201650r20909705i3aa87200786804ea@mail.gmail.com> References: <9e6e5c9e0706201614p44340c6ch72b3710c795d062a@mail.gmail.com> <7992d0d60706201650r20909705i3aa87200786804ea@mail.gmail.com> Message-ID: <9e6e5c9e0706201716q789b5432y11c4bd6dda63d1e3@mail.gmail.com> Looking at the blame history, this seems to have been created and refined by half a dozen in-house developers. Should be wide-open for any improvements. On 6/20/07, Dirk Moerenhout wrote: > The CPU data is too generic to know which CPU's are really used. We > really need more precise info on which extension bits are set on the > x86 CPU's. Or at the least we'll need to update llprocessor.cpp. Now > there are way too many unknown models. Is llprocessor.cpp derived from > something public we can update to or do I just take the Intel and AMD > docs and fill the gaps? > > Dirk aka Blakar Ogre > > On 6/21/07, Soft Linden wrote: > > The question of what CPUs SL users have has come up a number of times, > > and I believe GPUs have been mentioned as well. Attached, please find > > statistics on CPUs and reported GPUs for all platforms over a similar > > one week period. > > > > I haven't made any attempt to consolidate similar CPUs and GPUs. I > > don't know enough about the models to know where I might omit > > something important, such as cache size or SIMD abilities varying > > between two clocks of a like part model. I did remove the labels from > > two graphic cards/drivers, where I wasn't sure that the name reported > > was accurate, or that it didn't reveal personal information. > > > > I formatted this as CSV, which should parse by Excel, OpenOffice, or > > your favorite perl script. > > > > Let me know if ya find any interesting surprises. If you want to take > > a swing at summarizing, grouping by capability, or the like, that > > would be awesome. > > > > If this message comes through without two attachments, then I've > > learned a lesson about utf-8 or attachment sizes :) > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > From kerdezixe at gmail.com Wed Jun 20 17:23:25 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jun 20 17:23:27 2007 Subject: [sldev] SSE/2/3 optimisations Message-ID: <8a1bfe660706201723o6fd4238dgd6e28da18ec5fc1c@mail.gmail.com> Hi, for all the asm and specific CPU instruction fanatic, i had an idea... that sound really stupid, maybe you had this idea. (i wonder how i didn't tought about it before). We have a plateform that we know, for sure, at 100%, the cpu support SSE2 and SSE3. ALL the mac intel (macbook, iMac, ...) run a Core Duo or a Core 2 Duo. and both CPU support MMX, SSE, SSE2, SSE3. The mac'tel release can have very plateform specific optimisation, since we all run one of those CPU. The Mac Pro run a 64-bits Xeon, not a core duo, but the 64 bits Xeon probably also support SSE3 :) We don't even need to add some check (and cpu overhead) about the support of thoses instructions, there is simply no Mac'tel that doesn't support SSE3, as far as i know. Have fun ! -- kerunix Flan From blakar at gmail.com Wed Jun 20 17:39:36 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jun 20 17:39:39 2007 Subject: [sldev] SSE/2/3 optimisations In-Reply-To: <8a1bfe660706201723o6fd4238dgd6e28da18ec5fc1c@mail.gmail.com> References: <8a1bfe660706201723o6fd4238dgd6e28da18ec5fc1c@mail.gmail.com> Message-ID: <7992d0d60706201739n493aaa0fjfb43d37235f00545@mail.gmail.com> Well, brilliant call indeed :) Only downside is that I do not own a Mac. Somebody willing to send me one? ;-) Most important downside to this is the fact that few people have one and hence few will benefit. I still hope we'll get at one point CPU statistics that tell us what is the best path forward. I wouldn't necessarily drop support for older CPU's but I wouldn't support them in the default distribution. Old pre-SSE Athlon's for example could get their own binary (with some 3DNow code to have a few speed ups). Dirk aka Blakar Ogre On 6/21/07, Laurent Laborde wrote: > Hi, > > for all the asm and specific CPU instruction fanatic, i had an idea... > that sound really stupid, maybe you had this idea. (i wonder how i > didn't tought about it before). > > We have a plateform that we know, for sure, at 100%, the cpu support > SSE2 and SSE3. > ALL the mac intel (macbook, iMac, ...) run a Core Duo or a Core 2 Duo. > and both CPU support MMX, SSE, SSE2, SSE3. > > The mac'tel release can have very plateform specific optimisation, > since we all run one of those CPU. The Mac Pro run a 64-bits Xeon, not > a core duo, but the 64 bits Xeon probably also support SSE3 :) > > We don't even need to add some check (and cpu overhead) about the > support of thoses instructions, there is simply no Mac'tel that > doesn't support SSE3, as far as i know. > > Have fun ! > > -- > kerunix Flan > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From soft at lindenlab.com Wed Jun 20 17:56:40 2007 From: soft at lindenlab.com (Soft Linden) Date: Wed Jun 20 17:56:41 2007 Subject: [sldev] Possible 3rd party contract for viewer modification Message-ID: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> A company with a significant in-world presence has approached Linden Lab about the best way to upload a very, very large number of images in Second Life. The viewer is useful for uploading small batches of images, but nothing like the number they've asked about. To me, what would make sense would be a patch to the viewer that can read image URLs from a database, grab images via curl, and post the asset IDs of successful uploads back to the database. Ideally, this would let them run a small farm of machines chewing through the image set. I'm suggesting we propose this to them, and their likely next question would be who could make such a patch to the viewer. If you're interested in being named, please write me off-list with contact information and a paragraph or two that you'd like to be passed on. I can't be a running intermediary, but I'll gladly facilitate the initial connection. I'm also going to point them at our developer page for a list of possible candidates: http://secondlife.com/developers/listings.php?category=SoftwareDeveloper Also, if you're not listed above but you'd like to be, consider filling out the form here. If you've had patches accepted in the past, the form should be all you need in order to be listed: http://secondlife.com/developers/submission.php I'd love to get one of our existing contributors on this. :) From adam at gwala.net Wed Jun 20 18:04:38 2007 From: adam at gwala.net (Adam Frisby) Date: Wed Jun 20 18:04:58 2007 Subject: [sldev] Possible 3rd party contract for viewer modification In-Reply-To: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> References: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> Message-ID: <4679CEA6.2000803@gwala.net> This is probably better served with a libsl based bot to be honest. Hacking up a client to do it would be messy at best and libsl already has appropriate asset upload functions inplace that would turn it into a 15 line C# application (plus libsl is easier to maintain than a custom viewer fork) Adam Soft Linden wrote: > A company with a significant in-world presence has approached Linden > Lab about the best way to upload a very, very large number of images > in Second Life. The viewer is useful for uploading small batches of > images, but nothing like the number they've asked about. > > To me, what would make sense would be a patch to the viewer that can > read image URLs from a database, grab images via curl, and post the > asset IDs of successful uploads back to the database. Ideally, this > would let them run a small farm of machines chewing through the image > set. I'm suggesting we propose this to them, and their likely next > question would be who could make such a patch to the viewer. > > If you're interested in being named, please write me off-list with > contact information and a paragraph or two that you'd like to be > passed on. I can't be a running intermediary, but I'll gladly > facilitate the initial connection. I'm also going to point them at our > developer page for a list of possible candidates: > http://secondlife.com/developers/listings.php?category=SoftwareDeveloper > > Also, if you're not listed above but you'd like to be, consider > filling out the form here. If you've had patches accepted in the past, > the form should be all you need in order to be listed: > http://secondlife.com/developers/submission.php > > I'd love to get one of our existing contributors on this. :) > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From kerdezixe at gmail.com Wed Jun 20 18:07:12 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jun 20 18:07:13 2007 Subject: [sldev] SSE/2/3 optimisations In-Reply-To: <7992d0d60706201739n493aaa0fjfb43d37235f00545@mail.gmail.com> References: <8a1bfe660706201723o6fd4238dgd6e28da18ec5fc1c@mail.gmail.com> <7992d0d60706201739n493aaa0fjfb43d37235f00545@mail.gmail.com> Message-ID: <8a1bfe660706201807p1785427fmd56ed7b42151d110@mail.gmail.com> On 6/21/07, Dirk Moerenhout wrote: > Well, brilliant call indeed :) Only downside is that I do not own a > Mac. Somebody willing to send me one? ;-) I keep my macbook pro, unless you send me a Mac Pro (octo-core please) :) > Most important downside to this is the fact that few people have one > and hence few will benefit. True. But thoses who want to play with SSE2 and 3, can, and there is no good reason to not accept thoses CPU specific optimisation for the mac'tel release. And if you don't have a mac, but you have a PC with a core (2) duo, or any cpu supporting SSE2/3 : if the optimisation work for your PC it should work for the mac too. Mac are now, more or less, a PC with sculpty design and flexi-shiny OS (and vista is a watermeloned blingtard !! yay(zerama!)) -- kerunix Flan From kerdezixe at gmail.com Wed Jun 20 18:14:00 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jun 20 18:14:02 2007 Subject: [sldev] Possible 3rd party contract for viewer modification In-Reply-To: <4679CEA6.2000803@gwala.net> References: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> <4679CEA6.2000803@gwala.net> Message-ID: <8a1bfe660706201814i6c01b404h87c9cc7fd95986d6@mail.gmail.com> Good idea Adam. And it could be better for some automated image upload. e.g : mmm ... *scratch his idea* ... Ebay auctions pics ? -- Kerunix Flan On 6/21/07, Adam Frisby wrote: > This is probably better served with a libsl based bot to be honest. > > Hacking up a client to do it would be messy at best and libsl already > has appropriate asset upload functions inplace that would turn it into a > 15 line C# application (plus libsl is easier to maintain than a custom > viewer fork) > > Adam > > Soft Linden wrote: > > A company with a significant in-world presence has approached Linden > > Lab about the best way to upload a very, very large number of images > > in Second Life. The viewer is useful for uploading small batches of > > images, but nothing like the number they've asked about. > > > > To me, what would make sense would be a patch to the viewer that can > > read image URLs from a database, grab images via curl, and post the > > asset IDs of successful uploads back to the database. Ideally, this > > would let them run a small farm of machines chewing through the image > > set. I'm suggesting we propose this to them, and their likely next > > question would be who could make such a patch to the viewer. > > > > If you're interested in being named, please write me off-list with > > contact information and a paragraph or two that you'd like to be > > passed on. I can't be a running intermediary, but I'll gladly > > facilitate the initial connection. I'm also going to point them at our > > developer page for a list of possible candidates: > > http://secondlife.com/developers/listings.php?category=SoftwareDeveloper > > > > Also, if you're not listed above but you'd like to be, consider > > filling out the form here. If you've had patches accepted in the past, > > the form should be all you need in order to be listed: > > http://secondlife.com/developers/submission.php > > > > I'd love to get one of our existing contributors on this. :) > > _______________________________________________ > > 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 agrimes at speakeasy.net Wed Jun 20 20:04:34 2007 From: agrimes at speakeasy.net (Alan Grimes) Date: Wed Jun 20 19:04:26 2007 Subject: [sldev] getting serious about software. Message-ID: <4679EAC2.3060604@speakeasy.net> I am becoming increasingly distressed about all this focus on chip-level optimizations. At best we're talking about a speedup of around 1.3. Auditing the code would probably close 2/3rds the open bug reports and yield a speedup between 5 and 10 times. Here are a few articles. of interest: http://www.eros-os.org/essays/reliability/paper.html The lesson I take from Eros is that to make a piece of software FAST, you first put all your effort into making it verifiably reliable and removing every stray and redundant line of code you can find. Next, Examine how your app interacts with the libraries on your system, are you using the right libraries? are you taking full advantage of the library's features? Once you've done that, go to the manufacturer's performance manuals: http://developer.amd.com/devguides.jsp These manuals tell you how best to use the language and the compiler to generate more efficient binaries before writing off any CPUs. next, you identify the most performance critical modules and generate dynamic libraries compiled for each of the major architectures. Finally, if you still need more that your compiler can't give you, you write assembly language kernels for the stuff that absolutely positively needs to be screaming fast and the code the compiler makes blows donky chunks. -- Opera: Sing it loud! :o( )>-< From able.whitman at gmail.com Wed Jun 20 21:44:20 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 20 21:44:22 2007 Subject: [sldev] More on Mute Visibility Message-ID: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> Howdy, On and off, I've been investigating the feasibility of implementing "Visibility Muting" as Nicholaz describes in VWR-1017 ( https://jira.secondlife.com/browse/VWR-1017), and as discussed in a few threads on this list. I'm pretty close to having a proof-of-concept patch ready which adds the ability to mute the visibility of objects by their ID, in much the same fashion that the existing chat muting function works. I'd like to know if anyone would be interested it testing the patch which, I assure you, is rather rough around the edges. This is mainly because I cobbled it together as I was learning how the visibility muting needs to interact with object update messages and with the rendering pipeline. But it works pretty well, at least for me. Since there was a fair amount of interest the last couple of times this topic came up, I thought I'd share some of what I learned during my investigation. If you're not interested or don't care, I won't be offended if you mute this thread. :) The patch will add a new object pie menu item next to the existing "Mute / Unmute" item, named "Mute / Unmute Visibility". This is what the patch endeavors to do when an object's visibility is muted: 1. The object is also muted "classically," that is, its chat is suppressed, just as with a normal mute. 2. Any particle system associated with the object is removed, just as with a normal mute. 3. All the textures on the object are replaced with a solid-white texture. 4. Phantom objects are made completely transparent. 5. Non-phantom objects are made 67% transparent. (They are not made entirely transparent because I believe that object collision happens in part on the server, so avatars would still run into them. This way they are at least visible enough to avoid.) 6. Attached sounds on the object have their gain forced to zero. 7. Hovering text on the object is removed. 8. Objects have their light source and fullbright settings turned off. 9. Touchable objects have their click action removed. 10. Objects for sale are not purchasable. 11. Objects have their angular velocity (llTargetOmega) forced to zero. If a muted object is part of a link set, all objects in the set are also visibly muted. At the moment, only LLVOVolume objects are visibly mutable; so you can't visibly mute things like avatars, trees, the ground, the sky, etc. The patch works by extending the existing mute list capability of the viewer, adding a new OBJECTVISIBLE mute type. There are a lot of places in the LLPrimitive, LLViewerObject, and LLVOVolume classes (more than I expected) that are hooked into altering their behavior when an object is muted. There are portions of this patch that I am not at all happy with because they're quite a hack, but now that I know what I'm doing (more or less), I think the implementation can be much improved. A few observations from testing visibility muting so far: 1. It is possible to mute buildings -- houses, clubs, skyboxes, etc. This seems like an obvious statement, but I hadn't considered the implications of it until I tried muting my house. At first this was mildly amusing, but it does raise some very important privacy concerns. 2. Muting lots of individual, unlinked objects -- like lots of ad cubes or billboards or whatever -- is a pain. I might jam in a Client menu item and a keyboard accelerator, just because clicking the object pie menus over and over is really annoying. 3. It really, really reduces visual clutter. There's no question that visibility muting, even in this rough form, is very helpful at eliminating clutter and spam from ad prims and the like. Even though you wind up with a bunch of semi-transparent cubes hovering around, it's a huge improvement. I also learned some things about the feasibility of doing visibility muting by-owner or by-parcel: Mute-By-Owner is a nice idea, technically possible, but a bad way to go. The problem is that the owner information is not included in the ObjectUpdate message (or any of the related Update messages). In order to ascertain the owner of an object, the viewer must send a RequestObjectPropertiesFamily message and wait for an ObjectProperties reply. There's a significant amount of latency involved here -- it's the same thing that happens when you Edit an object and wait a moment before the "General" tab is populated. In order to implement Mute-By-Owner, the viewer would have to make this request for *every* object that it gets an ObjectUpdate message about. The patch already generates a good deal of extra ObjectUpdate traffic in order to trigger the initial muting / unmuting of an object, and adding this additional overhead would be simply untenable. Mute-By-Parcel is a nice idea, but it also has its share of complications. First and foremost is doing the work of figuring out if an object is in a given parcel or not. This in itself is not a trivial task, since parcels aren't always rectangular. Getting the border geometry of a parcel also requires a request and reply message from and two the viewer. Also, the viewer would probably have to request information for all the parcels in the agent's current draw distance. With a 16sqm minimum parcel size and a maximum draw distance of 512m, this is potentially a very large number of parcels. Basically what the viewer gets is a bounding rectangle for a parcel, and then a bitmapped array indicating which of the 16sqm subplots within that rectangle actually belong to that particular parcel. While doing an "is this object in that parcel" determination isn't terribly difficult, it's not trivial, and it would have to be done for every N objects in the viewer's object list, against M parcels in the agent's draw distance, which is potentially a lot of extra work. On top of all that, there's the problem with tracking objects that are moved into a parcel but not necessarily initially rezzed within that parcel. Simply matching an object to a parcel isn't enough, because vehicles or other moving objects which happen to cross into a parcel that is muted would become muted when they entered, and unmuted when they left. This isn't an ideal situation, so the viewer would also have to track whether an object started out in a muted parcel or not. It's also worth considering whether parcel muting should go "all the way up" or only cover objects rezzed below the map limit (400m). As I've said before, Mute-By-ObjectID is a useful approach, but ultimately one that can be defeated by clever scripting, since object IDs change whenever an object is rezzed by an agent or by a script. At any rate, it was a thoroughly interesting (if sometimes desperately frustrating) experience even getting this far with the visibility muting idea. I'd love to have a few adventurous people give it a whirl and then give me their feedback when I've got the proof-of-concept patch ready. Cheers, --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/984969f6/attachment-0001.htm From okumoto at ucsd.edu Wed Jun 20 23:14:29 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Wed Jun 20 23:14:32 2007 Subject: [sldev] Can someone clarify the object naming conventions llvosky.h vs llsky.h Message-ID: <467A1745.7010302@ucsd.edu> Hi, Can someone at LL explain the llvosky.h vs llsky.h naming convention? My cpu profiling says that LLVOSky::calcSkyColorInDir() is consuming about 5%, so I have started seeing if I can speed it up. Max From okumoto at ucsd.edu Thu Jun 21 00:26:47 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Thu Jun 21 00:26:50 2007 Subject: [sldev] Source release for 1.18.0.0 Message-ID: <467A2837.8040001@ucsd.edu> Hi Anthony, It looks like 1.18.0.0 is missing scripts/template_verifier.py is there anyway you could post this file to the list? Max Did anyone try this yet under Windows? ------ Build started: Project: newview, Configuration: ReleaseForDownload Win32 ------ Executing pre-build batch file '"../../scripts/template_verifier.py"' is not recognized as an internal or external command, operable program or batch file. PREBUILD FAILED newview : error PRJ0002 : error result returned from 'w:\sl1_18_0_0\linden\indra\newview\ReleaseForDownload\BAT00002E.bat'. Nick -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/b323f184/attachment.htm From jhurliman at wsu.edu Thu Jun 21 00:50:04 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Jun 21 00:49:59 2007 Subject: [sldev] Possible 3rd party contract for viewer modification In-Reply-To: <4679CEA6.2000803@gwala.net> References: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> <4679CEA6.2000803@gwala.net> Message-ID: <467A2DAC.5070602@wsu.edu> I know I have a biased opinion on this, but I would have to agree either way. A farm of machines running a 3D client to upload images doesn't make a whole lot of sense, plus you can tweak with some things in libsecondlife that allow you to upload images faster while using less bandwidth in the process. John Adam Frisby wrote: > This is probably better served with a libsl based bot to be honest. > > Hacking up a client to do it would be messy at best and libsl already > has appropriate asset upload functions inplace that would turn it into > a 15 line C# application (plus libsl is easier to maintain than a > custom viewer fork) > > Adam > > Soft Linden wrote: >> A company with a significant in-world presence has approached Linden >> Lab about the best way to upload a very, very large number of images >> in Second Life. The viewer is useful for uploading small batches of >> images, but nothing like the number they've asked about. >> >> To me, what would make sense would be a patch to the viewer that can >> read image URLs from a database, grab images via curl, and post the >> asset IDs of successful uploads back to the database. Ideally, this >> would let them run a small farm of machines chewing through the image >> set. I'm suggesting we propose this to them, and their likely next >> question would be who could make such a patch to the viewer. >> >> If you're interested in being named, please write me off-list with >> contact information and a paragraph or two that you'd like to be >> passed on. I can't be a running intermediary, but I'll gladly >> facilitate the initial connection. I'm also going to point them at our >> developer page for a list of possible candidates: >> http://secondlife.com/developers/listings.php?category=SoftwareDeveloper >> >> Also, if you're not listed above but you'd like to be, consider >> filling out the form here. If you've had patches accepted in the past, >> the form should be all you need in order to be listed: >> http://secondlife.com/developers/submission.php >> >> I'd love to get one of our existing contributors on this. :) >> _______________________________________________ >> 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 blakar at gmail.com Thu Jun 21 01:20:01 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Jun 21 01:20:03 2007 Subject: [sldev] Possible 3rd party contract for viewer modification In-Reply-To: <467A2DAC.5070602@wsu.edu> References: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> <4679CEA6.2000803@gwala.net> <467A2DAC.5070602@wsu.edu> Message-ID: <7992d0d60706210120g562653b4kde70786fc37bb35d@mail.gmail.com> It's strange that it's even considered to do this with a modified viewer. A single CPU client with multiple threads running of a dedicated program could fill it's bandwidth with uploads with ease. On top of that it would be a lot easier to write and cheaper to run. Dirk aka Blakar Ogre On 6/21/07, John Hurliman wrote: > I know I have a biased opinion on this, but I would have to agree either > way. A farm of machines running a 3D client to upload images doesn't > make a whole lot of sense, plus you can tweak with some things in > libsecondlife that allow you to upload images faster while using less > bandwidth in the process. > > John > > Adam Frisby wrote: > > This is probably better served with a libsl based bot to be honest. > > > > Hacking up a client to do it would be messy at best and libsl already > > has appropriate asset upload functions inplace that would turn it into > > a 15 line C# application (plus libsl is easier to maintain than a > > custom viewer fork) > > > > Adam > > > > Soft Linden wrote: > >> A company with a significant in-world presence has approached Linden > >> Lab about the best way to upload a very, very large number of images > >> in Second Life. The viewer is useful for uploading small batches of > >> images, but nothing like the number they've asked about. > >> > >> To me, what would make sense would be a patch to the viewer that can > >> read image URLs from a database, grab images via curl, and post the > >> asset IDs of successful uploads back to the database. Ideally, this > >> would let them run a small farm of machines chewing through the image > >> set. I'm suggesting we propose this to them, and their likely next > >> question would be who could make such a patch to the viewer. > >> > >> If you're interested in being named, please write me off-list with > >> contact information and a paragraph or two that you'd like to be > >> passed on. I can't be a running intermediary, but I'll gladly > >> facilitate the initial connection. I'm also going to point them at our > >> developer page for a list of possible candidates: > >> http://secondlife.com/developers/listings.php?category=SoftwareDeveloper > >> > >> Also, if you're not listed above but you'd like to be, consider > >> filling out the form here. If you've had patches accepted in the past, > >> the form should be all you need in order to be listed: > >> http://secondlife.com/developers/submission.php > >> > >> I'd love to get one of our existing contributors on this. :) > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nicholaz at blueflash.cc Thu Jun 21 01:53:52 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 21 01:54:11 2007 Subject: [sldev] Can someone clarify the object naming conventions llvosky.h vs llsky.h In-Reply-To: <467A1745.7010302@ucsd.edu> References: <467A1745.7010302@ucsd.edu> Message-ID: <467A3CA0.9030509@blueflash.cc> Just off hand and without looking deeper, I think the "VO" stands for Viewer-Object (think these are derived from LLViewerObject) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Max Okumoto wrote: > Hi, > > Can someone at LL explain the llvosky.h vs llsky.h naming convention? > > My cpu profiling says that LLVOSky::calcSkyColorInDir() is consuming > about 5%, so I have started seeing if I can speed it up. > > Max > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From blakar at gmail.com Thu Jun 21 02:34:42 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Jun 21 02:34:45 2007 Subject: [sldev] getting serious about software. In-Reply-To: <4679EAC2.3060604@speakeasy.net> References: <4679EAC2.3060604@speakeasy.net> Message-ID: <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> You do realise SL spends a lot of time on math? It's a 3D application, not an OS. If you audit the code for "what is necessary" you'll hardly have any speed up because cutting the math means cutting a feature. Sure you can discuss whether the effect of that feature is worth its cost in CPU time but it's not stray or redundant code. For the libraries we have the same issue. Which libraries are eating cycles? Again those doing lots of math. What they do is again necessary so an audit will keep them. You may upgrade to a newer version but it'll never yield big results. My personal approach to optimisation for this kind of application is: --- avoid complex math where possible --- This can be achieved in several ways. A few examples: * Hard code all numbers that are known in advance (sometimes still beaten by custom asm if CPU knows these numbers) * Make sure your code has short cuts for the most used calculations (if something gets called 90% of the time with the same parameters it should have the result hard coded and only perform the calculation in the other cases) * Cache results if they are calculated over and over (if you know that at a certain point in time you call the same function with the same input a lot you should make it possible for it to return one of the recent results). * Abuse your knowledge on IEEE numbers, numbers are still based on bits you can directly manipulate (create custom code for things that can be done by bypassing true math) * Make sure what you're doing is the most efficient mathematical way to achieve your goal. If you calculate things in a long winded way the compiler will never optimise this as it has little to no clue on math rules. --- redesign complex systems --- Some code may yield the wished for (mathematical) result but you could've achieved something with similar accuracy with a lot less hassle. Compression is an example. Your compression algorithm should be so that it gives you the best balance between speed and space. If 10% more compression costs you 50% more time then there's little reason to do so. --- Write custom code for your math --- All modern CPU's support SIMD instructions aimed at 3D. Compilers don't convert your vector math for you, you need to do it yourself. To do all of the above in the most efficient way you're best off taking a profiler and checking whether what is using the CPU does fall within the things defined above. The above is not an exhaustive list it's just an ordered list of what I can think of at the moment. Note also that in the end doing customisation geared towards chips is _fun_ for some of us. I've for example replaced one of the functions with a piece of custom asm that is 70x faster than the current code while yielding the exact same result. I don't care that the code will probably mean no more than 0.1% increase in speed overall. I bumped into it and though "no way that this is efficient". A bit of thinking later I had created a neat trick based on how IEEE numbers are stored and it made my day. Kind regards, Dirk aka Blakar Ogre > I am becoming increasingly distressed about all this focus on chip-level > optimizations. At best we're talking about a speedup of around 1.3. > Auditing the code would probably close 2/3rds the open bug reports and > yield a speedup between 5 and 10 times. > > Here are a few articles. of interest: > > http://www.eros-os.org/essays/reliability/paper.html > > The lesson I take from Eros is that to make a piece of software FAST, > you first put all your effort into making it verifiably reliable and > removing every stray and redundant line of code you can find. > > Next, Examine how your app interacts with the libraries on your system, > are you using the right libraries? are you taking full advantage of the > library's features? > > Once you've done that, go to the manufacturer's performance manuals: > > http://developer.amd.com/devguides.jsp > > These manuals tell you how best to use the language and the compiler to > generate more efficient binaries before writing off any CPUs. > > next, you identify the most performance critical modules and generate > dynamic libraries compiled for each of the major architectures. > > Finally, if you still need more that your compiler can't give you, you > write assembly language kernels for the stuff that absolutely positively > needs to be screaming fast and the code the compiler makes blows donky > chunks. > > -- > Opera: Sing it loud! :o( )>-< > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nicholaz at blueflash.cc Thu Jun 21 03:59:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 21 04:00:05 2007 Subject: [sldev] getting serious about software. In-Reply-To: <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> Message-ID: <467A5A06.4050609@blueflash.cc> Dirk Moerenhout wrote: > Note also that in the end doing customisation geared towards chips is > _fun_ for some of us. I've for example replaced one of the functions > with a piece of custom asm that is 70x faster than the current code > while yielding the exact same result. I don't care that the code will > probably mean no more than 0.1% increase in speed overall. I bumped > into it and though "no way that this is efficient". A bit of thinking > later I had created a neat trick based on how IEEE numbers are stored > and it made my day. I can fully relate to that part. It's the same with me and bug fixing. Fixinig bugs may be the most horrible task some people can think of, but for me it's a nice intellectual challenge ... like solving a Sudoku and you probably can't imagine how happy it makes me to see large chunks of leftover memory being gone from the leak dump (even if it's clear that it has zero practical impact). Nick From kerdezixe at gmail.com Thu Jun 21 05:01:38 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Thu Jun 21 05:01:40 2007 Subject: [sldev] getting serious about software. In-Reply-To: <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> Message-ID: <8a1bfe660706210501p555186dfo8eb0329854a7ac74@mail.gmail.com> On 6/21/07, Dirk Moerenhout wrote: > > Note also that in the end doing customisation geared towards chips is > _fun_ for some of us. I've for example replaced one of the functions > with a piece of custom asm that is 70x faster than the current code > while yielding the exact same result. I don't care that the code will > probably mean no more than 0.1% increase in speed overall. I bumped > into it and though "no way that this is efficient". A bit of thinking > later I had created a neat trick based on how IEEE numbers are stored > and it made my day. Hi, it's exactly my point in the SSE/2/3 optimisation (and mac'tel) thread. It is opensource. People, coder, work on what they want to do. We don't care if it is a 0.1%, or a 0.01% optimisation ... if he spent 1mn or 1 weeks on it ... He made it, he probably had fun to do it, ... We have no right to tell him "stop working on something you like to do and do instead", unless he's paid for that, of course, but he's not :) I'm that kind of volunteer. Sadly... The secondlife client is too complex for me and my coder's skills. I'm a poor sysadmin waiting for the server's code release so i can spend a great amount of energy optimising the server architecture. I could spend weeks to tweak the filesystem usage and parameters, tuning the kernel configuration, ... not because it's needed (it's certainly not the bottleneck on servers) but because i have fun doing that and it will make my day :) -- kerunix Flan From nicholaz at blueflash.cc Thu Jun 21 05:31:18 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 21 05:31:35 2007 Subject: [sldev] More on Mute Visibility In-Reply-To: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> Message-ID: <467A6F96.6020307@blueflash.cc> Wow Able, now that sounds like hours of extensive research and work :-) I think the conlusions about parcels are interesting, pity that this road seems closed for the moment. I'm currently thinking about giving it a try in my viewer build, but one of the things I can't (don't want to) do is to mod the the XML/GUI files (my viewer just is installed as a separate exe and doesn't touch anything inside the SL program folder). Do you think there would be a version of your hack with reasonable impact on the source, just based on the regular Mute function? I'm just thinking of the basic visibility functions, hoping that these would affect just a few points in the source? > 4. Phantom objects are made completely transparent. > 5. Non-phantom objects are made 67% transparent. > 11. Objects have their angular velocity (llTargetOmega) forced to zero. And these just depending how complex their implementations are? > 6. Attached sounds on the object have their gain forced to zero. > 7. Hovering text on the object is removed. > 8. Objects have their light source and fullbright settings turned off. > 9. Touchable objects have their click action removed. I'd then make a build and offer it to users to just gain a bit of feedback (although I fear that opening that door a bit might eat us alive with requests for more). Nick Able Whitman wrote: > Howdy, > > On and off, I've been investigating the feasibility of implementing > "Visibility Muting" as Nicholaz describes in VWR-1017 > (https://jira.secondlife.com/browse/VWR-1017 > ), and as discussed in a > few threads on this list. I'm pretty close to having a proof-of-concept > patch ready which adds the ability to mute the visibility of objects by > their ID, in much the same fashion that the existing chat muting > function works. > > I'd like to know if anyone would be interested it testing the patch > which, I assure you, is rather rough around the edges. This is mainly > because I cobbled it together as I was learning how the visibility > muting needs to interact with object update messages and with the > rendering pipeline. But it works pretty well, at least for me. > > Since there was a fair amount of interest the last couple of times this > topic came up, I thought I'd share some of what I learned during my > investigation. If you're not interested or don't care, I won't be > offended if you mute this thread. :) > > The patch will add a new object pie menu item next to the existing "Mute > / Unmute" item, named "Mute / Unmute Visibility". > > This is what the patch endeavors to do when an object's visibility is > muted: > 1. The object is also muted "classically," that is, its chat is > suppressed, just as with a normal mute. > 2. Any particle system associated with the object is removed, just as > with a normal mute. > 3. All the textures on the object are replaced with a solid-white > texture. > 4. Phantom objects are made completely transparent. > 5. Non-phantom objects are made 67% transparent. (They are not made > entirely transparent because I believe that object collision happens in > part on the server, so avatars would still run into them. This way they > are at least visible enough to avoid.) > 6. Attached sounds on the object have their gain forced to zero. > 7. Hovering text on the object is removed. > 8. Objects have their light source and fullbright settings turned off. > 9. Touchable objects have their click action removed. > 10. Objects for sale are not purchasable. > 11. Objects have their angular velocity (llTargetOmega) forced to zero. > > If a muted object is part of a link set, all objects in the set are also > visibly muted. At the moment, only LLVOVolume objects are visibly > mutable; so you can't visibly mute things like avatars, trees, the > ground, the sky, etc. > > The patch works by extending the existing mute list capability of the > viewer, adding a new OBJECTVISIBLE mute type. There are a lot of places > in the LLPrimitive, LLViewerObject, and LLVOVolume classes (more than I > expected) that are hooked into altering their behavior when an object is > muted. There are portions of this patch that I am not at all happy with > because they're quite a hack, but now that I know what I'm doing (more > or less), I think the implementation can be much improved. > > A few observations from testing visibility muting so far: > > 1. It is possible to mute buildings -- houses, clubs, skyboxes, etc. > This seems like an obvious statement, but I hadn't considered the > implications of it until I tried muting my house. At first this was > mildly amusing, but it does raise some very important privacy concerns. > > 2. Muting lots of individual, unlinked objects -- like lots of ad > cubes or billboards or whatever -- is a pain. I might jam in a Client > menu item and a keyboard accelerator, just because clicking the object > pie menus over and over is really annoying. > > 3. It really, really reduces visual clutter. There's no question that > visibility muting, even in this rough form, is very helpful at > eliminating clutter and spam from ad prims and the like. Even though you > wind up with a bunch of semi-transparent cubes hovering around, it's a > huge improvement. > > I also learned some things about the feasibility of doing visibility > muting by-owner or by-parcel: > > Mute-By-Owner is a nice idea, technically possible, but a bad way to go. > > The problem is that the owner information is not included in the > ObjectUpdate message (or any of the related Update messages). In order > to ascertain the owner of an object, the viewer must send a > RequestObjectPropertiesFamily message and wait for an ObjectProperties > reply. > > There's a significant amount of latency involved here -- it's the same > thing that happens when you Edit an object and wait a moment before the > "General" tab is populated. In order to implement Mute-By-Owner, the > viewer would have to make this request for *every* object that it gets > an ObjectUpdate message about. The patch already generates a good deal > of extra ObjectUpdate traffic in order to trigger the initial muting / > unmuting of an object, and adding this additional overhead would be > simply untenable. > > Mute-By-Parcel is a nice idea, but it also has its share of complications. > > First and foremost is doing the work of figuring out if an object is in > a given parcel or not. This in itself is not a trivial task, since > parcels aren't always rectangular. Getting the border geometry of a > parcel also requires a request and reply message from and two the viewer. > > Also, the viewer would probably have to request information for all the > parcels in the agent's current draw distance. With a 16sqm minimum > parcel size and a maximum draw distance of 512m, this is potentially a > very large number of parcels. > > Basically what the viewer gets is a bounding rectangle for a parcel, and > then a bitmapped array indicating which of the 16sqm subplots within > that rectangle actually belong to that particular parcel. While doing an > "is this object in that parcel" determination isn't terribly difficult, > it's not trivial, and it would have to be done for every N objects in > the viewer's object list, against M parcels in the agent's draw > distance, which is potentially a lot of extra work. > > On top of all that, there's the problem with tracking objects that are > moved into a parcel but not necessarily initially rezzed within that > parcel. Simply matching an object to a parcel isn't enough, because > vehicles or other moving objects which happen to cross into a parcel > that is muted would become muted when they entered, and unmuted when > they left. This isn't an ideal situation, so the viewer would also have > to track whether an object started out in a muted parcel or not. It's > also worth considering whether parcel muting should go "all the way up" > or only cover objects rezzed below the map limit (400m). > > As I've said before, Mute-By-ObjectID is a useful approach, but > ultimately one that can be defeated by clever scripting, since object > IDs change whenever an object is rezzed by an agent or by a script. > > At any rate, it was a thoroughly interesting (if sometimes desperately > frustrating) experience even getting this far with the visibility muting > idea. I'd love to have a few adventurous people give it a whirl and then > give me their feedback when I've got the proof-of-concept patch ready. > > Cheers, > --Able > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From soft at lindenlab.com Thu Jun 21 07:20:53 2007 From: soft at lindenlab.com (Soft Linden) Date: Thu Jun 21 07:20:54 2007 Subject: [sldev] Second Life - Intel Software Zone Events on Thursday In-Reply-To: <9e6e5c9e0706210606m6800d3afq8524fc5dfea47d01@mail.gmail.com> References: <9e6e5c9e0706210606m6800d3afq8524fc5dfea47d01@mail.gmail.com> Message-ID: <9e6e5c9e0706210720v24782833nf1be083beead8624@mail.gmail.com> One or both of these may be of interest to sldev members. These are in-world taking place today. Intel Compilers Q&A Session with Joe Wolf, Intel Compiler Team Manager Thursday, June 21 4:00 PM SLT (PST) Talk + Q&A discussion. Everything you wanted to know about Intel Compilers. Intel Threading Guru ? Clay Breshears Thursday, June 21 5:00 PM SLT (PST) Clay is Sr. Course architect, Intel Software College Talk with Clay about your threading issues or where the industry is headed regarding multicores and parallelism. http://tinyurl.com/34chl9 From secret.argent at gmail.com Thu Jun 21 07:24:50 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 21 07:24:51 2007 Subject: [sldev] Re: getting serious about software. In-Reply-To: <20070621044423.0356D41B0E1@stupor.lindenlab.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> Message-ID: <101CB0F3-3C56-442E-AF37-3D5E59031867@gmail.com> I got the impression that this was mostly a matter of picking the right compiler flags, rather than a significant amount of recoding. If you can get a 30% performance boost from that, then generating multiple binaries is a no-brainer. If we're talking about actually changing code, I absolutely agree there's better places to start. (getting some of this open-source attention on the server code, for example) (whoops, did I say that out loud) From able.whitman at gmail.com Thu Jun 21 07:27:31 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 21 07:27:34 2007 Subject: [sldev] More on Mute Visibility In-Reply-To: <467A6F96.6020307@blueflash.cc> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> <467A6F96.6020307@blueflash.cc> Message-ID: <7b3a84fb0706210727w54fe2245obc7a462f8ce2b3eb@mail.gmail.com> Thanks, Nick! I originally intended only to figure out how to extend the existing mute list functionality, but, well, I got a bit carried away. :) I think the conlusions about parcels are interesting, pity that > this road seems closed for the moment. Actually, after I sent the email out, I did some tinkering with the viewer code that's responsible for drawing parcel borders. This already does some pieces of what mute-by-parcel would require, at least in terms of reqesting and storing parcel boundary information. I'll have to do some poking around to see if a similar technique can be used for muting. I'm currently thinking about giving it a try in my viewer build, > but one of the things I can't (don't want to) do is to mod the > the XML/GUI files (my viewer just is installed as a separate > exe and doesn't touch anything inside the SL program folder). It would be very simple to just replace the existing mute functionality with mute visbility instead, and leave the menus alone. That would require changes to the code that hooks up the menu handlers, but wouldn't touch the XML. Do you think there would be a version of your hack with reasonable > impact on the source, just based on the regular Mute function? > > I'm just thinking of the basic visibility functions, hoping that > these would affect just a few points in the source? This sort of gets into why my current patch isn't really the best solution. I took a rather brute-force approach to forcing the effects of visibility muting, and I added code to special-case all the visbility properties of an object wherever it seemed like they could be manipulated. The result, while pretty effective, is inelegant at best. If I was updating this patch for submission, I'd take the time to go through all the tweaks and leave in only the ones that are absolutely necessary. I understand if you'd prefer to have fewer changes to the source, but I would prefer to put off the pruning until I get some more feedback. :) A lot of the hacks I used stem from the fact that there are 3 different messages the viewer can receive when an object is updated. There's essentially a single event handler which updates the object properties based on these messages, and it has a lot of special-cased code depending on the message type, since they're all decoded differently. In some places, I tweaked the getter/setter accessor functions for some properties. When that didn't work, or wasn't possible, I tweaked the message handlers themselves. And if *that* didn't work, I tweaked other things, even though I'm pretty sure there are better ways of handling the probelm. So right now it's a bit of a hodgepodge of tweaks. > I'd then make a build and offer it to users to just gain a bit > of feedback (although I fear that opening that door a bit might > eat us alive with requests for more). Well, I think I fixed the last crashing bug in my current patch. Right now, I'm trying to track down a couple fiddly issues, but when I get a chance to generate a diff based on what I currently have, I'll send it to you. Then and you can judge whether it's something you'd feel comfortable putting in your viewer or not. :) --Able > Able Whitman wrote: > > Howdy, > > > > On and off, I've been investigating the feasibility of implementing > > "Visibility Muting" as Nicholaz describes in VWR-1017 > > (https://jira.secondlife.com/browse/VWR-1017 > > ), and as discussed in a > > few threads on this list. I'm pretty close to having a proof-of-concept > > patch ready which adds the ability to mute the visibility of objects by > > their ID, in much the same fashion that the existing chat muting > > function works. > > > > I'd like to know if anyone would be interested it testing the patch > > which, I assure you, is rather rough around the edges. This is mainly > > because I cobbled it together as I was learning how the visibility > > muting needs to interact with object update messages and with the > > rendering pipeline. But it works pretty well, at least for me. > > > > Since there was a fair amount of interest the last couple of times this > > topic came up, I thought I'd share some of what I learned during my > > investigation. If you're not interested or don't care, I won't be > > offended if you mute this thread. :) > > > > The patch will add a new object pie menu item next to the existing "Mute > > / Unmute" item, named "Mute / Unmute Visibility". > > > > This is what the patch endeavors to do when an object's visibility is > > muted: > > 1. The object is also muted "classically," that is, its chat is > > suppressed, just as with a normal mute. > > 2. Any particle system associated with the object is removed, just as > > with a normal mute. > > 3. All the textures on the object are replaced with a solid-white > > texture. > > 4. Phantom objects are made completely transparent. > > 5. Non-phantom objects are made 67% transparent. (They are not made > > entirely transparent because I believe that object collision happens in > > part on the server, so avatars would still run into them. This way they > > are at least visible enough to avoid.) > > 6. Attached sounds on the object have their gain forced to zero. > > 7. Hovering text on the object is removed. > > 8. Objects have their light source and fullbright settings turned > off. > > 9. Touchable objects have their click action removed. > > 10. Objects for sale are not purchasable. > > 11. Objects have their angular velocity (llTargetOmega) forced to > zero. > > > > If a muted object is part of a link set, all objects in the set are also > > visibly muted. At the moment, only LLVOVolume objects are visibly > > mutable; so you can't visibly mute things like avatars, trees, the > > ground, the sky, etc. > > > > The patch works by extending the existing mute list capability of the > > viewer, adding a new OBJECTVISIBLE mute type. There are a lot of places > > in the LLPrimitive, LLViewerObject, and LLVOVolume classes (more than I > > expected) that are hooked into altering their behavior when an object is > > muted. There are portions of this patch that I am not at all happy with > > because they're quite a hack, but now that I know what I'm doing (more > > or less), I think the implementation can be much improved. > > > > A few observations from testing visibility muting so far: > > > > 1. It is possible to mute buildings -- houses, clubs, skyboxes, etc. > > This seems like an obvious statement, but I hadn't considered the > > implications of it until I tried muting my house. At first this was > > mildly amusing, but it does raise some very important privacy concerns. > > > > 2. Muting lots of individual, unlinked objects -- like lots of ad > > cubes or billboards or whatever -- is a pain. I might jam in a Client > > menu item and a keyboard accelerator, just because clicking the object > > pie menus over and over is really annoying. > > > > 3. It really, really reduces visual clutter. There's no question that > > visibility muting, even in this rough form, is very helpful at > > eliminating clutter and spam from ad prims and the like. Even though you > > wind up with a bunch of semi-transparent cubes hovering around, it's a > > huge improvement. > > > > I also learned some things about the feasibility of doing visibility > > muting by-owner or by-parcel: > > > > Mute-By-Owner is a nice idea, technically possible, but a bad way to go. > > > > The problem is that the owner information is not included in the > > ObjectUpdate message (or any of the related Update messages). In order > > to ascertain the owner of an object, the viewer must send a > > RequestObjectPropertiesFamily message and wait for an ObjectProperties > > reply. > > > > There's a significant amount of latency involved here -- it's the same > > thing that happens when you Edit an object and wait a moment before the > > "General" tab is populated. In order to implement Mute-By-Owner, the > > viewer would have to make this request for *every* object that it gets > > an ObjectUpdate message about. The patch already generates a good deal > > of extra ObjectUpdate traffic in order to trigger the initial muting / > > unmuting of an object, and adding this additional overhead would be > > simply untenable. > > > > Mute-By-Parcel is a nice idea, but it also has its share of > complications. > > > > First and foremost is doing the work of figuring out if an object is in > > a given parcel or not. This in itself is not a trivial task, since > > parcels aren't always rectangular. Getting the border geometry of a > > parcel also requires a request and reply message from and two the > viewer. > > > > Also, the viewer would probably have to request information for all the > > parcels in the agent's current draw distance. With a 16sqm minimum > > parcel size and a maximum draw distance of 512m, this is potentially a > > very large number of parcels. > > > > Basically what the viewer gets is a bounding rectangle for a parcel, and > > then a bitmapped array indicating which of the 16sqm subplots within > > that rectangle actually belong to that particular parcel. While doing an > > "is this object in that parcel" determination isn't terribly difficult, > > it's not trivial, and it would have to be done for every N objects in > > the viewer's object list, against M parcels in the agent's draw > > distance, which is potentially a lot of extra work. > > > > On top of all that, there's the problem with tracking objects that are > > moved into a parcel but not necessarily initially rezzed within that > > parcel. Simply matching an object to a parcel isn't enough, because > > vehicles or other moving objects which happen to cross into a parcel > > that is muted would become muted when they entered, and unmuted when > > they left. This isn't an ideal situation, so the viewer would also have > > to track whether an object started out in a muted parcel or not. It's > > also worth considering whether parcel muting should go "all the way up" > > or only cover objects rezzed below the map limit (400m). > > > > As I've said before, Mute-By-ObjectID is a useful approach, but > > ultimately one that can be defeated by clever scripting, since object > > IDs change whenever an object is rezzed by an agent or by a script. > > > > At any rate, it was a thoroughly interesting (if sometimes desperately > > frustrating) experience even getting this far with the visibility muting > > idea. I'd love to have a few adventurous people give it a whirl and then > > give me their feedback when I've got the proof-of-concept patch ready. > > > > Cheers, > > --Able > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/506cb617/attachment-0001.htm From soft at lindenlab.com Thu Jun 21 07:29:49 2007 From: soft at lindenlab.com (Soft Linden) Date: Thu Jun 21 07:29:51 2007 Subject: [sldev] Possible 3rd party contract for viewer modification In-Reply-To: <4679CEA6.2000803@gwala.net> References: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> <4679CEA6.2000803@gwala.net> Message-ID: <9e6e5c9e0706210729n3c3e5094rbbd9eddda44911f1@mail.gmail.com> I expect you're right! I tend to go with what I know, and a viewer change is a shallow problem for me, while I'd have to learn C# and libsl for the other. I'd think the same were true of many on the list. That said, so long as I'm convinced of the ability to deliver, I'm comfortable making a connection regardless of what tools you want to use. I certainly have no doubts at all as to whether the libsl developers could deliver -- they've got a pretty solid track record. On 6/20/07, Adam Frisby wrote: > This is probably better served with a libsl based bot to be honest. > > Hacking up a client to do it would be messy at best and libsl already > has appropriate asset upload functions inplace that would turn it into a > 15 line C# application (plus libsl is easier to maintain than a custom > viewer fork) > > Adam From alissa_sabre at yahoo.co.jp Thu Jun 21 07:34:23 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Thu Jun 21 07:34:45 2007 Subject: [sldev] Wiki Formatting In-Reply-To: <466DB287.1030407@blueflash.cc> References: <466DB287.1030407@blueflash.cc> Message-ID: <1m9Pdv4dx4t2otmh6uwwk7e.alissa_sabre@yahoo.co.jp> > Is there an "official" way to insert forced blank lines into the wiki? I believe there is no official way (see below), but I will use "
" if I were to make a persistent empty line. > I noticed with the longer documents (like the VS2003 / VS2005 instructions) > that editing a section (the [edit] link next to a header) removes empty > lines and pushes the headings very close to the previous paragraph. I don't recommend such an ad hoc adjustment. If a heading and the preceding paragraph is too close, I believe it's better to update stylesheet appropriately to make more space there rather than to manually insert blank lines. The best practice is to edit MediaWiki:Monobook.css, but it is not allowed for ordinary users. We need to ask Rob or somebody else in LL. BTW, I don't think the current break between the last paragraph and a heading is too close, either. But, yes, it's a subjective matter and I have no objection to the idea to make the gap wider. Alissa -------------------------------------- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ From secret.argent at gmail.com Thu Jun 21 07:45:51 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 21 07:45:56 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <20070621044423.0356D41B0E1@stupor.lindenlab.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> Message-ID: <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> > 3. All the textures on the object are replaced with a solid- > white texture. I suggest using "smoke", which is the old "loading texture", instead. > 1. It is possible to mute buildings -- houses, clubs, skyboxes, > etc. This > seems like an obvious statement, but I hadn't considered the > implications of > it until I tried muting my house. At first this was mildly amusing, > but it > does raise some very important privacy concerns. Not really. There's nothing this lets you do that "disable camera constraints" doesn't let you do already. > 2. Muting lots of individual, unlinked objects -- like lots of > ad cubes > or billboards or whatever -- is a pain. I might jam in a Client > menu item > and a keyboard accelerator, just because clicking the object pie > menus over > and over is really annoying. "Mute selected" "Mute all objects in selected land" > Getting the border geometry of a parcel also requires a request and > reply message from and two the viewer. If you have an area selected, you have that. If you haven't swept an area out, or are just looking at the land info rather than the editor, that will be the whole parcel. That will also significantly reduce the complexity of the process. I think that for a first pass, mute by object ID and having "selected" and "selected land" as methods of grabbing a lot of object IDs at once is plenty. It would also be interesting to have "listen to mute requests on 'channel'", with appropriate checks (eg, fetch the owner of the object sending the message and ignore it if it's not owned by you or by the owner of the land you're on) so you could have an in-world object doing something like this: sensor(integer n) { integer i; for(i = 0; i < n; i++) { key k = llDetectedKey(i); if(shouldBeMuted(k)) { if(llListFindList(alreadyMuted,[k]) == -1) { alreadyMuted += [llTime()+TIMEOUT,k]; llSay(CHANNEL, (string)k); } } } } timer() { integer n = llGetListLength(alreadyMuted); integer i; float t = llTime(); list l = []; for(i = 0; i < n; i+= 2) { if(llList2Float(alreadyMuted,i) > t) { l += llList2List(alreadyMuted, i, i+1); } } alreadyMuted = l; } From secret.argent at gmail.com Thu Jun 21 07:51:59 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 21 07:52:01 2007 Subject: [sldev] Re: getting serious about software. In-Reply-To: <20070621120143.3033441B08F@stupor.lindenlab.com> References: <20070621120143.3033441B08F@stupor.lindenlab.com> Message-ID: <6DEF5117-7DCF-408D-8CB5-94774A7B556D@gmail.com> > * Cache results if they are calculated over and over (if you know that > at a certain point in time you call the same function with the same > input a lot you should make it possible for it to return one of the > recent results). There are techniques to do this routinely. I think the googlable term is "memoization". http://en.wikipedia.org/wiki/Memoization And don't forget, "Almost all programming can be viewed as an exercise in caching." From brad at lindenlab.com Thu Jun 21 08:35:05 2007 From: brad at lindenlab.com (Brad Linden) Date: Thu Jun 21 08:35:18 2007 Subject: [sldev] Can someone clarify the object naming conventions llvosky.h vs llsky.h In-Reply-To: <467A3CA0.9030509@blueflash.cc> References: <467A1745.7010302@ucsd.edu> <467A3CA0.9030509@blueflash.cc> Message-ID: <467A9AA9.90507@lindenlab.com> First, a real short introduction: I'm Brad Linden and joined the Boston area office of Linden Lab last month. I've been working on WindLight (available at http://svn.secondlife.com/svn/linden/branches/2007/windlight_1-17-0/). You can see Zen's blog post (http://blog.secondlife.com/2007/06/14/windlight-update/) and Torley's post (http://blog.secondlife.com/2007/05/21/windlight-atmospheric-rendering-comes-to-second-life/) for more details. Nicholaz Beresford wrote: > > Just off hand and without looking deeper, I think > the "VO" stands for Viewer-Object (think these > are derived from LLViewerObject) > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > That is correct. The LLSky class is a global singleton (gSky) for managing access to anything related to the sky, including the LLVOSky instance (gSky.mVOSkyp). > Max Okumoto wrote: >> Hi, >> >> Can someone at LL explain the llvosky.h vs llsky.h naming convention? >> >> My cpu profiling says that LLVOSky::calcSkyColorInDir() is consuming >> about 5%, so I have started seeing if I can speed it up. >> >> Max You might want to wait before spending too much time on that, or at least not work on that branch. If you look at the WindLight branch you'll see that that function has been completely replaced with something much more cpu-intensive, but updated less frequently. It's essentially a straightforward attempt at imitating the WindLight sky glsl shaders in indra/newview/app_settings/shaders/class2/windlight/WLSkyV.glsl and indra/newview/app_settings/shaders/class2/windlight/WLSkyF.glsl. If you want to try to optimize the sky CPU code, this branch is the place to do it, but take note that on systems that have a GPU and OpenGL drivers that can run WindLight, this code is obsoleted by the new LLVOWLSky class, and the LLVOSky class will be largely disabled (this is not happening properly in the snapshot we exported to the public svn server). As our focus has been on getting the new GPU rendered WindLight codepath working on as many hardware configurations as possible, the CPU rendering code in LLVOSky has not had as much attention, as it's really not suited for the way WindLight works and may need a complete refactoring, and there are major outstanding bugs in it: https://jira.secondlife.com/browse/VWR-980. Any contributions to the CPU fallback code in LLVOSky would be much appreciated. So in summary, if you want to work on sky code and get your code used after WindLight gets merged into the trunk, work in the WindLight branch. If you have questions about what you find there, I'm your man. hope this helps, -Brad Linden From nicholaz at blueflash.cc Thu Jun 21 08:51:44 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 21 08:52:06 2007 Subject: [sldev] Wiki Formatting In-Reply-To: <1m9Pdv4dx4t2otmh6uwwk7e.alissa_sabre@yahoo.co.jp> References: <466DB287.1030407@blueflash.cc> <1m9Pdv4dx4t2otmh6uwwk7e.alissa_sabre@yahoo.co.jp> Message-ID: <467A9E90.3070704@blueflash.cc> > BTW, I don't think the current break between the last paragraph and a > heading is too close, either. But, yes, it's a subjective matter and I > have no objection to the idea to make the gap wider. The current one is hand edited with
s ... the default (from the CSS) has practically no whitespace over the headlines. Nick From able.whitman at gmail.com Thu Jun 21 09:05:31 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 21 09:05:35 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> Message-ID: <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> > > I suggest using "smoke", which is the old "loading texture", instead. That's a good idea; I just chose the white texture rather arbitrarily. Not really. There's nothing this lets you do that "disable camera > constraints" doesn't let you do already. You're right, but how well-known is the "disable camera constraints" feature, versus the Mute feature? It's an unavoidable consequence of visibility muting, but I'm sure some people will complain about it, so I figured I would at least mention it. "Mute selected" > "Mute all objects in selected land" Is it possible to group select objects which aren't yours and which you don't have permission to edit? I thought the last time I tried (with "select only my objects" unchecked) it it didn't work, but I could be wrong. > Getting the border geometry of a parcel also requires a request and > > reply message from and two the viewer. > > If you have an area selected, you have that. If you haven't swept an > area out, or are just looking at the land info rather than the > editor, that will be the whole parcel. That will also significantly > reduce the complexity of the process. > > I think that for a first pass, mute by object ID and having > "selected" and "selected land" as methods of grabbing a lot of object > IDs at once is plenty. Yes, if there is a parcel selected, the viewer has its geometry, but I'm talking about determining the geometry after the parcel has been muted. I think you and I are just talking about different approaches to mute-by-parcel. You're suggesting that when the user mutes a parcel, the viewer mutes all the object IDs for objects it knows about that are in that parcel. The code I've written so far could be adapted to do just this without too much trouble, I think. I was thinking that when a user mutes a parcel, that parcel ID is added to the mute list, and then each time an object is updated, the viewer checks to see if it falls inside of a muted parcel and if it does, the object is muted. This is much more complicated than your approach, but it has a couple of advantages: 1. It's not dependent on object ID, which is easily mutable. 2. It will also mute objects in the parcel that are outside of the viewer's draw distance. 3. If new objects are placed in the parcel later, they will automatically be muted. Aside from being more complicated to implement, the by-parcel-ID approach raises the question of how to handle objects (liek vehicles) that are only transiently inside of a muted parcel. I'm not sure yet how to implement my version of mute-by-parcel, but I will take a shot at implementing yours, so at least we can get feedback about how it works in principle. It would also be interesting to have "listen to mute requests on > 'channel'", with appropriate checks (eg, fetch the owner of the > object sending the message and ignore it if it's not owned by you or > by the owner of the land you're on) so you could have an in-world > object doing something like this: That's a really interesting idea, but I'm not really keen about reserving a "special" chanel for only the viewer to listen on. Plus, which channel do you choose? It doesn't seem possible to guarantee that that the channel you pick won't already be used by some existing script somewhere. In practice this probably isn't an issue, but I'd much rather implement a scriptable muting mechanism in cooperation with server support for the feature. Then there can be a special message from the sim that tells the viewer "mute this object, please." -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/69fae9ec/attachment-0001.htm From secret.argent at gmail.com Thu Jun 21 09:45:43 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 21 09:45:53 2007 Subject: [sldev] Anyone seen MakeHuman? In-Reply-To: <20070621120143.3033441B08F@stupor.lindenlab.com> References: <20070621120143.3033441B08F@stupor.lindenlab.com> Message-ID: MakeHuman: http://www.dedalo-3d.com/index.php From alissa_sabre at yahoo.co.jp Thu Jun 21 09:53:54 2007 From: alissa_sabre at yahoo.co.jp (alissa_sabre@yahoo.co.jp) Date: Thu Jun 21 09:54:07 2007 Subject: [sldev] Discussion on fontconfig Message-ID: <99kwxdz4ftbds4Gfddsweza.alissa_sabre@yahoo.co.jp> As a follow up to the discussion a month ago (http://lists.secondlife.com/pipermail/sldev/2007-May/001869.html), I'm writing a wiki page on fontconfig. Please take a look at http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Notes_on_fontconfig if you are interested in font handling issues. Forgive me that it is not yet complete. Comments are appreciated. Alissa -------------------------------------- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ From dale at daleglass.net Thu Jun 21 09:59:49 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Thu Jun 21 09:59:56 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> Message-ID: <20070621165949.GA10612@bruno.sbruno> On Thu, Jun 21, 2007 at 12:05:31PM -0400, Able Whitman wrote: > Aside from being more complicated to implement, the by-parcel-ID approach > raises the question of how to handle objects (liek vehicles) that are only > transiently inside of a muted parcel. Idea: Mute gradually. As a vehicle enters a muted parcel, make it gradually vanish. Make it slow enough that a vehicle moving through the parcel wouldn't normally vanish completely before it gets to the other side. The only problem is that parcel sizes and vehicle sizes vary. You could make the fading speed be dependent on the parcel's size and vehicle's speed: Make it so that the time to fade completely is slightly more than the time needed to cross the parcel. > That's a really interesting idea, but I'm not really keen about reserving a > "special" chanel for only the viewer to listen on. Plus, which channel do > you choose? It doesn't seem possible to guarantee that that the channel you > pick won't already be used by some existing script somewhere. In practice > this probably isn't an issue, but I'd much rather implement a scriptable > muting mechanism in cooperation with server support for the feature. Then > there can be a special message from the sim that tells the viewer "mute this > object, please." I have a hack for that. And it works with LLOwnerSay as well the other chat types: https://wiki.secondlife.com/wiki/LSL_To_Client_Communication > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070621/4b80db23/attachment.pgp From okumoto at ucsd.edu Thu Jun 21 12:43:09 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Thu Jun 21 12:43:21 2007 Subject: [sldev] Can someone clarify the object naming conventions llvosky.h vs llsky.h In-Reply-To: <467A9AA9.90507@lindenlab.com> References: <467A1745.7010302@ucsd.edu> <467A3CA0.9030509@blueflash.cc> <467A9AA9.90507@lindenlab.com> Message-ID: <467AD4CD.3040800@ucsd.edu> Thanks for the reply Brad. Right now I am playing with the 1.17.0.12 code, and I will start looking at the windlight branch. I'm still in the process of understanding the code, but when I run into problems I will drop you a line. Max Brad Linden wrote: > > First, a real short introduction: I'm Brad Linden and joined the > Boston area office of Linden Lab last month. I've been working on > WindLight (available at > http://svn.secondlife.com/svn/linden/branches/2007/windlight_1-17-0/). > You can see Zen's blog post > (http://blog.secondlife.com/2007/06/14/windlight-update/) and Torley's > post > (http://blog.secondlife.com/2007/05/21/windlight-atmospheric-rendering-comes-to-second-life/) > for more details. > > > Nicholaz Beresford wrote: >> >> Just off hand and without looking deeper, I think >> the "VO" stands for Viewer-Object (think these >> are derived from LLViewerObject) >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> > That is correct. The LLSky class is a global singleton (gSky) for > managing access to anything related to the sky, including the LLVOSky > instance (gSky.mVOSkyp). > >> Max Okumoto wrote: >>> Hi, >>> >>> Can someone at LL explain the llvosky.h vs llsky.h naming convention? >>> >>> My cpu profiling says that LLVOSky::calcSkyColorInDir() is consuming >>> about 5%, so I have started seeing if I can speed it up. >>> >>> Max > > You might want to wait before spending too much time on that, or at > least not work on that branch. If you look at the WindLight branch > you'll see that that function has been completely replaced with > something much more cpu-intensive, but updated less frequently. It's > essentially a straightforward attempt at imitating the WindLight sky > glsl shaders in > indra/newview/app_settings/shaders/class2/windlight/WLSkyV.glsl and > indra/newview/app_settings/shaders/class2/windlight/WLSkyF.glsl. If > you want to try to optimize the sky CPU code, this branch is the place > to do it, but take note that on systems that have a GPU and OpenGL > drivers that can run WindLight, this code is obsoleted by the new > LLVOWLSky class, and the LLVOSky class will be largely disabled (this > is not happening properly in the snapshot we exported to the public > svn server). > > As our focus has been on getting the new GPU rendered WindLight > codepath working on as many hardware configurations as possible, the > CPU rendering code in LLVOSky has not had as much attention, as it's > really not suited for the way WindLight works and may need a complete > refactoring, and there are major outstanding bugs in it: > https://jira.secondlife.com/browse/VWR-980. Any contributions to the > CPU fallback code in LLVOSky would be much appreciated. > > So in summary, if you want to work on sky code and get your code used > after WindLight gets merged into the trunk, work in the WindLight > branch. If you have questions about what you find there, I'm your man. > > hope this helps, > -Brad Linden From synthalor.mandelbrot at inbox.com Thu Jun 21 14:52:31 2007 From: synthalor.mandelbrot at inbox.com (Synthalor Mandelbrot) Date: Thu Jun 21 14:52:49 2007 Subject: [sldev] Who are the Sculpted Prim Godz? In-Reply-To: <466FDDF4.9000607@blueflash.cc> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> Message-ID: <2228C6FDF8A.00000683synthalor.mandelbrot@inbox.com> Sculpted prims rock! I have already seen quite a few builders make cool use of Sculpted Prims (sculpties) created via the usual cool tools: Maya, Blender, Rokuro, etc.. Sculpties are a gr8 addition to the builder's toolkit. Kudos to those who created them! I have a different challenge and would like to know who are the SL devs who understand sculptie technology at the deeper levels. I need to go beyond just genning solids of rotation, or pulling on meshes in Blender or Maya. I want to create a set of programs that will mathematicaly generate 3D shapes using quaternions (and other 3D chaos-based methods) and then map the resulting data sets to textures so they can be imported as sculpties. I'm not sure if that is even possible. Where can I find the best resources to really understand what's going on in a sculptie? How can I go about algorithmically creating them? Can someone help or point me in the right direction? Thanks in advance! Synthalor Mandelbrot From able.whitman at gmail.com Thu Jun 21 14:58:47 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 21 14:58:49 2007 Subject: [sldev] Who are the Sculpted Prim Godz? In-Reply-To: <2228C6FDF8A.00000683synthalor.mandelbrot@inbox.com> References: <8a1bfe660706130454l5bfa0041sc17dda5e4c3acc72@mail.gmail.com> <466FDDF4.9000607@blueflash.cc> <2228C6FDF8A.00000683synthalor.mandelbrot@inbox.com> Message-ID: <7b3a84fb0706211458i6d83a960p6da5fa6a9bb507ab@mail.gmail.com> Qarl Linden is your man. His wiki talk page is here: https://wiki.secondlife.com/wiki/User_talk:Qarl_Linden, and the wiki also has a lot of information on sculped prims here: https://wiki.secondlife.com/wiki/Sculpted_Prims On 6/21/07, Synthalor Mandelbrot wrote: > > Sculpted prims rock! I have already seen quite a few builders make cool > use of Sculpted Prims (sculpties) created via the usual cool tools: Maya, > Blender, Rokuro, etc.. Sculpties are a gr8 addition to the builder's > toolkit. Kudos to those who created them! > > I have a different challenge and would like to know who are the SL devs > who understand sculptie technology at the deeper levels. I need to go > beyond just genning solids of rotation, or pulling on meshes in Blender or > Maya. I want to create a set of programs that will mathematicaly generate > 3D shapes using quaternions (and other 3D chaos-based methods) and then map > the resulting data sets to textures so they can be imported as sculpties. > > I'm not sure if that is even possible. Where can I find the best > resources to really understand what's going on in a sculptie? How can I go > about algorithmically creating them? Can someone help or point me in the > right direction? > > Thanks in advance! > > Synthalor Mandelbrot > > _______________________________________________ > 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/20070621/891c97d7/attachment.htm From gigstaggart at gmail.com Thu Jun 21 15:25:22 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Jun 21 15:25:39 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> Message-ID: <467AFAD2.1010403@gmail.com> Able Whitman wrote: > That's a really interesting idea, but I'm not really keen about > reserving a "special" chanel for only the viewer to listen on. Plus, I am. > which channel do you choose? It doesn't seem possible to guarantee that > that the channel you pick won't already be used by some existing script > somewhere. In practice this probably isn't an issue, but I'd much rather It doesn't matter one bit. Soft and I discussed this, and she thinks a range might be more useful, say 32 or 64 channels. There's no security implication since anyone with an LSL script can already effectively listen to these channels. I suggest near the top of the range around MAX_INT, going down from DEBUG_CHANNEL. Any LSL script using it can continue to use it, no harm done. -Jason From secret.argent at gmail.com Thu Jun 21 16:58:02 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 21 16:58:04 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> Message-ID: <828372A7-89B9-41EA-858A-421508CE6535@gmail.com> On 21-Jun-2007, at 11:05, Able Whitman wrote: > "Mute selected" > "Mute all objects in selected land" > > Is it possible to group select objects which aren't yours and which > you don't have permission to edit? I thought the last time I tried > (with "select only my objects" unchecked) it it didn't work, but I > could be wrong. You can select them, you just can't get any handles (drag, etc) on them. > Yes, if there is a parcel selected, the viewer has its geometry, > but I'm talking about determining the geometry after the parcel has > been muted. I think you and I are just talking about different > approaches to mute-by-parcel. I wasn't considering that the underlying code actually maintain some kind of "mute" on the parcel, I was thinking in terms of this being a way of selecting objects for mute-by-UUID. I'd rather leave more complex stuff for the sim. > That's a really interesting idea, but I'm not really keen about > reserving a "special" chanel for only the viewer to listen on. That's why I quoted 'channel', it would be a user specified preference (you could start by just making it a debug variable). Existing scripts already have to be able to deal with unexpected chat on any channel, so I wouldn't worry about breaking someone else's scripts... if they're going to die if they see some UUIDs on -32701 (or whatever) then they're broken anyway. Later it should be possible to switch to a new message type from an "llMuteFromThisParcel()" call easily. From able.whitman at gmail.com Thu Jun 21 18:01:28 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 21 18:01:31 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <467AFAD2.1010403@gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <467AFAD2.1010403@gmail.com> Message-ID: <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> I meant that I wasn't keen on reserving a channel just for the purposes of allowing scriptable muting of objects. General-purpose client channels are a good idea, though. As long as it uses the same chat mechanism as channel 0 chat, so that the viewer can identify the chatting object and its owner, etc., then I am all in favor of it. I'd like to also see a way to have the client monitor the amount of chat traffic on the reserved channels, though, and be able to mute objects that spam them. The last thing we need is for griefers (or just buggy scripts) to induce client-side lag by clogging these channels with spam. On 6/21/07, Jason Giglio wrote: > > Able Whitman wrote: > > That's a really interesting idea, but I'm not really keen about > > reserving a "special" chanel for only the viewer to listen on. Plus, > > I am. > > > which channel do you choose? It doesn't seem possible to guarantee that > > that the channel you pick won't already be used by some existing script > > somewhere. In practice this probably isn't an issue, but I'd much rather > > It doesn't matter one bit. Soft and I discussed this, and she thinks a > range might be more useful, say 32 or 64 channels. There's no security > implication since anyone with an LSL script can already effectively > listen to these channels. I suggest near the top of the range around > MAX_INT, going down from DEBUG_CHANNEL. > > Any LSL script using it can continue to use it, no harm done. > > -Jason > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/39809d2c/attachment.htm From able.whitman at gmail.com Thu Jun 21 18:05:28 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 21 18:05:31 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <828372A7-89B9-41EA-858A-421508CE6535@gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <828372A7-89B9-41EA-858A-421508CE6535@gmail.com> Message-ID: <7b3a84fb0706211805y33ba4c38r4e85689544485f4@mail.gmail.com> > > > You can select them, you just can't get any handles (drag, etc) on them. Ah, yes, I went and tried this just after posting my reply, actually. While I'm looking into muting object IDs by the parcel they're in, I'll look at the selection manager as well. Adding group-mute-by-selection and group-mute-by-parcel should be pretty similar in implementation. I wasn't considering that the underlying code actually maintain some > kind of "mute" on the parcel, I was thinking in terms of this being a > way of selecting objects for mute-by-UUID. I'd rather leave more > complex stuff for the sim. You weren't, but I was. :) For the reasons I mentioned before, putting a mute on a parcel is, I believe, a better general solution to the ad prim problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/2b443270/attachment-0001.htm From able.whitman at gmail.com Thu Jun 21 18:07:31 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 21 18:07:35 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> Message-ID: <7b3a84fb0706211807u3882926lae2bb95352f310e6@mail.gmail.com> I figured an example was in order, to demonstrate how "mute visibility" as I've currently implemented it looks, so I've posted a couple of screenshots for comparison on my blog: http://ablewhitman.blogspot.com/2007/06/trying-to-take-back-view.html Cheers, --Able On 6/21/07, Able Whitman wrote: > > Howdy, > > On and off, I've been investigating the feasibility of implementing > "Visibility Muting" as Nicholaz describes in VWR-1017 (https://jira.secondlife.com/browse/VWR-1017 > ), and as discussed in a few threads on this list. I'm pretty close to > having a proof-of-concept patch ready which adds the ability to mute the > visibility of objects by their ID, in much the same fashion that the > existing chat muting function works. > > I'd like to know if anyone would be interested it testing the patch which, > I assure you, is rather rough around the edges. This is mainly because I > cobbled it together as I was learning how the visibility muting needs to > interact with object update messages and with the rendering pipeline. But it > works pretty well, at least for me. > > Since there was a fair amount of interest the last couple of times this > topic came up, I thought I'd share some of what I learned during my > investigation. If you're not interested or don't care, I won't be offended > if you mute this thread. :) > > The patch will add a new object pie menu item next to the existing "Mute / > Unmute" item, named "Mute / Unmute Visibility". > > This is what the patch endeavors to do when an object's visibility is > muted: > 1. The object is also muted "classically," that is, its chat is > suppressed, just as with a normal mute. > 2. Any particle system associated with the object is removed, just as > with a normal mute. > 3. All the textures on the object are replaced with a solid-white > texture. > 4. Phantom objects are made completely transparent. > 5. Non-phantom objects are made 67% transparent. (They are not made > entirely transparent because I believe that object collision happens in part > on the server, so avatars would still run into them. This way they are at > least visible enough to avoid.) > 6. Attached sounds on the object have their gain forced to zero. > 7. Hovering text on the object is removed. > 8. Objects have their light source and fullbright settings turned off. > 9. Touchable objects have their click action removed. > 10. Objects for sale are not purchasable. > 11. Objects have their angular velocity (llTargetOmega) forced to zero. > > If a muted object is part of a link set, all objects in the set are also > visibly muted. At the moment, only LLVOVolume objects are visibly mutable; > so you can't visibly mute things like avatars, trees, the ground, the sky, > etc. > > The patch works by extending the existing mute list capability of the > viewer, adding a new OBJECTVISIBLE mute type. There are a lot of places in > the LLPrimitive, LLViewerObject, and LLVOVolume classes (more than I > expected) that are hooked into altering their behavior when an object is > muted. There are portions of this patch that I am not at all happy with > because they're quite a hack, but now that I know what I'm doing (more or > less), I think the implementation can be much improved. > > A few observations from testing visibility muting so far: > > 1. It is possible to mute buildings -- houses, clubs, skyboxes, etc. > This seems like an obvious statement, but I hadn't considered the > implications of it until I tried muting my house. At first this was mildly > amusing, but it does raise some very important privacy concerns. > > 2. Muting lots of individual, unlinked objects -- like lots of ad cubes > or billboards or whatever -- is a pain. I might jam in a Client menu item > and a keyboard accelerator, just because clicking the object pie menus over > and over is really annoying. > > 3. It really, really reduces visual clutter. There's no question that > visibility muting, even in this rough form, is very helpful at eliminating > clutter and spam from ad prims and the like. Even though you wind up with a > bunch of semi-transparent cubes hovering around, it's a huge improvement. > > I also learned some things about the feasibility of doing visibility > muting by-owner or by-parcel: > > Mute-By-Owner is a nice idea, technically possible, but a bad way to go. > > The problem is that the owner information is not included in the > ObjectUpdate message (or any of the related Update messages). In order to > ascertain the owner of an object, the viewer must send a > RequestObjectPropertiesFamily message and wait for an ObjectProperties > reply. > > There's a significant amount of latency involved here -- it's the same > thing that happens when you Edit an object and wait a moment before the > "General" tab is populated. In order to implement Mute-By-Owner, the viewer > would have to make this request for *every* object that it gets an > ObjectUpdate message about. The patch already generates a good deal of extra > ObjectUpdate traffic in order to trigger the initial muting / unmuting of an > object, and adding this additional overhead would be simply untenable. > > Mute-By-Parcel is a nice idea, but it also has its share of complications. > > > First and foremost is doing the work of figuring out if an object is in a > given parcel or not. This in itself is not a trivial task, since parcels > aren't always rectangular. Getting the border geometry of a parcel also > requires a request and reply message from and two the viewer. > > Also, the viewer would probably have to request information for all the > parcels in the agent's current draw distance. With a 16sqm minimum parcel > size and a maximum draw distance of 512m, this is potentially a very large > number of parcels. > > Basically what the viewer gets is a bounding rectangle for a parcel, and > then a bitmapped array indicating which of the 16sqm subplots within that > rectangle actually belong to that particular parcel. While doing an "is this > object in that parcel" determination isn't terribly difficult, it's not > trivial, and it would have to be done for every N objects in the viewer's > object list, against M parcels in the agent's draw distance, which is > potentially a lot of extra work. > > On top of all that, there's the problem with tracking objects that are > moved into a parcel but not necessarily initially rezzed within that parcel. > Simply matching an object to a parcel isn't enough, because vehicles or > other moving objects which happen to cross into a parcel that is muted would > become muted when they entered, and unmuted when they left. This isn't an > ideal situation, so the viewer would also have to track whether an object > started out in a muted parcel or not. It's also worth considering whether > parcel muting should go "all the way up" or only cover objects rezzed below > the map limit (400m). > > As I've said before, Mute-By-ObjectID is a useful approach, but ultimately > one that can be defeated by clever scripting, since object IDs change > whenever an object is rezzed by an agent or by a script. > > At any rate, it was a thoroughly interesting (if sometimes desperately > frustrating) experience even getting this far with the visibility muting > idea. I'd love to have a few adventurous people give it a whirl and then > give me their feedback when I've got the proof-of-concept patch ready. > > Cheers, > --Able > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/b535ccfa/attachment.htm From tateru.nino at gmail.com Thu Jun 21 20:37:07 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Thu Jun 21 20:37:18 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <467AFAD2.1010403@gmail.com> <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> Message-ID: <467B43E3.9090608@gmail.com> Those channels aren't sent to the viewer though, are they? Able Whitman wrote: > I meant that I wasn't keen on reserving a channel just for the > purposes of allowing scriptable muting of objects. General-purpose > client channels are a good idea, though. > > As long as it uses the same chat mechanism as channel 0 chat, so that > the viewer can identify the chatting object and its owner, etc., then > I am all in favor of it. I'd like to also see a way to have the client > monitor the amount of chat traffic on the reserved channels, though, > and be able to mute objects that spam them. The last thing we need is > for griefers (or just buggy scripts) to induce client-side lag by > clogging these channels with spam. > > On 6/21/07, *Jason Giglio* > wrote: > > Able Whitman wrote: > > That's a really interesting idea, but I'm not really keen about > > reserving a "special" chanel for only the viewer to listen on. Plus, > > I am. > > > which channel do you choose? It doesn't seem possible to > guarantee that > > that the channel you pick won't already be used by some existing > script > > somewhere. In practice this probably isn't an issue, but I'd > much rather > > It doesn't matter one bit. Soft and I discussed this, and she > thinks a > range might be more useful, say 32 or 64 channels. There's no > security > implication since anyone with an LSL script can already effectively > listen to these channels. I suggest near the top of the range around > MAX_INT, going down from DEBUG_CHANNEL. > > Any LSL script using it can continue to use it, no harm done. > > -Jason > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 able.whitman at gmail.com Thu Jun 21 20:48:42 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 21 20:48:46 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <467B43E3.9090608@gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <467AFAD2.1010403@gmail.com> <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> <467B43E3.9090608@gmail.com> Message-ID: <7b3a84fb0706212048q2890c7c8s32beba63bede5ffc@mail.gmail.com> As I understood it, the idea (at least in the case of muting) would be to have a channel that the viewer could listen on for object IDs to mute, so a script could tell the viewer to mute an object automatically. But maybe I'm completely misunderstanding :) On 6/21/07, Tateru Nino wrote: > > Those channels aren't sent to the viewer though, are they? > > Able Whitman wrote: > > I meant that I wasn't keen on reserving a channel just for the > > purposes of allowing scriptable muting of objects. General-purpose > > client channels are a good idea, though. > > > > As long as it uses the same chat mechanism as channel 0 chat, so that > > the viewer can identify the chatting object and its owner, etc., then > > I am all in favor of it. I'd like to also see a way to have the client > > monitor the amount of chat traffic on the reserved channels, though, > > and be able to mute objects that spam them. The last thing we need is > > for griefers (or just buggy scripts) to induce client-side lag by > > clogging these channels with spam. > > > > On 6/21/07, *Jason Giglio* > > wrote: > > > > Able Whitman wrote: > > > That's a really interesting idea, but I'm not really keen about > > > reserving a "special" chanel for only the viewer to listen on. > Plus, > > > > I am. > > > > > which channel do you choose? It doesn't seem possible to > > guarantee that > > > that the channel you pick won't already be used by some existing > > script > > > somewhere. In practice this probably isn't an issue, but I'd > > much rather > > > > It doesn't matter one bit. Soft and I discussed this, and she > > thinks a > > range might be more useful, say 32 or 64 channels. There's no > > security > > implication since anyone with an LSL script can already effectively > > listen to these channels. I suggest near the top of the range > around > > MAX_INT, going down from DEBUG_CHANNEL. > > > > Any LSL script using it can continue to use it, no harm done. > > > > -Jason > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > -- > Tateru Nino > http://dwellonit.blogspot.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/7231cbb1/attachment-0001.htm From chance at kalacia.com Thu Jun 21 22:23:45 2007 From: chance at kalacia.com (Chance Unknown) Date: Thu Jun 21 22:23:47 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <7b3a84fb0706212048q2890c7c8s32beba63bede5ffc@mail.gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <467AFAD2.1010403@gmail.com> <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> <467B43E3.9090608@gmail.com> <7b3a84fb0706212048q2890c7c8s32beba63bede5ffc@mail.gmail.com> Message-ID: <2925011a0706212223h7e089c53he1b2d8b3fd415ccf@mail.gmail.com> basically, think of this idea as a channel zero (the viewer gets that) but that doesnt show on the screen ... this has the implication that you can script prims to send stuff to a hacked up viewer to which the viewer then could prgramatically respond to. this could be utilized to provide simplistic scripted capability to such a viewer based on how it was hacked up. On 6/21/07, Able Whitman wrote: > > As I understood it, the idea (at least in the case of muting) would be to > have a channel that the viewer could listen on for object IDs to mute, so a > script could tell the viewer to mute an object automatically. But maybe I'm > completely misunderstanding :) > > On 6/21/07, Tateru Nino wrote: > > > > Those channels aren't sent to the viewer though, are they? > > > > Able Whitman wrote: > > > I meant that I wasn't keen on reserving a channel just for the > > > purposes of allowing scriptable muting of objects. General-purpose > > > client channels are a good idea, though. > > > > > > As long as it uses the same chat mechanism as channel 0 chat, so that > > > the viewer can identify the chatting object and its owner, etc., then > > > I am all in favor of it. I'd like to also see a way to have the client > > > > > monitor the amount of chat traffic on the reserved channels, though, > > > and be able to mute objects that spam them. The last thing we need is > > > for griefers (or just buggy scripts) to induce client-side lag by > > > clogging these channels with spam. > > > > > > On 6/21/07, *Jason Giglio* > > > wrote: > > > > > > Able Whitman wrote: > > > > That's a really interesting idea, but I'm not really keen about > > > > reserving a "special" chanel for only the viewer to listen on. > > Plus, > > > > > > I am. > > > > > > > which channel do you choose? It doesn't seem possible to > > > guarantee that > > > > that the channel you pick won't already be used by some existing > > > > > script > > > > somewhere. In practice this probably isn't an issue, but I'd > > > much rather > > > > > > It doesn't matter one bit. Soft and I discussed this, and she > > > thinks a > > > range might be more useful, say 32 or 64 channels. There's no > > > security > > > implication since anyone with an LSL script can already > > effectively > > > listen to these channels. I suggest near the top of the range > > around > > > MAX_INT, going down from DEBUG_CHANNEL. > > > > > > Any LSL script using it can continue to use it, no harm done. > > > > >//////////////////////////////////////////////////////////////////////// > > // Open Shifting Float and Follow Script, by Foolish Frost. // > > // From Open Basic Follower/Facing Script, by Logan Bauer. // > > /////////////////////////////////////////////////////////////////////// > > // OFFSET is the position of your pet in relation to it's owner's > > position. > > // For example, in the default setting below, "vector offset =<-1,0,1>;" > > // I.E. (x,y,z), the -1 puts it 1m back behind owner, the 0 means don't > > have > > // it stay left or right, and 1 means have it stay 1m above it's owner. > > // So, if you wanted the script to make it follow directly in front of > > you, > > // and to the left, then you would change it to "vector offset > > =<1,1,0>;" > > > > > > // llFrand(float max) > > > > vector offset =<-1.2,0,1>; > > vector currentoffset =<0,0,0>; > > float xshift =.2; //How far it roams forward and back. > > float yshift =1.25; //How wide it roams left to right. > > float bob =2; //multiplyer of the BobCycle listed below. > > float shifttime =5; //average time it takes to shift to another XY > > position. > > integer timeset=0; //Is the timer running? > > float currentxshift =0; //current X shift position > > float currentyshift =0; //current Y shift position > > float currentyfacing =0; //currentyfacing storage > > integer currentbob; //current state of the BobCycle > > float bobbing =0; //bob storage > > list BobCycle = [0.0, 0.08, 0.12, 0.14, 0.15, 0.14, 0.12, 0.08, 0.0, - > > 0.08, -0.12, -0.14, -0.15, -0.14, -0.12, -0.08]; > > > > > > startup() > > { > > vector pos = llGetPos(); > > llSetStatus(STATUS_ROTATE_Z,TRUE); > > llSetStatus(STATUS_PHYSICS, TRUE); > > key id = llGetOwner(); > > llSensorRemove(); > > llSensorRepeat("",llGetOwner(),AGENT,200,2*PI,.5); > > } > > > > default > > { > > state_entry() > > { > > startup(); > > > > > > } > > > > on_rez(integer start_param) > > { > > startup(); > > } > > > > sensor(integer total_number) > > { > > vector pos = llDetectedPos(0); > > > > bobbing = llList2Float(BobCycle, currentbob)*bob; > > > > llSetTimerEvent(llFrand(shifttime)); > > currentoffset = ; > > llMoveToTarget(pos+(offset+currentoffset)*llDetect edRot(0),.3); > > if (currentyshift>=0) > > { > > currentyfacing = currentyshift; > > } else { > > currentyfacing = currentyshift*-1; > > } > > > > llLookAt(pos+<0,0+(currentyfacing*.33),1+bobbing>, 1 , 2); > > > > currentbob = currentbob +1; > > if (currentbob == 16) > > { > > currentbob = 0; > > } > > > > if(timeset==0) > > { > > timeset = 1; > > llSetTimerEvent(((llFrand(shifttime)+llFrand(shift > > time)+llFrand(shifttime))/3)*2); > > } > > > > > > } > > > > timer() > > { > > timeset = 0; > > currentyshift = llFrand(yshift*2)-yshift; > > currentxshift = > > llFrand(x//////////////////////////////////////////////////////////////////////// > > // Open Shifting Float and Follow Script, by Foolish Frost. // > > // From Open Basic Follower/Facing Script, by Logan Bauer. // > > /////////////////////////////////////////////////////////////////////// > > // OFFSET is the position of your pet in relation to it's owner's > > position. > > // For example, in the default setting below, "vector offset =<-1,0,1>;" > > // I.E. (x,y,z), the -1 puts it 1m back behind owner, the 0 means don't > > have > > // it stay left or right, and 1 means have it stay 1m above it's owner. > > // So, if you wanted the script to make it follow directly in front of > > you, > > // and to the left, then you would change it to "vector offset > > =<1,1,0>;" > > > > > > // llFrand(float max) > > > > vector offset =<-1.2,0,1>; > > vector currentoffset =<0,0,0>; > > float xshift =.2; //How far it roams forward and back. > > float yshift =1.25; //How wide it roams left to right. > > float bob =2; //multiplyer of the BobCycle listed below. > > float shifttime =5; //average time it takes to shift to another XY > > position. > > integer timeset=0; //Is the timer running? > > float currentxshift =0; //current X shift position > > float currentyshift =0; //current Y shift position > > float currentyfacing =0; //currentyfacing storage > > integer currentbob; //current state of the BobCycle > > float bobbing =0; //bob storage > > list BobCycle = [0.0, 0.08, 0.12, 0.14, 0.15, 0.14, 0.12, 0.08, 0.0, - > > 0.08, -0.12, -0.14, -0.15, -0.14, -0.12, -0.08]; > > > > > > startup() > > { > > vector pos = llGetPos(); > > llSetStatus(STATUS_ROTATE_Z,TRUE); > > llSetStatus(STATUS_PHYSICS, TRUE); > > key id = llGetOwner(); > > llSensorRemove(); > > llSensorRepeat("",llGetOwner(),AGENT,200,2*PI,.5); > > } > > > > default > > { > > state_entry() > > { > > startup(); > > > > > > } > > > > on_rez(integer start_param) > > { > > startup(); > > } > > > > sensor(integer total_number) > > { > > vector pos = llDetectedPos(0); > > > > bobbing = llList2Float(BobCycle, currentbob)*bob; > > > > llSetTimerEvent(llFrand(shifttime)); > > currentoffset = ; > > llMoveToTarget(pos+(offset+currentoffset)*llDetect edRot(0),.3); > > if (currentyshift>=0) > > { > > currentyfacing = currentyshift; > > } else { > > currentyfacing = currentyshift*-1; > > } > > > > llLookAt(pos+<0,0+(currentyfacing*.33),1+bobbing>, 1 , 2); > > > > currentbob = currentbob +1; > > if (currentbob == 16) > > { > > currentbob = 0; > > } > > > > if(timeset==0) > > { > > timeset = 1; > > llSetTimerEvent(((llFrand(shifttime)+llFrand(shift > > time)+llFrand(shifttime))/3)*2); > > } > > > > > > } > > > > timer() > > { > > timeset = 0; > > currentyshift = llFrand(yshift*2)-yshift; > > currentxshift = llFrand(xshift*2)-xshift; > > } > > }shift*2)-xshift; > > } > > } > > > -Jason > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > -- > > Tateru Nino > > http://dwellonit.blogspot.com/ > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070621/ce47fece/attachment.htm From hawk.carter at unix-dev.de Fri Jun 22 01:46:52 2007 From: hawk.carter at unix-dev.de (Hawk) Date: Fri Jun 22 01:47:15 2007 Subject: [sldev] Can someone clarify the object naming conventions llvosky.h vs llsky.h Message-ID: <000c01c7b4a9$e2ae60a0$0301a8c0@main1> I'm on the Windlight branch, i got it compiled with the glh header out from the nvidia-sdk 9.53, but the viewer dont wants to start and crashes while loading and swithcing to fullscreen (happens too with window mode). Maybe Brad or someone else from Linden or one of the OS-Devs can help in that issue ? I can send all logs i have laters if needed (i compile a debug version too right at the moment) Would be great :) Attachments : Secondlife.log -------------- next part -------------- A non-text attachment was scrubbed... Name: SecondLife.log Type: application/octet-stream Size: 54219 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070622/da0c4cb4/SecondLife-0001.obj From nicholaz at blueflash.cc Fri Jun 22 02:04:35 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 22 02:04:49 2007 Subject: [sldev] Fullscreen/Window In-Reply-To: <000c01c7b4a9$e2ae60a0$0301a8c0@main1> References: <000c01c7b4a9$e2ae60a0$0301a8c0@main1> Message-ID: <467B90A3.5060209@blueflash.cc> Btw, Hawk wrote: > I'm on the Windlight branch, i got it compiled with the glh header out > from the nvidia-sdk 9.53, but the viewer dont wants to start and crashes > while loading and swithcing to fullscreen (happens too with window mode). This is most likely something different (regular branch, my version of the viewer) but over the last day's I've seen crashes when switching between fullscreen and desktop applications (I just went back using fullscreen a few days ago, where before I was just running windowed) Nick From tao.takashi at googlemail.com Fri Jun 22 02:21:05 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Fri Jun 22 02:21:07 2007 Subject: [sldev] Possible 3rd party contract for viewer modification In-Reply-To: <9e6e5c9e0706210729n3c3e5094rbbd9eddda44911f1@mail.gmail.com> References: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> <4679CEA6.2000803@gwala.net> <9e6e5c9e0706210729n3c3e5094rbbd9eddda44911f1@mail.gmail.com> Message-ID: <23bbb49e0706220221o37246994mdaf3d774fbc229fe@mail.gmail.com> Hi! The easiest for everybody would still be if Linden Lab could provide some sort of web service where I can upload an asset and get a UUID back and get L$10 charged (IMHO) (or web textures but I guess they are way in the future) Next best thing would probably be an libsl bot with HTTP interface basically doing the same. I wonder how much work that would be and how much it would cost to implement (no time to learn C# right now ;-) ). I guess it's something many people might be happy to have as it sort of opens the long tail from the Real World to Second Life. -- Tao 2007/6/21, Soft Linden : > > I expect you're right! I tend to go with what I know, and a viewer > change is a shallow problem for me, while I'd have to learn C# and > libsl for the other. I'd think the same were true of many on the list. > > That said, so long as I'm convinced of the ability to deliver, I'm > comfortable making a connection regardless of what tools you want to > use. I certainly have no doubts at all as to whether the libsl > developers could deliver -- they've got a pretty solid track record. > > > On 6/20/07, Adam Frisby wrote: > > This is probably better served with a libsl based bot to be honest. > > > > Hacking up a client to do it would be messy at best and libsl already > > has appropriate asset upload functions inplace that would turn it into a > > 15 line C# application (plus libsl is easier to maintain than a custom > > viewer fork) > > > > Adam > _______________________________________________ > 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/20070622/5008b4e9/attachment.htm From hawk.carter at unix-dev.de Fri Jun 22 04:17:33 2007 From: hawk.carter at unix-dev.de (Hawk) Date: Fri Jun 22 04:17:52 2007 Subject: [sldev] Can someone clarify the object naming conventions Message-ID: <001901c7b4be$ee1ccfc0$0301a8c0@main1> I think i have found the Problem at the Windlight Client after some Hours of debugging : 2007-06-22T11:11:35Z INFO: idle_startup: Initializing sky... 2007-06-22T11:11:35Z INFO: LLDrawPoolWLSky::LLDrawPoolWLSky: loading WindLight cloud noise from C:\Programme\SL-Wind\app_settings\windlight\clouds2.jpg 2007-06-22T11:11:35Z WARNING: LLImageBase::setLastError: Unable to open file for reading FILE:C:\Programme\SL-Wind\app_settings\windlight\clouds2.jpg 2007-06-22T11:11:35Z WARNING: LLImageBase::setLastError: LLImageJPEG trying to decode an image with no data! 2007-06-22T11:11:35Z ./llimagegl.cpp(838) : error 2007-06-22T11:11:35Z ERROR: LLImageGL::createGLTexture: Bad number of components for texture: 0 The images arent in the SVN-Tree, would be cool that this gets fixed. From hawk.carter at unix-dev.de Fri Jun 22 05:10:09 2007 From: hawk.carter at unix-dev.de (Hawk) Date: Fri Jun 22 05:10:35 2007 Subject: [sldev] Windlight 1.17 (was : Can someone clarify the object naming conventions) References: <001901c7b4be$ee1ccfc0$0301a8c0@main1> Message-ID: <000801c7b4c6$4b71c520$0301a8c0@main1> Ok got it working as debugging client (ReleaseNoOpt), all in all : Bugs/Stoppers/Nasty Stuff : No Fullscreen Very very slow Hud attachments are borked (graphicly) Nice : Water Reflections !! and the known stuff from windlight ........ I'll write a how to soonish, if somebody wants. I hope the development from Linden side will start again soon on this, the features are still awesome eyecandys ! Greetings Hawk ----- Original Message ----- From: "Hawk" To: "SLDEV" Sent: Friday, June 22, 2007 1:17 PM Subject: [sldev] Can someone clarify the object naming conventions >I think i have found the Problem at the Windlight Client after some Hours >of debugging : > > 2007-06-22T11:11:35Z INFO: idle_startup: Initializing sky... > 2007-06-22T11:11:35Z INFO: LLDrawPoolWLSky::LLDrawPoolWLSky: loading > WindLight cloud noise from > C:\Programme\SL-Wind\app_settings\windlight\clouds2.jpg > 2007-06-22T11:11:35Z WARNING: LLImageBase::setLastError: Unable to open > file for reading > FILE:C:\Programme\SL-Wind\app_settings\windlight\clouds2.jpg > 2007-06-22T11:11:35Z WARNING: LLImageBase::setLastError: LLImageJPEG > trying to decode an image with no data! > 2007-06-22T11:11:35Z ./llimagegl.cpp(838) : error > 2007-06-22T11:11:35Z ERROR: LLImageGL::createGLTexture: Bad number of > components for texture: 0 > > The images arent in the SVN-Tree, would be cool that this gets fixed. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From odysseus654 at gmail.com Fri Jun 22 07:41:19 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Fri Jun 22 07:41:21 2007 Subject: [sldev] Possible 3rd party contract for viewer modification In-Reply-To: <23bbb49e0706220221o37246994mdaf3d774fbc229fe@mail.gmail.com> References: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> <4679CEA6.2000803@gwala.net> <9e6e5c9e0706210729n3c3e5094rbbd9eddda44911f1@mail.gmail.com> <23bbb49e0706220221o37246994mdaf3d774fbc229fe@mail.gmail.com> Message-ID: <1674f6c70706220741n1e087ef3yf054e0ed2bdb6af2@mail.gmail.com> One of the big problems with such a service is probably that it would require a third party to be trusted with your SL password. It's easier to trust a client that you own and run than it is a webservice that has unknown security and retention policies. On 6/22/07, Tao Takashi wrote: > > Hi! > > The easiest for everybody would still be if Linden Lab could provide some > sort of web service where I can upload an asset and get a UUID back and get > L$10 charged (IMHO) (or web textures but I guess they are way in the future) > > > Next best thing would probably be an libsl bot with HTTP interface > basically doing the same. > I wonder how much work that would be and how much it would cost to > implement (no time > to learn C# right now ;-) ). I guess it's something many people might be > happy to have as > it sort of opens the long tail from the Real World to Second Life. > > -- Tao > > 2007/6/21, Soft Linden : > > > > I expect you're right! I tend to go with what I know, and a viewer > > change is a shallow problem for me, while I'd have to learn C# and > > libsl for the other. I'd think the same were true of many on the list. > > > > That said, so long as I'm convinced of the ability to deliver, I'm > > comfortable making a connection regardless of what tools you want to > > use. I certainly have no doubts at all as to whether the libsl > > developers could deliver -- they've got a pretty solid track record. > > > > > > On 6/20/07, Adam Frisby wrote: > > > This is probably better served with a libsl based bot to be honest. > > > > > > Hacking up a client to do it would be messy at best and libsl already > > > has appropriate asset upload functions inplace that would turn it into > > a > > > 15 line C# application (plus libsl is easier to maintain than a custom > > > > > viewer fork) > > > > > > Adam > > _______________________________________________ > > 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 > _______________________________________________ > 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/20070622/e4100c5f/attachment.htm From dale at daleglass.net Fri Jun 22 07:41:54 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Fri Jun 22 07:42:09 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <2925011a0706212223h7e089c53he1b2d8b3fd415ccf@mail.gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <467AFAD2.1010403@gmail.com> <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> <467B43E3.9090608@gmail.com> <7b3a84fb0706212048q2890c7c8s32beba63bede5ffc@mail.gmail.com> <2925011a0706212223h7e089c53he1b2d8b3fd415ccf@mail.gmail.com> Message-ID: <20070622144154.GA1262@bruno.sbruno> On Thu, Jun 21, 2007 at 10:23:45PM -0700, Chance Unknown wrote: > basically, think of this idea as a channel zero (the viewer gets that) but > that doesnt show on the screen ... this has the implication that you can > script prims to send stuff to a hacked up viewer to which the viewer then > could prgramatically respond to. this could be utilized to provide > simplistic scripted capability to such a viewer based on how it was hacked > up. I've already got a bit of code for that, with the protocol documented here: https://wiki.secondlife.com/wiki/LSL_To_Client_Communication This allows an object talk to the viewer with for example, llOwnerSay. Having the viewer reply to the object isn't done yet, but the basic idea is as follows: object: llOwnerSay("$VwrComm$1$REGISTER$3234"); // 3234 is the channel Viewer in response notes that object with key K wants replies to its requests on channel 3234, and also sends an "ok" message there in response to let the object know the viewer got the message. My idea is to try to submit an implementation of this as a patch, with protocol parser, a class that allows other parts to set callbacks to handle things directed to them, plus some predefined versions as querying the viewer's version, recognized extensions, etc. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070622/29b6f662/attachment.pgp From doug at lindenlab.com Fri Jun 22 07:59:04 2007 From: doug at lindenlab.com (Douglas Soo) Date: Fri Jun 22 07:59:09 2007 Subject: [sldev] Profiling and optimization Message-ID: <672B7BC888DC6DAA8C2205C9@[10.14.11.59]> After watching the chatter fly on this list, I thought that it might be worthwhile to write up a short summary of what we have found at Linden to be effective approaches to profiling and optimizing code. It's pretty thing, but hopefully will be useful. - Doug -- Douglas Soo Studio Director Linden Lab 1100 Sansome San Francisco, CA 94111 doug@lindenlab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070622/bc6f156a/attachment-0001.pgp From brad at lindenlab.com Fri Jun 22 08:26:35 2007 From: brad at lindenlab.com (Brad Kittenbrink) Date: Fri Jun 22 08:26:48 2007 Subject: [sldev] Windlight 1.17 (was : Can someone clarify the object naming conventions) In-Reply-To: <000801c7b4c6$4b71c520$0301a8c0@main1> References: <001901c7b4be$ee1ccfc0$0301a8c0@main1> <000801c7b4c6$4b71c520$0301a8c0@main1> Message-ID: <467BEA2B.2060804@lindenlab.com> Hawk wrote: > Ok got it working as debugging client (ReleaseNoOpt), all in all : > > Bugs/Stoppers/Nasty Stuff : > > No Fullscreen > Very very slow > Hud attachments are borked (graphicly) > > Nice : > > Water Reflections !! > and the known stuff from windlight > > > ........ > > I'll write a how to soonish, if somebody wants. > > I hope the development from Linden side will start again soon on this, > the features are still awesome eyecandys ! > > > > Greetings > > Hawk Thanks for checking this out. Would you mind putting the fullscreen and hud attachments problems into Jira? Regarding the performance, could you try playing with the WLSkyDetail debug setting and reporting whether it makes a difference? It defaults to 64, but decent quality can still be had down to 32. If this helps your performance (or even if it doesn't) could you give me some details on what graphics card you have and what settings worked best for you? > > ----- Original Message ----- From: "Hawk" > To: "SLDEV" > Sent: Friday, June 22, 2007 1:17 PM > Subject: [sldev] Can someone clarify the object naming conventions > > >> I think i have found the Problem at the Windlight Client after some >> Hours of debugging : >> >> 2007-06-22T11:11:35Z INFO: idle_startup: Initializing sky... >> 2007-06-22T11:11:35Z INFO: LLDrawPoolWLSky::LLDrawPoolWLSky: loading >> WindLight cloud noise from >> C:\Programme\SL-Wind\app_settings\windlight\clouds2.jpg >> 2007-06-22T11:11:35Z WARNING: LLImageBase::setLastError: Unable to >> open file for reading >> FILE:C:\Programme\SL-Wind\app_settings\windlight\clouds2.jpg >> 2007-06-22T11:11:35Z WARNING: LLImageBase::setLastError: LLImageJPEG >> trying to decode an image with no data! >> 2007-06-22T11:11:35Z ./llimagegl.cpp(838) : error >> 2007-06-22T11:11:35Z ERROR: LLImageGL::createGLTexture: Bad number of >> components for texture: 0 >> >> The images arent in the SVN-Tree, would be cool that this gets fixed. >> Ahh, sorry about that. I think that was supposed to go in a modified slviewer-artlook.zip, but I'm not sure what ended up happening to that. thanks, -Brad From soft at lindenlab.com Fri Jun 22 10:15:09 2007 From: soft at lindenlab.com (Soft Linden) Date: Fri Jun 22 10:15:11 2007 Subject: [sldev] Help me with ancient patches Message-ID: <9e6e5c9e0706221015w6f8f1c5dy7490fde2e470ce97@mail.gmail.com> I'm looking for old patches that might have gotten lost before there was a standard pipeline in place for open source contributions. I've scanned sldev, looking for patches without a JIRA in close proximity. Please help me out and see if you think some of these should be added to the JIRA -- or tag the patch with a JIRA if it is in the JIRA. Jan/Feb first: https://wiki.secondlife.com/wiki/User:Soft_Linden/scratch#Old_Patches_Possibly_Wanting_Love ( http://tinyurl.com/2cl9ff ) Even if a patch couldn't/shouldn't be used, it may still point to a live issue. Feel free to reply here if you want to talk about how we could handle that on a specific patch. Going forward, if you see a *new* patch show up without a matching JIRA, give the submitter a friendly bump toward the Submitting Code page if you want to help ensure we don't drop any more. :) https://wiki.secondlife.com/wiki/Submitting_code Thanks! From secret.argent at gmail.com Fri Jun 22 10:30:19 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 22 10:30:20 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <467AFAD2.1010403@gmail.com> <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> Message-ID: <64293F6A-F1A0-48B4-B7F0-859301737EBC@gmail.com> On 21-Jun-2007, at 20:01, Able Whitman wrote: > I meant that I wasn't keen on reserving a channel just for the > purposes of allowing scriptable muting of objects. General-purpose > client channels are a good idea, though. Allowing multiple channels mostly lets you "subscribe" to different sets of muting advertisements. There's no security or privacy or interference reasons for doing so. Having a single channel would avoid the problem of having to find out what channel the parcel you're on is using. Mute advisories from objects you don't own should only be honored while you're on the parcel that they're broadcasting from. When you live the parcel the advisories should come back. A user interface to allow you to see what individual advisers or channels have muted, and track how often they're coming in, and to ignore them... that's something that absolutely needs to be in the final version. To experiment with the model you'd only need something like this: Dialog: "The parcel you're in has a "mute list", would you like to use it? (yes) (no)" For objects you own, this dialog wouldn't come up. Griefers wouldn't be a problem, since you would only accept mute advisements from objects you don't own if they have the same owner as the parcel you're on. If they come in too fast... you could simply mute them. :) From makosoft at googlemail.com Fri Jun 22 10:32:46 2007 From: makosoft at googlemail.com (Aidan Thornton) Date: Fri Jun 22 10:32:48 2007 Subject: [sldev] Possible 3rd party contract for viewer modification In-Reply-To: <23bbb49e0706220221o37246994mdaf3d774fbc229fe@mail.gmail.com> References: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> <4679CEA6.2000803@gwala.net> <9e6e5c9e0706210729n3c3e5094rbbd9eddda44911f1@mail.gmail.com> <23bbb49e0706220221o37246994mdaf3d774fbc229fe@mail.gmail.com> Message-ID: On 6/22/07, Tao Takashi wrote: > Hi! > > The easiest for everybody would still be if Linden Lab could provide some > sort of web service where I can upload an asset and get a UUID back and get > L$10 charged (IMHO) (or web textures but I guess they are way in the future) They already have something very similar to that, in the form of the NewFileAgentInventory capability. Unfortunately, you can only use it whilst you're connected to Second Life, either through the official viewer or through libsecondlife. (See http://www.libsecondlife.org/wiki/NewAgentInventory for the gory details. I can't see any technical reason why Linden Labs couldn't set up a more permanent version of this that didn't require logging in to Second Life.) From secret.argent at gmail.com Fri Jun 22 10:35:12 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 22 10:35:12 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particles bug... In-Reply-To: <46745A6E.4080901@gmail.com> References: <20070614173937.4E2F741B136@stupor.lindenlab.com> <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> <46745A6E.4080901@gmail.com> Message-ID: This is a bigger problem than just Farallon's "sparks". I just used Coadey Concord's Aurora Wings for the first time in a long time and they show the problem very effectively: the "Follow Source" behavior they depend on is really broken in the current particle system. When flying at a high speed, you "shed feathers"... a problem they didn't have earlier. It's like "Follow Source" is being applied periodically to "fix up" the positions of the particles, rather than being applied as they're moved. If this is a performance enhancement it's an unfortunate one. From able.whitman at gmail.com Fri Jun 22 10:41:08 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 22 10:41:10 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <64293F6A-F1A0-48B4-B7F0-859301737EBC@gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <467AFAD2.1010403@gmail.com> <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> <64293F6A-F1A0-48B4-B7F0-859301737EBC@gmail.com> Message-ID: <7b3a84fb0706221041n2873befr1d5d9150118a71b1@mail.gmail.com> This would definitely be a good, flexible way to share mute lists between users, something that I would really like to see. Unfortunately I'm restricted to only modifying the client (until the server code is released, hint, hint), so mute list sharing is out of the scope of my patch for now :) On 6/22/07, Argent Stonecutter wrote: > > On 21-Jun-2007, at 20:01, Able Whitman wrote: > > I meant that I wasn't keen on reserving a channel just for the > > purposes of allowing scriptable muting of objects. General-purpose > > client channels are a good idea, though. > > Allowing multiple channels mostly lets you "subscribe" to different > sets of muting advertisements. There's no security or privacy or > interference reasons for doing so. Having a single channel would > avoid the problem of having to find out what channel the parcel > you're on is using. > > Mute advisories from objects you don't own should only be honored > while you're on the parcel that they're broadcasting from. When you > live the parcel the advisories should come back. > > A user interface to allow you to see what individual advisers or > channels have muted, and track how often they're coming in, and to > ignore them... that's something that absolutely needs to be in the > final version. To experiment with the model you'd only need something > like this: > > Dialog: "The parcel you're in has a "mute list", would you like to > use it? (yes) (no)" > > For objects you own, this dialog wouldn't come up. > > Griefers wouldn't be a problem, since you would only accept mute > advisements from objects you don't own if they have the same owner as > the parcel you're on. If they come in too fast... you could simply > mute them. :) > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070622/4a2eca54/attachment.htm From secret.argent at gmail.com Fri Jun 22 10:43:51 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 22 10:43:50 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <467B43E3.9090608@gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <467AFAD2.1010403@gmail.com> <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> <467B43E3.9090608@gmail.com> Message-ID: <90168971-C20C-44DC-B538-70AAD828518B@gmail.com> On 21-Jun-2007, at 22:37, Tateru Nino wrote: > Those channels aren't sent to the viewer though, are they? Good point. You'd have to use an llInstantMessage/llOwnerSay based relay hack. How about this, as an interim implementation? The viewer would listen to llOwnerSay() or llInstamtMessage() messages prefixed with the string "%mute%" and followed by an optional integer and one or more valid UUIDs separated by whitespace. When it got them, it wouldn't display them in your chat (unless you requested it explicitly) but would instead add the UUIDs to the mute list. If there is an integer, it would be a "channel" ID. You could wear an "ad prim scanner" that would just llOwnerSay() the messages to you, or listen to chat on a high channel and relay them to you. That way the behavior would be under the control of a scripted object you control and you couldn't be spammed. If this works well, this functionality could be put into the sim and made into a formal Linden message. From secret.argent at gmail.com Fri Jun 22 10:53:41 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 22 10:53:39 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <20070622145908.E353841B120@stupor.lindenlab.com> References: <20070622145908.E353841B120@stupor.lindenlab.com> Message-ID: <9D7BA0DD-39B4-41EF-B798-9BF86E13CA15@gmail.com> > Having the viewer reply to the object isn't done yet, but the basic > idea is as follows: For this design, would we even need this capability? From dale at daleglass.net Fri Jun 22 11:25:12 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Fri Jun 22 11:25:17 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <9D7BA0DD-39B4-41EF-B798-9BF86E13CA15@gmail.com> References: <20070622145908.E353841B120@stupor.lindenlab.com> <9D7BA0DD-39B4-41EF-B798-9BF86E13CA15@gmail.com> Message-ID: <20070622182512.GB1262@bruno.sbruno> On Fri, Jun 22, 2007 at 12:53:41PM -0500, Argent Stonecutter wrote: > >Having the viewer reply to the object isn't done yet, but the basic > >idea is as follows: > > For this design, would we even need this capability? For this design specifically, no. But I'm trying to implement a general solution. Rationale: 1. This isn't an unique need. Other people will want something of the sort. 20 different ways of doing the same thing is bad. 2. Chat messages are visible [1]. So any protocol like this must have in mind that the standard client would just display it, resulting on random junk on the screen. If multiple ways of doing this develop, some of which have common capabilities, this could lead to scripts trying multiple protocol, with multiplying amounts of junk on the screen as result. 3. The best way to solve the above problem is coming up with a standard protocol, which is usable for whatever is needed, then: A. Get a patch that does the basic functionality accepted by LL, so that any script can try to talk to the viewer without filling people's screens with junk. B. Have LL create an official system, with functions added to LSL to support it. This would be the ideal case, but since we don't have server code yet, it's not possible to implement without LL support. So I'm taking option A for the time being. Due to the above, I think a good protocol must have the following characteristics: 1. Provision for versioning and extensibility. Must be possible to update without ugly hacks or breaking existing functionality. 2. Simple enough for LSL scripts to use without complication 3. Generates minimum amount of junk in case it's not supported. Due to this I plan to have some sort of registration request, which if unanswered should be a sign that the viewer doesn't know what's that, and that the script shouldn't try to make further requests. 4. Supports a mechanism to ask the viewer about what functionality it can provide. This would help making user friendly scripts which can figure out that the viewer's functionality is too old, or not present. Notes: [1] Yeah, something could be hacked up with the object changing its description, size or something of that sort, but that's even uglier than the chat hack. -------------- 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/20070622/e39e7e46/attachment.pgp From secret.argent at gmail.com Fri Jun 22 13:02:08 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 22 13:02:07 2007 Subject: [sldev] Re: More client forwarded chat channels. In-Reply-To: <7b3a84fb0706221041n2873befr1d5d9150118a71b1@mail.gmail.com> References: <20070621044423.0356D41B0E1@stupor.lindenlab.com> <2F06B745-CDD9-4403-B5E8-30855A2B4AE4@gmail.com> <7b3a84fb0706210905n4949482cy868fbcf5d2d67a4f@mail.gmail.com> <467AFAD2.1010403@gmail.com> <7b3a84fb0706211801n70dfcdebrae56c0bfe1f27bb5@mail.gmail.com> <64293F6A-F1A0-48B4-B7F0-859301737EBC@gmail.com> <7b3a84fb0706221041n2873befr1d5d9150118a71b1@mail.gmail.com> Message-ID: On 22-Jun-2007, at 12:41, Able Whitman wrote: > This would definitely be a good, flexible way to share mute lists > between users, something that I would really like to see. > Unfortunately I'm restricted to only modifying the client (until > the server code is released, hint, hint), so mute list sharing is > out of the scope of my patch for now :) You don't need to modify the server to listen to one of Dale's instant message chats from an object that you've got attached to you. You don't need to modify the server to have that object listen to broadcasts on a channel and send them on to you with appropriate extra info. From nicholaz at blueflash.cc Fri Jun 22 14:37:41 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 22 14:38:04 2007 Subject: [sldev] The "flashing particles" bug isn't a flashing particles bug... In-Reply-To: References: <20070614173937.4E2F741B136@stupor.lindenlab.com> <97F938A9-1C19-4DA8-8F48-5CDEE2955F4B@gmail.com> <46745A6E.4080901@gmail.com> Message-ID: <467C4125.3000002@blueflash.cc> I know ... there's another JIRA about that already somewhere. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Argent Stonecutter wrote: > This is a bigger problem than just Farallon's "sparks". I just used > Coadey Concord's Aurora Wings for the first time in a long time and they > show the problem very effectively: the "Follow Source" behavior they > depend on is really broken in the current particle system. When flying > at a high speed, you "shed feathers"... a problem they didn't have > earlier. It's like "Follow Source" is being applied periodically to "fix > up" the positions of the particles, rather than being applied as they're > moved. If this is a performance enhancement it's an unfortunate one. From tshephard at gmail.com Fri Jun 22 15:48:31 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Jun 22 15:48:33 2007 Subject: [sldev] Possible 3rd party contract for viewer modification In-Reply-To: <23bbb49e0706220221o37246994mdaf3d774fbc229fe@mail.gmail.com> References: <9e6e5c9e0706201756n21878507jf3a465082430b94@mail.gmail.com> <4679CEA6.2000803@gwala.net> <9e6e5c9e0706210729n3c3e5094rbbd9eddda44911f1@mail.gmail.com> <23bbb49e0706220221o37246994mdaf3d774fbc229fe@mail.gmail.com> Message-ID: <3b19a500706221548oac3731j47f9505182ef608e@mail.gmail.com> > The easiest for everybody would still be if Linden Lab could provide some > sort of web service where I can upload an asset and get a UUID back and get > L$10 charged (IMHO) (or web textures but I guess they are way in the future) It's a cool idea, but you'd have to double pay for the bandwidth. > One of the big problems with such a service is probably that it would require a third party > to be trusted with your SL password. For this particular application you could (in theory) transfer the texture full perm to the avatar or just hand off an asset ID if that is not feasible. However, it's an interesting problem. The rules around password sharing are mystifying when it comes to 3rd party software. SL needs to develop a similar authentication scheme that eBay has where you authorize temporary tokens but do not reveal your password. From gigstaggart at gmail.com Fri Jun 22 16:22:48 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 22 16:23:07 2007 Subject: [sldev] Help me with ancient patches In-Reply-To: <9e6e5c9e0706221015w6f8f1c5dy7490fde2e470ce97@mail.gmail.com> References: <9e6e5c9e0706221015w6f8f1c5dy7490fde2e470ce97@mail.gmail.com> Message-ID: <467C59C8.1020604@gmail.com> Soft Linden wrote: > I'm looking for old patches that might have gotten lost before there I think all the OpenJPEG patches are merged. OpenJPEG runs a lot nicer now. It's very usable and almost as fast as KDU. From seg at haxxed.com Fri Jun 22 20:32:24 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 22 20:31:47 2007 Subject: [sldev] getting serious about software. In-Reply-To: <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> Message-ID: <1182569545.30666.34.camel@localhost> Don't underestimate the compiler's ability to optimize. I did a little writeup on my LJ: http://ninjaseg.livejournal.com/49842.html Lesson: Code what you mean, "tmp / 2", and the compiler can optimize it in the best way for the platform you tell it to target. Though notably, gcc 4.1 is too dumb to vectorize an integer divide on its own. But on the other hand, vectorization hasn't proven to be a benefit in this case. MMX/SSE really is of little benefit in a loop with a single divide, in fact it seems to slow it down a little. Moving things in and out of the registers is the bottleneck. Vectorization is really only a benefit if you can keep it all in the registers and do a large number of operations in a row. The cleanup on the way to vectorization has resulted in a measurable speedup though. But the biggest speedup by far has been from reducing cache pollution and memory overhead. > --- Write custom code for your math --- > All modern CPU's support SIMD instructions aimed at 3D. Compilers > don't convert your vector math for you, you need to do it yourself. Compilers are actually starting to be pretty good at autovectorization. You still need to design the code with vectorization in mind. In gcc's case, it is very picky about aliasing, basically requiring C99 "restrict" to be used on all pointers, and assigning structure members to temporary variables... I've experimented with Intel's compiler, but I can't actually get the thing to link right on Fedora 6/7, so I've only been able to look at its assembler output. -------------- 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/20070622/1157f71a/attachment.pgp From kathycat at kol.co.nz Fri Jun 22 22:36:10 2007 From: kathycat at kol.co.nz (kathy) Date: Fri Jun 22 22:36:55 2007 Subject: [sldev] Send SLDev mailing list submissions to Message-ID: <001e01c7b558$7e8abec0$3d7696ca@yourn6spa3hc62> Yes please is this the mailing list for secondlife my name there is melonice Miles some one talk to me please :) cheers deary -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070623/91af2d02/attachment.htm From blakar at gmail.com Sat Jun 23 02:53:52 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jun 23 02:53:56 2007 Subject: [sldev] getting serious about software. In-Reply-To: <1182569545.30666.34.camel@localhost> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> <1182569545.30666.34.camel@localhost> Message-ID: <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> Your reference seems incomplete. I assume what you wanted to tell us is that in the mean time you've learned that the compiler translates temp/2 or temp>>1 into a single instruction (SAR on intel) which handles the sign correctly (as long as you correctly typed your variable as being signed)? The issue in your attempted optimisation is that you try to replace integer math. Now this is something where you'll hardly be able to beat the compiler. The magic is in FP math and rarely in integer math. I'll give a fun example from the LL code: This is the current code for finding the next power of two: F32 next_power_of_two(F32 value) { S32 power = (S32)llceil((F32)log((double)value)/(F32)log(2.0)); return pow(2.0f, power); } Note that it is indeed a mathematically sane way to do it. This is my version, exploiting what we know of IEEE: inline F32 next_power_of_two(F32 value) { union { F32 result; S32 iresult; }; if (value <= 0) return 0; result=value; iresult&= 0x7F800000; iresult+= 0x00800000; return result; } What it does is rather simple: IEEE has you multiply 1.xxxxxx by a power of 2 to represent numbers. Now in such a situation the only way to store a power of 2 is by multiplying with 1.0. We hence first clear all the bits of the fraction so we get 1.0. Then we add 1 to the mantissa so we multiply with the next power of 2. Et voila, you're done :) On my Athlon 64 my code runs about 200 times faster than the current LL code. Admittedly it's not guaranteed to be fully portable. It requires 2 things: - The endianess is the same for float and int - Floats are stored in IEEE format My first bet would be that it's supported on all CPU's we want to work with (now and in the future). Are there any powerpc users who are willing to play guinea pig from time to time? :) Kind regards, Dirk aka Blakar Ogre On 6/23/07, Callum Lerwick wrote: > Don't underestimate the compiler's ability to optimize. I did a little > writeup on my LJ: > > http://ninjaseg.livejournal.com/49842.html > > Lesson: Code what you mean, "tmp / 2", and the compiler can optimize it > in the best way for the platform you tell it to target. > > Though notably, gcc 4.1 is too dumb to vectorize an integer divide on > its own. But on the other hand, vectorization hasn't proven to be a > benefit in this case. MMX/SSE really is of little benefit in a loop with > a single divide, in fact it seems to slow it down a little. Moving > things in and out of the registers is the bottleneck. Vectorization is > really only a benefit if you can keep it all in the registers and do a > large number of operations in a row. > > The cleanup on the way to vectorization has resulted in a measurable > speedup though. > > But the biggest speedup by far has been from reducing cache pollution > and memory overhead. > > > --- Write custom code for your math --- > > All modern CPU's support SIMD instructions aimed at 3D. Compilers > > don't convert your vector math for you, you need to do it yourself. > > Compilers are actually starting to be pretty good at autovectorization. > You still need to design the code with vectorization in mind. In gcc's > case, it is very picky about aliasing, basically requiring C99 > "restrict" to be used on all pointers, and assigning structure members > to temporary variables... > > I've experimented with Intel's compiler, but I can't actually get the > thing to link right on Fedora 6/7, so I've only been able to look at its > assembler output. > > _______________________________________________ > 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 Sat Jun 23 04:16:17 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jun 23 04:16:19 2007 Subject: [sldev] Popup ordering patch Message-ID: I've been musing on the issue of accidental click throughs on the popup dialogs. I mentioned this before in relation to the pay permissions one - that it is very easy to click on an existing popup, only for a new one to appear at just that instances and get clicked again. Although Able's pay permissions patch deals with a specific case, the general click through issue remains and I notice that someone on the forums refers to this in relation to the new popups generated in the recent anti-notecard-spam changes. It occured to me one solution would be to have new popups appear behind the existing ones, so even if a new popup appears you still end up clicking on the one you intended. You could argue that this is better behaviour in that you would then handle the popups in the order they appears. However, as this is a change in behaviour which doesn't reflect how dialogs normally work, it should probably be a configurable option. I've submitted a patch at https://jira.secondlife.com/browse/VWR-1344 which adds a new option in the Preferences Popups tab to toggle between the standard behaviour and this proposed behaviour. This is my first patch submission so let me know if I've not done in properly. Able Whitman's blog on his pay permissions patch was invaluable in pointing me at the right bits of the source code to look at to implement this. Matthew _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From nicholaz at blueflash.cc Sat Jun 23 05:49:08 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 23 05:49:29 2007 Subject: [sldev] getting serious about software. In-Reply-To: <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> <1182569545.30666.34.camel@localhost> <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> Message-ID: <467D16C4.1020303@blueflash.cc> > I'll give a fun example from the LL code: > > This is the current code for finding the next power of two: > F32 next_power_of_two(F32 value) > { > S32 power = (S32)llceil((F32)log((double)value)/(F32)log(2.0)); > return pow(2.0f, power); > } Umm, what's most amusing is that for the fun of it I rewrote it to S32 and bit shifting (inside the function casting the parameter from F32 to S32 and the result back to F32) just to find later that the function is only called two times in the following form: sides = (S32)next_power_of_two((F32)sides); ROFLMAO :-) (Not that this has any real impact on the program runtime.) Nick From nicholaz at blueflash.cc Sat Jun 23 06:28:05 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 23 06:28:30 2007 Subject: [sldev] getting serious about software. In-Reply-To: <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> <1182569545.30666.34.camel@localhost> <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> Message-ID: <467D1FE5.5090506@blueflash.cc> Just for the fun of it, here's my version (it's exactly the same behavior as the float version, not rounding up numbers that are already powers of two). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ -------------- next part -------------- --- linden-orig\indra\llmath\llvolume.cpp 2007-06-13 10:13:18.000000000 +0200 +++ linden\indra\llmath\llvolume.cpp 2007-06-23 15:06:49.921875000 +0200 @@ -461,6 +461,16 @@ return pow(2.0f, power); } +S32 next_power_of_two(S32 n) +{ + S32 res = (n<(1<<15)) ? (1<<15) : (1<<30); + + while (res>=n) { + res>>= 1; + } + + return (res<<1); +} BOOL LLProfile::generate(BOOL path_open,F32 detail, S32 split, BOOL is_sculpted) @@ -605,7 +615,7 @@ S32 sides = (S32)circle_detail; if (is_sculpted) - sides = (S32)next_power_of_two((F32)sides); + sides = next_power_of_two(sides); genNGon(sides); @@ -1148,7 +1158,7 @@ S32 sides = (S32)llfloor(llfloor((MIN_DETAIL_FACES * detail + twist_mag * 3.5f * (detail-0.5f))) * mParams.getRevolutions()); if (is_sculpted) - sides = (S32)next_power_of_two((F32)sides); + sides = next_power_of_two(sides); genNGon(sides); } From sllists at boroon.dasgupta.ch Sat Jun 23 06:33:51 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat Jun 23 06:34:05 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <467A2837.8040001@ucsd.edu> References: <467A2837.8040001@ucsd.edu> Message-ID: <40402.83.180.83.164.1182605631.squirrel@datendelphin.net> > Hi Anthony, > > It looks like 1.18.0.0 is missing scripts/template_verifier.py is there > anyway you could post this file to the list? I see the same bug under Linux, I think. Shall I expand VWR-1267's "Environment" accordingly and comment on it or rather file a separate bug and mark it as related? From soft at lindenlab.com Sat Jun 23 07:05:48 2007 From: soft at lindenlab.com (Soft Linden) Date: Sat Jun 23 07:05:50 2007 Subject: [sldev] Popup ordering patch In-Reply-To: References: Message-ID: <9e6e5c9e0706230705x2db321ale5aacde066a92793@mail.gmail.com> Sweet! I'm forwarding this to our usability guy in case he wants to chime in. I think we're trying to minimize the number of options in preferences so they don't obscure the more-frequently sought ones, but it may well be that pop-behind ought to be the default behavior instead of pop-to-front. On 6/23/07, Matthew Dowd wrote: > > I've been musing on the issue of accidental click throughs on the popup dialogs. I mentioned this before in relation to the pay permissions one - that it is very easy to click on an existing popup, only for a new one to appear at just that instances and get clicked again. Although Able's pay permissions patch deals with a specific case, the general click through issue remains and I notice that someone on the forums refers to this in relation to the new popups generated in the recent anti-notecard-spam changes. > > It occured to me one solution would be to have new popups appear behind the existing ones, so even if a new popup appears you still end up clicking on the one you intended. You could argue that this is better behaviour in that you would then handle the popups in the order they appears. However, as this is a change in behaviour which doesn't reflect how dialogs normally work, it should probably be a configurable option. > > I've submitted a patch at https://jira.secondlife.com/browse/VWR-1344 which adds a new option in the Preferences Popups tab to toggle between the standard behaviour and this proposed behaviour. This is my first patch submission so let me know if I've not done in properly. Able Whitman's blog on his pay permissions patch was invaluable in pointing me at the right bits of the source code to look at to implement this. > > Matthew > _________________________________________________________________ > 100's of Music vouchers to be won with MSN Music > https://www.musicmashup.co.uk/index.html_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From blakar at gmail.com Sat Jun 23 07:34:01 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jun 23 07:34:04 2007 Subject: [sldev] getting serious about software. In-Reply-To: <467D1FE5.5090506@blueflash.cc> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> <1182569545.30666.34.camel@localhost> <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> <467D1FE5.5090506@blueflash.cc> Message-ID: <7992d0d60706230734u14ce92b4q233018df6163569c@mail.gmail.com> > Just for the fun of it, here's my version > (it's exactly the same behavior as the float > version, not rounding up numbers that are already > powers of two). Ah yes, I took it literally (the next) and rewrote it for exercise (not for the viewer) and never checked if it actually got called with powers of 2 :-) Still my version returns floats so it does work beyond 2^31 even if it's not used ;-) It did give me some ideas on how I can do the ceil and floor stuff in C without resorting to the system calls (which are slow as you need to change rounding method). From nicholaz at blueflash.cc Sat Jun 23 07:46:12 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 23 07:46:36 2007 Subject: [sldev] getting serious about software. In-Reply-To: <7992d0d60706230734u14ce92b4q233018df6163569c@mail.gmail.com> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> <1182569545.30666.34.camel@localhost> <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> <467D1FE5.5090506@blueflash.cc> <7992d0d60706230734u14ce92b4q233018df6163569c@mail.gmail.com> Message-ID: <467D3234.4060507@blueflash.cc> Dirk Moerenhout wrote: > Ah yes, I took it literally (the next) and rewrote it for exercise > (not for the viewer) and never checked if it actually got called with > powers of 2 :-) Still my version returns floats so it does work beyond > 2^31 even if it's not used ;-) > > It did give me some ideas on how I can do the ceil and floor stuff in > C without resorting to the system calls (which are slow as you need to > change rounding method). Yep, mine was also just a fun thing, I just got curious about how it was called and that was really a good laugh when I saw it :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Sat Jun 23 09:14:17 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 23 09:14:39 2007 Subject: [sldev] Profiling and optimization In-Reply-To: <672B7BC888DC6DAA8C2205C9@[10.14.11.59]> References: <672B7BC888DC6DAA8C2205C9@[10.14.11.59]> Message-ID: <467D46D9.5050207@blueflash.cc> Did anyone try GlowCode on Windows? I ordered an Eval and tried it with their demo app, but it doesn't seem to show any function calls (just a thread list) for any of the SecondLife builds (either debug, NoOpt or ForDownload). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Douglas Soo wrote: > After watching the chatter fly on this list, I thought that it might be > worthwhile to write up a short summary of what we have found at Linden > to be effective approaches to profiling and optimizing code. > > > > It's pretty thing, but hopefully will be useful. > > - Doug > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From blakar at gmail.com Sat Jun 23 09:41:39 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sat Jun 23 09:41:42 2007 Subject: [sldev] Profiling and optimization In-Reply-To: <467D46D9.5050207@blueflash.cc> References: <672B7BC888DC6DAA8C2205C9@10.14.11.59> <467D46D9.5050207@blueflash.cc> Message-ID: <7992d0d60706230941q6469fa40m220cf4973554d670@mail.gmail.com> I haven't used it as I don't plan to pay for a profiler. I'm recently downloaded AMD's CodeAnalyst as it's the only free alternative for windows I know off. It works pretty well but I haven't managed to get the call stack sampling to work which I'd like to have. It does properly show you function names and can do drilldown to code and such. I did have an issue getting it to work with the ForDownload pdb but I figured out that compiling only viewer.cpp with /ZI is enough to have it working again. Dirk aka Blakar Ogre On 6/23/07, Nicholaz Beresford wrote: > > Did anyone try GlowCode on Windows? I ordered > an Eval and tried it with their demo app, but > it doesn't seem to show any function calls > (just a thread list) for any of the SecondLife > builds (either debug, NoOpt or ForDownload). > > > Nick > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Douglas Soo wrote: > > After watching the chatter fly on this list, I thought that it might be > > worthwhile to write up a short summary of what we have found at Linden > > to be effective approaches to profiling and optimizing code. > > > > > > > > It's pretty thing, but hopefully will be useful. > > > > - Doug > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dzonatas at dzonux.net Sat Jun 23 10:11:12 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jun 23 10:10:23 2007 Subject: [sldev] Profiling and optimization In-Reply-To: <7992d0d60706230941q6469fa40m220cf4973554d670@mail.gmail.com> References: <672B7BC888DC6DAA8C2205C9@10.14.11.59> <467D46D9.5050207@blueflash.cc> <7992d0d60706230941q6469fa40m220cf4973554d670@mail.gmail.com> Message-ID: <467D5430.5090306@dzonux.net> The profiler may need the executable to be compiled with "/FIXED:NO" in order to wrap all calls at run-time. Dirk Moerenhout wrote: > I haven't used it as I don't plan to pay for a profiler. I'm recently > downloaded AMD's CodeAnalyst as it's the only free alternative for > windows I know off. It works pretty well but I haven't managed to get > the call stack sampling to work which I'd like to have. > > It does properly show you function names and can do drilldown to code > and such. I did have an issue getting it to work with the ForDownload > pdb but I figured out that compiling only viewer.cpp with /ZI is > enough to have it working again. > > Dirk aka Blakar Ogre > > On 6/23/07, Nicholaz Beresford wrote: >> >> Did anyone try GlowCode on Windows? I ordered >> an Eval and tried it with their demo app, but >> it doesn't seem to show any function calls >> (just a thread list) for any of the SecondLife >> builds (either debug, NoOpt or ForDownload). >> >> >> Nick >> >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Douglas Soo wrote: >> > After watching the chatter fly on this list, I thought that it >> might be >> > worthwhile to write up a short summary of what we have found at Linden >> > to be effective approaches to profiling and optimizing code. >> > >> > >> > >> > It's pretty thing, but hopefully will be useful. >> > >> > - Doug >> > >> > >> > >> ------------------------------------------------------------------------ >> > >> > _______________________________________________ >> > Click here to unsubscribe or manage your list subscription: >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From seg at haxxed.com Sat Jun 23 13:08:56 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jun 23 13:08:15 2007 Subject: [sldev] getting serious about software. In-Reply-To: <467D1FE5.5090506@blueflash.cc> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> <1182569545.30666.34.camel@localhost> <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> <467D1FE5.5090506@blueflash.cc> Message-ID: <1182629336.32691.17.camel@localhost> On Sat, 2007-06-23 at 15:28 +0200, Nicholaz Beresford wrote: > Just for the fun of it, here's my version > (it's exactly the same behavior as the float > version, not rounding up numbers that are already > powers of two). > +S32 next_power_of_two(S32 n) > +{ > + S32 res = (n<(1<<15)) ? (1<<15) : (1<<30); > + > + while (res>=n) { > + res>>= 1; > + } > + > + return (res<<1); > +} This is a little over twice as fast on my Athlon 64, about a third faster on my PIII, and a quarter faster on my G3 iMac: int next_power_of_two2(int v){ v--; v |= v >> 1; v |= v >> 2; v |= v >> 4; v |= v >> 8; v |= v >> 16; v++; return v; } (Snagged from here: http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2Float ) At any rate, the existing version is reeeally slow. Please Jira this. -------------- 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/20070623/f23e284b/attachment.pgp From rdw at lindenlab.com Sat Jun 23 14:50:31 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Sat Jun 23 14:50:10 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <467A2837.8040001@ucsd.edu> References: <467A2837.8040001@ucsd.edu> Message-ID: <467D95A7.4000804@lindenlab.com> Sorry about the omission! template_verifier.py actually has 4 dependencies, which should all be ready for posting after the weekend. For now though, try just working around it by writing a no-op .py in its place. -RYaN Max Okumoto wrote: > Hi Anthony, > > It looks like 1.18.0.0 is missing scripts/template_verifier.py is > there anyway you could post this file to the list? > > Max > > Did anyone try this yet under Windows? > > ------ Build started: Project: newview, Configuration: > ReleaseForDownload Win32 ------ > Executing pre-build batch file > '"../../scripts/template_verifier.py"' is not recognized as an > internal or external command, > operable program or batch file. > PREBUILD FAILED > newview : error PRJ0002 : error result returned from > 'w:\sl1_18_0_0\linden\indra\newview\ReleaseForDownload\BAT00002E.bat'. > > > > Nick > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From okumoto at ucsd.edu Sat Jun 23 14:53:52 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sat Jun 23 14:54:06 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <467D95A7.4000804@lindenlab.com> References: <467A2837.8040001@ucsd.edu> <467D95A7.4000804@lindenlab.com> Message-ID: <467D9670.1080209@ucsd.edu> Ok thanks. I had done that but hadn't really drilled down to see if that was ok. Max Ryan Williams wrote: > Sorry about the omission! template_verifier.py actually has 4 > dependencies, which should all be ready for posting after the > weekend. For now though, try just working around it by writing a > no-op .py in its place. > > -RYaN > > Max Okumoto wrote: >> Hi Anthony, >> >> It looks like 1.18.0.0 is missing scripts/template_verifier.py is >> there anyway you could post this file to the list? >> >> Max >> >> Did anyone try this yet under Windows? >> >> ------ Build started: Project: newview, Configuration: >> ReleaseForDownload Win32 ------ >> Executing pre-build batch file >> '"../../scripts/template_verifier.py"' is not recognized as an >> internal or external command, >> operable program or batch file. >> PREBUILD FAILED >> newview : error PRJ0002 : error result returned from >> >> 'w:\sl1_18_0_0\linden\indra\newview\ReleaseForDownload\BAT00002E.bat'. >> >> >> >> Nick >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> From secret.argent at gmail.com Sat Jun 23 15:18:53 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 23 15:18:52 2007 Subject: [sldev] Popup ordering patch In-Reply-To: <20070623124931.758E041AF25@stupor.lindenlab.com> References: <20070623124931.758E041AF25@stupor.lindenlab.com> Message-ID: <1BA23C81-D0AA-4C79-9EAE-CEDE0EE292B9@gmail.com> The big issue with click-through isn't really having a popup timed to come up on top of an existing benign dialog, it's having a lot of similar dialogs up at once and clicking through them all to clear them... and having one of them take money from you. For example, this is what people who spam group invites to "pay to join" groups depended on... people logging in and having a bunch of "You got an IM from FOO" and "BAR has given you an object" messages, and clicking "join" accidentally. There's three classes of dialog that we should be thinking about here: 1. dialogs for which the results are easily reversed, eg: friending. 2. dialogs for which the results are hard or impossible to reverse, eg: certain permissions 3. dialogs for which results can include an irreversible loss of money or inventory, eg: payment Then there's a second dimension: a. dialogs that are triggered only by a user's explicit action. "do you really want to do that?" b. dialogs that are triggered asyncronously. There should probably be few if any "a" type dialogs, and it should be possible for the user to disable most of them, though there's a few special cases (like granting someone permission to modify your objects) that should be rare and the dialog shouldn't be disabled. Type A and B dialogs should probably look different. Class 3 dialogs should probably look different. I don't think popup ordering should be changed, unless there's some kind of clear and obvious effect to clearly indicate that there's new dialogs coming in. For example, having a stylized stack with its depth proportional to the number of dialogs "below" the displayed dialog. From seg at haxxed.com Sat Jun 23 15:36:22 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jun 23 15:35:39 2007 Subject: [sldev] getting serious about software. In-Reply-To: <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> <1182569545.30666.34.camel@localhost> <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> Message-ID: <1182638182.32691.20.camel@localhost> On Sat, 2007-06-23 at 11:53 +0200, Dirk Moerenhout wrote: > Your reference seems incomplete. I assume what you wanted to tell us > is that in the mean time you've learned that the compiler translates > temp/2 or temp>>1 into a single instruction (SAR on intel) which > handles the sign correctly (as long as you correctly typed your > variable as being signed)? Nope, three instructions. Simply shifting is incorrect with a negative value, and a lot of programmers don't seem to realize this. I didn't until I broke 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/20070623/7718d0cf/attachment.pgp From matthew.dowd at hotmail.co.uk Sat Jun 23 15:49:33 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jun 23 15:49:34 2007 Subject: [sldev] Popup ordering patch Message-ID: > The big issue with click-through isn't really having a popup timed to > come up on top of an existing benign dialog, it's having a lot of > similar dialogs up at once and clicking through them all to clear > them... and having one of them take money from you. I agree that is an issue, but not the one I was directly tackling. The issue I was tackling is when you have two dialogs in quick succession (as happens when shopping - the you have paid quickly followed by the you have received dialog). It is not uncommon (in fact surprisingly common) that the second dialog appears just as you are closing the first with the result it is the second which closes. Whether the action is reversible becomes somewhat mute as you often haven't had time to see what the dialog was. > I don't think popup ordering should be changed, unless there's some > kind of clear and obvious effect to clearly indicate that there's new > dialogs coming in. For example, having a stylized stack with its > depth proportional to the number of dialogs "below" the displayed > dialog. The way I've implemented the patch is although the dialog is placed at the bottom of the stack, I still call moveToBack() as that was the quickest why of ensuring the ">>>" button appears, and the appearance of that button is the visual clue there are more dialogs behind. moveToBack in turn calls triggerFocusFlash so there is also a visual clue when a new dialog comes in. This may not be as rich but I think sufficient. I'm afraid that the visual clues you describe go beyond my understanding of the code at the moment (I only started looking at the source code Friday!) The other ordering also makes better sense when dealing with group messages etc when you first log on (I quite often read group messages which refer to or correct to an earlier group message which of course is further down the stack I'm working through). However, I suspect that some would like the reverse order and some would hate it, hence I made it configurable. Matthew _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com/index2.html From okumoto at ucsd.edu Sat Jun 23 15:58:10 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sat Jun 23 15:58:14 2007 Subject: [sldev] Popup ordering patch In-Reply-To: <1BA23C81-D0AA-4C79-9EAE-CEDE0EE292B9@gmail.com> References: <20070623124931.758E041AF25@stupor.lindenlab.com> <1BA23C81-D0AA-4C79-9EAE-CEDE0EE292B9@gmail.com> Message-ID: <467DA582.3080701@ucsd.edu> Maybe it would be a good idea to have a "lock protecting your wallet". Or at least some sort of governor that limits the size of transactions. You don't walk around with cash in your hands all day long. You leave it in your wallet until you need to buy something. Max Argent Stonecutter wrote: > The big issue with click-through isn't really having a popup timed to > come up on top of an existing benign dialog, it's having a lot of > similar dialogs up at once and clicking through them all to clear > them... and having one of them take money from you. > > For example, this is what people who spam group invites to "pay to > join" groups depended on... people logging in and having a bunch of > "You got an IM from FOO" and "BAR has given you an object" messages, > and clicking "join" accidentally. > > There's three classes of dialog that we should be thinking about here: > > 1. dialogs for which the results are easily reversed, eg: friending. > 2. dialogs for which the results are hard or impossible to reverse, > eg: certain permissions > 3. dialogs for which results can include an irreversible loss of money > or inventory, eg: payment > > Then there's a second dimension: > > a. dialogs that are triggered only by a user's explicit action. "do > you really want to do that?" > b. dialogs that are triggered asyncronously. > > There should probably be few if any "a" type dialogs, and it should be > possible for the user to disable most of them, though there's a few > special cases (like granting someone permission to modify your > objects) that should be rare and the dialog shouldn't be disabled. > > Type A and B dialogs should probably look different. > > Class 3 dialogs should probably look different. > > I don't think popup ordering should be changed, unless there's some > kind of clear and obvious effect to clearly indicate that there's new > dialogs coming in. For example, having a stylized stack with its depth > proportional to the number of dialogs "below" the displayed dialog. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From secret.argent at gmail.com Sat Jun 23 17:04:51 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sat Jun 23 17:04:49 2007 Subject: [sldev] Popup ordering patch In-Reply-To: <467DA582.3080701@ucsd.edu> References: <20070623124931.758E041AF25@stupor.lindenlab.com> <1BA23C81-D0AA-4C79-9EAE-CEDE0EE292B9@gmail.com> <467DA582.3080701@ucsd.edu> Message-ID: <3166FC78-349D-48BA-923D-59F483363A14@gmail.com> On 23-Jun-2007, at 17:58, Max Okumoto wrote: > Maybe it would be a good idea to have a "lock protecting your > wallet". Or at least some sort > of governor that limits the size of transactions. That may be a good idea, but it doesn't really address the problem I'm talking about. When people spam with for-fee group joins those are all small transactions, and a debit attack can be slow enough that it doesn't trigger any threshold. That would be useful for gambling situations, though. You could set your "daily debit limit" to your stake. Also, that's really out of the scope of this list, since that kind of lock would have to be server-side. From chance at kalacia.com Sat Jun 23 17:33:32 2007 From: chance at kalacia.com (Chance Unknown) Date: Sat Jun 23 17:33:39 2007 Subject: [sldev] Popup ordering patch In-Reply-To: <3166FC78-349D-48BA-923D-59F483363A14@gmail.com> References: <20070623124931.758E041AF25@stupor.lindenlab.com> <1BA23C81-D0AA-4C79-9EAE-CEDE0EE292B9@gmail.com> <467DA582.3080701@ucsd.edu> <3166FC78-349D-48BA-923D-59F483363A14@gmail.com> Message-ID: <2925011a0706231733v42773ae1y1ee52f89b769dae3@mail.gmail.com> you act like you dont know how to move your money to an alt as a mule. why would you encumber people from spending in world funds? if you dont want to spend your money, then dont keep any. On 6/23/07, Argent Stonecutter wrote: > > > On 23-Jun-2007, at 17:58, Max Okumoto wrote: > > Maybe it would be a good idea to have a "lock protecting your > > wallet". Or at least some sort > > of governor that limits the size of transactions. > > That may be a good idea, but it doesn't really address the problem > I'm talking about. When people spam with for-fee group joins those > are all small transactions, and a debit attack can be slow enough > that it doesn't trigger any threshold. > > That would be useful for gambling situations, though. You could set > your "daily debit limit" to your stake. > > Also, that's really out of the scope of this list, since that kind of > lock would have to be server-side. > _______________________________________________ > 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/20070623/78248521/attachment-0001.htm From dale at daleglass.net Sat Jun 23 18:48:24 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Jun 23 18:48:41 2007 Subject: [sldev] Initial viewer/object communication code Message-ID: <200706240348.31246.dale@daleglass.net> I've been working on a general solution to the problem. See the wiki for a detailed explanation: https://wiki.secondlife.com/wiki/LSL_To_Client_Communication I've been working on the code and have just finished the first draft. There are two parts to this, the viewer side, and the LSL script side. The script side is explained in the wiki. The viewer side works like this: #include "llviewercommunication.h" const LLString EXT_NAME = "DaleGlass.Echo"; const U32 EXT_VERSION = 1; // This gets called when the script sends something to our name void echo(LLString& data, LLViewerCircuit& circuit, void* userdata) { llinfos << "I got: " << data << llendl; circuit.sendReply(data); } Plugin::Plugin() { // Register callback gViewerCommunication->registerExtension( LLViewerExtension(EXT_NAME, EXT_VERSION, echo, NULL, "Dale Glass", "Echo extension") ); } LSL code (connection establishment not shown): llOwnerSay("$VwrComm$0$DaleGlass.Echo$This will be echoed at me"); The code is in SVN here: http://svn.daleglass.net/sl/branches/viewercomm/ The patch is here: http://daleglass.net/viewercomm.patch Here is the LSL script that tests the above patch: http://daleglass.net/viewercomm_test.lsl -------------- 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/20070624/83e5d8e6/attachment.pgp From tateru.nino at gmail.com Sat Jun 23 19:38:41 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Jun 23 19:38:49 2007 Subject: [sldev] Popup ordering patch In-Reply-To: References: Message-ID: <467DD931.6050501@gmail.com> Matthew Dowd wrote: >> The big issue with click-through isn't really having a popup timed to >> come up on top of an existing benign dialog, it's having a lot of >> similar dialogs up at once and clicking through them all to clear >> them... and having one of them take money from you. >> > > I agree that is an issue, but not the one I was directly tackling. The issue I was tackling is when you have two dialogs in quick succession (as happens when shopping - the you have paid quickly followed by the you have received dialog). It is not uncommon (in fact surprisingly common) that the second dialog appears just as you are closing the first with the result it is the second which closes. Whether the action is reversible becomes somewhat mute as you often haven't had time to see what the dialog was. This happens to me A LOT. I'll be clicking on one of the buttons on a popup, and as the mouse button is moving those few microns to close the contact, something else pops up - and is gone. And I have no idea what it said. Did I just keep something or join something or allow something? You tell me. I saw it flicker onto my screen, but not for long enough to see the words before it was gone. -- Tateru Nino http://dwellonit.blogspot.com/ From matthew.dowd at hotmail.co.uk Sun Jun 24 02:03:17 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Jun 24 02:03:19 2007 Subject: [sldev] Popup ordering patch Message-ID: I'm glad it ins't just me ;-) The difference between the two click through issues is this - in the situation Argent describes (clicking through a lot of dialogs without reading them), the solution is really a social one rather than a technical one, i.e. teaching people to *read* before they click. We can add some visual cues to indicate different types of dialog but ultimately we are just reinforcing the message of *read* before you click, and no one has really solved this problem outside of SL (the latest approach being the modal fade screen dialog from Vista). The situation that I've tried to address and which Tateru describes, is one in which no matter how careful you are at reading things before clicking, a quirk in the user interface can result in you clicking on something you had no intention of clicking on before you've had a chance to read it. I've no idea how many people experience this - it could be that Tateru and myself are the only ones in the entire world cursed with this ability ;-) Matthew ---------------------------------------- > Date: Sun, 24 Jun 2007 12:38:41 +1000 > To: matthew.dowd@hotmail.co.uk > CC: sldev@lists.secondlife.com > Subject: Re: [sldev] Popup ordering patch > From: tateru.nino@gmail.com > > > > Matthew Dowd wrote: > >> The big issue with click-through isn't really having a popup timed to > >> come up on top of an existing benign dialog, it's having a lot of > >> similar dialogs up at once and clicking through them all to clear > >> them... and having one of them take money from you. > >> > > > > I agree that is an issue, but not the one I was directly tackling. The issue I was tackling is when you have two dialogs in quick succession (as happens when shopping - the you have paid quickly followed by the you have received dialog). It is not uncommon (in fact surprisingly common) that the second dialog appears just as you are closing the first with the result it is the second which closes. Whether the action is reversible becomes somewhat mute as you often haven't had time to see what the dialog was. > This happens to me A LOT. I'll be clicking on one of the buttons on a > popup, and as the mouse button is moving those few microns to close the > contact, something else pops up - and is gone. And I have no idea what > it said. > > Did I just keep something or join something or allow something? You tell > me. I saw it flicker onto my screen, but not for long enough to see the > words before it was gone. > > -- > Tateru Nino > http://dwellonit.blogspot.com/ > _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From okumoto at ucsd.edu Sun Jun 24 02:04:44 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sun Jun 24 02:04:49 2007 Subject: [sldev] Can someone clarify the object naming conventions llvosky.h vs llsky.h In-Reply-To: <467A9AA9.90507@lindenlab.com> References: <467A1745.7010302@ucsd.edu> <467A3CA0.9030509@blueflash.cc> <467A9AA9.90507@lindenlab.com> Message-ID: <467E33AC.6090301@ucsd.edu> Hi Brad, I tried to compile the windlight-1-17-0 branch, but ran into a slight problem. I don't have the glh headers. llwindow/llgl.cpp:47:28: glh/glh_linear.h: No such file or directory llwindow/llgl.cpp:48:33: glh/glh_convenience.h: No such file or directory Googling for them seems to indicate that those are NVIDA header files. Are there any patches for using ATI drivers? Max Brad Linden wrote: > > First, a real short introduction: I'm Brad Linden and joined the > Boston area office of Linden Lab last month. I've been working on > WindLight (available at > http://svn.secondlife.com/svn/linden/branches/2007/windlight_1-17-0/). > You can see Zen's blog post > (http://blog.secondlife.com/2007/06/14/windlight-update/) and Torley's > post > (http://blog.secondlife.com/2007/05/21/windlight-atmospheric-rendering-comes-to-second-life/) > for more details. > > > Nicholaz Beresford wrote: >> >> Just off hand and without looking deeper, I think >> the "VO" stands for Viewer-Object (think these >> are derived from LLViewerObject) >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> > That is correct. The LLSky class is a global singleton (gSky) for > managing access to anything related to the sky, including the LLVOSky > instance (gSky.mVOSkyp). > >> Max Okumoto wrote: >>> Hi, >>> >>> Can someone at LL explain the llvosky.h vs llsky.h naming convention? >>> >>> My cpu profiling says that LLVOSky::calcSkyColorInDir() is consuming >>> about 5%, so I have started seeing if I can speed it up. >>> >>> Max > > You might want to wait before spending too much time on that, or at > least not work on that branch. If you look at the WindLight branch > you'll see that that function has been completely replaced with > something much more cpu-intensive, but updated less frequently. It's > essentially a straightforward attempt at imitating the WindLight sky > glsl shaders in > indra/newview/app_settings/shaders/class2/windlight/WLSkyV.glsl and > indra/newview/app_settings/shaders/class2/windlight/WLSkyF.glsl. If > you want to try to optimize the sky CPU code, this branch is the place > to do it, but take note that on systems that have a GPU and OpenGL > drivers that can run WindLight, this code is obsoleted by the new > LLVOWLSky class, and the LLVOSky class will be largely disabled (this > is not happening properly in the snapshot we exported to the public > svn server). > > As our focus has been on getting the new GPU rendered WindLight > codepath working on as many hardware configurations as possible, the > CPU rendering code in LLVOSky has not had as much attention, as it's > really not suited for the way WindLight works and may need a complete > refactoring, and there are major outstanding bugs in it: > https://jira.secondlife.com/browse/VWR-980. Any contributions to the > CPU fallback code in LLVOSky would be much appreciated. > > So in summary, if you want to work on sky code and get your code used > after WindLight gets merged into the trunk, work in the WindLight > branch. If you have questions about what you find there, I'm your man. > > hope this helps, > -Brad Linden -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070624/75982218/attachment.htm From okumoto at ucsd.edu Sun Jun 24 02:09:48 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Sun Jun 24 02:09:51 2007 Subject: [sldev] Can someone clarify the object naming conventions llvosky.h vs llsky.h In-Reply-To: <467E33AC.6090301@ucsd.edu> References: <467A1745.7010302@ucsd.edu> <467A3CA0.9030509@blueflash.cc> <467A9AA9.90507@lindenlab.com> <467E33AC.6090301@ucsd.edu> Message-ID: <467E34DC.40501@ucsd.edu> Never mind, I miss read the header. I just need to down load the glgui package. Max Max Okumoto wrote: > Hi Brad, > > I tried to compile the windlight-1-17-0 branch, but ran into a slight > problem. I don't have the glh headers. > > llwindow/llgl.cpp:47:28: glh/glh_linear.h: No such file or directory > llwindow/llgl.cpp:48:33: glh/glh_convenience.h: No such file or > directory > > Googling for them seems to indicate that those are NVIDA header > files. Are there any patches > for using ATI drivers? > > Max > > Brad Linden wrote: >> >> First, a real short introduction: I'm Brad Linden and joined the >> Boston area office of Linden Lab last month. I've been working on >> WindLight (available at >> http://svn.secondlife.com/svn/linden/branches/2007/windlight_1-17-0/). >> You can see Zen's blog post >> (http://blog.secondlife.com/2007/06/14/windlight-update/) and >> Torley's post >> (http://blog.secondlife.com/2007/05/21/windlight-atmospheric-rendering-comes-to-second-life/) >> for more details. >> >> >> Nicholaz Beresford wrote: >>> >>> Just off hand and without looking deeper, I think >>> the "VO" stands for Viewer-Object (think these >>> are derived from LLViewerObject) >>> >>> >>> Nick >>> >>> >>> Second Life from the inside out: >>> http://nicholaz-beresford.blogspot.com/ >>> >>> >> That is correct. The LLSky class is a global singleton (gSky) for >> managing access to anything related to the sky, including the LLVOSky >> instance (gSky.mVOSkyp). >> >>> Max Okumoto wrote: >>>> Hi, >>>> >>>> Can someone at LL explain the llvosky.h vs llsky.h naming convention? >>>> >>>> My cpu profiling says that LLVOSky::calcSkyColorInDir() is consuming >>>> about 5%, so I have started seeing if I can speed it up. >>>> >>>> Max >> >> You might want to wait before spending too much time on that, or at >> least not work on that branch. If you look at the WindLight branch >> you'll see that that function has been completely replaced with >> something much more cpu-intensive, but updated less frequently. It's >> essentially a straightforward attempt at imitating the WindLight sky >> glsl shaders in >> indra/newview/app_settings/shaders/class2/windlight/WLSkyV.glsl and >> indra/newview/app_settings/shaders/class2/windlight/WLSkyF.glsl. If >> you want to try to optimize the sky CPU code, this branch is the >> place to do it, but take note that on systems that have a GPU and >> OpenGL drivers that can run WindLight, this code is obsoleted by the >> new LLVOWLSky class, and the LLVOSky class will be largely disabled >> (this is not happening properly in the snapshot we exported to the >> public svn server). >> >> As our focus has been on getting the new GPU rendered WindLight >> codepath working on as many hardware configurations as possible, the >> CPU rendering code in LLVOSky has not had as much attention, as it's >> really not suited for the way WindLight works and may need a complete >> refactoring, and there are major outstanding bugs in it: >> https://jira.secondlife.com/browse/VWR-980. Any contributions to the >> CPU fallback code in LLVOSky would be much appreciated. >> >> So in summary, if you want to work on sky code and get your code used >> after WindLight gets merged into the trunk, work in the WindLight >> branch. If you have questions about what you find there, I'm your man. >> >> hope this helps, >> -Brad Linden > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Sun Jun 24 04:32:47 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sun Jun 24 04:32:50 2007 Subject: [sldev] Jira down? Message-ID: Is Jira down? Matthew _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From tateru.nino at gmail.com Sun Jun 24 05:24:12 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sun Jun 24 05:24:18 2007 Subject: [sldev] Jira down? In-Reply-To: References: Message-ID: <467E626C.5070704@gmail.com> Matthew Dowd wrote: > Is Jira down? > Seems to be. It's certainly not responding to me. Server's running but JIRA itself isn't answering before the connection times out. -- Tateru Nino http://dwellonit.blogspot.com/ From nicholaz at blueflash.cc Sun Jun 24 06:53:10 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 24 06:53:20 2007 Subject: [sldev] Jira down? In-Reply-To: References: Message-ID: <467E7746.1070100@blueflash.cc> Seems so ... fourth week in a row on Weekends :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Matthew Dowd wrote: > Is Jira down? > > Matthew > > _________________________________________________________________ > Feel like a local wherever you go with BackOfMyHand.com > http://www.backofmyhand.com_______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Sun Jun 24 08:38:23 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 24 08:38:32 2007 Subject: [sldev] VWR-1354 / crash in drawpool Message-ID: <467E8FEF.4030109@blueflash.cc> Please have a look, in case I missed something: https://jira.secondlife.com/browse/VWR-1354 Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ -------------- next part -------------- --- linden-orig\indra\newview\lldrawpool.cpp 2007-06-13 10:13:20.000000000 +0200 +++ linden\indra\newview\lldrawpool.cpp 2007-06-24 17:27:39.140625000 +0200 @@ -473,8 +473,10 @@ for (std::vector::const_iterator k = draw_info.begin(); k != draw_info.end(); ++k) { - LLDrawInfo& params = **k; - pushBatch(params, mask, texture); + LLDrawInfo *pparams = *k; + if (pparams) { + pushBatch(*pparams, mask, texture); + } } } @@ -489,12 +491,16 @@ U32* indices_pointer = NULL; for (std::vector::iterator i = draw_info.begin(); i != draw_info.end(); ++i) { - LLDrawInfo& params = **i; - params.mVertexBuffer->setBuffer(mask); - indices_pointer = (U32*) params.mVertexBuffer->getIndicesPointer(); - glDrawRangeElements(GL_TRIANGLES, params.mStart, params.mEnd, params.mCount, - GL_UNSIGNED_INT, indices_pointer+params.mOffset); - gPipeline.mTrianglesDrawn += params.mCount/3; + LLDrawInfo *pparams = *i; + if (pparams && pparams->mVertexBuffer.notNull()) + { + LLDrawInfo& params = *pparams; + params.mVertexBuffer->setBuffer(mask); + indices_pointer = (U32*) params.mVertexBuffer->getIndicesPointer(); + glDrawRangeElements(GL_TRIANGLES, params.mStart, params.mEnd, params.mCount, + GL_UNSIGNED_INT, indices_pointer+params.mOffset); + gPipeline.mTrianglesDrawn += params.mCount/3; + } } } @@ -508,18 +514,15 @@ for (std::vector::iterator i = draw_info.begin(); i != draw_info.end(); ++i) { - LLDrawInfo& params = **i; - pushBatch(params, mask, TRUE); + LLDrawInfo* pparams = *i; + if (pparams) { + pushBatch(*pparams, mask, TRUE); + } } } void LLRenderPass::pushBatch(LLDrawInfo& params, U32 mask, BOOL texture) { - if (params.mVertexBuffer.isNull()) - { - return; - } - if (texture) { if (params.mTexture.notNull()) @@ -537,12 +540,15 @@ LLImageGL::unbindTexture(0); } } - - params.mVertexBuffer->setBuffer(mask); - U32* indices_pointer = (U32*) params.mVertexBuffer->getIndicesPointer(); - glDrawRangeElements(GL_TRIANGLES, params.mStart, params.mEnd, params.mCount, - GL_UNSIGNED_INT, indices_pointer+params.mOffset); - gPipeline.mTrianglesDrawn += params.mCount/3; + + if (params.mVertexBuffer.notNull()) + { + params.mVertexBuffer->setBuffer(mask); + U32* indices_pointer = (U32*) params.mVertexBuffer->getIndicesPointer(); + glDrawRangeElements(GL_TRIANGLES, params.mStart, params.mEnd, params.mCount, + GL_UNSIGNED_INT, indices_pointer+params.mOffset); + gPipeline.mTrianglesDrawn += params.mCount/3; + } if (params.mTextureMatrix && texture && params.mTexture.notNull()) { From blakar at gmail.com Sun Jun 24 15:09:54 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Sun Jun 24 15:09:57 2007 Subject: [sldev] getting serious about software. In-Reply-To: <1182638182.32691.20.camel@localhost> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> <1182569545.30666.34.camel@localhost> <7992d0d60706230253u5953c394ve3bbbc0150fdb4b0@mail.gmail.com> <1182638182.32691.20.camel@localhost> Message-ID: <7992d0d60706241509l402126d1r565297ed2a8d35df@mail.gmail.com> The difference between / and >> is rounding. A shift will round the result away from zero for a negative and towards zero for a positive. / will in both cases round towards zero. The compiler will hence add additional instructions to give you the rounding you expect if you use / but it'll not if you use >>. In both cases the division itself is a single instruction. Still, as I said before, it's integer math and you won't be able to beat the compiler. The only thing you can exploit is that you get to pick between / and >> where >> will be faster if you are ok with the rounding. Given you broke OpenJPEG by using shifts I guess it requires rounding towards 0 :) Dirk aka Blakar Ogre On 6/24/07, Callum Lerwick wrote: > On Sat, 2007-06-23 at 11:53 +0200, Dirk Moerenhout wrote: > > Your reference seems incomplete. I assume what you wanted to tell us > > is that in the mean time you've learned that the compiler translates > > temp/2 or temp>>1 into a single instruction (SAR on intel) which > > handles the sign correctly (as long as you correctly typed your > > variable as being signed)? > > Nope, three instructions. Simply shifting is incorrect with a negative > value, and a lot of programmers don't seem to realize this. I didn't > until I broke OpenJPEG... > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From soft at lindenlab.com Sun Jun 24 16:24:13 2007 From: soft at lindenlab.com (Soft Linden) Date: Sun Jun 24 16:24:25 2007 Subject: [sldev] Jira down? In-Reply-To: <467E7746.1070100@blueflash.cc> References: <467E7746.1070100@blueflash.cc> Message-ID: <9e6e5c9e0706241624t669c3a7yf3b07c7e96cce65b@mail.gmail.com> It's been working all day, but dog ass slow for me. Let's bring this up during Rob's office hours - maybe something's broken, or maybe we're overdue for a machine upgrade with more and more residents starting to use it? On 6/24/07, Nicholaz Beresford wrote: > > Seems so ... fourth week in a row on Weekends :-) > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Matthew Dowd wrote: > > Is Jira down? > > > > Matthew > > > > _________________________________________________________________ > > Feel like a local wherever you go with BackOfMyHand.com > > http://www.backofmyhand.com_______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From nicholaz at blueflash.cc Sun Jun 24 16:48:19 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sun Jun 24 16:48:25 2007 Subject: [sldev] Jira down? In-Reply-To: <9e6e5c9e0706241624t669c3a7yf3b07c7e96cce65b@mail.gmail.com> References: <467E7746.1070100@blueflash.cc> <9e6e5c9e0706241624t669c3a7yf3b07c7e96cce65b@mail.gmail.com> Message-ID: <467F02C3.2020800@blueflash.cc> It's probably due for update, someone recently mentioned that there was a newer version with the indexing error fixed. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Soft Linden wrote: > It's been working all day, but dog ass slow for me. > > Let's bring this up during Rob's office hours - maybe something's > broken, or maybe we're overdue for a machine upgrade with more and > more residents starting to use it? > > > On 6/24/07, Nicholaz Beresford wrote: >> >> Seems so ... fourth week in a row on Weekends :-) >> >> >> Nick >> >> >> Second Life from the inside out: >> http://nicholaz-beresford.blogspot.com/ >> >> >> Matthew Dowd wrote: >> > Is Jira down? >> > >> > Matthew >> > >> > _________________________________________________________________ >> > Feel like a local wherever you go with BackOfMyHand.com >> > >> http://www.backofmyhand.com_______________________________________________ >> >> > Click here to unsubscribe or manage your list subscription: >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> From able.whitman at gmail.com Sun Jun 24 17:10:01 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sun Jun 24 17:10:04 2007 Subject: [sldev] Jira down? In-Reply-To: <467F02C3.2020800@blueflash.cc> References: <467E7746.1070100@blueflash.cc> <9e6e5c9e0706241624t669c3a7yf3b07c7e96cce65b@mail.gmail.com> <467F02C3.2020800@blueflash.cc> Message-ID: <7b3a84fb0706241710w3a3805c0nc01fd5278f32ba17@mail.gmail.com> Especially since all residents are being encouraged to use JIRA for every bug report, feature suggestion, etc., an upgraded system is a great idea :) On 6/24/07, Nicholaz Beresford wrote: > > > It's probably due for update, someone recently > mentioned that there was a newer version with the > indexing error fixed. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Soft Linden wrote: > > It's been working all day, but dog ass slow for me. > > > > Let's bring this up during Rob's office hours - maybe something's > > broken, or maybe we're overdue for a machine upgrade with more and > > more residents starting to use it? > > > > > > On 6/24/07, Nicholaz Beresford wrote: > >> > >> Seems so ... fourth week in a row on Weekends :-) > >> > >> > >> Nick > >> > >> > >> Second Life from the inside out: > >> http://nicholaz-beresford.blogspot.com/ > >> > >> > >> Matthew Dowd wrote: > >> > Is Jira down? > >> > > >> > Matthew > >> > > >> > _________________________________________________________________ > >> > Feel like a local wherever you go with BackOfMyHand.com > >> > > >> > http://www.backofmyhand.com_______________________________________________ > >> > >> > Click here to unsubscribe or manage your list subscription: > >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> _______________________________________________ > >> 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/20070624/6304cde0/attachment.htm From soft at lindenlab.com Sun Jun 24 17:31:53 2007 From: soft at lindenlab.com (Soft Linden) Date: Sun Jun 24 17:31:55 2007 Subject: [sldev] CPU and GPU statistics In-Reply-To: <7992d0d60706201650r20909705i3aa87200786804ea@mail.gmail.com> References: <9e6e5c9e0706201614p44340c6ch72b3710c795d062a@mail.gmail.com> <7992d0d60706201650r20909705i3aa87200786804ea@mail.gmail.com> Message-ID: <9e6e5c9e0706241731t32f0d24er1c0093d349696dfb@mail.gmail.com> While assembling sldev-traffic for the week, I realized this email, and my response, had been private. Dirk confirmed that it was a mistake, and that it was okay to respond to the list. llprocessor.cpp is LL source. We're more than willing to accept any patches for additional information reporting you'd find helpful in viewer hacking. The Linden guru behind the initial report confirms willingness to run another report after the info's been added. On 6/20/07, Dirk Moerenhout wrote: > The CPU data is too generic to know which CPU's are really used. We > really need more precise info on which extension bits are set on the > x86 CPU's. Or at the least we'll need to update llprocessor.cpp. Now > there are way too many unknown models. Is llprocessor.cpp derived from > something public we can update to or do I just take the Intel and AMD > docs and fill the gaps? > > Dirk aka Blakar Ogre > > On 6/21/07, Soft Linden wrote: > > The question of what CPUs SL users have has come up a number of times, > > and I believe GPUs have been mentioned as well. Attached, please find > > statistics on CPUs and reported GPUs for all platforms over a similar > > one week period. > > > > I haven't made any attempt to consolidate similar CPUs and GPUs. I > > don't know enough about the models to know where I might omit > > something important, such as cache size or SIMD abilities varying > > between two clocks of a like part model. I did remove the labels from > > two graphic cards/drivers, where I wasn't sure that the name reported > > was accurate, or that it didn't reveal personal information. > > > > I formatted this as CSV, which should parse by Excel, OpenOffice, or > > your favorite perl script. > > > > Let me know if ya find any interesting surprises. If you want to take > > a swing at summarizing, grouping by capability, or the like, that > > would be awesome. > > > > If this message comes through without two attachments, then I've > > learned a lesson about utf-8 or attachment sizes :) > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > From soft at lindenlab.com Sun Jun 24 18:08:45 2007 From: soft at lindenlab.com (Soft Linden) Date: Sun Jun 24 18:08:47 2007 Subject: [sldev] Just askin': How are we doing? Message-ID: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> I'm convinced Linden Lab is doing a lot better with the open source community. - Rob is running bug and patch triage sessions - Bridie brings new developers into Studio Blacklight to learn to process your patches as part of their developer orientation, and many stay on to keep pulling those in - Many developers are now cutting through the patches at a frantic pace, with Sardonyx far in the lead - he's a buzzsaw! - The release team (or just Anthony?) is taking over source deployments to keep you better in sync with released viewers - We're making an effort to direct an increasing number of residents to the JIRA to vote on the patches you contribute as well as general reported bugs - Starting shortly, we'll hold a combined open source office hour where you can find Rob's steering, Liana's licensing and legal, and my developer input all in the same place. This raises a few questions for me. Firstly, from where you stand, *are* we doing better overall? Second, is there anything we're doing *worse*? Any recent changes you *don't* like? Lastly, what can we still do better? Are there one or two things that frustrate you the most, which we could make part of our third quarter goals? I've been looking at other open source projects for a while, looking for other ideas we can adopt. Nicholaz Beresford suggested watching the wine lists, which I've done, as well as looking in on a couple of the Linux distributions. I'm trying to identify the things we do differently, where they might have the better answer. I've got a small list I'm ready to discuss, including a couple of the long-standing pain points, but I want to get your input before pushing my own ideas. From soft at lindenlab.com Sun Jun 24 18:10:54 2007 From: soft at lindenlab.com (Soft Linden) Date: Sun Jun 24 18:10:57 2007 Subject: [sldev] SLDev-Traffic #17 - Now with 100% more Seventeen(tm) Message-ID: <9e6e5c9e0706241810m2b0ba69cj45a1c6c30bcb4b5a@mail.gmail.com> https://wiki.secondlife.com/wiki/SLDev-Traffic_17 SLDev-Traffic number 17 is up. Feel free to edit as always. That's why it's a wiki. Please use the original threads and talk pages if anything in the summary encourages further discussion. Thanks! From kerdezixe at gmail.com Sun Jun 24 18:55:01 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Sun Jun 24 18:55:02 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> Message-ID: <8a1bfe660706241855r6e10cc47m5e5758548429630@mail.gmail.com> On 6/25/07, Soft Linden wrote: > Are there one or two things that frustrate you the most, > which we could make part of our third quarter goals? The server side performance and bug we can't patch because it's closed source. (and being syadmin, i'm sure i could help with server performance) ::smile:: -- kerunix Flan From able.whitman at gmail.com Sun Jun 24 19:16:52 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sun Jun 24 19:16:54 2007 Subject: [sldev] Opening the server source? Message-ID: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> Laurent reminded me of a post I meant to make after triage, but forgot about in my absentmindedness... It would be nice to know more about the plans to release the sim source. At the last bug triage, Rob mentioned that it was a "long topic for another time". I'm not really asking for every last detail, just some information on where things stand, and where they're going. Is there a timetable for releasing the server code? Are there blocking issues that are confounding the process? At his town hall, Cory talked about the next generation of SL (I'm not sure if "SL 2.0" was his term or not). Will we see a server source release before "SL 2.0"? I'm just askin' :) --Able On 6/24/07, Laurent Laborde wrote: > > On 6/25/07, Soft Linden wrote: > > Are there one or two things that frustrate you the most, > > which we could make part of our third quarter goals? > > The server side performance and bug we can't patch because it's closed > source. > (and being syadmin, i'm sure i could help with server performance) > > ::smile:: > > -- > kerunix Flan > _______________________________________________ > 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/20070624/e6acf07c/attachment-0001.htm From adam at gwala.net Sun Jun 24 19:21:50 2007 From: adam at gwala.net (Adam Frisby) Date: Sun Jun 24 19:22:19 2007 Subject: [sldev] Opening the server source? In-Reply-To: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> Message-ID: <467F26BE.6090409@gwala.net> **Speculation**: I believe LL is targetting sometime next year for the official server release. As far as I am aware, LL still has a long way to go towards a distributed central architecture before that is a possibility, although they certainly appear to be moving in that direction fairly quickly. Adam Able Whitman wrote: > Laurent reminded me of a post I meant to make after triage, but forgot > about in my absentmindedness... > > It would be nice to know more about the plans to release the sim source. > At the last bug triage, Rob mentioned that it was a "long topic for > another time". I'm not really asking for every last detail, just some > information on where things stand, and where they're going. > > Is there a timetable for releasing the server code? Are there blocking > issues that are confounding the process? At his town hall, Cory talked > about the next generation of SL (I'm not sure if "SL 2.0" was his term > or not). Will we see a server source release before "SL 2.0"? > > I'm just askin' :) > > --Able > > On 6/24/07, *Laurent Laborde* > wrote: > > On 6/25/07, Soft Linden > wrote: > > Are there one or two things that frustrate you the most, > > which we could make part of our third quarter goals? > > The server side performance and bug we can't patch because it's > closed source. > (and being syadmin, i'm sure i could help with server performance) > > ::smile:: > > -- > kerunix Flan > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From robla at lindenlab.com Sun Jun 24 19:48:20 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sun Jun 24 19:48:37 2007 Subject: [sldev] Jira down? In-Reply-To: <7b3a84fb0706241710w3a3805c0nc01fd5278f32ba17@mail.gmail.com> References: <467E7746.1070100@blueflash.cc> <9e6e5c9e0706241624t669c3a7yf3b07c7e96cce65b@mail.gmail.com> <467F02C3.2020800@blueflash.cc> <7b3a84fb0706241710w3a3805c0nc01fd5278f32ba17@mail.gmail.com> Message-ID: <467F2CF4.2080403@lindenlab.com> A software upgrade is in the works. I'm not exactly sure when the timing will be, but should be within the next few days. Hardware scaling is rather rough for JIRA. It's already running on some fairly beefy hardware, from what I understand. Another thing I understand is that clustering is not supported in JIRA, so we can't necessarily scale outward. See the JIRA feature request at jira.atlassian.com for more on this: http://jira.atlassian.com/browse/JRA-7330 Rob On 6/24/07 5:10 PM, Able Whitman wrote: > Especially since all residents are being encouraged to use JIRA for > every bug report, feature suggestion, etc., an upgraded system is a > great idea :) > > On 6/24/07, * Nicholaz Beresford* > wrote: > > > It's probably due for update, someone recently > mentioned that there was a newer version with the > indexing error fixed. > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Soft Linden wrote: > > It's been working all day, but dog ass slow for me. > > > > Let's bring this up during Rob's office hours - maybe something's > > broken, or maybe we're overdue for a machine upgrade with more and > > more residents starting to use it? > > > > > > On 6/24/07, Nicholaz Beresford < nicholaz@blueflash.cc > > wrote: > >> > >> Seems so ... fourth week in a row on Weekends :-) > >> > >> > >> Nick > >> > >> > >> Second Life from the inside out: > >> http://nicholaz-beresford.blogspot.com/ > >> > >> > >> Matthew Dowd wrote: > >> > Is Jira down? > >> > > >> > Matthew > >> > > >> > _________________________________________________________________ > >> > Feel like a local wherever you go with BackOfMyHand.com > >> > > >> > http://www.backofmyhand.com_______________________________________________ > >> > >> > Click here to unsubscribe or manage your list subscription: > >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> _______________________________________________ > >> Click here to unsubscribe or manage your list subscription: > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- 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/20070624/0eabd1f2/signature.pgp From able.whitman at gmail.com Sun Jun 24 20:10:47 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sun Jun 24 20:10:50 2007 Subject: [sldev] Uniquely identifying parcels Message-ID: <7b3a84fb0706242010t60efa39fn97acd0d53b6f750f@mail.gmail.com> The ParcelProperties message includes a LocalID for the parcel, but not an LLUUID for it. For my purposes, this is unfortunate. I'm hoping there is a way uniquely identify parcels in a given region. Is the LocalID a reliable identifier for a given parcel in a region? Or does it change, like when a region restarts? Similarly, is a region's RegionHandle fixed, or is it also mutable? If it's mutable, then is the region name fixed? I'd like to be able to use a combination of a RegionHandle (or a region's name) and a parcel LocalID to uniquely identify a parcel. If that won't work, the alternatives are pretty hackish. These are probably questions for a Linden, but since I don't know who specifically to ask, I'm posting here. :) Thanks! --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070624/3e25a8c9/attachment.htm From adam at gwala.net Sun Jun 24 20:20:31 2007 From: adam at gwala.net (Adam Frisby) Date: Sun Jun 24 20:20:59 2007 Subject: [sldev] Uniquely identifying parcels In-Reply-To: <7b3a84fb0706242010t60efa39fn97acd0d53b6f750f@mail.gmail.com> References: <7b3a84fb0706242010t60efa39fn97acd0d53b6f750f@mail.gmail.com> Message-ID: <467F347F.5020005@gwala.net> RegionHandle is based on the position of the region, and is as close to a region ID we can get. Changes if the sim moves, but is otherwise unique. ParcelID is mostly unique. If a parcel is subdivided, it will be split into two parcels with different IDs. So subdiving/joining will change the IDs, but otherwise it should stay the same. A combination of the two can make an alright parcel identifier, only that you need to be aware that it can change. Adam Able Whitman wrote: > The ParcelProperties message includes a LocalID for the parcel, but not > an LLUUID for it. For my purposes, this is unfortunate. > > I'm hoping there is a way uniquely identify parcels in a given region. > Is the LocalID a reliable identifier for a given parcel in a region? Or > does it change, like when a region restarts? > > Similarly, is a region's RegionHandle fixed, or is it also mutable? If > it's mutable, then is the region name fixed? > > I'd like to be able to use a combination of a RegionHandle (or a > region's name) and a parcel LocalID to uniquely identify a parcel. If > that won't work, the alternatives are pretty hackish. > > These are probably questions for a Linden, but since I don't know who > specifically to ask, I'm posting here. :) > > Thanks! > --Able > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From able.whitman at gmail.com Sun Jun 24 20:23:47 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sun Jun 24 20:23:50 2007 Subject: [sldev] Opening the server source? In-Reply-To: <467F26BE.6090409@gwala.net> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> Message-ID: <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> Right, having the source in order to build a working simulator only makes sense if you can also build the pieces of the SL service that the sim depends on. But even without a decoupled architecture, the server source has a great deal of value today: It would tell us how the sim works and interacts with the viewer, in much more complete detail than what we can infer from the viewer source. Just having a copy of the server source for examination would be extremely useful. Either that, or a set of detailed, up-to-date design specs. In my experience, though, "up-to-date" and "design specs" are mutually exclusive concepts. So I would prefer the source. :) On 6/24/07, Adam Frisby wrote: > > **Speculation**: > I believe LL is targetting sometime next year for the official > server > release. As far as I am aware, LL still has a long way to go towards a > distributed central architecture before that is a possibility, although > they certainly appear to be moving in that direction fairly quickly. > > Adam > > Able Whitman wrote: > > > Laurent reminded me of a post I meant to make after triage, but forgot > > about in my absentmindedness... > > > > It would be nice to know more about the plans to release the sim source. > > At the last bug triage, Rob mentioned that it was a "long topic for > > another time". I'm not really asking for every last detail, just some > > information on where things stand, and where they're going. > > > > Is there a timetable for releasing the server code? Are there blocking > > issues that are confounding the process? At his town hall, Cory talked > > about the next generation of SL (I'm not sure if "SL 2.0" was his term > > or not). Will we see a server source release before "SL 2.0"? > > > > I'm just askin' :) > > > > --Able > > > > On 6/24/07, *Laurent Laborde* > > wrote: > > > > On 6/25/07, Soft Linden > > wrote: > > > Are there one or two things that frustrate you the most, > > > which we could make part of our third quarter goals? > > > > The server side performance and bug we can't patch because it's > > closed source. > > (and being syadmin, i'm sure i could help with server performance) > > > > ::smile:: > > > > -- > > kerunix Flan > > _______________________________________________ > > 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/20070624/ec06fbb7/attachment.htm From able.whitman at gmail.com Sun Jun 24 20:26:53 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sun Jun 24 20:26:56 2007 Subject: [sldev] Uniquely identifying parcels In-Reply-To: <467F347F.5020005@gwala.net> References: <7b3a84fb0706242010t60efa39fn97acd0d53b6f750f@mail.gmail.com> <467F347F.5020005@gwala.net> Message-ID: <7b3a84fb0706242026s1b818340w63010f67cb5fb3cb@mail.gmail.com> Thanks very much, Adam! That's incredibly helpful to know. It's fine that the ParcelID will change if the parcel's geometry changes; in fact, that's ideal. On 6/24/07, Adam Frisby wrote: > > RegionHandle is based on the position of the region, and is as close to > a region ID we can get. Changes if the sim moves, but is otherwise unique. > > ParcelID is mostly unique. If a parcel is subdivided, it will be split > into two parcels with different IDs. So subdiving/joining will change > the IDs, but otherwise it should stay the same. > > A combination of the two can make an alright parcel identifier, only > that you need to be aware that it can change. > > Adam > > Able Whitman wrote: > > > The ParcelProperties message includes a LocalID for the parcel, but not > > an LLUUID for it. For my purposes, this is unfortunate. > > > > I'm hoping there is a way uniquely identify parcels in a given region. > > Is the LocalID a reliable identifier for a given parcel in a region? Or > > does it change, like when a region restarts? > > > > Similarly, is a region's RegionHandle fixed, or is it also mutable? If > > it's mutable, then is the region name fixed? > > > > I'd like to be able to use a combination of a RegionHandle (or a > > region's name) and a parcel LocalID to uniquely identify a parcel. If > > that won't work, the alternatives are pretty hackish. > > > > These are probably questions for a Linden, but since I don't know who > > specifically to ask, I'm posting here. :) > > > > Thanks! > > --Able > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070624/b7cc2094/attachment-0001.htm From seg at haxxed.com Sun Jun 24 20:46:20 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sun Jun 24 20:45:38 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> Message-ID: <1182743180.20433.29.camel@localhost> On Sun, 2007-06-24 at 18:08 -0700, Soft Linden wrote: > This raises a few questions for me. Firstly, from where you stand, > *are* we doing better overall? There seems to be a marked improvement recently, yes. Only time will tell if LL will keep this up. :) > Lastly, what can we still do better? Are there one or two things that > frustrate you the most, which we could make part of our third quarter > goals? Jira's slowness and unreliability? One concern is coordinating releases with downstream packagers. I'm working on getting slviewer into Fedora. It would be nice if we could get our hands on the final source code a day or two before a required update, so we can have it built and ready once the grid comes back up. Though then we'd also have to prepared to abort the update if LL decides to do so... Ultimately it would be nice to just have required updates go away entirely, if I understand correctly, 1.18 is a step in that direction? At the very least, allowing some version overlap would solve most of the problem. And... you know, it would be neat if maybe LL would put its weight behind advocating for Open Source OpenGL drivers. And maybe, just maybe, even put some development resources into them. The open source r300 driver works beautifully for OpenArena, (Gee, I wonder what the developers are using as a test case :) but SL seems to be able to tickle the driver in ways it's not ready for, locking up the entire machine occasionally. (Or instantly, as the case is on my desktop machine...) fglrx has yet to be updated to be compatible with Fedora 7, a prime example of the problem with closed source drivers... -------------- 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/20070624/b6c93c0e/attachment.pgp From gwardell at gwsystems.co.il Sun Jun 24 20:55:23 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Sun Jun 24 20:55:36 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <1182743180.20433.29.camel@localhost> Message-ID: <007401c7b6dc$a8fd6e70$a4689943@gwsystems2.com> > > .... but SL seems to be > able to tickle > the driver in ways it's not ready for, locking up the entire machine > occasionally. (Or instantly, as the case is on my desktop machine...) > Ohhhh, maybe that is what's happening to my workstation... If it is, then there is basically no remedy right now? How do I find out if that's what's happening? Gary. From matthew.dowd at hotmail.co.uk Mon Jun 25 02:42:00 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jun 25 02:42:02 2007 Subject: [sldev] Jira down? Message-ID: Mmmm, interesting about the clustering issue. Something is amiss - even on a good day, Jira is very slow. Without knowing the hardware, I can only guess but perhaps beef up the disk (multiple controllers, striped disks etc., maybe even fork out on som 15000rpm SCSI disks)? As a stop gap could the four projects (SVC, VWR, WEB, MISC) be served off seperate jira servers? It may also be worth cleaning the issue database - deleting all the duplicates which are really requests for help - when you upgrade the software. Matthew ---------------------------------------- > Date: Sun, 24 Jun 2007 19:48:20 -0700 > From: robla@lindenlab.com > To: sldev@lists.secondlife.com > Subject: Re: [sldev] Jira down? > > A software upgrade is in the works. I'm not exactly sure when the > timing will be, but should be within the next few days. > > Hardware scaling is rather rough for JIRA. It's already running on some > fairly beefy hardware, from what I understand. Another thing I > understand is that clustering is not supported in JIRA, so we can't > necessarily scale outward. See the JIRA feature request at > jira.atlassian.com for more on this: > http://jira.atlassian.com/browse/JRA-7330 > > Rob > > On 6/24/07 5:10 PM, Able Whitman wrote: > > Especially since all residents are being encouraged to use JIRA for > > every bug report, feature suggestion, etc., an upgraded system is a > > great idea :) > > > > On 6/24/07, * Nicholaz Beresford* > > wrote: > > > > > > It's probably due for update, someone recently > > mentioned that there was a newer version with the > > indexing error fixed. > > > > > > Nick > > > > > > Second Life from the inside out: > > http://nicholaz-beresford.blogspot.com/ > > > > > > Soft Linden wrote: > > > It's been working all day, but dog ass slow for me. > > > > > > Let's bring this up during Rob's office hours - maybe something's > > > broken, or maybe we're overdue for a machine upgrade with more and > > > more residents starting to use it? > > > > > > > > > On 6/24/07, Nicholaz Beresford < nicholaz@blueflash.cc > > > wrote: > > >> > > >> Seems so ... fourth week in a row on Weekends :-) > > >> > > >> > > >> Nick > > >> > > >> > > >> Second Life from the inside out: > > >> http://nicholaz-beresford.blogspot.com/ > > >> > > >> > > >> Matthew Dowd wrote: > > >> > Is Jira down? > > >> > > > >> > Matthew > > >> > > > >> > _________________________________________________________________ > > >> > Feel like a local wherever you go with BackOfMyHand.com > > >> > > > >> > > http://www.backofmyhand.com_______________________________________________ > > >> > > >> > Click here to unsubscribe or manage your list subscription: > > >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > >> _______________________________________________ > > >> Click here to unsubscribe or manage your list subscription: > > >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > >> > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From matthew.dowd at hotmail.co.uk Mon Jun 25 02:43:34 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jun 25 02:43:35 2007 Subject: [sldev] Just askin': How are we doing? Message-ID: Am I right in that the voice firstlook source hasn't been made public yet? or have I just not looked in the right places? Matthew ---------------------------------------- > Subject: Re: [sldev] Just askin': How are we doing? > From: seg@haxxed.com > To: sldev@lists.secondlife.com > Date: Sun, 24 Jun 2007 22:46:20 -0500 > > On Sun, 2007-06-24 at 18:08 -0700, Soft Linden wrote: > > This raises a few questions for me. Firstly, from where you stand, > > *are* we doing better overall? > > There seems to be a marked improvement recently, yes. Only time will > tell if LL will keep this up. :) > > > Lastly, what can we still do better? Are there one or two things that > > frustrate you the most, which we could make part of our third quarter > > goals? > > Jira's slowness and unreliability? > > One concern is coordinating releases with downstream packagers. I'm > working on getting slviewer into Fedora. It would be nice if we could > get our hands on the final source code a day or two before a required > update, so we can have it built and ready once the grid comes back up. > Though then we'd also have to prepared to abort the update if LL decides > to do so... > > Ultimately it would be nice to just have required updates go away > entirely, if I understand correctly, 1.18 is a step in that direction? > At the very least, allowing some version overlap would solve most of the > problem. > > And... you know, it would be neat if maybe LL would put its weight > behind advocating for Open Source OpenGL drivers. And maybe, just maybe, > even put some development resources into them. The open source r300 > driver works beautifully for OpenArena, (Gee, I wonder what the > developers are using as a test case :) but SL seems to be able to tickle > the driver in ways it's not ready for, locking up the entire machine > occasionally. (Or instantly, as the case is on my desktop machine...) > > fglrx has yet to be updated to be compatible with Fedora 7, a prime > example of the problem with closed source drivers... _________________________________________________________________ Feel like a local wherever you go with BackOfMyHand.com http://www.backofmyhand.com From dale at daleglass.net Mon Jun 25 05:34:22 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Mon Jun 25 05:34:28 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> Message-ID: <20070625123421.GA23047@bruno.sbruno> On Sun, Jun 24, 2007 at 06:08:45PM -0700, Soft Linden wrote: > I'm convinced Linden Lab is doing a lot better with the open source > community. > [...] > This raises a few questions for me. Firstly, from where you stand, > *are* we doing better overall? I think we definitely are. I think one of the main improvements is that OSS developers don't necessarily have to work on the most urgent stuff, so we're getting a lot more optimizations and fixes for issues like the notifications ordering than we would otherwise. > Second, is there anything we're doing *worse*? Any recent changes you > *don't* like? Nothing I can think of ATM > Lastly, what can we still do better? Are there one or two things that > frustrate you the most, which we could make part of our third quarter > goals? Main one is that the source releases are too infrequent, and while not a very big problem right now, I think it'll eventually become annoying. It probably won't be long until people will start trying to offer their patched client to other people, and merging a version worth of changes at once could be annoying. It also makes it harder to see where development is going. The release team sounds like it'd fix this. If so, then great :-) Jira annoyances: it's slow as molasses, and the jira client while it mitigates the problems a lot can't be used for everything because auth doesn't seem to work. Since Rob mentioned scalability is hard, I think fixing auth would be a very good temporary relief. Server source code: Been said already, but a pretty big one. I'm starting to bump into that something I want implemented would need server changes. I would go ahead and patch the server too, if I could. Also in that case having the server source would make it a lot easier to determine whether a feature would require something impractical server-side and thus not worth trying to do at all. A suggestion: give credit to whoever fixed a bug when publishing changelogs on the blog, resident or Linden. -------------- 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/20070625/a121d9ef/attachment.pgp From nicholaz at blueflash.cc Mon Jun 25 05:38:31 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 05:38:42 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> Message-ID: <467FB747.5040702@blueflash.cc> Hi All! > This raises a few questions for me. Firstly, from where you stand, > *are* we doing better overall? Yes, I think it going a lot better. Stuff is taken out of the Patch Sematary (that's what the "Issues with patches attached" query looked like when I started) and eventually into the viewer. > Second, is there anything we're doing *worse*? Any recent changes you > *don't* like? None that I could think of. > Lastly, what can we still do better? Are there one or two things that > frustrate you the most, which we could make part of our third quarter > goals? There are a couple of things, although I'm beyond the "frustration" phase. One small thing on my wishlist would be on JIRA being able to watch topics and get email notifications on changes. A thing regarding the open source and development would be better communication. Things are probably looking a lot different from inside LL, but from the outside LL looks like a huge black box with an occasional blip on the radar. The other (big) thing, and I think the comments on the blog for the 1.17.1 and 1.18 release announcements support that, would be to make the 3rd quarter the quarter of "bug fixing". This is probably something King Philip would need to do (like Bill Gates at one point just announced the "year of security" or something like that), but a quarter of letting the dust settle, where everybody would just work on fixing and cleaning up stuff, would do the whole viewer a lot of good. > I've been looking at other open source projects for a while, looking > for other ideas we can adopt. Nicholaz Beresford suggested watching > the wine lists, which I've done, as well as looking in on a couple of > the Linux distributions. I'm trying to identify the things we do > differently, where they might have the better answer. I've got a small > list I'm ready to discuss, including a couple of the long-standing > pain points, but I want to get your input before pushing my own ideas. I have not done anything myself with Wine, but my partner here in my business is using Linux and is checking our software against Wine occasionally. From what I've heard and watched, this project really sets an example. They have clear procedures, fast turnaround times (which is easier, because they have a real time open source repository), and excellent communication. One point which is really important for me is communication. I don't mind if a patch is rejected for good reasons, but with them you usually seem to get a response on a patch submit within 24 hours. For example most of my early patches for SL weren't exactly the way that helped easy integration because I didn't understand the procedures and I would not have minded redoing them with a hint about how to do so (the wiki for "submitting code" didn't exist then). Speaking of Wine, we recently submitted one and had it go life in 10 hours. The key seems there that the guy (or guys) who apply the atches, have authority to do so and also the knowledge to judge what's good and what not. Nick From nicholaz at blueflash.cc Mon Jun 25 05:51:59 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 05:52:11 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> Message-ID: <467FBA6F.2080902@blueflash.cc> More stuff ... > Lastly, what can we still do better? Are there one or two things that > frustrate you the most, which we could make part of our third quarter > goals? Since Dale mentioned it: Source releases during the Wednesday downtime would be a nice thing. The downtimes coincide with the time here where I'm working on the project (European time) and would be a good time to see what's new and get the viewer compiled locally. JIRA: A link next to the "Patch attached" checkbox (in JIRA, Edit), linking to the "submit code" page on the Wiki. Access to the crash logs: Maybe I'm the only one who's looking at crashes instead of doing Sudoku, but I think it's beyond the time where the stack dump alone will help fixing crashes (at least for the top 10). I think crash reports will go back by an order of magnitue with the leak fixed (at least that's what I'm hearing from people using my viewer) but they will most likely become more and more obscure (which again, it is what I'm seeing from the crash dumps from my viewer). Dunno how to approach this exactly, but it's something I noticed. Nick From dale at daleglass.net Mon Jun 25 06:00:45 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Mon Jun 25 06:00:55 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <467FBA6F.2080902@blueflash.cc> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FBA6F.2080902@blueflash.cc> Message-ID: <20070625130045.GB23047@bruno.sbruno> On Mon, Jun 25, 2007 at 02:51:59PM +0200, Nicholaz Beresford wrote: > Access to the crash logs: Maybe I'm the only one who's looking at > crashes instead of doing Sudoku, but I think it's beyond the time > where the stack dump alone will help fixing crashes (at least for the > top 10). I think crash reports will go back by an order of magnitue > with the leak fixed (at least that's what I'm hearing from people > using my viewer) but they will most likely become more and more > obscure (which again, it is what I'm seeing from the crash dumps > from my viewer). Dunno how to approach this exactly, but it's > something I noticed. That would be nice indeed. A stack trace shouldn't contain anything very private. Only potential problem is the arguments to the functions, if the stacktrace sent includes that (haven't looked at it). This could contain passwords or something else that's sensitive. Short term fix would not giving that info at all, but that makes debugging harder. Perhaps there could be some sort of blacklist with functions that take sensitive data to have it scrubbed, but something could be missed. -------------- 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/20070625/2fb3a13f/attachment-0001.pgp From kerdezixe at gmail.com Mon Jun 25 06:48:30 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Mon Jun 25 06:48:33 2007 Subject: [sldev] Firstlook Voice... more memory leak ? Message-ID: <8a1bfe660706250648q62f5566eva90082f58b1f10bf@mail.gmail.com> Hi, when i run Secondlife on my PC (because of the 20" screen against my 15" macbook pro) i use a software named "O&O Clever cache". This software have a very nice memory usage monitor. Since i upgraded my PC with 3GB of RAM, i noticed a lot of performance improvment and less crash. I guess that the overhead of swapping cause a race condition, or some kind of memory inconsistency... and crash. With firstlook i noticed that SecondLife can use up to 2GB of memory, that never happened with the "regular client"... the memory usage is growing over time... 'til crash. I hate to say that, because i want voice, but : i think it should be fixed before the "official" release of voicechat... swapping is the cause of a MAJOR slowdown and most people have 1GB or less of RAM (and fragmented disk and bad virtual memory managment and ...). We said that voice won't generate more lag, and i believe this is true. But this memory leak will generate an insane lag and crash. It won't take more than a second for people to say "Voice = lag" and "Linden Lab = Liar", "Fix teh bugz instead of adding features". I have voice chat enabled on my 3 major french sims, with a traffic of 100.000 visitor per month. We like voice, but most people switch back to the regular client. Myself, i don't use FirstLook unless i planned to use voice. More crash, FPS drop, ... I wish i could help to find the memory leak, and analyze the crashdump, ... but i don't know how. -- kerunix Flan I ARE IN UR MAILING LIST, SPAMING UR DEVZ. :) From kerdezixe at gmail.com Mon Jun 25 07:33:05 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Mon Jun 25 07:33:06 2007 Subject: [sldev] Jira down? In-Reply-To: <467F2CF4.2080403@lindenlab.com> References: <467E7746.1070100@blueflash.cc> <9e6e5c9e0706241624t669c3a7yf3b07c7e96cce65b@mail.gmail.com> <467F02C3.2020800@blueflash.cc> <7b3a84fb0706241710w3a3805c0nc01fd5278f32ba17@mail.gmail.com> <467F2CF4.2080403@lindenlab.com> Message-ID: <8a1bfe660706250733y235a270fid0abdcc8a897a848@mail.gmail.com> On 6/25/07, Rob Lanphier wrote: > A software upgrade is in the works. I'm not exactly sure when the > timing will be, but should be within the next few days. > > Hardware scaling is rather rough for JIRA. It's already running on some > fairly beefy hardware, from what I understand. Another thing I > understand is that clustering is not supported in JIRA, so we can't > necessarily scale outward. See the JIRA feature request at > jira.atlassian.com for more on this: > http://jira.atlassian.com/browse/JRA-7330 Holy cow ! A java application (you probably run tomcat ?) that can't be clustered ? i was used to manage a jserv cluster for some major phone operator, we always found a workaround to support more load. When i left my job we were supporting up to 2000 requests/second. I don't like java, but if there is ONE benefit about java, it's clustering. So ... Where is the bottleneck exactly ? Can't you use a reverse-proxy ? Tomcat loadbalancing capabilities (even a simple round-robin) ? Unless the bottleneck is the database ? How jira is mostly used ? Searching ? Read-only browsing ? Even the frontpage take age to load... while i'm still not authentified, and reading a page that never change. there is something wrong here. Wikipedia is doing very well, running 2 differents services (with a lot of caching) for identified and unidentified users (unidentified users are *ALWAYS* read-only, caching is good). Also, i checked your robots.txt, you don't disallow search engine bot. Can you check your stats and take care of thoses bots ? I know they can generate a great amount of load on dynamic page with link, retro-link, retro-back-link, diff, history, post-reverse-back-retro-diff-history-link and that kind of silly unused high load dynamic page. -- kerunix Flan From brad at lindenlab.com Mon Jun 25 07:47:45 2007 From: brad at lindenlab.com (Brad Kittenbrink) Date: Mon Jun 25 07:47:56 2007 Subject: [sldev] Can someone clarify the object naming conventions llvosky.h vs llsky.h In-Reply-To: <467E34DC.40501@ucsd.edu> References: <467A1745.7010302@ucsd.edu> <467A3CA0.9030509@blueflash.cc> <467A9AA9.90507@lindenlab.com> <467E33AC.6090301@ucsd.edu> <467E34DC.40501@ucsd.edu> Message-ID: <467FD591.2010300@lindenlab.com> For others who might be interested, the nVidia sdk is usable on all hardware configurations, it is a general OpenGL sdk for easing the use of extensions. -Brad Max Okumoto wrote: > Never mind, I miss read the header. I just need to down load the > glgui package. > > Max > > Max Okumoto wrote: >> Hi Brad, >> >> I tried to compile the windlight-1-17-0 branch, but ran into a slight >> problem. I don't have the glh headers. >> >> llwindow/llgl.cpp:47:28: glh/glh_linear.h: No such file or directory >> llwindow/llgl.cpp:48:33: glh/glh_convenience.h: No such file or >> directory >> >> Googling for them seems to indicate that those are NVIDA header >> files. Are there any patches >> for using ATI drivers? >> >> Max >> From robla at lindenlab.com Mon Jun 25 08:43:30 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jun 25 08:43:45 2007 Subject: [sldev] Jira down? In-Reply-To: References: Message-ID: <467FE2A2.500@lindenlab.com> For some users, I think there's something else at play. JIRA performance is generally quite acceptable for me. Let's move this thread to: https://jira.secondlife.com/browse/WEB-107 Thanks Rob On 6/25/07 2:42 AM, Matthew Dowd wrote: > Mmmm, interesting about the clustering issue. > > Something is amiss - even on a good day, Jira is very slow. Without knowing the hardware, I can only guess but perhaps beef up the disk (multiple controllers, striped disks etc., maybe even fork out on som 15000rpm SCSI disks)? > > As a stop gap could the four projects (SVC, VWR, WEB, MISC) be served off seperate jira servers? > > It may also be worth cleaning the issue database - deleting all the duplicates which are really requests for help - when you upgrade the software. > > Matthew > > > > > ---------------------------------------- > >> Date: Sun, 24 Jun 2007 19:48:20 -0700 >> From: robla@lindenlab.com >> To: sldev@lists.secondlife.com >> Subject: Re: [sldev] Jira down? >> >> A software upgrade is in the works. I'm not exactly sure when the >> timing will be, but should be within the next few days. >> >> Hardware scaling is rather rough for JIRA. It's already running on some >> fairly beefy hardware, from what I understand. Another thing I >> understand is that clustering is not supported in JIRA, so we can't >> necessarily scale outward. See the JIRA feature request at >> jira.atlassian.com for more on this: >> http://jira.atlassian.com/browse/JRA-7330 >> >> Rob >> >> On 6/24/07 5:10 PM, Able Whitman wrote: >> >>> Especially since all residents are being encouraged to use JIRA for >>> every bug report, feature suggestion, etc., an upgraded system is a >>> great idea :) >>> >>> On 6/24/07, * Nicholaz Beresford* > > wrote: >>> >>> >>> It's probably due for update, someone recently >>> mentioned that there was a newer version with the >>> indexing error fixed. >>> >>> >>> Nick >>> >>> >>> Second Life from the inside out: >>> http://nicholaz-beresford.blogspot.com/ >>> >>> >>> Soft Linden wrote: >>> > It's been working all day, but dog ass slow for me. >>> > >>> > Let's bring this up during Rob's office hours - maybe something's >>> > broken, or maybe we're overdue for a machine upgrade with more and >>> > more residents starting to use it? >>> > >>> > >>> > On 6/24/07, Nicholaz Beresford < nicholaz@blueflash.cc >>> > wrote: >>> >> >>> >> Seems so ... fourth week in a row on Weekends :-) >>> >> >>> >> >>> >> Nick >>> >> >>> >> >>> >> Second Life from the inside out: >>> >> http://nicholaz-beresford.blogspot.com/ >>> >> >>> >> >>> >> Matthew Dowd wrote: >>> >> > Is Jira down? >>> >> > >>> >> > Matthew >>> >> > >>> >> > _________________________________________________________________ >>> >> > Feel like a local wherever you go with BackOfMyHand.com >>> >> > >>> >> >>> http://www.backofmyhand.com_______________________________________________ >>> >> >>> >> > Click here to unsubscribe or manage your list subscription: >>> >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >> _______________________________________________ >>> >> Click here to unsubscribe or manage your list subscription: >>> >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> >>> >> > > _________________________________________________________________ > 100?s of Music vouchers to be won with MSN Music > https://www.musicmashup.co.uk/index.html -------------- 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/20070625/150accd0/signature.pgp From soft at lindenlab.com Mon Jun 25 10:14:44 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jun 25 10:14:45 2007 Subject: [sldev] Opening the server source? In-Reply-To: <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> Message-ID: <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> We're certainly a ways off from being in a position where opening the sim source fully would make sense. I haven't been in on these discussions, but as an outsider to those discussions, I can anticipate that LL wouldn't want to do this until a few things happen: - We need to be in a position to profit from the growth that comes with third-party sim hosting - at least enough to replace lost revenue from our own sim hosting. - We need to be in a position to run a variety of versions of the sim on the same grid. - We need to be able to scale core services to meet a spike in use from a zillion new sims. - Licensing issues on the middleware that I don't even want to ever have to think about. (Thank you, Rob and Liana!!!) That said, it's probably silly to treat open sourcing the sim as an all-or-nothing affair. If there are specific pieces of the sim you'd like to see, I can lobby for us to open source select files. What you can do is to identify any specific bits and, for each, give me strong justification I can arm myself with. The stronger and more concise, the better. I'd have to convince folks (including myself if I'm putting my name to the effort!) that the benefits outweigh the costs. Between legal, developer time, and security auditing, this isn't free. Good will on sldev is worth a lot - but so is remaining solvent. :) On 6/24/07, Able Whitman wrote: > Right, having the source in order to build a working simulator only makes > sense if you can also build the pieces of the SL service that the sim > depends on. > > But even without a decoupled architecture, the server source has a great > deal of value today: It would tell us how the sim works and interacts with > the viewer, in much more complete detail than what we can infer from the > viewer source. > > Just having a copy of the server source for examination would be extremely > useful. Either that, or a set of detailed, up-to-date design specs. In my > experience, though, "up-to-date" and "design specs" are mutually exclusive > concepts. So I would prefer the source. :) > > > On 6/24/07, Adam Frisby wrote: > > **Speculation**: > > I believe LL is targetting sometime next year for the official > server > > release. As far as I am aware, LL still has a long way to go towards a > > distributed central architecture before that is a possibility, although > > they certainly appear to be moving in that direction fairly quickly. > > > > Adam > > > > Able Whitman wrote: > > > > > Laurent reminded me of a post I meant to make after triage, but forgot > > > about in my absentmindedness... > > > > > > It would be nice to know more about the plans to release the sim source. > > > At the last bug triage, Rob mentioned that it was a "long topic for > > > another time". I'm not really asking for every last detail, just some > > > information on where things stand, and where they're going. > > > > > > Is there a timetable for releasing the server code? Are there blocking > > > issues that are confounding the process? At his town hall, Cory talked > > > about the next generation of SL (I'm not sure if "SL 2.0" was his term > > > or not). Will we see a server source release before "SL 2.0"? > > > > > > I'm just askin' :) > > > > > > --Able > > > > > > On 6/24/07, *Laurent Laborde* > > > wrote: > > > > > > On 6/25/07, Soft Linden > > > wrote: > > > > Are there one or two things that frustrate you the most, > > > > which we could make part of our third quarter goals? > > > > > > The server side performance and bug we can't patch because it's > > > closed source. > > > (and being syadmin, i'm sure i could help with server performance) > > > > > > ::smile:: > > > > > > -- > > > kerunix Flan > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From tao.takashi at googlemail.com Mon Jun 25 10:20:28 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Jun 25 10:20:31 2007 Subject: [sldev] Opening the server source? In-Reply-To: <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> Message-ID: <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> forgot to CC the list of course.. ;-) here my reply to Soft.. Hi! Just to get this clear: Is releasing the server as open source and opening up the grid to plugin third-party servers one project? I'd think that as long as you don't open up the grid but only release the source code you wouldn't have to worry about lost revenue? (as long as nobody creates the backend services themselves and creates another (separate) grid). Of course I can imagine that opening up the grid is a somewhat difficult task to do from all points of view. -- Tao 2007/6/25, Soft Linden : > > We're certainly a ways off from being in a position where opening the > sim source fully would make sense. I haven't been in on these > discussions, but as an outsider to those discussions, I can anticipate > that LL wouldn't want to do this until a few things happen: > > - We need to be in a position to profit from the growth that comes > with third-party sim hosting - at least enough to replace lost revenue > from our own sim hosting. > > - We need to be in a position to run a variety of versions of the sim > on the same grid. > > - We need to be able to scale core services to meet a spike in use > from a zillion new sims. > > - Licensing issues on the middleware that I don't even want to ever > have to think about. (Thank you, Rob and Liana!!!) > > That said, it's probably silly to treat open sourcing the sim as an > all-or-nothing affair. If there are specific pieces of the sim you'd > like to see, I can lobby for us to open source select files. > > What you can do is to identify any specific bits and, for each, give > me strong justification I can arm myself with. The stronger and more > concise, the better. I'd have to convince folks (including myself if > I'm putting my name to the effort!) that the benefits outweigh the > costs. Between legal, developer time, and security auditing, this > isn't free. Good will on sldev is worth a lot - but so is remaining > solvent. :) > > > > On 6/24/07, Able Whitman wrote: > > Right, having the source in order to build a working simulator only > makes > > sense if you can also build the pieces of the SL service that the sim > > depends on. > > > > But even without a decoupled architecture, the server source has a great > > deal of value today: It would tell us how the sim works and interacts > with > > the viewer, in much more complete detail than what we can infer from the > > viewer source. > > > > Just having a copy of the server source for examination would be > extremely > > useful. Either that, or a set of detailed, up-to-date design specs. In > my > > experience, though, "up-to-date" and "design specs" are mutually > exclusive > > concepts. So I would prefer the source. :) > > > > > > On 6/24/07, Adam Frisby wrote: > > > **Speculation**: > > > I believe LL is targetting sometime next year for the official > > server > > > release. As far as I am aware, LL still has a long way to go towards a > > > distributed central architecture before that is a possibility, > although > > > they certainly appear to be moving in that direction fairly quickly. > > > > > > Adam > > > > > > Able Whitman wrote: > > > > > > > Laurent reminded me of a post I meant to make after triage, but > forgot > > > > about in my absentmindedness... > > > > > > > > It would be nice to know more about the plans to release the sim > source. > > > > At the last bug triage, Rob mentioned that it was a "long topic for > > > > another time". I'm not really asking for every last detail, just > some > > > > information on where things stand, and where they're going. > > > > > > > > Is there a timetable for releasing the server code? Are there > blocking > > > > issues that are confounding the process? At his town hall, Cory > talked > > > > about the next generation of SL (I'm not sure if "SL 2.0" was his > term > > > > or not). Will we see a server source release before "SL 2.0"? > > > > > > > > I'm just askin' :) > > > > > > > > --Able > > > > > > > > On 6/24/07, *Laurent Laborde* > > > > wrote: > > > > > > > > On 6/25/07, Soft Linden > > > > wrote: > > > > > Are there one or two things that frustrate you the most, > > > > > which we could make part of our third quarter goals? > > > > > > > > The server side performance and bug we can't patch because it's > > > > closed source. > > > > (and being syadmin, i'm sure i could help with server > performance) > > > > > > > > ::smile:: > > > > > > > > -- > > > > kerunix Flan > > > > _______________________________________________ > > > > Click here to unsubscribe or manage your list subscription: > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > > > > Click here to unsubscribe or manage your list subscription: > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- 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/20070625/bbd58ba8/attachment-0001.htm From bos at lindenlab.com Mon Jun 25 10:34:17 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 25 10:34:19 2007 Subject: [sldev] getting serious about software. In-Reply-To: <1182569545.30666.34.camel@localhost> References: <4679EAC2.3060604@speakeasy.net> <7992d0d60706210234qf4ea53ex667edb8a587ae09d@mail.gmail.com> <1182569545.30666.34.camel@localhost> Message-ID: <467FFC99.9030407@lindenlab.com> Callum Lerwick wrote: > I've experimented with Intel's compiler, but I can't actually get the > thing to link right on Fedora 6/7, so I've only been able to look at its > assembler output. I've got the viewer compiling with version 10 of the Intel compiler. Look for a few changes to SConstruct soon that support this. If you're having linking problems, it's probably because you're linking with icc (the C compiler), when you should be using icpc (the C++ compiler) instead. References: <467FE2A2.500@lindenlab.com> Message-ID: <467FFCB4.8020600@blueflash.cc> Rob Lanphier wrote: > For some users, I think there's something else at play. JIRA > performance is generally quite acceptable for me. That may be true. It's acceptable if I want to file a bug or patch, but I find keeping use of JIRA to a minimum myself (for example voting on issue, sorting through other bug reports, etc). The reason is, that acceptable is quite different from attractive. Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From xotmid at gmail.com Mon Jun 25 10:35:06 2007 From: xotmid at gmail.com (Brandon Husbands) Date: Mon Jun 25 10:35:09 2007 Subject: [sldev] Opening the server source? In-Reply-To: <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> Message-ID: - We need to be in a position to profit from the growth that comes with third-party sim hosting - at least enough to replace lost revenue from our own sim hosting. Simple Domain name registration type of thing. - We need to be in a position to run a variety of versions of the sim on the same grid. Make it manditory for the version. Or atleast compatibility if the sis not compatable people can not TP there. - We need to be able to scale core services to meet a spike in use from a zillion new sims. Reallocate sims... also if you charge enough for a person to be a liscensed registrar not everyone can run a server. - Licensing issues on the middleware that I don't even want to ever have to think about. (Thank you, Rob and Liana!!!) No idea :P On 6/25/07, Tao Takashi wrote: > forgot to CC the list of course.. ;-) here my reply to Soft.. > > Hi! > > Just to get this clear: Is releasing the server as open source and opening > up the grid to plugin third-party servers one project? > I'd think that as long as you don't open up the grid but only release the > source code you wouldn't have to worry about lost revenue? > (as long as nobody creates the backend services themselves and creates > another (separate) grid). > > Of course I can imagine that opening up the grid is a somewhat difficult > task to do from all points of view. > > -- Tao > > > > 2007/6/25, Soft Linden : > > We're certainly a ways off from being in a position where opening the > > sim source fully would make sense. I haven't been in on these > > discussions, but as an outsider to those discussions, I can anticipate > > that LL wouldn't want to do this until a few things happen: > > > > - We need to be in a position to profit from the growth that comes > > with third-party sim hosting - at least enough to replace lost revenue > > from our own sim hosting. > > > > - We need to be in a position to run a variety of versions of the sim > > on the same grid. > > > > - We need to be able to scale core services to meet a spike in use > > from a zillion new sims. > > > > - Licensing issues on the middleware that I don't even want to ever > > have to think about. (Thank you, Rob and Liana!!!) > > > > That said, it's probably silly to treat open sourcing the sim as an > > all-or-nothing affair. If there are specific pieces of the sim you'd > > like to see, I can lobby for us to open source select files. > > > > What you can do is to identify any specific bits and, for each, give > > me strong justification I can arm myself with. The stronger and more > > concise, the better. I'd have to convince folks (including myself if > > I'm putting my name to the effort!) that the benefits outweigh the > > costs. Between legal, developer time, and security auditing, this > > isn't free. Good will on sldev is worth a lot - but so is remaining > > solvent. :) > > > > > > > > On 6/24/07, Able Whitman wrote: > > > Right, having the source in order to build a working simulator only > makes > > > sense if you can also build the pieces of the SL service that the sim > > > depends on. > > > > > > But even without a decoupled architecture, the server source has a great > > > deal of value today: It would tell us how the sim works and interacts > with > > > the viewer, in much more complete detail than what we can infer from the > > > viewer source. > > > > > > Just having a copy of the server source for examination would be > extremely > > > useful. Either that, or a set of detailed, up-to-date design specs. In > my > > > experience, though, "up-to-date" and "design specs" are mutually > exclusive > > > concepts. So I would prefer the source. :) > > > > > > > > > On 6/24/07, Adam Frisby wrote: > > > > **Speculation**: > > > > I believe LL is targetting sometime next year for the official > > > server > > > > release. As far as I am aware, LL still has a long way to go towards a > > > > distributed central architecture before that is a possibility, > although > > > > they certainly appear to be moving in that direction fairly quickly. > > > > > > > > Adam > > > > > > > > Able Whitman wrote: > > > > > > > > > Laurent reminded me of a post I meant to make after triage, but > forgot > > > > > about in my absentmindedness... > > > > > > > > > > It would be nice to know more about the plans to release the sim > source. > > > > > At the last bug triage, Rob mentioned that it was a "long topic for > > > > > another time". I'm not really asking for every last detail, just > some > > > > > information on where things stand, and where they're going. > > > > > > > > > > Is there a timetable for releasing the server code? Are there > blocking > > > > > issues that are confounding the process? At his town hall, Cory > talked > > > > > about the next generation of SL (I'm not sure if "SL 2.0" was his > term > > > > > or not). Will we see a server source release before "SL 2.0"? > > > > > > > > > > I'm just askin' :) > > > > > > > > > > --Able > > > > > > > > > > On 6/24/07, *Laurent Laborde* > > > > > wrote: > > > > > > > > > > On 6/25/07, Soft Linden > > > > > wrote: > > > > > > Are there one or two things that frustrate you the most, > > > > > > which we could make part of our third quarter goals? > > > > > > > > > > The server side performance and bug we can't patch because it's > > > > > closed source. > > > > > (and being syadmin, i'm sure i could help with server > performance) > > > > > > > > > > ::smile:: > > > > > > > > > > -- > > > > > kerunix Flan > > > > > _______________________________________________ > > > > > Click here to unsubscribe or manage your list subscription: > > > > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > _______________________________________________ > > > > > Click here to unsubscribe or manage your list subscription: > > > > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > -- > 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 > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From kerdezixe at gmail.com Mon Jun 25 10:38:19 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Mon Jun 25 10:38:22 2007 Subject: [sldev] Opening the server source? In-Reply-To: <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> Message-ID: <8a1bfe660706251038t4508d9dbi7a5b9d0ed6b45839@mail.gmail.com> On 6/25/07, Tao Takashi wrote: > > Just to get this clear: Is releasing the server as open source and opening > up the grid to plugin third-party servers one project? > I'd think that as long as you don't open up the grid but only release the > source code you wouldn't have to worry about lost revenue? > (as long as nobody creates the backend services themselves and creates > another (separate) grid). > > Of course I can imagine that opening up the grid is a somewhat difficult > task to do from all points of view. Exactly ! 1) We're used to think "opensource server = 3rd party hosting" but it's not the point here. We could have the source without being allowed to connect to the main grid. 2) Licence problems. All we need is the ability to compile, read, and patch the sourcecode. Who said it had to be GPL ? As a first step you could release the sourcecode with a proprietary custom licence and release it as GPL... Later. And if some people don't want to patch non-GPL code... well... they don't, point ! -- kerunix Flan From kelly at lindenlab.com Mon Jun 25 10:38:22 2007 From: kelly at lindenlab.com (Kelly Washington) Date: Mon Jun 25 10:38:26 2007 Subject: [sldev] Opening the server source? In-Reply-To: <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> Message-ID: <467FFD8E.30301@lindenlab.com> Tao Takashi wrote: > (as long as nobody creates the backend services themselves and creates > another (separate) grid). > This is a key point to remember. In addition to Soft's excellent points I have a couple of my own: * Just having the source but being unable to run it is of extremely limited use, even for bug fixing. Right now the 'server side' is a large cloud of services, some central, some distributed to various degrees. If we release *just* the simulator source right now it would be essentially useless. Until someone reverse engineered the central services and started running their own back end systems... * Being able to run a simulator outside our network that can use our services (or appropriately interact with them) is a key part of the *missing* infrastructure needed for our open source goals. * An open source "server" benefits SL and LL far, far more if third parties are able to run regions that interact with the "main" grid and expand the main grid. So much more so that this feature is usually the primary focus of efforts towards an open source "server". - Kelly From jhurliman at wsu.edu Mon Jun 25 10:45:32 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Jun 25 10:45:37 2007 Subject: [sldev] Opening the server source? In-Reply-To: <467FFD8E.30301@lindenlab.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> <467FFD8E.30301@lindenlab.com> Message-ID: <467FFF3C.5020600@wsu.edu> Kelly Washington wrote: > > * Just having the source but being unable to run it is of extremely > limited use, even for bug fixing. Right now the 'server side' is a > large cloud of services, some central, some distributed to various > degrees. If we release *just* the simulator source right now it would > be essentially useless. Until someone reverse engineered the central > services and started running their own back end systems... > Or patched the simulator to use the OpenSim backend service protocols instead. John From kerdezixe at gmail.com Mon Jun 25 10:46:08 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Mon Jun 25 10:46:10 2007 Subject: [sldev] Opening the server source? In-Reply-To: <467FFD8E.30301@lindenlab.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> <467FFD8E.30301@lindenlab.com> Message-ID: <8a1bfe660706251046p6ea1705ava23cfd9eb021ce3f@mail.gmail.com> On 6/25/07, Kelly Washington wrote: > Tao Takashi wrote: > > (as long as nobody creates the backend services themselves and creates > > another (separate) grid). > > > This is a key point to remember. > > In addition to Soft's excellent points I have a couple of my own: > > * Just having the source but being unable to run it is of extremely > limited use, even for bug fixing. Right now the 'server side' is a > large cloud of services, some central, some distributed to various > degrees. If we release *just* the simulator source right now it would > be essentially useless. Until someone reverse engineered the central > services and started running their own back end systems... Then LL could create a separate grid to allow 3rd party sim. And find a way to make it useless for other purpose than testing and debuging. e.g : a specific grid with an asset server cleared every week. It will make the grid useless for "residents" and you'll save money by maintaining only a light-weight database instead of the huge (and probably very costly) asset server. -- kerunix Flan. From bos at lindenlab.com Mon Jun 25 10:59:06 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 25 10:59:10 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <467FB747.5040702@blueflash.cc> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> Message-ID: <4680026A.4040907@lindenlab.com> Nicholaz Beresford wrote: > One small thing on my wishlist would be on JIRA being able to watch > topics and get email notifications on changes. This is very important to us, too. We've done as much as we can internally to get this going, and now we're waiting on some outside tasks to get completed. > A thing regarding the open source and development would be better > communication. Yes, definitely. > One point which is really important for me is communication. I don't > mind if a patch is rejected for good reasons, but with them you usually > seem to get a response on a patch submit within 24 hours. See my earlier message about exactly this. We've had to play catch-up with months of backlogged changes, many of which have bit-rotted or need a lot of manual fixing or complete rewrites to be applied usefully, but we're rapidly closing in on a point where we'll be able to respond to patches within hours or days. References: <4677C7B4.3080602@blueflash.cc> Message-ID: <1182794536.20433.43.camel@localhost> On Tue, 2007-06-19 at 14:10 +0200, Nicholaz Beresford wrote: > http://nicholaz-beresford.blogspot.com/2007/06/memory-leaksleftover-almost-completed.html Just wondering, what OS, compiler and debug tool are you using for your leak debugging? Windows, right? I've been toying with running the client (Linux/gcc) under valgrind, and there appears to still be plenty to clean up. Running under valgrind is rather painful, its difficult to get connected, and stay on long enough to get a decent test in without getting dropped off the sim, which somewhat invalidates the test. (Though it should probably be cleaning itself up properly anyway) To get logged in at all, I have to put a platform way up in the sky where there's NOTHING else, disconnect, start up the client under valgrind, then I can just barely connect fast enough to not have the login time out. Usually it takes a couple tries. This is on my wife's Athlon 64 3000+ laptop (1.8ghz). -------------- 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/20070625/3b81d605/attachment.pgp From bos at lindenlab.com Mon Jun 25 11:02:33 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 25 11:02:34 2007 Subject: [sldev] Firstlook Voice... more memory leak ? In-Reply-To: <8a1bfe660706250648q62f5566eva90082f58b1f10bf@mail.gmail.com> References: <8a1bfe660706250648q62f5566eva90082f58b1f10bf@mail.gmail.com> Message-ID: <46800339.30804@lindenlab.com> Laurent Laborde wrote: > I wish i could help to find the memory leak, and analyze the > crashdump, ... but i don't know how. Have you filed a JIRA task to report this problem? References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> <8a1bfe660706251038t4508d9dbi7a5b9d0ed6b45839@mail.gmail.com> Message-ID: <23bbb49e0706251102l5b9b45ev18183bcf61b8b4f4@mail.gmail.com> 2) Licence problems. All we need is the ability to compile, read, and > patch the sourcecode. Who said it had to be GPL ? As a first step you > could release the sourcecode with a proprietary custom licence and > release it as GPL... Later. And if some people don't want to patch > non-GPL code... well... they don't, point ! I am not sure if patches are of great value then as they only come untested and it might be a unpractical process if a Linden tests them for you and comes back with some error.. So maybe it really would be just handy for understanding the overall mechanisms of SL better and eventually to come up with optimization ideas which could be implemented by LL and the OS team together. -- Tao -- > kerunix Flan > _______________________________________________ > 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/20070625/6b40315a/attachment.htm From tao.takashi at googlemail.com Mon Jun 25 11:17:18 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Jun 25 11:17:20 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <4680026A.4040907@lindenlab.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <4680026A.4040907@lindenlab.com> Message-ID: <23bbb49e0706251117h7920689t91ae956cf4d096de@mail.gmail.com> So I am not directly working on the open source viewer but watching this list here as it's interested to see what is happening. >From my own experiences with Open Source (I am working on the open source CMS Plone, http://plone.org), maybe some ideas: 1) put the name of the one creating a feature or patch in the history and mention them wherever you can. 2) maybe perform sprints here and there where people meet in RL for a few days to work on something closely together. Of course this is best with Linden Lab involved as a) many people can learn from each other (also enables pair programming), b) there is a bigger sense of community, c) communication afterwards is probably better and d) you are quite motivated afterwards. We do this quite often in the Plone community (usually around conferences) and it's a great way of working together. Of course it's also fun :-) (I also heard from Zero and he talked to Rob about such an idea). 3) not sure if there is already but if the irc channel would have some CIA ( http://cia.vc/) and it's able to hook it up with Jira it would maybe be a good mechanism of being alterted by bugs and changes. Additionally it would appear on the website and would make Second Life being an open source project more known. Of course this would make even more sense with a SVN where everybody can post to (or has this happened in the meanwhile, I am bit out of that discussion). Same might go for a checkins mailing list. Ok, just my $0.02 from the outside. -- Tao 2007/6/25, Bryan O'Sullivan : > > Nicholaz Beresford wrote: > > > One small thing on my wishlist would be on JIRA being able to watch > > topics and get email notifications on changes. > > This is very important to us, too. We've done as much as we can > internally to get this going, and now we're waiting on some outside > tasks to get completed. > > > A thing regarding the open source and development would be better > > communication. > > Yes, definitely. > > > One point which is really important for me is communication. I don't > > mind if a patch is rejected for good reasons, but with them you usually > > seem to get a response on a patch submit within 24 hours. > > See my earlier message about exactly this. We've had to play catch-up > with months of backlogged changes, many of which have bit-rotted or need > a lot of manual fixing or complete rewrites to be applied usefully, but > we're rapidly closing in on a point where we'll be able to respond to > patches within hours or days. > > _______________________________________________ > 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/20070625/39d1662a/attachment.htm From secret.argent at gmail.com Mon Jun 25 11:19:52 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 25 11:19:48 2007 Subject: [sldev] Popup ordering patch In-Reply-To: <20070624113252.4323141AF7E@stupor.lindenlab.com> References: <20070624113252.4323141AF7E@stupor.lindenlab.com> Message-ID: > The difference between the two click through issues is this - in > the situation Argent describes (clicking through a lot of dialogs > without reading them), the solution is really a social one rather > than a technical one, i.e. teaching people to *read* before they > click. The solution (and it's an effective one) to that one is to design the application so that you don't need to bring up routine approval dialogs except in exceptional circumstances. Apple used to be good at this, but they seem to have lost the plot a bit in Safari. Microsoft is the worst offender by far, alas... which has led people to equate these kinds of dialogs with secure design. I've got some ideas on addressing that one in SL too. But it's not really the one I'm talking about either. What I'm talking about is simple rote repetition. Repeating the same physical action (clicking the mouse) over and over again in the same spot. Simply moving the buttons around so that destructive and/or irreversible actions won't get caught in the clickstream will fix that one. From garth at fairchang.com Mon Jun 25 11:22:52 2007 From: garth at fairchang.com (Garth FairChang) Date: Mon Jun 25 11:22:55 2007 Subject: [sldev] Re: Firstlook Voice... more memory leak ? References: <20070625172031.DB62941AF15@stupor.lindenlab.com> Message-ID: <00b301c7b755$d7d78f40$8c00a8c0@MikeLaptop> Hi How do we get voice enabled on our sims? We have a private estate and would love to get this going for our residents. Garth FairChang > Date: Mon, 25 Jun 2007 15:48:30 +0200 > From: "Laurent Laborde" > Subject: [sldev] Firstlook Voice... more memory leak ? > To: sldev@lists.secondlife.com > Message-ID: > <8a1bfe660706250648q62f5566eva90082f58b1f10bf@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > when i run Secondlife on my PC (because of the 20" screen against my > 15" macbook pro) i use a software named "O&O Clever cache". This > software have a very nice memory usage monitor. > > Since i upgraded my PC with 3GB of RAM, i noticed a lot of performance > improvment and less crash. I guess that the overhead of swapping cause > a race condition, or some kind of memory inconsistency... and crash. > > With firstlook i noticed that SecondLife can use up to 2GB of memory, > that never happened with the "regular client"... the memory usage is > growing over time... 'til crash. > > I hate to say that, because i want voice, but : i think it should be > fixed before the "official" release of voicechat... swapping is the > cause of a MAJOR slowdown and most people have 1GB or less of RAM (and > fragmented disk and bad virtual memory managment and ...). > > We said that voice won't generate more lag, and i believe this is > true. But this memory leak will generate an insane lag and crash. It > won't take more than a second for people to say "Voice = lag" and > "Linden Lab = Liar", "Fix teh bugz instead of adding features". > > I have voice chat enabled on my 3 major french sims, with a traffic of > 100.000 visitor per month. > We like voice, but most people switch back to the regular client. > Myself, i don't use FirstLook unless i planned to use voice. More > crash, FPS drop, ... > > I wish i could help to find the memory leak, and analyze the > crashdump, ... but i don't know how. > > -- > kerunix Flan > I ARE IN UR MAILING LIST, SPAMING UR DEVZ. :) > > From able.whitman at gmail.com Mon Jun 25 11:29:15 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jun 25 11:29:25 2007 Subject: [sldev] Popup ordering patch In-Reply-To: References: <20070624113252.4323141AF7E@stupor.lindenlab.com> Message-ID: <7b3a84fb0706251129o1442456fleb3c58a283482ab9@mail.gmail.com> One idea I explored (but didn't implement) while working on the patch for VWR-650 was the addidion of a checkbox on permission dialogs that said something like "[ ] Remember my choice for this object". That way you'd only have to grant an object permission once, at least until it was re-rezed. On 6/25/07, Argent Stonecutter wrote: > > > The difference between the two click through issues is this - in > > the situation Argent describes (clicking through a lot of dialogs > > without reading them), the solution is really a social one rather > > than a technical one, i.e. teaching people to *read* before they > > click. > > The solution (and it's an effective one) to that one is to design the > application so that you don't need to bring up routine approval > dialogs except in exceptional circumstances. Apple used to be good at > this, but they seem to have lost the plot a bit in Safari. Microsoft > is the worst offender by far, alas... which has led people to equate > these kinds of dialogs with secure design. > > I've got some ideas on addressing that one in SL too. But it's not > really the one I'm talking about either. > > What I'm talking about is simple rote repetition. Repeating the same > physical action (clicking the mouse) over and over again in the same > spot. Simply moving the buttons around so that destructive and/or > irreversible actions won't get caught in the clickstream will fix > that one. > _______________________________________________ > 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/20070625/f3700c84/attachment-0001.htm From secret.argent at gmail.com Mon Jun 25 11:38:35 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 25 11:38:39 2007 Subject: [sldev] Opening the server source? In-Reply-To: <20070625172031.DB62941AF15@stupor.lindenlab.com> References: <20070625172031.DB62941AF15@stupor.lindenlab.com> Message-ID: <9F191BBE-30B5-42A6-A10E-3FA7CCD24F82@gmail.com> Oh man, I was thinking of the server source being more for improving the Linden code and _maybe_ getting the ability to run personal servers for offline development and testing, rather than opening up the main grid (and the assets therein!) to third-party servers. From nicholaz at blueflash.cc Mon Jun 25 11:45:35 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 11:45:45 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <23bbb49e0706251117h7920689t91ae956cf4d096de@mail.gmail.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <4680026A.4040907@lindenlab.com> <23bbb49e0706251117h7920689t91ae956cf4d096de@mail.gmail.com> Message-ID: <46800D4F.7040506@blueflash.cc> Hi! > 2) maybe perform sprints here and there where people meet in RL for a > few days to work on something closely together. > Of course this is best with Linden Lab involved as a) many people can > learn from each other (also enables pair programming), > b) there is a bigger sense of community, c) communication afterwards is > probably better and d) you are quite motivated afterwards. > We do this quite often in the Plone community (usually around > conferences) and it's a great way of working together. Of > course it's also fun :-) (I also heard from Zero and he talked to Rob > about such an idea). Well, being in Second Life, an open sorcerer's SIM to hang out and just chat while coding or meet or whatever might be an idea to throw into the mix as well. Maybe with a conference hall for regular meetings, triages or whatever ... Nick From okumoto at ucsd.edu Mon Jun 25 11:49:29 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Mon Jun 25 11:49:35 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <46800D4F.7040506@blueflash.cc> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <4680026A.4040907@lindenlab.com> <23bbb49e0706251117h7920689t91ae956cf4d096de@mail.gmail.com> <46800D4F.7040506@blueflash.cc> Message-ID: <46800E39.3070504@ucsd.edu> We could use the groups on SL :-) Is there a "OpenSource Viewer" group? But compiling and running the viewer at the same time hammers my machine :-P Max Nicholaz Beresford wrote: > > Hi! > >> 2) maybe perform sprints here and there where people meet in RL for a >> few days to work on something closely together. >> Of course this is best with Linden Lab involved as a) many people can >> learn from each other (also enables pair programming), >> b) there is a bigger sense of community, c) communication afterwards >> is probably better and d) you are quite motivated afterwards. >> We do this quite often in the Plone community (usually around >> conferences) and it's a great way of working together. Of >> course it's also fun :-) (I also heard from Zero and he talked to Rob >> about such an idea). > > Well, being in Second Life, an open sorcerer's SIM to hang out and > just chat while coding or meet or whatever might be an idea to throw > into the mix as well. > > Maybe with a conference hall for regular meetings, triages or whatever > ... > > > Nick > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Mon Jun 25 11:51:47 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 11:51:56 2007 Subject: [sldev] Memory leaks/leftover almost completed In-Reply-To: <1182794536.20433.43.camel@localhost> References: <4677C7B4.3080602@blueflash.cc> <1182794536.20433.43.camel@localhost> Message-ID: <46800EC3.2040207@blueflash.cc> Callum Lerwick wrote: > On Tue, 2007-06-19 at 14:10 +0200, Nicholaz Beresford wrote: >> http://nicholaz-beresford.blogspot.com/2007/06/memory-leaksleftover-almost-completed.html > > Just wondering, what OS, compiler and debug tool are you using for your > leak debugging? Windows, right? > > I've been toying with running the client (Linux/gcc) under valgrind, and > there appears to still be plenty to clean up. Yes, I'm running under Windows with the Microsoft debug malloc routines ... it's just a small patch to the code and then running the debug version under VS2003 does it. It's still slow as molass, so nothing to do and enjoy an SL session and check the log afterwards, but good enough for dedicated leak hunting. Downside is currently that (as Able observed recently) that under VS2005 it doesn't compile as a debug version because one of the libs (libmoz) interferes, so it's probably useful for as many people as it could. But from my tests (leak dump and memory usage under normal conditions), under Windows the whole thing is pretty much under control. I'm aware of one area which needs attention. It's not exactly leaking, but progressively growing until it's all cleaned up at the end, but besides that, real leaks are down to minimal (with the stuff I have tested and observed). Nick From secret.argent at gmail.com Mon Jun 25 12:00:43 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Mon Jun 25 12:00:37 2007 Subject: [sldev] Popup ordering patch In-Reply-To: <7b3a84fb0706251129o1442456fleb3c58a283482ab9@mail.gmail.com> References: <20070624113252.4323141AF7E@stupor.lindenlab.com> <7b3a84fb0706251129o1442456fleb3c58a283482ab9@mail.gmail.com> Message-ID: <28CE935F-532A-4F7D-A79F-8DCAF22178AE@gmail.com> On 25-Jun-2007, at 13:29, Able Whitman wrote: > One idea I explored (but didn't implement) while working on the > patch for VWR-650 was the addidion of a checkbox on permission > dialogs that said something like "[ ] Remember my choice for this > object". That way you'd only have to grant an object permission > once, at least until it was re-rezed. That's part of it. Another one is a SCADA-style alarm handler. After the second dialog you get the option of a browser interface (the iTunes interface is a good example of a browser) that allows you to accept or deny or acknowledge multiple messages at once. And this should be the default interface for requests received when offline. Another one is to make it possible to easily undo things, and then don't bother asking for approval. For example, you should be able to bring up a list of all the permissions you've granted and revoke them individually or en-masse. Then you can expand automatic permission grants ... e.g.: objects owned by the landowner or set to the land- owning group could automatically get animate and camera permissions. Same with objects owned by people in your friends list. The way auto-preview of textures and notecards is handled is pretty annoying, too: you get *two* "dialogs" to handle instead of just the the one, and two choices to "keep"... I would much rather just have the window be the dialog... that's not the problem, the way multiple textures are handled is the problem. Pop up *one* texture, if you must, and then put a "next" button on the window. If the user closes it instead, they don't get any more pending previews. From josh at lindenlab.com Mon Jun 25 12:10:12 2007 From: josh at lindenlab.com (Joshua Bell) Date: Mon Jun 25 12:08:14 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <1182743180.20433.29.camel@localhost> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <1182743180.20433.29.camel@localhost> Message-ID: <46801314.7060205@lindenlab.com> Callum Lerwick wrote: > Ultimately it would be nice to just have required updates go away > entirely, if I understand correctly, 1.18 is a step in that direction? > At the very least, allowing some version overlap would solve most of the > problem. > Yes, 1.18 is a step in that direction - how big a step remains to be seen. As anyone who's worked on an application that supports backwards/forwards-compatibility among file formats and/or plug-ins knows, even with a great framework in place compatibility is rarely trivial. It becomes a question of how important it is to maintain compatibility vs. the resources that will be spent on it. Joshua From josh at lindenlab.com Mon Jun 25 12:17:10 2007 From: josh at lindenlab.com (Joshua Bell) Date: Mon Jun 25 12:15:12 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <467FB747.5040702@blueflash.cc> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> Message-ID: <468014B6.6090707@lindenlab.com> Nicholaz Beresford wrote: > The other (big) thing, and I think the comments on the blog for > the 1.17.1 and 1.18 release announcements support that, would be to > make the 3rd quarter the quarter of "bug fixing". Oh darn, sounds like I do have to go read those comments. *sigh* Seriously though - feedback on how we're doing on bugs would be appreciated. The signal:noise ratio on most of our feedback mechanisms is extremely low. Every time I post to the blog saying "we're releasing 1.X which has 40 bug fixes" and the comments are "why aren't you fixing bugs?". Or my favorite: "Why was a Linden on the beta grid testing things when he should be fixing bugs?" The developer community here on SLDEV has a better insight into the cost and risk associated with bug fixes than many non-developers, and can understand when e.g. we announce "message template liberation" that decoupling viewer updates from server updates is a Good Thing even if it doesn't fix a pet bug. So please call us on egregious outstanding bugs that may be lost in the noise, and our fix rate. From okumoto at ucsd.edu Mon Jun 25 12:15:08 2007 From: okumoto at ucsd.edu (Max Okumoto) Date: Mon Jun 25 12:15:19 2007 Subject: [sldev] Memory leaks/leftover almost completed In-Reply-To: <46800EC3.2040207@blueflash.cc> References: <4677C7B4.3080602@blueflash.cc> <1182794536.20433.43.camel@localhost> <46800EC3.2040207@blueflash.cc> Message-ID: <4680143C.7080809@ucsd.edu> If you are building on Linux and using valgrind Bryan O'Sullivan mentioned that the tcmalloc() libraries and valgrind are in compatible. So you will need to link without tcmalloc to use valgrind. Max Nicholaz Beresford wrote: > > Callum Lerwick wrote: >> On Tue, 2007-06-19 at 14:10 +0200, Nicholaz Beresford wrote: >>> http://nicholaz-beresford.blogspot.com/2007/06/memory-leaksleftover-almost-completed.html >>> >> >> Just wondering, what OS, compiler and debug tool are you using for your >> leak debugging? Windows, right? >> >> I've been toying with running the client (Linux/gcc) under valgrind, and >> there appears to still be plenty to clean up. > > Yes, I'm running under Windows with the Microsoft debug malloc > routines ... it's just a small patch to the code and then running > the debug version under VS2003 does it. > > It's still slow as molass, so nothing to do and enjoy an SL session > and check the log afterwards, but good enough for dedicated leak > hunting. > > Downside is currently that (as Able observed recently) that under > VS2005 it doesn't compile as a debug version because one of the > libs (libmoz) interferes, so it's probably useful for as many > people as it could. > > But from my tests (leak dump and memory usage under normal conditions), > under Windows the whole thing is pretty much under control. > > I'm aware of one area which needs attention. It's not exactly > leaking, but progressively growing until it's all cleaned up at > the end, but besides that, real leaks are down to minimal (with > the stuff I have tested and observed). > > > Nick > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From jef at pleiades.ca Mon Jun 25 12:21:42 2007 From: jef at pleiades.ca (Jonathan Freedman) Date: Mon Jun 25 12:21:46 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <46800D4F.7040506@blueflash.cc> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <4680026A.4040907@lindenlab.com> <23bbb49e0706251117h7920689t91ae956cf4d096de@mail.gmail.com> <46800D4F.7040506@blueflash.cc> Message-ID: <468015C6.2050902@pleiades.ca> There is a plot related to the open metaverse project located in the North West corner of Theta (http://slurl.com/secondlife/Theta/28/230/32). Feel free to use it for whatever purpose. If you require more dedicated use of the sim (for larger meetings) then let Tao or I know. We are both residents of Pi/Theta and can reserve (and convert) the sandbox on an as-needed basis. I bet there are more Pi residents lurking out there too ;) As for my L$2 on the overall theme of this thread - I think that Linden Lab has made remarkable progress even in the past quarter and I would be surprised if this momentum doesn't keep building. Oh. And, from a libsl point of view, I'm psyched to see the message liberation stuff hitting the grid on Wed. Congrats to LL and Icehouse. Cheers Jonathan Freedman / otakup0pe Neumann VP Operations Pleiades Consulting Nicholaz Beresford wrote: > > Hi! > >> 2) maybe perform sprints here and there where people meet in RL for a >> few days to work on something closely together. >> Of course this is best with Linden Lab involved as a) many people can >> learn from each other (also enables pair programming), >> b) there is a bigger sense of community, c) communication afterwards >> is probably better and d) you are quite motivated afterwards. >> We do this quite often in the Plone community (usually around >> conferences) and it's a great way of working together. Of >> course it's also fun :-) (I also heard from Zero and he talked to Rob >> about such an idea). > > Well, being in Second Life, an open sorcerer's SIM to hang out and > just chat while coding or meet or whatever might be an idea to throw > into the mix as well. > > Maybe with a conference hall for regular meetings, triages or whatever > ... > > > Nick > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From able.whitman at gmail.com Mon Jun 25 12:24:44 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jun 25 12:24:46 2007 Subject: [sldev] Popup ordering patch In-Reply-To: <28CE935F-532A-4F7D-A79F-8DCAF22178AE@gmail.com> References: <20070624113252.4323141AF7E@stupor.lindenlab.com> <7b3a84fb0706251129o1442456fleb3c58a283482ab9@mail.gmail.com> <28CE935F-532A-4F7D-A79F-8DCAF22178AE@gmail.com> Message-ID: <7b3a84fb0706251224p63f03748yccbf3cf2c076565b@mail.gmail.com> Changing the notification popup system from a stack of popups a scrollable list of popups would be great. You could even group them together based on which notification template they used, so each group would have the same semantics (Yes / No, Accept / Decline / Mute, etc.). For textures, instead of a Next/Back button, I'd be happy just to see multiple textures docked inside of a tablist, similar to how IM windows work now. Then at least your whole window wouldn't fill up if you had many textures open at the same time. An added advantage is that the viewer would only display one texture out of many at a time. I don't know about anyone else, but on my system the viewer slows to a crawl if more than one texture window is open, and this would be a nice way to address that. And for "given" inventory in general, I'd love to see the viewer lump together lots of similar objects together, when they're given within a certain period of time. So instead of 5 "Foo Bar has given you a notecard" popups (or even a list of 5 notecards), I'd just like one entry that says "Foo Bar has given you 5 notecards", and I can accept or decline them all in one fell swoop. I'd love to be able to have a master list of objects I've granted (or denied) permissions to, and which permissions I've granted/denied. I believe, though, that this permission information is stored along with object state, so there's no way to gather all the distributed information in one place. Hmm... there are several feature requests here; I think I should file a few JIRA entries. :) On 6/25/07, Argent Stonecutter wrote: > > On 25-Jun-2007, at 13:29, Able Whitman wrote: > > One idea I explored (but didn't implement) while working on the > > patch for VWR-650 was the addidion of a checkbox on permission > > dialogs that said something like "[ ] Remember my choice for this > > object". That way you'd only have to grant an object permission > > once, at least until it was re-rezed. > > That's part of it. > > Another one is a SCADA-style alarm handler. After the second dialog > you get the option of a browser interface (the iTunes interface is a > good example of a browser) that allows you to accept or deny or > acknowledge multiple messages at once. > > And this should be the default interface for requests received when > offline. > > Another one is to make it possible to easily undo things, and then > don't bother asking for approval. For example, you should be able to > bring up a list of all the permissions you've granted and revoke them > individually or en-masse. Then you can expand automatic permission > grants ... e.g.: objects owned by the landowner or set to the land- > owning group could automatically get animate and camera permissions. > Same with objects owned by people in your friends list. > > The way auto-preview of textures and notecards is handled is pretty > annoying, too: you get *two* "dialogs" to handle instead of just the > the one, and two choices to "keep"... I would much rather just have > the window be the dialog... that's not the problem, the way multiple > textures are handled is the problem. Pop up *one* texture, if you > must, and then put a "next" button on the window. If the user closes > it instead, they don't get any more pending previews. > _______________________________________________ > 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/20070625/eedd42c1/attachment.htm From able.whitman at gmail.com Mon Jun 25 12:53:02 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jun 25 12:53:05 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <467FB747.5040702@blueflash.cc> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> Message-ID: <7b3a84fb0706251253g2c82526coaf0013526f6420@mail.gmail.com> > > > The other (big) thing, and I think the comments on the blog for > the 1.17.1 and 1.18 release announcements support that, would be to > make the 3rd quarter the quarter of "bug fixing". This is probably > something King Philip would need to do (like Bill Gates at one point > just announced the "year of security" or something like that), but > a quarter of letting the dust settle, where everybody would just > work on fixing and cleaning up stuff, would do the whole viewer a > lot of good. > > I have to disagree, actually. While I do think it's vitally important to try and stay on top of the bugs which cause the biggest pain points, I don't think it's reasonable to focus only on big fixes. First, at least, is the fact that sometimes the line between bug fix and new feature is blurry. Modifying the internal browser to support cookies was certainly a new feature, but it also fixed the bug that sites using cookies didn't work in the internal browser, to pick just one example. :) Also, I think trying to get a team focused 100% on fixing defects has a deleterious effect on morale. It's good to guide your team's efforts so that they are properly prioritizing between testing, bug fixing, and new feature work. But when you're doing nothing but bug fixing, it quickly becomes an environment where people feel like they're stuck in a rut and not making an real progress. That's not conducive to keeping folks happy, and happiness is more important than just helping people feel good: Happy devs write better code, and happy testers find better bugs. Don't let Billg fool you -- even during the year-long security push, there was plenty of new feature working going on. Sure, a lot of those new features were security-related, but you can't just stop working on software for a year (or even a quarter). The only time I saw an entire team go heads-down into code reviews and bug fixing was when the COM folks went dark after the remotely-exploitable DCOM flaws a few years back. That effort was disasterous for morale, and I saw a bunch of people leave for another team, or another company, or burnout entirely. Again, it's a matter of prioritization and communication (both internal and external), and finding the right balance between bugs and features. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070625/804a5600/attachment-0001.htm From nicholaz at blueflash.cc Mon Jun 25 13:13:44 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 13:13:52 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <468014B6.6090707@lindenlab.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <468014B6.6090707@lindenlab.com> Message-ID: <468021F8.9040302@blueflash.cc> Joshua Bell wrote: > Nicholaz Beresford wrote: >> The other (big) thing, and I think the comments on the blog for >> the 1.17.1 and 1.18 release announcements support that, would be to >> make the 3rd quarter the quarter of "bug fixing". > Oh darn, sounds like I do have to go read those comments. *sigh* > > Seriously though - feedback on how we're doing on bugs would be > appreciated. The signal:noise ratio on most of our feedback mechanisms > is extremely low. Every time I post to the blog saying "we're releasing > 1.X which has 40 bug fixes" and the comments are "why aren't you fixing > bugs?". Or my favorite: "Why was a Linden on the beta grid testing > things when he should be fixing bugs?" What's interesting is that I find the comments on the blog quite precise. If I filter out 20% personal pet issues and abusive stuff, it's easy to see what people care about. Number one is logins and general grid health. You can fix all the bugs you like, if the grid isn't working, complaints about that will drown out everything. (Nobody cares about viewer crashes if they can't even get in or can't get anywhere). If grid and login works, what affects people most is communication, like friend list, lost inventory, group notices ... that kind of stuff. If that also works, the smaller stuff will come up and it may really be hard to pick what's most important there. I may have a tinted view, but I think the comments on those two posts were mainly positive, in the direction that "oh yes, please fix bugs and don't break new things". Even the announcement that Windlight was put to rest for a few weeks was taken positively in the sense that it's better to hold things back until it's working okay, than making one release too many which breaks things. I think it's been the consistent theme ever since I joined SL (some time in February). It also was the prime theme from the Open Letter. I'm a software developer myself with my own line of software, so I know both perspectives. Sometimes things need to be done and they're bound to break something somewhere. But with my software (and also when using software) I found that people want stability first and then features. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Mon Jun 25 13:32:13 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 13:32:24 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <7b3a84fb0706251253g2c82526coaf0013526f6420@mail.gmail.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <7b3a84fb0706251253g2c82526coaf0013526f6420@mail.gmail.com> Message-ID: <4680264D.9060704@blueflash.cc> Able Whitman wrote: > > The other (big) thing, and I think the comments on the blog for > the 1.17.1 and 1.18 release announcements support that, would be to > make the 3rd quarter the quarter of "bug fixing". This is probably > something King Philip would need to do (like Bill Gates at one point > just announced the "year of security" or something like that), but > a quarter of letting the dust settle, where everybody would just > work on fixing and cleaning up stuff, would do the whole viewer a > lot of good. > > I have to disagree, actually. While I do think it's vitally important to > try and stay on top of the bugs which cause the biggest pain points, I > don't think it's reasonable to focus only on big fixes. First, at least, > is the fact that sometimes the line between bug fix and new feature is > blurry. Modifying the internal browser to support cookies was certainly > a new feature, but it also fixed the bug that sites using cookies didn't > work in the internal browser, to pick just one example. :) > > Also, I think trying to get a team focused 100% on fixing defects has a > deleterious effect on morale. Dunno, three months fixing stuff doesn't sound so bad to me. It can even be quirks or even just a general priority or policy that steers people (and from what I hear, Lindens pick their areas and tasks pretty much by themselves). I know software development in cycles. And one of the cycles ultimately is focusing on stability. I really don't know how things work inside Linden Lab, and what motivation drives people (from the management down to the junior coders), but I've spoken to a lot of residents and the user's comments on my blog speak for themselves also. > But when you're doing nothing but bug fixing, it quickly becomes an > environment where people feel like they're stuck in a rut and not making > an real progress. Well, if people are not seeing stability as progress ... umm, I guess then a project is in trouble. > Sure, a lot of those new features were security-related, but you can't > just stop working on software for a year (or even a quarter). A year may be long, but personally I see no problem with a quarter if the prospect is right. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Mon Jun 25 14:05:31 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 14:05:41 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <4680026A.4040907@lindenlab.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <4680026A.4040907@lindenlab.com> Message-ID: <46802E1B.7020107@blueflash.cc> >> One point which is really important for me is communication. I don't >> mind if a patch is rejected for good reasons, but with them you usually >> seem to get a response on a patch submit within 24 hours. > > See my earlier message about exactly this. We've had to play catch-up > with months of backlogged changes, many of which have bit-rotted or need > a lot of manual fixing or complete rewrites to be applied usefully, but > we're rapidly closing in on a point where we'll be able to respond to > patches within hours or days. It's definitely visible and appreciated from my side, and I'm sure this will help the residents, open sourcers and Linden Lab folks. Thanks! Nick From bos at lindenlab.com Mon Jun 25 14:19:27 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 25 14:19:29 2007 Subject: [sldev] The recent uptick in open source patch activity, and where it's going Message-ID: <4680315F.4070709@lindenlab.com> Hi, all - As Soft mentioned, we're making a big effort within Linden Lab to review and apply patches from open source contributors. As recently as a month ago, our backlog of patches stretched to almost six months. We've since brought that down to, in most instances, about a month. We're closing in pretty quickly on a backlog near zero, which is great. My hope is that in the future, we ought to be able to triage and review patches within hours to days, not weeks to months. This can't be a promise, because there are always fires to fight and distractions to fend off, but we'd really like to be able to turn your submissions around quickly and effectively. If you've looked through source tarballs, you'll have seen the doc/contributions.txt file that lists all of the patches we've either applied or taken inspiration from. We are conscientious about crediting even one-liners. However, that file is pretty invisible, and doesn't to my mind do nearly a good enough job of acknowledging the efforts of people outside of LL who are working on the viewer. We're working to find a more visible and regular way to give credit to people for their work; watch this space. References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <7b3a84fb0706251253g2c82526coaf0013526f6420@mail.gmail.com> <4680264D.9060704@blueflash.cc> Message-ID: <7b3a84fb0706251429o67e44d87n436368e1af91fa52@mail.gmail.com> > > Dunno, three months fixing stuff doesn't sound so bad to me. It can > even be quirks or even just a general priority or policy that steers > people (and from what I hear, Lindens pick their areas and tasks pretty > much by themselves). Yes, that's exactly what I mean by setting priorities and finding a balance. You can't build coherent features without having a policy that sets your direction, and you can't be most effective at fixing bugs (at least not in a large software project) without some overall guidance. I know software development in cycles. And one of the cycles ultimately > is focusing on stability. I really don't know how things work inside > Linden Lab, and what motivation drives people (from the management down > to the junior coders), but I've spoken to a lot of residents and the > user's comments on my blog speak for themselves also. >From what Cory said at his last town hall, something like 65% of the devs are focused on bug fixes. That sounds pretty much like a focus on stability to me, but of course development cycles differ, so perhaps my particular kind of development lifecycle experience has biased me. I have no reason to doubt what Cory has said, and I can only assume that most of the remaining 35% of people are working on decentralizing the SL architecture, which in itself is a big bug fix in terms of scalability, reliability, and performance. Well, if people are not seeing stability as progress ... umm, I guess then > a project is in trouble. That's not what I'm saying; of course stability is vitally important, and I think LL has acknowldged that, even if they're not moving as fast as we might like. (Although I suspect that what we would always like is for them to be moving faster.) All I mean is that I don't think the incremental benefit of shifting from 65% bug fix work to 100% bug fix work would be worth the lost time in larger architectural improvements I don't think you'd see 35% more bugs fixed, or see fixes take 35% less time to implement. A year may be long, but personally I see no problem with a quarter if > the prospect is right. But that's the trick, though, right? Putting more people onto bug fixing is only part of the solution. The other part is that communication runs both ways, and the if the residents can help point out which bugs are the most painful and the most important to fix, then the Lindens can more effectively direct their efforts to addressing those bugs. I agree that the signal-to-noise in the blog comments (and even the forums) about bugs and pain points is actually pretty high. JIRA is sometimes a pain to use, even if you're familiar with bug tracking tools; it's downright daunting if what you're expecting is "click here if you're having trouble with group IMs not closing" or something like that. There's definitely improvements that can be made on both ends of bug reporting, but my perception of the rate of fixes is that lately it's been much higher than in the past, and that is definitely a Good Thing. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070625/1842ec14/attachment.htm From bos at lindenlab.com Mon Jun 25 14:34:14 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Mon Jun 25 14:34:16 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <4680264D.9060704@blueflash.cc> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <7b3a84fb0706251253g2c82526coaf0013526f6420@mail.gmail.com> <4680264D.9060704@blueflash.cc> Message-ID: <468034D6.8000705@lindenlab.com> Nicholaz Beresford wrote: > Dunno, three months fixing stuff doesn't sound so bad to me. We spend a lot more time than that on fixing problems. In terms of how our developers spend their time right now, it's more like nine months out of twelve spent fixing stuff, for loose values of "fixing" and "stuff". Remember, we have to work on problems that have massively different timescales. When griefers find a new attack mode, we have to be able to respond within hours. At the same time, we have to look a year into the future and ensure that the infrastructure we build now can cope with the users and concurrency levels we'll be seeing then. We spend comparatively little of our time working on new features. For example, the recent addition of sculpted prims was due almost entirely to one person working furiously in his spare time for months. The Windlight code turned up as part of the acquisition of a team of great developers we didn't even have before. Fixing stuff is our top priority. Hi folks, We're replacing my old Wednesday and Friday office hour with a single general purpose open source meeting. The new time will be Thursday, at 2pm PDT. This week's meeting will be held at SL4B: http://slurl.com/secondlife/SL4B/211/136/254 Agenda will be posted here: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda Future meeting location TBD, quite possibly still at my cube. More later. Right now, there's a bug triage: https://wiki.secondlife.com/wiki/Bug_triage/Agenda Rob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070625/b3948be8/signature-0001.pgp From matthew.dowd at hotmail.co.uk Mon Jun 25 15:36:17 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Mon Jun 25 15:36:19 2007 Subject: [sldev] Voice source Message-ID: Am I right in thinking that the source for the voice firstlook isn't available yet? or am I just not looking in the right place? I've been tweaking the chatterbox UI but think I've got as far as I can with the skin xml files without touching the source code. Matthew _________________________________________________________________ The next generation of MSN Hotmail has arrived - Windows Live Hotmail http://www.newhotmail.co.uk From nicholaz at blueflash.cc Mon Jun 25 16:34:42 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 16:34:52 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <468034D6.8000705@lindenlab.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <7b3a84fb0706251253g2c82526coaf0013526f6420@mail.gmail.com> <4680264D.9060704@blueflash.cc> <468034D6.8000705@lindenlab.com> Message-ID: <46805112.9000703@blueflash.cc> Bryan O'Sullivan wrote: > We spend a lot more time than that on fixing problems. > > In terms of how our developers spend their time right now, it's more > like nine months out of twelve spent fixing stuff, for loose values of > "fixing" and "stuff". Remember, we have to work on problems that have > massively different timescales. When griefers find a new attack mode, > we have to be able to respond within hours. At the same time, we have > to look a year into the future and ensure that the infrastructure we > build now can cope with the users and concurrency levels we'll be seeing > then. I believe you. I was just looking at the releasenotes doc and the list of changes is impressive. The odd thing however is, that even being a developer myself, this sort of escaped me. I know that it must be hell to go through the changes in infrastructure I think in my first week the concurrency broke through 20000 and the grid felt as if it was falling apart and just a moment ago it sailed easily on with over 45000 online. It's been incredible growth, that's for sure. > We spend comparatively little of our time working on new features. For > example, the recent addition of sculpted prims was due almost entirely > to one person working furiously in his spare time for months. The > Windlight code turned up as part of the acquisition of a team of great > developers we didn't even have before. I was just mentioning today to a friend that what Qarl did there was a terrific job. I think I did not see a single bug outside the sculpties realm (that is addition of scuplties breaking something else). But even if not much work went into Windlight and Voice, the annoucements of those versions came with pretty bad timing. > Fixing stuff is our top priority. Again, I do believe you, but at the same time I can say that until this mail I didn't see it. Maybe it boils down to communication, or maybe you guys have sort of given up letting the public know what's behind problems or what you are working on because no matter what you do, you get a beating from the public anyway. I don't imply spin-doctoring when saying communication, quite the opposite. On the SL blog or forum things always got worse, when there was no word from LL about the problems at all. Maybe I just have a too narrow view and came online through bad times, but I can understand a lot of comments on the SL blog or in the forums or blogosphere, because from the outside things are looking a lot different than from the inside. I really don't want to bash on you guys, I know that getting through a growth rate like this must be hell, but I guess it would really help if more of your efforts behind the scene would be visible on the outside (I think that "post mortem" post on the blog as really a good example for that and was also received well). People really love your platform/world, that's why they are going beserk if it doesn't work. And I love it, otherwise I would throw my hours at some other open source project. I'll keep my fingers crossed that 1.18 will be remembered as the version when things got better again (as many people told me that things went downhill with 1.14). Keep it up ... Nick From nicholaz at blueflash.cc Mon Jun 25 16:38:26 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 16:38:33 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <7b3a84fb0706251429o67e44d87n436368e1af91fa52@mail.gmail.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <7b3a84fb0706251253g2c82526coaf0013526f6420@mail.gmail.com> <4680264D.9060704@blueflash.cc> <7b3a84fb0706251429o67e44d87n436368e1af91fa52@mail.gmail.com> Message-ID: <468051F2.5070501@blueflash.cc> > I agree that the signal-to-noise in the blog comments (and even the > forums) about bugs and pain points is actually pretty high. JIRA is > sometimes a pain to use, even if you're familiar with bug tracking > tools; it's downright daunting if what you're expecting is "click here > if you're having trouble with group IMs not closing" or something like > that. There's definitely improvements that can be made on both ends of > bug reporting, but my perception of the rate of fixes is that lately > it's been much higher than in the past, and that is definitely a Good > Thing. I think so too. I've been telling people, that JIRA may be a geek took, but geeks have the same problems as everybody else, but are able to communicate with delveopers more in the form they can use and understand effectively. Or the geeks can just fix the stuff themselves *grin* Nick From robla at lindenlab.com Mon Jun 25 16:42:18 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Jun 25 16:42:26 2007 Subject: [sldev] Voice source In-Reply-To: References: Message-ID: <468052DA.4000003@lindenlab.com> On 6/25/07 3:36 PM, Matthew Dowd wrote: > Am I right in thinking that the source for the voice firstlook isn't available yet? or am I just not looking in the right place? I've been tweaking the chatterbox UI but think I've got as far as I can with the skin xml files without touching the source code. > No voice source yet. There's some work that needs to happen to untangle some dependencies before we can make the source available. I'll ping folks here about the timing of that, but my understanding is that it should be happening soon. 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/20070625/b5dac329/signature.pgp From anthony at lindenlab.com Mon Jun 25 16:59:40 2007 From: anthony at lindenlab.com (Anthony Foster) Date: Mon Jun 25 16:58:18 2007 Subject: [sldev] Source release for 1.17.1.0 Message-ID: <468056EC.4000303@lindenlab.com> Hello everyone, This is an optional viewer. 1.17.1.0 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.1.0 Release note information here: http://blog.secondlife.com/2007/06/25/optional-viewer-and-rolling-restart-this-monday-june-25th/#more-1044 Checksums: ca87865a746a2af6ac8b0e82a812f17a slviewer-darwin-libs-1.17.1.0.tar.gz 9502fd1c346b22c26f59a2e055808270 slviewer-linux-libs-1.17.1.0.tar.gz f31af3a6daeb18bb57e7e4e001793b5f slviewer-src-1.17.1.0.tar.gz bafd46c6ea5ee19f834c62df04869b3d slviewer-artwork-1.17.1.0.zip 8a86aeb603287536ac5356f5727d307d slviewer-src-1.17.1.0.zip 97fa81127d146bf338d4fb0798f7e3cf slviewer-win32-libs-1.17.1.0.zip SVN checkout: http://svn.secondlife.com/svn/linden/release Enjoy. -Anthony From nicholaz at blueflash.cc Mon Jun 25 17:05:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 17:05:28 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <468014B6.6090707@lindenlab.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <467FB747.5040702@blueflash.cc> <468014B6.6090707@lindenlab.com> Message-ID: <46805842.6090505@blueflash.cc> Joshua Bell wrote: > Nicholaz Beresford wrote: >> The other (big) thing, and I think the comments on the blog for >> the 1.17.1 and 1.18 release announcements support that, would be to >> make the 3rd quarter the quarter of "bug fixing". > > Oh darn, sounds like I do have to go read those comments. *sigh* Go read the comments on Zero Lindens "D?a de la Liberaci?n". You'll like them ... Nick From nicholaz at blueflash.cc Mon Jun 25 17:06:17 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Mon Jun 25 17:06:22 2007 Subject: [sldev] Source release for 1.17.1.0 In-Reply-To: <468056EC.4000303@lindenlab.com> References: <468056EC.4000303@lindenlab.com> Message-ID: <46805879.8060505@blueflash.cc> Anthony Foster wrote: > Hello everyone, > > This is an optional viewer. > > 1.17.1.0 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.1.0 Oh dang ... it's 2AM here ... there goes another night's sleep :-) Nick From rdw at lindenlab.com Mon Jun 25 17:58:36 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Mon Jun 25 17:59:07 2007 Subject: [sldev] Source release for 1.18.0.0 In-Reply-To: <467D9670.1080209@ucsd.edu> References: <467A2837.8040001@ucsd.edu> <467D95A7.4000804@lindenlab.com> <467D9670.1080209@ucsd.edu> Message-ID: <468064BC.3050007@lindenlab.com> I thought that I'd have template_verifier.py ready for release today, but it depends on a master message template that's currently internal-only, and the Web team has been hammered with various bugs today, so we haven't been able to export it to a public location. Soon, though, soon. In the meantime, though, I did post the documentation about what template_verifier.py actually does. http://wiki.secondlife.com/wiki/Template_verifier.py This page also comprehensively describes the message template compatibility policy created by Message Liberation (and which template_verifier.py enforces). Feel free to reorganize it if it doesn't make sense to put the information together like this. (That's why it's a wiki!) -RYaN Max Okumoto wrote: > Ok thanks. I had done that but hadn't really drilled down to see if > that was ok. > > Max > > Ryan Williams wrote: >> Sorry about the omission! template_verifier.py actually has 4 >> dependencies, which should all be ready for posting after the >> weekend. For now though, try just working around it by writing a >> no-op .py in its place. >> >> -RYaN >> >> Max Okumoto wrote: >>> Hi Anthony, >>> >>> It looks like 1.18.0.0 is missing scripts/template_verifier.py is >>> there anyway you could post this file to the list? >>> >>> Max >>> >>> Did anyone try this yet under Windows? >>> >>> ------ Build started: Project: newview, Configuration: >>> ReleaseForDownload Win32 ------ >>> Executing pre-build batch file >>> '"../../scripts/template_verifier.py"' is not recognized as an >>> internal or external command, >>> operable program or batch file. >>> PREBUILD FAILED >>> newview : error PRJ0002 : error result returned from >>> >>> 'w:\sl1_18_0_0\linden\indra\newview\ReleaseForDownload\BAT00002E.bat'. >>> >>> >>> >>> Nick >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >>> > From able.whitman at gmail.com Mon Jun 25 18:57:39 2007 From: able.whitman at gmail.com (Able Whitman) Date: Mon Jun 25 18:57:41 2007 Subject: [sldev] Cross compiling the viewer Message-ID: <7b3a84fb0706251857t683d6d41w6824e61e03b1ffaf@mail.gmail.com> I have limited cross-compiling experience, so pardon me if this is a dumb question: Is it possible to cross compile a Mac viewer binary on a Windows system? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070625/49ea9e8c/attachment.htm From tshephard at gmail.com Mon Jun 25 19:54:21 2007 From: tshephard at gmail.com (Tim Shephard) Date: Mon Jun 25 19:54:25 2007 Subject: [sldev] Opening the server source? In-Reply-To: <9F191BBE-30B5-42A6-A10E-3FA7CCD24F82@gmail.com> References: <20070625172031.DB62941AF15@stupor.lindenlab.com> <9F191BBE-30B5-42A6-A10E-3FA7CCD24F82@gmail.com> Message-ID: <3b19a500706251954g76ae7a2fl582e15499eb6e09e@mail.gmail.com> I suspect the biggest road block is scalability. Once they have scalability nailed so they can handle a "zillion" sims connected to the grid, I suspect they'll be all over it as the profit potential is near unlimited. However, until scalability is nailed (if such a feat is possible), open sourcing it would just be an invitation for people to fork. From soft at lindenlab.com Mon Jun 25 20:17:47 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jun 25 20:17:49 2007 Subject: [sldev] Opening the server source? In-Reply-To: <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> Message-ID: <9e6e5c9e0706252017o55e72e50q847c5335506834dc@mail.gmail.com> Kelly said it pretty well. Someone else creating the backend services is a concern. Once sim source is in hand, a rival grid is an exciting project if there's currently no way to use it. If we release *after* we're ready to take on third-party sims, rival grids might be about as exciting a project as those third-party alternative DNS networks. They're good to have around, but hopefully they're just there to keep us honest and playing nicely as we try to be the mainstream grid. Again though - 1) That's all speculation on my part, not some insight into a great master plan. Again - those discussions happen outside my corner of LL! 2) If you can point to specific modules of the sim that you'd like to see and can help me with an argument for getting them open sooner, I'm all ears. I'm all for anything that pushes SL forward, and the lot of ya are pretty well aligned with that goal. :) On 6/25/07, Tao Takashi wrote: > forgot to CC the list of course.. ;-) here my reply to Soft.. > > Hi! > > Just to get this clear: Is releasing the server as open source and opening > up the grid to plugin third-party servers one project? > I'd think that as long as you don't open up the grid but only release the > source code you wouldn't have to worry about lost revenue? > (as long as nobody creates the backend services themselves and creates > another (separate) grid). > > Of course I can imagine that opening up the grid is a somewhat difficult > task to do from all points of view. > > -- Tao > > > > 2007/6/25, Soft Linden : > > We're certainly a ways off from being in a position where opening the > > sim source fully would make sense. I haven't been in on these > > discussions, but as an outsider to those discussions, I can anticipate > > that LL wouldn't want to do this until a few things happen: > > > > - We need to be in a position to profit from the growth that comes > > with third-party sim hosting - at least enough to replace lost revenue > > from our own sim hosting. > > > > - We need to be in a position to run a variety of versions of the sim > > on the same grid. > > > > - We need to be able to scale core services to meet a spike in use > > from a zillion new sims. > > > > - Licensing issues on the middleware that I don't even want to ever > > have to think about. (Thank you, Rob and Liana!!!) > > > > That said, it's probably silly to treat open sourcing the sim as an > > all-or-nothing affair. If there are specific pieces of the sim you'd > > like to see, I can lobby for us to open source select files. > > > > What you can do is to identify any specific bits and, for each, give > > me strong justification I can arm myself with. The stronger and more > > concise, the better. I'd have to convince folks (including myself if > > I'm putting my name to the effort!) that the benefits outweigh the > > costs. Between legal, developer time, and security auditing, this > > isn't free. Good will on sldev is worth a lot - but so is remaining > > solvent. :) > > > > > > > > On 6/24/07, Able Whitman wrote: > > > Right, having the source in order to build a working simulator only > makes > > > sense if you can also build the pieces of the SL service that the sim > > > depends on. > > > > > > But even without a decoupled architecture, the server source has a great > > > deal of value today: It would tell us how the sim works and interacts > with > > > the viewer, in much more complete detail than what we can infer from the > > > viewer source. > > > > > > Just having a copy of the server source for examination would be > extremely > > > useful. Either that, or a set of detailed, up-to-date design specs. In > my > > > experience, though, "up-to-date" and "design specs" are mutually > exclusive > > > concepts. So I would prefer the source. :) > > > > > > > > > On 6/24/07, Adam Frisby wrote: > > > > **Speculation**: > > > > I believe LL is targetting sometime next year for the official > > > server > > > > release. As far as I am aware, LL still has a long way to go towards a > > > > distributed central architecture before that is a possibility, > although > > > > they certainly appear to be moving in that direction fairly quickly. > > > > > > > > Adam > > > > > > > > Able Whitman wrote: > > > > > > > > > Laurent reminded me of a post I meant to make after triage, but > forgot > > > > > about in my absentmindedness... > > > > > > > > > > It would be nice to know more about the plans to release the sim > source. > > > > > At the last bug triage, Rob mentioned that it was a "long topic for > > > > > another time". I'm not really asking for every last detail, just > some > > > > > information on where things stand, and where they're going. > > > > > > > > > > Is there a timetable for releasing the server code? Are there > blocking > > > > > issues that are confounding the process? At his town hall, Cory > talked > > > > > about the next generation of SL (I'm not sure if "SL 2.0" was his > term > > > > > or not). Will we see a server source release before "SL 2.0"? > > > > > > > > > > I'm just askin' :) > > > > > > > > > > --Able > > > > > > > > > > On 6/24/07, *Laurent Laborde* > > > > > wrote: > > > > > > > > > > On 6/25/07, Soft Linden > > > > > wrote: > > > > > > Are there one or two things that frustrate you the most, > > > > > > which we could make part of our third quarter goals? > > > > > > > > > > The server side performance and bug we can't patch because it's > > > > > closed source. > > > > > (and being syadmin, i'm sure i could help with server > performance) > > > > > > > > > > ::smile:: > > > > > > > > > > -- > > > > > kerunix Flan > > > > > _______________________________________________ > > > > > Click here to unsubscribe or manage your list subscription: > > > > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > _______________________________________________ > > > > > Click here to unsubscribe or manage your list subscription: > > > > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > -- > > 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 From soft at lindenlab.com Mon Jun 25 20:20:58 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jun 25 20:21:00 2007 Subject: [sldev] Opening the server source? In-Reply-To: <9e6e5c9e0706252017o55e72e50q847c5335506834dc@mail.gmail.com> References: <7b3a84fb0706241916r14255bd8gdc297a5b3fda11dd@mail.gmail.com> <467F26BE.6090409@gwala.net> <7b3a84fb0706242023h5e48aa7ybda6e9349a768023@mail.gmail.com> <9e6e5c9e0706251014m5b189ffq531a4cd7ea4684f0@mail.gmail.com> <23bbb49e0706251020j152f324fifda2e7ee150f4399@mail.gmail.com> <9e6e5c9e0706252017o55e72e50q847c5335506834dc@mail.gmail.com> Message-ID: <9e6e5c9e0706252020l41d77f39hade4d8ed7ee788f3@mail.gmail.com> I really need to proofread before sending, not after. Ambiguity cured in 3rd sentence: Kelly said it pretty well. Someone else creating the backend services is a concern. Once sim source is in hand, a rival grid is an exciting project if there's currently no other way to use the sim source. If we release *after* we're ready to take on third-party sims, rival grids might be about as exciting a project as those third-party alternative DNS networks. They're good to have around, but hopefully they're just there to keep us honest and playing nicely as we try to be the mainstream grid. Again though - 1) That's all speculation on my part, not some insight into a great master plan. Those discussions happen outside my corner of LL! 2) If you can point to specific modules of the sim that you'd like to see and can help me with an argument for getting them open sooner, I'm all ears. I'm all for anything that pushes SL forward, and the lot of ya are pretty well aligned with that goal. :) > On 6/25/07, Tao Takashi wrote: > > forgot to CC the list of course.. ;-) here my reply to Soft.. > > > > Hi! > > > > Just to get this clear: Is releasing the server as open source and opening > > up the grid to plugin third-party servers one project? > > I'd think that as long as you don't open up the grid but only release the > > source code you wouldn't have to worry about lost revenue? > > (as long as nobody creates the backend services themselves and creates > > another (separate) grid). > > > > Of course I can imagine that opening up the grid is a somewhat difficult > > task to do from all points of view. > > > > -- Tao > > > > > > > > 2007/6/25, Soft Linden : > > > We're certainly a ways off from being in a position where opening the > > > sim source fully would make sense. I haven't been in on these > > > discussions, but as an outsider to those discussions, I can anticipate > > > that LL wouldn't want to do this until a few things happen: > > > > > > - We need to be in a position to profit from the growth that comes > > > with third-party sim hosting - at least enough to replace lost revenue > > > from our own sim hosting. > > > > > > - We need to be in a position to run a variety of versions of the sim > > > on the same grid. > > > > > > - We need to be able to scale core services to meet a spike in use > > > from a zillion new sims. > > > > > > - Licensing issues on the middleware that I don't even want to ever > > > have to think about. (Thank you, Rob and Liana!!!) > > > > > > That said, it's probably silly to treat open sourcing the sim as an > > > all-or-nothing affair. If there are specific pieces of the sim you'd > > > like to see, I can lobby for us to open source select files. > > > > > > What you can do is to identify any specific bits and, for each, give > > > me strong justification I can arm myself with. The stronger and more > > > concise, the better. I'd have to convince folks (including myself if > > > I'm putting my name to the effort!) that the benefits outweigh the > > > costs. Between legal, developer time, and security auditing, this > > > isn't free. Good will on sldev is worth a lot - but so is remaining > > > solvent. :) > > > > > > > > > > > > On 6/24/07, Able Whitman wrote: > > > > Right, having the source in order to build a working simulator only > > makes > > > > sense if you can also build the pieces of the SL service that the sim > > > > depends on. > > > > > > > > But even without a decoupled architecture, the server source has a great > > > > deal of value today: It would tell us how the sim works and interacts > > with > > > > the viewer, in much more complete detail than what we can infer from the > > > > viewer source. > > > > > > > > Just having a copy of the server source for examination would be > > extremely > > > > useful. Either that, or a set of detailed, up-to-date design specs. In > > my > > > > experience, though, "up-to-date" and "design specs" are mutually > > exclusive > > > > concepts. So I would prefer the source. :) > > > > > > > > > > > > On 6/24/07, Adam Frisby wrote: > > > > > **Speculation**: > > > > > I believe LL is targetting sometime next year for the official > > > > server > > > > > release. As far as I am aware, LL still has a long way to go towards a > > > > > distributed central architecture before that is a possibility, > > although > > > > > they certainly appear to be moving in that direction fairly quickly. > > > > > > > > > > Adam > > > > > > > > > > Able Whitman wrote: > > > > > > > > > > > Laurent reminded me of a post I meant to make after triage, but > > forgot > > > > > > about in my absentmindedness... > > > > > > > > > > > > It would be nice to know more about the plans to release the sim > > source. > > > > > > At the last bug triage, Rob mentioned that it was a "long topic for > > > > > > another time". I'm not really asking for every last detail, just > > some > > > > > > information on where things stand, and where they're going. > > > > > > > > > > > > Is there a timetable for releasing the server code? Are there > > blocking > > > > > > issues that are confounding the process? At his town hall, Cory > > talked > > > > > > about the next generation of SL (I'm not sure if "SL 2.0" was his > > term > > > > > > or not). Will we see a server source release before "SL 2.0"? > > > > > > > > > > > > I'm just askin' :) > > > > > > > > > > > > --Able > > > > > > > > > > > > On 6/24/07, *Laurent Laborde* > > > > > > wrote: > > > > > > > > > > > > On 6/25/07, Soft Linden > > > > > > wrote: > > > > > > > Are there one or two things that frustrate you the most, > > > > > > > which we could make part of our third quarter goals? > > > > > > > > > > > > The server side performance and bug we can't patch because it's > > > > > > closed source. > > > > > > (and being syadmin, i'm sure i could help with server > > performance) > > > > > > > > > > > > ::smile:: > > > > > > > > > > > > -- > > > > > > kerunix Flan > > > > > > _______________________________________________ > > > > > > Click here to unsubscribe or manage your list subscription: > > > > > > > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > _______________________________________________ > > > > > > Click here to unsubscribe or manage your list subscription: > > > > > > > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Click here to unsubscribe or manage your list subscription: > > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > _______________________________________________ > > > Click here to unsubscribe or manage your list subscription: > > > > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > > > > > > -- > > > > 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 > From agrimes at speakeasy.net Mon Jun 25 21:31:16 2007 From: agrimes at speakeasy.net (Alan Grimes) Date: Mon Jun 25 20:31:13 2007 Subject: [sldev] missing file? Message-ID: <46809694.2070205@speakeasy.net> I've been wrestling with the SVN source, reverting all my changes just to get it to run again... New release came down the pipe but it seems to be missing some files.... SL/release/indra/i686-linux-client-release/llimage/llimagepng.cpp' not found, needed by targe =( -- Opera: Sing it loud! :o( )>-< From soft at lindenlab.com Mon Jun 25 20:48:25 2007 From: soft at lindenlab.com (Soft Linden) Date: Mon Jun 25 20:48:27 2007 Subject: [sldev] Source release for 1.17.1.0 In-Reply-To: <46805879.8060505@blueflash.cc> References: <468056EC.4000303@lindenlab.com> <46805879.8060505@blueflash.cc> Message-ID: <9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> On 6/25/07, Nicholaz Beresford wrote: > Anthony Foster wrote: > > Hello everyone, > > > > This is an optional viewer. > > > > 1.17.1.0 source release available here: > > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.1.0 > > Oh dang ... it's 2AM here ... there goes another night's sleep :-) Anthony does this just to be mean, ya know... From labrat.hb at gmail.com Mon Jun 25 21:09:13 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Mon Jun 25 21:09:14 2007 Subject: [sldev] Source release for 1.17.1.0 In-Reply-To: <9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> References: <468056EC.4000303@lindenlab.com> <46805879.8060505@blueflash.cc> <9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> Message-ID: And don't forget kids..... we're supposed to do this all over again on Wednesday On 6/25/07, Soft Linden wrote: > > On 6/25/07, Nicholaz Beresford wrote: > > Anthony Foster wrote: > > > Hello everyone, > > > > > > This is an optional viewer. > > > > > > 1.17.1.0 source release available here: > > > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.1.0 > > > > Oh dang ... it's 2AM here ... there goes another night's sleep :-) > > Anthony does this just to be mean, ya know... > _______________________________________________ > 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/20070625/b066aac9/attachment.htm From seg at haxxed.com Mon Jun 25 21:59:51 2007 From: seg at haxxed.com (Callum Lerwick) Date: Mon Jun 25 21:59:11 2007 Subject: [sldev] OpenAL patch updated Message-ID: <1182833992.6378.21.camel@localhost> Alright, I finally got a chance to sit down and do some debugging on my wife's x86_64 laptop. Turns out the crashyness was caused by not having stub implementations of all the audio streaming calls, which only affected x86_64 for some reason. There's still a bit of crashyness, which I just realized is probably because I need to make stubs for the wind noise calls too. Turning the wind volume slider all the way down seems to avoid it. I managed to fix the problems with doppler. Near as I can tell the sense of scale in SL is just plain off, so I scale the doppler factor down by a factor of 100 (!) which brings it down to a reasonable level. I tried scaling the speed of sound up instead, but that caused overflows inside OpenAL... I haven't bothered doing any comparison with fmod so I don't know how this matches up with what fmod is doing. http://www.haxxed.com/code/slviewer-1.17.0.12-openal-20070625.patch And also now included in my Fedora package, just in time to be out of date: http://www.haxxed.com/rpms/secondlife/ Next step: Music streaming! -------------- 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/20070625/e8529a64/attachment-0001.pgp From hawk.carter at unix-dev.de Mon Jun 25 22:26:03 2007 From: hawk.carter at unix-dev.de (Hawk) Date: Mon Jun 25 22:26:23 2007 Subject: [sldev] Source release for 1.17.1.0 References: <468056EC.4000303@lindenlab.com> <46805879.8060505@blueflash.cc><9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> Message-ID: <001701c7b7b2$7d467660$0301a8c0@main1> lalala i dont say anything : ------ Build started: Project: llimage, Configuration: Release Win32 ------ llpngwrapper.cpp c1xx : fatal error C1083: Cannot open source file: '.\llpngwrapper.cpp': No such file or directory llimagepng.cpp c1xx : fatal error C1083: Cannot open source file: '.\llimagepng.cpp': No such file or directory Greetings Hawk Carter From able.whitman at gmail.com Tue Jun 26 00:49:06 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jun 26 00:49:09 2007 Subject: [sldev] Accessing SL viewer crash reports? Message-ID: <7b3a84fb0706260049v742fea19m7c6423921c642b01@mail.gmail.com> I have a couple of friends who have been experiencing regular crashes with the 1.17.1.0 viewer release. This led me to wonder: Are there any plans to make information from viewer crash reports accessible to open source contributors? The crash call stacks in the wiki ( https://wiki.secondlife.com/wiki/Crash_Reports) are somewhat helpful, but are these top 10 lists still up-to-date? Some additional statistics about the frequency of the different crashes would also be useful, as well as more details about which environments (OS, video card, driver version, etc.) encounter which crashes most often. And, at least in the case of investigating crashes on a Windows system, minidump files would be tremendously useful. Of course, there are are privacy concerns around having access to crash dumps which may contain personally identifiable information, so it's understandable if full minidumps aren't available. (I haven't looked at the crash reporter source very closely, so I'm not entirely familiar with what all information it sends to LL in the event of a viewer crash, anyhow.) But the more information we have, the better our chances are of determining the root cause for a particular crash. Cheers, --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070626/7cbcf6fa/attachment.htm From nicholaz at blueflash.cc Tue Jun 26 01:31:57 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 01:32:09 2007 Subject: [sldev] Source release for 1.17.1.0 In-Reply-To: <001701c7b7b2$7d467660$0301a8c0@main1> References: <468056EC.4000303@lindenlab.com> <46805879.8060505@blueflash.cc><9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> <001701c7b7b2$7d467660$0301a8c0@main1> Message-ID: <4680CEFD.4080302@blueflash.cc> Have not checked yet, but you might find them here: https://jira.secondlife.com/browse/VWR-79 Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Hawk wrote: > lalala i dont say anything : > > ------ Build started: Project: llimage, Configuration: Release Win32 ------ > llpngwrapper.cpp > c1xx : fatal error C1083: Cannot open source file: '.\llpngwrapper.cpp': > No such file or directory > llimagepng.cpp > c1xx : fatal error C1083: Cannot open source file: '.\llimagepng.cpp': > No such file or directory > > > > Greetings > > Hawk Carter > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Tue Jun 26 01:32:56 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 01:33:07 2007 Subject: [sldev] Source release for 1.17.1.0 In-Reply-To: <9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> References: <468056EC.4000303@lindenlab.com> <46805879.8060505@blueflash.cc> <9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> Message-ID: <4680CF38.3080708@blueflash.cc> Soft Linden wrote: > On 6/25/07, Nicholaz Beresford wrote: >> Anthony Foster wrote: >> > This is an optional viewer. >> > >> > 1.17.1.0 source release available here: >> > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.1.0 >> >> Oh dang ... it's 2AM here ... there goes another night's sleep :-) > > Anthony does this just to be mean, ya know... I thought so, thanks for confirming my suspicion LOL :-) Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Tue Jun 26 01:57:42 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 01:57:54 2007 Subject: [sldev] Source release for 1.17.1.0 In-Reply-To: References: <468056EC.4000303@lindenlab.com> <46805879.8060505@blueflash.cc> <9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> Message-ID: <4680D506.2060408@blueflash.cc> It's rather painless here already, I used to have a perl script that does most of the work, just seem to have lost that and had to rewrite it yesterday night, so Wednesday will be easier :-) Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Harold Brown wrote: > And don't forget kids..... we're supposed to do this all over again on > Wednesday > > On 6/25/07, *Soft Linden* > wrote: > > On 6/25/07, Nicholaz Beresford > wrote: > > Anthony Foster wrote: > > > Hello everyone, > > > > > > This is an optional viewer. > > > > > > 1.17.1.0 source release available here: > > > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.1.0 > > > > Oh dang ... it's 2AM here ... there goes another night's sleep :-) > > Anthony does this just to be mean, ya know... > _______________________________________________ > 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 Tue Jun 26 03:36:52 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Tue Jun 26 03:36:53 2007 Subject: [sldev] Opening the server source? Message-ID: > Kelly said it pretty well. Someone else creating the backend services > is a concern. Once sim source is in hand, a rival grid is an exciting > project if there's currently no other way to use the sim source. If we > release *after* we're ready to take on third-party sims, rival grids > might be about as exciting a project as those third-party alternative > DNS networks. They're good to have around, but hopefully they're just > there to keep us honest and playing nicely as we try to be the > mainstream grid. Actually I think there are some other issues than just third party sims that LL would need to address to mitigate the risk of loosing residents to a competitor who had recreated the backend servers and were running their own grid. If someone did offer a alternative grid with a backend asset server architecture which supported user backups without breaking the permissions systems (using for instance some of the ideas in jira), managed to address some of the scalabilitty/performance issues, offered 24/7 support with minimal waiting queues, and offered an import mechanism of full permission scripts/prims between LL grid and their grid, I think they would give LL a run for their money at the moment. On the other hand, OpenSim is moving slowly but steadily some I think this scenario is a matter of when rather than if, so it will be interesting to see how LL can transition from running the SL Grid to the SL Grid equivalent of ICANN... Matthew _________________________________________________________________ Celeb spotting ? Play CelebMashup and win cool prizes https://www.celebmashup.com/index2.html From blakar at gmail.com Tue Jun 26 03:56:37 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Jun 26 03:56:41 2007 Subject: [sldev] Opening the server source? In-Reply-To: References: Message-ID: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> That's a rather big "if". Any new startup will seemingly have this because they don't need scalability or performance. If LL would start anew with their current knowledge they could run a grid for 1/10th the people without hassle too. The question is who would be able to run a full alternative at the same size without failing? Obviously the answer to that bubbles up while writing the question: any company that has a different setup that faces the same challenges. Which brings us to the like of Google. Though at that point the issue changes again. What benefit would Google and alike have to try and compete with LL? They could just buy and expand which would be tons cheaper than starting anew. Tuning services with a size as big as this is hard to do by open sourcing some code. There are a lot of things that come into play which you simply can't test just playing with code. To better the grid LL is, for now, best off hiring more experts. Dirk aka Blakar Ogre On 6/26/07, Matthew Dowd wrote: > >If someone did offer a alternative grid with a backend asset server architecture which supported user backups without breaking the permissions systems (using for instance some of the ideas in jira), managed to address some of the scalabilitty/performance issues, offered 24/7 support with minimal waiting queues, and offered an import mechanism of full permission scripts/prims between LL grid and their grid, I think they would give LL a run for their money at the moment. From tao.takashi at googlemail.com Tue Jun 26 04:04:43 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Jun 26 04:04:45 2007 Subject: [sldev] Opening the server source? In-Reply-To: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> Message-ID: <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> It's all a question of the license to attach to the source code. If it's not open source for a start you don't need to fear competitors. Of course they can learn from that source but still would need to reimplement all of it. Google, I think, is probably already going their own path internally which is most likely Google Earth based. Anyway, I guess there is not too much advantage anyway to having the source if you cannot run it and it would add a bit of work on LL's side to open it up sooner (which is maybe spent better otherwise). So maybe some better explanations of how things work would be good for a start (but honestly I haven't checked what is around I just know some details at least from Zero's office hours. Then again I guess it could always be more ;-) ). -- Tao -- 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/20070626/c36445ec/attachment.htm From nicholaz at blueflash.cc Tue Jun 26 04:45:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 04:45:29 2007 Subject: [sldev] Opening the server source? In-Reply-To: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> Message-ID: <4680FC52.1080400@blueflash.cc> Dirk Moerenhout wrote: > has a different setup that faces the same challenges. Which brings us > to the like of Google. Though at that point the issue changes again. > What benefit would Google and alike have to try and compete with LL? > They could just buy and expand which would be tons cheaper than > starting anew. I've been thinking about Google a couple of times, because they certainly has the back end firepower and database knowledge Nick From nicholaz at blueflash.cc Tue Jun 26 04:50:24 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 04:50:34 2007 Subject: [sldev] Accessing SL viewer crash reports? In-Reply-To: <7b3a84fb0706260049v742fea19m7c6423921c642b01@mail.gmail.com> References: <7b3a84fb0706260049v742fea19m7c6423921c642b01@mail.gmail.com> Message-ID: <4680FD80.2090709@blueflash.cc> I have some experiences with the crashes from my viewer (some of my users are sending crash reports to me). The bare bones reports which LL gets, with certainty of 99% don't have any user relevant information in them, because they just contain the stack and registers but no parts of the heap. But most of the time I'm seeing them this isn't sufficient to get a good picture of the error, although occasionally it does (I have found two possible crashes this way). With the rest, even the Minidumps are mostly not too helpful, except seeing that some pointers go into the wild. I've been looking at almost 100 of those over time, but these also don't even come close to being able to crash in the debugger (even just one time). Nick Able Whitman wrote: > I have a couple of friends who have been experiencing regular crashes > with the 1.17.1.0 viewer release. This led me to > wonder: Are there any plans to make information from viewer crash > reports accessible to open source contributors? > > The crash call stacks in the wiki > (https://wiki.secondlife.com/wiki/Crash_Reports) are somewhat helpful, > but are these top 10 lists still up-to-date? Some additional statistics > about the frequency of the different crashes would also be useful, as > well as more details about which environments (OS, video card, driver > version, etc.) encounter which crashes most often. And, at least in the > case of investigating crashes on a Windows system, minidump files would > be tremendously useful. > > Of course, there are are privacy concerns around having access to crash > dumps which may contain personally identifiable information, so it's > understandable if full minidumps aren't available. (I haven't looked at > the crash reporter source very closely, so I'm not entirely familiar > with what all information it sends to LL in the event of a viewer crash, > anyhow.) But the more information we have, the better our chances are of > determining the root cause for a particular crash. > > > Cheers, > --Able > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From chance at kalacia.com Tue Jun 26 04:56:24 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jun 26 04:56:26 2007 Subject: [sldev] Source release for 1.17.1.0 In-Reply-To: <4680D506.2060408@blueflash.cc> References: <468056EC.4000303@lindenlab.com> <46805879.8060505@blueflash.cc> <9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> <4680D506.2060408@blueflash.cc> Message-ID: <2925011a0706260456h1f6c288eh5becfa7c286e4ed9@mail.gmail.com> Ok, the new downladable viewer has got some serious jitter issues with on screen display. Is this a universal issue, or specific to particular hardware configurations. Access to crash statistics demographics without access to individual records would be a plus..... Oh wait, I havent crashed yet. Oh well, nm. Stability is pretty good. Rendering issues remain. On 6/26/07, Nicholaz Beresford wrote: > > > It's rather painless here already, I used to have > a perl script that does most of the work, just > seem to have lost that and had to rewrite it yesterday > night, so Wednesday will be easier :-) > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Harold Brown wrote: > > And don't forget kids..... we're supposed to do this all over again on > > Wednesday > > > > On 6/25/07, *Soft Linden* > > wrote: > > > > On 6/25/07, Nicholaz Beresford > > wrote: > > > Anthony Foster wrote: > > > > Hello everyone, > > > > > > > > This is an optional viewer. > > > > > > > > 1.17.1.0 source release available here: > > > > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.1.0 > > > > > > Oh dang ... it's 2AM here ... there goes another night's sleep > :-) > > > > Anthony does this just to be mean, ya know... > > _______________________________________________ > > 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/20070626/a55fd197/attachment.htm From chance at kalacia.com Tue Jun 26 05:03:58 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jun 26 05:04:00 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4680FC52.1080400@blueflash.cc> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> Message-ID: <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> I seriously doubt you could convince Google where the profit lies in porting a search engine into a game. They arent about good will, they are about profit. Putting on a Linden Hat : Why would I open source that item that is generating me lots of cash? I know that my cash cow island owners would be flirting with another hosting company if I did that. So open source my sim software??? mmmmmmm nah. On 6/26/07, Nicholaz Beresford wrote: > > > > Dirk Moerenhout wrote: > > has a different setup that faces the same challenges. Which brings us > > to the like of Google. Though at that point the issue changes again. > > What benefit would Google and alike have to try and compete with LL? > > They could just buy and expand which would be tons cheaper than > > starting anew. > > I've been thinking about Google a couple of times, because they > certainly has the back end firepower and database knowledge > > > Nick > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070626/c1b66a78/attachment.htm From nicholaz at blueflash.cc Tue Jun 26 05:04:05 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 05:04:14 2007 Subject: [sldev] Source release for 1.17.1.0 In-Reply-To: <2925011a0706260456h1f6c288eh5becfa7c286e4ed9@mail.gmail.com> References: <468056EC.4000303@lindenlab.com> <46805879.8060505@blueflash.cc> <9e6e5c9e0706252048q64c05e7dia7f0ac88f35b9518@mail.gmail.com> <4680D506.2060408@blueflash.cc> <2925011a0706260456h1f6c288eh5becfa7c286e4ed9@mail.gmail.com> Message-ID: <468100B5.6000007@blueflash.cc> Chance Unknown wrote: > Ok, the new downladable viewer has got some serious jitter issues with > on screen display. Is this a universal issue, or specific to particular > hardware configurations. Access to crash statistics demographics without > access to individual records would be a plus..... > > Oh wait, I havent crashed yet. Oh well, nm. Stability is pretty good. > Rendering issues remain. I have not built the 1.17.1 yet, so I don't know. But the SL blog says that editing seems to crash (maybe viewer yesterday being out of sync with the grid before the rolling restart today) and one user told me on my blog that memory was still growing while my viewer didn't. Looks like fun ... :-) Nick From chance at kalacia.com Tue Jun 26 05:11:15 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jun 26 05:11:18 2007 Subject: [sldev] Cross compiling the viewer In-Reply-To: <7b3a84fb0706251857t683d6d41w6824e61e03b1ffaf@mail.gmail.com> References: <7b3a84fb0706251857t683d6d41w6824e61e03b1ffaf@mail.gmail.com> Message-ID: <2925011a0706260511t6a1b7755o9405d4e178e04123@mail.gmail.com> Honestly, I dont think key library elements for MacOSX can be ported to a Windows environment for a true cross compilation environment due to Apple license restrictions. However having said that.. there are projects on linux that exist that allow you to build MacOSX binaries... So there are not technical reasons to keep it from happening. For instance: http://ranger.befunk.com/fink/darwin-cross/ On 6/25/07, Able Whitman wrote: > > I have limited cross-compiling experience, so pardon me if this is a dumb > question: Is it possible to cross compile a Mac viewer binary on a Windows > system? > > > _______________________________________________ > 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/20070626/ee42d3f1/attachment.htm From nicholaz at blueflash.cc Tue Jun 26 05:17:13 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 05:17:21 2007 Subject: [sldev] Opening the server source? In-Reply-To: <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> Message-ID: <468103C9.1000407@blueflash.cc> Chance Unknown wrote: > I seriously doubt you could convince Google where the profit lies in > porting a search engine into a game. They arent about good will, they > are about profit. My idea was more along the lines that if they provided the back end service (assets) for distributed sims, they would have the knowledge and expertise and hardware and deep enough pockets to do it. Nick From chance at kalacia.com Tue Jun 26 05:31:59 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jun 26 05:32:01 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468103C9.1000407@blueflash.cc> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468103C9.1000407@blueflash.cc> Message-ID: <2925011a0706260531v349d8b6clbd697e6c51e02cf5@mail.gmail.com> This could be explored now by using the Google Base API in the viewer. Inventory backup maybe? Get enough of player inventories backed up into their Google Base account and maybe a special mapping layer of UUID to Google Base location, and we can play when the asset servers are down? On 6/26/07, Nicholaz Beresford wrote: > > > > Chance Unknown wrote: > > I seriously doubt you could convince Google where the profit lies in > > porting a search engine into a game. They arent about good will, they > > are about profit. > > My idea was more along the lines that if they provided the back end > service (assets) for distributed sims, they would have the knowledge > and expertise and hardware and deep enough pockets to do it. > > > Nick > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070626/e8312fc2/attachment-0001.htm From nicholaz at blueflash.cc Tue Jun 26 06:10:02 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 06:10:15 2007 Subject: [sldev] 1.17.1 problem / Crash on Edit Message-ID: <4681102A.4090003@blueflash.cc> Still am not running 1.17.1 but if someone wants to try to reproduce something, here's something I just received from a user. This seems to be in line what I read on the Linden blog. Original message (German :-)): "detaillierter: wenn man ein objekt rezzed und zum editieren ?ffnet - skript austauscht - wieder take ins inv - wieder rezzen und wieder edit -> crash" Translation: "if an object is rezzed and opened for editing - replace script - take back to inventory - rezz again and again edit -> crash" Nick From nicholaz at blueflash.cc Tue Jun 26 06:40:12 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 06:40:23 2007 Subject: [sldev] 1.17.1 problem / Crash on Edit In-Reply-To: <4681102A.4090003@blueflash.cc> References: <4681102A.4090003@blueflash.cc> Message-ID: <4681173C.5090707@blueflash.cc> https://jira.secondlife.com/browse/VWR-1369 Nick Nicholaz Beresford wrote: > > Still am not running 1.17.1 but if someone wants to try to reproduce > something, here's something I just received from a user. This seems > to be in line what I read on the Linden blog. > > > Original message (German :-)): > "detaillierter: wenn man ein objekt rezzed und zum editieren ?ffnet - > skript austauscht - wieder take ins inv - wieder rezzen und wieder edit > -> crash" > > Translation: > "if an object is rezzed and opened for editing - replace script - take > back to inventory - rezz again and again edit -> crash" > > > > > Nick > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From kelly at lindenlab.com Tue Jun 26 08:01:24 2007 From: kelly at lindenlab.com (kelly@lindenlab.com) Date: Tue Jun 26 08:01:26 2007 Subject: [sldev] Opening the server source? In-Reply-To: <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> Message-ID: <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> > > Anyway, I guess there is not too much advantage anyway to having > the source if you cannot run it and it would add a bit of work on LL's > side to open it up sooner (which is maybe spent better otherwise). > So maybe some better explanations of how things work would be > good for a start (but honestly I haven't checked what is around I just > know some details at least from Zero's office hours. Then again I guess > it could always be more ;-) ). > > -- Tao > I would be glad to explain how things work. I think we have a system overview somewhere on the wiki already, but if we don't I could create it. If there is a more specific question (or set of questions) I would be happy to answer them. I was going to suggest just emailing me, but perhaps a wiki page / FAQ would be better. If anyone wants to set one up and populate it with a couple questions I can see about answering them. Questions I am imagining are like "what happens when this message is sent to the sim?" or "what specifically causes this message to be sent to the viewer?" or "why does this happen?". To be clear, I may not be able to answer all questions but Soft and I should be able to find those who can. From jef at pleiades.ca Tue Jun 26 08:26:10 2007 From: jef at pleiades.ca (Jonathan Freedman) Date: Tue Jun 26 08:26:15 2007 Subject: [sldev] Opening the server source? In-Reply-To: <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> Message-ID: <46813012.1050606@pleiades.ca> On that note, what ever happened to your office hours Kelly ? Jonathan Freedman / otakup0pe Neumann > I would be glad to explain how things work. I think we have a system > overview somewhere on the wiki already, but if we don't I could create it. > If there is a more specific question (or set of questions) I would be > happy to answer them. I was going to suggest just emailing me, but > perhaps a wiki page / FAQ would be better. If anyone wants to set one up > and populate it with a couple questions I can see about answering them. > > Questions I am imagining are like "what happens when this message is sent > to the sim?" or "what specifically causes this message to be sent to the > viewer?" or "why does this happen?". To be clear, I may not be able to > answer all questions but Soft and I should be able to find those who can. > > From tao.takashi at googlemail.com Tue Jun 26 08:33:48 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Tue Jun 26 08:33:51 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46813012.1050606@pleiades.ca> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> <46813012.1050606@pleiades.ca> Message-ID: <23bbb49e0706260833x794599c4p6b3bace5c6897439@mail.gmail.com> 2007/6/26, Jonathan Freedman : > > On that note, what ever happened to your office hours Kelly ? Right, yesterday I was waiting there for an hour... -- Tao -- 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/20070626/eaab0238/attachment.htm From kelly at lindenlab.com Tue Jun 26 08:52:31 2007 From: kelly at lindenlab.com (Kelly Washington) Date: Tue Jun 26 08:52:35 2007 Subject: [sldev] Opening the server source? In-Reply-To: <23bbb49e0706260833x794599c4p6b3bace5c6897439@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> <46813012.1050606@pleiades.ca> <23bbb49e0706260833x794599c4p6b3bace5c6897439@mail.gmail.com> Message-ID: <4681363F.50300@lindenlab.com> Tao Takashi wrote: > > > 2007/6/26, Jonathan Freedman >: > > On that note, what ever happened to your office hours Kelly ? > > > > Right, yesterday I was waiting there for an hour... > > -- Tao > > Um... Well, I did 4 office hours as an experiment and I didn't feel they were a particularly good use of time. Mostly my fault in that I was never organized, never had a good topic. I think Zero's office hours are far better and I may sit in on one or two of those again in the future. I thought I had removed all references to those office hours but guess I missed the wiki page. :( Sorry! - Kelly -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070626/a6f35b19/attachment.htm From mxalpha at gmail.com Tue Jun 26 09:20:26 2007 From: mxalpha at gmail.com (Gregory Peaker) Date: Tue Jun 26 09:20:55 2007 Subject: [sldev] New to SL Development Message-ID: <000001c7b80d$eb99f690$c2cde3b0$@com> Hi All, My name is Greg and I am new to SL development. I have been looking at the Second Life Wiki Development the past few days, and I want to know if anyone has a source copy with all the necessary files. For instance, a copy with Boost, Expat, Zlib, and etc. copied. I am very interested in participating in this open source development; however, does anyone have a copy of the application that, effectively, compiles out-of-the-box? Thanks, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070626/d412a292/attachment.htm From synthalor.mandelbrot at inbox.com Tue Jun 26 09:47:51 2007 From: synthalor.mandelbrot at inbox.com (Synthalor Mandelbrot) Date: Tue Jun 26 09:48:15 2007 Subject: [sldev] SLDev-Traffic #17 - Now with 100% more Seventeen(tm) In-Reply-To: <9e6e5c9e0706241810m2b0ba69cj45a1c6c30bcb4b5a@mail.gmail.com> Message-ID: <5E5D04A0142.000002C6synthalor.mandelbrot@inbox.com> > https://wiki.secondlife.com/wiki/SLDev-Traffic_17 > Soft, I want to personally thank you and whoever may be helping you for taking the time to create these summaries. I find these to be highly valuable. While I do try to keep up with the list chatter, to have someone thoughtfully extract the essentials, identify the key themes, and highlight the key points of the discussion is immensely helpful. You rock! Synthalor Mandelbrot From dzonatas at dzonux.net Tue Jun 26 10:07:17 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 26 10:07:17 2007 Subject: [sldev] 1.17.1 crashes Message-ID: <468147C5.1000800@dzonux.net> The crashes happen mostly when I click Edit or Create from the Pie Menu. They are random. These were fixed at one point way back in 1.13 or 1.14... did the fix get undone? =( -- Power to Change the Void From kelly at lindenlab.com Tue Jun 26 10:26:12 2007 From: kelly at lindenlab.com (Kelly Washington) Date: Tue Jun 26 10:26:15 2007 Subject: [sldev] 1.17.1 crashes In-Reply-To: <468147C5.1000800@dzonux.net> References: <468147C5.1000800@dzonux.net> Message-ID: <46814C34.90401@lindenlab.com> Dzonatas wrote: > The crashes happen mostly when I click Edit or Create from the Pie Menu. > > They are random. > > These were fixed at one point way back in 1.13 or 1.14... did the fix > get undone? > > =( I looked into this a bit this morning. It is not an old bug come back. Looks like probably classic double delete badness with interaction between our horrible LLLinkedList class and some changes to move things to LLPointer (our reference counting pointer implementation). Brian has taken this on since it looks related to code he has recently worked on. If anyone submits a patch that removes ALL uses of LLLinkedList (or any other home-brewed container class in our code) in favor of a std:: equivelant I will personally work to get it into the release code as fast as possible. This is a non-trivial task though. - Kelly From secret.argent at gmail.com Tue Jun 26 10:29:10 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Jun 26 10:29:15 2007 Subject: [sldev] Re: SLDev Digest, Vol 6, Issue 100 In-Reply-To: <20070626114530.2F69441AF29@stupor.lindenlab.com> References: <20070626114530.2F69441AF29@stupor.lindenlab.com> Message-ID: <048B9A7B-2068-48C7-8674-A4D0F85A59C0@gmail.com> A Google Earth based VR would be... interesting. Especially with their new street-level service. From nicholaz at blueflash.cc Tue Jun 26 11:16:51 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 11:17:04 2007 Subject: [sldev] building 1.17.1 on Windows Message-ID: <46815813.6080004@blueflash.cc> It appears there are a couple of files missing around the PNG stuff (sources and library includes). I just stitched together an archive with the missing files and put it on http://www.blueflash.cc/users/nicholaz/libs I didn't try a full compile yet (it's just running but I'll have to leave in a minute (does anyone have a spare quad-core server park for complilation for me?)), but it should be a step towards compilability. As said, it's been a quick one, no guarantees. Notes: The ZIP file contains sl sources, png and zlib includes and Windows release/debug binaries for the libpng. Just unpack over the linden source tree. You won't need the .lib files and they have another name (LL uses png12.lib, mine are libpng.lib and libpngd.lib), so there won't be any interference. Under VC8 you need to add the four new source/header files from linden/indra/llimage to the llimage project (two headers, two source) Also, the libs (lpng1218) were compiled with VC71 so I don't know if they are compatible with VC8. Nick PS: Compile just ended and started, so it should work (I just used the linden png12.lib). -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From bos at lindenlab.com Tue Jun 26 11:26:12 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Jun 26 11:26:14 2007 Subject: [sldev] 1.17.1 problem / Crash on Edit In-Reply-To: <4681173C.5090707@blueflash.cc> References: <4681102A.4090003@blueflash.cc> <4681173C.5090707@blueflash.cc> Message-ID: <46815A44.3040308@lindenlab.com> Nicholaz Beresford wrote: > https://jira.secondlife.com/browse/VWR-1369 This has been fixed. References: Message-ID: <7765f2c60706261233l3fdafd5pff92b55e9438b0bc@mail.gmail.com> You aren't alone. Happens to me too. ;) A reordering of popping new ones under the old would be a very good improvement. -- RL: Jeroen Frans / SL: Frans Charming http://www.thevesuviusgroup.com http://www.fransinnovations.com http://www.linkedin.com/in/mrfrans http://secondslog.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070626/2c05fd7b/attachment.htm From chance at kalacia.com Tue Jun 26 13:01:59 2007 From: chance at kalacia.com (Chance Unknown) Date: Tue Jun 26 13:02:01 2007 Subject: [sldev] New to SL Development In-Reply-To: <000001c7b80d$eb99f690$c2cde3b0$@com> References: <000001c7b80d$eb99f690$c2cde3b0$@com> Message-ID: <2925011a0706261301v575ed67ck2ef511c28e3123ca@mail.gmail.com> Pretty much you put in the time that it takes as outlined on the wiki to compile the application. If you are efficient, you should only need a couple of hours of setup time to get the environment right. Then you drop in copies of the zip files as also outlined in the wiki -- then go for it. The solution files for VC7 and VC8 are included in there, at that point you should be able to go for it. On 6/26/07, Gregory Peaker wrote: > > Hi All, > > > > My name is Greg and I am new to SL development. I have been looking at the > Second Life Wiki Development the past few days, and I want to know if anyone > has a source copy with all the necessary files. For instance, a copy with > Boost, Expat, Zlib, and etc. copied. > > > > I am very interested in participating in this open source development; > however, does anyone have a copy of the application that, effectively, > compiles out-of-the-box? > > > > Thanks, > > Greg > > _______________________________________________ > 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/20070626/df404311/attachment.htm From dzonatas at dzonux.net Tue Jun 26 13:47:02 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Tue Jun 26 13:47:00 2007 Subject: [sldev] 1.17.1 crashes In-Reply-To: <46814C34.90401@lindenlab.com> References: <468147C5.1000800@dzonux.net> <46814C34.90401@lindenlab.com> Message-ID: <46817B46.4020908@dzonux.net> Kelly Washington wrote: > If anyone submits a patch that removes ALL uses of LLLinkedList (or any > other home-brewed container class in our code) in favor of a std:: > equivelant I will personally work to get it into the release code as > fast as possible. This is a non-trivial task though. > When someone asks one to write a linked list in C++ or C, it is not so trivial for many reasons. I'll just touch on the portable issue and avoid the legal patent issues (and other patent nonsense). One could just write it out in plain C with full implementation and avoid any C++ containers. I'm sure C++ programmers usually bark at this technique. Actually, I know this because C++ programmers tend to watch the clock for how much time it takes to write out the implementation. C++ programmers, instead, would rather see something like std::vector being used. It is quick to implement and probably avoids that jerky head look at the clock. The std::vector (and like) container(s) are not pure linked lists, however. They rely more on dynamic arrays. The benefits of a linked list are lost. The trivial solution is to move the compiler to include the STL library, which is not in use by default. Then one could use the std::list<> template. The STL library also adds the additional benefit of cross platform compatibility. For example, many of the wide character implementations under MSVC's STD library are not portable. The STL library is the answer to make it portable. I'd jump on it, but I have a treasury program of higher priority to write, first. -- Power to Change the Void From qarl at lindenlab.com Tue Jun 26 13:58:37 2007 From: qarl at lindenlab.com (Karl Stiefvater) Date: Tue Jun 26 14:02:46 2007 Subject: [sldev] sculpties announcements Message-ID: <13E03905-55C0-4CE1-8190-FD23E1BDDDBC@lindenlab.com> hey all - i've got a few sculptie announcements, for those who might be interested in such things: 1. Dr. Dobbs will be hosting a daylong sculptie party on their island July 7. I'll be speaking (typing?) in the first panel. There should be lot's of fun sculptie experiments and toys and tools and camaraderie. I'll send more information as it becomes available. 2. I'm drumming-up support for an open-source/community-development project for the sculpties. The basic jist is: you guys rock, if possible we should continue the rockage. Details here: https://wiki.secondlife.com/wiki/Sculptie_Dev I'll also be coming to Rob Linden's office hours this Friday to discuss this and other sculptie fun. 3. I've released a new version of the sculptie exporter - it now makes some effort to reassemble entire maya scenes (and automatically bakes lighting.) Available here (much thanks to Dzonatas for the wiki clean-up.) http://wiki.secondlife.com/wiki/Advanced_Sculptie_Exporter_From_Maya best, K. From sllists at boroon.dasgupta.ch Tue Jun 26 14:08:34 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue Jun 26 14:08:46 2007 Subject: [sldev] Building 1.17.1 on Linux/Unix Message-ID: <54725.83.180.83.164.1182892114.squirrel@datendelphin.net> As building 1.17.1.0 has got some quirks in it, I dedicated to write this down ... Missing Files There are some files missing from the source drop. Get them by unpacking the zip from https://jira.secondlife.com/browse/VWR-79 into the source tree. I didn't apply the patch contained in the zip, but perhaps it's needed for the added functionality of VWR-79, I'm not sure about that. Then apply the patch attached to this message (llimage_fix.patch) to fix capitalization and stuff. Internally fixed bug To avoid https://jira.secondlife.com/browse/VWR-1369, apply llvoinventorylistener.patch (and maybe also linked_lists.patch) from there. Missing Libraries at Runtime If you build a release_for_download, the content of linden/indra/lib_releasefordownload_client/i686-linux/ isn't packaged into linden/indra/newview/SecondLife_i686_1_17_1_0.tar.bz2. So just copy that content into the SecondLife_i686_1_17_1_0/lib/ folder after unpacking. (The proper thing to do would be to fix the SConstruct file, of course.) If anyone feels like working this into PJira and/or the wiki, just do so :-) (Be aware that the Coco called their patche for VWR-1369 a "band aid" and that mine for llimage is probably no better) Hope this helps Boroondas Gupte PS: If anything herein is completely wrong, please correct me ;-) -------------- next part -------------- A non-text attachment was scrubbed... Name: llimage_fix.patch Type: text/x-patch Size: 2088 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070626/78f53d78/llimage_fix.bin From sllists at boroon.dasgupta.ch Tue Jun 26 14:23:46 2007 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Tue Jun 26 14:23:53 2007 Subject: [sldev] Building 1.17.1 on Linux/Unix In-Reply-To: <54725.83.180.83.164.1182892114.squirrel@datendelphin.net> References: <54725.83.180.83.164.1182892114.squirrel@datendelphin.net> Message-ID: <53472.83.180.83.164.1182893026.squirrel@datendelphin.net> > [...] > > Missing Libraries at Runtime > > If you build a release_for_download, the content of > linden/indra/lib_releasefordownload_client/i686-linux/ isn't packaged into > linden/indra/newview/SecondLife_i686_1_17_1_0.tar.bz2. So just copy that > content into the SecondLife_i686_1_17_1_0/lib/ folder after unpacking. > (The proper thing to do would be to fix the SConstruct file, of course.) > > [...] > > PS: If anything herein is completely wrong, please correct me > ;-) One little correction from myself: It's sufficient to copy the *.so files. (I don't even know if all of them are needed) Boroondas From mattk at electricsheepcompany.com Tue Jun 26 14:56:41 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Tue Jun 26 14:56:20 2007 Subject: [sldev] VC8/VS2005 project files for 1.18.0.0 Message-ID: <46818B99.8050003@electricsheepcompany.com> Hey all, I had to modify the VC8 project files included in VWR-1151 a bit to get 1.18.0.0 compiling, so I uploaded a new version of the project files ZIP to the JIRA (keeping to Nicholaz's naming scheme). See https://jira.secondlife.com/browse/VWR-1151 for details. I'll try to keep them current as the 1.18 release and subsequent releases come out (unless somebody beats me to it! :-) ). -Matt -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From seg at haxxed.com Tue Jun 26 15:14:40 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jun 26 15:14:00 2007 Subject: [sldev] -Werror? Message-ID: <1182896080.14627.3.camel@localhost> Argh. Who added -Werror to the build flags? While that may be great for upstream, more often than not us downstream packagers end up having to remove it anyway. gcc versions differ widely in what warnings they give. g++ -o x86_64-linux-client-release/llcommon/metaclass.os -c -g -pipe -Wall -Wno-trigraphs -Wno-sign-compare -Werror -fexceptions -fsigned-char -fno-strict-aliasing -ffast-math -fPIC -DLL_MESA_HEADLESS=0 -DLL_MESA=0 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DLL_LINUX=1 -DAPPID=secondlife -DLL_SDL=1 -DLL_FMOD=0 -DLL_X11=1 -DLL_GTK=1 -DLL_ELFBIN=0 -DLL_LIBXUL_ENABLED=0 -DNDEBUG -DLL_RELEASE=1 -DLL_RELEASE_FOR_DOWNLOAD=1 -Illcommon -Illmath -Illwindow -Illaudio -Illcharacter -Illdatabase -Illhavok -Illimage -Illinventory -Illmedia -Illmessage -Illprimitive -Illrender -Illscene -Illui -Illvfs -Illwindow -Illxml -Ilscript -I/builddir/build/BUILD/linden/libraries/include -I/builddir/build/BUILD/linden/libraries/include/havok -I/builddir/build/BUILD/linden/libraries/x86_64-linux/include -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/SDL x86_64-linux-client-release/llcommon/metaclass.cpp cc1plus: warnings being treated as errors x86_64-linux-client-release/llcommon/llsys.cpp: In static member function 'static U32 LLOSInfo::getProcessVirtualSizeKB()': x86_64-linux-client-release/llcommon/llsys.cpp:261: warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result x86_64-linux-client-release/llcommon/llsys.cpp: In static member function 'static U32 LLOSInfo::getProcessResidentSizeKB()': x86_64-linux-client-release/llcommon/llsys.cpp:289: warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result x86_64-linux-client-release/llcommon/llsys.cpp: In function 'BOOL gunzip_file(const char*, const char*)': x86_64-linux-client-release/llcommon/llsys.cpp:494: warning: ignoring return value of 'size_t fwrite(const void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result distcc[8315] ERROR: compile x86_64-linux-client-release/llcommon/llsys.cpp on localhost failed scons: *** [x86_64-linux-client-release/llcommon/llsys.os] Error 1 scons: building terminated because of errors. error: Bad exit status from /var/tmp/rpm-tmp.75410 (%build) -------------- 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/20070626/cd9f4f79/attachment.pgp From nicholaz at blueflash.cc Tue Jun 26 15:32:47 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 15:32:56 2007 Subject: [sldev] VC8/VS2005 project files for 1.18.0.0 In-Reply-To: <46818B99.8050003@electricsheepcompany.com> References: <46818B99.8050003@electricsheepcompany.com> Message-ID: <4681940F.60102@blueflash.cc> Matt Kimmel wrote: > Hey all, > > I had to modify the VC8 project files included in VWR-1151 a bit to get > 1.18.0.0 compiling, so I uploaded a new version of the project files ZIP > to the JIRA (keeping to Nicholaz's naming scheme). See > https://jira.secondlife.com/browse/VWR-1151 for details. I'll try to > keep them current as the 1.18 release and subsequent releases come out > (unless somebody beats me to it! :-) ). Sounds good to me. I'm not using VS2005 anyway, so I won't even try to make these if I know someone else is on it. :-) Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Tue Jun 26 15:38:30 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 15:38:38 2007 Subject: [sldev] VWR-1396 Message-ID: <46819566.6010601@blueflash.cc> I just saw the patch on 1396 (didn't even apply it, was just looking at the .patch), so I'm not hoping I'm making a fool of myself but ... If you enclose the code in an "if (mCurrentOperatingp)" to check for null pointers, what about the line above that? "mCurrentOperatingp->deleteData();" wouldn't when mCurrentOperatingp still crash if it is null? Nick Index: linked_lists.h =================================================================== --- linked_lists.h (revision 64028) +++ linked_lists.h (working copy) @@ -908,9 +908,12 @@ mCurrentp = mCurrentOperatingp->mNextp; mCurrentOperatingp->deleteData(); <<<--- ???? + if(mCurrentOperatingp) + { + if (mCurrentOperatingp->mDatap) + llerror("This is impossible!", 0); + delete mCurrentOperatingp; + } mCurrentOperatingp = mCurrentp; mCount--; } -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From kelly at lindenlab.com Tue Jun 26 15:47:44 2007 From: kelly at lindenlab.com (Kelly Washington) Date: Tue Jun 26 15:47:48 2007 Subject: [sldev] VWR-1396 In-Reply-To: <46819566.6010601@blueflash.cc> References: <46819566.6010601@blueflash.cc> Message-ID: <46819790.1060301@lindenlab.com> I personally advocated not changing linked_lists.h - the other patch is sufficient to stop the crash. Our home brewed container classes are arcane code used in arcane ways that needs to be excised from our code. Maintaining them is a Pandora's box I hope to avoid. Although I may be paranoid and I think I have already been accused of spreading FUD in this regard, although the accuser was rather subtle in the accusation. In this case, as scary as this is, the mCurrentOperatingp->deleteData() appears to be what is invalidating mCurrentOperatingp. This is obviously bad, and the fixes (both of them) are quick ones so they can be tested and included in tomorrow's release. I'll state it again: anyone willing to take the time to port any use of a LL home-brewed container class to an appropriate STL container will get my support and help. And again, be warned it is *not a trivial task*. It needs serious thought and understanding of all the code that uses the container class, including probably writing of some code to do magic the home brewed containers do internally. - Kelly Nicholaz Beresford wrote: > > I just saw the patch on 1396 (didn't even apply it, was > just looking at the .patch), so I'm not hoping I'm making > a fool of myself but ... > > If you enclose the code in an "if (mCurrentOperatingp)" > to check for null pointers, what about the line above that? > "mCurrentOperatingp->deleteData();" wouldn't > when mCurrentOperatingp still crash if it is null? > > > Nick > > > Index: linked_lists.h > =================================================================== > --- linked_lists.h (revision 64028) > +++ linked_lists.h (working copy) > @@ -908,9 +908,12 @@ > mCurrentp = mCurrentOperatingp->mNextp; > > mCurrentOperatingp->deleteData(); <<<--- ???? > + if(mCurrentOperatingp) > + { > + if (mCurrentOperatingp->mDatap) > + llerror("This is impossible!", 0); > + delete mCurrentOperatingp; > + } > mCurrentOperatingp = mCurrentp; > mCount--; > } > > From bos at lindenlab.com Tue Jun 26 15:55:24 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Jun 26 15:55:27 2007 Subject: [sldev] Letting the larger SL community know about open source work Message-ID: <4681995C.5070303@lindenlab.com> We've put together a blog posting to acknowledge and thank all of you who have been working on the open source viewer: http://blog.secondlife.com/2007/06/26/an-open-source-community-update/ Yay sldev! References: <1182896080.14627.3.camel@localhost> Message-ID: <468199D2.4030606@lindenlab.com> Callum Lerwick wrote: > Argh. Who added -Werror to the build flags? What version of gcc are you using? I haven't seen those errors with gcc 3.4 through 4.1. References: <46819566.6010601@blueflash.cc> <46819790.1060301@lindenlab.com> Message-ID: <46819D30.4030904@blueflash.cc> Kelly Washington wrote: > In this case, as scary as this is, the mCurrentOperatingp->deleteData() > appears to be what is invalidating mCurrentOperatingp. This is > obviously bad, and the fixes (both of them) are quick ones so they can > be tested and included in tomorrow's release. LOL, I had shortly considered that and thought it would be too wild. Spreading FUD about code which pulls stunts like these (not that I haven't done similar things in the past) is certainly a wise thing to do :-) > I'll state it again: anyone willing to take the time to port any use of > a LL home-brewed container class to an appropriate STL container will > get my support and help. And again, be warned it is *not a trivial > task*. It needs serious thought and understanding of all the code that > uses the container class, including probably writing of some code to do > magic the home brewed containers do internally. This certainly tickles my interest ... will have a look at the linked lists at some point, maybe just out of curiosity ... :-) Thanks for the info ... Nick From bridie at lindenlab.com Tue Jun 26 16:16:21 2007 From: bridie at lindenlab.com (Bridie Linden) Date: Tue Jun 26 16:16:24 2007 Subject: [sldev] Letting the larger SL community know about open source work In-Reply-To: <4681995C.5070303@lindenlab.com> References: <4681995C.5070303@lindenlab.com> Message-ID: <410CF387-0BC9-4354-9B0F-4C1B63FB3BF2@lindenlab.com> Thanks for posting, bos and thanks to SLDev! --Bridie On Jun 26, 2007, at 3:55 PM, Bryan O'Sullivan wrote: > We've put together a blog posting to acknowledge and thank all of > you who have been working on the open source viewer: http:// > blog.secondlife.com/2007/06/26/an-open-source-community-update/ > > Yay sldev! > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From labrat.hb at gmail.com Tue Jun 26 16:39:10 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Jun 26 16:39:11 2007 Subject: [sldev] Letting the larger SL community know about open source work In-Reply-To: <410CF387-0BC9-4354-9B0F-4C1B63FB3BF2@lindenlab.com> References: <4681995C.5070303@lindenlab.com> <410CF387-0BC9-4354-9B0F-4C1B63FB3BF2@lindenlab.com> Message-ID: May want to make sure you're crediting the people who submit the patches not the people who submitted the trouble ticket. They aren't always the same person. On 6/26/07, Bridie Linden wrote: > > Thanks for posting, bos and thanks to SLDev! > > --Bridie > > On Jun 26, 2007, at 3:55 PM, Bryan O'Sullivan wrote: > > > We've put together a blog posting to acknowledge and thank all of > > you who have been working on the open source viewer: http:// > > blog.secondlife.com/2007/06/26/an-open-source-community-update/ > > > > Yay sldev! > > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070626/b3790abf/attachment.htm From blakar at gmail.com Tue Jun 26 16:39:24 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Tue Jun 26 16:39:27 2007 Subject: [sldev] OpenJPEG vs KDU Message-ID: <7992d0d60706261639w15e6f338u92ebc7e8426090e0@mail.gmail.com> Ok, in light of VWR-866 I'm wondering what it would take for OpenJPEG to replace KDU. I've heard that KDU would be faster. Anybody has an idea on how much? I've build OpenJPEG 1.2 with VS2005 and did a quick check using CodeAnalyst. A few minutes after my first run I got a 0.5% benefit with 1 minor change. That may sound minor but given the simplicity of the change I guess some real effort would give us quite a bit more. Is it worth it? How much speed do we need to aim for? What parameters would LL want to use if we switch to OpenJPEG (then I can optimise towards that first). Dirk aka Blakar Ogre From bos at lindenlab.com Tue Jun 26 16:44:13 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Tue Jun 26 16:44:16 2007 Subject: [sldev] Letting the larger SL community know about open source work In-Reply-To: References: <4681995C.5070303@lindenlab.com> <410CF387-0BC9-4354-9B0F-4C1B63FB3BF2@lindenlab.com> Message-ID: <4681A4CD.2000408@lindenlab.com> Harold Brown wrote: > May want to make sure you're crediting the people who submit the patches > not the people who submitted the trouble ticket. Yep, that's what we do. Hello Everyone, I've missed a couple of beta source drops, but this version has some annoying bug fixes over the other two. 1.18.0.3 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_beta-1.18.0.3 Release note information here: There were any blog posts on this, so I've included the text from the release notes at the bottom. Checksums: 7c000abc8a2355bff45f7e304b8bbdd6 slviewer-darwin-libs-beta-1.18.0.3.tar.gz abf55d587c721198519459e24f4d63cd slviewer-linux-libs-beta-1.18.0.3.tar.gz 5ef7028c8d096fe2bd4bca38d22cbbeb slviewer-src-beta-1.18.0.3.tar.gz 73f578449684de847e44916954f5977d slviewer-artwork-beta-1.18.0.3.zip 0b52d87658f715cfb67f65e23774ef7c slviewer-src-beta-1.18.0.3.zip e2ff7472ac30204c9e76d5863854b001 slviewer-win32-libs-beta-1.18.0.3.zip SVN checkout: http://svn.secondlife.com/svn/linden/branches/release-candidate Enjoy. -Anthony Release Notes for Second Life 1.18.0(3) June 26, 2007 ===================================== Bug fixes: * Fixed VWR-1369: Creating, re-rezzing, then editing an object results in a viewer crash Release Notes for Second Life 1.18.0(2) June 26, 2007 ===================================== Changes: * German language added to the Windows installer. Bug fixes: * Fixed VWR-1339: Asset upload fails for certain saves, eg scripts and appearance. * Fixed VWR-796: llStopSound() not working Release Notes for Second Life 1.18.0(1) June 22, 2007 ===================================== Changes: * More Viewer interface elements and text has been translated to Japanese and German. * Estate owners can now postpone a region restart for one hour. Bug fixes: * Fixed MISC-273: Enrollment fee is incorrectly deducted if you belong to max. # of groups and try to join new ones * Fixed SVC-248: Viewer crash: Server sends malformed DeRezAck Packet (see VWR-176) * Fixed SVC-242: Copyable objects are not appearing in inventory after being taken, are remaining, invisible, in world * Fixed SVC-52: UTF-8 characters read from notecards are lost * Fixed SVC-21: Request for making identification of llOwnerSay messages possible * Fixed VWR-1101: Active Gestures > New button doesn't auto-open gesture * Fixed VWR-684: German Translation of the Viewer inaccurate/dangerously wrong (corrections in patch) * Fixed ejecting a sitting intruder would cause the object they were sitting on to eject too. From dale at daleglass.net Tue Jun 26 16:53:03 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Tue Jun 26 16:53:08 2007 Subject: [sldev] Letting the larger SL community know about open source work In-Reply-To: <4681995C.5070303@lindenlab.com> References: <4681995C.5070303@lindenlab.com> Message-ID: <20070626235303.GA32622@bruno.sbruno> On Tue, Jun 26, 2007 at 03:55:24PM -0700, Bryan O'Sullivan wrote: > We've put together a blog posting to acknowledge and thank all of you > who have been working on the open source viewer: > http://blog.secondlife.com/2007/06/26/an-open-source-community-update/ > > Yay sldev! That's great :-) I'd like to see this again when people come up with more patches. It seems that quite a few people had misgivings about the whole OSS idea, so it's really good to have something positive to point at, and show how not only the sky hasn't fallen, but good things came out of it. I think it would be nice if you could just credit whoever provided the fix right in the changelog, whether a LL employee or a SL resident. -------------- 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/20070627/e6006336/attachment.pgp From seg at haxxed.com Tue Jun 26 17:31:08 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jun 26 17:30:28 2007 Subject: [sldev] OpenJPEG vs KDU In-Reply-To: <7992d0d60706261639w15e6f338u92ebc7e8426090e0@mail.gmail.com> References: <7992d0d60706261639w15e6f338u92ebc7e8426090e0@mail.gmail.com> Message-ID: <1182904268.14627.19.camel@localhost> On Wed, 2007-06-27 at 01:39 +0200, Dirk Moerenhout wrote: > Ok, in light of VWR-866 I'm wondering what it would take for OpenJPEG > to replace KDU. I've heard that KDU would be faster. Anybody has an > idea on how much? I've build OpenJPEG 1.2 with VS2005 and did a quick > check using CodeAnalyst. A few minutes after my first run I got a 0.5% > benefit with 1 minor change. That may sound minor but given the > simplicity of the change I guess some real effort would give us quite > a bit more. I've revived Dzonatas DWT vectorization patch, which results in a significant speedup. Especially combined with my T1 vectorization/cleanup patch which can pass floating point data direct from T1 to DWT. I've got a bunch of patches lined up I really need to finish off and submit... -------------- 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/20070626/92e69e86/attachment.pgp From seg at haxxed.com Tue Jun 26 17:33:26 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jun 26 17:32:40 2007 Subject: [sldev] -Werror? In-Reply-To: <468199D2.4030606@lindenlab.com> References: <1182896080.14627.3.camel@localhost> <468199D2.4030606@lindenlab.com> Message-ID: <1182904406.14627.22.camel@localhost> On Tue, 2007-06-26 at 15:57 -0700, Bryan O'Sullivan wrote: > Callum Lerwick wrote: > > Argh. Who added -Werror to the build flags? > > What version of gcc are you using? I haven't seen those errors with gcc > 3.4 through 4.1. Those ones in particular are probably more a result of Fedora's glibc. -------------- 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/20070626/0f53ae02/attachment.pgp From labrat.hb at gmail.com Tue Jun 26 17:33:44 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Tue Jun 26 17:33:45 2007 Subject: [sldev] Letting the larger SL community know about open source work In-Reply-To: <4681A4CD.2000408@lindenlab.com> References: <4681995C.5070303@lindenlab.com> <410CF387-0BC9-4354-9B0F-4C1B63FB3BF2@lindenlab.com> <4681A4CD.2000408@lindenlab.com> Message-ID: "Thanks also to the other residents whose patches we've had time to apply: Argent Stonecutter, Benja Kepler, Blakar Ogre, blino Nakamura, bushing Spatula, Drewan Keats, Duckless Vandyke" Duckless Vandyke did not submit a patch. He submitted a suggestion. On 6/26/07, Bryan O'Sullivan wrote: > > Harold Brown wrote: > > May want to make sure you're crediting the people who submit the patches > > not the people who submitted the trouble ticket. > > Yep, that's what we do. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070626/edd0d8a7/attachment.htm From seg at haxxed.com Tue Jun 26 18:22:28 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jun 26 18:21:43 2007 Subject: [sldev] Linking broken? Message-ID: <1182907348.14627.25.camel@localhost> $ secondlife secondlife: error while loading shared libraries: libllimage.so: cannot open shared object file: No such file or directory $ ldd /usr/bin/secondlife libllimage.so => not found libllimagej2coj.so => not found libllvfs.so => not found libllmath.so => not found libllcommon.so => not found Sigh. -------------- 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/20070626/b3fa5ce3/attachment.pgp From seg at haxxed.com Tue Jun 26 18:34:17 2007 From: seg at haxxed.com (Callum Lerwick) Date: Tue Jun 26 18:33:37 2007 Subject: [sldev] Linking broken? In-Reply-To: <1182907348.14627.25.camel@localhost> References: <1182907348.14627.25.camel@localhost> Message-ID: <1182908058.14627.29.camel@localhost> Okay so its doing this on purpose: def create_cond_module(module, module_libs=[]): if build_target != 'client' or not opensource: create_static_module(module=module) else: create_dynamic_module(module=module, module_libs=module_libs) I don't see the reasoning behind this. -------------- 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/20070626/93249769/attachment.pgp From nicholaz at blueflash.cc Tue Jun 26 18:33:41 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Tue Jun 26 18:33:50 2007 Subject: [sldev] Blog, 1.17.2, 1.18 postponed Message-ID: <4681BE75.6020701@blueflash.cc> Hi Everybody and Lindens in particular. Dunno how to put it so that it comes across the way I intend it, but what I've seen in the last 24 hours (on the blog, with the releases, etc.) is so unlike what I've seen in the past weeks, that I seriously consider to believe in an incident of alien abduction at Linden Lab sites :-) This was an excellent example of how to do things right (as far as "right" is defined in my book). And I would really recommend to read the blog comments there, I think you haven't received that much public affection from the community in quite some time. Double thumbs up from me ... yay! Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From able.whitman at gmail.com Tue Jun 26 19:07:48 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jun 26 19:07:50 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> Message-ID: <7b3a84fb0706261907t54c8f6ebq8634ccb0f0de1c8f@mail.gmail.com> I've still been hammering on this idea in my spare time, and I've got a reasonable implementation of mute-by-parcel almost working. "Almost", because it turns out that persisting the parcel mutes is turning out to be rather fiddly. I just want to say to the nice folks at LL that the fact that the service both discards the MuteFlags field, and limits the length of the MuteName field to 63 chars is really cramping my style. :) Is there a way for the viewer to persist, in the dataserver, some user-specific data across sessions? On 6/21/07, Able Whitman wrote: > > Howdy, > > On and off, I've been investigating the feasibility of implementing > "Visibility Muting" as Nicholaz describes in VWR-1017 (https://jira.secondlife.com/browse/VWR-1017 > ), and as discussed in a few threads on this list. I'm pretty close to > having a proof-of-concept patch ready which adds the ability to mute the > visibility of objects by their ID, in much the same fashion that the > existing chat muting function works. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070626/5c3e3e6d/attachment.htm From mattk at electricsheepcompany.com Tue Jun 26 20:12:58 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Tue Jun 26 20:12:37 2007 Subject: [sldev] VC8/VS2005 project files for 1.18.0.0 In-Reply-To: <4681940F.60102@blueflash.cc> References: <46818B99.8050003@electricsheepcompany.com> <4681940F.60102@blueflash.cc> Message-ID: <4681D5BA.3090603@electricsheepcompany.com> No problem! I work with VS2005 every day, so it's easy for me to maintain this stuff--I'm just uploading the changes I make anyway. :-) -Matt Nicholaz Beresford wrote: > > Matt Kimmel wrote: >> Hey all, >> >> I had to modify the VC8 project files included in VWR-1151 a bit to get >> 1.18.0.0 compiling, so I uploaded a new version of the project files ZIP >> to the JIRA (keeping to Nicholaz's naming scheme). See >> https://jira.secondlife.com/browse/VWR-1151 for details. I'll try to >> keep them current as the 1.18 release and subsequent releases come out >> (unless somebody beats me to it! :-) ). > > Sounds good to me. I'm not using VS2005 anyway, so I won't even try > to make these if I know someone else is on it. :-) > > Nick > > --- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From agrimes at speakeasy.net Tue Jun 26 21:28:17 2007 From: agrimes at speakeasy.net (Alan Grimes) Date: Tue Jun 26 20:28:13 2007 Subject: [sldev] Standardizable classes Message-ID: <4681E761.8070201@speakeasy.net> Here's a brief list of classes in llcommon which are covered in posix standards... llDate -- Posix standard, probably on all reasonable platforms, see time.h Wchar support is now part of C99. ifstream/ofstream ???? uh, why?? -- classic part of C++ LLThread -- Provided by SDL which is already a dependency.. Not sure why we're using APR... (Apache Runtime Library) -- A better approach might be to #define the thread object as whatever the host library uses and the classic synchronization functions, this makes the thread calls much thinner and therefore, hopefully, faster, it also allows portability... and the aforementioned list class... -- Opera: Sing it loud! :o( )>-< From soft at lindenlab.com Tue Jun 26 22:49:07 2007 From: soft at lindenlab.com (Soft Linden) Date: Tue Jun 26 22:49:10 2007 Subject: [sldev] Opening the server source? In-Reply-To: <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> Message-ID: <9e6e5c9e0706262249u17e95ff1y26c18487a7d87f7a@mail.gmail.com> On 6/26/07, kelly@lindenlab.com wrote: > > I would be glad to explain how things work. I think we have a system > overview somewhere on the wiki already, but if we don't I could create it. > If there is a more specific question (or set of questions) I would be > happy to answer them. I was going to suggest just emailing me, but > perhaps a wiki page / FAQ would be better. If anyone wants to set one up > and populate it with a couple questions I can see about answering them. > > Questions I am imagining are like "what happens when this message is sent > to the sim?" or "what specifically causes this message to be sent to the > viewer?" or "why does this happen?". To be clear, I may not be able to > answer all questions but Soft and I should be able to find those who can. More Linden developer hours are in the pipeline, and one Linden has even raised the possibility of giving one of the same architectural overview presentations that new Linden developers get. In the interim, populating a page of questions as Kelly suggested sounds like a great move. Don't lose this invitation in a noisy thread. :) From jhurliman at wsu.edu Tue Jun 26 23:01:37 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Jun 26 23:01:36 2007 Subject: Simulator Baking Questions (was Re: [sldev] Opening the server source?) In-Reply-To: <9e6e5c9e0706262249u17e95ff1y26c18487a7d87f7a@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> <9e6e5c9e0706262249u17e95ff1y26c18487a7d87f7a@mail.gmail.com> Message-ID: <4681FD41.80207@wsu.edu> On 6/26/07, kelly@lindenlab.com wrote: >> >> I would be glad to explain how things work. I think we have a system >> overview somewhere on the wiki already, but if we don't I could >> create it. >> If there is a more specific question (or set of questions) I would be >> happy to answer them. I was going to suggest just emailing me, but >> perhaps a wiki page / FAQ would be better. If anyone wants to set >> one up >> and populate it with a couple questions I can see about answering them. >> >> Questions I am imagining are like "what happens when this message is >> sent >> to the sim?" or "what specifically causes this message to be sent to the >> viewer?" or "why does this happen?". To be clear, I may not be able to >> answer all questions but Soft and I should be able to find those who >> can. What exactly is the criteria for an image getting rejected or accepted by the server? Dimensions, compression rate, number of layers, number of comps, etc. What is the criteria for baked images? JPEG2000 comments, dimensions, number of layers, etc. If we are able to store five layer images on the asset server, could an avatar have a "permanent bake" where it always references images off the asset server when it logs in, and never changes outfits so it never has to worry about uploading temporary bake assets? John Hurliman From able.whitman at gmail.com Tue Jun 26 23:57:52 2007 From: able.whitman at gmail.com (Able Whitman) Date: Tue Jun 26 23:58:00 2007 Subject: [sldev] Opening the server source? In-Reply-To: <9e6e5c9e0706262249u17e95ff1y26c18487a7d87f7a@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> <9e6e5c9e0706262249u17e95ff1y26c18487a7d87f7a@mail.gmail.com> Message-ID: <7b3a84fb0706262357j162e29b0g26b810416c9b4fbc@mail.gmail.com> > > More Linden developer hours are in the pipeline, Maybe I'm rehashing an old idea, but why not have a few dedicated meeting locations where Lindens can sort of have on-demand office hours? You could publish a weekly schedule in the wiki, and office hours could be scheduled when you have something to discuss, or if there are residents who want to meet with you. That would still make it easier for us to track down our favorite Lindens and pester them with questions, with the advantage that if your time is better spent elsewhere, you're not stuck inworld for an hour where nobody comes by. And it doesn't preclude having fixed office hours if that works better for you. :) Of course, I'd love it if every Linden had regular office hours, but I understand about trying to make the best use of your time! and one Linden has > even raised the possibility of giving one of the same architectural > overview presentations that new Linden developers get. I would LOVE something like this. Cheers, --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070627/eb17406f/attachment.htm From nicholaz at blueflash.cc Wed Jun 27 01:54:24 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 01:54:36 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <7b3a84fb0706261907t54c8f6ebq8634ccb0f0de1c8f@mail.gmail.com> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> <7b3a84fb0706261907t54c8f6ebq8634ccb0f0de1c8f@mail.gmail.com> Message-ID: <468225C0.4070105@blueflash.cc> Able Whitman wrote: > I just want to say to the nice folks at LL that the fact that the > service both discards the MuteFlags field, and limits the length of the > MuteName field to 63 chars is really cramping my style. :) > > Is there a way for the viewer to persist, in the dataserver, some > user-specific data across sessions? Why don't you just use a local file? Nick From blakar at gmail.com Wed Jun 27 02:03:28 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jun 27 02:03:31 2007 Subject: [sldev] OpenJPEG vs KDU In-Reply-To: <1182904268.14627.19.camel@localhost> References: <7992d0d60706261639w15e6f338u92ebc7e8426090e0@mail.gmail.com> <1182904268.14627.19.camel@localhost> Message-ID: <7992d0d60706270203l3da1dc81ya8e3053cadcfad49@mail.gmail.com> Have these patches been submitted to the OpenJPEG maintainers? Do you think there would be any resistance from them in getting them applied? Given I'm located very near to them I wouldn't mind lending a hand when it comes to communication. Where can I get these patches? Dirk aka Blakar Ogre On 6/27/07, Callum Lerwick wrote: > On Wed, 2007-06-27 at 01:39 +0200, Dirk Moerenhout wrote: > > Ok, in light of VWR-866 I'm wondering what it would take for OpenJPEG > > to replace KDU. I've heard that KDU would be faster. Anybody has an > > idea on how much? I've build OpenJPEG 1.2 with VS2005 and did a quick > > check using CodeAnalyst. A few minutes after my first run I got a 0.5% > > benefit with 1 minor change. That may sound minor but given the > > simplicity of the change I guess some real effort would give us quite > > a bit more. > > I've revived Dzonatas DWT vectorization patch, which results in a > significant speedup. Especially combined with my T1 > vectorization/cleanup patch which can pass floating point data direct > from T1 to DWT. > > I've got a bunch of patches lined up I really need to finish off and > submit... > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From kerdezixe at gmail.com Wed Jun 27 05:14:48 2007 From: kerdezixe at gmail.com (Laurent Laborde) Date: Wed Jun 27 05:14:52 2007 Subject: [sldev] Opening the server source? In-Reply-To: <9e6e5c9e0706262249u17e95ff1y26c18487a7d87f7a@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <23bbb49e0706260404m2440449dn75ad529462338bf0@mail.gmail.com> <1101.76.103.71.48.1182870084.squirrel@mail.lindenlab.com> <9e6e5c9e0706262249u17e95ff1y26c18487a7d87f7a@mail.gmail.com> Message-ID: <8a1bfe660706270514k2a401b27y41634fd4d401d1b6@mail.gmail.com> On 6/27/07, Soft Linden wrote: > > In the interim, populating a page of questions as Kelly suggested > sounds like a great move. Don't lose this invitation in a noisy > thread. :) Certainly, but where ? https://wiki.secondlife.com/wiki/Talk:Server_architecture <- here ? -- kerunix Flan From able.whitman at gmail.com Wed Jun 27 05:39:08 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 27 05:39:10 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <468225C0.4070105@blueflash.cc> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> <7b3a84fb0706261907t54c8f6ebq8634ccb0f0de1c8f@mail.gmail.com> <468225C0.4070105@blueflash.cc> Message-ID: <7b3a84fb0706270539qb99faccvafcc85ccfa147e18@mail.gmail.com> I want the mute list to remain independent of the viewer, so that regardless of where you're accessing the grid from, you still get the same mute list as you would on your own machine. Plus, I'm sure there are plenty of people who regularly access the grid from more than one machine (e.g., at work and at home), and it would be annoying to have to maintain separate lists, I think. On 6/27/07, Nicholaz Beresford wrote: > > > Able Whitman wrote: > > I just want to say to the nice folks at LL that the fact that the > > service both discards the MuteFlags field, and limits the length of the > > MuteName field to 63 chars is really cramping my style. :) > > > > Is there a way for the viewer to persist, in the dataserver, some > > user-specific data across sessions? > > Why don't you just use a local file? > > > > Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070627/4e34938c/attachment.htm From alissa_sabre at yahoo.co.jp Wed Jun 27 05:42:24 2007 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed Jun 27 05:42:43 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> Message-ID: <74e0ddz4Lcuds4e04ei4te9a.alissa_sabre@yahoo.co.jp> # I'm afraid this message is too late... > Firstly, from where you stand, > *are* we doing better overall? Yes. > Second, is there anything we're doing *worse*? Any recent changes you > *don't* like? Nothing, except for some performance issues. (I'm sending my comments on JIRA performance separately.) > Lastly, what can we still do better? Are there one or two things that > frustrate you the most, which we could make part of our third quarter > goals? I have an issue in my mind. That is the synchronization of the official (released) binary and the source distribution. The open source community has experienced some cases that, when a new release of offical binary came out, and the corresponding source tarballs were distributed just after it, the source didn't produce the same viewer as the binary releases. Sometimes, few files were missing from the source tarballs. Sometimes build scripts were broken. And (I believe it is just once, but) on 1.4.0.1, the version number embedded in the source file was different from the binary release, that is, the distributed C++ source files was not exactly those for the binary release. Moreover, when I compare the binary from my own build and the official binary release, I heve never seen they are same. On Windows, I'm using VS2005, and the different binary is just as expected. On Linux, I'm not sure but it may be some minor differences between distribution. (I'm running Fedora, BTW.) What I'm not confortable is that on MacOS, my own binary and official binary don't match. I don't understand why they can different, because I believe LL and I are using exactly the same OS and same development tools... I don't like that. I wish two things to occure to solve this. When a new version of the viewer is out, I want the source for the release to be exported from the repository first, then that particular set of files to be used to build a binary releases. Distribution of the source can be before or after the binary release, but I want the source used to build it to be exactly the same as the source distribution. All the open source based products that I know of are run this way. My one cent. Alissa -------------------------------------- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ From nicholaz at blueflash.cc Wed Jun 27 05:48:04 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 05:48:17 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <7b3a84fb0706270539qb99faccvafcc85ccfa147e18@mail.gmail.com> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> <7b3a84fb0706261907t54c8f6ebq8634ccb0f0de1c8f@mail.gmail.com> <468225C0.4070105@blueflash.cc> <7b3a84fb0706270539qb99faccvafcc85ccfa147e18@mail.gmail.com> Message-ID: <46825C84.8000707@blueflash.cc> Understood. This was mainly meant as an easy workaround for development until you get some Linden assistance from the server side. Nick Able Whitman wrote: > I want the mute list to remain independent of the viewer, so that > regardless of where you're accessing the grid from, you still get the > same mute list as you would on your own machine. Plus, I'm sure there > are plenty of people who regularly access the grid from more than one > machine ( e.g., at work and at home), and it would be annoying to have > to maintain separate lists, I think. > > On 6/27/07, *Nicholaz Beresford* < nicholaz@blueflash.cc > > wrote: > > > Able Whitman wrote: > > I just want to say to the nice folks at LL that the fact that the > > service both discards the MuteFlags field, and limits the length > of the > > MuteName field to 63 chars is really cramping my style. :) > > > > Is there a way for the viewer to persist, in the dataserver, some > > user-specific data across sessions? > > Why don't you just use a local file? > > > > Nick > > From dzonatas at dzonux.net Wed Jun 27 06:00:23 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 27 06:00:18 2007 Subject: [sldev] OpenJPEG vs KDU In-Reply-To: <7992d0d60706270203l3da1dc81ya8e3053cadcfad49@mail.gmail.com> References: <7992d0d60706261639w15e6f338u92ebc7e8426090e0@mail.gmail.com> <1182904268.14627.19.camel@localhost> <7992d0d60706270203l3da1dc81ya8e3053cadcfad49@mail.gmail.com> Message-ID: <46825F67.8090909@dzonux.net> Some of the patches have already been applied to the main OpenJPEG repository. They provide about a 2x speed-up. I started work on the Floating Point/SSE and posted the patch here. Callum has taken over to finish up that code with merges into the T1 work that was done. The Floating Point/SSE, as it was, provided about anywhere from 2x to 20x speed-up, which set it closely behind KDU. I bet that OpenJPEG could be made to go faster than KDU under the terrible threads conditions (cache pollution) of Second Life. KDU was not designed to handle such conditions. Dirk Moerenhout wrote: > Have these patches been submitted to the OpenJPEG maintainers? Do you > think there would be any resistance from them in getting them applied? > Given I'm located very near to them I wouldn't mind lending a hand > when it comes to communication. > > Where can I get these patches? > > Dirk aka Blakar Ogre > > On 6/27/07, Callum Lerwick wrote: >> On Wed, 2007-06-27 at 01:39 +0200, Dirk Moerenhout wrote: >> > Ok, in light of VWR-866 I'm wondering what it would take for OpenJPEG >> > to replace KDU. I've heard that KDU would be faster. Anybody has an >> > idea on how much? I've build OpenJPEG 1.2 with VS2005 and did a quick >> > check using CodeAnalyst. A few minutes after my first run I got a 0.5% >> > benefit with 1 minor change. That may sound minor but given the >> > simplicity of the change I guess some real effort would give us quite >> > a bit more. >> >> I've revived Dzonatas DWT vectorization patch, which results in a >> significant speedup. Especially combined with my T1 >> vectorization/cleanup patch which can pass floating point data direct >> from T1 to DWT. >> >> I've got a bunch of patches lined up I really need to finish off and >> submit... >> >> _______________________________________________ >> 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 Wed Jun 27 06:19:12 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 27 06:19:07 2007 Subject: [sldev] STL port (was about LLLinkedList and container replacements) In-Reply-To: <46817B46.4020908@dzonux.net> References: <468147C5.1000800@dzonux.net> <46814C34.90401@lindenlab.com> <46817B46.4020908@dzonux.net> Message-ID: <468263D0.5030505@dzonux.net> One more thing to note, I have already done work on scripts to recompile the viewer with STL under GCC. And of note, GCC can produce Win32 executables also with STL. (MSVCRT is buggy by itself, the MS compilers have just been compiling in workarounds instead of directly updating the lib) There *may* be a problem to just drop in STL on the Express version of VC8. That'll have to be researched more. I'm sure someone has figured out a way to do it. The scripts are located on OSLCC. They compile everything under GCC. Just replace the standard GCC with the STL-port enabled GCC, and it works. Dzonatas wrote: > Kelly Washington wrote: >> If anyone submits a patch that removes ALL uses of LLLinkedList (or any >> other home-brewed container class in our code) in favor of a std:: >> equivelant I will personally work to get it into the release code as >> fast as possible. This is a non-trivial task though. >> > > When someone asks one to write a linked list in C++ or C, it is not so > trivial for many reasons. I'll just touch on the portable issue and > avoid the legal patent issues (and other patent nonsense). > > One could just write it out in plain C with full implementation and > avoid any C++ containers. I'm sure C++ programmers usually bark at > this technique. Actually, I know this because C++ programmers tend to > watch the clock for how much time it takes to write out the > implementation. > > C++ programmers, instead, would rather see something like std::vector > being used. It is quick to implement and probably avoids that jerky > head look at the clock. The std::vector (and like) container(s) are > not pure linked lists, however. They rely more on dynamic arrays. The > benefits of a linked list are lost. > > The trivial solution is to move the compiler to include the STL > library, which is not in use by default. Then one could use the > std::list<> template. > > The STL library also adds the additional benefit of cross platform > compatibility. For example, many of the wide character implementations > under MSVC's STD library are not portable. The STL library is the > answer to make it portable. > > I'd jump on it, but I have a treasury program of higher priority to > write, first. > -- Power to Change the Void From nicholaz at blueflash.cc Wed Jun 27 06:26:23 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 06:26:37 2007 Subject: [sldev] STL port (was about LLLinkedList and container replacements) In-Reply-To: <468263D0.5030505@dzonux.net> References: <468147C5.1000800@dzonux.net> <46814C34.90401@lindenlab.com> <46817B46.4020908@dzonux.net> <468263D0.5030505@dzonux.net> Message-ID: <4682657F.2090801@blueflash.cc> Dzonatas wrote: > There *may* be a problem to just drop in STL on the Express version of > VC8. That'll have to be researched more. I'm sure someone has figured > out a way to do it. I'm currently getting unresolved externals about std::vector when compiling with VS2005 (viewer and llstartup), but have not found what to do about it yet. Nick From nicholaz at blueflash.cc Wed Jun 27 06:38:54 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 06:39:02 2007 Subject: [sldev] Quirk in LIBPNG project files Message-ID: <4682686E.3070000@blueflash.cc> LIBPNG has a quirk in their VC71 project files (at least in relation to how SL does things). In the builds for LIB Debug and LIB Release (and possibly also LIB ASM Debug and LIB Asm Release) Properties, C++, Code Generation is set to link against the DLL Runtime Libraries. This causes a series of warnings when linking libpng to the SL viewer. For SL the settings there should be /MT and MTd rather than /MD and /MDd Nick From able.whitman at gmail.com Wed Jun 27 06:54:24 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 27 06:54:27 2007 Subject: [sldev] Re: More on Mute Visibility In-Reply-To: <46825C84.8000707@blueflash.cc> References: <7b3a84fb0706202144n19080280wf3df82c1edd9793c@mail.gmail.com> <7b3a84fb0706261907t54c8f6ebq8634ccb0f0de1c8f@mail.gmail.com> <468225C0.4070105@blueflash.cc> <7b3a84fb0706270539qb99faccvafcc85ccfa147e18@mail.gmail.com> <46825C84.8000707@blueflash.cc> Message-ID: <7b3a84fb0706270654m28fd3cf2w349549e0084924bd@mail.gmail.com> Ah, right, I understand. Yeah, I think I'm going to have to do something like that, because the alternatives are pretty hackish. On 6/27/07, Nicholaz Beresford wrote: > > > Understood. This was mainly meant as an easy workaround > for development until you get some Linden assistance > from the server side. > > > Nick > > > > Able Whitman wrote: > > I want the mute list to remain independent of the viewer, so that > > regardless of where you're accessing the grid from, you still get the > > same mute list as you would on your own machine. Plus, I'm sure there > > are plenty of people who regularly access the grid from more than one > > machine ( e.g., at work and at home), and it would be annoying to have > > to maintain separate lists, I think. > > > > On 6/27/07, *Nicholaz Beresford* < nicholaz@blueflash.cc > > > wrote: > > > > > > Able Whitman wrote: > > > I just want to say to the nice folks at LL that the fact that the > > > service both discards the MuteFlags field, and limits the length > > of the > > > MuteName field to 63 chars is really cramping my style. :) > > > > > > Is there a way for the viewer to persist, in the dataserver, some > > > user-specific data across sessions? > > > > Why don't you just use a local file? > > > > > > > > Nick > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070627/99bf53ba/attachment.htm From dzonatas at dzonux.net Wed Jun 27 08:22:36 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 27 08:22:31 2007 Subject: [sldev] STL port (was about LLLinkedList and container replacements) In-Reply-To: <4682657F.2090801@blueflash.cc> References: <468147C5.1000800@dzonux.net> <46814C34.90401@lindenlab.com> <46817B46.4020908@dzonux.net> <468263D0.5030505@dzonux.net> <4682657F.2090801@blueflash.cc> Message-ID: <468280BC.4030201@dzonux.net> Nicholaz Beresford wrote: > > > Dzonatas wrote: >> There *may* be a problem to just drop in STL on the Express version >> of VC8. That'll have to be researched more. I'm sure someone has >> figured out a way to do it. > > I'm currently getting unresolved externals about std::vector when > compiling with VS2005 (viewer and llstartup), but have not found what > to do about it yet. > Probably, it is the pre-compiled boost libs that weren't compiled with STL. -- Power to Change the Void From able.whitman at gmail.com Wed Jun 27 08:44:04 2007 From: able.whitman at gmail.com (Able Whitman) Date: Wed Jun 27 08:44:08 2007 Subject: [sldev] STL port (was about LLLinkedList and container replacements) In-Reply-To: <468280BC.4030201@dzonux.net> References: <468147C5.1000800@dzonux.net> <46814C34.90401@lindenlab.com> <46817B46.4020908@dzonux.net> <468263D0.5030505@dzonux.net> <4682657F.2090801@blueflash.cc> <468280BC.4030201@dzonux.net> Message-ID: <7b3a84fb0706270844k34c46d6eu6c90d539558f4555@mail.gmail.com> Nick, I'm surprised you're getting build errors with VC8 express, because it does include STL libraries. From http://msdn.microsoft.com/vstudio/express/visualc/features/language/default.aspx : "Visual C++ 2005 Express Edition includes a fully ISO-compliant implementation of the Standard Template Library (STL)." What are the errors you're seeing? --Able On 6/27/07, Dzonatas wrote: > > Nicholaz Beresford wrote: > > > > > > Dzonatas wrote: > >> There *may* be a problem to just drop in STL on the Express version > >> of VC8. That'll have to be researched more. I'm sure someone has > >> figured out a way to do it. > > > > I'm currently getting unresolved externals about std::vector when > > compiling with VS2005 (viewer and llstartup), but have not found what > > to do about it yet. > > > > Probably, it is the pre-compiled boost libs that weren't compiled with > STL. > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070627/a8824b64/attachment-0001.htm From nicholaz at blueflash.cc Wed Jun 27 09:12:28 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 09:12:45 2007 Subject: [sldev] STL port (was about LLLinkedList and container replacements) In-Reply-To: <7b3a84fb0706270844k34c46d6eu6c90d539558f4555@mail.gmail.com> References: <468147C5.1000800@dzonux.net> <46814C34.90401@lindenlab.com> <46817B46.4020908@dzonux.net> <468263D0.5030505@dzonux.net> <4682657F.2090801@blueflash.cc> <468280BC.4030201@dzonux.net> <7b3a84fb0706270844k34c46d6eu6c90d539558f4555@mail.gmail.com> Message-ID: <46828C6C.5050102@blueflash.cc> I was just using my own VC8 files and added rather than converting the 1.17.1 files. Dunno what went wrong there, but the newly converted files work. Nick Able Whitman wrote: > Nick, > > I'm surprised you're getting build errors with VC8 express, because it > does include STL libraries. > > From > http://msdn.microsoft.com/vstudio/express/visualc/features/language/default.aspx: > > "Visual C++ 2005 Express Edition includes a fully ISO-compliant > implementation of the Standard Template Library (STL)." > > What are the errors you're seeing? > > --Able > > On 6/27/07, *Dzonatas * > wrote: > > Nicholaz Beresford wrote: > > > > > > Dzonatas wrote: > >> There *may* be a problem to just drop in STL on the Express version > >> of VC8. That'll have to be researched more. I'm sure someone has > >> figured out a way to do it. > > > > I'm currently getting unresolved externals about std::vector when > > compiling with VS2005 (viewer and llstartup), but have not found what > > to do about it yet. > > > > Probably, it is the pre-compiled boost libs that weren't compiled > with STL. > > -- > Power to Change the Void > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From phoenix at secondlife.com Wed Jun 27 09:14:12 2007 From: phoenix at secondlife.com (Phoenix) Date: Wed Jun 27 09:14:21 2007 Subject: [sldev] Standardizable classes In-Reply-To: <4681E761.8070201@speakeasy.net> References: <4681E761.8070201@speakeasy.net> Message-ID: <732C12EC-9961-46A9-B2A5-8373CD5B75A7@secondlife.com> On 2007 Jun 26, at 21:28, Alan Grimes wrote: > Here's a brief list of classes in llcommon which are covered in posix > standards... > > llDate -- Posix standard, probably on all reasonable platforms, see > time.h time.h is a set of c functions, and we wanted a class to represent a point in time. > Wchar support is now part of C99. ...and different widths on different platforms. We use wchar for strings and llwchar where we want a fixed width wide character. > ifstream/ofstream ???? uh, why?? -- classic part of C++ do you mean llifstream and llofstream? Windows does not handle international character sets correctly with the standard c++ file streams. For example, we could not load your user settings if there was a non-us-ascii character in the path to your user directory. > LLThread -- Provided by SDL which is already a dependency.. Not > sure why we're using APR... (Apache Runtime Library) > -- A better approach might be to #define the thread object as whatever > the host library uses and the classic synchronization functions, this > makes the thread calls much thinner and therefore, hopefully, > faster, it > also allows portability... We only link to the SDL when building the client in linux. The APR library provides a reasonable cross-platform thread representation which supports more platforms and is less time consuming to update than the boost library. Threads predate the linux client and are in many places besides the linux client. If there is some compelling reason to specialize LLThread for linux based on SDL the project will be considered. -------------- 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/20070627/72b95027/PGP.pgp From josh at lindenlab.com Wed Jun 27 09:51:02 2007 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jun 27 09:51:31 2007 Subject: [sldev] Just askin': How are we doing? In-Reply-To: <74e0ddz4Lcuds4e04ei4te9a.alissa_sabre@yahoo.co.jp> References: <9e6e5c9e0706241808j5580fb9aw1ae658e625e5cc3d@mail.gmail.com> <74e0ddz4Lcuds4e04ei4te9a.alissa_sabre@yahoo.co.jp> Message-ID: <46829576.3070908@lindenlab.com> Alissa's issues boil down to one root cause: the Linden-provided viewer binary releases are not done using the same set of libraries and tools as are available in the source drop. This manifests in at least two ways: (1) The process of providing the source is a multi-step export process which is by necessity lossy. It is also error prone - because the list of files to export is explicit, a file can be missed. (2) The libraries and scripts used for building are different, thus producing different binaries. This is a situation we'd like to correct, but it will take time - for example, until the OpenJPEG performance is comparable with the KDU library we've licensed, I don't see us switching. And switching from "open source drops are a stripped subset of the internal build environment" to "internal builds are a superset of patches layered over the open code base" is also something we'd like to do, but will take time and resources. (Have I mentioned that we're hiring?) Alissa Sabre wrote: > The open source community has experienced some cases that, when a new > release of offical binary came out, and the corresponding source > tarballs were distributed just after it, the source didn't produce the > same viewer as the binary releases. Sometimes, few files were missing > from the source tarballs. Sometimes build scripts were broken. And > (I believe it is just once, but) on 1.4.0.1, the version number > embedded in the source file was different from the binary release, > that is, the distributed C++ source files was not exactly those for > the binary release. > This is a manifestation of #1. We've shifted responsibility for producing the source code drops from Rob to my release team, so when problems are reported we should have more ability to regenerate the tarballs. I try and monitor this list, so please scream and shout. We should have 1.17.2.0 code up shortly (I think it was bundled up last night but links weren't sent around, I'm checking on this) > Moreover, when I compare the binary from my own build and the official > binary release, I heve never seen they are same. On Windows, I'm > using VS2005, and the different binary is just as expected. On Linux, > I'm not sure but it may be some minor differences between > distribution. (I'm running Fedora, BTW.) What I'm not confortable is > that on MacOS, my own binary and official binary don't match. I don't > understand why they can different, because I believe LL and I are > using exactly the same OS and same development tools... > This is a manifestation of #2. At the very least, the open source-based releases use the OpenJPEG library vs. the KDU library for JPEG2000 decoding. There are probably a few other differences - Rob can probably provide a full list. Hopefully this is all in the Wiki - if not, scream at us! From nicholaz at blueflash.cc Wed Jun 27 10:05:51 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 10:06:01 2007 Subject: [sldev] STL port (was about LLLinkedList and container replacements) In-Reply-To: <46828C6C.5050102@blueflash.cc> References: <468147C5.1000800@dzonux.net> <46814C34.90401@lindenlab.com> <46817B46.4020908@dzonux.net> <468263D0.5030505@dzonux.net> <4682657F.2090801@blueflash.cc> <468280BC.4030201@dzonux.net> <7b3a84fb0706270844k34c46d6eu6c90d539558f4555@mail.gmail.com> <46828C6C.5050102@blueflash.cc> Message-ID: <468298EF.3070604@blueflash.cc> Found it ... llsrv.cpp and llsrv.h were missing. Nick Nicholaz Beresford wrote: > Able Whitman wrote: >> Nick, >> >> I'm surprised you're getting build errors with VC8 express, because it >> does include STL libraries. >> >> From >> http://msdn.microsoft.com/vstudio/express/visualc/features/language/default.aspx: >> >> >> "Visual C++ 2005 Express Edition includes a fully ISO-compliant >> implementation of the Standard Template Library (STL)." >> >> What are the errors you're seeing? >> >> --Able From nicholaz at blueflash.cc Wed Jun 27 10:51:01 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 10:51:17 2007 Subject: [sldev] Letting the larger SL community know about open source work In-Reply-To: <4681995C.5070303@lindenlab.com> References: <4681995C.5070303@lindenlab.com> Message-ID: <4682A385.3010003@blueflash.cc> Bryan O'Sullivan wrote: > We've put together a blog posting to acknowledge and thank all of you > who have been working on the open source viewer: > http://blog.secondlife.com/2007/06/26/an-open-source-community-update/ > > Yay sldev! Much appreciated! Yay LL! :-) Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From bos at lindenlab.com Wed Jun 27 11:52:32 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Wed Jun 27 11:52:35 2007 Subject: [sldev] -Werror? In-Reply-To: <1182904406.14627.22.camel@localhost> References: <1182896080.14627.3.camel@localhost> <468199D2.4030606@lindenlab.com> <1182904406.14627.22.camel@localhost> Message-ID: <4682B1F0.7070707@lindenlab.com> Callum Lerwick wrote: > On Tue, 2007-06-26 at 15:57 -0700, Bryan O'Sullivan wrote: >> Callum Lerwick wrote: >>> Argh. Who added -Werror to the build flags? >> What version of gcc are you using? I haven't seen those errors with gcc >> 3.4 through 4.1. > > Those ones in particular are probably more a result of Fedora's glibc. I'm building on Fedora 7, and I don't see these problems. References: <1182896080.14627.3.camel@localhost> <468199D2.4030606@lindenlab.com> <1182904406.14627.22.camel@localhost> <4682B1F0.7070707@lindenlab.com> Message-ID: <1182973288.27151.2.camel@localhost> On Wed, 2007-06-27 at 11:52 -0700, Bryan O'Sullivan wrote: > Callum Lerwick wrote: > > On Tue, 2007-06-26 at 15:57 -0700, Bryan O'Sullivan wrote: > >> Callum Lerwick wrote: > >>> Argh. Who added -Werror to the build flags? > >> What version of gcc are you using? I haven't seen those errors with gcc > >> 3.4 through 4.1. > > > > Those ones in particular are probably more a result of Fedora's glibc. > > I'm building on Fedora 7, and I don't see these problems. Are you using the standard Fedora build flags? In particular, I think its -Wp,-D_FORTIFY_SOURCE=2 doing it. -------------- 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/20070627/3fe2853c/attachment.pgp From lee at lindenlab.com Wed Jun 27 12:44:08 2007 From: lee at lindenlab.com (Lee Linden) Date: Wed Jun 27 12:44:08 2007 Subject: [sldev] Source release for 1.17.2.0 Message-ID: <4682BE08.7010809@lindenlab.com> Hello! A new source release is available. This is an optional viewer. 1.17.2.0 source release available here: https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.2.0 More information here: http://blog.secondlife.com/2007/06/26/release-update-1180-postponed-1172-viewer-pending/ Checksums: 000f766ee6eb45a2a8e572c3826845da slviewer-darwin-libs-1.17.2.0.tar.gz 19f99960fba9856c2da20f05fe263d4c slviewer-linux-libs-1.17.2.0.tar.gz 768dc0b7ff5e2dd2751f363fd6b568b3 slviewer-src-1.17.2.0.tar.gz 942ca9d4da3338a1bb28742a5d04a54c slviewer-artwork-1.17.2.0.zip 67fb10001a1c02e57ed4714896bba791 slviewer-src-1.17.2.0.zip 7e5bcda12c569fbfe3a76461a5bf4edc slviewer-win32-libs-1.17.2.0.zip SVN checkout: http://svn.secondlife.com/svn/linden/release Have fun! --Lee From blakar at gmail.com Wed Jun 27 13:19:58 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Wed Jun 27 13:20:02 2007 Subject: [sldev] OpenJPEG vs KDU In-Reply-To: <46825F67.8090909@dzonux.net> References: <7992d0d60706261639w15e6f338u92ebc7e8426090e0@mail.gmail.com> <1182904268.14627.19.camel@localhost> <7992d0d60706270203l3da1dc81ya8e3053cadcfad49@mail.gmail.com> <46825F67.8090909@dzonux.net> Message-ID: <7992d0d60706271319tfd61f21x83ccb39abc36a0eb@mail.gmail.com> Great, the work of you and Callum combined brings us probably already very close to the target. From LL's point of view it's clear: as soon as OpenJPEG competes on speed with KDU, KDU can be replaced. If Callum posts the current status of his patch we can see where we are in terms of beating KDU. Do you by any chance have already coded up something that calls KDU thru llkdu? I'm not exactly planning to pay 250AU$ to get the library :) Dirk aka Blakar Ogre On 6/27/07, Dzonatas wrote: > Some of the patches have already been applied to the main OpenJPEG > repository. They provide about a 2x speed-up. > > I started work on the Floating Point/SSE and posted the patch here. > Callum has taken over to finish up that code with merges into the T1 > work that was done. > > The Floating Point/SSE, as it was, provided about anywhere from 2x to > 20x speed-up, which set it closely behind KDU. > > I bet that OpenJPEG could be made to go faster than KDU under the > terrible threads conditions (cache pollution) of Second Life. KDU was > not designed to handle such conditions. > > Dirk Moerenhout wrote: > > Have these patches been submitted to the OpenJPEG maintainers? Do you > > think there would be any resistance from them in getting them applied? > > Given I'm located very near to them I wouldn't mind lending a hand > > when it comes to communication. > > > > Where can I get these patches? > > > > Dirk aka Blakar Ogre > > > > On 6/27/07, Callum Lerwick wrote: > >> On Wed, 2007-06-27 at 01:39 +0200, Dirk Moerenhout wrote: > >> > Ok, in light of VWR-866 I'm wondering what it would take for OpenJPEG > >> > to replace KDU. I've heard that KDU would be faster. Anybody has an > >> > idea on how much? I've build OpenJPEG 1.2 with VS2005 and did a quick > >> > check using CodeAnalyst. A few minutes after my first run I got a 0.5% > >> > benefit with 1 minor change. That may sound minor but given the > >> > simplicity of the change I guess some real effort would give us quite > >> > a bit more. > >> > >> I've revived Dzonatas DWT vectorization patch, which results in a > >> significant speedup. Especially combined with my T1 > >> vectorization/cleanup patch which can pass floating point data direct > >> from T1 to DWT. > >> > >> I've got a bunch of patches lined up I really need to finish off and > >> submit... > >> > >> _______________________________________________ > >> 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 nicholaz at blueflash.cc Wed Jun 27 13:47:26 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 13:47:37 2007 Subject: [sldev] compiling 1.17.2 Message-ID: <4682CCDE.6080209@blueflash.cc> If someone needs the missing include files to compile 1.17.2, I have a zip file on http://www.blueflash.cc/users/nicholaz/libs (see readme inside the file) Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From dzonatas at dzonux.net Wed Jun 27 13:49:05 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Wed Jun 27 13:49:00 2007 Subject: [sldev] OpenJPEG vs KDU In-Reply-To: <7992d0d60706271319tfd61f21x83ccb39abc36a0eb@mail.gmail.com> References: <7992d0d60706261639w15e6f338u92ebc7e8426090e0@mail.gmail.com> <1182904268.14627.19.camel@localhost> <7992d0d60706270203l3da1dc81ya8e3053cadcfad49@mail.gmail.com> <46825F67.8090909@dzonux.net> <7992d0d60706271319tfd61f21x83ccb39abc36a0eb@mail.gmail.com> Message-ID: <4682CD41.6090201@dzonux.net> Dirk Moerenhout wrote: > Do you by any chance have already coded up something that calls KDU > thru llkdu? I'm not exactly planning to pay 250AU$ to get the library > :) > Besides the indra source, no. The KDU utilities can be downloaded free, which includes the library. -- Power to Change the Void From gigstaggart at gmail.com Wed Jun 27 13:48:56 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 27 13:49:04 2007 Subject: [sldev] Standardizable classes In-Reply-To: <4681E761.8070201@speakeasy.net> References: <4681E761.8070201@speakeasy.net> Message-ID: <4682CD38.1090007@gmail.com> Alan Grimes wrote: > LLThread -- Provided by SDL which is already a dependency.. Not > sure why we're using APR... (Apache Runtime Library) If we can get rid of APR, all the better, it's not GPL compatible. -Jason From gigstaggart at gmail.com Wed Jun 27 13:53:21 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 27 13:53:30 2007 Subject: [sldev] OpenJPEG vs KDU In-Reply-To: <7992d0d60706271319tfd61f21x83ccb39abc36a0eb@mail.gmail.com> References: <7992d0d60706261639w15e6f338u92ebc7e8426090e0@mail.gmail.com> <1182904268.14627.19.camel@localhost> <7992d0d60706270203l3da1dc81ya8e3053cadcfad49@mail.gmail.com> <46825F67.8090909@dzonux.net> <7992d0d60706271319tfd61f21x83ccb39abc36a0eb@mail.gmail.com> Message-ID: <4682CE41.1070509@gmail.com> Dirk Moerenhout wrote: > Great, the work of you and Callum combined brings us probably already > very close to the target. From LL's point of view it's clear: as soon > as OpenJPEG competes on speed with KDU, KDU can be replaced. If Callum > posts the current status of his patch we can see where we are in terms > of beating KDU. I've been running OpenJPEG-only the last couple releases (with no extra patches), and I can tell you it's like 85% of the way there already. Seriously. KDU is soon to be history if these new patches speed up OpenJPEG even a little bit. Good job Callum and Dzonates! -Jason From nicholaz at blueflash.cc Wed Jun 27 15:13:58 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 15:14:07 2007 Subject: [sldev] VC8 project files for 1.17.2 Message-ID: <4682E126.4010104@blueflash.cc> I just made VC8 files for 1.17.2: https://jira.secondlife.com/browse/VWR-1151 Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From bos at lindenlab.com Wed Jun 27 16:01:17 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Wed Jun 27 16:01:19 2007 Subject: [sldev] Calling Linux / ATI / fglrx users Message-ID: <4682EC3D.9040708@lindenlab.com> If you're using ATI's fglrx driver on Linux, please pay a visit to https://jira.secondlife.com/browse/VWR-1320 and add a comment, to let us know whether or not the bug in question affects you. (In brief, the poster claims that the viewer crashes the X server if it tries to change the shape of the mouse pointer. The fix looks safe, but ugly, but I want to verify that other people can reproduce it.) Thanks, References: <4682BE08.7010809@lindenlab.com> Message-ID: <4682EDA9.60401@gmail.com> Lee Linden wrote: > Hello! > > A new source release is available. This is an optional viewer. > > 1.17.2.0 source release available here: > https://wiki.secondlife.com/wiki/Source_downloads#ver_1.17.2.0 > > More information here: > http://blog.secondlife.com/2007/06/26/release-update-1180-postponed-1172-viewer-pending/ RELEASE_FOR_DOWNLOAD no longer makes a tarball on Linux? Everything seemed to compile OK. From gigstaggart at gmail.com Wed Jun 27 16:16:37 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 27 16:16:58 2007 Subject: [sldev] VWR-1203 (cross eyes) not fixed Message-ID: <4682EFD5.4080803@gmail.com> I don't know if something got reverted, but no fix for VWR-1203 is in 1.17.2. diff ../../../linden.old/indra/llcharacter/llheadrotmotion.cpp llheadrotmotion.cpp (no difference from 17.0.12) There are no changes to llquaternion either that might have fixed it. It looks like it just didn't make it in, contrary to the release notes. -Jason From josh at lindenlab.com Wed Jun 27 16:22:30 2007 From: josh at lindenlab.com (Joshua Bell) Date: Wed Jun 27 16:23:57 2007 Subject: [sldev] VWR-1203 (cross eyes) not fixed In-Reply-To: <4682EFD5.4080803@gmail.com> References: <4682EFD5.4080803@gmail.com> Message-ID: <4682F136.3020509@lindenlab.com> It appears as though one variant of the issue was fixed, but there appear are others. If you can provide further repro steps, please add them to Jira issue. The change was in llhudeffectlookat.cpp; Index: llhudeffectlookat.cpp =================================================================== --- llhudeffectlookat.cpp (revision 64019) +++ llhudeffectlookat.cpp (revision 64020) @@ -456,6 +456,7 @@ { //sets the lookat point in front of the avatar mTargetOffsetGlobal.setVec(5.0, 0.0, 0.0); + local_offset.setVec(mTargetOffsetGlobal); } mTargetPos = avatarp->mHeadp->getWorldPosition(); Jason Giglio wrote: > I don't know if something got reverted, but no fix for VWR-1203 is in > 1.17.2. > > diff ../../../linden.old/indra/llcharacter/llheadrotmotion.cpp > llheadrotmotion.cpp > > (no difference from 17.0.12) > > There are no changes to llquaternion either that might have fixed it. > It looks like it just didn't make it in, contrary to the release notes. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From gigstaggart at gmail.com Wed Jun 27 16:32:10 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 27 16:32:17 2007 Subject: [sldev] VWR-1203 (cross eyes) not fixed In-Reply-To: <4682F136.3020509@lindenlab.com> References: <4682EFD5.4080803@gmail.com> <4682F136.3020509@lindenlab.com> Message-ID: <4682F37A.70607@gmail.com> Joshua Bell wrote: > It appears as though one variant of the issue was fixed, but there > appear are others. If you can provide further repro steps, please add > them to Jira issue. Review the patch I have attached to the issue. The problem was a "vergence" quat in llheadrot that was previously in an unused code path and was always ZERO_ROTATION prior to 1.17. The change that caused this bug enabled the code path, but apparently the code is broken. It looks like the idea was to have the eyes cross some when looking at a close object, but it's buggy. My patch disables the eye vergence code once again. This repro is fine: Beezle Warburton [27/Jun/07 02:57 PM] The way I reproduce this: 1) stand on a posing stand (leave camera facing avatar) 2) alt-click on avatar's forehead. 3) move mouse cursor to right side of screen. -Jason From richard at lindenlab.com Wed Jun 27 16:40:11 2007 From: richard at lindenlab.com (Richard Nelson) Date: Wed Jun 27 16:40:13 2007 Subject: [sldev] VWR-1203 (cross eyes) not fixed In-Reply-To: <4682F37A.70607@gmail.com> References: <4682EFD5.4080803@gmail.com> <4682F136.3020509@lindenlab.com> <4682F37A.70607@gmail.com> Message-ID: The zero rotation vergence was a bug. Not sure when it was introduced, but probably a long time ago, early in Second Life's existence. The fix that was checked in was for the eyes going in different random directions when hover tips (Ctrl-Shift-T) was turned on and you moused over an attachment on your avatar. This would result in your avatar trying to look inside his own head, which would look awkward no matter what. :) My guess is that the behavior you are seeing is related to the angular limit clamping being performed independently on the two eyes, causing them to resolve to opposite directions, but I'll investigate. Richard On Wed, 27 Jun 2007 16:32:10 -0700, Jason Giglio wrote: > Joshua Bell wrote: >> It appears as though one variant of the issue was fixed, but there >> appear are others. If you can provide further repro steps, please add >> them to Jira issue. > > Review the patch I have attached to the issue. The problem was a > "vergence" quat in llheadrot that was previously in an unused code path > and was always ZERO_ROTATION prior to 1.17. > > The change that caused this bug enabled the code path, but apparently > the code is broken. It looks like the idea was to have the eyes cross > some when looking at a close object, but it's buggy. My patch disables > the eye vergence code once again. > > This repro is fine: > > Beezle Warburton [27/Jun/07 02:57 PM] > The way I reproduce this: > > 1) stand on a posing stand (leave camera facing avatar) > 2) alt-click on avatar's forehead. > 3) move mouse cursor to right side of screen. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From gigstaggart at gmail.com Wed Jun 27 16:50:00 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 27 16:50:07 2007 Subject: [sldev] VWR-1203 (cross eyes) not fixed In-Reply-To: References: <4682EFD5.4080803@gmail.com> <4682F136.3020509@lindenlab.com> <4682F37A.70607@gmail.com> Message-ID: <4682F7A8.6050207@gmail.com> Richard Nelson wrote: > The zero rotation vergence was a bug. Not sure when it was introduced, but probably a long time ago, early in Second Life's existence. Yeah, I assumed so. I'm not good enough with rotations to actually fix the vergence code, and I figured that if it's been "broken" this long, people have come to expect the old behavior, and the safest thing to do for a minor point release hotfix is to just revert back to the old way (hence my patch). Since 1.18 is on the plate now, it may be a better time to actually make it work the way the original coder intended. If someone good with rotations can spare the time to explain, how can you have a version of SetQuat that takes a floating point angle and a Vector3 and come out with a single unambiguous answer? It seems to me that would only define a conic section, or if it were axis aligned, two possible orientations. -Jason From nicholaz at blueflash.cc Wed Jun 27 16:51:54 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Wed Jun 27 16:52:02 2007 Subject: [sldev] Quirk in end_net ( net.cpp ) / VWR-1410 Message-ID: <4682F81A.90308@blueflash.cc> Could someone please review that for the Linux part (shutdown() and socket numbers less than zero)? https://jira.secondlife.com/browse/VWR-1410 Nick -- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From richard at lindenlab.com Wed Jun 27 16:59:40 2007 From: richard at lindenlab.com (Richard Nelson) Date: Wed Jun 27 16:59:43 2007 Subject: [sldev] VWR-1203 (cross eyes) not fixed In-Reply-To: <4682F7A8.6050207@gmail.com> References: <4682EFD5.4080803@gmail.com> <4682F136.3020509@lindenlab.com> <4682F37A.70607@gmail.com> <4682F7A8.6050207@gmail.com> Message-ID: It uses the axis angle rotation representation: http://en.wikipedia.org/wiki/Axis_angle On Wed, 27 Jun 2007 16:50:00 -0700, Jason Giglio wrote: > Richard Nelson wrote: >> The zero rotation vergence was a bug. Not sure when it was introduced, but probably a long time ago, early in Second Life's existence. > > Yeah, I assumed so. I'm not good enough with rotations to actually fix > the vergence code, and I figured that if it's been "broken" this long, > people have come to expect the old behavior, and the safest thing to do > for a minor point release hotfix is to just revert back to the old way > (hence my patch). > > Since 1.18 is on the plate now, it may be a better time to actually make > it work the way the original coder intended. > > If someone good with rotations can spare the time to explain, how can > you have a version of SetQuat that takes a floating point angle and a > Vector3 and come out with a single unambiguous answer? > > It seems to me that would only define a conic section, or if it were > axis aligned, two possible orientations. > > > -Jason > From secret.argent at gmail.com Wed Jun 27 17:11:29 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 27 17:11:32 2007 Subject: [sldev] Re: APR In-Reply-To: <20070627232357.B59A741AFA5@stupor.lindenlab.com> References: <20070627232357.B59A741AFA5@stupor.lindenlab.com> Message-ID: > If we can get rid of APR, all the better, it's not GPL compatible. Not being GPL-compatible shouldn't be a problem, because LL includes an exception for FOSS. Being GPL would be a bigger problem for LL. That's going to be more important as GPL3 software starts showing up, since GPL3 isn't GPL2-compatible. :( From dale at daleglass.net Wed Jun 27 17:15:38 2007 From: dale at daleglass.net (dale@daleglass.net) Date: Wed Jun 27 17:15:45 2007 Subject: [sldev] Re: APR In-Reply-To: References: <20070627232357.B59A741AFA5@stupor.lindenlab.com> Message-ID: <20070628001538.GA7597@bruno.sbruno> On Wed, Jun 27, 2007 at 07:11:29PM -0500, Argent Stonecutter wrote: > >If we can get rid of APR, all the better, it's not GPL compatible. > > Not being GPL-compatible shouldn't be a problem, because LL includes > an exception for FOSS. > > Being GPL would be a bigger problem for LL. > > That's going to be more important as GPL3 software starts showing up, > since GPL3 isn't GPL2-compatible. :( I don't see why that is a problem. The contribution agreement in my understanding specifies you're assigning copyright to LL. In that case there's no non-LL-owned code in the source even with contributed patches added, so LL is perfectly free to release new versions under the GPL3 if needed. -------------- 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/20070628/ce5de975/attachment.pgp From richard at lindenlab.com Wed Jun 27 17:17:03 2007 From: richard at lindenlab.com (Richard Nelson) Date: Wed Jun 27 17:17:07 2007 Subject: [sldev] VWR-1203 (cross eyes) not fixed In-Reply-To: <4682F7A8.6050207@gmail.com> References: <4682EFD5.4080803@gmail.com> <4682F136.3020509@lindenlab.com> <4682F37A.70607@gmail.com> <4682F7A8.6050207@gmail.com> Message-ID: So I found a fix that will be in some upcoming release (not sure that it will make 1.18). For those who care, the bug was the result of applying angular constraints to the eyes separately, instead of to the initial target orientation... Index: D:/code/maintenance/indra/llcharacter/llheadrotmotion.cpp =================================================================== --- D:/code/maintenance/indra/llcharacter/llheadrotmotion.cpp (revision 61992) +++ D:/code/maintenance/indra/llcharacter/llheadrotmotion.cpp (revision 64407) @@ -418,6 +418,8 @@ up.setVec(eye_look_at % left); target_eye_rot = LLQuaternion(eye_look_at, left, up); + // constrain target orientation to be in front of avatar's face + target_eye_rot.constrain(EYE_ROT_LIMIT_ANGLE); // calculate vergence F32 interocular_dist = (mLeftEyeState.getJoint()->getWorldPosition() - mRightEyeState.getJoint()->getWorldPosition()).magVec(); @@ -472,13 +474,11 @@ // start with left LLQuaternion tQw = mLeftEyeState.getJoint()->getParent()->getWorldRotation(); LLQuaternion tQh = left_eye_rot * ~tQw; - tQh.constrain(EYE_ROT_LIMIT_ANGLE); mLeftEyeState.setRotation( tQh ); // now do right eye tQw = mRightEyeState.getJoint()->getParent()->getWorldRotation(); tQh = right_eye_rot * ~tQw; - tQh.constrain(EYE_ROT_LIMIT_ANGLE); mRightEyeState.setRotation( tQh ); return TRUE; Richard On Wed, 27 Jun 2007 16:50:00 -0700, Jason Giglio wrote: > Richard Nelson wrote: >> The zero rotation vergence was a bug. Not sure when it was introduced, but probably a long time ago, early in Second Life's existence. > > Yeah, I assumed so. I'm not good enough with rotations to actually fix > the vergence code, and I figured that if it's been "broken" this long, > people have come to expect the old behavior, and the safest thing to do > for a minor point release hotfix is to just revert back to the old way > (hence my patch). > > Since 1.18 is on the plate now, it may be a better time to actually make > it work the way the original coder intended. > > If someone good with rotations can spare the time to explain, how can > you have a version of SetQuat that takes a floating point angle and a > Vector3 and come out with a single unambiguous answer? > > It seems to me that would only define a conic section, or if it were > axis aligned, two possible orientations. > > > -Jason > From secret.argent at gmail.com Wed Jun 27 17:31:58 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Jun 27 17:32:02 2007 Subject: [sldev] Re: APR In-Reply-To: <20070628001538.GA7597@bruno.sbruno> References: <20070627232357.B59A741AFA5@stupor.lindenlab.com> <20070628001538.GA7597@bruno.sbruno> Message-ID: <2DBDC6A6-6CE9-4A54-9C60-623FD563F966@gmail.com> On 27-Jun-2007, at 19:15, dale@daleglass.net wrote: > The contribution agreement in my understanding specifies you're > assigning copyright to LL. In that case there's no non-LL-owned > code in > the source even with contributed patches added, so LL is perfectly > free > to release new versions under the GPL3 if needed. There's two separate issues here. 1: >> Being GPL would be a bigger problem for LL. This is about SL. SL isn't GPL, it's GPL+FOSS exception, and so it's not GPL-compatible itself. 2: >> That's going to be more important as GPL3 software starts showing up, >> since GPL3 isn't GPL2-compatible. :( This isn't about SL, it's about software that incorporates GPL (not LGPL) libraries. From robla at lindenlab.com Wed Jun 27 17:35:42 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Jun 27 17:35:51 2007 Subject: [sldev] Commit mail for svn.secondlife.com Message-ID: <4683025E.9030300@lindenlab.com> Hi everyone, svn.secondlife.com is now wired up to send out commitmail messages whenever new commits are made. Details about the list are here: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits Minor tweaks from stock install: * Diffs under 2000 lines will be emailed. Diffs over 2000 lines won't * Link to corresponding Trac page for all commits (so, for example, you can look at a 2000 line diff if you'd like). Also, there's a fresh snapshot of our "maintenance" branch. It includes the patch that Richard just emailed to this list. 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/20070627/6156fb27/signature-0001.pgp From seg at haxxed.com Wed Jun 27 17:41:46 2007 From: seg at haxxed.com (Callum Lerwick) Date: Wed Jun 27 17:41:11 2007 Subject: [sldev] Re: APR In-Reply-To: References: <20070627232357.B59A741AFA5@stupor.lindenlab.com> Message-ID: <1182991306.27151.5.camel@localhost> On Wed, 2007-06-27 at 19:11 -0500, Argent Stonecutter wrote: > Not being GPL-compatible shouldn't be a problem, because LL includes > an exception for FOSS. Except that still doesn't allow us to link to GPL libraries or merge in any GPL code. (Like the CPU detection stuff from the Linux kernel, for use on non-linux platforms...) -------------- 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/20070627/086a3946/attachment.pgp From gigstaggart at gmail.com Wed Jun 27 18:08:27 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Jun 27 18:08:39 2007 Subject: [sldev] Source release for 1.17.2.0 In-Reply-To: <4682EDA9.60401@gmail.com> References: <4682BE08.7010809@lindenlab.com> <4682EDA9.60401@gmail.com> Message-ID: <46830A0B.4070907@gmail.com> Jason Giglio wrote: > RELEASE_FOR_DOWNLOAD no longer makes a tarball on Linux? Everything > seemed to compile OK. Weird, I ran scons again, and it made the tar file. Looks like the first time around it built everything except the final executable and tar. There were no errors, though. -Jason From secret.argent at gmail.com Thu Jun 28 12:42:29 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Jun 28 12:42:30 2007 Subject: [sldev] Re: APR In-Reply-To: <20070628190008.ABD9B41AFEC@stupor.lindenlab.com> References: <20070628190008.ABD9B41AFEC@stupor.lindenlab.com> Message-ID: <6A785F84-F7EE-41D5-B5DA-79EDA522041E@gmail.com> > On Wed, 2007-06-27 at 19:11 -0500, Argent Stonecutter wrote: >> Not being GPL-compatible shouldn't be a problem, because LL includes >> an exception for FOSS. > Except that still doesn't allow us to link to GPL libraries or > merge in > any GPL code. (Like the CPU detection stuff from the Linux kernel, for > use on non-linux platforms...) That's the point. It's not "GPL-compatible" that's an issue for the SL client, because the FOSS exception makes it non-GPL-compatible itself. This is why GPL libraries are a problem. Especially since GPL3 and GPL2 aren't compatible. The CPU detection stuff, though, isn't a problem. Just create a GPLed command line tool that does CPU detection and reports the result. There's no reason SL has to be linked with a tool like that that's only run once during initialization. From seg at haxxed.com Thu Jun 28 14:19:54 2007 From: seg at haxxed.com (Callum Lerwick) Date: Thu Jun 28 14:19:18 2007 Subject: [sldev] Re: APR In-Reply-To: <6A785F84-F7EE-41D5-B5DA-79EDA522041E@gmail.com> References: <20070628190008.ABD9B41AFEC@stupor.lindenlab.com> <6A785F84-F7EE-41D5-B5DA-79EDA522041E@gmail.com> Message-ID: <1183065594.27151.8.camel@localhost> On Thu, 2007-06-28 at 14:42 -0500, Argent Stonecutter wrote: > That's the point. It's not "GPL-compatible" that's an issue for the > SL client, because the FOSS exception makes it non-GPL-compatible > itself. No, APR is what's GPL incompatible. > This is why GPL libraries are a problem. Especially since GPL3 and > GPL2 aren't compatible. No, GPL-incompatible libraries are a problem. -------------- 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/20070628/8e1f46b9/attachment.pgp From mattk at electricsheepcompany.com Thu Jun 28 14:30:29 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Thu Jun 28 14:30:05 2007 Subject: [sldev] VC8 project files for 1.18.0.3 Message-ID: <46842875.4030207@electricsheepcompany.com> Hey all, I just posted VC8 project files for 1.18.0.3 to https://jira.secondlife.com/browse/VWR-1151 -- as noted in the description, you will also need the PNG-related files that Nicholaz and others have posted. Enjoy! -Matt -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From blakar at gmail.com Thu Jun 28 15:39:26 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Thu Jun 28 15:39:29 2007 Subject: [sldev] Building 18.0.0.3 with VS 2005 Express Message-ID: <7992d0d60706281539p77fd9c10v2912b704fd2a55d3@mail.gmail.com> Anybody had any luck building with VS 2005 Express? For me it always seems to break. It compiles but when I run the errors are rather strange. My releaseNoOpt build crashes in const_reference operator*() const due to an uninitialised pointer. Dirk aka Blakar Ogre From mattk at electricsheepcompany.com Thu Jun 28 15:53:28 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Thu Jun 28 15:53:08 2007 Subject: [sldev] Building 18.0.0.3 with VS 2005 Express In-Reply-To: <7992d0d60706281539p77fd9c10v2912b704fd2a55d3@mail.gmail.com> References: <7992d0d60706281539p77fd9c10v2912b704fd2a55d3@mail.gmail.com> Message-ID: <46843BE8.50403@electricsheepcompany.com> Have you tried clearing out your SL cache? That's often helped me when going from running a release client to running a beta client, and vice versa. -Matt Dirk Moerenhout wrote: > Anybody had any luck building with VS 2005 Express? > > For me it always seems to break. It compiles but when I run the errors > are rather strange. My releaseNoOpt build crashes in const_reference > operator*() const due to an uninitialised pointer. > > Dirk aka Blakar Ogre > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From bos at lindenlab.com Thu Jun 28 16:55:52 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Jun 28 16:55:55 2007 Subject: [sldev] Quirk in end_net ( net.cpp ) / VWR-1410 In-Reply-To: <4682F81A.90308@blueflash.cc> References: <4682F81A.90308@blueflash.cc> Message-ID: <46844A88.8030304@lindenlab.com> Nicholaz Beresford wrote: > Could someone please review that for the Linux part > (shutdown() and socket numbers less than zero)? Looks good, thanks. References: <7992d0d60706281539p77fd9c10v2912b704fd2a55d3@mail.gmail.com> Message-ID: <46844C5A.5010509@dzonux.net> Last timed I tried, it crashed on invalid message templates in LLMessageTemplateBuilder. Dirk Moerenhout wrote: > Anybody had any luck building with VS 2005 Express? > > For me it always seems to break. It compiles but when I run the errors > are rather strange. My releaseNoOpt build crashes in const_reference > operator*() const due to an uninitialised pointer. > > Dirk aka Blakar Ogre > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- Power to Change the Void From bos at lindenlab.com Thu Jun 28 17:05:03 2007 From: bos at lindenlab.com (Bryan O'Sullivan) Date: Thu Jun 28 17:05:08 2007 Subject: [sldev] Linking broken? In-Reply-To: <1182908058.14627.29.camel@localhost> References: <1182907348.14627.25.camel@localhost> <1182908058.14627.29.camel@localhost> Message-ID: <46844CAF.3090309@lindenlab.com> Callum Lerwick wrote: > Okay so its doing this on purpose: > > def create_cond_module(module, module_libs=[]): > if build_target != 'client' or not opensource: > create_static_module(module=module) > else: > create_dynamic_module(module=module, module_libs=module_libs) > > I don't see the reasoning behind this. The llkdu.so shared library needs to be linked against code that is compiled with -fpic. We get away without that happening at the moment on i386, but not on x86_64. This was an excessively cumbersome attempt at getting that working, which I think I can improve on. For those of you with contributor agreements on file, or who plan to file them in the near future: What times are convenient for you for in-world programmer office hours? Please add a line for yourself and add asterisks to available slots. https://wiki.secondlife.com/wiki/User:Soft_Linden/scratch#sldev_Meeting_Times Thanks! From nicholaz at blueflash.cc Thu Jun 28 17:39:11 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Thu Jun 28 17:39:21 2007 Subject: [sldev] Quirk in end_net ( net.cpp ) / VWR-1410 In-Reply-To: <46844A88.8030304@lindenlab.com> References: <4682F81A.90308@blueflash.cc> <46844A88.8030304@lindenlab.com> Message-ID: <468454AF.5000109@blueflash.cc> Bryan O'Sullivan wrote: > Nicholaz Beresford wrote: > >> Could someone please review that for the Linux part >> (shutdown() and socket numbers less than zero)? > > Looks good, thanks. Thanks Bryan! Btw, I have another in the making, one with greetings from refcount hell. Had been looking for that one for a long time now (crash in LLEventPoll destructor) and found that through debugging VWR-1418, so at least 1418 had it's benefit. (Will post that tomorrow, it's 2:30AM here and my brain is already refcount overloaded :-)). Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From able.whitman at gmail.com Thu Jun 28 18:16:31 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 28 18:16:33 2007 Subject: [sldev] Quirk in end_net ( net.cpp ) / VWR-1410 In-Reply-To: <468454AF.5000109@blueflash.cc> References: <4682F81A.90308@blueflash.cc> <46844A88.8030304@lindenlab.com> <468454AF.5000109@blueflash.cc> Message-ID: <7b3a84fb0706281816i38df0259jea242bc2aa601f1c@mail.gmail.com> Oh man, I think I've just been digging into that same crash, Nick. Is this the crash that happens in a call to boost::intrusive_ptr_release(LLHTTPClient::Responder * p=0xfeeefeee), which originates from the LLEventPoll destructor? If it is, let me know if I can do anything to help you out. --Able On 6/28/07, Nicholaz Beresford wrote: > > > Bryan O'Sullivan wrote: > > Nicholaz Beresford wrote: > > > >> Could someone please review that for the Linux part > >> (shutdown() and socket numbers less than zero)? > > > > Looks good, thanks. > > Thanks Bryan! > > Btw, I have another in the making, one with greetings from > refcount hell. > > Had been looking for that one for a long time now (crash in > LLEventPoll destructor) and found that through debugging > VWR-1418, so at least 1418 had it's benefit. (Will post > that tomorrow, it's 2:30AM here and my brain is already > refcount overloaded :-)). > > > Nick > > --- > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070628/2dfb6ee5/attachment-0001.htm From able.whitman at gmail.com Thu Jun 28 19:50:58 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 28 19:51:01 2007 Subject: [sldev] Did the latest sim update change the behavior of RequestMultipleObjects? Message-ID: <7b3a84fb0706281950l75f4f5a6sdcabd48c33006a2f@mail.gmail.com> I noticed that if the viewer issues a RequestMultipleObjects with the LocalID of an object that is not in the agent's current region, it doesn't seem to get an ObjectUpdate (or related) message from the sim, even if CacheMissType is 0 (full update). But if it issues a request for an object that *is* in the current region, it receives an ObjectUpdate as expected. Maybe I'm hallucinating, but I could have sworn that before today's update, requesting an update for any object whose LocalID was known to the viewer would result in it getting an object update, regardless of which region the object was in. Is this a new behavior, or am I just going mad? --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070628/6bd1b93e/attachment.htm From mattk at electricsheepcompany.com Thu Jun 28 20:10:06 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Thu Jun 28 20:09:41 2007 Subject: [sldev] Subtle STL bug in VC8/VS2005 build Message-ID: <4684780E.4080907@electricsheepcompany.com> Hey all, While attempting to revive the "test" project for the VS2005 build (the subject of another thread entirely!), I uncovered a subtle but serious bug that has quite possibly been causing a lot of the crashes that various contributers have seen when building under VS2005. It was fixable with a project-file change, so I've uploaded new versions of the VS2005 project files to https://jira.secondlife.com/browse/VWR-1151 with the fix included. For those interested, here are the technical details, cut and pasted from my comment on the JIRA: "Found a very subtle but global bug caused by a change in behavior between VC7.1's STL implementation and VC8's STL implementation. VC8, by default, checks STL iterators to ensure that they have a back-link to their associated container. If they don't, the program will break (if you're running in the debugger) or crash (if you're not). However, you can still create a containerless iterator by calling the default constructor on an iterator type--and, as it turns out, LLSD::Impl::beginArray() and LLSD::Impl::endArray() do exactly that. This means that if beginArray() or endArray() are called on the "immutableUndefined" LLSD instance returned by LLSD::Impl::undef(), an iterator will be created that will later crash the app. The solution to this is to pre-define the preprocessor symbol _SECURE_SCL to be 0, in the project files. This causes that particular iterator check to be disabled, and the behavior reverts to exactly what it was in VC7.1. With the project files contained in this JIRA issue, the easiest way to do that is to add _SECURE_SCL=0 to the preprocessor definitions in SL-UpgradeFromVC71_vc8.vsprops, so that all projects and all configurations inherit it." Hopefully, this will stabilize the VS2005 build considerably! -Matt -- Matt Kimmel, Software Alchemist The Electric Sheep Company ------------------------------------- Email: mattk@electricsheepcompany.com SL: Feep Larsson From jhurliman at wsu.edu Thu Jun 28 22:24:11 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Jun 28 22:26:26 2007 Subject: [sldev] Did the latest sim update change the behavior of RequestMultipleObjects? In-Reply-To: <7b3a84fb0706281950l75f4f5a6sdcabd48c33006a2f@mail.gmail.com> References: <7b3a84fb0706281950l75f4f5a6sdcabd48c33006a2f@mail.gmail.com> Message-ID: <4684977B.6010607@wsu.edu> Able Whitman wrote: > I noticed that if the viewer issues a RequestMultipleObjects with the > LocalID of an object that is not in the agent's current region, it > doesn't seem to get an ObjectUpdate (or related) message from the sim, > even if CacheMissType is 0 (full update). But if it issues a request > for an object that *is* in the current region, it receives an > ObjectUpdate as expected. > > Maybe I'm hallucinating, but I could have sworn that before today's > update, requesting an update for any object whose LocalID was known to > the viewer would result in it getting an object update, regardless of > which region the object was in. > > Is this a new behavior, or am I just going mad? > > --Able > LocalIDs are local to each simulator, so if object 1000 exists in Simulator B but you send a RequestMultipleObjects to Simulator A asking for object 1000 it will have no idea what you are referring to and silently ignore it. The viewer should be sending that packet to Simulator B and get a reply back from Simulator B. Did something change so requests are going to the wrong simulator, or did I misread your explanation? John From able.whitman at gmail.com Thu Jun 28 22:35:34 2007 From: able.whitman at gmail.com (Able Whitman) Date: Thu Jun 28 22:35:37 2007 Subject: [sldev] Did the latest sim update change the behavior of RequestMultipleObjects? In-Reply-To: <4684977B.6010607@wsu.edu> References: <7b3a84fb0706281950l75f4f5a6sdcabd48c33006a2f@mail.gmail.com> <4684977B.6010607@wsu.edu> Message-ID: <7b3a84fb0706282235s3fd917a8t2ed70280ff389c9@mail.gmail.com> Ah, thanks. I was going crazy after all. It was my code for selecting which host to send the RequestMultipleObjects message to that was broken, due to a bit of code I had commented out when I was debugging something else. ("I won't forget to uncomment that later...") Now I feel dumb, but at least I fixed the problem! Thanks, --Able On 6/29/07, John Hurliman wrote: > > Able Whitman wrote: > > I noticed that if the viewer issues a RequestMultipleObjects with the > > LocalID of an object that is not in the agent's current region, it > > doesn't seem to get an ObjectUpdate (or related) message from the sim, > > even if CacheMissType is 0 (full update). But if it issues a request > > for an object that *is* in the current region, it receives an > > ObjectUpdate as expected. > > > > Maybe I'm hallucinating, but I could have sworn that before today's > > update, requesting an update for any object whose LocalID was known to > > the viewer would result in it getting an object update, regardless of > > which region the object was in. > > > > Is this a new behavior, or am I just going mad? > > > > --Able > > > > LocalIDs are local to each simulator, so if object 1000 exists in > Simulator B but you send a RequestMultipleObjects to Simulator A asking > for object 1000 it will have no idea what you are referring to and > silently ignore it. The viewer should be sending that packet to > Simulator B and get a reply back from Simulator B. Did something change > so requests are going to the wrong simulator, or did I misread your > explanation? > > 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/20070629/987e328e/attachment.htm From seg at haxxed.com Fri Jun 29 00:26:31 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 29 00:25:57 2007 Subject: [sldev] Linking broken? In-Reply-To: <46844CAF.3090309@lindenlab.com> References: <1182907348.14627.25.camel@localhost> <1182908058.14627.29.camel@localhost> <46844CAF.3090309@lindenlab.com> Message-ID: <1183101991.27151.12.camel@localhost> On Thu, 2007-06-28 at 17:05 -0700, Bryan O'Sullivan wrote: > The llkdu.so shared library needs to be linked against code that is > compiled with -fpic. We get away without that happening at the moment > on i386, but not on x86_64. This was an excessively cumbersome attempt > at getting that working, which I think I can improve on. Hmmm, well I'm not using KDU anyway. A "standalone" build would seem to imply that. Splitting out internals to libraries complicates packaging, I'd prefer to avoid it. -------------- 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/20070629/b447c8fc/attachment.pgp From nicholaz at blueflash.cc Fri Jun 29 02:16:56 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 29 02:17:09 2007 Subject: [sldev] Re: [offlist] Quirk in end_net ( net.cpp ) / VWR-1410 In-Reply-To: <7b3a84fb0706281816i38df0259jea242bc2aa601f1c@mail.gmail.com> References: <4682F81A.90308@blueflash.cc> <46844A88.8030304@lindenlab.com> <468454AF.5000109@blueflash.cc> <7b3a84fb0706281816i38df0259jea242bc2aa601f1c@mail.gmail.com> Message-ID: <4684CE08.3000509@blueflash.cc> Able Whitman wrote: > Oh man, I think I've just been digging into that same crash, Nick. Is > this the crash that happens in a call to > boost::intrusive_ptr_release(LLHTTPClient::Responder * p=0xfeeefeee), > which originates from the LLEventPoll destructor? > > If it is, let me know if I can do anything to help you out. Yes, it is that one. I have it already, I just don't know the best way to fix it yet. Let me know if you want the details upfront. Were you able to reproduce it? If you want details upfront, it's a nice riddle/puzzle (I just had it one of 10 times with the new leak enabled in one area). Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From nicholaz at blueflash.cc Fri Jun 29 03:43:27 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 29 03:43:43 2007 Subject: [sldev] Subtle STL bug in VC8/VS2005 build In-Reply-To: <4684780E.4080907@electricsheepcompany.com> References: <4684780E.4080907@electricsheepcompany.com> Message-ID: <4684E24F.3060503@blueflash.cc> Good catch (although so far I have not run into this bug from my occasional use) Very good to see someone who is actually using these files taking care of them. Nick Matt Kimmel wrote: > Hey all, > > While attempting to revive the "test" project for the VS2005 build (the > subject of another thread entirely!), I uncovered a subtle but serious > bug that has quite possibly been causing a lot of the crashes that > various contributers have seen when building under VS2005. > > It was fixable with a project-file change, so I've uploaded new versions > of the VS2005 project files to > https://jira.secondlife.com/browse/VWR-1151 with the fix included. > From nicholaz at blueflash.cc Fri Jun 29 06:13:33 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 29 06:13:50 2007 Subject: [sldev] Possible crash in llviewerregion / eventpoll / boost_ptr ... VWR-1436 Message-ID: <4685057D.7040008@blueflash.cc> Here's a nice one from refcount-hell. It could definitely use some peer-review. See comments on the issue. https://jira.secondlife.com/browse/VWR-1436 Nick From dzonatas at dzonux.net Fri Jun 29 07:18:21 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jun 29 07:18:24 2007 Subject: [sldev] Repros discovered for previous triage items, MISC-285 & VWR-895 Message-ID: <468514AD.8050409@dzonux.net> We've discovered repros for two items that were on triage before: (comments are on issues) https://jira.secondlife.com/browse/MISC-285 (internal permission bug related or script/notecard text doesn't actually appear when it should) MISC-285 was repro'd when full mod rights were granted to me. I tried to view the notecards.. nada.. but they really do have content. https://jira.secondlife.com/browse/VWR-895 (repro'd by multi-prim objects) VWR-895 is easy to reproduce with multi-prim texture selection in a certain placement. Create two prims side by side along the X axis. Select them both and shift-move them (duplicate) then to +10 Y. Select all 4 prims, and shift-move to duplicate them and snap them back them into original location. With the new 4 prims (8 total), rotate them 90 degrees so that now you have a square formed by all prims 8 prims. Like: ## # # # # ## Select all prims. From the texture picker, apply a texture immediately to all prims. You'll notice that at least two faces don't change. Here is what is interesting, unselect all prims except for those two prims that didn't fully change. Try to immediately apply the texture again, and you'll notice it still reverts back. -- Power to Change the Void From able.whitman at gmail.com Fri Jun 29 07:43:34 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 29 07:43:36 2007 Subject: [sldev] Re: [offlist] Quirk in end_net ( net.cpp ) / VWR-1410 In-Reply-To: <4684CE08.3000509@blueflash.cc> References: <4682F81A.90308@blueflash.cc> <46844A88.8030304@lindenlab.com> <468454AF.5000109@blueflash.cc> <7b3a84fb0706281816i38df0259jea242bc2aa601f1c@mail.gmail.com> <4684CE08.3000509@blueflash.cc> Message-ID: <7b3a84fb0706290743q77fa5bffh2bd2abc9ccf68776@mail.gmail.com> Honestly, my investigation into this bug has only gotten far enough to get a fairly-reliable repro. (It was aggrivating to no end trying to figure out what was going on when I only hit the crash occasionally.) Like you found, I saw that the crash only happened when LLEventPoll::Impl::error() was called with an HTTP error code other than 499. I can't repro it 100% but my most reliable (about 90% of the time) repro is this: 1. start the viewer under the debugger (F5) 2. login to the main grid 3. once logged in, press Ctrl+M to open the map 4. while the map is still rendering, Break All into the application ( i.e., pause debugging) 5. wait for 2 minutes or so - waiting less than 2 minutes doesn't reliably trigger the bug 6. continue the application - at this point you'll probably be getting lots of "unknown circuit" warnings in the debug console 7. press Ctrl+Q to quit the viewer The repro above ususally results in an error in the debug log like this: "". Which indicates that the error() method has called the stop() method before the LLEventPoll destructor is called, causing the crash. When you resume the viewer in step 6, pretty quickly you'll see a couple of debug messages like this: WARNING: sendMessage - Trying to send AgentUpdate on unknown circuit 64.129.45.197:13004 WARNING: LLEventPoll::Impl::error: <1> got 404: Not Found Once you see the 404 error from error(), you're golden, because you will crash. Hopefeully this is helpful. --Able On 6/29/07, Nicholaz Beresford wrote: > > > > Able Whitman wrote: > > Oh man, I think I've just been digging into that same crash, Nick. Is > > this the crash that happens in a call to > > boost::intrusive_ptr_release(LLHTTPClient::Responder * p=0xfeeefeee), > > which originates from the LLEventPoll destructor? > > > > If it is, let me know if I can do anything to help you out. > > Yes, it is that one. I have it already, I just don't know > the best way to fix it yet. Let me know if you want the > details upfront. > > Were you able to reproduce it? > > If you want details upfront, it's a nice riddle/puzzle (I just > had it one of 10 times with the new leak enabled in one area). > > > Nick > > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070629/ae158b7d/attachment.htm From dzonatas at dzonux.net Fri Jun 29 07:57:40 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jun 29 07:57:29 2007 Subject: MISC-285 & broken content -- Re: [sldev] Repros discovered for previous triage items, MISC-285 & VWR-895 In-Reply-To: <468514AD.8050409@dzonux.net> References: <468514AD.8050409@dzonux.net> Message-ID: <46851DE4.6010108@dzonux.net> Hopefully, I wasn't to subtle about MISC-285. I've noticed others who've had many objects not working for them anymore... Ad Space boards, Contests boards... etc. They spent a lot of money. It appears related. Dzonatas wrote: > > We've discovered repros for two items that were on triage before: > (comments are on issues) > > https://jira.secondlife.com/browse/MISC-285 (internal permission bug > related or script/notecard text doesn't actually appear when it should) > > MISC-285 was repro'd when full mod rights were granted to me. I tried > to view the notecards.. nada.. but they really do have content. > > > https://jira.secondlife.com/browse/VWR-895 (repro'd by multi-prim > objects) > > VWR-895 is easy to reproduce with multi-prim texture selection in a > certain placement. Create two prims side by side along the X axis. > Select them both and shift-move them (duplicate) then to +10 Y. Select > all 4 prims, and shift-move to duplicate them and snap them back them > into original location. With the new 4 prims (8 total), rotate them 90 > degrees so that now you have a square formed by all prims 8 prims. > > Like: > > ## > # # > # # > ## > > > Select all prims. From the texture picker, apply a texture immediately > to all prims. You'll notice that at least two faces don't change. Here > is what is interesting, unselect all prims except for those two prims > that didn't fully change. Try to immediately apply the texture again, > and you'll notice it still reverts back. > -- Power to Change the Void From nicholaz at blueflash.cc Fri Jun 29 08:12:11 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 29 08:12:33 2007 Subject: [sldev] Re: [offlist] Quirk in end_net ( net.cpp ) / VWR-1410 In-Reply-To: <7b3a84fb0706290743q77fa5bffh2bd2abc9ccf68776@mail.gmail.com> References: <4682F81A.90308@blueflash.cc> <46844A88.8030304@lindenlab.com> <468454AF.5000109@blueflash.cc> <7b3a84fb0706281816i38df0259jea242bc2aa601f1c@mail.gmail.com> <4684CE08.3000509@blueflash.cc> <7b3a84fb0706290743q77fa5bffh2bd2abc9ccf68776@mail.gmail.com> Message-ID: <4685214B.1050304@blueflash.cc> Able Whitman wrote: > Honestly, my investigation into this bug has only gotten far enough to > get a fairly-reliable repro. (It was aggrivating to no end trying to > figure out what was going on when I only hit the crash occasionally.) > > Like you found, I saw that the crash only happened when > LLEventPoll::Impl::error() was called with an HTTP error code other than > 499. I can't repro it 100% but my most reliable (about 90% of the time) > repro is this: Dang ... with a repro I would have found this much earlier. I had just seen it from post mortem crashes and couldn't figure out what it was (I suspected it was free'd memory but through the tricky implementation missed the stop() function in error()). Guess I'll send a list of my other crime scenes here shortly in case someone can provide parts of the puzzle. Nick From blakar at gmail.com Fri Jun 29 09:55:25 2007 From: blakar at gmail.com (Dirk Moerenhout) Date: Fri Jun 29 09:55:31 2007 Subject: [sldev] Subtle STL bug in VC8/VS2005 build In-Reply-To: <4684780E.4080907@electricsheepcompany.com> References: <4684780E.4080907@electricsheepcompany.com> Message-ID: <7992d0d60706290955y73b0df57hf2af656db5718130@mail.gmail.com> > Hopefully, this will stabilize the VS2005 build considerably! Confirmed! My strange problems were likely all related to this as I was crashing in either STL code or code related to things done via STL. A new build of releasenoopt worked just fine, building a releasefordownload now but I don't doubt it'll work too. Thanks a lot! Dirk aka Blakar Ogre From robla at lindenlab.com Fri Jun 29 10:08:19 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Jun 29 10:08:35 2007 Subject: [sldev] Special office hour today: Friday, 3pm, Sculpties! Message-ID: <46853C83.2050102@lindenlab.com> Hi folks, I messed up in coordinating my office hour shift with Qarl. So, we're going to go ahead and hold one last office hour at Grasmere at 3pm to specifically talk about Sculpties. See Qarl's email below for details about what we'll be talking about. Info on office hour can be found here: https://wiki.secondlife.com/wiki/User:Rob_Linden Rob -------- Original Message -------- Subject: [sldev] sculpties announcements Date: Tue, 26 Jun 2007 13:58:37 -0700 From: Karl Stiefvater To: sldev@lists.secondlife.com hey all - i've got a few sculptie announcements, for those who might be interested in such things: 1. Dr. Dobbs will be hosting a daylong sculptie party on their island July 7. I'll be speaking (typing?) in the first panel. There should be lot's of fun sculptie experiments and toys and tools and camaraderie. I'll send more information as it becomes available. 2. I'm drumming-up support for an open-source/community-development project for the sculpties. The basic jist is: you guys rock, if possible we should continue the rockage. Details here: https://wiki.secondlife.com/wiki/Sculptie_Dev I'll also be coming to Rob Linden's office hours this Friday to discuss this and other sculptie fun. 3. I've released a new version of the sculptie exporter - it now makes some effort to reassemble entire maya scenes (and automatically bakes lighting.) Available here (much thanks to Dzonatas for the wiki clean-up.) http://wiki.secondlife.com/wiki/Advanced_Sculptie_Exporter_From_Maya best, K. _______________________________________________ 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/20070629/af333879/signature.pgp From nicholaz at blueflash.cc Fri Jun 29 10:25:27 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 29 10:25:39 2007 Subject: [sldev] Finding memory leaks in VS2005 Message-ID: <46854087.7010209@blueflash.cc> Based on a suggestion from Bryan I added my patch and knowledge about finding memory leaks to the wiki and the contrib box: https://wiki.secondlife.com/wiki/Finding_leaks Feel free to explore, expand or discuss there. Nick From nicholaz at blueflash.cc Fri Jun 29 10:35:27 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Fri Jun 29 10:35:32 2007 Subject: [sldev] Finding memory leaks in VS2003 In-Reply-To: <46854087.7010209@blueflash.cc> References: <46854087.7010209@blueflash.cc> Message-ID: <468542DF.50804@blueflash.cc> Umm, of course the subject should be VS2003, I'm not sure if Debug builds work under VS2005 (see Able's recents posts about this). Nick Nicholaz Beresford wrote: > > Based on a suggestion from Bryan I added my patch and knowledge about > finding memory leaks to the wiki and the contrib box: > https://wiki.secondlife.com/wiki/Finding_leaks > > Feel free to explore, expand or discuss there. > > > > Nick > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From able.whitman at gmail.com Fri Jun 29 10:39:06 2007 From: able.whitman at gmail.com (Able Whitman) Date: Fri Jun 29 10:39:07 2007 Subject: [sldev] Finding memory leaks in VS2003 In-Reply-To: <468542DF.50804@blueflash.cc> References: <46854087.7010209@blueflash.cc> <468542DF.50804@blueflash.cc> Message-ID: <7b3a84fb0706291039g4847d6r9d4cc851a2f7f132@mail.gmail.com> As a quick update, I have not been able to successfully build a VS8 Debug configuration for the 1.17.2.0 release, either. It could be that there is a simple fix, but a debug build takes so long on my poor machine that I just haven't taken the time to get to the root of the problem. I've been making due with a ReleaseNoOpt build for my own development, which unfortunately isn't suitable for leak finding. --Able On 6/29/07, Nicholaz Beresford wrote: > > > Umm, of course the subject should be VS2003, I'm not sure > if Debug builds work under VS2005 (see Able's recents posts > about this). > > > Nick > > > > Nicholaz Beresford wrote: > > > > Based on a suggestion from Bryan I added my patch and knowledge about > > finding memory leaks to the wiki and the contrib box: > > https://wiki.secondlife.com/wiki/Finding_leaks > > > > Feel free to explore, expand or discuss there. > > > > > > > > Nick > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070629/4b803a33/attachment-0001.htm From secret.argent at gmail.com Fri Jun 29 12:49:02 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Fri Jun 29 12:49:04 2007 Subject: [sldev] Re: APR In-Reply-To: <20070629011637.1E78B41AFF7@stupor.lindenlab.com> References: <20070629011637.1E78B41AFF7@stupor.lindenlab.com> Message-ID: > On Thu, 2007-06-28 at 14:42 -0500, Argent Stonecutter wrote: >> That's the point. It's not "GPL-compatible" that's an issue for the >> SL client, because the FOSS exception makes it non-GPL-compatible >> itself. > No, APR is what's GPL incompatible. I'm not sure what your point is, because I didn't say APR was GPL compatible. From labrat.hb at gmail.com Fri Jun 29 13:24:40 2007 From: labrat.hb at gmail.com (Harold Brown) Date: Fri Jun 29 13:24:42 2007 Subject: [sldev] Re: APR In-Reply-To: References: <20070629011637.1E78B41AFF7@stupor.lindenlab.com> Message-ID: resending this as I didn't send it to the list I believe the gist of the matter is that APR is one of the reasons the client has to have the FOSS exception. If all the libraries used were GPL compatible, then there would be no need for the exception. On 6/29/07, Argent Stonecutter wrote: > > > On Thu, 2007-06-28 at 14:42 -0500, Argent Stonecutter wrote: > >> That's the point. It's not "GPL-compatible" that's an issue for the > >> SL client, because the FOSS exception makes it non-GPL-compatible > >> itself. > > > No, APR is what's GPL incompatible. > > I'm not sure what your point is, because I didn't say APR was GPL > compatible. > _______________________________________________ > 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/20070629/6e212250/attachment.htm From monkowsk at watson.ibm.com Fri Jun 29 13:51:10 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Jun 29 13:50:41 2007 Subject: [sldev] Opening the server source? In-Reply-To: <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> Message-ID: <468570BE.4090707@watson.ibm.com> Chance Unknown wrote: > Putting on a Linden Hat : Why would I open source that item that is > generating me lots of cash? I know that my cash cow island owners would > be flirting with another hosting company if I did that. So open source > my sim software??? mmmmmmm nah. Remember that the server side is more than just sim servers. Those sim servers require investment in hardware and maintenence. That is expense. That is a major scalability problem. Suppose LL allowed private sims that were virtually connected to the main grid, but still required the standard LL login to get the database services. Users logged on to both the private sims and the main grid would see a seamless connection. Users on the main grid, not logged on to the private sims would see a locked door, that would be opened by logging on to the private sim. Without logging on to the main grid, the private sim would be essentially inoperable. So LL makes its money by charging for access to the database servers. If you take away the cost of the sim server, the access charge can be significantly less, but the profit can remain the same. It's a matter of separating the physics and scripting functions from the rest and applying proper security to messaging. OK, so it's probably not that easy, but you get the idea. LL gets a benefit because it gets subscribers without having to host the whole thing. Private hosts get the benefit of minimal lag, privacy for confidential information, and the ability to customize the behavior of their worlds. It's really a question of what business LL wants to engage in. I don't think their goal is to manage more and more server farms, because their focus would have seen a support staff that scales with the size of the farms. That doesn't seem to be the case. Mike From adam at gwala.net Fri Jun 29 13:57:52 2007 From: adam at gwala.net (Adam Frisby) Date: Fri Jun 29 13:58:34 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468570BE.4090707@watson.ibm.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> Message-ID: <46857250.6010703@gwala.net> The key here however is that LL wants to be ready to accept outside servers before they enable it. Right now the server is extremely trusted - everything occurs on the server. Money handling, etc is just a few of the things that could be exploited. Kelly's email from earlier is really worth looking at for the reasons as to why LL wont be opening the sim any time soon (however I dont doubt it will happen, just probably not in the next 12 months.) Adam Mike Monkowski wrote: > Chance Unknown wrote: > >> Putting on a Linden Hat : Why would I open source that item that is >> generating me lots of cash? I know that my cash cow island owners >> would be flirting with another hosting company if I did that. So open >> source my sim software??? mmmmmmm nah. > > > Remember that the server side is more than just sim servers. Those sim > servers require investment in hardware and maintenence. That is > expense. That is a major scalability problem. > > Suppose LL allowed private sims that were virtually connected to the > main grid, but still required the standard LL login to get the database > services. Users logged on to both the private sims and the main grid > would see a seamless connection. Users on the main grid, not logged on > to the private sims would see a locked door, that would be opened by > logging on to the private sim. > > Without logging on to the main grid, the private sim would be > essentially inoperable. So LL makes its money by charging for access to > the database servers. If you take away the cost of the sim server, the > access charge can be significantly less, but the profit can remain the > same. > > It's a matter of separating the physics and scripting functions from the > rest and applying proper security to messaging. OK, so it's probably > not that easy, but you get the idea. > > LL gets a benefit because it gets subscribers without having to host the > whole thing. Private hosts get the benefit of minimal lag, privacy for > confidential information, and the ability to customize the behavior of > their worlds. > > It's really a question of what business LL wants to engage in. I don't > think their goal is to manage more and more server farms, because their > focus would have seen a support staff that scales with the size of the > farms. That doesn't seem to be the case. > > Mike > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dale at daleglass.net Fri Jun 29 14:11:45 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Jun 29 14:12:31 2007 Subject: [sldev] Why is scons ignoring the configured compiler for linking? Message-ID: <46857591.5080907@daleglass.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I'm having a problem building 17.2 here. I run a 64 bit Gentoo box, but build the viewer as a 32 bit binary to get sound. My only changes to SConstruct are removing -Werror (build fails on gcc4), and changing gcc_bin to g++32. Problem: scons ignores the chosen compiler when linking. This worked perfectly fine before, but now I've got a pretty strange problem. The build goes like this: g++32 -g -pipe -Wall -Wno-trigraphs -Wno-sign-compare -falign-loops=16 - -fno-math-errno -fexceptions -fsigned-char -fno-strict-aliasing - -ffast-math -DLL_MESA_HEADLESS=0 -DLL_MESA=0 -DLL_LINUX=1 - -DAPPID=secondlife -DLL_SDL=1 -DLL_X11=1 -DLL_GTK=1 - -DLL_LIBXUL_ENABLED=1 -DNDEBUG -DLL_RELEASE=1 -Illcommon -Illmath - -Illwindow -Illaudio -Illcharacter -Illdatabase -Illhavok -Illimage - -Illinventory -Illmedia -Illmessage -Illprimitive -Illrender -Illscene - -Illui -Illvfs -Illwindow -Illxml -Ilscript - -I/home/dale/svk/buildfixes/libraries/include - -I/home/dale/svk/buildfixes/libraries/include/havok - -I/home/dale/svk/buildfixes/libraries/i686-linux/include - -I/home/dale/svk/buildfixes/libraries/i686-linux/include/ELFIO - -I/home/dale/svk/buildfixes/libraries/i686-linux/include/atk-1.0 - -I/home/dale/svk/buildfixes/libraries/i686-linux/include/glib-2.0 - -I/home/dale/svk/buildfixes/libraries/i686-linux/include/gtk-2.0 - -I/home/dale/svk/buildfixes/libraries/i686-linux/include/llfreetype2 - -I/home/dale/svk/buildfixes/libraries/i686-linux/include/pango-1.0 -c - -o /home/dale/tmp/home/dale/svk/buildfixes/indra/i686-linux-client-releasenoopt/llui/llviewquery.o /home/dale/tmp/home/dale/svk/buildfixes/indra/i686-linux-client-releasenoopt/llui/llviewquery.cpp gcc --no-keep-memory --reduce-memory-overheads -shared -o lib_releasenoopt_client/i686-linux/libllkdu.so - -Llib_releasenoopt_client/i686-linux - -L/home/dale/svk/buildfixes/libraries/i686-linux/lib_release_client - -lllimage -lllvfs -lllmath -lllcommon -lapr-1 -lkdu_v42R /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible lib_releasenoopt_client/i686-linux/libllimage.so when searching for -lllimage /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible lib_releasenoopt_client/i686-linux/libllimage.a when searching for -lllimage /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lllimage collect2: ld returned 1 exit status scons: *** [lib_releasenoopt_client/i686-linux/libllkdu.so] Error 1 scons: building terminated because of errors. Notice the "gcc --no-keep-memory" one. But "gcc" doesn't appear *anywhere* in SConstruct. Not only that, but it should be calling g++32, as that's what gcc_bin is set to: gcc_bin = 'g++32' # some code snipped compiler = gcc_bin compiler_no_distcc = compiler if enable_distcc: compiler = 'distcc ' + gcc_bin # some code snipped base_env = Environment(CXX = compiler, CPPPATH = include_dirs, LIBPATH = lib_path, LINKFLAGS = system_link_flags + '--no-keep-memory - --reduce-memory-overheads ' ) As an alternative to setting the compiler, building a 32 bit binary can be easily done by adding a -m32 argument to GCC, which finally got the thing to build properly. Anybody knows why is it it ignoring the chosen compiler there? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGhXWKqzdyv8vqDKgRCkQiAKCMZvX6aROhUGXK9X8p8xFYZPPU2QCfaosW bakRMjtsVo9ezDFrA9qGzgI= =fCg5 -----END PGP SIGNATURE----- From seg at haxxed.com Fri Jun 29 14:15:47 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Jun 29 14:15:15 2007 Subject: [sldev] Re: [offlist] Quirk in end_net ( net.cpp ) / VWR-1410 In-Reply-To: <7b3a84fb0706290743q77fa5bffh2bd2abc9ccf68776@mail.gmail.com> References: <4682F81A.90308@blueflash.cc> <46844A88.8030304@lindenlab.com> <468454AF.5000109@blueflash.cc> <7b3a84fb0706281816i38df0259jea242bc2aa601f1c@mail.gmail.com> <4684CE08.3000509@blueflash.cc> <7b3a84fb0706290743q77fa5bffh2bd2abc9ccf68776@mail.gmail.com> Message-ID: <1183151747.23676.4.camel@localhost> On Fri, 2007-06-29 at 10:43 -0400, Able Whitman wrote: > Honestly, my investigation into this bug has only gotten far enough to > get a fairly-reliable repro. (It was aggrivating to no end trying to > figure out what was going on when I only hit the crash occasionally.) > > Like you found, I saw that the crash only happened when > LLEventPoll::Impl::error() was called with an HTTP error code other > than 499. I can't repro it 100% but my most reliable (about 90% of the > time) repro is this: I've seen this one when running under valgrind. In fact, that seems to trigger all kinds of weirdness. How about this one: 2007-06-28T07:51:01Z WARNING: LLCircuitData::checkCircuitTimeout for 66.150.244.151:12036 last ping 1875.67 seconds ago. 2007-06-28T07:51:02Z WARNING: LLCircuitData::checkCircuitTimeout for 66.150.244.151:12036 still dead, dropping. 2007-06-28T07:51:02Z INFO: LLCircuit::removeCircuitData for 66.150.244.151:12036 2007-06-28T07:51:02Z WARNING: LLCircuitData::checkCircuitTimeout for 63.210.158.164:13005 last ping 1881.9 seconds ago. 2007-06-28T07:51:03Z WARNING: LLCircuitData::checkCircuitTimeout for 63.210.158.164:13005 still dead, dropping. 2007-06-28T07:51:03Z INFO: LLCircuit::removeCircuitData for 63.210.158.164:13005 2007-06-28T07:51:03Z INFO: abortTransfer: Aborting transfer 02e82c41-07bf-aa08-9c52-6cbd935ac17f from 63.210.158.164:13005 2007-06-28T07:51:04Z WARNING: sendMessage - Trying to send TransferAbort on unknown circuit 63.210.158.164:13005 2007-06-28T07:51:05Z WARNING: completionCallback: Aborting vfile transfer for 587d044e-fbf3-a3f0-78d5-2aa3af3a29a2 ==1113== Invalid write of size 4 ==1113== at 0x1473368: LLAssetStorage::downloadCompleteCallback(int, LLUUID const&, LLAssetType::EType, void*) (lluuid.h:217) ==1113== by 0x14B9822: LLTransferTargetVFile::completionCallback(e_status_codes) (lltransfertargetvfile.cpp:218) ==1113== by 0x14B2E18: LLTransferTarget::abortTransfer() (lltransfermanager.cpp:1239) ==1113== by 0x14B2EE8: LLTransferTargetChannel::~LLTransferTargetChannel() (lltransfermanager.cpp:940) ==1113== by 0x14B22DE: LLTransferConnection::~LLTransferConnection() (lltransfermanager.cpp:670) ==1113== by 0x14B1C7C: LLTransferManager::cleanupConnection(LLHost const&) (lltransfermanager.cpp:126) ==1113== by 0x147E6A0: LLCircuitData::~LLCircuitData() (llcircuit.cpp:129) ==1113== by 0x147F228: LLCircuit::removeCircuitData(LLHost const&) (llcircuit.cpp:477) ==1113== by 0x147F4CF: LLCircuit::updateWatchDogTimers(LLMessageSystem*) (llcircuit.cpp:827) ==1113== by 0x14D8E1C: LLMessageSystem::processAcks() (message.cpp:1836) ==1113== by 0x1202EEC: idle_network() (viewer.cpp:3488) ==1113== by 0x1204569: idle() (viewer.cpp:3720) ==1113== Address 0x12CFF9D0 is not stack'd, malloc'd or (recently) free'd ==1113== ==1113== Invalid write of size 4 ==1113== at 0x1473370: LLAssetStorage::downloadCompleteCallback(int, LLUUID const&, LLAssetType::EType, void*) (lluuid.h:218) ==1113== by 0x14B9822: LLTransferTargetVFile::completionCallback(e_status_codes) (lltransfertargetvfile.cpp:218) ==1113== by 0x14B2E18: LLTransferTarget::abortTransfer() (lltransfermanager.cpp:1239) ==1113== by 0x14B2EE8: LLTransferTargetChannel::~LLTransferTargetChannel() (lltransfermanager.cpp:940) ==1113== by 0x14B22DE: LLTransferConnection::~LLTransferConnection() (lltransfermanager.cpp:670) ==1113== by 0x14B1C7C: LLTransferManager::cleanupConnection(LLHost const&) (lltransfermanager.cpp:126) ==1113== by 0x147E6A0: LLCircuitData::~LLCircuitData() (llcircuit.cpp:129) ==1113== by 0x147F228: LLCircuit::removeCircuitData(LLHost const&) (llcircuit.cpp:477) ==1113== by 0x147F4CF: LLCircuit::updateWatchDogTimers(LLMessageSystem*) (llcircuit.cpp:827) ==1113== by 0x14D8E1C: LLMessageSystem::processAcks() (message.cpp:1836) ==1113== by 0x1202EEC: idle_network() (viewer.cpp:3488) ==1113== by 0x1204569: idle() (viewer.cpp:3720) ==1113== Address 0x12CFF9D4 is not stack'd, malloc'd or (recently) free'd ==1113== ==1113== Invalid write of size 4 ==1113== at 0x1473377: LLAssetStorage::downloadCompleteCallback(int, LLUUID const&, LLAssetType::EType, void*) (lluuid.h:219) ==1113== by 0x14B9822: LLTransferTargetVFile::completionCallback(e_status_codes) (lltransfertargetvfile.cpp:218) ==1113== by 0x14B2E18: LLTransferTarget::abortTransfer() (lltransfermanager.cpp:1239) ==1113== by 0x14B2EE8: LLTransferTargetChannel::~LLTransferTargetChannel() (lltransfermanager.cpp:940) ==1113== by 0x14B22DE: LLTransferConnection::~LLTransferConnection() (lltransfermanager.cpp:670) ==1113== by 0x14B1C7C: LLTransferManager::cleanupConnection(LLHost const&) (lltransfermanager.cpp:126) ==1113== by 0x147E6A0: LLCircuitData::~LLCircuitData() (llcircuit.cpp:129) ==1113== by 0x147F228: LLCircuit::removeCircuitData(LLHost const&) (llcircuit.cpp:477) ==1113== by 0x147F4CF: LLCircuit::updateWatchDogTimers(LLMessageSystem*) (llcircuit.cpp:827) ==1113== by 0x14D8E1C: LLMessageSystem::processAcks() (message.cpp:1836) ==1113== by 0x1202EEC: idle_network() (viewer.cpp:3488) ==1113== by 0x1204569: idle() (viewer.cpp:3720) ==1113== Address 0x12CFF9D8 is not stack'd, malloc'd or (recently) free'd ==1113== ==1113== Invalid write of size 4 ==1113== at 0x147337E: LLAssetStorage::downloadCompleteCallback(int, LLUUID const&, LLAssetType::EType, void*) (lluuid.h:220) ==1113== by 0x14B9822: LLTransferTargetVFile::completionCallback(e_status_codes) (lltransfertargetvfile.cpp:218) ==1113== by 0x14B2E18: LLTransferTarget::abortTransfer() (lltransfermanager.cpp:1239) ==1113== by 0x14B2EE8: LLTransferTargetChannel::~LLTransferTargetChannel() (lltransfermanager.cpp:940) ==1113== by 0x14B22DE: LLTransferConnection::~LLTransferConnection() (lltransfermanager.cpp:670) ==1113== by 0x14B1C7C: LLTransferManager::cleanupConnection(LLHost const&) (lltransfermanager.cpp:126) ==1113== by 0x147E6A0: LLCircuitData::~LLCircuitData() (llcircuit.cpp:129) ==1113== by 0x147F228: LLCircuit::removeCircuitData(LLHost const&) (llcircuit.cpp:477) ==1113== by 0x147F4CF: LLCircuit::updateWatchDogTimers(LLMessageSystem*) (llcircuit.cpp:827) ==1113== by 0x14D8E1C: LLMessageSystem::processAcks() (message.cpp:1836) ==1113== by 0x1202EEC: idle_network() (viewer.cpp:3488) ==1113== by 0x1204569: idle() (viewer.cpp:3720) ==1113== Address 0x12CFF9DC is not stack'd, malloc'd or (recently) free'd ==1113== ==1113== Invalid write of size 4 ==1113== at 0x1473385: LLAssetStorage::downloadCompleteCallback(int, LLUUID const&, LLAssetType::EType, void*) (llassetstorage.h:97) ==1113== by 0x14B9822: LLTransferTargetVFile::completionCallback(e_status_codes) (lltransfertargetvfile.cpp:218) ==1113== by 0x14B2E18: LLTransferTarget::abortTransfer() (lltransfermanager.cpp:1239) ==1113== by 0x14B2EE8: LLTransferTargetChannel::~LLTransferTargetChannel() (lltransfermanager.cpp:940) ==1113== by 0x14B22DE: LLTransferConnection::~LLTransferConnection() (lltransfermanager.cpp:670) ==1113== by 0x14B1C7C: LLTransferManager::cleanupConnection(LLHost const&) (lltransfermanager.cpp:126) ==1113== by 0x147E6A0: LLCircuitData::~LLCircuitData() (llcircuit.cpp:129) ==1113== by 0x147F228: LLCircuit::removeCircuitData(LLHost const&) (llcircuit.cpp:477) ==1113== by 0x147F4CF: LLCircuit::updateWatchDogTimers(LLMessageSystem*) (llcircuit.cpp:827) ==1113== by 0x14D8E1C: LLMessageSystem::processAcks() (message.cpp:1836) ==1113== by 0x1202EEC: idle_network() (viewer.cpp:3488) ==1113== by 0x1204569: idle() (viewer.cpp:3720) ==1113== Address 0x12CFF9E0 is not stack'd, malloc'd or (recently) free'd 2007-06-28T07:51:13Z INFO: abortTransfer: Aborting transfer 9c68f818-f82d-f68f-5a60-2eb1be28fde7 from 63.210.158.164:13005 2007-06-28T07:51:14Z WARNING: sendMessage - Trying to send TransferAbort on unknown circuit 63.210.158.164:13005 2007-06-28T07:51:14Z WARNING: completionCallback: Aborting vfile transfer for bab3f6f0-24f7-9c43-3a37-b60a975e7fc0 2007-06-28T07:51:15Z INFO: dumpReceiveCounts: Dump: 1 messages processed in 16.0437 seconds 2007-06-28T07:51:15Z WARNING: sendMessage - Trying to send AgentAnimation on unknown circuit 63.210.158.164:13005 2007-06-28T07:51:18Z WARNING: sendMessage - Trying to send ViewerEffect on unknown circuit 63.210.158.164:13005 2007-06-28T07:51:31Z WARNING: sendMessage - Trying to send RequestImage on unknown circuit 63.210.158.164:13005 2007-06-28T07:51:31Z WARNING: sendMessage - Trying to send AgentUpdate on unknown circuit 63.210.158.164:13005 2007-06-28T07:51:31Z WARNING: checkMessages: Packet from invalid circuit 63.210.158.164:13005 2007-06-28T07:51:31Z WARNING: checkMessages: Packet from invalid circuit 63.210.158.164:13005 -------------- 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/20070629/da0af7e6/attachment-0001.pgp From monkowsk at watson.ibm.com Fri Jun 29 14:27:10 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Jun 29 14:26:36 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46857250.6010703@gwala.net> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> Message-ID: <4685792E.3070504@watson.ibm.com> Adam Frisby wrote: > The key here however is that LL wants to be ready to accept outside > servers before they enable it. Right now the server is extremely trusted > - everything occurs on the server. Money handling, etc is just a few of > the things that could be exploited. That's the point I was trying to make. It doesn't happen on "the" server, it happens on several types of servers: login server, userserver, dataserver, simulator, central backbone, agent database, central database, search database, map server, and RPC server. I don't know who gets the message stream from the viewer, but if it is the simuator, then just split that functionality out into a message server owned by LL. Let the viewer send two message streams. Tell the sim server only what it needs to know to keep track of agents, objects, and scripts. If the sim needs to communicate with other sims, it can go through the message server. The sim need be only a physics engine. How dangerous can physics be? :-) > Kelly's email from earlier is really worth looking at for the reasons as > to why LL wont be opening the sim any time soon (however I dont doubt it > will happen, just probably not in the next 12 months.) Yeah, I read that, but thought the other side of the discussion needed a few more words. Mike From dzonatas at dzonux.net Fri Jun 29 14:37:27 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jun 29 14:37:18 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4685792E.3070504@watson.ibm.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> Message-ID: <46857B97.3020001@dzonux.net> Mike Monkowski wrote: > Adam Frisby wrote: >> Kelly's email from earlier is really worth looking at for the reasons >> as to why LL wont be opening the sim any time soon (however I dont >> doubt it will happen, just probably not in the next 12 months.) > > Yeah, I read that, but thought the other side of the discussion needed > a few more words. No doubt that when the servers are hosted outside of LL's gridmonkeys reach that rapid development will change pace. This doesn't imply that it will stay that way, but it will be a another leap on the moon. -- Power to Change the Void From odysseus654 at gmail.com Fri Jun 29 14:38:28 2007 From: odysseus654 at gmail.com (Erik Anderson) Date: Fri Jun 29 14:38:29 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4685792E.3070504@watson.ibm.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> Message-ID: <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> >From what I understand, this kind of "dual connection" has already been in the works for some time. I read something somewhere (don't remember where at the moment) where inventory and other stuff would be moved off onto an "agent server" that maintained information for the client for the life of the connection. This would reduce the impact and instabilities of boundary crossing, which currently requires the sim to box up all the agent information and send it to the new sim. So from my understanding the sim is currently the sole authoritative communications pathway with the client, but there is some work underway to split them as you describe. On 6/29/07, Mike Monkowski wrote: > > Adam Frisby wrote: > > The key here however is that LL wants to be ready to accept outside > > servers before they enable it. Right now the server is extremely trusted > > - everything occurs on the server. Money handling, etc is just a few of > > the things that could be exploited. > > That's the point I was trying to make. It doesn't happen on "the" > server, it happens on several types of servers: login server, > userserver, dataserver, simulator, central backbone, agent database, > central database, search database, map server, and RPC server. > > I don't know who gets the message stream from the viewer, but if it is > the simuator, then just split that functionality out into a message > server owned by LL. Let the viewer send two message streams. Tell the > sim server only what it needs to know to keep track of agents, objects, > and scripts. If the sim needs to communicate with other sims, it can go > through the message server. The sim need be only a physics engine. How > dangerous can physics be? :-) > > > Kelly's email from earlier is really worth looking at for the reasons as > > to why LL wont be opening the sim any time soon (however I dont doubt it > > will happen, just probably not in the next 12 months.) > > Yeah, I read that, but thought the other side of the discussion needed a > few more words. > > Mike > _______________________________________________ > 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/20070629/754503fe/attachment.htm From adam at gwala.net Fri Jun 29 14:47:25 2007 From: adam at gwala.net (Adam Frisby) Date: Fri Jun 29 14:48:13 2007 Subject: [sldev] Opening the server source? In-Reply-To: <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> Message-ID: <46857DED.10702@gwala.net> Sort of. From my understanding of it (and I really do need to attend Zero's office hours one of these days), LL will be breaking things up as follows: ---TODAY--- Client -> Login Server (Initial Sim IP) Client -> Simulator Simulator -> L$ Server Simulator -> Inventory Server Simulator -> User servers etc.. Simulator -> Asset servers ---THE MYSTERIOUS FUTURE--- Client -> Simulator -- Simulator Transactions, Movement, Building, etc. Client->Inventory Server->Client->Simulator Client->L$ Server->Simulator->Client etc. Where the client becomes authoritive and contacts the specialised servers directly. Essentially in this fashion, Sims can do whatever the hell they like, and be unable to touch a users account as all the messaging for this is directly to/from the client itself. Adam Erik Anderson wrote: > >From what I understand, this kind of "dual connection" has already > been in the works for some time. I read something somewhere (don't > remember where at the moment) where inventory and other stuff would be > moved off onto an "agent server" that maintained information for the > client for the life of the connection. This would reduce the impact and > instabilities of boundary crossing, which currently requires the sim to > box up all the agent information and send it to the new sim. > > So from my understanding the sim is currently the sole authoritative > communications pathway with the client, but there is some work underway > to split them as you describe. > > On 6/29/07, *Mike Monkowski* > wrote: > > Adam Frisby wrote: > > The key here however is that LL wants to be ready to accept outside > > servers before they enable it. Right now the server is extremely > trusted > > - everything occurs on the server. Money handling, etc is just a > few of > > the things that could be exploited. > > That's the point I was trying to make. It doesn't happen on "the" > server, it happens on several types of servers: login server, > userserver, dataserver, simulator, central backbone, agent database, > central database, search database, map server, and RPC server. > > I don't know who gets the message stream from the viewer, but if it is > the simuator, then just split that functionality out into a message > server owned by LL. Let the viewer send two message streams. Tell the > sim server only what it needs to know to keep track of agents, objects, > and scripts. If the sim needs to communicate with other sims, it > can go > through the message server. The sim need be only a physics engine. How > dangerous can physics be? :-) > > > Kelly's email from earlier is really worth looking at for the > reasons as > > to why LL wont be opening the sim any time soon (however I dont > doubt it > > will happen, just probably not in the next 12 months.) > > Yeah, I read that, but thought the other side of the discussion needed a > few more words. > > Mike > _______________________________________________ > 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 monkowsk at watson.ibm.com Fri Jun 29 15:43:41 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Fri Jun 29 15:43:09 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46857DED.10702@gwala.net> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> <46857DED.10702@gwala.net> Message-ID: <46858B1D.10907@watson.ibm.com> Actually, I was suggesting something between these two. By breaking the sim into a message server and a physics server, you don't have to change the rest of the architecture. The viewer sees no change. The specialty servers see no change. One box is just split into two with the rest of the connections remaining intact. It should be a lot easier to implement. Mike Adam Frisby wrote: > Sort of. > > From my understanding of it (and I really do need to attend Zero's > office hours one of these days), LL will be breaking things up as follows: > > ---TODAY--- > > Client -> Login Server (Initial Sim IP) > Client -> Simulator > > Simulator -> L$ Server > Simulator -> Inventory Server > Simulator -> User servers > etc.. > Simulator -> Asset servers > > ---THE MYSTERIOUS FUTURE--- > > Client -> Simulator -- Simulator Transactions, Movement, Building, etc. > > Client->Inventory Server->Client->Simulator > Client->L$ Server->Simulator->Client > etc. > > Where the client becomes authoritive and contacts the specialised > servers directly. > > Essentially in this fashion, Sims can do whatever the hell they like, > and be unable to touch a users account as all the messaging for this is > directly to/from the client itself. > > Adam From adam at gwala.net Fri Jun 29 15:59:12 2007 From: adam at gwala.net (Adam Frisby) Date: Fri Jun 29 15:59:54 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46858B1D.10907@watson.ibm.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <46857250.6010703@gwala.net> <4685792E.3070504@watson.ibm.com> <1674f6c70706291438k51090dbdt7f2c78793cb5c931@mail.gmail.com> <46857DED.10702@gwala.net> <46858B1D.10907@watson.ibm.com> Message-ID: <46858EC0.7070309@gwala.net> Not quite, Most of these messages are still running through the old UDP packet system (and probably will be for a while until CAPS is solidified), having a server manage connections for the client strikes me as somewhat unneeded complexity since all it is doing is proxying the connections; which could be served better by having specialised per-service proxies. Adam Mike Monkowski wrote: > Actually, I was suggesting something between these two. By breaking the > sim into a message server and a physics server, you don't have to change > the rest of the architecture. The viewer sees no change. The specialty > servers see no change. One box is just split into two with the rest of > the connections remaining intact. It should be a lot easier to implement. > > Mike > > Adam Frisby wrote: > >> Sort of. >> >> From my understanding of it (and I really do need to attend Zero's >> office hours one of these days), LL will be breaking things up as >> follows: >> >> ---TODAY--- >> >> Client -> Login Server (Initial Sim IP) >> Client -> Simulator >> >> Simulator -> L$ Server >> Simulator -> Inventory Server >> Simulator -> User servers >> etc.. >> Simulator -> Asset servers >> >> ---THE MYSTERIOUS FUTURE--- >> >> Client -> Simulator -- Simulator Transactions, Movement, Building, etc. >> >> Client->Inventory Server->Client->Simulator >> Client->L$ Server->Simulator->Client >> etc. >> >> Where the client becomes authoritive and contacts the specialised >> servers directly. >> >> Essentially in this fashion, Sims can do whatever the hell they like, >> and be unable to touch a users account as all the messaging for this >> is directly to/from the client itself. >> >> Adam > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From adam at gwala.net Fri Jun 29 16:02:49 2007 From: adam at gwala.net (Adam Frisby) Date: Fri Jun 29 16:03:29 2007 Subject: [sldev] CAPS, UDP Packets, et al. Message-ID: <46858F99.7070007@gwala.net> Quick question (but probably not so quick an answer) - Is there a list of the UDP packets outthere which are to be obsoleted by CAPS (and bonus question, is there specifications for the CAPS interfaces floating around?) - I know the libsl wiki has a bit of information on this, but I'd like to know if there's any formal documentation or specifications from LL? Final question - when does the new HTTP asset download mechanism get enabled? Thanks, Adam From gigstaggart at gmail.com Fri Jun 29 17:21:18 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 29 17:21:28 2007 Subject: MISC-285 & broken content -- Re: [sldev] Repros discovered for previous triage items, MISC-285 & VWR-895 In-Reply-To: <46851DE4.6010108@dzonux.net> References: <468514AD.8050409@dzonux.net> <46851DE4.6010108@dzonux.net> Message-ID: <4685A1FE.3080804@gmail.com> Dzonatas wrote: > Hopefully, I wasn't to subtle about MISC-285. > > I've noticed others who've had many objects not working for them > anymore... Ad Space boards, Contests boards... etc. They spent a lot of > money. It appears related. My wife had a simple "inventory giver" that wouldn't work right when people bought it. I looked at the script and it was completely straightforward touch-give LSL. It was working previously in other versions. Something very weird is going on. -Jason From gigstaggart at gmail.com Fri Jun 29 17:30:30 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 29 17:30:39 2007 Subject: [sldev] Opening the server source? In-Reply-To: <468570BE.4090707@watson.ibm.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> Message-ID: <4685A426.7070809@gmail.com> Mike Monkowski wrote: > LL gets a benefit because it gets subscribers without having to host the > whole thing. Private hosts get the benefit of minimal lag, privacy for > confidential information, and the ability to customize the behavior of > their worlds. > > It's really a question of what business LL wants to engage in. I don't > think their goal is to manage more and more server farms, because their For $6700 per server + $1180 per month per server, I think they are quite happy hosting server farms. Any sort of open grid is going to decimate the market for linden land. To put it in perspective, if you were LL you'd need about 150-200 new premium accounts for each server you don't host, to make up the difference. And those accounts would use the bits of the service they are having the most trouble scaling well. Not to mention, sims probably couldn't handle assets directly like they do now, since that would give sim owners super-copybot-powers, the ability to grab perfect copies, including script binaries. That would put even more load on the centralized resources, since the sims can't be trusted anymore. -Jason From gigstaggart at gmail.com Fri Jun 29 17:33:32 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 29 17:33:42 2007 Subject: [sldev] Re: [offlist] Quirk in end_net ( net.cpp ) / VWR-1410 In-Reply-To: <1183151747.23676.4.camel@localhost> References: <4682F81A.90308@blueflash.cc> <46844A88.8030304@lindenlab.com> <468454AF.5000109@blueflash.cc> <7b3a84fb0706281816i38df0259jea242bc2aa601f1c@mail.gmail.com> <4684CE08.3000509@blueflash.cc> <7b3a84fb0706290743q77fa5bffh2bd2abc9ccf68776@mail.gmail.com> <1183151747.23676.4.camel@localhost> Message-ID: <4685A4DC.5030404@gmail.com> Callum Lerwick wrote: > I've seen this one when running under valgrind. In fact, that seems to > trigger all kinds of weirdness. > > How about this one: Looks like you were trying to open a notecard you didn't have permission to open? That bit of the code does need some work, on the server side too. Do you have any tips to get SL running under valgrind? How are you doing it? -Jason From adam at gwala.net Fri Jun 29 18:20:40 2007 From: adam at gwala.net (Adam Frisby) Date: Fri Jun 29 18:21:25 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4685A426.7070809@gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> Message-ID: <4685AFE8.5030202@gwala.net> This is going off on a bit of a tangent from the original discussion, but nonetheless is probably rather important background. I suspect LL may look in on this but not actually comment any further. -- This is really up to Linden Lab. It's a case of quantity vs quality of customers. LL's going to sell a lot more "regions" if they charge a connection fee of $5/month and hosters can come in. As a very quick example, I was able to get over a thousand regions running on a single server using an experimental lightweight version of OpenSim - obviously that isnt a practical real world example, but it does show that the "per sqm" pricing model is fundementally flawed compared to the real costs of hosting. The actual costs of hosting a region are going to come down to things like "What does this region cost to support - how many can run per server in this configuration, etc" - and most of this is going to end up very consumer focused like the web hosting industry is today. Now, the economic argument is in favour of opening the grid for one very fundemental reason - if LL doesnt do it, someone else eventually will. LL doesnt have any patents or similar covering the idea of a virtual world and their feature set is not unclonable. In 18 months, by the time that LL is ready to open the grid to third parties, there will be competitors around and active. Smaller competitors also have the advantage of smaller loads and knowledge of where things fall apart from the get-go. Most of us know the names already - the two from China, the one from Australia, et cetera. All of them are in alpha or beta now, but in a year and a half - they will be public - one of them will be bound to make the decision to allow third party hosting, and that will bring significant investment into them as large companies are able to control their regions to a degree not possible with LL hosting as it is today. See MTV or Wells Fargo for that demand. Never underestimate the power of commercial investment to spur development either - see the early life of Apache for a great example. Yes, this will be massively disruptive to the land industry - I know quite well (being the second largest 'landholder' inworld afaik), but I'm also a realist - even despite the disruption, the end result will be that Second Life grows far, far in excess of it's bounds today, and if it doesnt happen, someone else will do it, and will benefit from the growth. LL is moving towards being the ICANN of the 3D Virtual World - likely what they will sell will be region handles on the main grid, and the ability for your users to connect into it from other gridded servers. LL will probably also sell things in addition, like asset storage space, etc. Obviously LL will need to rethink what they host in terms of a cost argument (It may end up being that you pick a 'account host' as well as a 'land host' where the account host stores your assets for a fee, are advertising supported, or supported through their own hosting service) By shifting the load onto third party servers and distributing things, a lot of these load arguments also vanish due to economic imperitives - want to provide a reliable service or lower bandwidth bills? setup your own asset caches closer to your servers, etc. LL's real chokepoints that I can see in the long term will be things like: * Unlimited free inventory storage - this just isnt practical (and has been showing signs of this for the last two years) * Unlimited free asset storage * etc LL's benefits are: * Massive benefits for consulting / services "We invented the darn thing!" * Classed as a premium host (Know the platform, where scaling is needed, can roll out custom features faster & easier) * Fundementally control the grid and can charge outsiders for a connection (thus ensuring a better margin and competitors) * No need to manage certain scalability elements as third parties manage their own. Lots of things like grid region handle resolution can be scaled in the same way the DNS system has been scaled - economic imperitive and highly distributed load. From a developer perspective there's a lot to be gained as well, customised simulators done to specific tasks (eg viewing realtime scientific data in collaboration with other people) - the Croquet project is a fantastic proof of concept for things that will be possible, but the two fundemental questions for opening the grid are - a) Can Linden Lab Profit long-term from this? b) Can SL grow, or even survive without third parties long-term? Taking a 5-10 year look, I dont see SL surviving the "fad" stage without it, it may simmer, but it eventually will cool unless it becomes a standard -- ActiveWorlds these days has around 20 or so concurrent users because there hasnt been much interest in the platform, nor practical uses. Adam Jason Giglio wrote: > Mike Monkowski wrote: > >> LL gets a benefit because it gets subscribers without having to host >> the whole thing. Private hosts get the benefit of minimal lag, >> privacy for confidential information, and the ability to customize the >> behavior of their worlds. >> >> It's really a question of what business LL wants to engage in. I >> don't think their goal is to manage more and more server farms, >> because their > > > For $6700 per server + $1180 per month per server, I think they are > quite happy hosting server farms. > > Any sort of open grid is going to decimate the market for linden land. > > To put it in perspective, if you were LL you'd need about 150-200 new > premium accounts for each server you don't host, to make up the difference. > > And those accounts would use the bits of the service they are having the > most trouble scaling well. > > Not to mention, sims probably couldn't handle assets directly like they > do now, since that would give sim owners super-copybot-powers, the > ability to grab perfect copies, including script binaries. That would > put even more load on the centralized resources, since the sims can't be > trusted anymore. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dzonatas at dzonux.net Fri Jun 29 20:21:32 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Fri Jun 29 20:21:19 2007 Subject: Why settle for a small limited sim, when... Re: [sldev] Opening the server source? In-Reply-To: <4685AFE8.5030202@gwala.net> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> <4685AFE8.5030202@gwala.net> Message-ID: <4685CC3C.3010106@dzonux.net> Adam Frisby wrote: > LL is moving towards being the ICANN of the 3D Virtual World - likely > what they will sell will be region handles on the main grid, and the > ability for your users to connect into it from other gridded servers. > LL will probably also sell things in addition, like asset storage > space, etc. In in side note, IBM confirms plans to finish the worlds first petaflop supercomputer. Sun, who has taken a little more interest in in Second Life, announced plans to reveal a 2-3 petaflop computer. On the bleeding edge, researchers have announced that at least a half petaflop is now possible at the size of your chip on your desktop. Hmm. I believe my hint that they kinda held back from the public about computational power trends in modern technology is right on the money. =) -- Power to Change the Void From tateru.nino at gmail.com Fri Jun 29 23:17:07 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri Jun 29 23:17:14 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4685A426.7070809@gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> Message-ID: <4685F563.8040909@gmail.com> Jason Giglio wrote: > Mike Monkowski wrote: >> LL gets a benefit because it gets subscribers without having to host >> the whole thing. Private hosts get the benefit of minimal lag, >> privacy for confidential information, and the ability to customize >> the behavior of their worlds. >> >> It's really a question of what business LL wants to engage in. I >> don't think their goal is to manage more and more server farms, >> because their > > Not to mention, sims probably couldn't handle assets directly like > they do now, since that would give sim owners super-copybot-powers, > the ability to grab perfect copies, including script binaries. That > would put even more load on the centralized resources, since the sims > can't be trusted anymore. That's not really preventable, that I can see, and is something we sort of assumed would be the case from the announcement in 2005 that the sim software would be open sourced sometime in the future. Whoever owns the hardware owns whatever's going on on that hardware. Your rezzed objects and scripts, your textures. They can read your IMs and your chat. Just as you trust the girls and guys who run your ISP, even though they have as much acccess to your web-browsing habits, email and suchlike as they care to (probably, along with your CC details, depending on how you pay). Yet.... we trust people. Mostly, we trust them to not be interested enough in us to do us harm. If I ran a sim on my own hardware, would you trust me to behave? What about xXxXxblackdeathcyberbotXxXxXxXx Hax and his server? Which would you feel more comfortable visiting? -- Tateru Nino http://dwellonit.blogspot.com/ From gigstaggart at gmail.com Fri Jun 29 23:21:44 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Jun 29 23:21:54 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4685F563.8040909@gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> <4685F563.8040909@gmail.com> Message-ID: <4685F678.4080804@gmail.com> Tateru Nino wrote: > Whoever owns the hardware owns whatever's going on on that hardware. > Your rezzed objects and scripts, your textures. They can read your IMs If only it were that simple. Without some serious centralization, you don't need to merely trust your sim hosting provider, you need to trust EVERY sim hosting provider. Unless you plan on selling your neat objects only to people on your own hosting service, and not allowing them to ever change providers, which would kinda suck. -Jason From tateru.nino at gmail.com Sat Jun 30 00:12:34 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat Jun 30 00:12:41 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4685F678.4080804@gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> <4685F563.8040909@gmail.com> <4685F678.4080804@gmail.com> Message-ID: <46860262.6050801@gmail.com> Jason Giglio wrote: > Tateru Nino wrote: >> Whoever owns the hardware owns whatever's going on on that hardware. >> Your rezzed objects and scripts, your textures. They can read your IMs > > If only it were that simple. Without some serious centralization, you > don't need to merely trust your sim hosting provider, you need to > trust EVERY sim hosting provider. > > Unless you plan on selling your neat objects only to people on your > own hosting service, and not allowing them to ever change providers, > which would kinda suck. Ah, yes. Sorry - I didn't mean to trivialise the amount of work required to migrate the grid from an every-sim-is-totally-trustworthy to a sims-cannot-necessarily-be-trusted position. Just saying that even once that is done, you, the avatar must still trust the person who is running the hardware. -- Tateru Nino http://dwellonit.blogspot.com/ From gigstaggart at gmail.com Sat Jun 30 00:40:24 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Jun 30 00:40:34 2007 Subject: [sldev] Free coverity scan? Message-ID: <468608E8.9020401@gmail.com> Coverity has been giving out free static analysis to some open source projects. I'm sure the SL client could use it, considering the number of null pointer crash patches lately. :) http://scan.coverity.com/devfaq.html So who wants to be the "official contact" to approach Coverity about it? -Jason From nicholaz at blueflash.cc Sat Jun 30 01:57:21 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 30 01:57:30 2007 Subject: [sldev] Free coverity scan? In-Reply-To: <468608E8.9020401@gmail.com> References: <468608E8.9020401@gmail.com> Message-ID: <46861AF1.8060701@blueflash.cc> They look pretty much Linux oriented I guess. Dunno if they will be able to handle my visual studio project files :-) Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Jason Giglio wrote: > Coverity has been giving out free static analysis to some open source > projects. > > I'm sure the SL client could use it, considering the number of null > pointer crash patches lately. :) > > http://scan.coverity.com/devfaq.html > > So who wants to be the "official contact" to approach Coverity about it? > > -Jason > _______________________________________________ > 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 Sat Jun 30 02:08:31 2007 From: matthew.dowd at hotmail.co.uk (Matthew Dowd) Date: Sat Jun 30 02:08:33 2007 Subject: [sldev] Opening the server source? Message-ID: > LL is moving towards being the ICANN of the 3D Virtual World - likely > what they will sell will be region handles on the main grid, and the > ability for your users to connect into it from other gridded servers. LL > will probably also sell things in addition, like asset storage space, etc. As has been pointed out, allowing thirdparties to connect their own sims could result in massive growth of the Grid and put additional pressure on precisely the services which are currently suffering scalability/reliability/performance problems (the asset servers, the search servers, etc.), and this would be a major issue for LL aspirations to be the ICANN of a 3D web. The more components that LL release to the commnuity the less work you'd have to do to run your own Grid. I am sure that as soon as LL release the sim source code, the OpenSIM community would start work on an opensource asset server etc. I think third party SL grids are inevitable (the OpenSIM community will get there sooner or later in any case). One model is that LL runs the main Grid, with these thirdparty grids being just small, enthusiast Grids (although I suspect we'd see a lot of University research projects running these in anycase, which could loose LL some of its current publicity). However, someone will mod the client so that it can import/export full mod objects between Grids, someone will mod the client so that it can simultaneously connect to a second grid to do searchesin, IMs, map look ups etc. someone will mod the client so that logging in/out between Grids is as transparent to a user as a teleport, etc. If would only take, say Microsoft deciding to run their own Grid to demonstrate the performance of MS SQL (that it can run a 3D world asset server with good performance even with transactions enabled), or Disney, or Maxis, or Google or Playboy etc. to decide to run their own Grids, and we would begin to see the emergence of a MetaGrid. At this point someone like Anshe Chung would set up an inter-Grid financial Exchange. Within the MetaGrid which Grid you spent time on, or connected your sim to would be a mixture of cost, level of reliability, level of service, rules of conduct etc. unfortunately things which LL has been struggling with a little recently. At this point LL's Grid has to be highly competitive to survive, and it seriously faces the same fate of other Technology pioneers such as Netscape, Lycos etc. Would this scenario happen - I don't know, but there are no real major leaps of faith there - it is a real possibility, and one I'm sure LL would be taking seriously in its internal discussions on open sourcing the Sim code, whilst aware that the activities of the OpenSim community could still bring this scenario to pass regardless of whether LL open sources its own code or not! Matthew _________________________________________________________________ 100?s of Music vouchers to be won with MSN Music https://www.musicmashup.co.uk/index.html From nicholaz at blueflash.cc Sat Jun 30 02:28:37 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 30 02:28:53 2007 Subject: [sldev] Opening the server source? In-Reply-To: References: Message-ID: <46862245.3030903@blueflash.cc> Matthew Dowd wrote: > and it seriously faces the same fate of other Technology pioneers > such as Netscape, Lycos etc. Does anyone remember AOL and CompuServe from the pre-WWW days? They were quite similar to what LL does today. In their time they were able to build large proprietary network services which were successful but were closed worlds. The rest is history, AOL was able to adjust and open to the outside changes and open standards and became a major player by the new rules. CompuServe didn't. I really doubt that the 3D web will be based on SL technology. Not anymore than WWW is based on Gopher. It's proprietary and too complex to become a spread-like-wildfire phenomena. CompuServe/AOL were both big, no doubt about it, but these explosive quantum leap like acceptances of technology require different ingredients. Nick --- Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ From seg at haxxed.com Sat Jun 30 02:40:32 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Jun 30 02:40:49 2007 Subject: [sldev] Re: [offlist] Quirk in end_net ( net.cpp ) / VWR-1410 In-Reply-To: <4685A4DC.5030404@gmail.com> References: <4682F81A.90308@blueflash.cc> <46844A88.8030304@lindenlab.com> <468454AF.5000109@blueflash.cc> <7b3a84fb0706281816i38df0259jea242bc2aa601f1c@mail.gmail.com> <4684CE08.3000509@blueflash.cc> <7b3a84fb0706290743q77fa5bffh2bd2abc9ccf68776@mail.gmail.com> <1183151747.23676.4.camel@localhost> <4685A4DC.5030404@gmail.com> Message-ID: <1183196432.2965.14.camel@localhost> On Fri, 2007-06-29 at 20:33 -0400, Jason Giglio wrote: > Looks like you were trying to open a notecard you didn't have permission > to open? That bit of the code does need some work, on the server side too. Don't think so. Connections tend to time out a lot due to the slowness, which triggers all kinds of interesting edge cases. I'm too busy with OpenJPEG at the moment to go debug them myself though... > Do you have any tips to get SL running under valgrind? How are you > doing it? Well, to have any chance, you have connect normally, make yourself a platform way up in the empty sky with nothing around you, and disconnect while standing on it. (One of those empty water sims might work too...) Then run slviewer under valgrind and you just might get connected before it all times out. And use a fast-ish machine. My wife's Athlon 64 3000+ laptop is just barely fast enough it seems. Also you might want to use --undef-value-errors=no, as otherwise you get a lot of spurious crap from the OpenGL drivers. And a lot of crap from curl and such too, those should probably get fixed... -------------- 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/20070630/0d7514ce/attachment.pgp From tom at cornish-pasty.com Sat Jun 30 05:47:57 2007 From: tom at cornish-pasty.com (Thomas Rowland) Date: Sat Jun 30 05:48:04 2007 Subject: [sldev] Debug build of 1.17.2.0 in vc 2005 (Express) Message-ID: <001101c7bb14$e4732580$21071f52@tomhome> Yey, I got it to build, link and connect to the grid (but I had to disable llmozlib, which won't help anybody), and it is a bit of a work around too. The first problem. ytab.h is not generated. I worked around this by building the releasenoopt lscript_compile, which generated (a version of) the file. I have not worked out why generation of ytab.h breaks in the debug conf. Then the linking errors. change newview properties Linker\Input\Ignore Specific Library to: msvcrtd;libcd.lib;msvcrt;libcmt (add ;msvcrt;libcmt) Alas I was not able to get the debug or release versions of llmozlib-vc80.lib to link, so disabled it: linden\indra\llcommon\llpreprocessor.h @ line 59 --59: #define LL_LIBXUL_ENABLED 1 ++59: #define LL_LIBXUL_ENABLED 0 Just for info. the errors are posted below. using llmozlib-vc80.lib in debug libs folder; llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLMozLib::enableCookies(bool)" ( ?enableCookies@LLMozLib@@QAE_N_N@Z) referenced in function "public: virtual void __thiscall LLPanelWeb::refresh(void)" ( ?refresh@LLPanelWeb@@UAEXXZ) llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLMozLib::clearAllCookies(void)" ( ?clearAllCookies@LLMozLib@@QAE_NXZ) referenced in function "private: static void __cdecl LLPanelWeb::callback_clear_cookies(int,void *)" ( ?callback_clear_cookies@LLPanelWeb@@CAXHPAX@Z) llstartup.obj : error LNK2019: unresolved external symbol "public: bool __thiscall LLMozLib::init(class std::basic_string,class std::allocator >,class std::basic_string,class std::allocator >,class std::basic_string,class std::allocator >)" ( ?init@LLMozLib@@QAE_NV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2 @@std@@00@Z) referenced in function "int __cdecl idle_startup(void)" ( ?idle_startup@@YAHXZ) llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: unresolved external symbol __invalid_parameter_noinfo referenced in function "public: class std::list >::_Const_iterator<1> & __thiscall std::list >::_Const_iterator<1>::operator++(void)" ( ??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$alloc ator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ) using llmozlib-vc80.lib (copied from release libs folder into debug libs folder); llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: unresolved external symbol __invalid_parameter_noinfo referenced in function "public: class std::list >::_Const_iterator<1> & __thiscall std::list >::_Const_iterator<1>::operator++(void)" ( ??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$alloc ator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ) Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070630/7753aba8/attachment.htm From nicholaz at blueflash.cc Sat Jun 30 06:08:22 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 30 06:08:33 2007 Subject: [sldev] Debug build of 1.17.2.0 in vc 2005 (Express) In-Reply-To: <001101c7bb14$e4732580$21071f52@tomhome> References: <001101c7bb14$e4732580$21071f52@tomhome> Message-ID: <468655C6.2020509@blueflash.cc> Thomas, > The first problem. ytab.h is not generated. > I worked around this by building the releasenoopt lscript_compile, which > generated (a version of) the file. > I have not worked out why generation of ytab.h breaks in the debug conf. There's a "mv" command missing in the postbuild step of indra.y in the debug configuration. (Same is true for VS2003 files). > msvcrtd;libcd.lib;msvcrt;libcmt > (add ;msvcrt;libcmt) Ok, will add that to the instructions on the wiki. > linden\indra\llcommon\llpreprocessor.h @ line 59 > --59: #define LL_LIBXUL_ENABLED 1 > ++59: #define LL_LIBXUL_ENABLED 0 This as well. Helpful ... many thanks! Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Thomas Rowland wrote: > Yey, I got it to build, link and connect to the grid (but I had to > disable llmozlib, which won't help anybody), and it is a bit of a work > around too. > > The first problem. ytab.h is not generated. > I worked around this by building the releasenoopt lscript_compile, which > generated (a version of) the file. > I have not worked out why generation of ytab.h breaks in the debug conf. > > Then the linking errors. > change newview properties Linker\Input\Ignore Specific Library to: > > msvcrtd;libcd.lib;msvcrt;libcmt > (add ;msvcrt;libcmt) > > Alas I was not able to get the debug or release versions of > llmozlib-vc80.lib to link, so disabled it: > > linden\indra\llcommon\llpreprocessor.h @ line 59 > --59: #define LL_LIBXUL_ENABLED 1 > ++59: #define LL_LIBXUL_ENABLED 0 > Just for info. the errors are posted below. > > using llmozlib-vc80.lib in debug libs folder; > > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::enableCookies(bool)" > (?enableCookies@LLMozLib@@QAE_N_N@Z > ) referenced in function > "public: virtual void __thiscall LLPanelWeb::refresh(void)" > (?refresh@LLPanelWeb@@UAEXXZ ) > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::clearAllCookies(void)" > (?clearAllCookies@LLMozLib@@QAE_NXZ > ) referenced in function > "private: static void __cdecl > LLPanelWeb::callback_clear_cookies(int,void *)" > (?callback_clear_cookies@LLPanelWeb@@CAXHPAX@Z > ) > llstartup.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::init(class std::basic_string std::char_traits,class std::allocator >,class > std::basic_string,class > std::allocator >,class std::basic_string std::char_traits,class std::allocator >)" > (?init@LLMozLib@@QAE_NV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@00@Z > ) > referenced in function "int __cdecl idle_startup(void)" > (?idle_startup@@YAHXZ ) > llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: > unresolved external symbol __invalid_parameter_noinfo referenced in > function "public: class std::list *,class std::allocator > >::_Const_iterator<1> & __thiscall std::list LLEmbeddedBrowserWindowObserver *,class std::allocator LLEmbeddedBrowserWindowObserver *> > >::_Const_iterator<1>::operator++(void)" > (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > ) > > using llmozlib-vc80.lib (copied from release libs folder into debug libs > folder); > > llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: > unresolved external symbol __invalid_parameter_noinfo referenced in > function "public: class std::list *,class std::allocator > >::_Const_iterator<1> & __thiscall std::list LLEmbeddedBrowserWindowObserver *,class std::allocator LLEmbeddedBrowserWindowObserver *> > >::_Const_iterator<1>::operator++(void)" > (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > ) > > > Tom > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From dzonatas at dzonux.net Sat Jun 30 06:15:09 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jun 30 06:14:55 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46860262.6050801@gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> <4685F563.8040909@gmail.com> <4685F678.4080804@gmail.com> <46860262.6050801@gmail.com> Message-ID: <4686575D.40102@dzonux.net> Tateru Nino wrote: > Jason Giglio wrote: > >> Tateru Nino wrote: >> >>> Whoever owns the hardware owns whatever's going on on that hardware. >>> Your rezzed objects and scripts, your textures. They can read your IMs >>> >> If only it were that simple. Without some serious centralization, you >> don't need to merely trust your sim hosting provider, you need to >> trust EVERY sim hosting provider. >> >> Unless you plan on selling your neat objects only to people on your >> own hosting service, and not allowing them to ever change providers, >> which would kinda suck. >> > Ah, yes. Sorry - I didn't mean to trivialise the amount of work required > to migrate the grid from an every-sim-is-totally-trustworthy to a > sims-cannot-necessarily-be-trusted position. Just saying that even once > that is done, you, the avatar must still trust the person who is running > the hardware. > > It appears a bit of false security is being uncovered here. I'd worry less about who to trust and worry more about how to make it more secure. Something along the lines of those security certificates you find in web browser may help. -- Power to Change the Void -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070630/13c5c1e2/attachment.htm From mattk at electricsheepcompany.com Sat Jun 30 06:51:41 2007 From: mattk at electricsheepcompany.com (Matt Kimmel) Date: Sat Jun 30 06:51:49 2007 Subject: [sldev] Debug build of 1.17.2.0 in vc 2005 (Express) In-Reply-To: <001101c7bb14$e4732580$21071f52@tomhome> References: <001101c7bb14$e4732580$21071f52@tomhome> Message-ID: <46865FED.9030901@electricsheepcompany.com> You may be able to get the release version of llmozlib linking by stubbing out invalid_parameter_noinfo; for some reason, it's only included in the release libraries under Visual Studio 2005. All it does is call invalid_parameter with all NULLs as parameters. -Matt Thomas Rowland wrote: > Yey, I got it to build, link and connect to the grid (but I had to > disable llmozlib, which won't help anybody), and it is a bit of a work > around too. > > The first problem. ytab.h is not generated. > I worked around this by building the releasenoopt lscript_compile, which > generated (a version of) the file. > I have not worked out why generation of ytab.h breaks in the debug conf. > > Then the linking errors. > change newview properties Linker\Input\Ignore Specific Library to: > > msvcrtd;libcd.lib;msvcrt;libcmt > (add ;msvcrt;libcmt) > > Alas I was not able to get the debug or release versions of > llmozlib-vc80.lib to link, so disabled it: > > linden\indra\llcommon\llpreprocessor.h @ line 59 > --59: #define LL_LIBXUL_ENABLED 1 > ++59: #define LL_LIBXUL_ENABLED 0 > Just for info. the errors are posted below. > > using llmozlib-vc80.lib in debug libs folder; > > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::enableCookies(bool)" > (?enableCookies@LLMozLib@@QAE_N_N@Z > ) referenced in function > "public: virtual void __thiscall LLPanelWeb::refresh(void)" > (?refresh@LLPanelWeb@@UAEXXZ ) > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::clearAllCookies(void)" > (?clearAllCookies@LLMozLib@@QAE_NXZ > ) referenced in function > "private: static void __cdecl > LLPanelWeb::callback_clear_cookies(int,void *)" > (?callback_clear_cookies@LLPanelWeb@@CAXHPAX@Z > ) > llstartup.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::init(class std::basic_string std::char_traits,class std::allocator >,class > std::basic_string,class > std::allocator >,class std::basic_string std::char_traits,class std::allocator >)" > (?init@LLMozLib@@QAE_NV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@00@Z > ) > referenced in function "int __cdecl idle_startup(void)" > (?idle_startup@@YAHXZ ) > llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: > unresolved external symbol __invalid_parameter_noinfo referenced in > function "public: class std::list *,class std::allocator > >::_Const_iterator<1> & __thiscall std::list LLEmbeddedBrowserWindowObserver *,class std::allocator LLEmbeddedBrowserWindowObserver *> > >::_Const_iterator<1>::operator++(void)" > (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > ) > > using llmozlib-vc80.lib (copied from release libs folder into debug libs > folder); > > llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: > unresolved external symbol __invalid_parameter_noinfo referenced in > function "public: class std::list *,class std::allocator > >::_Const_iterator<1> & __thiscall std::list LLEmbeddedBrowserWindowObserver *,class std::allocator LLEmbeddedBrowserWindowObserver *> > >::_Const_iterator<1>::operator++(void)" > (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > ) > > > Tom > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From nicholaz at blueflash.cc Sat Jun 30 06:53:26 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 30 06:53:39 2007 Subject: [sldev] Debug build of 1.17.2.0 in vc 2005 (Express) In-Reply-To: <46865FED.9030901@electricsheepcompany.com> References: <001101c7bb14$e4732580$21071f52@tomhome> <46865FED.9030901@electricsheepcompany.com> Message-ID: <46866056.9020105@blueflash.cc> I've tried that recently (there's a patch for that here on the list somewhere) but it still crashed with a nice loop of exceptions. Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Matt Kimmel wrote: > You may be able to get the release version of llmozlib linking by > stubbing out invalid_parameter_noinfo; for some reason, it's only > included in the release libraries under Visual Studio 2005. All it does > is call invalid_parameter with all NULLs as parameters. > > -Matt > > Thomas Rowland wrote: >> Yey, I got it to build, link and connect to the grid (but I had to >> disable llmozlib, which won't help anybody), and it is a bit of a work >> around too. >> >> The first problem. ytab.h is not generated. >> I worked around this by building the releasenoopt lscript_compile, >> which generated (a version of) the file. >> I have not worked out why generation of ytab.h breaks in the debug conf. >> >> Then the linking errors. >> change newview properties Linker\Input\Ignore Specific Library to: >> >> msvcrtd;libcd.lib;msvcrt;libcmt >> (add ;msvcrt;libcmt) >> >> Alas I was not able to get the debug or release versions of >> llmozlib-vc80.lib to link, so disabled it: >> >> linden\indra\llcommon\llpreprocessor.h @ line 59 --59: #define >> LL_LIBXUL_ENABLED 1 >> ++59: #define LL_LIBXUL_ENABLED 0 >> Just for info. the errors are posted below. >> >> using llmozlib-vc80.lib in debug libs folder; >> >> llpanelweb.obj : error LNK2019: unresolved external symbol "public: >> bool __thiscall LLMozLib::enableCookies(bool)" >> (?enableCookies@LLMozLib@@QAE_N_N@Z >> ) referenced in function >> "public: virtual void __thiscall LLPanelWeb::refresh(void)" >> (?refresh@LLPanelWeb@@UAEXXZ ) >> llpanelweb.obj : error LNK2019: unresolved external symbol "public: >> bool __thiscall LLMozLib::clearAllCookies(void)" >> (?clearAllCookies@LLMozLib@@QAE_NXZ >> ) referenced in function >> "private: static void __cdecl >> LLPanelWeb::callback_clear_cookies(int,void *)" >> (?callback_clear_cookies@LLPanelWeb@@CAXHPAX@Z >> ) >> llstartup.obj : error LNK2019: unresolved external symbol "public: >> bool __thiscall LLMozLib::init(class std::basic_string> std::char_traits,class std::allocator >,class >> std::basic_string,class >> std::allocator >,class std::basic_string> std::char_traits,class std::allocator >)" >> (?init@LLMozLib@@QAE_NV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@00@Z >> ) >> referenced in function "int __cdecl idle_startup(void)" >> (?idle_startup@@YAHXZ ) >> llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: >> unresolved external symbol __invalid_parameter_noinfo referenced in >> function "public: class std::list> LLEmbeddedBrowserWindowObserver *,class std::allocator> LLEmbeddedBrowserWindowObserver *> >::_Const_iterator<1> & __thiscall >> std::list> std::allocator >> >::_Const_iterator<1>::operator++(void)" >> (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ >> ) >> >> >> using llmozlib-vc80.lib (copied from release libs folder into debug >> libs folder); >> >> llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: >> unresolved external symbol __invalid_parameter_noinfo referenced in >> function "public: class std::list> LLEmbeddedBrowserWindowObserver *,class std::allocator> LLEmbeddedBrowserWindowObserver *> >::_Const_iterator<1> & __thiscall >> std::list> std::allocator >> >::_Const_iterator<1>::operator++(void)" >> (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ >> ) >> >> >> >> Tom >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 chance at kalacia.com Sat Jun 30 06:54:44 2007 From: chance at kalacia.com (Chance Unknown) Date: Sat Jun 30 06:54:48 2007 Subject: [sldev] Opening the server source? In-Reply-To: <4686575D.40102@dzonux.net> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> <4685F563.8040909@gmail.com> <4685F678.4080804@gmail.com> <46860262.6050801@gmail.com> <4686575D.40102@dzonux.net> Message-ID: <2925011a0706300654n7d1b1b7bkcb44cd16dbba70c3@mail.gmail.com> You fail to realize something : it's all just online hosted content. You "trust" websites enough to click the viagra links in your email. So what is the issue with trusting other online hosted content in the same manner? There isn't any -- update your virus scanners, and make sure your pop up blockers are up to date - and browse till your mouse finger falls off. On 6/30/07, Dzonatas wrote: > > Tateru Nino wrote: > > Jason Giglio wrote: > > Tateru Nino wrote: > > Whoever owns the hardware owns whatever's going on on that hardware. > Your rezzed objects and scripts, your textures. They can read your IMs > > If only it were that simple. Without some serious centralization, you > don't need to merely trust your sim hosting provider, you need to > trust EVERY sim hosting provider. > > Unless you plan on selling your neat objects only to people on your > own hosting service, and not allowing them to ever change providers, > which would kinda suck. > > Ah, yes. Sorry - I didn't mean to trivialise the amount of work required > to migrate the grid from an every-sim-is-totally-trustworthy to a > sims-cannot-necessarily-be-trusted position. Just saying that even once > that is done, you, the avatar must still trust the person who is running > the hardware. > > > It appears a bit of false security is being uncovered here. I'd worry less > about who to trust and worry more about how to make it more secure. > Something along the lines of those security certificates you find in web > browser may help. > > -- > Power to Change the Void > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070630/f81b924d/attachment.htm From nicholaz at blueflash.cc Sat Jun 30 06:59:56 2007 From: nicholaz at blueflash.cc (Nicholaz Beresford) Date: Sat Jun 30 07:00:27 2007 Subject: [sldev] Debug build of 1.17.2.0 in vc 2005 (Express) In-Reply-To: <001101c7bb14$e4732580$21071f52@tomhome> References: <001101c7bb14$e4732580$21071f52@tomhome> Message-ID: <468661DC.60903@blueflash.cc> Thomas, did you try the leak patch under 2005? Would like to know if it works. https://wiki.secondlife.com/wiki/Finding_leaks Nick Second Life from the inside out: http://nicholaz-beresford.blogspot.com/ Thomas Rowland wrote: > Yey, I got it to build, link and connect to the grid (but I had to > disable llmozlib, which won't help anybody), and it is a bit of a work > around too. > > The first problem. ytab.h is not generated. > I worked around this by building the releasenoopt lscript_compile, which > generated (a version of) the file. > I have not worked out why generation of ytab.h breaks in the debug conf. > > Then the linking errors. > change newview properties Linker\Input\Ignore Specific Library to: > > msvcrtd;libcd.lib;msvcrt;libcmt > (add ;msvcrt;libcmt) > > Alas I was not able to get the debug or release versions of > llmozlib-vc80.lib to link, so disabled it: > > linden\indra\llcommon\llpreprocessor.h @ line 59 > --59: #define LL_LIBXUL_ENABLED 1 > ++59: #define LL_LIBXUL_ENABLED 0 > Just for info. the errors are posted below. > > using llmozlib-vc80.lib in debug libs folder; > > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::enableCookies(bool)" > (?enableCookies@LLMozLib@@QAE_N_N@Z > ) referenced in function > "public: virtual void __thiscall LLPanelWeb::refresh(void)" > (?refresh@LLPanelWeb@@UAEXXZ ) > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::clearAllCookies(void)" > (?clearAllCookies@LLMozLib@@QAE_NXZ > ) referenced in function > "private: static void __cdecl > LLPanelWeb::callback_clear_cookies(int,void *)" > (?callback_clear_cookies@LLPanelWeb@@CAXHPAX@Z > ) > llstartup.obj : error LNK2019: unresolved external symbol "public: bool > __thiscall LLMozLib::init(class std::basic_string std::char_traits,class std::allocator >,class > std::basic_string,class > std::allocator >,class std::basic_string std::char_traits,class std::allocator >)" > (?init@LLMozLib@@QAE_NV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@00@Z > ) > referenced in function "int __cdecl idle_startup(void)" > (?idle_startup@@YAHXZ ) > llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: > unresolved external symbol __invalid_parameter_noinfo referenced in > function "public: class std::list *,class std::allocator > >::_Const_iterator<1> & __thiscall std::list LLEmbeddedBrowserWindowObserver *,class std::allocator LLEmbeddedBrowserWindowObserver *> > >::_Const_iterator<1>::operator++(void)" > (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > ) > > using llmozlib-vc80.lib (copied from release libs folder into debug libs > folder); > > llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: > unresolved external symbol __invalid_parameter_noinfo referenced in > function "public: class std::list *,class std::allocator > >::_Const_iterator<1> & __thiscall std::list LLEmbeddedBrowserWindowObserver *,class std::allocator LLEmbeddedBrowserWindowObserver *> > >::_Const_iterator<1>::operator++(void)" > (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > ) > > > Tom > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From able.whitman at gmail.com Sat Jun 30 07:43:42 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sat Jun 30 07:43:44 2007 Subject: [sldev] Debug build of 1.17.2.0 in vc 2005 (Express) In-Reply-To: <468655C6.2020509@blueflash.cc> References: <001101c7bb14$e4732580$21071f52@tomhome> <468655C6.2020509@blueflash.cc> Message-ID: <7b3a84fb0706300743i7d2b3d53o1959b1a7905e843a@mail.gmail.com> Thanks very much, Thomas and Nick! I've now got a working VC8 debug build going, which is very heplful. On 6/30/07, Nicholaz Beresford wrote: > > Thomas, > > > The first problem. ytab.h is not generated. > > I worked around this by building the releasenoopt lscript_compile, which > > generated (a version of) the file. > > I have not worked out why generation of ytab.h breaks in the debug conf. > > There's a "mv" command missing in the postbuild step of indra.y in the > debug configuration. (Same is true for VS2003 files). > > > msvcrtd;libcd.lib;msvcrt;libcmt > > (add ;msvcrt;libcmt) > > Ok, will add that to the instructions on the wiki. > > > > linden\indra\llcommon\llpreprocessor.h @ line 59 > > --59: #define LL_LIBXUL_ENABLED 1 > > ++59: #define LL_LIBXUL_ENABLED 0 > > This as well. > > Helpful ... many thanks! > > > Nick > > > Second Life from the inside out: > http://nicholaz-beresford.blogspot.com/ > > > Thomas Rowland wrote: > > Yey, I got it to build, link and connect to the grid (but I had to > > disable llmozlib, which won't help anybody), and it is a bit of a work > > around too. > > > > The first problem. ytab.h is not generated. > > I worked around this by building the releasenoopt lscript_compile, which > > generated (a version of) the file. > > I have not worked out why generation of ytab.h breaks in the debug conf. > > > > Then the linking errors. > > change newview properties Linker\Input\Ignore Specific Library to: > > > > msvcrtd;libcd.lib;msvcrt;libcmt > > (add ;msvcrt;libcmt) > > > > Alas I was not able to get the debug or release versions of > > llmozlib-vc80.lib to link, so disabled it: > > > > linden\indra\llcommon\llpreprocessor.h @ line 59 > > --59: #define LL_LIBXUL_ENABLED 1 > > ++59: #define LL_LIBXUL_ENABLED 0 > > Just for info. the errors are posted below. > > > > using llmozlib-vc80.lib in debug libs folder; > > > > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > > __thiscall LLMozLib::enableCookies(bool)" > > (?enableCookies@LLMozLib@@QAE_N_N@Z > > ) referenced in function > > "public: virtual void __thiscall LLPanelWeb::refresh(void)" > > (?refresh@LLPanelWeb@@UAEXXZ ) > > llpanelweb.obj : error LNK2019: unresolved external symbol "public: bool > > __thiscall LLMozLib::clearAllCookies(void)" > > (?clearAllCookies@LLMozLib@@QAE_NXZ > > ) referenced in function > > "private: static void __cdecl > > LLPanelWeb::callback_clear_cookies(int,void *)" > > (?callback_clear_cookies@LLPanelWeb@@CAXHPAX@Z > > ) > > llstartup.obj : error LNK2019: unresolved external symbol "public: bool > > __thiscall LLMozLib::init(class std::basic_string > std::char_traits,class std::allocator >,class > > std::basic_string,class > > std::allocator >,class std::basic_string > std::char_traits,class std::allocator >)" > > (?init@LLMozLib@@QAE_NV?$basic_string@DU?$char_traits@D@std@@ > V?$allocator@D@2@@std@@00@Z > > V?$allocator@D@2@@std@@00@Z>) > > referenced in function "int __cdecl idle_startup(void)" > > (?idle_startup@@YAHXZ ) > > llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: > > unresolved external symbol __invalid_parameter_noinfo referenced in > > function "public: class std::list > *,class std::allocator > > >::_Const_iterator<1> & __thiscall std::list > LLEmbeddedBrowserWindowObserver *,class std::allocator > LLEmbeddedBrowserWindowObserver *> > > >::_Const_iterator<1>::operator++(void)" > > (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@ > V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > > > V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > >) > > > > using llmozlib-vc80.lib (copied from release libs folder into debug libs > > folder); > > > > llmozlib-vc80.lib(llembeddedbrowserwindow.obj) : error LNK2019: > > unresolved external symbol __invalid_parameter_noinfo referenced in > > function "public: class std::list > *,class std::allocator > > >::_Const_iterator<1> & __thiscall std::list > LLEmbeddedBrowserWindowObserver *,class std::allocator > LLEmbeddedBrowserWindowObserver *> > > >::_Const_iterator<1>::operator++(void)" > > (??E?$_Const_iterator@$00@?$list@PAVLLEmbeddedBrowserWindowObserver@@ > V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > > > V?$allocator@PAVLLEmbeddedBrowserWindowObserver@@@std@@@std@@QAEAAV012@XZ > >) > > > > > > Tom > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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/20070630/a5432837/attachment.htm From able.whitman at gmail.com Sat Jun 30 07:49:54 2007 From: able.whitman at gmail.com (Able Whitman) Date: Sat Jun 30 07:49:57 2007 Subject: [sldev] Building LLMozLib? Message-ID: <7b3a84fb0706300749s273bc27eh361c54730311ce9@mail.gmail.com> I'm curious why the source for LLMozLib isn't included with the viewer source. Is there a licensing issue involved? My motives are selfish -- I'd like to be able to generate a debug build in VC8 without disabling the embedded browser. But just for the sake of completeness, it would be nice to have in order to inspect and improve. The latest source on ubrowser.com is "llmozlib_win_src_2006_11_06.zip", which is clearly not the latest version, as it's rather old and lacks cookie support. --Able -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070630/bbd9b4f9/attachment.htm From tao.takashi at googlemail.com Sat Jun 30 08:21:41 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Sat Jun 30 08:21:43 2007 Subject: [sldev] Opening the server source? In-Reply-To: <2925011a0706300654n7d1b1b7bkcb44cd16dbba70c3@mail.gmail.com> References: <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> <4685F563.8040909@gmail.com> <4685F678.4080804@gmail.com> <46860262.6050801@gmail.com> <4686575D.40102@dzonux.net> <2925011a0706300654n7d1b1b7bkcb44cd16dbba70c3@mail.gmail.com> Message-ID: <23bbb49e0706300821t5fe7e150nad0f3336fbc8cae7@mail.gmail.com> Isn't there a difference between web sites and a virtual world? Websites are more or less distinct spaces while a virtual world IMHO should be more continuous. So if you walk or teleport from A to B people usually don't bother if you need to trust B or not. You even my walk into it and might not even notice it. So people might need to be more sensible to the place they are on. But then again on a website you are usually on a branded site and you might know or might not know that brand. On a sim with e.g. residential parcels you might not know who the owner is and if you can trust him or her (Linden Lab's sim might be known as the ones you can trust though and probably there will be some more bigger providers then). Another difference is that I usually don't take content from website A to website B (like attachements in SL). And certificates might also not help if applied like on the web as they only secure the transmission between client and server but not what the owner of the server might be able to do with it. Different certificate application could be created of course in a way that scripts are only readable by people with the right certificate etc. But I guess everything can be broken and in the end it's nevertheless up to whom you trust (on the web of course I can also copy any photo if I wanted to. I just might not be allowed to do so). Last but not least the main worry of people is that content might get stolen because it's usually up for sale and not free. On web2.0 sites at least it's different as the whole idea there is to share and if something moves to another spot (like an embedded video) then this is actually intended behaviour. So all in all I think there are many not that easy to solve issues, some technical, some structural and some UI wise. As for the idea of opening up itself I think that backend database solutions will be around quite quickly and thus I really wonder what a business model for LL could be. Moreover I think that a true virtual world standard is hard to achieve. If a business is doing it they need to make sure it makes sense for their business model and they need to find partners. Now the term "virtual world" is sort of a big term and it has many incarnations and it might be hard to get all these incarnations into one standard.. So first it needs to get broken up anyway and then maybe somebody can start on a standard for e.g. exchanging objects (which already depends very much on the internal representation of objects like prim based or polygon based). All in all a non-trivial task. (but I'd like to learn more about the business model of Linden Lab for that case :-) -- Tao 2007/6/30, Chance Unknown : > > You fail to realize something : it's all just online hosted content. You > "trust" websites enough to click the viagra links in your email. So what is > the issue with trusting other online hosted content in the same manner? > There isn't any -- update your virus scanners, and make sure your pop up > blockers are up to date - and browse till your mouse finger falls off. > > On 6/30/07, Dzonatas wrote: > > > Tateru Nino wrote: > > > > Jason Giglio wrote: > > > > Tateru Nino wrote: > > > > Whoever owns the hardware owns whatever's going on on that hardware. > > Your rezzed objects and scripts, your textures. They can read your IMs > > > > If only it were that simple. Without some serious centralization, you > > don't need to merely trust your sim hosting provider, you need to > > trust EVERY sim hosting provider. > > > > Unless you plan on selling your neat objects only to people on your > > own hosting service, and not allowing them to ever change providers, > > which would kinda suck. > > > > Ah, yes. Sorry - I didn't mean to trivialise the amount of work required > > to migrate the grid from an every-sim-is-totally-trustworthy to a > > sims-cannot-necessarily-be-trusted position. Just saying that even once > > that is done, you, the avatar must still trust the person who is running > > the hardware. > > > > > > It appears a bit of false security is being uncovered here. I'd worry > > less about who to trust and worry more about how to make it more secure. > > Something along the lines of those security certificates you find in web > > browser may help. > > > > -- > > Power to Change the Void > > > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- 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/20070630/0c2b84fc/attachment-0001.htm From dzonatas at dzonux.net Sat Jun 30 11:42:52 2007 From: dzonatas at dzonux.net (Dzonatas) Date: Sat Jun 30 11:42:38 2007 Subject: [sldev] Opening the server source? In-Reply-To: <23bbb49e0706300821t5fe7e150nad0f3336fbc8cae7@mail.gmail.com> References: <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> <4685F563.8040909@gmail.com> <4685F678.4080804@gmail.com> <46860262.6050801@gmail.com> <4686575D.40102@dzonux.net> <2925011a0706300654n7d1b1b7bkcb44cd16dbba70c3@mail.gmail.com> <23bbb49e0706300821t5fe7e150nad0f3336fbc8cae7@mail.gmail.com> Message-ID: <4686A42C.10104@dzonux.net> Tao Takashi wrote: > Isn't there a difference between web sites and a virtual world? ... As much as there is a different between the Apache webserver and Second Life's sim server. =) > As for the idea of opening up itself I think that backend database > solutions will be around quite quickly and thus I really wonder what a > business model for LL could be. Moreover I think that a true virtual > world standard is hard to achieve. If a business is doing it they need > to make sure it makes sense for their business model and they need to > find partners. Now the term "virtual world" is sort of a big term and > it has many incarnations and it might be hard to get all these > incarnations into one standard.. So first it needs to get broken up > anyway and then maybe somebody can start on a standard for e.g. > exchanging objects (which already depends very much on the internal > representation of objects like prim based or polygon based). For businesses besides LL's internal motives, this can be narrowed down to a secure transactional asset server and script/program platform. To touch on the briefly, let's say you have a ATM machine in-world and the sim crashes in the midst of a transaction. Simple transactions may be easily to recover, but more complex ones really need to allow the scripts to detect crashes, failed transactions, perform recovery, etc. Right now, a lot of extra code has to be added to accomplish all that for even the softest crashes or failures. You can't guarantee that all script writers will include all that extra code in their script. Therefore, there is a need to create a solid framework to handle serious business in virtual worlds. The immediate answer is to move the business into a hybrid mode and use something like XML-RPC, so that it is part in-world and part website. It is not the best answer, but it works. The website can add the higher degree of transactional software. (if they do...) Considering how GPLv3 (just released) now works with Apache, we may see more bits of hybrid Second-Life-on-a-Apache mod(s). This is no longer a blocker issue. -- Power to Change the Void From eponymousdylan at googlemail.com Sat Jun 30 11:55:47 2007 From: eponymousdylan at googlemail.com (EponymousDylan Ra) Date: Sat Jun 30 11:55:49 2007 Subject: [sldev] VWR-1465: Viewer crash after taking several hi-res snapshots Message-ID: My first patch, so please be gentle: https://jira.secondlife.com/browse/VWR-1465 Nicholaz - if you're reading this, perhaps you'd consider including this in the next release of your viewer, given how simple the fix is. (I suspect this will be a low priority for the official builds, given that it doesn't affect most people, and it would be nice to be able to point SL photographers at your viewer until it gets addressed in the official release) Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070630/279ccd7e/attachment.htm From jhurliman at wsu.edu Sat Jun 30 12:15:03 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sat Jun 30 12:17:09 2007 Subject: [sldev] Free coverity scan? In-Reply-To: <468608E8.9020401@gmail.com> References: <468608E8.9020401@gmail.com> Message-ID: <4686ABB7.6030608@wsu.edu> Jason Giglio wrote: > Coverity has been giving out free static analysis to some open source > projects. > > I'm sure the SL client could use it, considering the number of null > pointer crash patches lately. :) > > http://scan.coverity.com/devfaq.html > > So who wants to be the "official contact" to approach Coverity about it? > > -Jason Already looked in to it, at the time they were apprehensive about giving SL a free scan because they were already in talks with LL about a paid contract (for the client and simulator code). They said if the contract does get established and LL approves they will give OSS developers access to the results, or if they add C# compatibility they will offer a free scan of libsecondlife. John Hurliman From cnd at knowprose.com Sat Jun 30 16:16:43 2007 From: cnd at knowprose.com (Taran Rampersad) Date: Sat Jun 30 16:16:47 2007 Subject: [sldev] Opening the server source? In-Reply-To: <46860262.6050801@gmail.com> References: <7992d0d60706260356y7ebd9839jac409e3000e3d8c1@mail.gmail.com> <4680FC52.1080400@blueflash.cc> <2925011a0706260503m550e46ach392093b28f642923@mail.gmail.com> <468570BE.4090707@watson.ibm.com> <4685A426.7070809@gmail.com> <4685F563.8040909@gmail.com> <4685F678.4080804@gmail.com> <46860262.6050801@gmail.com> Message-ID: <4686E45B.7040400@knowprose.com> Tateru Nino wrote: > Ah, yes. Sorry - I didn't mean to trivialise the amount of work required > to migrate the grid from an every-sim-is-totally-trustworthy to a > sims-cannot-necessarily-be-trusted position. Just saying that even once > that is done, you, the avatar must still trust the person who is running > the hardware. > Further, future sim providers need to be able to trust the infrastructure provider, be assured of timely information and to manage the server side software project until someone else comes along who does it better. It also means that there needs to be more standardization on Terms of Service related issues, specifically related to fiscal policy which will be handled throughout greater grid. Which means - LL has a lot of work to do and the code is only a part of it. Stage whisper that wherever you can, because it is true even without the server source being opened. -- Taran Rampersad Presently in: San Fernando, Trinidad and Tobago cnd@knowprose.com http://www.knowprose.com Pictures: http://www.flickr.com/photos/knowprose/ "Criticize by creating." ? Michelangelo "The present is theirs; the future, for which I really worked, is mine." - Nikola Tesla