From robla at lindenlab.com Thu Feb 1 00:35:21 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Feb 1 00:36:41 2007 Subject: [sldev] which code base? In-Reply-To: <200701311218.08263.todd@fries.net> References: <200701311218.08263.todd@fries.net> Message-ID: <45C1A649.7020906@lindenlab.com> On 1/31/07 10:18 AM, Todd T. Fries wrote: > I've built 1.13.2(15) and apparently the new grid is running 1.13.3 according > to http://secondlif.com/status .. > > Which version of the available source downloads will connect to this new grid? > The newly available 1.13.3(2) source code will. Sorry for the hassle; we anticipate that this level of churn will be with us for a few more months before we can stabilize the protocol enough not to constantly revise the code. > And btw, will the *.bz2 files be create-able by the open source viewers > and/or packaged separately for download anytime soon? > What do you mean by this? 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/20070201/98e06295/signature.pgp From robla at lindenlab.com Thu Feb 1 11:05:01 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Feb 1 11:06:27 2007 Subject: [sldev] Request for LL feedback on avatar scanner features In-Reply-To: <200701310039.50610.dale@daleglass.net> References: <200701310039.50610.dale@daleglass.net> Message-ID: <45C239DD.4040103@lindenlab.com> Hi Dale, Comments inline: On 1/30/07 3:39 PM, Dale Glass wrote: > I've been working on an avatar scanner right in the client. Here's the > screenshot of a recent build: > > http://daleglass.net/images/screenshots/avlist3_001.jpg > > I would like to ask, just in case, if LL would have any problem with any of > the features that I'm working on. I wouldn't want to infringe any sort of > policy or anything like that. Most aspects don't run afoul of any policies that I'm aware of, though the main concern that I have is increased load on our services by one of the features. That said, it looks quite interesting. Torley pointed out to me that this can help fulfill this feature request: http://secondlife.com/vote/get_feature.php?get_id=905 > * Automatically retrieves the birth date, account type and payment data for > all users shown. The data is of course cached, and if this is too much of an > extra load, I'll implement a permanent on-disk cache. If data doesn't arrive, > it will retry with an exponential backoff (starting from 1 minute, doubling > until 30 minutes) > Please fetch this information on demand rather than doing so automatically. At a minimum, please have a default "off" checkbox for "Fetch account information". To be honest, I don't know how much extra load this feature would really impose, but in general, we're pretty sensitive to the load issues right now. (Dale's full proposal is here: https://lists.secondlife.com/pipermail/sldev/2007-January/000291.html ) 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/20070201/9992d890/signature.pgp From dale at daleglass.net Thu Feb 1 12:50:30 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Feb 1 12:50:46 2007 Subject: [sldev] Request for LL feedback on avatar scanner features In-Reply-To: <45C239DD.4040103@lindenlab.com> References: <200701310039.50610.dale@daleglass.net> <45C239DD.4040103@lindenlab.com> Message-ID: <200702012150.35216.dale@daleglass.net> ? ????????? ?? 1 ??????? 2007 20:05 Rob Lanphier ???????(a): > Most aspects don't run afoul of any policies that I'm aware of, though > the main concern that I have is increased load on our services by one of Yes, I imagined that sort of thing wouldn't necessarily be appreciated, so thought it'd be best to ask just in case. I'm definitely going to try to add as little extra load as possible. BTW, the scripted version of it is already in-world and about 360 people have it. This one also does the payment/age requests automatically, but it's limited to 16 avatars and 96m max (configurable). On the other hand, due to LSL memory constraints, it does a lot less caching. When I was doing it I didn't think it'd affect things much, but now I'm starting to wonder whether it might be having a noticeable effect. This version makes normal dataserver queries, which I assume LL can throttle if needed. If this is placing too much load on the grid, I'll make changes (make it be disabled by default, say), and push an update. Scripted version is available here for free: http://www.slboutique.com/index.php?p=buy&itemid=153356 > the features. That said, it looks quite interesting. Torley pointed > out to me that this can help fulfill this feature request: > http://secondlife.com/vote/get_feature.php?get_id=905 Thanks :-) I won't be working on this sort of thing right now though. My experience with C++ is very limited still, so I'm starting from the easier stuff, and over time will get there. > Please fetch this information on demand rather than doing so > automatically. At a minimum, please have a default "off" checkbox for > "Fetch account information". No problem, will do. > To be honest, I don't know how much extra > load this feature would really impose, but in general, we're pretty > sensitive to the load issues right now. I've been thinking on this, so here's what I came up with so far: I'm going to store data for every avatar on disk. Since the data currently queried won't change often this should be very effective. For example: * Birth date doesn't change ever, so once obtained it'll be stored permanently * Payment data very seldom changes, and AFAIK doesn't get downgraded. * Avatar names don't change either, so that could be stored too (wonder if this could be generalized, since the client seems to have to make a query to find things like the name of an object's creator) With this, there would be only one query per avatar with used payment data (since that won't be changing anymore), and it'll display the cached data if requesting data is disabled. One thing I'm thinking about here is whether this could be generalized. For example, profiles use that data as well, so why not make an "avatar data cache" and make the rest of the client use it as well? > > (Dale's full proposal is here: > https://lists.secondlife.com/pipermail/sldev/2007-January/000291.html ) > > Rob -------------- 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/20070201/e27ea9fd/attachment.pgp From gigstaggart at gmail.com Thu Feb 1 14:45:28 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Feb 1 14:46:49 2007 Subject: [sldev] Request for LL feedback on avatar scanner features In-Reply-To: <200702012150.35216.dale@daleglass.net> References: <200701310039.50610.dale@daleglass.net> <45C239DD.4040103@lindenlab.com> <200702012150.35216.dale@daleglass.net> Message-ID: <45C26D88.5050109@gmail.com> Dale Glass wrote: > One thing I'm thinking about here is whether this could be generalized. For > example, profiles use that data as well, so why not make an "avatar data > cache" and make the rest of the client use it as well? It already exists, names.cache. From dale at daleglass.net Thu Feb 1 15:20:31 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Feb 1 15:20:48 2007 Subject: [sldev] Request for LL feedback on avatar scanner features In-Reply-To: <45C26D88.5050109@gmail.com> References: <200701310039.50610.dale@daleglass.net> <200702012150.35216.dale@daleglass.net> <45C26D88.5050109@gmail.com> Message-ID: <200702020020.37170.dale@daleglass.net> ? ????????? ?? 1 ??????? 2007 23:45 Jason Giglio ???????(a): > Dale Glass wrote: > > One thing I'm thinking about here is whether this could be generalized. > > For example, profiles use that data as well, so why not make an "avatar > > data cache" and make the rest of the client use it as well? > > It already exists, names.cache. My name.cache is tiny, and seems to have been created today. And I'm thinking of something bigger and more general here. Rough idea: * 1 file per avatar, kept permanently. * In-memory cache of that, of course * Probably XML format for extensibility * Keep all data relating to avatar, including: name, key, birth data, payment status, and a full copy of the whole profile (if it was acessed) * Extra data related to avatar. Say, I'd like to assign colors to people, which would be stored here as well. The class implementing all this would decide whether requesting data from the server is needed, and be able to deliver cached data if the server doesn't answer. So instead of the profile not loading at all you could see the last data you got (with a warning of that it's stale of course) This is not completely thought out yet, but it should be something along those lines. -------------- 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/20070202/44c4d1c2/attachment.pgp From gigstaggart at gmail.com Thu Feb 1 15:25:35 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Feb 1 15:26:47 2007 Subject: [sldev] Request for LL feedback on avatar scanner features In-Reply-To: <200702020020.37170.dale@daleglass.net> References: <200701310039.50610.dale@daleglass.net> <200702012150.35216.dale@daleglass.net> <45C26D88.5050109@gmail.com> <200702020020.37170.dale@daleglass.net> Message-ID: <45C276EF.3040500@gmail.com> Dale Glass wrote: > ? ????????? ?? 1 ??????? 2007 23:45 Jason Giglio ???????(a): >> Dale Glass wrote: >>> One thing I'm thinking about here is whether this could be generalized. >>> For example, profiles use that data as well, so why not make an "avatar >>> data cache" and make the rest of the client use it as well? >> It already exists, names.cache. > > My name.cache is tiny, and seems to have been created today. > > And I'm thinking of something bigger and more general here. Rough idea: > > * 1 file per avatar, kept permanently. I don't think permanent caching is a good idea. Billing status does change, in both direction. Names change too. In fact, nearly everything on there can change under some circumstances. You are making dangerous assumptions about what will and won't change. > Probably XML format for extensibility XML is a data interchange format for blind exchange, not for storing data within an application. Just make the data "on-request" and leave it at that. This isn't a huge volume of data, if you only load it when the user requests. From dale at daleglass.net Thu Feb 1 16:16:35 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Feb 1 16:20:01 2007 Subject: [sldev] Request for LL feedback on avatar scanner features In-Reply-To: <45C276EF.3040500@gmail.com> References: <200701310039.50610.dale@daleglass.net> <200702020020.37170.dale@daleglass.net> <45C276EF.3040500@gmail.com> Message-ID: <200702020116.42706.dale@daleglass.net> ? ????????? ?? 2 ??????? 2007 00:25 Jason Giglio ???????(a): > I don't think permanent caching is a good idea. > > Billing status does change, in both direction. Even if it does, does it matter? The point of knowing somebody's payment data is basically as an indication of how much they invested into SL, and how effectively they can be kept out if they're found to be undesirable. Once you provided that data, LL will still have it even if you change your card. > Names change too. In AFAIK, there's still no way for a random person of doing that, and the only exception I know of is people becoming Lindens. Even in that case, it'd be okay. If you remember somebody under their old name, you'd just keep getting it when looking at say, object creators until you cleared your cache. If the key is the same, it's still the same person, after all. Expiring the cache every week just in case could be done, which should still be an improvement. > fact, nearly everything on there can change under some circumstances. > You are making dangerous assumptions about what will and won't change. It depends on the situation. For example, my scanner as originally designed requests payment data and birth date for everybody around. Birth date is set in stone, payment data even if it does somehow change to a "lesser" status, it's probably harmless to keep it like that anyway. Once you look at somebody's profile, the scanner could use that data without making an extra request to the server to get the same stuff. Extended further: Adding a timestamp to profiles it could be known for sure whether any data has been invalidated. One request to the server would tell you whether anything needs to be updated or not. What I'm aiming for here is that since I'm working on something that will add extra load to the server (if used) I'm attempting to add something that will lower the load to compensate. Even if my scanner goes into the official client, not everybody would always use it, while caching improvements if they go in would benefit everybody. So if this works the way I expect, I would hope for a net win. > XML is a data interchange format for blind exchange, not for storing > data within an application. XML is a very good format for it, for these reasons: * It's already used in the client (XML UI say), so it makes sense to use something with existing code to support it * It can deal perfectly with issues like delimitation and charsets. It's a lot easier to just use XML than to figure out whether japanese in somebody's "about" field would break my parser * It can represent nested structures easily, which is good for things like the group of lists they belong to * It's easy to extend, so if more data needs to be stored, backwards compatibility is very easy to achieve. > Just make the data "on-request" and leave it at that. This isn't a huge > volume of data, if you only load it when the user requests. Now where's the fun in that? If I make it to be ONLY by request, then what's the point in it, you can just go and load profiles like before. This is just the beginning though. For example I've been asked to make the scanner identify people who belong to a group (not necessarily having it as the active one). That's another thing that could use caching. > > _______________________________________________ > 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/20070202/ef108385/attachment.pgp From mrfrans at gmail.com Thu Feb 1 16:26:08 2007 From: mrfrans at gmail.com (Frans) Date: Thu Feb 1 16:26:11 2007 Subject: [sldev] Request for LL feedback on avatar scanner features In-Reply-To: <200702020116.42706.dale@daleglass.net> References: <200701310039.50610.dale@daleglass.net> <200702020020.37170.dale@daleglass.net> <45C276EF.3040500@gmail.com> <200702020116.42706.dale@daleglass.net> Message-ID: <7765f2c60702011626n295c8384yb3f75b00f56575b@mail.gmail.com> Groups change a lot more though. I remove and add a group almost weekly because of the limit. >This is just the beginning though. For example I've been asked to make thescanner identify >people who belong to a group (not necessarily having it asthe active one). That's another thing >that could use caching. -- RL: Jeroen Frans SL: Frans Charming http://www.fransinnovations.com http://secondslog.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070202/bf48658c/attachment.htm From dale at daleglass.net Thu Feb 1 16:54:26 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Feb 1 16:54:44 2007 Subject: [sldev] Request for LL feedback on avatar scanner features In-Reply-To: <7765f2c60702011626n295c8384yb3f75b00f56575b@mail.gmail.com> References: <200701310039.50610.dale@daleglass.net> <200702020116.42706.dale@daleglass.net> <7765f2c60702011626n295c8384yb3f75b00f56575b@mail.gmail.com> Message-ID: <200702020154.31964.dale@daleglass.net> ? ????????? ?? 2 ??????? 2007 01:26 Frans ???????(a): > Groups change a lot more though. I remove and add a group almost weekly > because of the limit. It can be useful to keep the data around anyway. If you want to know if people are members of a group you're a member of, you can get the list of members with one query, instead of submitting a request per person. This is of course even more out of date, but could be of use anyway. There are degrees of staleness, as well. For example, as a part of working on the SL client, I often start it up, run it for a minute or two, notice something isn't right, close it, fix, start again in the same place... Then if I don't run SL for a week, discarding the cache completely would make sense. Old data can be used if the server is too busy -- old stuff is better than nothing. I think this could at least help keeping people from hammering the server to death. If the profile is already not loading and people need the data, they could try to re-open it, adding even more load. It's like when a server gets slashdotted -- people who are impatient, or get images that didn't load decide to reload the page and make the general situation even worse. -------------- 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/20070202/56f77181/attachment-0001.pgp From carnildo at gmail.com Thu Feb 1 20:04:11 2007 From: carnildo at gmail.com (Mark Wagner) Date: Thu Feb 1 20:04:14 2007 Subject: [sldev] Rendering Message-ID: <31073ef90702012004p67b1296fk9800baa13981945b@mail.gmail.com> Is there a document somewhere describing how the client handles drawing the world? Things like where it stores the scene model, how it updates it, and how objects are turned into OpenGL primitives? -- Mark Carnildo Greenacre From david at fries.net Thu Feb 1 23:27:29 2007 From: david at fries.net (David Fries) Date: Thu Feb 1 23:27:56 2007 Subject: [sldev] xmlrpc-epi and expat crash Message-ID: <20070202072728.GA32549@spacedout.fries.net> Skipped content of type multipart/mixed-------------- 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/20070202/6e5a611f/attachment-0001.pgp From emaslows at umich.edu Fri Feb 2 06:55:40 2007 From: emaslows at umich.edu (Eric Maslowski) Date: Fri Feb 2 06:55:47 2007 Subject: [sldev] Rendering In-Reply-To: <31073ef90702012004p67b1296fk9800baa13981945b@mail.gmail.com> Message-ID: <022901c746da$352a06b0$f21fd58d@adsroot.itcs.umich.edu> Hi Mark, Unfortunately, I don't have any documents (or know of any) that go into this, but we've found that the majority of the work is done in "pipeline", "viewerDisplay", "viewerCamera." If you find a comprehensive document which goes over the rendering pipeline, I would be highly interested as well. Cheers E. --- Eric Maslowski Research Computer Specialist University of Michigan 3D Lab Autodesk 3D Studio Max Certified Trainer email: emaslows@umich.edu office: 734-615-9699 mobile: 734-730-9904 -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Mark Wagner Sent: Thursday, February 01, 2007 23:04 To: Second Life Developer Mailing List Subject: [sldev] Rendering Is there a document somewhere describing how the client handles drawing the world? Things like where it stores the scene model, how it updates it, and how objects are turned into OpenGL primitives? -- Mark Carnildo Greenacre _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From kunnis at gmail.com Fri Feb 2 08:48:31 2007 From: kunnis at gmail.com (Zack Geers) Date: Fri Feb 2 08:48:33 2007 Subject: [sldev] Rendering In-Reply-To: <022901c746da$352a06b0$f21fd58d@adsroot.itcs.umich.edu> References: <31073ef90702012004p67b1296fk9800baa13981945b@mail.gmail.com> <022901c746da$352a06b0$f21fd58d@adsroot.itcs.umich.edu> Message-ID: The FL client also has a lot of changes in pipeline. Kunnis On 2/2/07, Eric Maslowski wrote: > > Hi Mark, > Unfortunately, I don't have any documents (or know of any) that go into > this, but we've found that the majority of the work is done in "pipeline", > "viewerDisplay", "viewerCamera." > > If you find a comprehensive document which goes over the rendering > pipeline, > I would be highly interested as well. > > Cheers > > E. > > --- > Eric Maslowski > Research Computer Specialist > University of Michigan 3D Lab > > Autodesk 3D Studio Max Certified Trainer > > email: emaslows@umich.edu > office: 734-615-9699 > mobile: 734-730-9904 > > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Mark Wagner > Sent: Thursday, February 01, 2007 23:04 > To: Second Life Developer Mailing List > Subject: [sldev] Rendering > > Is there a document somewhere describing how the client handles > drawing the world? Things like where it stores the scene model, how > it updates it, and how objects are turned into OpenGL primitives? > > -- > Mark > Carnildo Greenacre > _______________________________________________ > 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/20070202/559810bd/attachment.htm From phoenix at secondlife.com Fri Feb 2 09:00:40 2007 From: phoenix at secondlife.com (Phoenix) Date: Fri Feb 2 09:00:56 2007 Subject: [sldev] xmlrpc-epi and expat crash In-Reply-To: <20070202072728.GA32549@spacedout.fries.net> References: <20070202072728.GA32549@spacedout.fries.net> Message-ID: Our instructions on the wiki include steps to remove xmlrpc-epi's copy of expat. Are these insufficient or unclear? https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MS_Windows% 29#XMLRPC-epi On 2007 Feb 1, at 23:27, David Fries wrote: > What do you get when some code is compiled against one set of headers > and other code (in the same program) is compiled against a different > set? Problems, just see my earlier post on 'OpenJPEG MAX_PATH issue' > don't look for a thread, there were no replies on the list. > > I'm guessing that second life just started using some XML that it > wasn't using earlier. Maybe something to do with capabilities and > xmlrpc that wasn't used earlier? Here's the problem. > > xmlrpc-epi-0.51 includes expat, but it is an old version. When I say > includes it, I mean there is a copy in the source directory, and that > verson is compiled into the xmlrpc-epi library. Old enough that it > doesn't even use expat.h which the current expat version does. There > are multipe references to expat.h in the second life source code > indicating that second life is expected to compile against the new > version of expat. > > My solution was to remove expat from xmlrpc-epi and fixup the source > files to reference the new header file name for expat. Another Unix > developer I was talking to was having the same issue and doing what I > did worked for him as well. I would expect other problem to have this > problem as well. > > -- > David Fries > http://fries.net/~david/ (PGP encryption key available) > > _______________________________________________ > 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/20070202/0edc4f48/PGP.pgp From kunnis at gmail.com Fri Feb 2 11:19:38 2007 From: kunnis at gmail.com (Zack Geers) Date: Fri Feb 2 11:19:42 2007 Subject: [sldev] Rendering In-Reply-To: <029501c746fd$26ed8900$f21fd58d@adsroot.itcs.umich.edu> References: <029501c746fd$26ed8900$f21fd58d@adsroot.itcs.umich.edu> Message-ID: I asked Rob L. which one he suggested that I do development work on a few days ago, he suggested FL. It makes sense because FL is basically what the 1.14 branch will be. It sounds like the 1.13.3 branch is pretty much going to be required changes only. OTOH, I've been having a lot of problems with FL, I can't even to get it to run on my system, even though I downloaded the graphics. I'm running winxp64 if anyone has tried it on there yet. Most of the changes in the pipeline deal with changes to the rendering order of graphics, I haven't looked at any of viewpoint code. Kunnis Basiat On 2/2/07, Eric Maslowski wrote: > > I haven't worked with FL yet, but was wondering if that would be a better > code base to develop our stereo viewer for. What are your thoughts on the > recent pipeline changes? > > Thanks > > E. > > --- > Eric Maslowski > Research Computer Specialist > University of Michigan 3D Lab > > Autodesk 3D Studio Max Certified Trainer > > email: emaslows@umich.edu > office: 734-615-9699 > mobile: 734-730-9904 > > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Zack Geers > Sent: Friday, February 02, 2007 11:49 > To: sldev@lists.secondlife.com > Subject: Re: [sldev] Rendering > > The FL client also has a lot of changes in pipeline. > > Kunnis > > > On 2/2/07, Eric Maslowski wrote: > > Hi Mark, > Unfortunately, I don't have any documents (or know of any) that go > into > this, but we've found that the majority of the work is done in > "pipeline", > "viewerDisplay", "viewerCamera." > > If you find a comprehensive document which goes over the rendering > pipeline, > I would be highly interested as well. > > Cheers > > E. > > --- > Eric Maslowski > Research Computer Specialist > University of Michigan 3D Lab > > Autodesk 3D Studio Max Certified Trainer > > email: emaslows@umich.edu > office: 734-615-9699 > mobile: 734-730-9904 > > > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com ] On Behalf Of Mark > Wagner > Sent: Thursday, February 01, 2007 23:04 > To: Second Life Developer Mailing List > Subject: [sldev] Rendering > > Is there a document somewhere describing how the client handles > drawing the world? Things like where it stores the scene model, > how > > it updates it, and how objects are turned into OpenGL primitives? > > -- > Mark > Carnildo Greenacre > _______________________________________________ > 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/20070202/18c3dfd1/attachment.htm From david at fries.net Fri Feb 2 16:29:30 2007 From: david at fries.net (David Fries) Date: Fri Feb 2 16:29:43 2007 Subject: [sldev] xmlrpc-epi and expat crash In-Reply-To: References: <20070202072728.GA32549@spacedout.fries.net> Message-ID: <20070203002930.GF6496@spacedout.fries.net> What instructions? https://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) Anything else I should know about? On Fri, Feb 02, 2007 at 09:00:40AM -0800, Phoenix wrote: > Our instructions on the wiki include steps to remove xmlrpc-epi's > copy of expat. Are these insufficient or unclear? > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MS_Windows% > 29#XMLRPC-epi > > > On 2007 Feb 1, at 23:27, David Fries wrote: > >What do you get when some code is compiled against one set of headers > >and other code (in the same program) is compiled against a different > >set? Problems, just see my earlier post on 'OpenJPEG MAX_PATH issue' > >don't look for a thread, there were no replies on the list. > > > >I'm guessing that second life just started using some XML that it > >wasn't using earlier. Maybe something to do with capabilities and > >xmlrpc that wasn't used earlier? Here's the problem. > > > >xmlrpc-epi-0.51 includes expat, but it is an old version. When I say > >includes it, I mean there is a copy in the source directory, and that > >verson is compiled into the xmlrpc-epi library. Old enough that it > >doesn't even use expat.h which the current expat version does. There > >are multipe references to expat.h in the second life source code > >indicating that second life is expected to compile against the new > >version of expat. > > > >My solution was to remove expat from xmlrpc-epi and fixup the source > >files to reference the new header file name for expat. Another Unix > >developer I was talking to was having the same issue and doing what I > >did worked for him as well. I would expect other problem to have this > >problem as well. > > > >-- > >David Fries > >http://fries.net/~david/ (PGP encryption key available) > > > >_______________________________________________ > >Click here to unsubscribe or manage your list subscription: > >https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- David Fries http://fries.net/~david/ (PGP encryption key available) -------------- 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/20070202/9459b007/attachment.pgp From phoenix at secondlife.com Fri Feb 2 16:50:46 2007 From: phoenix at secondlife.com (Phoenix) Date: Fri Feb 2 16:50:54 2007 Subject: [sldev] xmlrpc-epi and expat crash In-Reply-To: <20070203002930.GF6496@spacedout.fries.net> References: <20070202072728.GA32549@spacedout.fries.net> <20070203002930.GF6496@spacedout.fries.net> Message-ID: <81049DB2-C8DA-44BB-B066-B7FE1DF9791A@secondlife.com> I have added notes on patching to source to the linux build instructions. https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28Linux% 29#Prerequisites On 2007 Feb 2, at 16:29, David Fries wrote: > What instructions? > > https://wiki.secondlife.com/wiki/Compiling_the_viewer_(Linux) > > Anything else I should know about? > > On Fri, Feb 02, 2007 at 09:00:40AM -0800, Phoenix wrote: >> Our instructions on the wiki include steps to remove xmlrpc-epi's >> copy of expat. Are these insufficient or unclear? >> >> https://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MS_Windows% >> 29#XMLRPC-epi >> >> >> On 2007 Feb 1, at 23:27, David Fries wrote: >>> What do you get when some code is compiled against one set of >>> headers >>> and other code (in the same program) is compiled against a different >>> set? Problems, just see my earlier post on 'OpenJPEG MAX_PATH >>> issue' >>> don't look for a thread, there were no replies on the list. >>> >>> I'm guessing that second life just started using some XML that it >>> wasn't using earlier. Maybe something to do with capabilities and >>> xmlrpc that wasn't used earlier? Here's the problem. >>> >>> xmlrpc-epi-0.51 includes expat, but it is an old version. When I >>> say >>> includes it, I mean there is a copy in the source directory, and >>> that >>> verson is compiled into the xmlrpc-epi library. Old enough that it >>> doesn't even use expat.h which the current expat version does. >>> There >>> are multipe references to expat.h in the second life source code >>> indicating that second life is expected to compile against the new >>> version of expat. >>> >>> My solution was to remove expat from xmlrpc-epi and fixup the source >>> files to reference the new header file name for expat. Another Unix >>> developer I was talking to was having the same issue and doing >>> what I >>> did worked for him as well. I would expect other problem to have >>> this >>> problem as well. >>> >>> -- >>> David Fries >>> http://fries.net/~david/ (PGP encryption key available) >>> >>> _______________________________________________ >>> Click here to unsubscribe or manage your list subscription: >>> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > > > -- > David Fries > http://fries.net/~david/ (PGP encryption key available) -------------- 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/20070202/060c7b57/PGP.pgp From robla at lindenlab.com Fri Feb 2 19:49:50 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Feb 2 19:51:16 2007 Subject: [sldev] New First Look source code Message-ID: <45C4065E.20501@lindenlab.com> Hi all, The source code for the First Look viewer binary that Steve announced yesterday (1.13.3.57575) is now available: https://wiki.secondlife.com/wiki/Source_archive Mac developers will need to also download the precompiled libcares library, included at the URL above. Release notes, and further forum discussion about this release is available on the Second Life blog: http://blog.secondlife.com/2007/02/01/first-look-render-pipeline-improvements-update-57575-available/ 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/20070202/1ea8ff5d/signature.pgp From ismail at pardus.org.tr Sat Feb 3 04:09:22 2007 From: ismail at pardus.org.tr (Ismail =?utf-8?q?D=C3=B6nmez?=) Date: Sat Feb 3 04:09:34 2007 Subject: [sldev] New First Look source code In-Reply-To: <45C4065E.20501@lindenlab.com> References: <45C4065E.20501@lindenlab.com> Message-ID: <200702031409.23080.ismail@pardus.org.tr> On Saturday 03 February 2007 05:49:50 Rob Lanphier wrote: > Hi all, > > The source code for the First Look viewer binary that Steve announced > yesterday (1.13.3.57575) is now available: > https://wiki.secondlife.com/wiki/Source_archive Needs following patch to compile with gcc4: --- linden/indra/newview/lltexturecache.h +++ linden/indra/newview/lltexturecache.h @@ -82,8 +82,8 @@ ??????bool readComplete(handle_t handle, bool abort); ??????handle_t writeToCache(const LLUUID& id, U32 priority, U8* data, S32 datasize, S32 imagesize, ?????????????????????????????????????????????? ?WriteResponder* responder); -??????bool LLTextureCache::writeComplete(handle_t handle, bool abort = false); -??????void LLTextureCache::prioritizeWrite(handle_t handle); +??????bool writeComplete(handle_t handle, bool abort = false); +??????void prioritizeWrite(handle_t handle); ??????void removeFromCache(const LLUUID& id); Regards, ismail From robla at lindenlab.com Mon Feb 5 01:10:51 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Feb 5 01:12:20 2007 Subject: [sldev] Subversion RFP posted Message-ID: <45C6F49B.4010506@lindenlab.com> Hi folks, I've posted an RFP for hosting an official Subversion repository here: https://wiki.secondlife.com/wiki/Version_control_repository There's a handful of parties we're already talking to, but I figured it makes sense to open it up. Requirements: * High capacity, high availability anonymous read access, with corresponding SLA * Direct user management by Linden Lab (self-service add/remove/disable accounts) * Self-service password changing for all individual account holders * Minimum 40GB capacity * Ability to completely delete rogue revisions within one business day * Nightly backups * Real-time read access to all raw Subversion data files via ssh/sftp or other secure Additional desirable features: * Integration with outside authentication system, either Kerberos or custom XML-RPC based system. o If relying on external authentication, user management still needed to provide authorization management Proposals being accepted through February 9, 2007. Please send them to me. 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/20070205/3a145140/signature.pgp From seki at fexx.org Sun Feb 4 22:06:13 2007 From: seki at fexx.org (seki@fexx.org) Date: Mon Feb 5 06:11:52 2007 Subject: [sldev] LLVertexProgramGL Message-ID: <1du4dw5sn5fL4L1us14t3.seki@fexx.org> Does anybody know the purpose of LLVertexProgramGL class defined in linden/indra/llrender/llvertexprogramgl.{h,cpp}? It apparently is a class for shader program management, but I found no references to it in Viewer codes. From hud at zurich.ibm.com Mon Feb 5 00:52:09 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Mon Feb 5 06:48:13 2007 Subject: [sldev] Request for LL feedback on avatar scanner features In-Reply-To: <200702020116.42706.dale@daleglass.net> References: <200701310039.50610.dale@daleglass.net> <200702020020.37170.dale@daleglass.net> <45C276EF.3040500@gmail.com> <200702020116.42706.dale@daleglass.net> Message-ID: <45C6F039.80605@zurich.ibm.com> Dale Glass wrote: > [...] >> fact, nearly everything on there can change under some circumstances. >> You are making dangerous assumptions about what will and won't change. >> > It depends on the situation. > > For example, my scanner as originally designed requests payment data and birth > date for everybody around. Birth date is set in stone, payment data even if > it does somehow change to a "lesser" status, it's probably harmless to keep > it like that anyway. Once you look at somebody's profile, the scanner could > use that data without making an extra request to the server to get the same > stuff. > the profile is something the user can change (joining groups, etc.), i'd at least check on its "freshness" once a session perhaps? cheers dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070205/44906ed6/signature.pgp From makosoft at googlemail.com Mon Feb 5 07:59:05 2007 From: makosoft at googlemail.com (Aidan Thornton) Date: Mon Feb 5 07:59:08 2007 Subject: [sldev] LLVertexProgramGL In-Reply-To: <1du4dw5sn5fL4L1us14t3.seki@fexx.org> References: <1du4dw5sn5fL4L1us14t3.seki@fexx.org> Message-ID: On 2/5/07, seki@fexx.org wrote: > Does anybody know the purpose of LLVertexProgramGL class defined in > linden/indra/llrender/llvertexprogramgl.{h,cpp}? > > It apparently is a class for shader program management, but I found no > references to it in Viewer codes. If you can't find any reference to it elsewhere in the viewer code, it's probably dead code from one of LL's abandoned features. I think there's a lot of that in the codebase... From gigstaggart at gmail.com Mon Feb 5 10:29:39 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon Feb 5 10:29:38 2007 Subject: [sldev] [Fwd: TOS Problems] Message-ID: <45C77793.5000700@gmail.com> Here is the letter I sent to Ginsu after the conversation on IRC where several developers voiced concerns about the TOS rendering the GPL ineffective. I decided to post it publicly here so we can get this out in the open. -------------- next part -------------- An embedded message was scrubbed... From: Jason Giglio Subject: TOS Problems Date: Sun, 04 Feb 2007 20:03:56 -0500 Size: 1756 Url: http://lists.secondlife.com/pipermail/sldev/attachments/20070205/8a41f0d6/TOSProblems.eml From mathew at lifeart.net.au Mon Feb 5 12:51:44 2007 From: mathew at lifeart.net.au (Mathew Frank) Date: Mon Feb 5 12:51:48 2007 Subject: [sldev] [Fwd: TOS Problems] In-Reply-To: <45C77793.5000700@gmail.com> References: <45C77793.5000700@gmail.com> Message-ID: <45C798E0.3050409@lifeart.net.au> Thanks, Jason. This is a big concern most (all?) of us who are aware of it - either directly, or due to the impact of potentially deep-sixing work on the GPL view project itself. I look forward to this being cleared up. Cheers, Mathew Jason Giglio wrote: > Here is the letter I sent to Ginsu after the conversation on IRC where > several developers voiced concerns about the TOS rendering the GPL > ineffective. > > I decided to post it publicly here so we can get this out in the open. > > > __________ NOD32 2038 (20070205) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > ------------------------------------------------------------------------ > > Subject: > TOS Problems > From: > Jason Giglio > Date: > Sun, 04 Feb 2007 20:03:56 -0500 > To: > ginsu@lindenlab.com > > To: > ginsu@lindenlab.com > > > Hello, > > There are some problems with the TOS. > > "Further, you may use and modify the source code for the Viewer as > permitted by any open source license agreement under which Linden Lab > distributes such Viewer source code." > > You forgot to allow distribution. This would be better: > > "Further, you may use, modify, and distribute the source code for the > Viewer as permitted by any open source license agreement under which > Linden Lab distributes such Viewer source code." > > Of course, the GPL allows selling the software, so you might need to > revise the portion forbidding anyone from charging for access. > > Several open source developers (including myself) have a problem with > this clause: > > "Linden Lab is not obligated to allow access to the Servers by any > software that is not provided by Linden Lab, and you agree to cease > using, creating, distributing or providing any such software at the > request of Linden Lab." > > Their primary concern is that this clause is so broad that it renders > the GPL ineffective. > > My primary concern with it is that it makes it impossible to enter > into a contract to develop viewer-like functionality. > > If Party A contracts me to write interactive agent software, or other > software that does functions similar to the viewer, and I agree to > provide it, LL can compel me to violate my contract with Party A. > This is an unacceptable risk. > > Thanks, > Jason > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > __________ NOD32 2038 (20070205) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070206/c9328dc4/attachment.htm From robla at lindenlab.com Mon Feb 5 13:51:20 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Feb 5 13:52:50 2007 Subject: [sldev] [Fwd: TOS Problems] In-Reply-To: <45C798E0.3050409@lifeart.net.au> References: <45C77793.5000700@gmail.com> <45C798E0.3050409@lifeart.net.au> Message-ID: <45C7A6D8.1000209@lindenlab.com> I'll have a conversation with Ginsu about this about the TOS as soon as I can. However, it looks like he's in Europe on business this week and probably has a pretty full itinerary over there, which is going to make real-time communication a little difficult. We have no intention of rendering the GPL ineffective. I would like to point out that this agreement governs the terms of service for Second Life, not the terms associated with the software itself. You have whatever rights the GPL gives you to the software; however, we have the right to limit how you use our service. It's going to be very difficult for us to economically preserve access to our service if we don't have the legal tools to prohibit usage of abusive clients. I don't feel comfortable getting into any more detail on this subject without consulting Ginsu on it. Sorry, I can't give you a timeline on when/how we can resolve this issue until I get a chance to talk to him. 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/20070205/ca369a3b/signature.pgp From dale at daleglass.net Mon Feb 5 14:27:58 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Feb 5 14:28:17 2007 Subject: [sldev] [Fwd: TOS Problems] In-Reply-To: <45C7A6D8.1000209@lindenlab.com> References: <45C77793.5000700@gmail.com> <45C798E0.3050409@lifeart.net.au> <45C7A6D8.1000209@lindenlab.com> Message-ID: <200702052328.03716.dale@daleglass.net> ? ????????? ?? 5 ??????? 2007 22:51 Rob Lanphier ???????(a): > We have no intention of rendering the GPL ineffective. I would like to > point out that this agreement governs the terms of service for Second > Life, not the terms associated with the software itself. You have > whatever rights the GPL gives you to the software; however, we have the > right to limit how you use our service. It's going to be very difficult > for us to economically preserve access to our service if we don't have > the legal tools to prohibit usage of abusive clients. This part is perfectly fine: "Linden Lab is not obligated to allow access to the Servers by any software that is not provided by Linden Lab" Now this would be what is problematic and conflicts with the GPL: "and you agree to cease using, creating, distributing or providing any such software at the request of Linden Lab." -------------- 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/20070205/02fc5b0f/attachment.pgp From aestes at acm.org Tue Feb 6 06:28:53 2007 From: aestes at acm.org (Andy Estes) Date: Tue Feb 6 06:30:38 2007 Subject: [sldev] Unused files in source tree Message-ID: <005f01c749fb$2305f380$6911da80$@org> Could any Lindens (or others) comment on the unused files in the source tree? llvotreenew.{cpp,h} llvodrawpooltreenew.{cpp,h} Are these planned replacements or abandoned versions? FL: Andy SL: Drewan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070206/7c4c4f20/attachment.htm From tcallawa at redhat.com Tue Feb 6 11:44:48 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue Feb 6 11:45:21 2007 Subject: [sldev] license for static content Message-ID: <1170791088.12347.15.camel@localhost.localdomain> Hi Second Life Developers, With the open sourcing of the slviewer code, there is a lot of interest in packaging the bits up for Fedora. However, we've run into a minor snag: The slviewer seems to need the static_index.db2 and static_data.db2 files in order to do anything useful. What is the license on these data files? Are they freely redistributable? If we can't freely include and redistribute these data files (at a bare minimum, it would be nice to freely be able to edit these data files as well, but not required), then we can't really include slviewer in Fedora. This was originally raised here: http://forums.secondlife.com/showthread.php?p=1402381 Thanks in advance, Tom "spot" Callaway aka Snake Plisskin Fedora/Red Hat From mindtriggerz at gmail.com Tue Feb 6 12:02:04 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Tue Feb 6 12:02:12 2007 Subject: [sldev] license for static content In-Reply-To: <1170791088.12347.15.camel@localhost.localdomain> References: <1170791088.12347.15.camel@localhost.localdomain> Message-ID: Good question. The answer is that noone is quite sure. I believe we were talking about this in IRC the other day.. On 2/6/07, Tom 'spot' Callaway wrote: > Hi Second Life Developers, > > With the open sourcing of the slviewer code, there is a lot of interest > in packaging the bits up for Fedora. However, we've run into a minor > snag: > > The slviewer seems to need the static_index.db2 and static_data.db2 > files in order to do anything useful. What is the license on these data > files? Are they freely redistributable? > > If we can't freely include and redistribute these data files (at a bare > minimum, it would be nice to freely be able to edit these data files as > well, but not required), then we can't really include slviewer in > Fedora. > > This was originally raised here: > > http://forums.secondlife.com/showthread.php?p=1402381 > > Thanks in advance, > > Tom "spot" Callaway > aka Snake Plisskin > > Fedora/Red Hat > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- --Jesse From tcallawa at redhat.com Tue Feb 6 12:05:07 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue Feb 6 12:05:43 2007 Subject: [sldev] license for static content In-Reply-To: References: <1170791088.12347.15.camel@localhost.localdomain> Message-ID: <1170792307.19237.2.camel@localhost.localdomain> On Tue, 2007-02-06 at 15:02 -0500, Jesse Nesbitt wrote: > Good question. The answer is that noone is quite sure. I believe we > were talking about this in IRC the other day.. Alright. Hopefully the right folks to get an answer for this (in writing, in the source tarball or in the static_* tarballs) will see this. ~spot From robla at lindenlab.com Tue Feb 6 16:20:13 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Feb 6 16:21:34 2007 Subject: [sldev] First Look 1.13.3.57679 source code Message-ID: <45C91B3D.6050103@lindenlab.com> Hi folks, The source code for the First Look viewer is available (actually posted last night): https://wiki.secondlife.com/wiki/Source_downloads See Steve Linden's blog posting for the list of changes, as well as a comment area that he's monitoring for issue reports: http://blog.secondlife.com/2007/02/05/first-look-1134-now-available/ 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/20070206/fd3b012c/signature.pgp From robla at lindenlab.com Tue Feb 6 16:22:10 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Feb 6 16:23:27 2007 Subject: [sldev] license for static content In-Reply-To: <1170792307.19237.2.camel@localhost.localdomain> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> Message-ID: <45C91BB2.7070605@lindenlab.com> On 2/6/07 12:05 PM, Tom 'spot' Callaway wrote: > On Tue, 2007-02-06 at 15:02 -0500, Jesse Nesbitt wrote: > >> Good question. The answer is that noone is quite sure. I believe we >> were talking about this in IRC the other day.. >> > > Alright. Hopefully the right folks to get an answer for this (in > writing, in the source tarball or in the static_* tarballs) will see > this. > Hi folks, Sorry for the delay in responding to this. You'll notice that the library distributions in 1.13.3.57679 contains LICENSE-logos.txt, which applies to the artwork distributed there: > Logos and trademarks > ============== > > "Second Life" and "Linden Lab" are registered trademarks of Linden > Research, Inc. Other trademarks include (but are not limited to): the > names Linden and Linden Research, as well as the Linden Lab Hexagon > Design and the Second Life Hand Design logos. > > Use of logos and trademarks are subject to the Linden Lab trademark > policy, available at: > > http://secondlife.com/corporate/trademark/ Hope this helps, 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/20070206/1bd1f848/signature.pgp From tcallawa at redhat.com Tue Feb 6 16:29:20 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue Feb 6 16:30:01 2007 Subject: [sldev] license for static content In-Reply-To: <45C91BB2.7070605@lindenlab.com> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> Message-ID: <1170808160.19237.9.camel@localhost.localdomain> On Tue, 2007-02-06 at 16:22 -0800, Rob Lanphier wrote: > On 2/6/07 12:05 PM, Tom 'spot' Callaway wrote: > > On Tue, 2007-02-06 at 15:02 -0500, Jesse Nesbitt wrote: > > > >> Good question. The answer is that noone is quite sure. I believe we > >> were talking about this in IRC the other day.. > >> > > > > Alright. Hopefully the right folks to get an answer for this (in > > writing, in the source tarball or in the static_* tarballs) will see > > this. > > > Hi folks, > > Sorry for the delay in responding to this. You'll notice that the > library distributions in 1.13.3.57679 contains LICENSE-logos.txt, which > applies to the artwork distributed there: So... err. All this has managed is further confusion on my part. Can we (Fedora) legally redistribute the static content? ~spot From robla at lindenlab.com Tue Feb 6 16:42:06 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Feb 6 16:43:22 2007 Subject: [sldev] license for static content In-Reply-To: <1170808160.19237.9.camel@localhost.localdomain> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> Message-ID: <45C9205E.20003@lindenlab.com> On 2/6/07 4:29 PM, Tom 'spot' Callaway wrote: > On Tue, 2007-02-06 at 16:22 -0800, Rob Lanphier wrote: > >> On 2/6/07 12:05 PM, Tom 'spot' Callaway wrote: >> >>> On Tue, 2007-02-06 at 15:02 -0500, Jesse Nesbitt wrote: >>> >>> >>>> Good question. The answer is that noone is quite sure. I believe we >>>> were talking about this in IRC the other day.. >>>> >>>> >>> Alright. Hopefully the right folks to get an answer for this (in >>> writing, in the source tarball or in the static_* tarballs) will see >>> this. >>> >>> >> Hi folks, >> >> Sorry for the delay in responding to this. You'll notice that the >> library distributions in 1.13.3.57679 contains LICENSE-logos.txt, which >> applies to the artwork distributed there: >> > > So... err. All this has managed is further confusion on my part. > > Can we (Fedora) legally redistribute the static content? > Per the FAQ referenced at the trademark policy: > > Can I distribute any of the Linden viewer software from my website, by > CD, or to my friends, employees or students? > > Yes. > Further questions should be addressed to the licensing@lindenlab.com alias. My apologies for the backlog there; we've had quite a few issues sent there, so please be patient. 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/20070206/1de7274a/signature.pgp From jhurliman at wsu.edu Tue Feb 6 16:54:34 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Feb 6 16:54:48 2007 Subject: [sldev] license for static content In-Reply-To: <1170808160.19237.9.camel@localhost.localdomain> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> Message-ID: <45C9234A.3020303@wsu.edu> Tom 'spot' Callaway wrote: > On Tue, 2007-02-06 at 16:22 -0800, Rob Lanphier wrote: > >> On 2/6/07 12:05 PM, Tom 'spot' Callaway wrote: >> >>> On Tue, 2007-02-06 at 15:02 -0500, Jesse Nesbitt wrote: >>> >>> >>>> Good question. The answer is that noone is quite sure. I believe we >>>> were talking about this in IRC the other day.. >>>> >>>> >>> Alright. Hopefully the right folks to get an answer for this (in >>> writing, in the source tarball or in the static_* tarballs) will see >>> this. >>> >>> >> Hi folks, >> >> Sorry for the delay in responding to this. You'll notice that the >> library distributions in 1.13.3.57679 contains LICENSE-logos.txt, which >> applies to the artwork distributed there: >> > > So... err. All this has managed is further confusion on my part. > > Can we (Fedora) legally redistribute the static content? > > ~spot > http://secondlife.com/corporate/trademark/distribution.php says: "Those taking full advantage of the open-source elements of Linden's products and making significant functional changes may not redistribute the fruits of their labor under any Linden trademark." Further up the page it says that distribution of unaltered binaries (including Linden trademarks) is fine. So from my understanding, Fedora redistributing the static content along with viewer source code and/or a compiled viewer is fine, but opensecondlife.org redistributing the static content along with their modified viewer is infringing. John Hurliman From gigstaggart at gmail.com Tue Feb 6 19:10:51 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 6 19:10:57 2007 Subject: [sldev] license for static content In-Reply-To: <45C9205E.20003@lindenlab.com> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> <45C9205E.20003@lindenlab.com> Message-ID: <45C9433B.3000308@gmail.com> John Hurliman wrote: > > http://secondlife.com/corporate/trademark/distribution.php says: > > "Those taking full advantage of the open-source elements of Linden's > products and making significant functional changes may not redistribute > the fruits of their labor under any Linden trademark." > > Further up the page it says that distribution of unaltered binaries > (including Linden trademarks) is fine. So from my understanding, Fedora > redistributing the static content along with viewer source code and/or a > compiled viewer is fine, but opensecondlife.org redistributing the > static content along with their modified viewer is infringing. Red Hat often patches versions they distribute. It is likely they can't distribute a version with trademarks either. That really doesn't even address whether the static cache that doesn't contain trademarks can be distributed or not. There's tons of assets there that are not trademark material. From robla at lindenlab.com Tue Feb 6 21:03:06 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Feb 6 21:04:29 2007 Subject: [sldev] license for static content In-Reply-To: <45C9433B.3000308@gmail.com> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> <45C9205E.20003@lindenlab.com> <45C9433B.3000308@gmail.com> Message-ID: <45C95D8A.6030708@lindenlab.com> On 2/6/07 7:10 PM, Jason Giglio wrote: > John Hurliman wrote: > > > > http://secondlife.com/corporate/trademark/distribution.php says: > > > > "Those taking full advantage of the open-source elements of Linden's > > products and making significant functional changes may not redistribute > > the fruits of their labor under any Linden trademark." > > > > Further up the page it says that distribution of unaltered binaries > > (including Linden trademarks) is fine. So from my understanding, Fedora > > redistributing the static content along with viewer source code > and/or a > > compiled viewer is fine, but opensecondlife.org redistributing the > > static content along with their modified viewer is infringing. > > Red Hat often patches versions they distribute. It is likely they > can't distribute a version with trademarks either. The policy says "significant functional changes". I am assuming that any Red Hat patches would be minor integration issues, such as changing locations for files, but not behavioral changes. Assuming they maintain a similar policy toward the Second Life viewer as they do with other open source projects that maintain strict trademark guidelines (e.g. Firefox), they should be just fine. > That really doesn't even address whether the static cache that doesn't > contain trademarks can be distributed or not. There's tons of assets > there that are not trademark material. We have a discussion internally already about this issue, but I don't imagine it'll get solved this week (while Ginsu is out). In the meantime, it's easiest to lump them all together. 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/20070206/1350f9be/signature-0001.pgp From tcallawa at redhat.com Tue Feb 6 21:11:16 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue Feb 6 21:11:50 2007 Subject: [sldev] license for static content In-Reply-To: <45C95D8A.6030708@lindenlab.com> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> <45C9205E.20003@lindenlab.com> <45C9433B.3000308@gmail.com> <45C95D8A.6030708@lindenlab.com> Message-ID: <1170825076.19237.15.camel@localhost.localdomain> On Tue, 2007-02-06 at 21:03 -0800, Rob Lanphier wrote: > The policy says "significant functional changes". I am assuming that > any Red Hat patches would be minor integration issues, such as changing > locations for files, but not behavioral changes. Assuming they maintain > a similar policy toward the Second Life viewer as they do with other > open source projects that maintain strict trademark guidelines (e.g. > Firefox), they should be just fine. Yes, right now, we're just patching for the following: - file locations - using gcc4 - not using closed source bits - not using precompiled libraries I don't really see us doing "significant functional changes". That doesn't really benefit our users, nor Linden. If we did, we'd certainly take them upstream rather than introduce them in the Fedora package. > > That really doesn't even address whether the static cache that doesn't > > contain trademarks can be distributed or not. There's tons of assets > > there that are not trademark material. > We have a discussion internally already about this issue, but I don't > imagine it'll get solved this week (while Ginsu is out). In the > meantime, it's easiest to lump them all together. Is there any chance of providing the static content tarballs independently of the library tarballs online? I can certainly pull them out and package them by hand, but it would be a LOT easier if they were kept separately for those of us who choose not to use the precompiled binary libraries. ~spot From gigstaggart at gmail.com Wed Feb 7 07:34:48 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Feb 7 07:34:52 2007 Subject: [sldev] Distribution of openjpeg In-Reply-To: <1170825076.19237.15.camel@localhost.localdomain> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> <45C9205E.20003@lindenlab.com> <45C9433B.3000308@gmail.com> <45C95D8A.6030708@lindenlab.com> <1170825076.19237.15.camel@localhost.localdomain> Message-ID: <45C9F198.80501@gmail.com> Tom 'spot' Callaway wrote: > On Tue, 2007-02-06 at 21:03 -0800, Rob Lanphier wrote: > >> The policy says "significant functional changes". I am assuming that >> any Red Hat patches would be minor integration issues, such as changing >> locations for files, but not behavioral changes. Assuming they maintain >> a similar policy toward the Second Life viewer as they do with other >> open source projects that maintain strict trademark guidelines (e.g. >> Firefox), they should be just fine. > > Yes, right now, we're just patching for the following: > > - file locations > - using gcc4 > - not using closed source bits > - not using precompiled libraries Tom, Had a brief discussion with Mike Harris on IRC about openjpeg. I know he's not Fedora Leadership, and they would probably be best to consult about this, but he said that Red Hat would likely have to run openjpeg through an official approval process before it could be included in Fedora. The issue with openjpeg is the patents. The numerous applicable patents are only licensed freely for an ISO Compliant implementation of jpeg2000. It is for this reason openjpeg is not DFSG compliant, because it has encumbrance on the right to modify (into something not ISO compliant). I don't know if openjpeg has ever been through any official vetting for ISO compliance or not. It is something else you will probably need to consider. -Jason From peekay at targetomega.com Wed Feb 7 10:54:10 2007 From: peekay at targetomega.com (Peekay Semyorka) Date: Wed Feb 7 10:54:19 2007 Subject: [sldev] Distribution of openjpeg In-Reply-To: <45C9F198.80501@gmail.com> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> <45C9205E.20003@lindenlab.com> <45C9433B.3000308@gmail.com> <45C95D8A.6030708@lindenlab.com> <1170825076.19237.15.camel@localhost.localdomain> <45C9F198.80501@gmail.com> Message-ID: <4375.64.231.233.184.1170874450.squirrel@webmail.bluewax.com> > It is for this reason openjpeg is not DFSG compliant, because > it has encumbrance on the right to modify (into something not ISO > compliant). OpenJPEG has no such limitation. The library is distributed under a vanilla BSD-license. So strictly speaking, OpenJPEG should be DFSG compliant. Of course, it's possible to modify OpenJPEG until it infringes on a patent somewhere, but that is possible with any software. We can each modify the SL-Viewer until it infringes on a number of patents; that does not make the SL-Viewer itself non-free. OpenJPEG is a compliant Jpeg2000 implementation, having passed the P1C1 & J2F conformance tests (though strict compliance is not required by the patent declarations.) It's still possible that the Part 1 standard itself is infringing on an unknown patent, but again that is a separate issue. $0.02, -peekay From tcallawa at redhat.com Wed Feb 7 11:09:27 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed Feb 7 11:10:08 2007 Subject: [sldev] Distribution of openjpeg In-Reply-To: <4375.64.231.233.184.1170874450.squirrel@webmail.bluewax.com> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> <45C9205E.20003@lindenlab.com> <45C9433B.3000308@gmail.com> <45C95D8A.6030708@lindenlab.com> <1170825076.19237.15.camel@localhost.localdomain> <45C9F198.80501@gmail.com> <4375.64.231.233.184.1170874450.squirrel@webmail.bluewax.com> Message-ID: <1170875367.4802.10.camel@dhcp-32-109.ord.redhat.com> On Wed, 2007-02-07 at 18:54 +0000, Peekay Semyorka wrote: > > It is for this reason openjpeg is not DFSG compliant, because > > it has encumbrance on the right to modify (into something not ISO > > compliant). > > OpenJPEG has no such limitation. The library is distributed under a > vanilla BSD-license. So strictly speaking, OpenJPEG should be DFSG > compliant. > > Of course, it's possible to modify OpenJPEG until it infringes on a patent > somewhere, but that is possible with any software. We can each modify the > SL-Viewer until it infringes on a number of patents; that does not make > the SL-Viewer itself non-free. > > OpenJPEG is a compliant Jpeg2000 implementation, having passed the P1C1 & > J2F conformance tests (though strict compliance is not required by the > patent declarations.) It's still possible that the Part 1 standard itself > is infringing on an unknown patent, but again that is a separate issue. FWIW, this is also my opinion on the matter. ~spot From gigstaggart at gmail.com Wed Feb 7 13:11:36 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Feb 7 13:11:34 2007 Subject: [sldev] Distribution of openjpeg In-Reply-To: <4375.64.231.233.184.1170874450.squirrel@webmail.bluewax.com> References: <1170791088.12347.15.camel@localhost.localdomain> <1170792307.19237.2.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> <45C9205E.20003@lindenlab.com> <45C9433B.3000308@gmail.com> <45C95D8A.6030708@lindenlab.com> <1170825076.19237.15.camel@localhost.localdomain> <45C9F198.80501@gmail.com> <4375.64.231.233.184.1170874450.squirrel@webmail.bluewax.com> Message-ID: <45CA4088.8080205@gmail.com> Peekay Semyorka wrote: >> It is for this reason openjpeg is not DFSG compliant, because >> it has encumbrance on the right to modify (into something not ISO >> compliant). > > OpenJPEG has no such limitation. The library is distributed under a > vanilla BSD-license. So strictly speaking, OpenJPEG should be DFSG > compliant. Hmm It looks like you are right. Debian is including Jasper now, though they only recently reconsidered their position, looks like they added it in late December. Previous to that they had rejected it on the basis that it was DFSG non-compliant due to the patent situation. -Jason From fodprolux at gmail.com Thu Feb 8 08:36:01 2007 From: fodprolux at gmail.com (Francois-Olivier Devaux) Date: Thu Feb 8 08:36:06 2007 Subject: [sldev] Distribution of openjpeg In-Reply-To: <45CA4088.8080205@gmail.com> References: <1170791088.12347.15.camel@localhost.localdomain> <45C91BB2.7070605@lindenlab.com> <1170808160.19237.9.camel@localhost.localdomain> <45C9205E.20003@lindenlab.com> <45C9433B.3000308@gmail.com> <45C95D8A.6030708@lindenlab.com> <1170825076.19237.15.camel@localhost.localdomain> <45C9F198.80501@gmail.com> <4375.64.231.233.184.1170874450.squirrel@webmail.bluewax.com> <45CA4088.8080205@gmail.com> Message-ID: <60ce64890702080836i65cc86b5v1c3efb92c21412fc@mail.gmail.com> Hi, I am Fran?ois-Olivier Devaux, a member of the OpenJPEG team (TELE laboratory at UCL - Universit? catholique de Louvain). It is important to separate JPEG 2000 implementation license issues, and the patent situation of the JPEG 2000 algorithm. OpenJPEG, an implementation of the JPEG 2000 standard, is distributed under a BSD license. UCL has been involved since quite a long time in the JPEG standardization process (ISO), and OpenJPEG is the reference implementation to generate JPWL bitstreams (part 11 of the JPEG 2000 standard). The JPEG 2000 committee has and taken all possible measures to avoid patents claims (and an agreement has been reached with over 20 large organizations holding many patents in this area to allow use of their intellectual property in connection with the standard without payment of license fees or royalties). Believe me, this threat has been taken very seriously by the committee. However, risk zero does not exist in the patent field, and like any algorithm, submarine patents may be present. This has not frightened the biggest Hollywood studios to select JPEG 2000 as compression algorithm for Digital Cinema (among other interesting features about JPEG 2000, they were interested this free licensing). Regarding the possible JPEG 2000 patents claim, this problem may be applied to any JPEG 2000 implementation, Jasper, Kakadu, JJ2000 among others. So I think we can say that there is no licensing issue with OpenJPEG in Second Life. In another topic, several persons have contacted us to optimize the code. We're very happy about that, and invite everybody interested in improving the code to contact us at openjpeg at tele.ucl.ac.be -- Fran?ois-Olivier www.openjpeg.org On 2/7/07, Jason Giglio wrote: > > Peekay Semyorka wrote: > >> It is for this reason openjpeg is not DFSG compliant, because > >> it has encumbrance on the right to modify (into something not ISO > >> compliant). > > > > OpenJPEG has no such limitation. The library is distributed under a > > vanilla BSD-license. So strictly speaking, OpenJPEG should be DFSG > > compliant. > > Hmm It looks like you are right. Debian is including Jasper now, though > they only recently reconsidered their position, looks like they added it > in late December. > > Previous to that they had rejected it on the basis that it was DFSG > non-compliant due to the patent situation. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070208/aa87f1ad/attachment.htm From gigstaggart at gmail.com Thu Feb 8 09:20:36 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu Feb 8 09:20:32 2007 Subject: [sldev] OpenJPEG Optimizations Message-ID: <45CB5BE4.7000000@gmail.com> Thank you for your reply regarding OpenJPEG licensing. I do not have the skill currently to help much improving OpenJPEG efficiency, but I have gathered up all the information I could find on it. Here is what I have come up with: https://wiki.secondlife.com/wiki/Openjpeg_improvements Bushing's profiling shows that the DWT, particularly the 9/7 is where the bottleneck is for SL. Improvements: Use in-place DWT. Use lifting implementations rather than the current implementation. Use SSE/MMX to get a speed increase. I have found several lifting implementations of 5/3 and 9/7, but it seems that all of them are floating point rather than integer. I don't know how useful they would be. Please coordinate with the SL developers on that wiki page or here on the mailing list. If you could forward this to anyone who has contacted you so that we can all work together that would be best. Thanks. -Jason From ismail at pardus.org.tr Thu Feb 8 10:44:28 2007 From: ismail at pardus.org.tr (Ismail =?utf-8?q?D=C3=B6nmez?=) Date: Thu Feb 8 10:44:40 2007 Subject: [sldev] First Look 1.13.3.57679 source code In-Reply-To: <45C91B3D.6050103@lindenlab.com> References: <45C91B3D.6050103@lindenlab.com> Message-ID: <200702082044.28989.ismail@pardus.org.tr> On Wednesday 07 February 2007 02:20:13 Rob Lanphier wrote: > Hi folks, > > The source code for the First Look viewer is available (actually posted > last night): > https://wiki.secondlife.com/wiki/Source_downloads > > See Steve Linden's blog posting for the list of changes, as well as a > comment area that he's monitoring for issue reports: > http://blog.secondlife.com/2007/02/05/first-look-1134-now-available/ Am I the only one getting something broken like this: http://cekirdek.pardus.org.tr/~ismail/tmp/broken.png ? Regards, ismail From ismail at pardus.org.tr Thu Feb 8 22:47:17 2007 From: ismail at pardus.org.tr (Ismail =?iso-8859-1?q?D=F6nmez?=) Date: Thu Feb 8 22:47:23 2007 Subject: [sldev] First Look 1.13.3.57679 source code In-Reply-To: <20070209044717.GA9336@spacedout.fries.net> References: <45C91B3D.6050103@lindenlab.com> <200702082044.28989.ismail@pardus.org.tr> <20070209044717.GA9336@spacedout.fries.net> Message-ID: <200702090847.18375.ismail@pardus.org.tr> On Friday 09 February 2007 06:47:19 you wrote: > On Thu, Feb 08, 2007 at 08:44:28PM +0200, Ismail D??nmez wrote: > > Am I the only one getting something broken like this: > > http://cekirdek.pardus.org.tr/~ismail/tmp/broken.png ? > > What is your configuration? I'm on AMD x86_64, OpenJPEG, ATI Radeon > Xpress 1100. Pentium M, using KKU binary libs, Intel i915 Regards, ismail From david at fries.net Thu Feb 8 20:47:18 2007 From: david at fries.net (David Fries) Date: Thu Feb 8 23:24:41 2007 Subject: [sldev] First Look 1.13.3.57679 source code In-Reply-To: <200702082044.28989.ismail@pardus.org.tr> References: <45C91B3D.6050103@lindenlab.com> <200702082044.28989.ismail@pardus.org.tr> Message-ID: <20070209044717.GA9336@spacedout.fries.net> On Thu, Feb 08, 2007 at 08:44:28PM +0200, Ismail D??nmez wrote: > Am I the only one getting something broken like this: > http://cekirdek.pardus.org.tr/~ismail/tmp/broken.png ? What is your configuration? I'm on AMD x86_64, OpenJPEG, ATI Radeon Xpress 1100. That looks like exactly what I'm seeing. Then when I get logged in pretty much nothing of the UI has any textures applied. The jpeg 2000 texture decoding isn't blocking the rendering like it used to (which is good), but textures take a very long time to appear. I logged in at the International Spaceflight Museum (Spaceport Alpha 49,81,24) and even after 15 minutes most things didn't have textures. If I enable 'HTTP Get Textures' it crashes when it receives a SIGPIPE. I don't know if this is a second life or a libcurl issue. -- David Fries http://fries.net/~david/ (PGP encryption key available) From david at fries.net Thu Feb 8 23:35:01 2007 From: david at fries.net (David Fries) Date: Thu Feb 8 23:35:05 2007 Subject: [sldev] OpenJPEG usuable now Message-ID: <20070209073501.GB9336@spacedout.fries.net> I'm a bit excited. I have some patches that I'm working on, but I was just able to fly a loop around a three region area just now with them and it seemed comparable to the binary client. This is with OpenJPEG and the first look source client on a Linux dual core 64 bit AMD machine. Good enough that I'm going to have to fly around it again with the binary version and compare. Any suggestions on how to compare the performance between them? My qualitative experience tonight says that it is good enough to run with. Up until tonight it was like pulling teeth using OpenJPEG, so bad, now it looks good. I hacked OpenJPEG to have an opj_meta_decode that would only decode enough to get the size and number of channels. That's all getMetadata used anyway. That patch needs to be cleaned up and submitted to OpenJPEG. But here are the results. A full decode can take anywhere on the order of .015 to .5 seconds (though I've seen 1.5 seconds before). Currently Second Life does a full decode, saves the image size and channels, then tosses the image. This OpenJPEG meta decode just gets enough header decoded to get at the image sizes, and it AVERAGED at .000076 seconds that's with 6200 samples and all but two under 1 millisecond. That's a total of .474 seconds spent in OpenJPEG getMetadata decode, or about the time it takes to decode a large image. There is a function, LLImageJ2C::validate that calls mImpl->getMetadata in llimage/llimagej2c.cpp, my question is how much validation is required to be done to the image? I only see that function being called by LLViewerImageList::createUploadFile. Seriously though, does it just need to find out if it has a jpeg header without looking at any data? In that case the meta decode should work. The last piece of the puzzle was based on a patch on jira by Hiro Sommambulist, VWR-66. Without that patch textures decoded at say a 1/8 resolution would only take up 1/8 of the size leaving the rest blank and grow from there until it was fully decoded. Some of his math didn't make sense to me, but it was enough to point me in the right direction. I have some cleanup work to do on that patch as well. Of course it wouldn't have been possible without the first look viewer FL-1.13.3.57679 doing the actual jpeg2000 decoding in another thread. I wasn't going to go as far as time slicing the decoding like the proprietary decoder does. In my previous e-mail where things were still gray after an hour at the International Spaceflight Museum? It was good in under a minute. -- David Fries http://fries.net/~david/ (PGP encryption key available) -------------- 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/20070209/8453d14f/attachment.pgp From james.w.dumay at gmail.com Fri Feb 9 00:29:01 2007 From: james.w.dumay at gmail.com (James Dumay) Date: Fri Feb 9 00:29:04 2007 Subject: [sldev] OpenJPEG usuable now In-Reply-To: <20070209073501.GB9336@spacedout.fries.net> References: <20070209073501.GB9336@spacedout.fries.net> Message-ID: <139722840702090029p19ffc444l4e4e4c30f2b87a96@mail.gmail.com> Awesome! Congrats! On 2/9/07, David Fries wrote: > > I'm a bit excited. > > I have some patches that I'm working on, but I was just able to fly a > loop around a three region area just now with them and it seemed > comparable to the binary client. This is with OpenJPEG and the first > look source client on a Linux dual core 64 bit AMD machine. Good > enough that I'm going to have to fly around it again with the binary > version and compare. Any suggestions on how to compare the > performance between them? My qualitative experience tonight says that > it is good enough to run with. Up until tonight it was like pulling > teeth using OpenJPEG, so bad, now it looks good. > > I hacked OpenJPEG to have an opj_meta_decode that would only decode > enough to get the size and number of channels. That's all getMetadata > used anyway. That patch needs to be cleaned up and submitted to > OpenJPEG. But here are the results. > > A full decode can take anywhere on the order of .015 to .5 seconds > (though I've seen 1.5 seconds before). Currently Second Life does a > full decode, saves the image size and channels, then tosses the image. > This OpenJPEG meta decode just gets enough header decoded to get at > the image sizes, and it AVERAGED at .000076 seconds that's with 6200 > samples and all but two under 1 millisecond. That's a total of .474 > seconds spent in OpenJPEG getMetadata decode, or about the time it > takes to decode a large image. > > There is a function, LLImageJ2C::validate that calls > mImpl->getMetadata in llimage/llimagej2c.cpp, my question is how much > validation is required to be done to the image? I only see that > function being called by LLViewerImageList::createUploadFile. > Seriously though, does it just need to find out if it has a jpeg > header without looking at any data? In that case the meta decode > should work. > > The last piece of the puzzle was based on a patch on jira by Hiro > Sommambulist, VWR-66. Without that patch textures decoded at say a > 1/8 resolution would only take up 1/8 of the size leaving the rest > blank and grow from there until it was fully decoded. Some of his > math didn't make sense to me, but it was enough to point me in the > right direction. I have some cleanup work to do on that patch as > well. > > Of course it wouldn't have been possible without the first look viewer > FL-1.13.3.57679 doing the actual jpeg2000 decoding in another thread. > I wasn't going to go as far as time slicing the decoding like the > proprietary decoder does. > > In my previous e-mail where things were still gray after an hour at > the International Spaceflight Museum? It was good in under a minute. > > -- > David Fries > http://fries.net/~david/ (PGP encryption key available) > > _______________________________________________ > 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/20070209/206b7c20/attachment.htm From fodprolux at gmail.com Fri Feb 9 05:11:42 2007 From: fodprolux at gmail.com (Francois-Olivier Devaux) Date: Fri Feb 9 05:11:46 2007 Subject: [sldev] OpenJPEG Optimizations In-Reply-To: <45CB5BE4.7000000@gmail.com> References: <45CB5BE4.7000000@gmail.com> Message-ID: <60ce64890702090511l33d6061avfca88974d060acf2@mail.gmail.com> Ok, the coordination will be done through the https://wiki.secondlife.com/wiki/Openjpeg_improvements page. Fran?ois On 2/8/07, Jason Giglio wrote: > > Thank you for your reply regarding OpenJPEG licensing. > > I do not have the skill currently to help much improving OpenJPEG > efficiency, but I have gathered up all the information I could find on > it. Here is what I have come up with: > > https://wiki.secondlife.com/wiki/Openjpeg_improvements > > Bushing's profiling shows that the DWT, particularly the 9/7 is where > the bottleneck is for SL. > > Improvements: > Use in-place DWT. > Use lifting implementations rather than the current implementation. > Use SSE/MMX to get a speed increase. > > I have found several lifting implementations of 5/3 and 9/7, but it > seems that all of them are floating point rather than integer. I don't > know how useful they would be. > > Please coordinate with the SL developers on that wiki page or here on > the mailing list. If you could forward this to anyone who has contacted > you so that we can all work together that would be best. > > Thanks. > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070209/027ad58f/attachment.htm From sl at email.fries.net Fri Feb 9 06:14:30 2007 From: sl at email.fries.net (Todd T. Fries) Date: Fri Feb 9 06:16:42 2007 Subject: [sldev] Re: OpenJPEG usuable now In-Reply-To: <20070209073501.GB9336@spacedout.fries.net> References: <20070209073501.GB9336@spacedout.fries.net> Message-ID: <20070209141430.GA1979@fries.net> Congratulations! I can't wait to try out this speed improvement myself. Waiting with baited breath for the patches.. ;-) Thanks, -- Todd Fries .. todd@fries.net _____________________________________________ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | "..in support of free software solutions." \ 250797 (FWD) | \ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt Penned by David D. Fries on 20070209 1:35.01, we have: | I'm a bit excited. | | I have some patches that I'm working on, but I was just able to fly a | loop around a three region area just now with them and it seemed | comparable to the binary client. This is with OpenJPEG and the first | look source client on a Linux dual core 64 bit AMD machine. Good | enough that I'm going to have to fly around it again with the binary | version and compare. Any suggestions on how to compare the | performance between them? My qualitative experience tonight says that | it is good enough to run with. Up until tonight it was like pulling | teeth using OpenJPEG, so bad, now it looks good. | | I hacked OpenJPEG to have an opj_meta_decode that would only decode | enough to get the size and number of channels. That's all getMetadata | used anyway. That patch needs to be cleaned up and submitted to | OpenJPEG. But here are the results. | | A full decode can take anywhere on the order of .015 to .5 seconds | (though I've seen 1.5 seconds before). Currently Second Life does a | full decode, saves the image size and channels, then tosses the image. | This OpenJPEG meta decode just gets enough header decoded to get at | the image sizes, and it AVERAGED at .000076 seconds that's with 6200 | samples and all but two under 1 millisecond. That's a total of .474 | seconds spent in OpenJPEG getMetadata decode, or about the time it | takes to decode a large image. | | There is a function, LLImageJ2C::validate that calls | mImpl->getMetadata in llimage/llimagej2c.cpp, my question is how much | validation is required to be done to the image? I only see that | function being called by LLViewerImageList::createUploadFile. | Seriously though, does it just need to find out if it has a jpeg | header without looking at any data? In that case the meta decode | should work. | | The last piece of the puzzle was based on a patch on jira by Hiro | Sommambulist, VWR-66. Without that patch textures decoded at say a | 1/8 resolution would only take up 1/8 of the size leaving the rest | blank and grow from there until it was fully decoded. Some of his | math didn't make sense to me, but it was enough to point me in the | right direction. I have some cleanup work to do on that patch as | well. | | Of course it wouldn't have been possible without the first look viewer | FL-1.13.3.57679 doing the actual jpeg2000 decoding in another thread. | I wasn't going to go as far as time slicing the decoding like the | proprietary decoder does. | | In my previous e-mail where things were still gray after an hour at | the International Spaceflight Museum? It was good in under a minute. | | -- | David Fries | http://fries.net/~david/ (PGP encryption key available) From overtake at keynet.com.br Fri Feb 9 08:03:33 2007 From: overtake at keynet.com.br (Sylvio Deutsch) Date: Fri Feb 9 08:26:42 2007 Subject: [sldev] Alt keys Message-ID: <000801c74c67$06f83220$0301010a@eaurouge> Hi guys I'm left handed and was thinking if there is any way to make right Alt key to work with mouse to make zoom, so I can use only right Alt, Ctrl and Shift keys to control view. I know I can zoom pressing right Alt, pressing mouse, pressing Shift or Ctrl and releasing Alt, but it would be much easier if just Alt-mouse did it, since we already have rotation with right Alt-Ctrl... Would it be too difficult for a newbie to make this change on the viewer? Thanks, {}Overtake -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070209/1754c7d7/attachment.htm From gigstaggart at gmail.com Fri Feb 9 13:15:42 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Feb 9 13:15:31 2007 Subject: [sldev] OpenJPEG usuable now In-Reply-To: <20070209073501.GB9336@spacedout.fries.net> References: <20070209073501.GB9336@spacedout.fries.net> Message-ID: <45CCE47E.6020703@gmail.com> David Fries wrote: > I'm a bit excited. > > I have some patches that I'm working on, but I was just able to fly a > loop around a three region area just now with them and it seemed > comparable to the binary client. This is with OpenJPEG and the first Good catch! I think we should still pursue the other OpenJPEG optimizations, but it sounds like you have solved a major part of it! The way I understand it, since all of the CPU slack is taken up pushing out frames, you may be able to compare framerates to determine relative texture decoding performance. Of course a full profile like bushing did would be the ideal. Maybe you could get with him on profiling your patches. I think he said he has some crazy setup that can compile in a few minutes, so it might not be too hard for him. :P -Jason From jhurliman at wsu.edu Fri Feb 9 13:50:14 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Fri Feb 9 13:50:39 2007 Subject: [sldev] OpenJPEG usuable now In-Reply-To: <45CCE47E.6020703@gmail.com> References: <20070209073501.GB9336@spacedout.fries.net> <45CCE47E.6020703@gmail.com> Message-ID: <45CCEC96.4010500@wsu.edu> Jason Giglio wrote: > David Fries wrote: >> I'm a bit excited. >> >> I have some patches that I'm working on, but I was just able to fly a >> loop around a three region area just now with them and it seemed >> comparable to the binary client. This is with OpenJPEG and the first > > Good catch! I think we should still pursue the other OpenJPEG > optimizations, but it sounds like you have solved a major part of it! > > The way I understand it, since all of the CPU slack is taken up > pushing out frames, you may be able to compare framerates to determine > relative texture decoding performance. > > Of course a full profile like bushing did would be the ideal. Maybe > you could get with him on profiling your patches. I think he said he > has some crazy setup that can compile in a few minutes, so it might > not be too hard for him. :P > > The problem with Ben's setup is that it is built to only analyze raw decoding times, it doesn't take in to account how SL is actually using the decoder and doesn't gauge the performance of metadata decoding at all. To get an accurate picture you would need some sort of usage statistics for SL (such as: "in the image decoding, 80% of the time is spent decompressing images in to GL textures and 20% of the time is spent decoding metadata" or something like that). But it is kind of a moot point since this is a "Pareto" optimization; it improves performance without decreasing performance anywhere, and there is no current better alternative. John From sldev at bushing.mm.st Fri Feb 9 14:21:44 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Fri Feb 9 14:21:51 2007 Subject: [sldev] Re: OpenJPEG profiling In-Reply-To: <45CCE47E.6020703@gmail.com> References: <20070209073501.GB9336@spacedout.fries.net> <45CCE47E.6020703@gmail.com> Message-ID: On Feb 9, 2007, at 1:15 PM, Jason Giglio wrote: > David Fries wrote: >> I'm a bit excited. >> I have some patches that I'm working on, but I was just able to fly a >> loop around a three region area just now with them and it seemed >> comparable to the binary client. This is with OpenJPEG and the first > Of course a full profile like bushing did would be the ideal. > Maybe you could get with him on profiling your patches. I think he > said he has some crazy setup that can compile in a few minutes, so > it might not be too hard for him. :P I can compile *OpenJPEG* in a few minutes, but the whole client takes a bit longer -- a few hours on my PowerBook. Thankfully, we have opensecondlife.org's build box... :) I did the profiling using Shark, and I can do it with the whole client too... -b From guidoj at users.sourceforge.net Fri Feb 9 15:34:57 2007 From: guidoj at users.sourceforge.net (Guido) Date: Fri Feb 9 15:34:11 2007 Subject: [sldev] OpenJPEG usuable now In-Reply-To: <20070209073501.GB9336@spacedout.fries.net> References: <20070209073501.GB9336@spacedout.fries.net> Message-ID: <200702100034.57490.guidoj@users.sourceforge.net> On Friday 9 February 2007 08:35, David Fries hit keys in the following order: > The last piece of the puzzle was based on a patch on jira by Hiro > Sommambulist, VWR-66. Without that patch textures decoded at say a > 1/8 resolution would only take up 1/8 of the size leaving the rest > blank and grow from there until it was fully decoded. Some of his > math didn't make sense to me, but it was enough to point me in the > right direction. I have some cleanup work to do on that patch as > well. The math is the same as in the codec that comes with OpenJPEG. The entire implementation of llimage/llimagej2c.cpp is based on that codec. BTW on each call to decodeImpl(), encodeImpl() and getMetadata() in llimage/llimagej2c.cpp a decoder or encoder is completely setup from scratch and teared down at the end. This might be optimized by moving the setup code to the constructor and the tear down code to the destructor. - Guido From robla at lindenlab.com Fri Feb 9 17:27:14 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Feb 9 17:28:38 2007 Subject: [sldev] OpenJPEG usuable now In-Reply-To: <20070209073501.GB9336@spacedout.fries.net> References: <20070209073501.GB9336@spacedout.fries.net> Message-ID: <45CD1F72.7040505@lindenlab.com> Wow, very cool! We're really looking forward to seeing this work progress. Rob On 2/8/07 11:35 PM, David Fries wrote: > I'm a bit excited. > > I have some patches that I'm working on, but I was just able to fly a > loop around a three region area just now with them and it seemed > comparable to the binary client. This is with OpenJPEG and the first > look source client on a Linux dual core 64 bit AMD machine. Good > enough that I'm going to have to fly around it again with the binary > version and compare. Any suggestions on how to compare the > performance between them? My qualitative experience tonight says that > it is good enough to run with. Up until tonight it was like pulling > teeth using OpenJPEG, so bad, now it looks good. > > I hacked OpenJPEG to have an opj_meta_decode that would only decode > enough to get the size and number of channels. That's all getMetadata > used anyway. That patch needs to be cleaned up and submitted to > OpenJPEG. But here are the results. > > A full decode can take anywhere on the order of .015 to .5 seconds > (though I've seen 1.5 seconds before). Currently Second Life does a > full decode, saves the image size and channels, then tosses the image. > This OpenJPEG meta decode just gets enough header decoded to get at > the image sizes, and it AVERAGED at .000076 seconds that's with 6200 > samples and all but two under 1 millisecond. That's a total of .474 > seconds spent in OpenJPEG getMetadata decode, or about the time it > takes to decode a large image. > > There is a function, LLImageJ2C::validate that calls > mImpl->getMetadata in llimage/llimagej2c.cpp, my question is how much > validation is required to be done to the image? I only see that > function being called by LLViewerImageList::createUploadFile. > Seriously though, does it just need to find out if it has a jpeg > header without looking at any data? In that case the meta decode > should work. > > The last piece of the puzzle was based on a patch on jira by Hiro > Sommambulist, VWR-66. Without that patch textures decoded at say a > 1/8 resolution would only take up 1/8 of the size leaving the rest > blank and grow from there until it was fully decoded. Some of his > math didn't make sense to me, but it was enough to point me in the > right direction. I have some cleanup work to do on that patch as > well. > > Of course it wouldn't have been possible without the first look viewer > FL-1.13.3.57679 doing the actual jpeg2000 decoding in another thread. > I wasn't going to go as far as time slicing the decoding like the > proprietary decoder does. > > In my previous e-mail where things were still gray after an hour at > the International Spaceflight Museum? It was good in under a minute. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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/20070209/b3ebff9a/signature.pgp From robla at lindenlab.com Fri Feb 9 18:18:58 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Feb 9 18:20:27 2007 Subject: [sldev] First Look 1.13.3.57837 source code is available now Message-ID: <45CD2B92.60104@lindenlab.com> Hi folks, For those of you who might not have not noticed, there's a new version of the First Look viewer available: https://wiki.secondlife.com/wiki/Source_downloads Most of the changes are covered in the blog entry from Steve Linden: http://blog.secondlife.com/2007/02/08/first-look-update-113357837-now-available/ However, there are a couple of important changes specific to the source code: * Artwork is broken out into a separate download * Artwork license is clarified: "The copyrightable materials in this file that are owned by Linden Lab are "Work" licensed under Creative Commons license Attribution-Share Alike 2.5 (summarized at http://creativecommons.org/licenses/by-sa/2.5/ , full text of license at http://creativecommons.org/licenses/by-sa/2.5/legalcode ); provided however that all trademarks of Linden Lab are subject to the Linden Lab trademark policy, available at http://secondlife.com/corporate/trademark/" I just noticed that I'm one version behind already. *sigh* Well, I'll try to do that later this weekend. Anyway, have fun with this version! 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/20070209/8f52c844/signature.pgp From sldev at bushing.mm.st Sat Feb 10 04:31:58 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Sat Feb 10 04:32:02 2007 Subject: [sldev] First Look 1.13.3.57837 source code is available now In-Reply-To: <45CD2B92.60104@lindenlab.com> References: <45CD2B92.60104@lindenlab.com> Message-ID: <86F9E276-0FD8-4DC8-B9DA-D31C643394AE@bushing.mm.st> On Feb 9, 2007, at 6:18 PM, Rob Lanphier wrote: > However, there are a couple of important changes specific to the > source > code: > * Artwork is broken out into a separate download > * Artwork license is clarified: > "The copyrightable materials in this file that are owned by Linden Lab > are "Work" licensed under Creative Commons license Attribution-Share > Alike 2.5 Nice! Thanks for following through on this. -b From tcallawa at redhat.com Sat Feb 10 06:55:27 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat Feb 10 06:56:05 2007 Subject: [sldev] First Look 1.13.3.57837 source code is available now In-Reply-To: <86F9E276-0FD8-4DC8-B9DA-D31C643394AE@bushing.mm.st> References: <45CD2B92.60104@lindenlab.com> <86F9E276-0FD8-4DC8-B9DA-D31C643394AE@bushing.mm.st> Message-ID: <1171119327.1479.48.camel@dhcp-32-109.ord.redhat.com> On Sat, 2007-02-10 at 04:31 -0800, Ben Byer wrote: > On Feb 9, 2007, at 6:18 PM, Rob Lanphier wrote: > > > However, there are a couple of important changes specific to the > > source > > code: > > * Artwork is broken out into a separate download > > * Artwork license is clarified: > > "The copyrightable materials in this file that are owned by Linden Lab > > are "Work" licensed under Creative Commons license Attribution-Share > > Alike 2.5 > > Nice! Thanks for following through on this. Indeed. A few more testing cycles and I can start driving this into Fedora. Thanks! ~spot From gigstaggart at gmail.com Sat Feb 10 09:01:43 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Feb 10 09:01:28 2007 Subject: [sldev] OpenJPEG usuable now In-Reply-To: <45CCEC96.4010500@wsu.edu> References: <20070209073501.GB9336@spacedout.fries.net> <45CCE47E.6020703@gmail.com> <45CCEC96.4010500@wsu.edu> Message-ID: <45CDFA77.9040700@gmail.com> John Hurliman wrote: > spent decoding metadata" or something like that). But it is kind of a > moot point since this is a "Pareto" optimization; it improves > performance without decreasing performance anywhere, and there is no > current better alternative. I agree, the question is not whether to use his improvement or not, that's a no-brainer. The question is how far we have left to go to rival or exceed Kakadu performance, after his patch is done. It may turn out we don't have all that far to go to come pretty close in real world use. -Jason From mindtriggerz at gmail.com Sat Feb 10 10:05:17 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Sat Feb 10 10:05:20 2007 Subject: [sldev] First Look 1.13.3.57837 source code is available now In-Reply-To: <1171119327.1479.48.camel@dhcp-32-109.ord.redhat.com> References: <45CD2B92.60104@lindenlab.com> <86F9E276-0FD8-4DC8-B9DA-D31C643394AE@bushing.mm.st> <1171119327.1479.48.camel@dhcp-32-109.ord.redhat.com> Message-ID: I'm really glad that LL is licensing their art under CC By-SA. I'm sure that the CC group inword would love to hear this. On 2/10/07, Tom 'spot' Callaway wrote: > On Sat, 2007-02-10 at 04:31 -0800, Ben Byer wrote: > > On Feb 9, 2007, at 6:18 PM, Rob Lanphier wrote: > > > > > However, there are a couple of important changes specific to the > > > source > > > code: > > > * Artwork is broken out into a separate download > > > * Artwork license is clarified: > > > "The copyrightable materials in this file that are owned by Linden Lab > > > are "Work" licensed under Creative Commons license Attribution-Share > > > Alike 2.5 > > > > Nice! Thanks for following through on this. > > Indeed. A few more testing cycles and I can start driving this into > Fedora. > > Thanks! > > ~spot > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- --Jesse From gigstaggart at gmail.com Sat Feb 10 13:41:33 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Feb 10 13:41:22 2007 Subject: [sldev] First Look 1.13.3.57837 source code is available now In-Reply-To: References: <45CD2B92.60104@lindenlab.com> <86F9E276-0FD8-4DC8-B9DA-D31C643394AE@bushing.mm.st> <1171119327.1479.48.camel@dhcp-32-109.ord.redhat.com> Message-ID: <45CE3C0D.5060504@gmail.com> Jesse Nesbitt wrote: > I'm really glad that LL is licensing their art under CC By-SA. I'm > sure that the CC group inword would love to hear this. > You get additional rights under the TOS to use the art in world for any purpose. This license is mainly for out of world use. From mindtriggerz at gmail.com Sat Feb 10 14:05:42 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Sat Feb 10 14:05:45 2007 Subject: [sldev] First Look 1.13.3.57837 source code is available now In-Reply-To: <45CE3C0D.5060504@gmail.com> References: <45CD2B92.60104@lindenlab.com> <86F9E276-0FD8-4DC8-B9DA-D31C643394AE@bushing.mm.st> <1171119327.1479.48.camel@dhcp-32-109.ord.redhat.com> <45CE3C0D.5060504@gmail.com> Message-ID: Still, it's a plus for distribution and a plus for Creative Commons. On 2/10/07, Jason Giglio wrote: > Jesse Nesbitt wrote: > > I'm really glad that LL is licensing their art under CC By-SA. I'm > > sure that the CC group inword would love to hear this. > > > > You get additional rights under the TOS to use the art in world for any > purpose. This license is mainly for out of world use. > > -- --Jesse From david at fries.net Sun Feb 11 14:26:06 2007 From: david at fries.net (David Fries) Date: Sun Feb 11 14:26:18 2007 Subject: [sldev] OpenJPEG meta decode, Second Life patches Message-ID: <20070211222606.GA12928@spacedout.fries.net> OpenJPEG feature, partial image decode OPJ_limit_tags_for_decode.diff Contains the modifications to OpenJPEG to limit the decoded tags to the ones specified. There is a set of enumerations specified in the openjpeg.h header file and an additional variable in the opj_dparameters structure to hold a bitmask of those values. If it is zero, all of them are decoded, if it is another value then decoding will be stopped when any of those tags are encountered. There is a macro OPJ_LIMIT_FOR_SIZE that contains the two required to get just the image size. Only the j2k decoding uses this extra flag and only j2k_decode checks the parameter, so it isn't terribly fine grained. But it works great to get just the size. Bug fixes and the Second Life side of the above patch. llimagej2coj_bug_fixes.patch These are against the src-FL-1.13.3.57876 source code release, but it should work with many others. The first look client with a thread for texture decoding is required to get the full performance improvements with this. I have a dual core CPU so someone else will have to comment how well it works with a single CPU system, I know I could set all the threads to one CPU, but I'll let someone else do that. New bug with both patches. VWR-123 llimagej2coj_fixes.diff LLImageJ2COJ::decodeImpl Destroy OpenJPEG decompression and cio structures before checking the image so that they don't have to be called in two different places. Bug: return FALSE if the image decode fails not 1 Bug: VWR-66 segfault on decoding images of clothing A rework of the patch included in VWR-66 which fixes the problem with texture scaling. decodeImpl would provide a reduce value which would cause the resulting decode to be 2^reduce smaller in width and height, with the final image taking up the top left of the buffer with the rest black. This resulted in what should have been reduced size textures taking up much more texture memory than they should and the image only taking up a small part of that texture. The VWR-66 bug report was on the crash, which the patch just avoided until it decoded the entire image, but VWR-94 fixes. Bug: VWR-94 Buffer overflow in decoding image. See VWR-94 for the details, but the patch is included in here. VWR-68 and VWR-94 are not related, they are independent bugs in the same code. LLImageJ2COJ::getMetadata Performance improvement: parameters.cp_limit_tags=OPJ_LIMIT_FOR_SIZE; This is only available when OpenJPEG has been patched with the above patch. This makes use of the partial decode feature of that patch. It looks to me that Second Life will call the getMetadecode when it gets the first part of an image. When getMetadecode was doing a full decode of the image, opj_decode would return NULL because the image wasn't there to decode. Some code would then see that the image was 0 by 0 and I'm guessing would flag the image as corrupt and restart the texture download. That last part I'm guessing on, but now that it is only decoding enough to get the image size information it can stop decoding much sooner and the part of the image it needs is there so it doesn't mark it as bad. Win win. Bug: VWR-113 bad getMetadata return code Even when the image failed to decode (see last issue) the return value was 1 instead of 0 (FALSE). Fixed. Now that I've sent in the patches, who is going to be the first to join me in Second Life with them? Space CoLab 100,200,24 -- SpacedOut Frye -- David Fries http://fries.net/~david/ (PGP encryption key available) -------------- next part -------------- Index: libopenjpeg/openjpeg.h =================================================================== --- libopenjpeg/openjpeg.h (revision 338) +++ libopenjpeg/openjpeg.h (working copy) @@ -311,6 +311,41 @@ } opj_cparameters_t; +/** Stop after tags. */ +typedef enum LIMIT_TAGS { + OPJ_TAG_SOC = 0x000001, /**< start of codestream */ + OPJ_TAG_SOT = 0x000002, /**< start of tile-part*/ + OPJ_TAG_SOD = 0x000004, /**< start of data */ + OPJ_TAG_EOC = 0x000008, /**< end of codestream */ + OPJ_TAG_SIZ = 0x000010, /**< image and tile size */ + OPJ_TAG_COD = 0x000020, /**< coding style default */ + OPJ_TAG_COC = 0x000040, /**< coding style component */ + OPJ_TAG_RGN = 0x000080, /**< region-of-interest */ + OPJ_TAG_QCD = 0x000100, /**< quantization default */ + OPJ_TAG_QCC = 0x000200, /**< quantization component */ + OPJ_TAG_POC = 0x000400, /**< progression order change */ + OPJ_TAG_TLM = 0x000800, /**< tile-part lengths */ + OPJ_TAG_PLM = 0x001000, /**< packet length, main header */ + OPJ_TAG_PLT = 0x002000, /**< packet length, tile-part header */ + OPJ_TAG_PPM = 0x004000, /**< packet packet headers, main header */ + OPJ_TAG_PPT = 0x008000, /**< packet packet headers, tile-part header */ + OPJ_TAG_SOP = 0x010000, /**< SOP marker value */ + OPJ_TAG_EPH = 0x020000, /**< EPH marker value */ + OPJ_TAG_CRG = 0x040000, /**< component registration */ + OPJ_TAG_COM = 0x080000, /**< comment */ +#ifdef USE_JPWL +/* UniPG>> */ + OPJ_TAG_EPC = 0x100000, /**< EPC marker value (Part11) */ + OPJ_TAG_EPB = 0x200000, /**< EPB marker value (Part11) */ + OPJ_TAG_ESD = 0x400000, /**< ESD marker value (Part11) */ + OPJ_TAG_RED = 0x800000, /**< RED marker value (Part11) */ +#endif /* USE_JPWL */ +/* <> */ #ifdef USE_JPWL - {J2K_MS_EPC, J2K_STATE_MH | J2K_STATE_TPH, j2k_read_epc}, - {J2K_MS_EPB, J2K_STATE_MH | J2K_STATE_TPH, j2k_read_epb}, - {J2K_MS_ESD, J2K_STATE_MH | J2K_STATE_TPH, j2k_read_esd}, - {J2K_MS_RED, J2K_STATE_MH | J2K_STATE_TPH, j2k_read_red}, + {J2K_MS_EPC, J2K_STATE_MH | J2K_STATE_TPH, j2k_read_epc, OPJ_TAG_EPC}, + {J2K_MS_EPB, J2K_STATE_MH | J2K_STATE_TPH, j2k_read_epb, OPJ_TAG_EPB}, + {J2K_MS_ESD, J2K_STATE_MH | J2K_STATE_TPH, j2k_read_esd, OPJ_TAG_ESD}, + {J2K_MS_RED, J2K_STATE_MH | J2K_STATE_TPH, j2k_read_red, OPJ_TAG_RED}, #endif /* USE_JPWL */ /* <reduce = parameters->cp_reduce; cp->layer = parameters->cp_layer; + cp->limit_tags = parameters->cp_limit_tags; /* UniPG>> */ #ifdef USE_JPWL cp->correct = parameters->jpwl_correct; @@ -1599,6 +1602,12 @@ opj_event_msg(cinfo, EVT_ERROR, "%.8x: unexpected marker %x\n", cio_tell(cio) - 2, id); return 0; } + /* If a partial decode is requested, stop if the current tag + * isn't in the list. + */ + if (j2k->cp->limit_tags && !(j2k->cp->limit_tags & e->limit_tag)) { + return image; + } if (e->handler) { (*e->handler)(j2k); } Index: libopenjpeg/j2k.h =================================================================== --- libopenjpeg/j2k.h (revision 338) +++ libopenjpeg/j2k.h (working copy) @@ -197,6 +197,8 @@ int reduce; /** if != 0, then only the first "layer" layers are decoded; if == 0 or not used, all the quality layers are decoded */ int layer; + /** if != 0, then only decode specific tags, abort on any other; if == 0 decode all tags */ + OPJ_LIMIT_TAGS limit_tags; /** 0 = no index || 1 = index */ int index_on; /** XTOsiz */ -------------- next part -------------- Only in llimagej2coj: .#llimagej2coj.cpp.1.7 Only in llimagej2coj: .llimagej2coj.cpp.swp Only in llimagej2coj: .llimagej2coj.h.swp Only in llimagej2coj: CVS diff -upr llimagej2coj_FL-1.13.3.57876.orig/llimagej2coj.cpp llimagej2coj/llimagej2coj.cpp --- llimagej2coj_FL-1.13.3.57876.orig/llimagej2coj.cpp 2007-02-09 23:49:21.000000000 -0600 +++ llimagej2coj/llimagej2coj.cpp 2007-02-10 20:23:08.000000000 -0600 @@ -122,46 +122,58 @@ BOOL LLImageJ2COJ::decodeImpl(LLImageJ2C /* decode the stream and fill the image structure */ image = opj_decode(dinfo, cio); - if(!image) - { - fprintf(stderr, "ERROR -> j2k_to_image: failed to decode image!\n"); - opj_destroy_decompress(dinfo); - opj_cio_close(cio); - return 1; - } /* close the byte stream */ opj_cio_close(cio); - /* free remaining structures */ - if(dinfo) { + if(dinfo) + { opj_destroy_decompress(dinfo); } + // The image decode failed if the return was NULL or the component + // count was zero. The latter is just a sanity check before we + // dereference the array. + if(!image || !image->numcomps) + { + fprintf(stderr, "ERROR -> j2k_to_image: failed to decode image!\n"); + return FALSE; + } + // Copy image data into our raw image format (instead of the separate channel format - S32 width = 0; - S32 height = 0; S32 img_components = image->numcomps; S32 channels = img_components - first_channel; if( channels > max_channel_count ) - { channels = max_channel_count; - } - width = image->x1 - image->x0; - height = image->y1 - image->y0; + + // Component buffers are allocated in an image width by height buffer. + // The image placed in that buffer is ceil(width/2^factor) by + // ceil(height/2^factor) and if the factor isn't zero it will be at the + // top left of the buffer with black filled in the rest of the pixels. + // It is integer math so the formual is written in ceildivpo2. + // (Assuming all the components have the same width, height and + // factor.) + S32 comp_width = image->comps[0].w; + S32 f=image->comps[0].factor; + S32 width = ceildivpow2(image->x1 - image->x0, f); + S32 height = ceildivpow2(image->y1 - image->y0, f); raw_image.resize(width, height, channels); U8 *rawp = raw_image.getData(); - for (S32 comp = first_channel; comp < first_channel + channels; comp++) + // first_channel is what channel to start copying from + // dest is what channel to copy to. first_channel comes from the + // argument, dest always starts writing at channel zero. + for (S32 comp = first_channel, dest=0; comp < first_channel + channels; + comp++, dest++) { - S32 offset = comp; + S32 offset = dest; for (S32 y = (height - 1); y >= 0; y--) { for (S32 x = 0; x < width; x++) { - rawp[offset] = image->comps[comp].data[y*width + x]; + rawp[offset] = image->comps[comp].data[y*comp_width + x]; offset += channels; } } @@ -323,6 +335,9 @@ BOOL LLImageJ2COJ::getMetadata(LLImageJ2 /* set decoding parameters to default values */ opj_set_default_decoder_parameters(¶meters); + // Only decode what's required to get the size data. + parameters.cp_limit_tags=OPJ_LIMIT_FOR_SIZE; + //parameters.cp_reduce = mRawDiscardLevel; /* decode the code-stream */ @@ -349,7 +364,7 @@ BOOL LLImageJ2COJ::getMetadata(LLImageJ2 fprintf(stderr, "ERROR -> j2k_to_image: failed to decode image!\n"); opj_destroy_decompress(dinfo); opj_cio_close(cio); - return 1; + return FALSE; } /* close the byte stream */ @@ -371,5 +386,6 @@ BOOL LLImageJ2COJ::getMetadata(LLImageJ2 base.setSize(width, height, img_components); /* free image data structure */ - opj_image_destroy(image); return TRUE; + opj_image_destroy(image); + return TRUE; } diff -upr llimagej2coj_FL-1.13.3.57876.orig/llimagej2coj.h llimagej2coj/llimagej2coj.h --- llimagej2coj_FL-1.13.3.57876.orig/llimagej2coj.h 2007-02-09 23:49:21.000000000 -0600 +++ llimagej2coj/llimagej2coj.h 2007-02-10 20:15:33.000000000 -0600 @@ -40,6 +40,11 @@ protected: /*virtual*/ BOOL getMetadata(LLImageJ2C &base); /*virtual*/ BOOL decodeImpl(LLImageJ2C &base, LLImageRaw &raw_image, F32 decode_time, S32 first_channel, S32 max_channel_count); /*virtual*/ BOOL encodeImpl(LLImageJ2C &base, const LLImageRaw &raw_image, const char* comment_text, F32 encode_time=0.0); + int ceildivpow2(int a, int b) + { + // Divide a by b to the power of 2 and round upwards. + return (a + (1 << b) - 1) >> b; + } // Temporary variables for in-progress decodes... LLImageRaw *mRawImagep; From robla at lindenlab.com Sun Feb 11 22:16:17 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sun Feb 11 22:17:59 2007 Subject: [sldev] Conferences/meetings/etc Message-ID: <45D00631.9080204@lindenlab.com> Hi folks, I'm figuring out what conferences and meetings I should go to this year, and just realized I should be asking here. What conferences do you all go to? Other that the really obvious SLCC and O'Reilly's OSCON, are there any conferences you'd be surprised if there wasn't someone from Linden Lab to talk about our viewer source code work? 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/20070211/2b858c89/signature.pgp From james.w.dumay at gmail.com Sun Feb 11 23:42:59 2007 From: james.w.dumay at gmail.com (James Dumay) Date: Sun Feb 11 23:43:02 2007 Subject: [sldev] Conferences/meetings/etc In-Reply-To: <45D00631.9080204@lindenlab.com> References: <45D00631.9080204@lindenlab.com> Message-ID: <139722840702112342k17a1a09rbe4f97e8598e8cce@mail.gmail.com> Rob, In early 2008 you should look at coming to Linux.conf.au which is in Melbourne, Australia. At Linux.conf.au this year I ported the SecondLife viewer to Linux/PowerPC( http://i386.kruel.org/blog/?p=232) (and other non-x86 platforms) and showed it off to people - including talking about SecondLife at the gaming miniconf. http://linux.conf.au/ if your up for it... cheers and thanks for the source!, James Dumay (Caelum Lewellen) On 2/12/07, Rob Lanphier wrote: > > Hi folks, > > I'm figuring out what conferences and meetings I should go to this year, > and just realized I should be asking here. What conferences do you all > go to? > Other that the really obvious SLCC and O'Reilly's OSCON, are there any > conferences you'd be surprised if there wasn't someone from Linden Lab > to talk about our viewer source code work? > > 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/20070212/ec40b3ad/attachment.htm From rob at hackerfriendly.com Mon Feb 12 00:26:13 2007 From: rob at hackerfriendly.com (Rob Flickenger) Date: Mon Feb 12 00:26:24 2007 Subject: [sldev] Conferences/meetings/etc In-Reply-To: <45D00631.9080204@lindenlab.com> References: <45D00631.9080204@lindenlab.com> Message-ID: <0306C8C0-27B1-4160-837C-3B6224B13F78@hackerfriendly.com> I helped hold an impromptu Second Life session at Seattle Mind Camp last fall. The room was packed and it was very well received. This would be a good place to reach Amazon, Microsoft, and Google developers (and regular human beings, too...) It's a small conference with very high signal-to-noise. The next mind camp should be in the spring. http://www.seattlemind.com/ Another good venue is Ignite Seattle. It's a high-energy evening of lightning talks, held roughly every other month. Beth Goza was there last time, talking about her island: http://igniteseattle.com/ --Rob On Feb 12, 2007, at 7:16 AM, Rob Lanphier wrote: > Hi folks, > > I'm figuring out what conferences and meetings I should go to this > year, > and just realized I should be asking here. What conferences do you > all > go to? > Other that the really obvious SLCC and O'Reilly's OSCON, are there any > conferences you'd be surprised if there wasn't someone from Linden Lab > to talk about our viewer source code work? > > Rob > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From blino at mandriva.com Mon Feb 12 09:33:35 2007 From: blino at mandriva.com (Olivier Blin) Date: Mon Feb 12 09:33:00 2007 Subject: [sldev] Conferences/meetings/etc In-Reply-To: <45D00631.9080204@lindenlab.com> (Rob Lanphier's message of "Sun\, 11 Feb 2007 22\:16\:17 -0800") References: <45D00631.9080204@lindenlab.com> Message-ID: Rob Lanphier writes: > Hi folks, > > I'm figuring out what conferences and meetings I should go to this year, > and just realized I should be asking here. What conferences do you all > go to? Maybe FOSDEM? (24th and 25th February 2007 in Brussels, Belgium) It's an open-source development oriented meeting. See http://www.fosdem.org/2007/ Regards -- Olivier Blin - Mandriva From sl at email.fries.net Mon Feb 12 14:44:23 2007 From: sl at email.fries.net (Todd T. Fries) Date: Mon Feb 12 14:46:03 2007 Subject: [sldev] OpenJPEG meta decode, Second Life patches In-Reply-To: <20070211222606.GA12928@spacedout.fries.net> References: <20070211222606.GA12928@spacedout.fries.net> Message-ID: <20070212224421.GA24581@fries.net> On my single processor system, the secondlife release source tree performs markedly better with the following diffs applied. Thanks for the good work, can't wait to see the FL viewer behavior ;-) -- Todd Fries .. todd@fries.net _____________________________________________ | \ 1.636.410.0632 (voice) | Free Daemon Consulting, LLC \ 1.405.227.9094 (voice) | http://FreeDaemonConsulting.com \ 1.866.792.3418 (FAX) | "..in support of free software solutions." \ 250797 (FWD) | \ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ 37E7 D3EB 74D0 8D66 A68D B866 0326 204E 3F42 004A http://todd.fries.net/pgp.txt Penned by David D. Fries on 20070211 16:26.06, we have: | OpenJPEG feature, partial image decode | OPJ_limit_tags_for_decode.diff [..] | Bug fixes and the Second Life side of the above patch. | llimagej2coj_bug_fixes.patch [..] From robla at lindenlab.com Mon Feb 12 17:05:20 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Feb 12 17:05:27 2007 Subject: [sldev] 64-bit client for Vista In-Reply-To: <45B93785.6070805@aol.com> References: <45B93785.6070805@aol.com> Message-ID: <45D10ED0.7090306@lindenlab.com> On 1/25/07 3:04 PM, Mickey wrote: > Introducing myself and stating an interest in a native 64-bit client > for Vista. > > Mickey Lane > Zephyrhills, Florida (US) > Windows kernel coder (device drivers, file system filters, etc.) > currently working on anti-spyware applications Hi Mickey Very belated "welcome!" to the list. Steve Linden (cc'd here) was just asked me "Have you heard of any folks in the OS community working with Vista?", and looked back through my email to find your email to the list. Have you had a chance to compile and play around with it? What's your (or anyone else's) experience running the Second Life viewer on Vista? 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/20070212/526058bf/signature.pgp From tshephard at gmail.com Mon Feb 12 17:33:28 2007 From: tshephard at gmail.com (Tim Shephard) Date: Mon Feb 12 17:33:32 2007 Subject: [sldev] Plugin API Architecture for Second Life Message-ID: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> Hi folks, I was wondering .. briefly, how do you invision a plugin / api / architecture will work for SecondLife? Cheers, Tim. From mindtriggerz at gmail.com Mon Feb 12 17:40:08 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Mon Feb 12 17:40:12 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> Message-ID: bushing has been doing some work in the opensecondlife.org svn towards those ends. Pop in to #opensl on EFnet. On 2/12/07, Tim Shephard wrote: > Hi folks, > > I was wondering .. briefly, how do you invision a plugin / api / > architecture will work for SecondLife? > > Cheers, > > Tim. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- --Jesse From jhurliman at wsu.edu Mon Feb 12 17:47:38 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Feb 12 17:47:34 2007 Subject: [sldev] 64-bit client for Vista In-Reply-To: <45D10ED0.7090306@lindenlab.com> References: <45B93785.6070805@aol.com> <45D10ED0.7090306@lindenlab.com> Message-ID: <45D118BA.3080709@wsu.edu> Rob Lanphier wrote: > On 1/25/07 3:04 PM, Mickey wrote: > >> Introducing myself and stating an interest in a native 64-bit client >> for Vista. >> >> Mickey Lane >> Zephyrhills, Florida (US) >> Windows kernel coder (device drivers, file system filters, etc.) >> currently working on anti-spyware applications >> > Hi Mickey > > Very belated "welcome!" to the list. Steve Linden (cc'd here) was just > asked me "Have you heard of any folks in the OS community working with > Vista?", and looked back through my email to find your email to the list. > > Have you had a chance to compile and play around with it? What's your > (or anyone else's) experience running the Second Life viewer on Vista? > > Rob > I've been working on Vista RC2 32-bit (haven't had time to upgrade to the retail version yet) and it works fine. I see the VWR-15 patch has been applied so I assume the official source release would run as well as the opensecondlife.org version on Vista. No experience with 64-bit Vista though. John Hurliman From tao.takashi at googlemail.com Mon Feb 12 09:47:06 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Mon Feb 12 18:26:38 2007 Subject: [sldev] Conferences/meetings/etc In-Reply-To: References: <45D00631.9080204@lindenlab.com> Message-ID: <23bbb49e0702120947h3ad7ef63j513e9efdea3e7911@mail.gmail.com> Hi! I will be probably at FOSDEM, at least 1 day. Anybody who wants to meet up, just gimme a shout. Cheers, Tao 2007/2/12, Olivier Blin : > > Rob Lanphier writes: > > > Hi folks, > > > > I'm figuring out what conferences and meetings I should go to this year, > > and just realized I should be asking here. What conferences do you all > > go to? > > Maybe FOSDEM? (24th and 25th February 2007 in Brussels, Belgium) > It's an open-source development oriented meeting. > See http://www.fosdem.org/2007/ > > Regards > > -- > Olivier Blin - Mandriva > _______________________________________________ > 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://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/20070212/f505a884/attachment.htm From tshephard at gmail.com Mon Feb 12 18:37:17 2007 From: tshephard at gmail.com (Tim Shephard) Date: Mon Feb 12 18:37:26 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> Message-ID: <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> I believe bushing has mostly been using callbacks in functions in the open sourced code and then loading libraries dynamically via LoadLibrary/GetProcAddress. This is certainly one approach, and an interesting one, but there are many others which have different pros/cons and trade offs. For example, what do people think about embedding a virtual machine and running a scripted language such as Python, JavaScript, or something custom? What security and stability issues are people concerned about? Is cross platform support critical? Do you think LL should support different frame rendering plug ins or should we keep it so that everyone in SL always sees the same thing when viewing the world? Should we be able to communicate back and forth with LSL programs from the plug in? Any particular favorite plug in architectures out there that you think would be a good model for Second Life? Any other comments people might have? Cheers, Tim. On 2/12/07, Jesse Nesbitt wrote: > bushing has been doing some work in the opensecondlife.org svn towards > those ends. Pop in to #opensl on EFnet. > > On 2/12/07, Tim Shephard wrote: > > Hi folks, > > > > I was wondering .. briefly, how do you invision a plugin / api / > > architecture will work for SecondLife? > > > > Cheers, > > > > Tim. > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > -- > --Jesse > From robla at lindenlab.com Mon Feb 12 18:37:23 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Feb 12 18:37:31 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> Message-ID: <45D12463.4090800@lindenlab.com> Actually, as I've said on #opensl, and I'll repeat here, I'd prefer that we have a conversation about it on this mailing list, and document what we discuss on wiki.secondlife.com. There's a great document that's been started on the wiki: https://wiki.secondlife.com/wiki/Plugin_architecture I guess the original authors are too shy to post that link here, so I'm posting it now. My feedback is that we should probably come up with something relatively simple (ala early browser plugin models). Have basic hooks, and a way for end users to discover what plugins are running via simple dialog. Even better (but not mandatory in version 1.0), have a way to enable/disable plugins via user interface. The easier this thing is for Linden Lab to support (via telephone, with a very non-technical resident), the more likely we are to incorporate it in the main source code. Rob On 2/12/07 5:40 PM, Jesse Nesbitt wrote: > bushing has been doing some work in the opensecondlife.org svn towards > those ends. Pop in to #opensl on EFnet. > > On 2/12/07, Tim Shephard wrote: >> Hi folks, >> >> I was wondering .. briefly, how do you invision a plugin / api / >> architecture will work for SecondLife? >> >> Cheers, >> >> Tim. >> _______________________________________________ >> 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/20070212/823790f9/signature.pgp From robla at lindenlab.com Mon Feb 12 19:06:46 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Mon Feb 12 19:06:54 2007 Subject: [sldev] Conferences/meetings/etc In-Reply-To: <0306C8C0-27B1-4160-837C-3B6224B13F78@hackerfriendly.com> References: <45D00631.9080204@lindenlab.com> <0306C8C0-27B1-4160-837C-3B6224B13F78@hackerfriendly.com> Message-ID: <45D12B46.1020101@lindenlab.com> Hi folks, Thanks for all of the great suggestions (and keep them coming). Some were on my radar, some (like Rob Flickenger's suggestions below) were surprisingly not. I feel especially silly that I'm going to still be in San Francisco when Ignite Seattle is going on tomorrow night (doh!) I've got a bunch of work to do to put my calendar together. I'm also going to try to sneak some Seattle, San Francisco, and St. Louis user group meetings in, not because I have a bias toward cities that begin with "S", but because the first two are areas that I work in, and I can piggyback a user group meeting in Missouri or southern Illinois on trips to visit extended family. Rob On 2/12/07 12:26 AM, Rob Flickenger wrote: > I helped hold an impromptu Second Life session at Seattle Mind Camp > last fall. The room was packed and it was very well received. This > would be a good place to reach Amazon, Microsoft, and Google > developers (and regular human beings, too...) It's a small conference > with very high signal-to-noise. The next mind camp should be in the > spring. > > http://www.seattlemind.com/ > > Another good venue is Ignite Seattle. It's a high-energy evening of > lightning talks, held roughly every other month. Beth Goza was there > last time, talking about her island: > > http://igniteseattle.com/ > > --Rob > > On Feb 12, 2007, at 7:16 AM, Rob Lanphier wrote: > >> Hi folks, >> >> I'm figuring out what conferences and meetings I should go to this year, >> and just realized I should be asking here. What conferences do you all >> go to? >> Other that the really obvious SLCC and O'Reilly's OSCON, are there any >> conferences you'd be surprised if there wasn't someone from Linden Lab >> to talk about our viewer source code work? >> >> Rob >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070212/dae26e03/signature-0001.pgp From mathew at lifeart.net.au Mon Feb 12 19:25:19 2007 From: mathew at lifeart.net.au (Mathew Frank) Date: Mon Feb 12 19:25:20 2007 Subject: [sldev] Conferences/meetings/etc In-Reply-To: <45D12B46.1020101@lindenlab.com> References: <45D00631.9080204@lindenlab.com> <0306C8C0-27B1-4160-837C-3B6224B13F78@hackerfriendly.com> <45D12B46.1020101@lindenlab.com> Message-ID: <45D12F9F.1060904@lifeart.net.au> > I've got a bunch of work to do to put my calendar together. I'm also > going to try to sneak some Seattle, San Francisco, and St. Louis user > group meetings in, not because I have a bias toward cities that begin > with "S", but because the first two are areas that I work in, and I can > piggyback a user group meeting in Missouri or southern Illinois on > trips to visit extended family. > Rob, Glad to see personal priorities given a mention ;-) I am assuming you are attending GDC in San Francisco next month? I think there is a 'games technology for business use' event just after that - though the name escape me. I believe that Robin Eckermann or Paul Boustead will be there. (I mention them because it was Robin that told me about the latter event - if you ask me what it's called I'll have to ask them) Cheers, Mathew From sldev at bushing.mm.st Mon Feb 12 19:51:58 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Mon Feb 12 19:52:06 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> Message-ID: On Feb 12, 2007, at 6:37 PM, Tim Shephard wrote: > I believe bushing has mostly been using callbacks in functions in the > open sourced code and then loading libraries dynamically via > LoadLibrary/GetProcAddress. > > This is certainly one approach, and an interesting one, but there are > many others which have different pros/cons and trade offs. > > For example, what do people think about embedding a virtual machine > and running a scripted language such as Python, JavaScript, or > something custom? I don't really understand how you can embed a virtual machine without using callbacks in functions. I finally put down some of my thoughts and a bit of sample code here: https://wiki.secondlife.com/wiki/Plugin_architecture_Low- level_Architecture -b From jhurliman at wsu.edu Mon Feb 12 20:49:34 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Mon Feb 12 20:49:20 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> Message-ID: <45D1435E.8020206@wsu.edu> Tim Shephard wrote: > I believe bushing has mostly been using callbacks in functions in the > open sourced code and then loading libraries dynamically via > LoadLibrary/GetProcAddress. > > This is certainly one approach, and an interesting one, but there are > many others which have different pros/cons and trade offs. > > For example, what do people think about embedding a virtual machine > and running a scripted language such as Python, JavaScript, or > something custom? > > What security and stability issues are people concerned about? > > Is cross platform support critical? > > Do you think LL should support different frame rendering plug ins or > should we keep it so that everyone in SL always sees the same thing > when viewing the world? > > Should we be able to communicate back and forth with LSL programs from > the plug in? > > Any particular favorite plug in architectures out there that you think > would be a good model for Second Life? > > Any other comments people might have? > > Cheers, > > Tim. > I don't think it's necessary to embed a virtual machine directly inside opensl, since you can always write a plugin to do that. I think cross platform support is important so plugins aren't restricted to only OSX users, there is a lot of people using SL that aren't running macs. John Hurliman From tshephard at gmail.com Mon Feb 12 21:10:30 2007 From: tshephard at gmail.com (Tim Shephard) Date: Mon Feb 12 21:10:34 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D1435E.8020206@wsu.edu> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> Message-ID: <3b19a500702122110v138bd666q1c08fd156ce05e47@mail.gmail.com> On 2/12/07, John Hurliman wrote: > Tim Shephard wrote: > > I believe bushing has mostly been using callbacks in functions in the > > open sourced code and then loading libraries dynamically via > > LoadLibrary/GetProcAddress. > > > > This is certainly one approach, and an interesting one, but there are > > many others which have different pros/cons and trade offs. > > > > For example, what do people think about embedding a virtual machine > > and running a scripted language such as Python, JavaScript, or > > something custom? > > > > What security and stability issues are people concerned about? > > > > Is cross platform support critical? > > > > Do you think LL should support different frame rendering plug ins or > > should we keep it so that everyone in SL always sees the same thing > > when viewing the world? > > > > Should we be able to communicate back and forth with LSL programs from > > the plug in? > > > > Any particular favorite plug in architectures out there that you think > > would be a good model for Second Life? > > > > Any other comments people might have? > > > > Cheers, > > > > Tim. > > > > I don't think it's necessary to embed a virtual machine directly inside > opensl, since you can always write a plugin to do that. I think cross > platform support is important so plugins aren't restricted to only OSX > users, there is a lot of people using SL that aren't running macs. > For my own selfish purposes, I agree with this statement. However, to make sure the discussion is complete and that we're not simply rushing ahead, I think there is some value in thinking about a plugin architecture which doesn't allow for open ended linking in the client .. I just want to make sure we're all aware of the sacrifices we're making by losing some of the 'stability and security' (quote quote) that the current client, unsullied by plugins, provides.. > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From sldev at bushing.mm.st Mon Feb 12 22:45:50 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Mon Feb 12 22:45:55 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <3b19a500702122038k6ceedf2ag8c1d1414fb70b60e@mail.gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <3b19a500702122038k6ceedf2ag8c1d1414fb70b60e@mail.gmail.com> Message-ID: <8EF305ED-A67A-47D0-B2B3-18B38F25BE8A@bushing.mm.st> On Feb 12, 2007, at 8:38 PM, Tim Shephard wrote: >> I don't really understand how you can embed a virtual machine without >> using callbacks in functions. > > I think your comment probably should have been, you don't really > understand how you can do the things you want to (such as your OTR > plugin) without callbacks. And, that's a good point. I don't > understand that either! Fair enough. Actually.. I don't understand how you can have a plugin that can do *anything* useful without callbacks. Let's say you compile a Python interpreter into SecondLife.exe (easy), and you set up some bindings so you can pop up message windows and send packets from a Python program (less easy, but still possible). Let's say that you then modify the client and add a Plugins... menu (option) that lets you load plugins, and maybe run them ... but then what? How do you make plugins that do the following, without overriding / intercepting some existing behavior of the client? * Log Chat or IMs or Avatar names or ... * Support new types of media -- movies, textures, etc * readline support for editing the chat input box * A better script editor * HTML-on-a-prim, or at least HTML-in-a-window ... -b From sldev at bushing.mm.st Mon Feb 12 22:49:51 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Mon Feb 12 22:49:58 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D1435E.8020206@wsu.edu> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> Message-ID: On Feb 12, 2007, at 8:49 PM, John Hurliman wrote: >> >> Is cross platform support critical? >> > > I don't think it's necessary to embed a virtual machine directly > inside opensl, since you can always write a plugin to do that. I > think cross platform support is important so plugins aren't > restricted to only OSX users, there is a lot of people using SL > that aren't running macs. Pfft. Loading plugin code is easy -- the dlopen() / dlsym() code I've written will work without modification on any Posix system (Linux, OSX, Solaris, *BSD...). It would (will) take at most 20 lines of code to add support for windows. Once you've loaded plugin code into the client's address space, the porting issues become the same as for the rest of the viewer -- I imagine that most plugins will only need to be recompiled to support multiple architectures. -b From james.w.dumay at gmail.com Mon Feb 12 23:54:29 2007 From: james.w.dumay at gmail.com (James Dumay) Date: Mon Feb 12 23:54:31 2007 Subject: [sldev] 64-bit client for Vista In-Reply-To: <45D118BA.3080709@wsu.edu> References: <45B93785.6070805@aol.com> <45D10ED0.7090306@lindenlab.com> <45D118BA.3080709@wsu.edu> Message-ID: <139722840702122354t63f49954kecd35e308f7740a0@mail.gmail.com> I develop for Windows Vista 64bit atm - ill try and have a burn at building SL on it. James On 2/13/07, John Hurliman wrote: > > Rob Lanphier wrote: > > On 1/25/07 3:04 PM, Mickey wrote: > > > >> Introducing myself and stating an interest in a native 64-bit client > >> for Vista. > >> > >> Mickey Lane > >> Zephyrhills, Florida (US) > >> Windows kernel coder (device drivers, file system filters, etc.) > >> currently working on anti-spyware applications > >> > > Hi Mickey > > > > Very belated "welcome!" to the list. Steve Linden (cc'd here) was just > > asked me "Have you heard of any folks in the OS community working with > > Vista?", and looked back through my email to find your email to the > list. > > > > Have you had a chance to compile and play around with it? What's your > > (or anyone else's) experience running the Second Life viewer on Vista? > > > > Rob > > > > I've been working on Vista RC2 32-bit (haven't had time to upgrade to > the retail version yet) and it works fine. I see the VWR-15 patch has > been applied so I assume the official source release would run as well > as the opensecondlife.org version on Vista. No experience with 64-bit > Vista though. > > John Hurliman > _______________________________________________ > 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/20070213/6aebcef7/attachment.htm From fairlight at tigress.com Tue Feb 13 01:11:15 2007 From: fairlight at tigress.com (Fairlight) Date: Tue Feb 13 01:11:24 2007 Subject: [sldev] 64-bit client for Vista In-Reply-To: <45D10ED0.7090306@lindenlab.com> References: <45B93785.6070805@aol.com> <45D10ED0.7090306@lindenlab.com> Message-ID: Hi! I've been using both the first look client and the regular one with Vista 32bit for about a month now, and it seems to run quite good. Compared to Windows XP, I get 2-3 fps less, but that was expected. I have not yet tried to compile the client on this platform, but can have a try if the need arises. For statistical purposes, here's my setup: As from the SL client's About page: (btw.. did you know you can't copy and paste from the about page?) SecondLife 1.13.3 (57876) CPU: AMD (2211 Mhz) Memory: 2047 MB OS Version: Windows Vista (Build 6000) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce 7950 GT/PCI/SSE2/3DNOW! OpenGL Version: 2.1.0 LLMozLib Version: 1.1.0 Info from me: Processor: AMD64 X2 4200+ OS: 32bit Vista GFX card: GeForce 7950GT, 512 MB NVidia Drivers used: 97.46_forceware_winvista_x86_international_whql 2 things I noticed: a) The SL client's application settings go to c:\users\(username)\AppData\Roaming\Secondlife It should go to AppData\Local\SecondLife imo, since having a 1 gig SL cache in a roaming profile doesn't make much sense. b) The GeForce 7950GT gets detected with 64 MB ro RAM instead of the 512 MB it really has, but that could be related to the GFX card not beeing properly detected by the client instead of it beeing a Vista issue. The Viewer log, however, seems to point towards the correct amount of RAM beeing detected. Still it defaults to 64MB after detection. ----snip---- 2007-02-13T08:56:46Z INFO: VRAM Detected: 512 DX9 string: 512 MB 2007-02-13T08:56:46Z INFO: Done polling DirectX for hardware info 2007-02-13T08:56:46Z INFO: Detected VRAM: 512 2007-02-13T08:56:46Z INFO: TEXTURE CACHE: Headers: 139810 Textures size: 320 MB 2007-02-13T08:56:46Z INFO: TEXTURE CACHE: PURGED: 0 ENTRIES: 2038 CACHE SIZE: 40771852 2007-02-13T08:56:46Z INFO: VFS CACHE SIZE: 100 MB .... 2007-02-13T08:56:48Z INFO: GPU is NVIDIA GeForce 7900 2007-02-13T08:56:48Z INFO: Setting GPU Class to Class3 2007-02-13T08:56:48Z INFO: Applying Feature Mask: Class3 2007-02-13T08:56:48Z WARNING: Unknown feature mask NVIDIA ----/snip---- For added reading pleasure, here's the complete Viewer Log of that session: 2007-02-13T08:56:45Z INFO: Checking marker file for lock... 2007-02-13T08:56:45Z INFO: Marker file isn't locked. 2007-02-13T08:56:45Z INFO: Checking marker file for lock... 2007-02-13T08:56:45Z INFO: Marker file created. 2007-02-13T08:56:45Z INFO: Removing SecondLife.dmp 2007-02-13T08:56:45Z INFO: Removing message.log 2007-02-13T08:56:45Z INFO: Exiting init_marker_file(). 2007-02-13T08:56:45Z INFO: Opening debug file C:\Users\Fairlight\AppData\Roaming\SecondLife\logs\debug_info.log 2007-02-13T08:56:45Z INFO: Second Life version 1.13.3 2007-02-13T08:56:45Z INFO: Local time: 2007-02-13T09:56:45 W. Europe Standard Time 2007-02-13T08:56:46Z INFO: CPU info: 2007-02-13T08:56:46Z // CPU General Information 2007-02-13T08:56:46Z ////////////////////////// 2007-02-13T08:56:46Z Processor name: Original OEM AMD (Unknown model) 2007-02-13T08:56:46Z Frequency: 2211.33 MHz 2007-02-13T08:56:46Z 2007-02-13T08:56:46Z Vendor: AuthenticAMD 2007-02-13T08:56:46Z Family: Unknown family 2007-02-13T08:56:46Z Extended family: 0 2007-02-13T08:56:46Z Model: Unknown AMD model 2007-02-13T08:56:46Z Extended model: 0 2007-02-13T08:56:46Z Type: Original OEM 2007-02-13T08:56:46Z Brand ID: AMD 2007-02-13T08:56:46Z Processor Serial: Disabled 2007-02-13T08:56:46Z 2007-02-13T08:56:46Z 2007-02-13T08:56:46Z // CPU Configuration 2007-02-13T08:56:46Z //////////////////// 2007-02-13T08:56:46Z L1 instruction cache: 64 KB cache size, 4 ways associative, 64 bytes line size 2007-02-13T08:56:46Z L1 data cache: 64 KB cache size, 4 ways associative, 64 bytes line size 2007-02-13T08:56:46Z L2 cache: 512 KB cache size, 16 ways associative, 64 bytes line size 2007-02-13T08:56:46Z L3 cache: Not present 2007-02-13T08:56:46Z Trace cache: Not present 2007-02-13T08:56:46Z Instruction TLB: 4 KB / 2 MB / 4MB page size, fully associative, 8 entries 2007-02-13T08:56:46Z Data TLB: 4 KB / 2 MB / 4MB page size, fully associative, 8 entries 2007-02-13T08:56:46Z Max Supported CPUID-Level: 0x00000001 2007-02-13T08:56:46Z Max Supported Ext. CPUID-Level: 0x80000018 2007-02-13T08:56:46Z 2007-02-13T08:56:46Z 2007-02-13T08:56:46Z // CPU Extensions 2007-02-13T08:56:46Z ///////////////// 2007-02-13T08:56:46Z AA64 AMD 64-bit Architecture: Yes 2007-02-13T08:56:46Z ACPI Thermal Monitor And Clock Control: No 2007-02-13T08:56:46Z APIC Advanced Programmable Interrupt Controller: Yes 2007-02-13T08:56:46Z APIC-ID: 0 2007-02-13T08:56:46Z CLFSH CLFLUSH Instruction Presence: Yes 2007-02-13T08:56:46Z CLFLUSH Instruction Cache Line Size: 8 2007-02-13T08:56:46Z CMOV Conditional Move And Compare Instructions: Yes 2007-02-13T08:56:46Z CX8 COMPXCHG8B Instruction: Yes 2007-02-13T08:56:46Z DE Debugging Extensions: Yes 2007-02-13T08:56:46Z DS Debug Store: No 2007-02-13T08:56:46Z FGPAT Page Attribute Table: Yes 2007-02-13T08:56:46Z FPU Floating Point Unit: Yes 2007-02-13T08:56:46Z FXSR Fast Streaming SIMD Extensions Save/Restore: Yes 2007-02-13T08:56:46Z HT Hyper Threading: Yes 2007-02-13T08:56:46Z IA64 Intel 64-Bit Architecture: No 2007-02-13T08:56:46Z MCA Machine Check Architecture: Yes 2007-02-13T08:56:46Z MCE Machine Check Exception: Yes 2007-02-13T08:56:46Z MMX Multimedia Extensions: Yes 2007-02-13T08:56:46Z MMX+ Multimedia Extensions: Yes 2007-02-13T08:56:46Z MSR Model Specific Registers: Yes 2007-02-13T08:56:46Z MTRR Memory Type Range Registers: Yes 2007-02-13T08:56:46Z PAE Physical Address Extension: Yes 2007-02-13T08:56:46Z PGE PTE Global Flag: Yes 2007-02-13T08:56:46Z PN Processor Serial Number: Disabled 2007-02-13T08:56:46Z PSE Page Size Extensions: Yes 2007-02-13T08:56:46Z PSE36 36-bit Page Size Extension: Yes 2007-02-13T08:56:46Z SEP Fast System Call: Yes 2007-02-13T08:56:46Z SS Self Snoop: No 2007-02-13T08:56:46Z SSE Streaming SIMD Extensions: Yes 2007-02-13T08:56:46Z SSE2 Streaming SIMD 2 Extensions: Yes 2007-02-13T08:56:46Z TM Thermal Monitor: No 2007-02-13T08:56:46Z TSC Time Stamp Counter: Yes 2007-02-13T08:56:46Z VME Virtual 8086 Mode Enhancements: Yes 2007-02-13T08:56:46Z 3DNow! Instructions: Yes 2007-02-13T08:56:46Z Enhanced 3DNow! Instructions: Yes 2007-02-13T08:56:46Z 2007-02-13T08:56:46Z INFO: Memory info: 2007-02-13T08:56:46Z Percent Memory use: 28% 2007-02-13T08:56:46Z Total Physical Kb: 2096064 2007-02-13T08:56:46Z Avail Physical Kb: 1502692 2007-02-13T08:56:46Z Total page Kb: 4194303 2007-02-13T08:56:46Z Avail page Kb: 3707648 2007-02-13T08:56:46Z Total Virtual Kb: 2097024 2007-02-13T08:56:46Z Avail Virtual Kb: 1986476 2007-02-13T08:56:46Z 2007-02-13T08:56:46Z INFO: OS info: Microsoft Windows Vista (Build 6000) 2007-02-13T08:56:46Z INFO: Turning off Windows error reporting. 2007-02-13T08:56:46Z INFO: Loading feature tables. 2007-02-13T08:56:46Z INFO: Loading configuration file C:\Users\Fairlight\AppData\Roaming\SecondLife\user_settings\settings_firstlook.xml 2007-02-13T08:56:46Z INFO: Loading art table from C:\Program Files\SecondLifeFirstLook\app_settings\viewerart.xml 2007-02-13T08:56:46Z INFO: Loading art table from C:\Program Files\SecondLifeFirstLook\skins\textures\textures.xml 2007-02-13T08:56:46Z INFO: Loading base colors from C:\Program Files\SecondLifeFirstLook\app_settings\colors_base.xml 2007-02-13T08:56:46Z INFO: Loading user colors from C:\Program Files\SecondLifeFirstLook\app_settings\colors.xml 2007-02-13T08:56:46Z INFO: Failed to load user colors from C:\Program Files\SecondLifeFirstLook\app_settings\colors.xml 2007-02-13T08:56:46Z INFO: Loading legacy colors from C:\Program Files\SecondLifeFirstLook\app_settings\colors.ini 2007-02-13T08:56:46Z INFO: Attempting to poll DirectX for hardware info 2007-02-13T08:56:46Z INFO: CoCreateInstance IID_IDxDiagProvider 2007-02-13T08:56:46Z INFO: dx_diag_providerp->Initialize 2007-02-13T08:56:46Z INFO: dx_diag_providerp->GetRootContainer 2007-02-13T08:56:46Z INFO: dx_diag_rootp->GetChildContainer 2007-02-13T08:56:46Z INFO: devices_containerp->GetChildContainer 2007-02-13T08:56:46Z INFO: VRAM Detected: 512 DX9 string: 512 MB 2007-02-13T08:56:46Z INFO: Done polling DirectX for hardware info 2007-02-13T08:56:46Z INFO: Detected VRAM: 512 2007-02-13T08:56:46Z INFO: TEXTURE CACHE: Headers: 139810 Textures size: 320 MB 2007-02-13T08:56:46Z INFO: TEXTURE CACHE: PURGED: 0 ENTRIES: 2038 CACHE SIZE: 40771852 2007-02-13T08:56:46Z INFO: VFS CACHE SIZE: 100 MB 2007-02-13T08:56:46Z INFO: Renaming C:\Users\Fairlight\AppData\Roaming\SecondLife\cache\data.db2.x.19216 to C:\Users\Fairlight\AppData\Roaming\SecondLife\cache\data.db2.x.19428 2007-02-13T08:56:46Z INFO: Renaming C:\Users\Fairlight\AppData\Roaming\SecondLife\cache\index.db2.x.19216 to C:\Users\Fairlight\AppData\Roaming\SecondLife\cache\index.db2.x.19428 2007-02-13T08:56:46Z INFO: VFS: Using index file C:\Users\Fairlight\AppData\Roaming\SecondLife\cache\index.db2.x.19428 and data file C:\Users\Fairlight\AppData\Roaming\SecondLife\cache\data.db2.x.19428 2007-02-13T08:56:46Z INFO: VFS: Using index file C:\Program Files\SecondLifeFirstLook\app_settings\static_index.db2 and data file C:\Program Files\SecondLifeFirstLook\app_settings\static_data.db2 2007-02-13T08:56:46Z INFO: Initializing window... 2007-02-13T08:56:46Z WARNING: No ARB WGL render texture extensions 2007-02-13T08:56:47Z INFO: Swap Method: Exchange 2007-02-13T08:56:47Z INFO: GL buffer: Color Bits 32 Alpha Bits 8 Depth Bits 24 2007-02-13T08:56:48Z INFO: Couldn't initialize GL_EXT_paletted_texture 2007-02-13T08:56:48Z INFO: GL Probe: Getting symbols 2007-02-13T08:56:48Z INFO: GL Probe: Got symbols 2007-02-13T08:56:48Z INFO: Disabling vertical sync 2007-02-13T08:56:48Z INFO: Previous gamma: 1 2007-02-13T08:56:48Z INFO: GPU is NVIDIA GeForce 7900 2007-02-13T08:56:48Z INFO: Setting GPU Class to Class3 2007-02-13T08:56:48Z INFO: Applying Feature Mask: Class3 2007-02-13T08:56:48Z WARNING: Unknown feature mask NVIDIA 2007-02-13T08:56:48Z INFO: Loading shader file: lighting/lightV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/lighting/lightV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: lighting/lightF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/lighting/lightF.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: environment/scatterV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/environment/scatterV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/environment/scatterV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: environment/scatterF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/environment/scatterF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/environment/scatterF.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: environment/waterV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/environment/waterV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: environment/waterF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/environment/waterF.glsl 2007-02-13T08:56:48Z INFO: 2007-02-13T08:56:48Z INFO: Uniform bumpMap is at location 0 2007-02-13T08:56:48Z INFO: Assigned to texture channel 0 2007-02-13T08:56:48Z INFO: Uniform d1 is at location 1 stored in index 7 2007-02-13T08:56:48Z INFO: Uniform d2 is at location 2 stored in index 8 2007-02-13T08:56:48Z INFO: Uniform diffuseMap is at location 3 2007-02-13T08:56:48Z INFO: Assigned to texture channel 1 2007-02-13T08:56:48Z INFO: Uniform environmentMap is at location 4 2007-02-13T08:56:48Z INFO: Assigned to texture channel 2 2007-02-13T08:56:48Z INFO: Uniform eyeVec is at location 5 stored in index 5 2007-02-13T08:56:48Z INFO: Uniform fbScale is at location 6 stored in index 12 2007-02-13T08:56:48Z INFO: Uniform lightDir is at location 7 stored in index 9 2007-02-13T08:56:48Z INFO: Uniform lightExp is at location 8 stored in index 11 2007-02-13T08:56:48Z INFO: Uniform refScale is at location 9 stored in index 13 2007-02-13T08:56:48Z INFO: Uniform screenTex is at location 10 stored in index 4 2007-02-13T08:56:48Z INFO: Assigned to texture channel 3 2007-02-13T08:56:48Z INFO: Uniform specular is at location 11 stored in index 10 2007-02-13T08:56:48Z INFO: Uniform time is at location 12 stored in index 6 2007-02-13T08:56:48Z INFO: Loading shader file: environment/groundV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/environment/groundV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/environment/groundV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: environment/groundF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/environment/groundF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/environment/groundF.glsl 2007-02-13T08:56:48Z INFO: 2007-02-13T08:56:48Z INFO: Loading shader file: environment/terrainV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/environment/terrainV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/environment/terrainV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: environment/terrainF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/environment/terrainF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/environment/terrainF.glsl 2007-02-13T08:56:48Z INFO: 2007-02-13T08:56:48Z INFO: Attribute materialColor assigned to channel 1 2007-02-13T08:56:48Z INFO: Uniform alphaRamp is at location 0 stored in index 6 2007-02-13T08:56:48Z INFO: Assigned to texture channel 0 2007-02-13T08:56:48Z INFO: Uniform detail0 is at location 1 stored in index 4 2007-02-13T08:56:48Z INFO: Assigned to texture channel 1 2007-02-13T08:56:48Z INFO: Uniform detail1 is at location 2 stored in index 5 2007-02-13T08:56:48Z INFO: Assigned to texture channel 2 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/eyeballV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class3/avatar/eyeballV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/eyeballV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/eyeballF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class3/avatar/eyeballF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/eyeballF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/eyeballF.glsl 2007-02-13T08:56:48Z INFO: 2007-02-13T08:56:48Z INFO: Attribute materialColor assigned to channel 1 2007-02-13T08:56:48Z INFO: Uniform diffuseMap is at location 0 2007-02-13T08:56:48Z INFO: Assigned to texture channel 0 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/avatarSkinV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class3/avatar/avatarSkinV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/avatarSkinV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/avatarSkinV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/avatarV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class3/avatar/avatarV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/avatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class3/avatar/avatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/avatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/avatarF.glsl 2007-02-13T08:56:48Z INFO: 2007-02-13T08:56:48Z INFO: Attribute materialColor assigned to channel 4 2007-02-13T08:56:48Z INFO: Attribute weight assigned to channel 1 2007-02-13T08:56:48Z INFO: Attribute clothing assigned to channel 6 2007-02-13T08:56:48Z INFO: Attribute gWindDir assigned to channel 7 2007-02-13T08:56:48Z INFO: Attribute gSinWaveParams assigned to channel 9 2007-02-13T08:56:48Z INFO: Attribute gGravity assigned to channel 10 2007-02-13T08:56:48Z INFO: Uniform diffuseMap is at location 0 2007-02-13T08:56:48Z INFO: Assigned to texture channel 0 2007-02-13T08:56:48Z INFO: Uniform matrixPalette is at location 1 stored in index 4 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/pickAvatarV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class3/avatar/pickAvatarV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/pickAvatarV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/pickAvatarV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/pickAvatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class3/avatar/pickAvatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/pickAvatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/pickAvatarF.glsl 2007-02-13T08:56:48Z INFO: 2007-02-13T08:56:48Z INFO: Attribute weight assigned to channel 1 2007-02-13T08:56:48Z INFO: Uniform diffuseMap is at location 0 2007-02-13T08:56:48Z INFO: Assigned to texture channel 0 2007-02-13T08:56:48Z INFO: Uniform matrixPalette is at location 1 stored in index 4 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/eyeballV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/eyeballV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/eyeballF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/eyeballF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/eyeballF.glsl 2007-02-13T08:56:48Z INFO: 2007-02-13T08:56:48Z INFO: Attribute materialColor assigned to channel 1 2007-02-13T08:56:48Z INFO: Uniform diffuseMap is at location 0 2007-02-13T08:56:48Z INFO: Assigned to texture channel 0 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/avatarSkinV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/avatarSkinV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/avatarSkinV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/avatarV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/avatarV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/avatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/avatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/avatarF.glsl 2007-02-13T08:56:48Z INFO: 2007-02-13T08:56:48Z INFO: Attribute materialColor assigned to channel 4 2007-02-13T08:56:48Z INFO: Attribute weight assigned to channel 1 2007-02-13T08:56:48Z INFO: Uniform diffuseMap is at location 0 2007-02-13T08:56:48Z INFO: Assigned to texture channel 0 2007-02-13T08:56:48Z INFO: Uniform matrixPalette is at location 1 stored in index 4 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/pickAvatarV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/pickAvatarV.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/pickAvatarV.glsl 2007-02-13T08:56:48Z INFO: Loading shader file: avatar/pickAvatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class2/avatar/pickAvatarF.glsl 2007-02-13T08:56:48Z INFO: Looking in C:\Program Files\SecondLifeFirstLook\app_settings\shaders/class1/avatar/pickAvatarF.glsl 2007-02-13T08:56:48Z INFO: 2007-02-13T08:56:48Z INFO: Attribute weight assigned to channel 1 2007-02-13T08:56:48Z INFO: Uniform diffuseMap is at location 0 2007-02-13T08:56:48Z INFO: Assigned to texture channel 0 2007-02-13T08:56:48Z INFO: Uniform matrixPalette is at location 1 stored in index 4 2007-02-13T08:56:48Z INFO: Preloading images... 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_woodgrain.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_bark.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_bricks.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_checker.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_concrete.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_crustytile.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_cutstone.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_discs.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_gravel.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_petridish.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_siding.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_stonetile.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_stucco.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_suction.tga from viewerart 2007-02-13T08:56:48Z INFO: Loading bumpmap: bump_weave.tga from viewerart 2007-02-13T08:56:48Z WARNING: Couldn't load font arialuni.ttf 2007-02-13T08:56:48Z WARNING: Couldn't load font msgothic.ttf 2007-02-13T08:56:48Z WARNING: Couldn't load font gulim.ttf 2007-02-13T08:56:49Z WARNING: Couldn't load font simhei.ttc 2007-02-13T08:56:49Z WARNING: Couldn't load font arialuni.ttf 2007-02-13T08:56:49Z WARNING: Couldn't load font msgothic.ttf 2007-02-13T08:56:49Z WARNING: Couldn't load font gulim.ttf 2007-02-13T08:56:49Z WARNING: Couldn't load font simhei.ttc 2007-02-13T08:56:49Z WARNING: Couldn't load font arialuni.ttf 2007-02-13T08:56:49Z WARNING: Couldn't load font msgothic.ttf 2007-02-13T08:56:49Z WARNING: Couldn't load font gulim.ttf 2007-02-13T08:56:50Z WARNING: Couldn't load font simhei.ttc 2007-02-13T08:56:50Z WARNING: Couldn't load font arialuni.ttf 2007-02-13T08:56:50Z WARNING: Couldn't load font msgothic.ttf 2007-02-13T08:56:50Z WARNING: Couldn't load font gulim.ttf 2007-02-13T08:56:50Z WARNING: Couldn't load font simhei.ttc 2007-02-13T08:56:50Z WARNING: Couldn't load font arialuni.ttf 2007-02-13T08:56:50Z WARNING: Couldn't load font msgothic.ttf 2007-02-13T08:56:50Z WARNING: Couldn't load font gulim.ttf 2007-02-13T08:56:51Z WARNING: Couldn't load font simhei.ttc 2007-02-13T08:56:51Z INFO: GL_VENDOR NVIDIA Corporation 2007-02-13T08:56:51Z GL_RENDERER GeForce 7950 GT/PCI/SSE2/3DNOW! 2007-02-13T08:56:51Z GL_VERSION 2.1.0 2007-02-13T08:56:51Z GL_EXTENSIONS: 2007-02-13T08:56:51Z GL_ARB_color_buffer_float 2007-02-13T08:56:51Z GL_ARB_depth_texture 2007-02-13T08:56:51Z GL_ARB_draw_buffers 2007-02-13T08:56:51Z GL_ARB_fragment_program 2007-02-13T08:56:51Z GL_ARB_fragment_program_shadow 2007-02-13T08:56:51Z GL_ARB_fragment_shader 2007-02-13T08:56:51Z GL_ARB_half_float_pixel 2007-02-13T08:56:51Z GL_ARB_imaging 2007-02-13T08:56:51Z GL_ARB_multisample 2007-02-13T08:56:51Z GL_ARB_multitexture 2007-02-13T08:56:51Z GL_ARB_occlusion_query 2007-02-13T08:56:51Z GL_ARB_pixel_buffer_object 2007-02-13T08:56:51Z GL_ARB_point_parameters 2007-02-13T08:56:51Z GL_ARB_point_sprite 2007-02-13T08:56:51Z GL_ARB_shadow 2007-02-13T08:56:51Z GL_ARB_shader_objects 2007-02-13T08:56:51Z GL_ARB_shading_language_100 2007-02-13T08:56:51Z GL_ARB_texture_border_clamp 2007-02-13T08:56:51Z GL_ARB_texture_compression 2007-02-13T08:56:51Z GL_ARB_texture_cube_map 2007-02-13T08:56:51Z GL_ARB_texture_env_add 2007-02-13T08:56:51Z GL_ARB_texture_env_combine 2007-02-13T08:56:51Z GL_ARB_texture_env_dot3 2007-02-13T08:56:51Z GL_ARB_texture_float 2007-02-13T08:56:51Z GL_ARB_texture_mirrored_repeat 2007-02-13T08:56:51Z GL_ARB_texture_non_power_of_two 2007-02-13T08:56:51Z GL_ARB_texture_rectangle 2007-02-13T08:56:51Z GL_ARB_transpose_matrix 2007-02-13T08:56:51Z GL_ARB_vertex_buffer_object 2007-02-13T08:56:51Z GL_ARB_vertex_program 2007-02-13T08:56:51Z GL_ARB_vertex_shader 2007-02-13T08:56:51Z GL_ARB_window_pos 2007-02-13T08:56:51Z GL_ATI_draw_buffers 2007-02-13T08:56:51Z GL_ATI_texture_float 2007-02-13T08:56:51Z GL_ATI_texture_mirror_once 2007-02-13T08:56:51Z GL_S3_s3tc 2007-02-13T08:56:51Z GL_EXT_texture_env_add 2007-02-13T08:56:51Z GL_EXT_abgr 2007-02-13T08:56:51Z GL_EXT_bgra 2007-02-13T08:56:51Z GL_EXT_blend_color 2007-02-13T08:56:51Z GL_EXT_blend_equation_separate 2007-02-13T08:56:51Z GL_EXT_blend_func_separate 2007-02-13T08:56:51Z GL_EXT_blend_minmax 2007-02-13T08:56:51Z GL_EXT_blend_subtract 2007-02-13T08:56:51Z GL_EXT_compiled_vertex_array 2007-02-13T08:56:51Z GL_EXT_Cg_shader 2007-02-13T08:56:51Z GL_EXT_depth_bounds_test 2007-02-13T08:56:51Z GL_EXT_draw_range_elements 2007-02-13T08:56:51Z GL_EXT_fog_coord 2007-02-13T08:56:51Z GL_EXT_framebuffer_object 2007-02-13T08:56:51Z GL_EXT_gpu_program_parameters 2007-02-13T08:56:51Z GL_EXT_multi_draw_arrays 2007-02-13T08:56:51Z GL_EXT_packed_depth_stencil 2007-02-13T08:56:51Z GL_EXT_packed_pixels 2007-02-13T08:56:51Z GL_EXT_pixel_buffer_object 2007-02-13T08:56:51Z GL_EXT_point_parameters 2007-02-13T08:56:51Z GL_EXT_rescale_normal 2007-02-13T08:56:51Z GL_EXT_secondary_color 2007-02-13T08:56:51Z GL_EXT_separate_specular_color 2007-02-13T08:56:51Z GL_EXT_shadow_funcs 2007-02-13T08:56:51Z GL_EXT_stencil_two_side 2007-02-13T08:56:51Z GL_EXT_stencil_wrap 2007-02-13T08:56:51Z GL_EXT_texture3D 2007-02-13T08:56:51Z GL_EXT_texture_compression_s3tc 2007-02-13T08:56:51Z GL_EXT_texture_cube_map 2007-02-13T08:56:51Z GL_EXT_texture_edge_clamp 2007-02-13T08:56:51Z GL_EXT_texture_env_combine 2007-02-13T08:56:51Z GL_EXT_texture_env_dot3 2007-02-13T08:56:51Z GL_EXT_texture_filter_anisotropic 2007-02-13T08:56:51Z GL_EXT_texture_lod 2007-02-13T08:56:51Z GL_EXT_texture_lod_bias 2007-02-13T08:56:51Z GL_EXT_texture_mirror_clamp 2007-02-13T08:56:51Z GL_EXT_texture_object 2007-02-13T08:56:51Z GL_EXT_texture_sRGB 2007-02-13T08:56:51Z GL_EXT_timer_query 2007-02-13T08:56:51Z GL_EXT_vertex_array 2007-02-13T08:56:51Z GL_HP_occlusion_test 2007-02-13T08:56:51Z GL_IBM_rasterpos_clip 2007-02-13T08:56:51Z GL_IBM_texture_mirrored_repeat 2007-02-13T08:56:51Z GL_KTX_buffer_region 2007-02-13T08:56:51Z GL_NV_blend_square 2007-02-13T08:56:51Z GL_NV_copy_depth_to_color 2007-02-13T08:56:51Z GL_NV_depth_clamp 2007-02-13T08:56:51Z GL_NV_fence 2007-02-13T08:56:51Z GL_NV_float_buffer 2007-02-13T08:56:51Z GL_NV_fog_distance 2007-02-13T08:56:51Z GL_NV_fragment_program 2007-02-13T08:56:51Z GL_NV_fragment_program_option 2007-02-13T08:56:51Z GL_NV_fragment_program2 2007-02-13T08:56:51Z GL_NV_half_float 2007-02-13T08:56:51Z GL_NV_light_max_exponent 2007-02-13T08:56:51Z GL_NV_multisample_filter_hint 2007-02-13T08:56:51Z GL_NV_occlusion_query 2007-02-13T08:56:51Z GL_NV_packed_depth_stencil 2007-02-13T08:56:51Z GL_NV_pixel_data_range 2007-02-13T08:56:51Z GL_NV_point_sprite 2007-02-13T08:56:51Z GL_NV_primitive_restart 2007-02-13T08:56:51Z GL_NV_register_combiners 2007-02-13T08:56:51Z GL_NV_register_combiners2 2007-02-13T08:56:51Z GL_NV_texgen_reflection 2007-02-13T08:56:51Z GL_NV_texture_compression_vtc 2007-02-13T08:56:51Z GL_NV_texture_env_combine4 2007-02-13T08:56:51Z GL_NV_texture_expand_normal 2007-02-13T08:56:51Z GL_NV_texture_rectangle 2007-02-13T08:56:51Z GL_NV_texture_shader 2007-02-13T08:56:51Z GL_NV_texture_shader2 2007-02-13T08:56:51Z GL_NV_texture_shader3 2007-02-13T08:56:51Z GL_NV_vertex_array_range 2007-02-13T08:56:51Z GL_NV_vertex_array_range2 2007-02-13T08:56:51Z GL_NV_vertex_program 2007-02-13T08:56:51Z GL_NV_vertex_program1_1 2007-02-13T08:56:51Z GL_NV_vertex_program2 2007-02-13T08:56:51Z GL_NV_vertex_program2_option 2007-02-13T08:56:51Z GL_NV_vertex_program3 2007-02-13T08:56:51Z GL_NVX_conditional_render 2007-02-13T08:56:51Z GL_NVX_instanced_arrays 2007-02-13T08:56:51Z GL_SGIS_generate_mipmap 2007-02-13T08:56:51Z GL_SGIS_texture_lod 2007-02-13T08:56:51Z GL_SGIX_depth_texture 2007-02-13T08:56:51Z GL_SGIX_shadow 2007-02-13T08:56:51Z GL_SUN_slice_accum 2007-02-13T08:56:51Z GL_WIN_swap_hint 2007-02-13T08:56:51Z WGL_EXT_swap_control 2007-02-13T08:56:51Z 2007-02-13T08:56:51Z WGL_ARB_buffer_region 2007-02-13T08:56:51Z WGL_ARB_extensions_string 2007-02-13T08:56:51Z WGL_ARB_make_current_read 2007-02-13T08:56:51Z WGL_ARB_multisample 2007-02-13T08:56:51Z WGL_ARB_pbuffer 2007-02-13T08:56:51Z WGL_ARB_pixel_format 2007-02-13T08:56:51Z WGL_ARB_pixel_format_float 2007-02-13T08:56:51Z WGL_ARB_render_texture 2007-02-13T08:56:51Z WGL_ATI_pixel_format_float 2007-02-13T08:56:51Z WGL_EXT_extensions_string 2007-02-13T08:56:51Z WGL_EXT_swap_control 2007-02-13T08:56:51Z WGL_NV_float_buffer 2007-02-13T08:56:51Z WGL_NV_render_depth_texture 2007-02-13T08:56:51Z WGL_NV_render_texture_rectangle 2007-02-13T08:56:51Z 2007-02-13T08:56:51Z 2007-02-13T08:56:51Z 2007-02-13T08:56:51Z INFO: Viewer Digest: 209311f4-2cdd-1466-d5ff-175f2ac59b3c 2007-02-13T08:56:51Z INFO: Resend: 150 2007-02-13T08:56:51Z INFO: Land: 130 2007-02-13T08:56:51Z INFO: Wind: 26 2007-02-13T08:56:51Z INFO: Cloud: 26 2007-02-13T08:56:51Z INFO: Task: 484 2007-02-13T08:56:51Z INFO: Texture: 484 2007-02-13T08:56:51Z INFO: Asset: 200 2007-02-13T08:56:51Z INFO: Total: 1500 2007-02-13T08:56:51Z INFO: Initializing messaging system... 2007-02-13T08:56:51Z INFO: Message template checksum = 9a5fd87f 2007-02-13T08:56:51Z INFO: attempting to connect on port 0 2007-02-13T08:56:51Z INFO: connected on port 0 2007-02-13T08:56:51Z INFO: startNet - receive buffer size : 400000 2007-02-13T08:56:51Z INFO: startNet - send buffer size : 400000 2007-02-13T08:56:51Z INFO: Message template version matches prehash version number 2007-02-13T08:56:51Z INFO: LLXferManager ack throttle min rate: 2.66667e+006 2007-02-13T08:56:51Z INFO: LLXferManager ack throttle actual rate: 2.93333e+006 2007-02-13T08:56:51Z INFO: LLXferManager ack throttle min rate: 8000 2007-02-13T08:56:51Z INFO: LLXferManager ack throttle actual rate: 150000 2007-02-13T08:56:51Z INFO: AssetStorage: Setting upstream provider to 0.0.0.0:12036 2007-02-13T08:56:51Z INFO: LLAudioEngine_FMOD::init() initializing FMOD 2007-02-13T08:56:51Z INFO: LLAudioEngine_FMOD::init() FMOD initialized correctly 2007-02-13T08:56:53Z INFO: LLSDXMLParser::Impl::parse: XML_STATUS_ERROR parsing: 2007-02-13T09:00:40Z INFO: app_request_quit 2007-02-13T09:00:40Z INFO: Exiting main_loop 2007-02-13T09:00:40Z INFO: Disconnecting viewer! 2007-02-13T09:00:40Z INFO: Viewer disconnected 2007-02-13T09:00:40Z INFO: Cleaning Up 2007-02-13T09:00:40Z INFO: HUD Objects cleaned up 2007-02-13T09:00:40Z INFO: Global stuff deleted 2007-02-13T09:00:40Z WARNING: Hack, skipping audio engine cleanup 2007-02-13T09:00:40Z INFO: Quicktime cleaned up 2007-02-13T09:00:40Z INFO: Cleaning up feature manager 2007-02-13T09:00:40Z INFO: Settings patched up 2007-02-13T09:00:40Z INFO: Cache files removed 2007-02-13T09:00:40Z INFO: Shutting down. 2007-02-13T09:00:40Z WARNING: View holding keyboard focus deleted: panel_login. Keyboard focus removed. 2007-02-13T09:00:40Z INFO: Cleaning up pipeline 2007-02-13T09:00:40Z INFO: Stopping GL during shutdown 2007-02-13T09:00:40Z INFO: Shutting down GL... 2007-02-13T09:00:40Z INFO: Remaining allocated texture memory: 0 bytes 2007-02-13T09:00:40Z INFO: Destroying Window 2007-02-13T09:00:40Z INFO: Closing LLWindowWin32 2007-02-13T09:00:40Z INFO: Shutting down GL 2007-02-13T09:00:40Z INFO: Releasing Context 2007-02-13T09:00:40Z INFO: Destroying Window 2007-02-13T09:00:40Z INFO: ViewerWindow deleted 2007-02-13T09:00:40Z INFO: START MESSAGE LOG SUMMARY 2007-02-13T09:00:40Z Run time: 228.935 seconds 2007-02-13T09:00:40Z Incoming: 2007-02-13T09:00:40Z Total bytes received: 0 ( 0.00 kbits per second) 2007-02-13T09:00:40Z Total packets received: 0 ( 0.00 packets per second) 2007-02-13T09:00:40Z Average packet size: -1 bytes 2007-02-13T09:00:40Z Total reliable packets: 0 ( 0.00%) 2007-02-13T09:00:40Z Total compressed packets: 0 ( 0.00%) 2007-02-13T09:00:40Z Total compression savings: 0 bytes 2007-02-13T09:00:40Z Avg comp packet savings: 0 ( 0.00 : 1) 2007-02-13T09:00:40Z Avg overall comp savings: 0 ( 0.00 : 1) 2007-02-13T09:00:40Z 2007-02-13T09:00:40Z Outgoing: 2007-02-13T09:00:40Z Total bytes sent: 0 ( 0.00 kbits per second) 2007-02-13T09:00:40Z Total packets sent: 0 ( 0.00 packets per second) 2007-02-13T09:00:40Z Average packet size: -1 bytes 2007-02-13T09:00:40Z Total reliable packets: 0 ( 0.00%) 2007-02-13T09:00:40Z Total compressed packets: 0 ( 0.00%) 2007-02-13T09:00:40Z Total compression savings: 0 bytes 2007-02-13T09:00:40Z Avg comp packet savings: 0 ( 0.00 : 1) 2007-02-13T09:00:40Z Avg overall comp savings: 0 ( 0.00 : 1) 2007-02-13T09:00:40Z 2007-02-13T09:00:40Z SendPacket failures: 0 2007-02-13T09:00:40Z Dropped packets: 0 2007-02-13T09:00:40Z Resent packets: 0 2007-02-13T09:00:40Z Failed reliable resends: 0 2007-02-13T09:00:40Z Off-circuit rejected packets: 0 2007-02-13T09:00:40Z On-circuit invalid packets: 0 2007-02-13T09:00:40Z 2007-02-13T09:00:40Z Decoding: 2007-02-13T09:00:40Z Message Count Time Max Avg 2007-02-13T09:00:40Z END MESSAGE LOG SUMMARY 2007-02-13T09:00:40Z 2007-02-13T09:00:40Z INFO: VFS cleaned up 2007-02-13T09:00:40Z INFO: Saving settings to file: C:\Users\Fairlight\AppData\Roaming\SecondLife\user_settings\settings_firstlook.xml 2007-02-13T09:00:40Z INFO: Saved settings 2007-02-13T09:00:40Z INFO: Saving settings to file: C:\Users\Fairlight\AppData\Roaming\SecondLife\user_settings\crash_settings.xml 2007-02-13T09:00:40Z INFO: remove_marker_file() 2007-02-13T09:00:40Z WARNING: Quitting with pending background tasks. 2007-02-13T09:00:40Z INFO: QUEUED THREAD TextureCache EXITING. 2007-02-13T09:00:40Z INFO: LLThread::staticRun() Exiting: TextureCache 2007-02-13T09:00:40Z INFO: QUEUED THREAD ImageDecode EXITING. 2007-02-13T09:00:40Z INFO: LLThread::staticRun() Exiting: ImageDecode 2007-02-13T09:00:40Z INFO: QUEUED THREAD VFS EXITING. 2007-02-13T09:00:40Z INFO: LLThread::staticRun() Exiting: VFS 2007-02-13T09:00:40Z INFO: QUEUED THREAD LFS EXITING. 2007-02-13T09:00:40Z INFO: LLThread::staticRun() Exiting: LFS 2007-02-13T09:00:40Z INFO: VFS Thread finished 2007-02-13T09:00:40Z INFO: Cleaning up APR 2007-02-13T09:00:40Z INFO: Goodbye Best regards, Fairlight! On Tue, 13 Feb 2007 02:05:20 +0100, Rob Lanphier wrote: > On 1/25/07 3:04 PM, Mickey wrote: >> Introducing myself and stating an interest in a native 64-bit client >> for Vista. >> >> Mickey Lane >> Zephyrhills, Florida (US) >> Windows kernel coder (device drivers, file system filters, etc.) >> currently working on anti-spyware applications > Hi Mickey > > Very belated "welcome!" to the list. Steve Linden (cc'd here) was just > asked me "Have you heard of any folks in the OS community working with > Vista?", and looked back through my email to find your email to the list. > > Have you had a chance to compile and play around with it? What's your > (or anyone else's) experience running the Second Life viewer on Vista? > > Rob > > -- (`.-,') -------------------------------------------- .-' ; F a i r l i g h t _.-' , `,- t h e w h i t e l i o n _ _.-' .' /._ .' ` _.-. / ,'._;) E-mail: fairlight@tigress.com ( . )-| ( Homepage: http://www.tigress.com/fairlight )`,_ ,'_,' \_;) fL Puppetry E-Mail: pawpet@pawpet.de ('_ _,'.' (___,)) Puppetry Homepage: http://www.pawpet.de `-:;.-' -------------------------------------------- From splat1 at splat1.com Tue Feb 13 01:49:15 2007 From: splat1 at splat1.com (Matt Evans) Date: Tue Feb 13 01:49:18 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> Message-ID: <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> I know Lua is more of a scripting language rather then a true plugin architecture, but it would provide a lot of what people want from a plugin architecture and has the active benefit of being cross platform and well supported. It may be the VM approach to this, but can inherently provide a better level of system security, although account security depends totally on how it would be implemented. Thoughts? (And before anyone makes a wise crack I'm not a WOW fan.) -- ? Matt Evans ? Splat1 From tofu.linden at lindenlab.com Tue Feb 13 02:19:57 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue Feb 13 02:19:19 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> Message-ID: <45D190CD.2030803@lindenlab.com> Matt Evans wrote: > I know Lua is more of a scripting language rather then a true plugin > architecture, but it would provide a lot of what people want from a > plugin architecture and has the active benefit of being cross platform > and well supported. Lua is spectacular, lightweight, portable, fast and flexible - having implemented it for game and UI logic in the past I would totally support it as an embedded scripting language should it be decided that the client would benefit from such a thing. Sadly I think that discussion is quite orthogonal to the more important question of what the plugin API should look like, i.e. what functionality needs to be exposed to plugins and what the interface to that functionality should look like. Once that interface is established, binding it to a scripting language is usually fairly straightforward. The question behind that of exposed functionality should be: what do people anticipate doing with such plugins? 'Everything' is perhaps not a very useful answer for initial API planning. :) Kind regards, - Tofu! From babbage at lindenlab.com Tue Feb 13 02:43:00 2007 From: babbage at lindenlab.com (Jim Purbrick) Date: Tue Feb 13 02:43:18 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D190CD.2030803@lindenlab.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> Message-ID: If we're advocating virtual machines, I would like to suggest Mono. Ultimately we'd like to allow client side scripts running on the Mono VM, so if viewer plugins were running on a VM it would be nice to use the same one. Cheers, Jim/Babbage On 13 Feb 2007, at 10:19, Tofu Linden wrote: > Matt Evans wrote: >> I know Lua is more of a scripting language rather then a true plugin >> architecture, but it would provide a lot of what people want from a >> plugin architecture and has the active benefit of being cross >> platform >> and well supported. > > Lua is spectacular, lightweight, portable, fast and flexible - having > implemented it for game and UI logic in the past I would totally > support > it as an embedded scripting language should it be decided that the > client would benefit from such a thing. > > Sadly I think that discussion is quite orthogonal to the more > important > question of what the plugin API should look like, i.e. what > functionality needs to be exposed to plugins and what the interface to > that functionality should look like. Once that interface is > established, binding it to a scripting language is usually fairly > straightforward. > > The question behind that of exposed functionality should be: what > do people anticipate doing with such plugins? 'Everything' is perhaps > not a very useful answer for initial API planning. :) > > Kind regards, > - Tofu! > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From sldev at bushing.mm.st Tue Feb 13 02:47:55 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Tue Feb 13 02:48:03 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D190CD.2030803@lindenlab.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> Message-ID: <8DE203D9-875D-4993-9E65-44FCFBB7C616@bushing.mm.st> On Feb 13, 2007, at 2:19 AM, Tofu Linden wrote: > > Sadly I think that discussion is quite orthogonal to the more > important > question of what the plugin API should look like, i.e. what > functionality needs to be exposed to plugins and what the interface to > that functionality should look like. Once that interface is > established, binding it to a scripting language is usually fairly > straightforward. /me applauds -b From dani at protozoo.com Tue Feb 13 03:21:56 2007 From: dani at protozoo.com (Daniel Aguilar) Date: Tue Feb 13 03:22:00 2007 Subject: [sldev] develop plugins using Flash Message-ID: <1ec616de0702130321o64cc2760o8e82b525958f8715@mail.gmail.com> Hi everyone, I just joined the list and read through the archive. I'm happy to see there's so much activity on this subject (a plugin framework), as I've been developing HUDs for some time now and it's clear to me that many things could be drastically improved if run locally on the client side. I'd like to ask if someone has though about the option of using the Flash player for this purpose. I know Flash has some bad reputation as is often related to banners and annoying adds, but it i's currently a pretty efficient piece of software (as by last version, 9) with a powerfull scripting language based on ECMA (similar to JavaScript) and many visualization/communication tools to work with. It also implements some different ways of external communication, both syncronous and async. Also, there's a really big developer community behind it, mainly using it to develop rich interfaces. I have no skills in low level languages such as C, but I have worked in the past with C guys working on the hard side and me creating the view layer with flash, and it really is a damn fast tool for that purpose. I think it is used via activeX, but the player is cross-platform and runs nice both on Win, Mac and Unix. Well, just wondering if it could be of your interest, as I'm really willing to improve the client inteface. Thanks to everyone for your work! -- Daniel Aguilar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070213/817bd443/attachment.htm From jhurliman at wsu.edu Tue Feb 13 03:26:11 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Feb 13 03:25:58 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D190CD.2030803@lindenlab.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> Message-ID: <45D1A053.8070901@wsu.edu> Tofu Linden wrote: > Sadly I think that discussion is quite orthogonal to the more important > question of what the plugin API should look like, i.e. what > functionality needs to be exposed to plugins and what the interface to > that functionality should look like. Once that interface is > established, binding it to a scripting language is usually fairly > straightforward. > > The question behind that of exposed functionality should be: what > do people anticipate doing with such plugins? 'Everything' is perhaps > not a very useful answer for initial API planning. :) > > Kind regards, > - Tofu! > _______________________________________________ > > Agreed. Talking about scripting languages really has nothing to do with the plugin architecture, as you can easily drop luaplugin.dylib or monoplugin.dylib in your Second Life folder *once there is a plugin architecture*. Here is my wishlist for the plugin system, in order of priority: * Raw access to the messaging system. The ability to setup a callback for any packet that can suppress, modify, or pass through any packet before it is sent to the internal SL callbacks, and the ability to inject both incoming and outgoing packets. * Create new menu items that hook to callbacks in the plugin * Create new floaters (windows) * Access to the OpenGL system (Many of these have already existed for years through snowcrash.exe) John Hurliman From a7b22y91 at aol.com Tue Feb 13 06:04:30 2007 From: a7b22y91 at aol.com (Mickey) Date: Tue Feb 13 06:04:40 2007 Subject: [sldev] 64-bit client for Vista In-Reply-To: <45D1C34C.7070702@earthlink.net> References: <45B93785.6070805@aol.com> <45D10ED0.7090306@lindenlab.com> <45D1C34C.7070702@earthlink.net> Message-ID: <45D1C56E.8000604@aol.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070213/0cc296b4/attachment.htm From secret.argent at gmail.com Tue Feb 13 06:05:59 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 13 06:06:05 2007 Subject: [sldev] Re: Plugin API Architecture for Second Life In-Reply-To: <20070213030655.CA5A741AEEA@stupor.lindenlab.com> References: <20070213030655.CA5A741AEEA@stupor.lindenlab.com> Message-ID: <56054FEA-5E54-4A5F-83E3-7578361606C9@gmail.com> My choice for a first cut at a plugin architecture for SL would be a socket-based one for interfacing LSL scripts and scripts local to the PC. That would be easiest to implement, and external scripts could be written that would run on any platform: Windows, Linux, or Mac. There's two possible ways to initiate the connection. You could have a preference pane in SL to configure it, with a list of LSL chat channels and the ports they're assigned to, and whether they're one- way (control only) or two-way (control and feedback). Or you could have a single port that SL listens to and accepts requests for channels from local scripts - the local script would open the port and send a line of text such as "chat=42 listen=0". The port would be opened on localhost only, so it couldn't be used as part of a remote exploit. The external script would open the port. Any line of text it sent would be chatted on that channel by the client. LSL scripts in the sim would interpret that and react appropriately. This would allow you to control LSL scripts that weren't specifically designed for remote control, like existing vehicles. For feedback, all scripts could receive: * Messages sent on channel 0, if the user chooses to allow it - this would be necessary for some vehicle controls. * llInstantMessage messages. * Messages sent on the requested channel, if the client has the ability to request responses from channels other than 0. Otherwise, a HUD forwarder that could convert messages on channels into llInstantMessages could be used. From robla at lindenlab.com Tue Feb 13 09:20:19 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Feb 13 09:20:30 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D190CD.2030803@lindenlab.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> Message-ID: <45D1F353.8000308@lindenlab.com> On 2/13/07 2:19 AM, Tofu Linden wrote > The question behind that of exposed functionality should be: what > do people anticipate doing with such plugins? 'Everything' is perhaps > not a very useful answer for initial API planning. :) > Starting with a concrete example that came up during discussion at my office hour on Friday, I'd like to figure out how to make it possible for Dale Glass to ship his client scanner (see forwarded email below) as a plugin. This would involve the following: * Minimal plugin management (e.g. a set of conventions on where plugin dll/dylib/so files should be located, maybe some initialization file conventions, and a dialog which lets people know what plugins are loaded and running in their viewer. * Stabilization of important interfaces to enable this functionality, breaking out that functionality into a separate dll/dylib/so file. In Dale's case, an example would the API to our XUI user interface layer. * Other hooks/interfaces that give access to useful functionality. I think Bushing sums up the options well here: https://wiki.secondlife.com/wiki/Plugin_architecture_Low-level_Architecture That's what I think would be a reasonable start on things. Get the basic mechanisms in place, stabilize enough interfaces and hooks that it's possible to actually do something useful (like Dale's plugin), and call it version 1.0. After that, keep incrementally adding new hooks and/or stabilizing other interfaces. 2c please. Rob -------- Original Message -------- Subject: [sldev] In-client avatar scanner in progress Date: Sat, 20 Jan 2007 04:12:18 +0100 From: Dale Glass To: sldev@lists.secondlife.com Ok, I've been giving this a try, and so far I seem to be getting somewhere. http://daleglass.net/images/screenshots/client_scanner.png The aim is to create an avatar scanner in the client, showing avatar, distance, and payment data to start with. As you can see there I mostly looked at how the avatar list is built and tried to make my own code starting from that. Screenshot is a bit old, current state of things is better. I thought I would ask a few questions to make sure I'm going in the right direction: So far I figured out LLVOAvatar::sInstances seems to be a list of all the avatars the client knows of (probably the ones known in the connected sims). Is this the right place to look for the data? I want to at the very least duplicate the functionality of in-world scanners, but with a better interface. A constraint is that I don't want to add extra load unless required, so I'd like to use data that the client already gets if possible. Also, can columns be hidden? I'd like to display quite a lot of data, but most people probably won't want all of it (like the exact avatar position) What is LLVOAvatar::isDead()? Lack of comments in the source complicates things a bit for me, as I'm not entirely sure I'm looking for things in the right place, for instance. One of my plans is to add doxygen docs to things as I figure them out. Will LL accept patches for this? Does anybody (LL/SL users) mind such a feature being developed, and are there chances of getting it into the official client? And, is there a testing grid/sim for playing with this stuff? I asked on a recent town hall, and got told to look in the FAQ, but I don't see anything in it. Attempts to connect to other grids failed. Hope that's not too many questions. Thanks in advance :-) -------------- 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/20070213/3f876b01/signature.pgp From dale at daleglass.net Tue Feb 13 11:05:38 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 13 11:06:20 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D1F353.8000308@lindenlab.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <45D1F353.8000308@lindenlab.com> Message-ID: <200702132005.48317.dale@daleglass.net> ? ????????? ?? 13 ??????? 2007 18:20 Rob Lanphier ???????(a): > On 2/13/07 2:19 AM, Tofu Linden wrote > > > The question behind that of exposed functionality should be: what > > do people anticipate doing with such plugins? 'Everything' is perhaps > > not a very useful answer for initial API planning. :) Oh, I have TONS of ideas for plugins. I'm sure other people have ideas too. IMO, plugins are especially good for estoteric functionality. For example, I have something of an obsession with information -- if there's something I could know I'd like to have it displayed. But I doubt LL would integrate most of my additions into the main client, as quite a few of them would have quite specialized purposes. Other examples would include things like client-side versions of HUD attachments. At the time, HUD attachments are seriously limited in what they can do, and suffer from latency, update problems, LSL memory limits, etc. A > > Starting with a concrete example that came up during discussion at my > office hour on Friday, I'd like to figure out how to make it possible > for Dale Glass to ship his client scanner (see forwarded email below) as > a plugin. This would involve the following: > * Minimal plugin management (e.g. a set of conventions on where plugin > dll/dylib/so files should be located, maybe some initialization file > conventions, and a dialog which lets people know what plugins are loaded > and running in their viewer. Since I appear to be one of the first people working on something that would work well as a plugin, I would appreciate if somebody could tell me which people are working on the plugin system. I think it would be good to discuss how to make the functionality my plugin would need available, and of course I would convert my code into a plugin when it becomes possible. > * Stabilization of important interfaces to enable this functionality, > breaking out that functionality into a separate dll/dylib/so file. In > Dale's case, an example would the API to our XUI user interface layer. > * Other hooks/interfaces that give access to useful functionality. I > think Bushing sums up the options well here: > https://wiki.secondlife.com/wiki/Plugin_architecture_Low-level_Architecture In case somebody is interested (especially people implementing plugins functionality, here's what my code currently requires): * XUI (obviously) * Knowing the logged in user's current position * Access to list of known users. Currently done by scanning LLCharacter::sInstances every frame, but a callback based approach that would notify of new and disappearing avatars would also work, and probably save some CPU time as well. * If using LLCharacter::sInstances then I need to be able to run code during every frame, to detect changes. * If using callbacks, then I still need the ability to periodically run code. A timer callback would work. * Ability to measure passage of time * Sending messages. Specifically AvatarPropertiesRequest. * Receiving the reply * Setting a beacon on an avatar or a location (LLTracker class) * Finding when an avatar is producing a sound Future requirements: * Ability to interface with an in-world scripted object. Until a specific method is created, it would be by speaking on a channel and filtering replies with llOwnerSay * Ability to detect when avatars are rezzing, generating particles, or using a gesture * Ability to read/write files, probably in XML * Ability to save/load settings -------------- 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/20070213/775b3f28/attachment.pgp From tshephard at gmail.com Tue Feb 13 12:13:25 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 13 12:13:29 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> Message-ID: <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> Hey Jim, It looks like we've decided that loading DLLs into memory is the way to go. Loading a DLL means that anyone can drop in any VM they want (or spyware, key logger, etc..) Be it Lua, Mono, ScriptMonkey, etc. Personally, I think that we're rushing ahead jumping into the implementation phase already without thinking things through, but this certainly serves my purpose. Nothing like ready, fire, aim! The software engineer in me is a tad alarmed, but the profiteer in me is pretty happy! ;) Cheers, Tim. On 2/13/07, Jim Purbrick wrote: > If we're advocating virtual machines, I would like to suggest Mono. > Ultimately we'd like to allow client side scripts running on the Mono > VM, so if viewer plugins were running on a VM it would be nice to use > the same one. > > Cheers, > > Jim/Babbage > > On 13 Feb 2007, at 10:19, Tofu Linden wrote: > > > Matt Evans wrote: > >> I know Lua is more of a scripting language rather then a true plugin > >> architecture, but it would provide a lot of what people want from a > >> plugin architecture and has the active benefit of being cross > >> platform > >> and well supported. > > > > Lua is spectacular, lightweight, portable, fast and flexible - having > > implemented it for game and UI logic in the past I would totally > > support > > it as an embedded scripting language should it be decided that the > > client would benefit from such a thing. > > > > Sadly I think that discussion is quite orthogonal to the more > > important > > question of what the plugin API should look like, i.e. what > > functionality needs to be exposed to plugins and what the interface to > > that functionality should look like. Once that interface is > > established, binding it to a scripting language is usually fairly > > straightforward. > > > > The question behind that of exposed functionality should be: what > > do people anticipate doing with such plugins? 'Everything' is perhaps > > not a very useful answer for initial API planning. :) > > > > Kind regards, > > - Tofu! > > _______________________________________________ > > 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 tshephard at gmail.com Tue Feb 13 12:47:00 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 13 12:47:09 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D1F353.8000308@lindenlab.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <45D1F353.8000308@lindenlab.com> Message-ID: <3b19a500702131247g1d6ea2c6o6b2235d86d96af53@mail.gmail.com> > * Other hooks/interfaces that give access to useful functionality. I > think Bushing sums up the options well here: > https://wiki.secondlife.com/wiki/Plugin_architecture_Low-level_Architecture > This approach is great, however there are a couple of specific concerns I have: * The hook code on this page is not linking against the functionality at large in the client. This means there is no easy way to add messages to the queue or access the global UI factories. For example, it would be nice to call gUICtrlFactory->buildFloater() >From the plugins. * I'd like to see an arbitrary number of parameters rather than just two. Also, once we're bringing in headers from the client we should be able to use better typing than void *s. Cheers, Tim. > -------- Original Message -------- > Subject: [sldev] In-client avatar scanner in progress > Date: Sat, 20 Jan 2007 04:12:18 +0100 > From: Dale Glass > To: sldev@lists.secondlife.com > > > > Ok, I've been giving this a try, and so far I seem to be getting somewhere. > > http://daleglass.net/images/screenshots/client_scanner.png > > The aim is to create an avatar scanner in the client, showing avatar, > distance, and payment data to start with. As you can see there I mostly > looked at how the avatar list is built and tried to make my own code starting > from that. Screenshot is a bit old, current state of things is better. > > I thought I would ask a few questions to make sure I'm going in the right > direction: > > So far I figured out LLVOAvatar::sInstances seems to be a list of all the > avatars the client knows of (probably the ones known in the connected sims). > Is this the right place to look for the data? I want to at the very least > duplicate the functionality of in-world scanners, but with a better > interface. A constraint is that I don't want to add extra load unless > required, so I'd like to use data that the client already gets if possible. > > Also, can columns be hidden? I'd like to display quite a lot of data, but most > people probably won't want all of it (like the exact avatar position) > > What is LLVOAvatar::isDead()? > > Lack of comments in the source complicates things a bit for me, as I'm not > entirely sure I'm looking for things in the right place, for instance. One of > my plans is to add doxygen docs to things as I figure them out. Will LL > accept patches for this? > > Does anybody (LL/SL users) mind such a feature being developed, and are there > chances of getting it into the official client? > > And, is there a testing grid/sim for playing with this stuff? I asked on a > recent town hall, and got told to look in the FAQ, but I don't see anything > in it. Attempts to connect to other grids failed. > > Hope that's not too many questions. Thanks in advance :-) > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From gigstaggart at gmail.com Tue Feb 13 13:10:06 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 13 13:10:01 2007 Subject: [sldev] 64-bit client for Vista In-Reply-To: <45D1C56E.8000604@aol.com> References: <45B93785.6070805@aol.com> <45D10ED0.7090306@lindenlab.com> <45D1C34C.7070702@earthlink.net> <45D1C56E.8000604@aol.com> Message-ID: <45D2292E.4080300@gmail.com> Mickey wrote: >> RTM). They worked on the various Vista beta releases. I haven't spent >> any time at all looking into what the various third party packages >> needed by the SL client would look like on 64-bit but I can make a >> really good guess... To sum, 64-bit Vista is *not* anywhere close to You'd be surprised. Most of the libraries SL uses are open source, and therefore support 64 bit just fine. It's only proprietary crap that can't deal with 64 bit, all the open source stuff has been supporting it for years now. -Jason From gigstaggart at gmail.com Tue Feb 13 13:16:56 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 13 13:16:48 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> Message-ID: <45D22AC8.80005@gmail.com> Tim Shephard wrote: > Personally, I think that we're rushing ahead jumping into the > implementation phase already without thinking things through, but this > certainly serves my purpose. Patch first, discuss later is the open source way. It works, and it cuts through a lot of debating that doesn't get anything accomplished. -Jason From tshephard at gmail.com Tue Feb 13 13:42:09 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 13 13:42:13 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D22AC8.80005@gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> <45D22AC8.80005@gmail.com> Message-ID: <3b19a500702131342s302ece2ft2faf372ac193ef8f@mail.gmail.com> I'll agree - patch first, think later - it's a lot more entertaining doing things that way. Unfortunately, I can't really afford to be a part of that methodology, as I'm no longer a university student. But I'll be happy to use whatever you folks come up with. Cheers, Tim. On 2/13/07, Jason Giglio wrote: > Tim Shephard wrote: > > Personally, I think that we're rushing ahead jumping into the > > implementation phase already without thinking things through, but this > > certainly serves my purpose. > > Patch first, discuss later is the open source way. It works, and it > cuts through a lot of debating that doesn't get anything accomplished. > > -Jason > > From sldev at bushing.mm.st Tue Feb 13 15:11:13 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Tue Feb 13 15:11:17 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <3b19a500702131342s302ece2ft2faf372ac193ef8f@mail.gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> <45D22AC8.80005@gmail.com> <3b19a500702131342s302ece2ft2faf372ac193ef8f@mail.gmail.com> Message-ID: On Feb 13, 2007, at 1:42 PM, Tim Shephard wrote: > I'll agree - patch first, think later - it's a lot more entertaining > doing things that way. > > Unfortunately, I can't really afford to be a part of that methodology, > as I'm no longer a university student. But I'll be happy to use > whatever you folks come up with. > Me neither, but I don't have time to argue over what color to paint the bikeshed; coming up with a prototype sidesteps a lot of that. @ Linden Lab: It sounds like splitting chunks of the viewer code into dynamically- loaded chunks is a win-win situation: * Plugins could then link against that code * Dynamic chunks could be updated without disturbing the rest of the viewer * The same mechanisms could be used to create plugins * Infrequently-used functions (estate manager, etc?) could defer loading until they're actually needed. Given that I can't sign a code-contribution agreement, how can I help with this effort? -b From david at fries.net Tue Feb 13 15:19:13 2007 From: david at fries.net (David Fries) Date: Tue Feb 13 15:19:29 2007 Subject: [sldev] 64-bit client In-Reply-To: <45D2292E.4080300@gmail.com> References: <45B93785.6070805@aol.com> <45D10ED0.7090306@lindenlab.com> <45D1C34C.7070702@earthlink.net> <45D1C56E.8000604@aol.com> <45D2292E.4080300@gmail.com> Message-ID: <20070213231913.GC9336@spacedout.fries.net> I've been running 64 bit on Linux for a while now. It will crash if you don't have the patches for Second Life. Some of my patches have been included already, they aren't specific to Linux. You'll want to look at jira VWR-123 to get OpenJPEG up to speed and other fixes. -- David Fries http://fries.net/~david/ (PGP encryption key available) From tshephard at gmail.com Tue Feb 13 15:38:26 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 13 15:38:31 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> <45D22AC8.80005@gmail.com> <3b19a500702131342s302ece2ft2faf372ac193ef8f@mail.gmail.com> Message-ID: <3b19a500702131538x2c804b8au479db34393985fe6@mail.gmail.com> On 2/13/07, Ben Byer wrote: > On Feb 13, 2007, at 1:42 PM, Tim Shephard wrote: > > > I'll agree - patch first, think later - it's a lot more entertaining > > doing things that way. > > > > Unfortunately, I can't really afford to be a part of that methodology, > > as I'm no longer a university student. But I'll be happy to use > > whatever you folks come up with. > > > > Me neither, but I don't have time to argue over what color to paint > the bikeshed; coming up with a prototype sidesteps a lot of that. > Equating issues of stability and security to the color of paint on a bikeshed? Anyways, this isn't aimed at your prototype. Prototyping is great, the more the better. My hopes are that LL has already signed on to all of this, and we're just not getting the full story (suprise), so this will all work out fine. However, if things don't get merged or this never pans out, I hope we all understand we have no reason to complain. > @ Linden Lab: > > It sounds like splitting chunks of the viewer code into dynamically- > loaded chunks is a win-win situation: > > * Plugins could then link against that code > * Dynamic chunks could be updated without disturbing the rest of the > viewer > * The same mechanisms could be used to create plugins > * Infrequently-used functions (estate manager, etc?) could defer > loading until they're actually needed. > > Given that I can't sign a code-contribution agreement, how can I help > with this effort? > > -b > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From joel at ourstillwaters.org Tue Feb 13 16:29:47 2007 From: joel at ourstillwaters.org (Joel Riedesel) Date: Tue Feb 13 16:29:57 2007 Subject: [sldev] Any description of LL GUI model? Message-ID: <17874.22523.251000.971668@gargle.gargle.HOWL> Hello, Is there any halfway-usable description of the LLGUI model in SL Client floating about somewhere? I'm finding it difficult to determine what I need to implement and subclass in order to build my own floaters, dialogs or just plain widgets/controls. Start from LLView? LLPanel? How easy is it to use the LLScroll... class? Any pointers would be greatly appreciated. Cheers, Joel From mindtriggerz at gmail.com Tue Feb 13 16:31:20 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Tue Feb 13 16:31:24 2007 Subject: [sldev] Any description of LL GUI model? In-Reply-To: <17874.22523.251000.971668@gargle.gargle.HOWL> References: <17874.22523.251000.971668@gargle.gargle.HOWL> Message-ID: It's XML UI. Check the Learn By Example section of the open source portal on wiki.secondlife.com. On 2/13/07, Joel Riedesel wrote: > Hello, > > Is there any halfway-usable description of the LLGUI model > in SL Client floating about somewhere? > > I'm finding it difficult to determine what I need to implement > and subclass in order to build my own floaters, dialogs or just > plain widgets/controls. Start from LLView? LLPanel? > > How easy is it to use the LLScroll... class? > > Any pointers would be greatly appreciated. > > Cheers, > Joel > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- --Jesse From joel at ourstillwaters.org Tue Feb 13 16:40:37 2007 From: joel at ourstillwaters.org (Joel Riedesel) Date: Tue Feb 13 16:40:45 2007 Subject: [sldev] Any description of LL GUI model? In-Reply-To: References: <17874.22523.251000.971668@gargle.gargle.HOWL> Message-ID: <17874.23173.357000.352767@gargle.gargle.HOWL> Thanks. I'm aware of that. Is that the intent of their model at this point - to only be used via the XML descriptions? If I want to develop my own look and feel for something I am doing I don't believe that the XML descriptions will allow me to do that. Perhaps I'm mis-applying the direction of my integration efforts here. I'll take another look at seeing what I can do with the XML approach but it'd be nice to know: - The actual LL GUI model - The GL integration level/layer (on windows) and how that could be taken advantage of to completely sidestep the LL GUI model if necessary Obviously, any existing words about this would be helpful. Cheers, Joel Jesse Nesbitt writes: > It's XML UI. Check the Learn By Example section of the open source > portal on wiki.secondlife.com. > > On 2/13/07, Joel Riedesel wrote: > > Hello, > > > > Is there any halfway-usable description of the LLGUI model > > in SL Client floating about somewhere? > > > > I'm finding it difficult to determine what I need to implement > > and subclass in order to build my own floaters, dialogs or just > > plain widgets/controls. Start from LLView? LLPanel? > > > > How easy is it to use the LLScroll... class? > > > > Any pointers would be greatly appreciated. > > > > Cheers, > > Joel > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > > > -- > --Jesse From david at fries.net Tue Feb 13 17:15:56 2007 From: david at fries.net (David Fries) Date: Tue Feb 13 17:16:22 2007 Subject: [sldev] JIRA e-mail notifications Message-ID: <20070214011556.GD9336@spacedout.fries.net> Does anyone know how to enable e-mail notifications on JIRA? It would be really useful. I just looked at a bug report of mine today and it had a comment, it would have been nice to not have to pool the reports. The 'Your profile' page has a field for Email, and the 'Update User Preferences' has e-mail options, but I don't see where I set an e-mail address. -- David Fries http://fries.net/~david/ (PGP encryption key available) From sldev at bushing.mm.st Tue Feb 13 17:22:05 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Tue Feb 13 17:22:08 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <3b19a500702131538x2c804b8au479db34393985fe6@mail.gmail.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> <45D22AC8.80005@gmail.com> <3b19a500702131342s302ece2ft2faf372ac193ef8f@mail.gmail.com> <3b19a500702131538x2c804b8au479db34393985fe6@mail.gmail.com> Message-ID: <6A22B4A1-ACCE-4A84-A2E2-2434D9FCBCDD@bushing.mm.st> On Feb 13, 2007, at 3:38 PM, Tim Shephard wrote: > On 2/13/07, Ben Byer wrote: >> On Feb 13, 2007, at 1:42 PM, Tim Shephard wrote: >> >> > I'll agree - patch first, think later - it's a lot more >> entertaining >> > doing things that way. >> > >> > Unfortunately, I can't really afford to be a part of that >> methodology, >> > as I'm no longer a university student. But I'll be happy to use >> > whatever you folks come up with. >> > >> >> Me neither, but I don't have time to argue over what color to paint >> the bikeshed; coming up with a prototype sidesteps a lot of that. >> > > Equating issues of stability and security to the color of paint on > a bikeshed? No, I was equating quibbling over the number of parameters for a callback to arguing over the http://en.wikipedia.org/wiki/Color_of_the_bikeshed (As Tofu Linden already noted, stability and security are important issues, but orthogonal to this discussion.) > Anyways, this isn't aimed at your prototype. Prototyping is great, > the more the better. Thanks. It was only put out there with the hope that someone would come along and clean it up or suggest a specifically better method. > My hopes are that LL has already signed on to all of this, and we're > just not getting the full story (suprise), so this will all work out > fine. However, if things don't get merged or this never pans out, > I hope we all understand we have no reason to complain. Why? -b From tshephard at gmail.com Tue Feb 13 17:30:17 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 13 17:30:22 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <6A22B4A1-ACCE-4A84-A2E2-2434D9FCBCDD@bushing.mm.st> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> <45D22AC8.80005@gmail.com> <3b19a500702131342s302ece2ft2faf372ac193ef8f@mail.gmail.com> <3b19a500702131538x2c804b8au479db34393985fe6@mail.gmail.com> <6A22B4A1-ACCE-4A84-A2E2-2434D9FCBCDD@bushing.mm.st> Message-ID: <3b19a500702131730re8ee424v61ea5e1523b78022@mail.gmail.com> > > My hopes are that LL has already signed on to all of this, and we're > > just not getting the full story (suprise), so this will all work out > > fine. However, if things don't get merged or this never pans out, > > I hope we all understand we have no reason to complain. > > Why? I'll start up a new thread to answer this. From carnildo at gmail.com Tue Feb 13 23:28:14 2007 From: carnildo at gmail.com (Mark Wagner) Date: Tue Feb 13 23:28:15 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D190CD.2030803@lindenlab.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <3b19a500702121837y6bfe8ff3k27736890ecf91369@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> Message-ID: <31073ef90702132328m6328c9e2xeb6c9f109bf6b08d@mail.gmail.com> On 2/13/07, Tofu Linden wrote: > Sadly I think that discussion is quite orthogonal to the more important > question of what the plugin API should look like, i.e. what > functionality needs to be exposed to plugins and what the interface to > that functionality should look like. Once that interface is > established, binding it to a scripting language is usually fairly > straightforward. > > The question behind that of exposed functionality should be: what > do people anticipate doing with such plugins? 'Everything' is perhaps > not a very useful answer for initial API planning. :) "Everything" sounds like a good start. Failing that, my raytracing engine needs hooks into the low-level geometry-generation code to suppress the normal OpenGL output, and instead generate raytracing primitives. A hook into the high-level geometry-generation routine would also be required to inject the resulting image back into the client. Hooks into the initialization code, the main loop (for synchronization), and the ability to create new preferences tabs would also be nice. -- Mark Carnildo Greenacre From george.williams at gmail.com Tue Feb 13 23:42:15 2007 From: george.williams at gmail.com (George Williams) Date: Tue Feb 13 23:42:17 2007 Subject: [sldev] compile ok, userserver.dmz.lindenlab.com does not exist Message-ID: <85e6f7f00702132342h71133258w5fc1036542df47c@mail.gmail.com> Hi, I was just able to compile the src code. Perhaps a silly question - how do I change the server that it goes to? What is a valid server I can try with my compiled code? It does not like userserver.dmz.lindenlab.com, which appears to be the default. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070213/0c19db3b/attachment.htm From robla at lindenlab.com Wed Feb 14 00:29:04 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Feb 14 00:29:15 2007 Subject: [sldev] 9am office hour topic: plugin architecture Message-ID: <45D2C850.9000508@lindenlab.com> Hi all, The 9am PST office hour topic today will be a discussion of plugin architecture. For those of you who can't make it, don't worry too much. I'm hoping someone will volunteer to take notes if the conversation becomes interesting, and still consider this mailing list the preferred venue for broad discussion. The in-world discussion will center around my advice for accelerating the process, for those that are most eager to see progress on this front. Further details available here: https://wiki.secondlife.com/wiki/User:Rob_Linden 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/20070214/2d59c6db/signature.pgp From mindtriggerz at gmail.com Wed Feb 14 05:58:17 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Wed Feb 14 05:58:25 2007 Subject: [sldev] compile ok, userserver.dmz.lindenlab.com does not exist In-Reply-To: <85e6f7f00702132342h71133258w5fc1036542df47c@mail.gmail.com> References: <85e6f7f00702132342h71133258w5fc1036542df47c@mail.gmail.com> Message-ID: DMZ is an internal Linden Labs grid, change the drop down box on the side in the login screen to Agni, the current production grid. On 2/14/07, George Williams wrote: > Hi, > > I was just able to compile the src code. > > Perhaps a silly question - how do I change the server that it goes to? What > is a valid server I can try with my compiled code? > > It does not like userserver.dmz.lindenlab.com, which appears to be the > default. > > Thank you! > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- --Jesse From secret.argent at gmail.com Wed Feb 14 06:21:56 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Feb 14 06:22:02 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <20070214002957.CB15141AEE3@stupor.lindenlab.com> References: <20070214002957.CB15141AEE3@stupor.lindenlab.com> Message-ID: <7BF11E00-F708-4B45-9C25-7C93390CEFD5@gmail.com> > Patch first, discuss later is the open source way. It works, and it > cuts through a lot of debating that doesn't get anything accomplished. There's no single "the open source way". And "patch first, discuss later" is just as common in proprietary software. And it's produced some notable disasters on both sides. There are tools available to generate compatible calls between embedded languages and compiled languages that provide a much higher level view than this. At the very least it should be possible for the hooks for a given function to take the same parameters as that function, and to call that function explicitly. Unfortunately, C++ is in a horrid swamp between classical structured languages that have a well defined low level calling mechanism, and modern dynamic object-oriented languages that let you call any method of any object that implements the required method at runtime. So I'm not sure a totally general plugin API that's completely function-agnostic is even meaningful in this code base. I think the first thing that needs to be done is to look for the places in SL where a plugin architecture makes sense. Where do you most need to be able to hook in to it? What kind of architecture works best for it? That's where I'm coming from with my socket concept. Here's where I most see hooks being needed: * chat... my socket idea * controls... plug-ins for joysticks and the like * editing actions... eg, "autosave this script I'm working on", or "smart-snap these prims" * other user interface events and llGUI * texture loading * texture rendering... eg, "composite this application window on "10234-18378-...". * client-sim communications * in-client databases... examining or even inserting items into the object, avatar, and prim lists Looking for places where these come together and there's a big benefit for low cost is the best way to start. And the proposed architecture looks more like coming up with a new kind of paint when you haven't decided whether you're building a bike shed or a swimming pool yet. From liuc at ohio.edu Wed Feb 14 06:25:33 2007 From: liuc at ohio.edu (Chang Liu) Date: Wed Feb 14 06:25:44 2007 Subject: [sldev] Second Life use of undocumented ports In-Reply-To: <9ab86fb00702140624g7cbd7c18r713840ca51751213@mail.gmail.com> References: <9ab86fb00702140624g7cbd7c18r713840ca51751213@mail.gmail.com> Message-ID: <9ab86fb00702140625p6bf3fb0fu9e010e8a1efd3d3d@mail.gmail.com> According to Linden Lab (http://secondlife.com/whatis/faq.php), "Second Life needs to connect to ports 443/TCP, 12035/UDP, 12036/UDP, and 13000-13050/UDP." Our tech people recently detected traffic on port 12043 to the Second Life servers. Does anyone know if the current version uses any undocumented ports, including 12043? Many thanks! Chang -- Chang Liu, Assistant Professor, School of EECS, Ohio University -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070214/1bb994cb/attachment.htm From aestes at acm.org Wed Feb 14 07:16:49 2007 From: aestes at acm.org (Andy Estes) Date: Wed Feb 14 07:14:26 2007 Subject: [sldev] 9am office hour topic: plugin architecture In-Reply-To: <45D2C850.9000508@lindenlab.com> Message-ID: <200702141514.l1EFEOH2027188@ms-smtp-03.tampabay.rr.com> I will try to be there but wanted to add my 5L$ on the list I believe this will have to be a phased implementation. Start with some basics and add to it later. I would love to have a client-side scripting environment but agree that should be a separate discussion. I think there is a general consensus toward the dynamic library load/message hooks approach. It is easy to implement and would be useful for an entire class of filter-style plugins. The plug-in would need access to some internal functions (e.g. floater creation, text rendering). I don't think it will be very easy to provide hooks into the rendering engine initially but confess that I haven't spent much time looking at the rendering code so I would be happy to be proven wrong. Some type of plug-in manager to loading/unloading is also a necessity. Security is an issue which must be dealt with. With the ability to hook and discard messages it might be trivial to write an uber-cool plug-in which also happens to pay the author a few Linden Dollars every day or so. Short of looking at their transaction records, the user would never know. The best approach might be Linden issued certificates as it would tie First Life name (which could remain hidden) to Second Life name to TOS. Unfortunately, I don't know if LL would have the cycles to manage this any time soon. Personally, I am a fan of the design some, prototype some, design some more style of engineering. There is a bit of a catch-22 here because the code base on which we are prototyping is regularly being changed and we don't know what the next revision will bring. Still, for my own part, I will probably set up a local repository and start playing with bushing's code. My question for Rob and LL is "Would you be willing to accept a phased implementation (probably over a period of weeks to months) or would you rather receive a more complete implementation?" SL: Drewan FL: Andy -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Rob Lanphier Sent: Wednesday, February 14, 2007 3:29 AM To: Second Life Developer Mailing List Subject: [sldev] 9am office hour topic: plugin architecture Hi all, The 9am PST office hour topic today will be a discussion of plugin architecture. For those of you who can't make it, don't worry too much. I'm hoping someone will volunteer to take notes if the conversation becomes interesting, and still consider this mailing list the preferred venue for broad discussion. The in-world discussion will center around my advice for accelerating the process, for those that are most eager to see progress on this front. Further details available here: https://wiki.secondlife.com/wiki/User:Rob_Linden Rob From robla at lindenlab.com Wed Feb 14 11:19:58 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Feb 14 11:20:15 2007 Subject: [sldev] Second Life use of undocumented ports In-Reply-To: <9ab86fb00702140625p6bf3fb0fu9e010e8a1efd3d3d@mail.gmail.com> References: <9ab86fb00702140624g7cbd7c18r713840ca51751213@mail.gmail.com> <9ab86fb00702140625p6bf3fb0fu9e010e8a1efd3d3d@mail.gmail.com> Message-ID: <45D360DE.9040906@lindenlab.com> On 2/14/07 6:25 AM, Chang Liu wrote: > According to Linden Lab (http://secondlife.com/whatis/faq.php), > "Second Life needs to connect to ports 443/TCP, 12035/UDP, 12036/UDP, > and 13000-13050/UDP." Our tech people recently detected traffic on > port 12043 to the Second Life servers. Does anyone know if the current > version uses any undocumented ports, including 12043? Many thanks! Hi Chang, This was a recent change, documented here: http://secondlife.com/knowledgebase/article.php?id=3D355 I've filed a bug report to get that inaccuracy resolved. Thanks for noting it! 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/20070214/90aabb46/signature.pgp From tshephard at gmail.com Wed Feb 14 11:21:32 2007 From: tshephard at gmail.com (Tim Shephard) Date: Wed Feb 14 11:21:35 2007 Subject: [sldev] Where is communication occuring, mailing list or IRC? Message-ID: <3b19a500702141121w2081a8a9u9bf0e9b65b3f0264@mail.gmail.com> Hey Rob, some miscommunication is obviously occuring. Can you let us know where you're going to communicate decisions in IRC, or on the mailing list? I had been under the impression that it was going to happen on the mailing list, but apparently things are are being discussed and decided elswhere. Not a problem, but some consistency would be appreciated. From robla at lindenlab.com Wed Feb 14 11:39:57 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Feb 14 11:40:08 2007 Subject: [sldev] Where is communication occuring, mailing list or IRC? In-Reply-To: <3b19a500702141121w2081a8a9u9bf0e9b65b3f0264@mail.gmail.com> References: <3b19a500702141121w2081a8a9u9bf0e9b65b3f0264@mail.gmail.com> Message-ID: <45D3658D.5080304@lindenlab.com> On 2/14/07 11:21 AM, Tim Shephard wrote: > Hey Rob, some miscommunication is obviously occuring. > > Can you let us know where you're going to communicate decisions in > IRC, or on the mailing list? > > I had been under the impression that it was going to happen on the > mailing list, but apparently things are are being discussed and > decided elswhere. > > Not a problem, but some consistency would be appreciated. Unofficial discussions can happen anywhere (including at my office hour), but "official" discussions need to happen here. The goal is not to slow people down unnecessarily. Often times, real-time communication is the fastest way to get things done. However, I also don't want to leave anyone out of the discussion who can't be there for a real-time discussion. Hence, as far as I'm concerned, the discussion that happened this morning didn't really happen until it gets documented on this mailing list :) I'll restate the important points I made during our discussion this morning. I think the way forward is to document the choices considered, the rough consensus, and the plan moving forward, and put it all here: https://wiki.secondlife.com/wiki/Plugin_architecture ...then send out mail to the mailing list for comment. Looks like there's been work on that page; if you don't agree with what's going on there, feel free to either put a comment on the talk page, or send out a "whoa, wait a sec" to this mailing list. The current state of that page seems to reflect the rough consensus so far, but doesn't yet have a fair summary of the options considered. I'm hoping its still a work in progress, given that I haven't yet seen anyone claim to be done with the work. If you want to have a real-time conversation with me personally, then get my attention either in-world, or on the #opensl IRC channel on irc.efnet.org if I'm not around. Just understand (per what I've described on IRC before) that getting me to agree that something is reasonable is not the same as getting Linden Lab to agree to something, and that if you're trying to get the general attention of Linden Lab or want me to make sure that LL is aware of something, this mailing list is the best way to do it. 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/20070214/23fbb298/signature.pgp From rdw at lindenlab.com Wed Feb 14 11:49:57 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Wed Feb 14 11:50:42 2007 Subject: [sldev] Second Life use of undocumented ports In-Reply-To: <45D360DE.9040906@lindenlab.com> References: <9ab86fb00702140624g7cbd7c18r713840ca51751213@mail.gmail.com> <9ab86fb00702140625p6bf3fb0fu9e010e8a1efd3d3d@mail.gmail.com> <45D360DE.9040906@lindenlab.com> Message-ID: <45D367E5.80204@lindenlab.com> Rob Lanphier wrote: > On 2/14/07 6:25 AM, Chang Liu wrote: >> According to Linden Lab (http://secondlife.com/whatis/faq.php), >> "Second Life needs to connect to ports 443/TCP, 12035/UDP, 12036/UDP, >> and 13000-13050/UDP." Our tech people recently detected traffic on >> port 12043 to the Second Life servers. Does anyone know if the current >> version uses any undocumented ports, including 12043? Many thanks! > Hi Chang, > > This was a recent change, documented here: > http://secondlife.com/knowledgebase/article.php?id=3D355 That url went to the "what are graphics cards?" article. Here's the one I think you meant: http://secondlife.com/knowledgebase/article.php?id=355 -RYaN > > I've filed a bug report to get that inaccuracy resolved. Thanks for > noting it! > > Rob > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From robla at lindenlab.com Wed Feb 14 13:52:38 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Feb 14 13:52:47 2007 Subject: [sldev] Development philosophy Message-ID: <45D384A6.5050602@lindenlab.com> Hi folks, Based on the chatter I see on IRC and other unofficial channels, there seems to be some consternation about Linden Lab's policy with respect to collaboration with the free software/open source community. One disconnect, I believe, is that many people may have an unrealistic picture of Linden Lab as a monolithic Borg-like structure with a completely unified view of the world and its role in it. It's an understandable mistake, since many corporations actually pretend that they operate that way. However, no group of two or more people operates that way, hence the reason why children the world over have learned they can play one parent off of the other (e.g. "but Mom said I could!"). Linden Lab doesn't even pretend that's the case, hence you'll see lots of blog postings from lots of different people here at Linden Lab, each in a unique voice. It's hard to have an authentically human voice when everything get blandified/corporatified by the consensus and approval filter, and we feel like the quality and authenticity is better than making sure every single thing we say is 100% representative of every person at Linden Lab. The reason I bring this disconnect up is when I'm asked the question "how does Linden Lab want to work with the community?", I can only answer with how *I* want to work with the community. And that answer is going to change depending on our situation and who we're able to hire. Right now, I'm the only person who's stated job description involves working with the open source community. Therefore, I'm going to be focused on working out the process of working with the community. Since I'm not a developer, and since people at Linden Lab choose their own work, other people at Linden Lab will have to be convinced that this is the cool happening place for other developers to join in the external collaboration. Just about everyone currently at Linden Lab hired in before they knew that Linden Lab was going to release source code, the natural instinct of those developers is to keep plugging away inside the firewall. We've got many issues to deal with right now, mainly centering around the phenomenal growth in popularity of Second Life, and the ability (or inability) of our infrastructure to deal with it. Collaboration with the open source community is something that we also want to do well, but it's going to take some time and effort to make that investment pay off. So, in the short term, we're trying to make sure we at least get the transparency and infrastructure in place for a deeper collaboration down the road. You may disagree with that priority of things. One way of fixing that problem is to draw those developers out with high value activity, which seems to be happening. Another way is for new developers to come from the group who is reading this email right now and doesn't think that Linden Lab is doing enough in the community. If you want to really accelerate this initiative, come work for us, and show us how it's done! 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/20070214/d03e30cd/signature.pgp From gigstaggart at gmail.com Wed Feb 14 14:24:36 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Feb 14 14:24:38 2007 Subject: [sldev] Development philosophy In-Reply-To: <45D384A6.5050602@lindenlab.com> References: <45D384A6.5050602@lindenlab.com> Message-ID: <45D38C24.9030705@gmail.com> Rob, More specifically, can we expect the following: 1. Linden Lab sign-offs on major functionality before work begins 2. Any assurance our code will be merged, ahead of time I don't have these expectation, but it seems that some do. Specifically can you reply to the following: --------------------- Tim said: > My hopes are that LL has already signed on to all of this, and we're > just not getting the full story (suprise), so this will all work out --------------------- This "development roadmap" that looks like something straight out of a PMI exam study guide: https://wiki.secondlife.com/w/index.php?title=Plugin_architecture_RoadMap&oldid=9910 I edited out "linden sign off" but the rest is almost as bad. This was the version as it stood before I edited it. --------------------- From robla at lindenlab.com Wed Feb 14 14:25:49 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Feb 14 14:26:08 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> <45D22AC8.80005@gmail.com> <3b19a500702131342s302ece2ft2faf372ac193ef8f@mail.gmail.com> Message-ID: <45D38C6D.8050707@lindenlab.com> On 2/13/07 3:11 PM, Ben Byer wrote: > @ Linden Lab: > > It sounds like splitting chunks of the viewer code into > dynamically-loaded chunks is a win-win situation: > > * Plugins could then link against that code > * Dynamic chunks could be updated without disturbing the rest of the > viewer > * The same mechanisms could be used to create plugins > * Infrequently-used functions (estate manager, etc?) could defer > loading until they're actually needed. > > Given that I can't sign a code-contribution agreement, how can I help > with this effort? That definitely puts a damper on things in general. If you can't agree to contribute code or ideas to this effort, then I think writing plugins against whatever we come up with/reporting bugs is the next step.=20 However, even using the bug tracker or wiki requires agreement to the contribution agreement there. I suppose I need to turn the question around. How do you feel you can best help? Also, what about the contribution agreement is disagreeable? 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/20070214/19ad4e03/signature.pgp From robla at lindenlab.com Wed Feb 14 14:43:19 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Feb 14 14:43:30 2007 Subject: [sldev] Development philosophy In-Reply-To: <45D38C24.9030705@gmail.com> References: <45D384A6.5050602@lindenlab.com> <45D38C24.9030705@gmail.com> Message-ID: <45D39087.6030509@lindenlab.com> On 2/14/07 2:24 PM, Jason Giglio wrote: > More specifically, can we expect the following: > > 1. Linden Lab sign-offs on major functionality before work begins > 2. Any assurance our code will be merged, ahead of time > > I don't have these expectation, but it seems that some do. Well, those that hold those expectations should defend that expectation. I'm not aware of any open source project that agrees incorporate code from an outside contributor before its written and before that contributor has developed a track record as a trusted contributor. As an example, the plugin architecture is something that is of very high risk to the stability of the codebase if done incorrectly, and is something that people will expect Linden Lab to support years from now. The phrase "the devil is in the details" immediately comes to mind, and specifically, the details are the code itself. So, will Linden Lab agree in advance to incorporate code we haven't reviewed? No. > Specifically can you reply to the following: > > --------------------- > Tim said: > > My hopes are that LL has already signed on to all of this, and we're > > just not getting the full story (suprise), so this will all work out > > --------------------- > > This "development roadmap" that looks like something straight out of a > PMI exam study guide: > > https://wiki.secondlife.com/w/index.php?title=Plugin_architecture_RoadMap&oldid=9910 > > > I edited out "linden sign off" but the rest is almost as bad. This > was the version as it stood before I edited it. > Well, I don't think it's necessary or appropriate to start throwing rocks. The earlier versions was a good early drafts, but I agree that the current version is an improvement. I had meant to get clarification on what was expected by "sign off", per my comments above. 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/20070214/3846475d/signature.pgp From tshephard at gmail.com Wed Feb 14 14:54:16 2007 From: tshephard at gmail.com (Tim Shephard) Date: Wed Feb 14 14:54:21 2007 Subject: [sldev] Development philosophy In-Reply-To: <45D39087.6030509@lindenlab.com> References: <45D384A6.5050602@lindenlab.com> <45D38C24.9030705@gmail.com> <45D39087.6030509@lindenlab.com> Message-ID: <3b19a500702141454r105c1e73nc2352c66ce89b844@mail.gmail.com> Good luck everyone :) Cheers, Tim. On 2/14/07, Rob Lanphier wrote: > On 2/14/07 2:24 PM, Jason Giglio wrote: > > More specifically, can we expect the following: > > > > 1. Linden Lab sign-offs on major functionality before work begins > > 2. Any assurance our code will be merged, ahead of time > > > > I don't have these expectation, but it seems that some do. > Well, those that hold those expectations should defend that > expectation. I'm not aware of any open source project that agrees > incorporate code from an outside contributor before its written and > before that contributor has developed a track record as a trusted > contributor. > > As an example, the plugin architecture is something that is of very high > risk to the stability of the codebase if done incorrectly, and is > something that people will expect Linden Lab to support years from now. > The phrase "the devil is in the details" immediately comes to mind, and > specifically, the details are the code itself. So, will Linden Lab > agree in advance to incorporate code we haven't reviewed? No. > > Specifically can you reply to the following: > > > > --------------------- > > Tim said: > > > My hopes are that LL has already signed on to all of this, and we're > > > just not getting the full story (suprise), so this will all work out > > > > --------------------- > > > > This "development roadmap" that looks like something straight out of a > > PMI exam study guide: > > > > https://wiki.secondlife.com/w/index.php?title=Plugin_architecture_RoadMap&oldid=9910 > > > > > > I edited out "linden sign off" but the rest is almost as bad. This > > was the version as it stood before I edited it. > > > Well, I don't think it's necessary or appropriate to start throwing > rocks. The earlier versions was a good early drafts, but I agree that > the current version is an improvement. I had meant to get clarification > on what was expected by "sign off", per my comments above. > > Rob > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From sldev at bushing.mm.st Wed Feb 14 17:04:03 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Wed Feb 14 17:04:12 2007 Subject: [sldev] Plugin API Architecture for Second Life In-Reply-To: <45D38C6D.8050707@lindenlab.com> References: <3b19a500702121733v5270109du3a54c6eb2fa1499d@mail.gmail.com> <45D1435E.8020206@wsu.edu> <33781800702130145s2c5d1415laac3c0809751c94e@mail.gmail.com> <33781800702130147w63a8bfdfg5b841f4d56622894@mail.gmail.com> <33781800702130149i6b2e218ave05e3fc7aa6db3fb@mail.gmail.com> <45D190CD.2030803@lindenlab.com> <3b19a500702131213h5f511ca4k6bcd72ccfbf47e00@mail.gmail.com> <45D22AC8.80005@gmail.com> <3b19a500702131342s302ece2ft2faf372ac193ef8f@mail.gmail.com> <45D38C6D.8050707@lindenlab.com> Message-ID: <2B310CA5-5D6E-4F77-8993-8C476E64B1C8@bushing.mm.st> On Feb 14, 2007, at 2:25 PM, Rob Lanphier wrote: > On 2/13/07 3:11 PM, Ben Byer wrote: >> @ Linden Lab: >> >> It sounds like splitting chunks of the viewer code into >> dynamically-loaded chunks is a win-win situation: >> >> * Plugins could then link against that code >> * Dynamic chunks could be updated without disturbing the rest of the >> viewer >> * The same mechanisms could be used to create plugins >> * Infrequently-used functions (estate manager, etc?) could defer >> loading until they're actually needed. >> >> Given that I can't sign a code-contribution agreement, how can I help >> with this effort? > > That definitely puts a damper on things in general. If you can't > agree > to contribute code or ideas to this effort, then I think writing > plugins > against whatever we come up with/reporting bugs is the next step.=20 > However, even using the bug tracker or wiki requires agreement to the > contribution agreement there. > > I suppose I need to turn the question around. How do you feel you can > best help? Also, what about the contribution agreement is > disagreeable? I didn't say that I couldn't agree to contribute code or ideas to the effort, or that I wouldn't do so; I said that I can't sign the "Second Life Viewer Contribution Agreement". I work for a fairly large organization doing professional software development, mostly on open-source projects. Contributing to BSD- licensed codebases has historically been acceptable, but anything for which I would have to sign a release would require our Legal department's review of the document, as well as executive approval. Once you've gotten a handful of busy people involved in this decision, it becomes a risk / benefit assessment -- what is the benefit of allowing Ben to hack away on some "game" vs. the potential risk of signing some legal document which could have some unforeseen consequence? Stepping back to the present, "minor" contributions are fine -- small patches, build fixes, bug reports, etc, are fine. (Basically, things that don't rise to the level of being "worth" something, taken individually.) I wouldn't be surprised if you hesitate to take my word on that, but it doesn't bother my conscience. Historically, I've been very involved in the libsecondlife project, and helped start opensecondlife.org. I've written some code for libsecondlife, but if you go looking for it, you won't find it -- it's all been rewritten, which is fine with me. Much of it is like the plugin code I posted on the wiki; slightly crude, slightly hurried, generally intended to show a possible approach rather than be a final solution. Beyond some trivial non-trivial coding, I've done a lot of infrastructure work -- for libsecondlife, I set up the SVN repo and moved it 3 times; I wrote the cron script that used to pull out the message template and keywords file using gdb so that we could keep libsecondlife compatible with the main grid whenever a new version of the viewer was released. (Yes, #libsl, I know it's currently busted. Sorry!) More recently, I helped set up opensecondlife.org; I set up the SVN tree there so that people would have a place to collaborate on code that was not yet mature enough to be submitted back upstream to Linden Lab; I set up git and Mercurial repos in the hopes that people might start using those while we waited for an official LL SVN. I set up OpenGrok to give 3rd-party devs a better way to grep through the massive amount of source. I helped write build scripts to make it more practical to build and rebuild official releases of the SecondLife viewer. We threw the releases and build scripts into SVN to make it easier to collect the pieces together, and started working on a "tinderbox"-like continuous integration solution, to speed up development. Since Mercurial never caught on, I started helping resync our trunk with every new Linden release, but eventually left that thankless, painful task to people more qualified. Apparently everyone thinks that was a waste of time; I'm told FOSSL was started because OpenSL was too hard to build (?) and with the intent to "minimize divergence from the Linden Labs code to ease merging and patching". (Best of luck with that.) Linden Lab seems to see it as at best a waste of effort that could be better spent writing up bugs and patches and wiki entries (*), or at worst some sort of threat-to-fork; really, it was / has been / will be an attempt to fill in the cracks and provide services that aren't practical for Linden to provide to the community. Or maybe I'm just tilting at windmills. Ben (*) I guess I actually can't do any of that. Oops. From david at fries.net Wed Feb 14 20:00:27 2007 From: david at fries.net (David Fries) Date: Wed Feb 14 20:00:49 2007 Subject: [sldev] jinclude.h ? Message-ID: <20070215040027.GE9336@spacedout.fries.net> llimagejpeg.h includes jinclude.h Where does jinclude.h come from? Debian doesn't list the file in their packages, and the source compiles just fine without it. jpeglib.h and jerror are both included in libjpeg62-dev (Version 6b-13) Index: llimage/llimagejpeg.h =================================================================== RCS file: /home/david/SecondLife/cvs_root/linden/indra/llimage/llimagejpeg.h,v retrieving revision 1.1 retrieving revision 1.3 diff -u -r1.1 -r1.3 --- llimage/llimagejpeg.h 1 Feb 2007 03:37:32 -0000 1.1 +++ llimage/llimagejpeg.h 15 Feb 2007 03:50:56 -0000 1.3 @@ -33,7 +33,6 @@ #include "llimage.h" extern "C" { -#include "jpeglib/jinclude.h" #include "jpeglib/jpeglib.h" #include "jpeglib/jerror.h" } -- David Fries http://fries.net/~david/ (PGP encryption key available) From peekay at targetomega.com Wed Feb 14 21:00:11 2007 From: peekay at targetomega.com (Peekay Semyorka) Date: Wed Feb 14 21:00:18 2007 Subject: [sldev] jinclude.h ? In-Reply-To: <20070215040027.GE9336@spacedout.fries.net> References: <20070215040027.GE9336@spacedout.fries.net> Message-ID: <1498.70.49.104.128.1171515611.squirrel@webmail.bluewax.com> jinclude.h is from the IJG libjpeg distribution (www.ijg.org) from which the Debian package was derived from. The file is only needed when compiling the original distribution, and can be safely removed from SL if desired. It defines a few compatibility macros, none of which used by the viewer. -peekay > llimagejpeg.h includes jinclude.h > Where does jinclude.h come from? Debian doesn't list the file in > their packages, and the source compiles just fine without it. From robla at lindenlab.com Thu Feb 15 09:41:03 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Feb 15 09:41:16 2007 Subject: [sldev] Source for First Look 1.13.3.58018 now available Message-ID: <45D49B2F.5060608@lindenlab.com> Hi folks, Source code for the First Look viewer is available here: https://wiki.secondlife.com/wiki/Source_downloads Changes can be found on Steve Linden's blog entry here: http://blog.secondlife.com/2007/02/14/first-look-113358018-now-available-nvidia-crash-fix/ 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/20070215/643143de/signature.pgp From signore at autistiche.org Thu Feb 15 11:42:37 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Thu Feb 15 11:42:44 2007 Subject: [sldev] Patch_xmlrpc-epi Message-ID: <91quOCI5.1171568557.5062230.signore@autistiche.org> Hi all, I'm not skilled with patching. I followed the instructions at https://wiki.secondlife.com/wiki/Patch_xmlrpc-epi the page says "Save this into the file lindenlab/xmlrpc-epi-0.51/remove_iconv.patch" as I added in the page - maybe it's linden/xmlrpc-epi-0.51/remove_iconv.patch ? (not lindenlab) however, I didn't have problem while applying the first two patches - but with the third one, I did - this is the error: can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |diff -ur xmlrpc-epi-0.51-old/Makefile xmlrpc-epi-0.51-new/Makefile |--- xmlrpc-epi-0.51-old/Makefile 2006-04-27 14:55:33.000000000 -0700 |+++ xmlrpc-epi-0.51-new/Makefile 2006-04-27 15:16:19.886773976 -0700 -------------------------- File to patch: any idea? btw, am I right assuming that using the slviewer-linux-libs bundle I cannot use the "BUILD=releasefordownload" scon option? I mean, I need to install the additional dependencies (libboost-dev, libboost-regex-dev, libapr1.0-dev...) in order to do it, right? thanks for the instructions on the Wiki, it's very useful. Signore Iredell From tofu.linden at lindenlab.com Thu Feb 15 12:26:04 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Feb 15 12:25:28 2007 Subject: [sldev] Patch_xmlrpc-epi In-Reply-To: <91quOCI5.1171568557.5062230.signore@autistiche.org> References: <91quOCI5.1171568557.5062230.signore@autistiche.org> Message-ID: <45D4C1DC.8070207@lindenlab.com> signore@autistiche.org wrote: > btw, am I right assuming that using the slviewer-linux-libs bundle > I cannot use the "BUILD=releasefordownload" scon option? I mean, > I need to install the additional dependencies (libboost-dev, > libboost-regex-dev, libapr1.0-dev...) in order to do it, right? That option should be fine with slviewer-linux-libs. By 'should' I mean that it used to work but if it's broken now then I'm interested in more details. :) - Tofu From david at fries.net Thu Feb 15 20:06:06 2007 From: david at fries.net (David Fries) Date: Thu Feb 15 20:06:26 2007 Subject: [sldev] jinclude.h ? In-Reply-To: <1498.70.49.104.128.1171515611.squirrel@webmail.bluewax.com> References: <20070215040027.GE9336@spacedout.fries.net> <1498.70.49.104.128.1171515611.squirrel@webmail.bluewax.com> Message-ID: <20070216040605.GF9336@spacedout.fries.net> Thanks for the response, submitted a patch in VWR-130 'llimagejpeg.h remove jinclude.h' to remove the header reference. On Thu, Feb 15, 2007 at 05:00:11AM -0000, Peekay Semyorka wrote: > jinclude.h is from the IJG libjpeg distribution (www.ijg.org) from which > the Debian package was derived from. > > The file is only needed when compiling the original distribution, and can > be safely removed from SL if desired. It defines a few compatibility > macros, none of which used by the viewer. > > -peekay > > > llimagejpeg.h includes jinclude.h > > Where does jinclude.h come from? Debian doesn't list the file in > > their packages, and the source compiles just fine without it. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- David Fries http://fries.net/~david/ (PGP encryption key available) From seg at haxxed.com Fri Feb 16 01:35:31 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Feb 16 01:39:03 2007 Subject: [sldev] Second Life client packaged for Fedora Message-ID: <1171618531.2953.14.camel@localhost.localdomain> Okay, after much pain, sorrow and apparently duplicated effort[*] I finally managed to get a vaguely usable Second Life package + deps: http://www.haxxed.com/rpms/secondlife/ * spot has some packages too: http://www.auroralinux.org/people/spot/SecondLife/ Don't expect his and mine to be interchangeable just yet. I guess we have some merging to do... -------------- 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/20070216/b0a84d21/attachment.pgp From signore at autistiche.org Fri Feb 16 04:35:27 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Fri Feb 16 04:35:34 2007 Subject: [sldev] Patch_xmlrpc-epi In-Reply-To: <45D4C1DC.8070207@lindenlab.com> Message-ID: In data 15/2/2007, "Tofu Linden" ha scritto: >signore@autistiche.org wrote: >> btw, am I right assuming that using the slviewer-linux-libs bundle >> I cannot use the "BUILD=releasefordownload" scon option? I mean, >> I need to install the additional dependencies (libboost-dev, >> libboost-regex-dev, libapr1.0-dev...) in order to do it, right? > >That option should be fine with slviewer-linux-libs. By 'should' >I mean that it used to work but if it's broken now then I'm >interested in more details. :) When I use that option, then after the building I extract the resulting bz2 archive, directories (example: app_settings) lack lots of files and the client doesn't start. The viewer runs well from inside the tree. Steps I made, and building details, at http://signore.wordpress.com , 1st article. An excerpt of building output follows. bye, signore iredell cp: target `SecondLife_i686_1_13_3_3/app_settings/*? is not a directory [: 91: ==: unexpected operator cp: target `SecondLife_i686_1_13_3_3/character/*? is not a directory [: 91: ==: unexpected operator cp: target `SecondLife_i686_1_13_3_3/fonts/*? is not a directory [: 91: ==: unexpected operator cp: target `SecondLife_i686_1_13_3_3/help/*? is not a directory [: 91: ==: unexpected operator cp: target `SecondLife_i686_1_13_3_3/skins/*? is not a directory [: 91: ==: unexpected operator cp: target `SecondLife_i686_1_13_3_3/res-sdl/*? is not a directory From nanodave at gmail.com Fri Feb 16 09:14:12 2007 From: nanodave at gmail.com (Dave Taylor (nanodave)) Date: Fri Feb 16 09:14:19 2007 Subject: [sldev] Question about customising registration Message-ID: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> Hi Does anyone know if its possible to customise the registration process with the API to provide our own choice of 30 avatar designs? Also, since we are considering the re-use of avatars by people at a series of events is it possible to provide a login process that enables a user to select their name from a predefined list of avatars, whilst keeping the password invisible from them. Many thanks Dave Taylor From nanodave at gmail.com Fri Feb 16 09:15:57 2007 From: nanodave at gmail.com (Dave Taylor (nanodave)) Date: Fri Feb 16 09:16:04 2007 Subject: [sldev] Question about Proxy Servers Message-ID: <5CCCF8D7-EC29-4E03-B989-24EA0DA80F78@gmail.com> Does anyone know how to achieve access to Second Life from a site that insists on all connections to the internet going via a proxy server ? Many thanks Dave Taylor From mindtriggerz at gmail.com Fri Feb 16 09:19:52 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Fri Feb 16 09:19:55 2007 Subject: [sldev] Question about customising registration In-Reply-To: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> Message-ID: I don't think SLDev is for discussing registration API, however I think I'll answer your question. I don't believe that it's possible to pre-specify an avatar that's not in the library, even if regapi did expose this function, as you are guaranteed that your new account has no inventory whatsoever. You could try proxing through a SLProxy application and change the login details before they're sent to the server, but that'd require a second application. On 2/16/07, Dave Taylor (nanodave) wrote: > Hi > > Does anyone know if its possible to customise the registration > process with the API to provide our own choice of 30 avatar designs? > > Also, since we are considering the re-use of avatars by people at a > series of events is it possible to provide a login process that > enables a user to select their name from a predefined list of > avatars, whilst keeping the password invisible from them. > > Many thanks > Dave Taylor > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- --Jesse From james at lindenlab.com Fri Feb 16 09:30:21 2007 From: james at lindenlab.com (James Cook) Date: Fri Feb 16 09:30:28 2007 Subject: [sldev] Question about customising registration In-Reply-To: References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> Message-ID: <45D5EA2D.8080901@lindenlab.com> I wrote the initial-outfit code and as Jesse notes, it only works for outfits that exist in the inventory when you log in. (The code is dirt simple - it just provides a folder name to the client, which tries to find and wear it on login.) Sorry about that, James Jesse Nesbitt wrote: > I don't think SLDev is for discussing registration API, however I > think I'll answer your question. > I don't believe that it's possible to pre-specify an avatar that's not > in the library, even if regapi did expose this function, as you are > guaranteed that your new account has no inventory whatsoever. > You could try proxing through a SLProxy application and change the > login details before they're sent to the server, but that'd require a > second application. > > On 2/16/07, Dave Taylor (nanodave) wrote: >> Hi >> >> Does anyone know if its possible to customise the registration >> process with the API to provide our own choice of 30 avatar designs? >> >> Also, since we are considering the re-use of avatars by people at a >> series of events is it possible to provide a login process that >> enables a user to select their name from a predefined list of >> avatars, whilst keeping the password invisible from them. >> >> Many thanks >> Dave Taylor >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > > From robla at lindenlab.com Fri Feb 16 09:42:35 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Feb 16 09:42:54 2007 Subject: Scope of the list (Re: [sldev] Question about customising registration) In-Reply-To: References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> Message-ID: <45D5ED0B.3010602@lindenlab.com> On 2/16/07 9:19 AM, Jesse Nesbitt wrote: > I don't think SLDev is for discussing registration API, however I > think I'll answer your question. Since there's no other mailing list to discuss registration API (that I'm aware of), this list is fine. This list is generally about software development issues relating to Second Life; The only issues that might relate to software development and Second Life that I think would be more appropriate elsewhere would be LSL scripting questions, which are more appropriate for the secondlifescripters list: https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters If things get too chaotic, we can figure out how to split things off later, but things seem pretty manageable right now. Let me know if the status quo doesn't work for you. 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/20070216/44e3f237/signature.pgp From dimentox at dimentox.com Fri Feb 16 10:37:22 2007 From: dimentox at dimentox.com (Brandon) Date: Fri Feb 16 10:36:31 2007 Subject: [sldev] Question about Proxy Servers In-Reply-To: <5CCCF8D7-EC29-4E03-B989-24EA0DA80F78@gmail.com> References: <5CCCF8D7-EC29-4E03-B989-24EA0DA80F78@gmail.com> Message-ID: <17971.134.163.255.14.1171651042.squirrel@mail.thantosga.com> I am trying to do the same but on linux.. i have tried tsocks i have tried proxychains all use the LD_PRELOAD whch for some reason the binary just wont accept or something ProxyChains-3.1 (http://proxychains.sf.net) bin/do-not-directly-run-secondlife-bin: error while loading shared libraries: libproxychains.so: cannot open shared object file: No such file or directory but i run proxychains mozilla it works fine! its something to do withe the binary i think. i set my ld.so.conf to the lib files dir so i could run the bin directly. it works w/o the proxy but i have to be behind a proxy sigh. > Does anyone know how to achieve access to Second Life from a site > that insists on all connections to the internet going via a proxy > server ? > > Many thanks > Dave Taylor > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From moshe at sapwood.org Fri Feb 16 10:39:47 2007 From: moshe at sapwood.org (moshe@sapwood.org) Date: Fri Feb 16 10:39:48 2007 Subject: [sldev] COM for plugins Message-ID: <34379.64.81.228.9.1171651187.squirrel@webmail.sapwood.org> I'm reading https://wiki.secondlife.com/wiki/Plugin_architecture for the dylib plugin approach. Any feelings on a COM-like interface instead of the function pointer example? This has two advantages: - The SL viewer can provide multiple interface versions - The SL viewer can warn the user if he's using a plugin that will be obsoleted at the next update The first is less scary than it sounds. I'm not proposing something like DirectX with its twelve year legacy interfaces, but rather 2-3 SL viewer revisions, especially when the viewer hits a run of fast updates. A versioned interface is useful when a function has been changed to take different arguments, the flags going into a bitfield change, or an old version of a function had a side-effect a plugin may rely on. It's trivial to write thunking functions that translate calls between the old and new calling convention or emulate old side-effects temporarily. The second can be accomplished by a simple version comparison, based on what the plugin requests and what the viewer supports. To be nice, the viewer could even accept an URL from the plugin as part of the interface request, then send users to a website to check for an updated version of the plugin when the plugin is of a warned or denied version. From mindtriggerz at gmail.com Fri Feb 16 11:57:10 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Fri Feb 16 11:57:13 2007 Subject: Scope of the list (Re: [sldev] Question about customising registration) In-Reply-To: <45D5ED0B.3010602@lindenlab.com> References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> <45D5ED0B.3010602@lindenlab.com> Message-ID: Thanks for the clarification! On 2/16/07, Rob Lanphier wrote: > On 2/16/07 9:19 AM, Jesse Nesbitt wrote: > > I don't think SLDev is for discussing registration API, however I > > think I'll answer your question. > Since there's no other mailing list to discuss registration API (that > I'm aware of), this list is fine. This list is generally about software > development issues relating to Second Life; The only issues that might > relate to software development and Second Life that I think would be > more appropriate elsewhere would be LSL scripting questions, which are > more appropriate for the secondlifescripters list: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters > > If things get too chaotic, we can figure out how to split things off > later, but things seem pretty manageable right now. Let me know if the > status quo doesn't work for you. > > Thanks > Rob > > > > > -- --Jesse From dimentox at dimentox.com Fri Feb 16 12:46:36 2007 From: dimentox at dimentox.com (Brandon) Date: Fri Feb 16 12:45:44 2007 Subject: [sldev] Socksifying linux client via LD_PRELOAD In-Reply-To: References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> <45D5ED0B.3010602@lindenlab.com> Message-ID: <55906.134.163.255.14.1171658796.squirrel@mail.thantosga.com> proxy chains libary works with gaim and netscape.. so its working correctly.. but when i try to preload it with the sl binary it just cant seem to find the lib anyone know whats going on? (btw i installed sl/lib dir to the ldconfig so i could run the binary directly.. it runs and works on its own. ------LOGS------ ldd on the lib # ldd /lib/libproxychains.so.3.0.0 libdl.so.2 => /lib64/libdl.so.2 (0x0000002a9670a000) libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a9680d000) /lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000) # strace -eopen proxychains ./bin/do-not-directly-run-secondlife-bin open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib64/libtermcap.so.2", O_RDONLY) = 3 open("/lib64/libdl.so.2", O_RDONLY) = 3 open("/lib64/tls/libc.so.6", O_RDONLY) = 3 open("/dev/tty", O_RDWR|O_NONBLOCK) = 3 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 open("/etc/mtab", O_RDONLY) = 3 open("/proc/meminfo", O_RDONLY) = 3 open("/bin/proxychains", O_RDONLY) = 3 open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 3 ProxyChains-3.1 (http://proxychains.sf.net) [ Process PID=4878 runs in 32 bit mode. ] ./bin/do-not-directly-run-secondlife-bin: error while loading shared libraries: /lib/libproxychains.so.3.0.0: cannot open shared object file: No such file or director LD_DEBUG=all ------------ proxychains bin/do-not-directly-run-secondlife-bin 29982: 29982: file=libtermcap.so.2; needed by /bin/sh 29982: find library=libtermcap.so.2; searching 29982: search cache=/etc/ld.so.cache 29982: trying file=/lib64/libtermcap.so.2 29982: 29982: file=libtermcap.so.2; generating link map 29982: dynamic: 0x0000002a9578e0e0 base: 0x0000002a9568b000 size: 0x0000000000103450 29982: entry: 0x0000002a9568c380 phdr: 0x0000002a9568b040 phnum: 4 29982: 29982: 29982: file=libdl.so.2; needed by /bin/sh 29982: find library=libdl.so.2; searching 29982: search cache=/etc/ld.so.cache 29982: trying file=/lib64/libdl.so.2 29982: 29982: file=libdl.so.2; generating link map 29982: dynamic: 0x0000002a95891460 base: 0x0000002a9578f000 size: 0x00000000001027a8 29982: entry: 0x0000002a95790df0 phdr: 0x0000002a9578f040 phnum: 8 29982: 29982: 29982: file=libc.so.6; needed by /bin/sh 29982: find library=libc.so.6; searching 29982: search cache=/etc/ld.so.cache 29982: trying file=/lib64/tls/libc.so.6 29982: 29982: file=libc.so.6; generating link map 29982: dynamic: 0x0000002a95ad25b0 base: 0x0000002a95893000 size: 0x0000000000243f68 29982: entry: 0x0000002a958b0240 phdr: 0x0000002a95893040 phnum: 9 29982: 29982: checking for version `GLIBC_2.2.5' in file /lib64/libdl.so.2 required by file /bin/sh 29982: checking for version `GLIBC_2.3' in file /lib64/tls/libc.so.6 required by file /bin/sh 29982: checking for version `GLIBC_2.2.5' in file /lib64/tls/libc.so.6 required by file /bin/sh 29982: checking for version `GLIBC_2.2.5' in file /lib64/tls/libc.so.6 required by file /lib64/libtermcap.so.2 29982: checking for version `GLIBC_PRIVATE' in file /lib64/ld-linux-x86-64.so.2 required by file /lib64/libdl.so.2 29982: checking for version `GLIBC_2.3' in file /lib64/tls/libc.so.6 required by file /lib64/libdl.so.2 29982: checking for version `GLIBC_PRIVATE' in file /lib64/tls/libc.so.6 required by file /lib64/libdl.so.2 29982: checking for version `GLIBC_2.2.5' in file /lib64/tls/libc.so.6 required by file /lib64/libdl.so.2 29982: checking for version `GLIBC_2.3' in file /lib64/ld-linux-x86-64.so.2 required by file /lib64/tls/libc.so.6 29982: checking for version `GLIBC_2.2.5' in file /lib64/ld-linux-x86-64.so.2 required by file /lib64/tls/libc.so.6 29982: checking for version `GLIBC_PRIVATE' in file /lib64/ld-linux-x86-64.so.2 required by file /lib64/tls/libc.so.6 29982: 29982: relocation processing: /lib64/tls/libc.so.6 (lazy) 29982: symbol=_IO_file_close; lookup in file=/bin/sh 29982: symbol=_IO_file_close; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_IO_file_close; lookup in file=/lib64/libdl.so.2 29982: symbol=_IO_file_close; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_IO_file_close' [GLIBC_2.2.5] 29982: symbol=_IO_2_1_stdin_; lookup in file=/bin/sh 29982: symbol=_IO_2_1_stdin_; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_IO_2_1_stdin_; lookup in file=/lib64/libdl.so.2 29982: symbol=_IO_2_1_stdin_; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_IO_2_1_stdin_' [GLIBC_2.2.5] 29982: symbol=_IO_2_1_stdout_; lookup in file=/bin/sh 29982: symbol=_IO_2_1_stdout_; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_IO_2_1_stdout_; lookup in file=/lib64/libdl.so.2 29982: symbol=_IO_2_1_stdout_; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_IO_2_1_stdout_' [GLIBC_2.2.5] 29982: symbol=_IO_2_1_stderr_; lookup in file=/bin/sh 29982: symbol=_IO_2_1_stderr_; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_IO_2_1_stderr_; lookup in file=/lib64/libdl.so.2 29982: symbol=_IO_2_1_stderr_; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_IO_2_1_stderr_' [GLIBC_2.2.5] 29982: symbol=_res; lookup in file=/bin/sh 29982: symbol=_res; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_res; lookup in file=/lib64/libdl.so.2 29982: symbol=_res; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_res' [GLIBC_2.2.5] 29982: symbol=__morecore; lookup in file=/bin/sh 29982: symbol=__morecore; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__morecore; lookup in file=/lib64/libdl.so.2 29982: symbol=__morecore; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__morecore' [GLIBC_2.2.5] 29982: symbol=__daylight; lookup in file=/bin/sh 29982: symbol=__daylight; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__daylight; lookup in file=/lib64/libdl.so.2 29982: symbol=__daylight; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__daylight' [GLIBC_2.2.5] 29982: symbol=__malloc_hook; lookup in file=/bin/sh 29982: symbol=__malloc_hook; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__malloc_hook; lookup in file=/lib64/libdl.so.2 29982: symbol=__malloc_hook; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__malloc_hook' [GLIBC_2.2.5] 29982: symbol=h_nerr; lookup in file=/bin/sh 29982: symbol=h_nerr; lookup in file=/lib64/libtermcap.so.2 29982: symbol=h_nerr; lookup in file=/lib64/libdl.so.2 29982: symbol=h_nerr; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `h_nerr' [GLIBC_2.2.5] 29982: symbol=__malloc_initialize_hook; lookup in file=/bin/sh 29982: symbol=__malloc_initialize_hook; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__malloc_initialize_hook; lookup in file=/lib64/libdl.so.2 29982: symbol=__malloc_initialize_hook; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__malloc_initialize_hook' [GLIBC_2.2.5] 29982: symbol=_dl_starting_up; lookup in file=/bin/sh 29982: symbol=_dl_starting_up; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_dl_starting_up; lookup in file=/lib64/libdl.so.2 29982: symbol=_dl_starting_up; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_dl_starting_up; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/tls/libc.so.6 to /lib64/ld-linux-x86-64.so.2: normal symbol `_dl_starting_up' [GLIBC_PRIVATE] 29982: symbol=__ctype32_toupper; lookup in file=/bin/sh 29982: symbol=__ctype32_toupper; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__ctype32_toupper; lookup in file=/lib64/libdl.so.2 29982: symbol=__ctype32_toupper; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__ctype32_toupper' [GLIBC_2.2.5] 29982: symbol=stdout; lookup in file=/bin/sh 29982: binding file /lib64/tls/libc.so.6 to /bin/sh: normal symbol `stdout' [GLIBC_2.2.5] 29982: symbol=__rcmd_errstr; lookup in file=/bin/sh 29982: symbol=__rcmd_errstr; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__rcmd_errstr; lookup in file=/lib64/libdl.so.2 29982: symbol=__rcmd_errstr; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__rcmd_errstr' [GLIBC_2.2.5] 29982: symbol=_nl_domain_bindings; lookup in file=/bin/sh 29982: symbol=_nl_domain_bindings; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_nl_domain_bindings; lookup in file=/lib64/libdl.so.2 29982: symbol=_nl_domain_bindings; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_nl_domain_bindings' [GLIBC_2.2.5] 29982: symbol=re_syntax_options; lookup in file=/bin/sh 29982: symbol=re_syntax_options; lookup in file=/lib64/libtermcap.so.2 29982: symbol=re_syntax_options; lookup in file=/lib64/libdl.so.2 29982: symbol=re_syntax_options; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `re_syntax_options' [GLIBC_2.2.5] 29982: symbol=argp_program_bug_address; lookup in file=/bin/sh 29982: symbol=argp_program_bug_address; lookup in file=/lib64/libtermcap.so.2 29982: symbol=argp_program_bug_address; lookup in file=/lib64/libdl.so.2 29982: symbol=argp_program_bug_address; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `argp_program_bug_address' [GLIBC_2.2.5] 29982: symbol=__tzname; lookup in file=/bin/sh 29982: symbol=__tzname; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__tzname; lookup in file=/lib64/libdl.so.2 29982: symbol=__tzname; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__tzname' [GLIBC_2.2.5] 29982: symbol=_IO_funlockfile; lookup in file=/bin/sh 29982: symbol=_IO_funlockfile; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_IO_funlockfile; lookup in file=/lib64/libdl.so.2 29982: symbol=_IO_funlockfile; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_IO_funlockfile' [GLIBC_2.2.5] 29982: symbol=__realloc_hook; lookup in file=/bin/sh 29982: symbol=__realloc_hook; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__realloc_hook; lookup in file=/lib64/libdl.so.2 29982: symbol=__realloc_hook; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__realloc_hook' [GLIBC_2.2.5] 29982: symbol=malloc; lookup in file=/bin/sh 29982: binding file /lib64/tls/libc.so.6 to /bin/sh: normal symbol `malloc' [GLIBC_2.2.5] 29982: symbol=_nl_msg_cat_cntr; lookup in file=/bin/sh 29982: symbol=_nl_msg_cat_cntr; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_nl_msg_cat_cntr; lookup in file=/lib64/libdl.so.2 29982: symbol=_nl_msg_cat_cntr; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_nl_msg_cat_cntr' [GLIBC_2.2.5] 29982: symbol=optarg; lookup in file=/bin/sh 29982: symbol=optarg; lookup in file=/lib64/libtermcap.so.2 29982: symbol=optarg; lookup in file=/lib64/libdl.so.2 29982: symbol=optarg; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `optarg' [GLIBC_2.2.5] 29982: symbol=loc2; lookup in file=/bin/sh 29982: symbol=loc2; lookup in file=/lib64/libtermcap.so.2 29982: symbol=loc2; lookup in file=/lib64/libdl.so.2 29982: symbol=loc2; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `loc2' [GLIBC_2.2.5] 29982: symbol=h_errlist; lookup in file=/bin/sh 29982: symbol=h_errlist; lookup in file=/lib64/libtermcap.so.2 29982: symbol=h_errlist; lookup in file=/lib64/libdl.so.2 29982: symbol=h_errlist; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `h_errlist' [GLIBC_2.2.5] 29982: symbol=opterr; lookup in file=/bin/sh 29982: symbol=opterr; lookup in file=/lib64/libtermcap.so.2 29982: symbol=opterr; lookup in file=/lib64/libdl.so.2 29982: symbol=opterr; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `opterr' [GLIBC_2.2.5] 29982: symbol=error_message_count; lookup in file=/bin/sh 29982: symbol=error_message_count; lookup in file=/lib64/libtermcap.so.2 29982: symbol=error_message_count; lookup in file=/lib64/libdl.so.2 29982: symbol=error_message_count; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `error_message_count' [GLIBC_2.2.5] 29982: symbol=_environ; lookup in file=/bin/sh 29982: binding file /lib64/tls/libc.so.6 to /bin/sh: normal symbol `_environ' [GLIBC_2.2.5] 29982: symbol=getdate_err; lookup in file=/bin/sh 29982: symbol=getdate_err; lookup in file=/lib64/libtermcap.so.2 29982: symbol=getdate_err; lookup in file=/lib64/libdl.so.2 29982: symbol=getdate_err; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `getdate_err' [GLIBC_2.2.5] 29982: symbol=__environ; lookup in file=/bin/sh 29982: binding file /lib64/tls/libc.so.6 to /bin/sh: normal symbol `__environ' [GLIBC_2.2.5] 29982: symbol=obstack_exit_failure; lookup in file=/bin/sh 29982: symbol=obstack_exit_failure; lookup in file=/lib64/libtermcap.so.2 29982: symbol=obstack_exit_failure; lookup in file=/lib64/libdl.so.2 29982: symbol=obstack_exit_failure; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `obstack_exit_failure' [GLIBC_2.2.5] 29982: symbol=_rtld_global; lookup in file=/bin/sh 29982: symbol=_rtld_global; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_rtld_global; lookup in file=/lib64/libdl.so.2 29982: symbol=_rtld_global; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_rtld_global; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/tls/libc.so.6 to /lib64/ld-linux-x86-64.so.2: normal symbol `_rtld_global' [GLIBC_PRIVATE] 29982: symbol=error_print_progname; lookup in file=/bin/sh 29982: symbol=error_print_progname; lookup in file=/lib64/libtermcap.so.2 29982: symbol=error_print_progname; lookup in file=/lib64/libdl.so.2 29982: symbol=error_print_progname; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `error_print_progname' [GLIBC_2.2.5] 29982: symbol=__after_morecore_hook; lookup in file=/bin/sh 29982: symbol=__after_morecore_hook; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__after_morecore_hook; lookup in file=/lib64/libdl.so.2 29982: symbol=__after_morecore_hook; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__after_morecore_hook' [GLIBC_2.2.5] 29982: symbol=__ctype32_b; lookup in file=/bin/sh 29982: symbol=__ctype32_b; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__ctype32_b; lookup in file=/lib64/libdl.so.2 29982: symbol=__ctype32_b; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__ctype32_b' [GLIBC_2.2.5] 29982: symbol=__key_encryptsession_pk_LOCAL; lookup in file=/bin/sh 29982: symbol=__key_encryptsession_pk_LOCAL; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__key_encryptsession_pk_LOCAL; lookup in file=/lib64/libdl.so.2 29982: symbol=__key_encryptsession_pk_LOCAL; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__key_encryptsession_pk_LOCAL' [GLIBC_2.2.5] 29982: symbol=argp_program_version; lookup in file=/bin/sh 29982: symbol=argp_program_version; lookup in file=/lib64/libtermcap.so.2 29982: symbol=argp_program_version; lookup in file=/lib64/libdl.so.2 29982: symbol=argp_program_version; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `argp_program_version' [GLIBC_2.2.5] 29982: symbol=__fpu_control; lookup in file=/bin/sh 29982: symbol=__fpu_control; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__fpu_control; lookup in file=/lib64/libdl.so.2 29982: symbol=__fpu_control; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__fpu_control' [GLIBC_2.2.5] 29982: symbol=optind; lookup in file=/bin/sh 29982: symbol=optind; lookup in file=/lib64/libtermcap.so.2 29982: symbol=optind; lookup in file=/lib64/libdl.so.2 29982: symbol=optind; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `optind' [GLIBC_2.2.5] 29982: symbol=_res_hconf; lookup in file=/bin/sh 29982: symbol=_res_hconf; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_res_hconf; lookup in file=/lib64/libdl.so.2 29982: symbol=_res_hconf; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_res_hconf' [GLIBC_2.2.5] 29982: symbol=stdin; lookup in file=/bin/sh 29982: binding file /lib64/tls/libc.so.6 to /bin/sh: normal symbol `stdin' [GLIBC_2.2.5] 29982: symbol=__progname; lookup in file=/bin/sh 29982: symbol=__progname; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__progname; lookup in file=/lib64/libdl.so.2 29982: symbol=__progname; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__progname' [GLIBC_2.2.5] 29982: symbol=loc1; lookup in file=/bin/sh 29982: symbol=loc1; lookup in file=/lib64/libtermcap.so.2 29982: symbol=loc1; lookup in file=/lib64/libdl.so.2 29982: symbol=loc1; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `loc1' [GLIBC_2.2.5] 29982: symbol=program_invocation_short_name; lookup in file=/bin/sh 29982: symbol=program_invocation_short_name; lookup in file=/lib64/libtermcap.so.2 29982: symbol=program_invocation_short_name; lookup in file=/lib64/libdl.so.2 29982: symbol=program_invocation_short_name; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `program_invocation_short_name' [GLIBC_2.2.5] 29982: symbol=argp_err_exit_status; lookup in file=/bin/sh 29982: symbol=argp_err_exit_status; lookup in file=/lib64/libtermcap.so.2 29982: symbol=argp_err_exit_status; lookup in file=/lib64/libdl.so.2 29982: symbol=argp_err_exit_status; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `argp_err_exit_status' [GLIBC_2.2.5] 29982: symbol=__ctype_b; lookup in file=/bin/sh 29982: symbol=__ctype_b; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__ctype_b; lookup in file=/lib64/libdl.so.2 29982: symbol=__ctype_b; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__ctype_b' [GLIBC_2.2.5] 29982: symbol=__check_rhosts_file; lookup in file=/bin/sh 29982: symbol=__check_rhosts_file; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__check_rhosts_file; lookup in file=/lib64/libdl.so.2 29982: symbol=__check_rhosts_file; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__check_rhosts_file' [GLIBC_2.2.5] 29982: symbol=obstack_alloc_failed_handler; lookup in file=/bin/sh 29982: symbol=obstack_alloc_failed_handler; lookup in file=/lib64/libtermcap.so.2 29982: symbol=obstack_alloc_failed_handler; lookup in file=/lib64/libdl.so.2 29982: symbol=obstack_alloc_failed_handler; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `obstack_alloc_failed_handler' [GLIBC_2.2.5] 29982: symbol=stderr; lookup in file=/bin/sh 29982: binding file /lib64/tls/libc.so.6 to /bin/sh: normal symbol `stderr' [GLIBC_2.2.5] 29982: symbol=__key_gendes_LOCAL; lookup in file=/bin/sh 29982: symbol=__key_gendes_LOCAL; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__key_gendes_LOCAL; lookup in file=/lib64/libdl.so.2 29982: symbol=__key_gendes_LOCAL; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__key_gendes_LOCAL' [GLIBC_2.2.5] 29982: symbol=optopt; lookup in file=/bin/sh 29982: symbol=optopt; lookup in file=/lib64/libtermcap.so.2 29982: symbol=optopt; lookup in file=/lib64/libdl.so.2 29982: symbol=optopt; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `optopt' [GLIBC_2.2.5] 29982: symbol=__timezone; lookup in file=/bin/sh 29982: symbol=__timezone; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__timezone; lookup in file=/lib64/libdl.so.2 29982: symbol=__timezone; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__timezone' [GLIBC_2.2.5] 29982: symbol=svcauthdes_stats; lookup in file=/bin/sh 29982: symbol=svcauthdes_stats; lookup in file=/lib64/libtermcap.so.2 29982: symbol=svcauthdes_stats; lookup in file=/lib64/libdl.so.2 29982: symbol=svcauthdes_stats; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `svcauthdes_stats' [GLIBC_2.2.5] 29982: symbol=mallwatch; lookup in file=/bin/sh 29982: symbol=mallwatch; lookup in file=/lib64/libtermcap.so.2 29982: symbol=mallwatch; lookup in file=/lib64/libdl.so.2 29982: symbol=mallwatch; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `mallwatch' [GLIBC_2.2.5] 29982: symbol=_r_debug; lookup in file=/bin/sh 29982: symbol=_r_debug; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_r_debug; lookup in file=/lib64/libdl.so.2 29982: symbol=_r_debug; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_r_debug; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/tls/libc.so.6 to /lib64/ld-linux-x86-64.so.2: normal symbol `_r_debug' [GLIBC_2.2.5] 29982: symbol=svc_fdset; lookup in file=/bin/sh 29982: symbol=svc_fdset; lookup in file=/lib64/libtermcap.so.2 29982: symbol=svc_fdset; lookup in file=/lib64/libdl.so.2 29982: symbol=svc_fdset; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `svc_fdset' [GLIBC_2.2.5] 29982: symbol=__curbrk; lookup in file=/bin/sh 29982: symbol=__curbrk; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__curbrk; lookup in file=/lib64/libdl.so.2 29982: symbol=__curbrk; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__curbrk' [GLIBC_2.2.5] 29982: symbol=__libc_enable_secure; lookup in file=/bin/sh 29982: symbol=__libc_enable_secure; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__libc_enable_secure; lookup in file=/lib64/libdl.so.2 29982: symbol=__libc_enable_secure; lookup in file=/lib64/tls/libc.so.6 29982: symbol=__libc_enable_secure; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/tls/libc.so.6 to /lib64/ld-linux-x86-64.so.2: normal symbol `__libc_enable_secure' [GLIBC_PRIVATE] 29982: symbol=__free_hook; lookup in file=/bin/sh 29982: symbol=__free_hook; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__free_hook; lookup in file=/lib64/libdl.so.2 29982: symbol=__free_hook; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__free_hook' [GLIBC_2.2.5] 29982: symbol=_null_auth; lookup in file=/bin/sh 29982: symbol=_null_auth; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_null_auth; lookup in file=/lib64/libdl.so.2 29982: symbol=_null_auth; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `_null_auth' [GLIBC_2.2.5] 29982: symbol=error_one_per_line; lookup in file=/bin/sh 29982: symbol=error_one_per_line; lookup in file=/lib64/libtermcap.so.2 29982: symbol=error_one_per_line; lookup in file=/lib64/libdl.so.2 29982: symbol=error_one_per_line; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `error_one_per_line' [GLIBC_2.2.5] 29982: symbol=_dl_argv; lookup in file=/bin/sh 29982: symbol=_dl_argv; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_dl_argv; lookup in file=/lib64/libdl.so.2 29982: symbol=_dl_argv; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_dl_argv; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/tls/libc.so.6 to /lib64/ld-linux-x86-64.so.2: normal symbol `_dl_argv' [GLIBC_PRIVATE] 29982: symbol=__ctype32_tolower; lookup in file=/bin/sh 29982: symbol=__ctype32_tolower; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__ctype32_tolower; lookup in file=/lib64/libdl.so.2 29982: symbol=__ctype32_tolower; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__ctype32_tolower' [GLIBC_2.2.5] 29982: symbol=program_invocation_name; lookup in file=/bin/sh 29982: symbol=program_invocation_name; lookup in file=/lib64/libtermcap.so.2 29982: symbol=program_invocation_name; lookup in file=/lib64/libdl.so.2 29982: symbol=program_invocation_name; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `program_invocation_name' [GLIBC_2.2.5] 29982: symbol=svc_max_pollfd; lookup in file=/bin/sh 29982: symbol=svc_max_pollfd; lookup in file=/lib64/libtermcap.so.2 29982: symbol=svc_max_pollfd; lookup in file=/lib64/libdl.so.2 29982: symbol=svc_max_pollfd; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `svc_max_pollfd' [GLIBC_2.2.5] 29982: symbol=rpc_createerr; lookup in file=/bin/sh 29982: symbol=rpc_createerr; lookup in file=/lib64/libtermcap.so.2 29982: symbol=rpc_createerr; lookup in file=/lib64/libdl.so.2 29982: symbol=rpc_createerr; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `rpc_createerr' [GLIBC_2.2.5] 29982: symbol=argp_program_version_hook; lookup in file=/bin/sh 29982: symbol=argp_program_version_hook; lookup in file=/lib64/libtermcap.so.2 29982: symbol=argp_program_version_hook; lookup in file=/lib64/libdl.so.2 29982: symbol=argp_program_version_hook; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `argp_program_version_hook' [GLIBC_2.2.5] 29982: symbol=svc_pollfd; lookup in file=/bin/sh 29982: symbol=svc_pollfd; lookup in file=/lib64/libtermcap.so.2 29982: symbol=svc_pollfd; lookup in file=/lib64/libdl.so.2 29982: symbol=svc_pollfd; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `svc_pollfd' [GLIBC_2.2.5] 29982: symbol=_dl_out_of_memory; lookup in file=/bin/sh 29982: symbol=_dl_out_of_memory; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_dl_out_of_memory; lookup in file=/lib64/libdl.so.2 29982: symbol=_dl_out_of_memory; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_dl_out_of_memory; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/tls/libc.so.6 to /lib64/ld-linux-x86-64.so.2: normal symbol `_dl_out_of_memory' [GLIBC_PRIVATE] 29982: symbol=__ctype_toupper; lookup in file=/bin/sh 29982: symbol=__ctype_toupper; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__ctype_toupper; lookup in file=/lib64/libdl.so.2 29982: symbol=__ctype_toupper; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__ctype_toupper' [GLIBC_2.2.5] 29982: symbol=__key_decryptsession_pk_LOCAL; lookup in file=/bin/sh 29982: symbol=__key_decryptsession_pk_LOCAL; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__key_decryptsession_pk_LOCAL; lookup in file=/lib64/libdl.so.2 29982: symbol=__key_decryptsession_pk_LOCAL; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__key_decryptsession_pk_LOCAL' [GLIBC_2.2.5] 29982: symbol=__ctype_tolower; lookup in file=/bin/sh 29982: symbol=__ctype_tolower; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__ctype_tolower; lookup in file=/lib64/libdl.so.2 29982: symbol=__ctype_tolower; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__ctype_tolower' [GLIBC_2.2.5] 29982: symbol=__memalign_hook; lookup in file=/bin/sh 29982: symbol=__memalign_hook; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__memalign_hook; lookup in file=/lib64/libdl.so.2 29982: symbol=__memalign_hook; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__memalign_hook' [GLIBC_2.2.5] 29982: symbol=__progname_full; lookup in file=/bin/sh 29982: symbol=__progname_full; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__progname_full; lookup in file=/lib64/libdl.so.2 29982: symbol=__progname_full; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__progname_full' [GLIBC_2.2.5] 29982: symbol=free; lookup in file=/bin/sh 29982: binding file /lib64/tls/libc.so.6 to /bin/sh: normal symbol `free' [GLIBC_2.2.5] 29982: 29982: relocation processing: /lib64/libdl.so.2 (lazy) 29982: symbol=__pthread_once; lookup in file=/bin/sh 29982: symbol=__pthread_once; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__pthread_once; lookup in file=/lib64/libdl.so.2 29982: symbol=__pthread_once; lookup in file=/lib64/tls/libc.so.6 29982: symbol=__pthread_once; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: symbol=__pthread_key_create; lookup in file=/bin/sh 29982: symbol=__pthread_key_create; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__pthread_key_create; lookup in file=/lib64/libdl.so.2 29982: symbol=__pthread_key_create; lookup in file=/lib64/tls/libc.so.6 29982: symbol=__pthread_key_create; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: symbol=_rtld_global; lookup in file=/bin/sh 29982: symbol=_rtld_global; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_rtld_global; lookup in file=/lib64/libdl.so.2 29982: symbol=_rtld_global; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_rtld_global; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/libdl.so.2 to /lib64/ld-linux-x86-64.so.2: normal symbol `_rtld_global' [GLIBC_PRIVATE] 29982: symbol=stdin; lookup in file=/bin/sh 29982: binding file /lib64/libdl.so.2 to /bin/sh: normal symbol `stdin' [GLIBC_2.2.5] 29982: symbol=_libc_intl_domainname; lookup in file=/bin/sh 29982: symbol=_libc_intl_domainname; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_libc_intl_domainname; lookup in file=/lib64/libdl.so.2 29982: symbol=_libc_intl_domainname; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/libdl.so.2 to /lib64/tls/libc.so.6: normal symbol `_libc_intl_domainname' [GLIBC_2.2.5] 29982: symbol=__pthread_getspecific; lookup in file=/bin/sh 29982: symbol=__pthread_getspecific; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__pthread_getspecific; lookup in file=/lib64/libdl.so.2 29982: symbol=__pthread_getspecific; lookup in file=/lib64/tls/libc.so.6 29982: symbol=__pthread_getspecific; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: symbol=__cxa_finalize; lookup in file=/bin/sh 29982: symbol=__cxa_finalize; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__cxa_finalize; lookup in file=/lib64/libdl.so.2 29982: symbol=__cxa_finalize; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/libdl.so.2 to /lib64/tls/libc.so.6: normal symbol `__cxa_finalize' [GLIBC_2.2.5] 29982: symbol=__pthread_setspecific; lookup in file=/bin/sh 29982: symbol=__pthread_setspecific; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__pthread_setspecific; lookup in file=/lib64/libdl.so.2 29982: symbol=__pthread_setspecific; lookup in file=/lib64/tls/libc.so.6 29982: symbol=__pthread_setspecific; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: symbol=_Jv_RegisterClasses; lookup in file=/bin/sh 29982: symbol=_Jv_RegisterClasses; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_Jv_RegisterClasses; lookup in file=/lib64/libdl.so.2 29982: symbol=_Jv_RegisterClasses; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_Jv_RegisterClasses; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: symbol=__gmon_start__; lookup in file=/bin/sh 29982: symbol=__gmon_start__; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__gmon_start__; lookup in file=/lib64/libdl.so.2 29982: symbol=__gmon_start__; lookup in file=/lib64/tls/libc.so.6 29982: symbol=__gmon_start__; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: 29982: relocation processing: /lib64/libtermcap.so.2 (lazy) 29982: symbol=ospeed; lookup in file=/bin/sh 29982: symbol=ospeed; lookup in file=/lib64/libtermcap.so.2 29982: binding file /lib64/libtermcap.so.2 to /lib64/libtermcap.so.2: normal symbol `ospeed' 29982: symbol=BC; lookup in file=/bin/sh 29982: binding file /lib64/libtermcap.so.2 to /bin/sh: normal symbol `BC' 29982: symbol=PC; lookup in file=/bin/sh 29982: binding file /lib64/libtermcap.so.2 to /bin/sh: normal symbol `PC' 29982: symbol=__cxa_finalize; lookup in file=/bin/sh 29982: symbol=__cxa_finalize; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__cxa_finalize; lookup in file=/lib64/libdl.so.2 29982: symbol=__cxa_finalize; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/libtermcap.so.2 to /lib64/tls/libc.so.6: normal symbol `__cxa_finalize' [GLIBC_2.2.5] 29982: symbol=UP; lookup in file=/bin/sh 29982: binding file /lib64/libtermcap.so.2 to /bin/sh: normal symbol `UP' 29982: symbol=_Jv_RegisterClasses; lookup in file=/bin/sh 29982: symbol=_Jv_RegisterClasses; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_Jv_RegisterClasses; lookup in file=/lib64/libdl.so.2 29982: symbol=_Jv_RegisterClasses; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_Jv_RegisterClasses; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: symbol=__gmon_start__; lookup in file=/bin/sh 29982: symbol=__gmon_start__; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__gmon_start__; lookup in file=/lib64/libdl.so.2 29982: symbol=__gmon_start__; lookup in file=/lib64/tls/libc.so.6 29982: symbol=__gmon_start__; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: 29982: relocation processing: /bin/sh (lazy) 29982: symbol=__gmon_start__; lookup in file=/bin/sh 29982: symbol=__gmon_start__; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__gmon_start__; lookup in file=/lib64/libdl.so.2 29982: symbol=__gmon_start__; lookup in file=/lib64/tls/libc.so.6 29982: symbol=__gmon_start__; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: symbol=stderr; lookup in file=/lib64/libtermcap.so.2 29982: symbol=stderr; lookup in file=/lib64/libdl.so.2 29982: symbol=stderr; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `stderr' [GLIBC_2.2.5] 29982: symbol=BC; lookup in file=/lib64/libtermcap.so.2 29982: binding file /bin/sh to /lib64/libtermcap.so.2: normal symbol `BC' 29982: symbol=__environ; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__environ; lookup in file=/lib64/libdl.so.2 29982: symbol=__environ; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `__environ' [GLIBC_2.2.5] 29982: symbol=stdin; lookup in file=/lib64/libtermcap.so.2 29982: symbol=stdin; lookup in file=/lib64/libdl.so.2 29982: symbol=stdin; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `stdin' [GLIBC_2.2.5] 29982: symbol=PC; lookup in file=/lib64/libtermcap.so.2 29982: binding file /bin/sh to /lib64/libtermcap.so.2: normal symbol `PC' 29982: symbol=UP; lookup in file=/lib64/libtermcap.so.2 29982: binding file /bin/sh to /lib64/libtermcap.so.2: normal symbol `UP' 29982: symbol=stdout; lookup in file=/lib64/libtermcap.so.2 29982: symbol=stdout; lookup in file=/lib64/libdl.so.2 29982: symbol=stdout; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `stdout' [GLIBC_2.2.5] 29982: 29982: relocation processing: /lib64/ld-linux-x86-64.so.2 29982: symbol=_r_debug; lookup in file=/bin/sh 29982: symbol=_r_debug; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_r_debug; lookup in file=/lib64/libdl.so.2 29982: symbol=_r_debug; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_r_debug; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/ld-linux-x86-64.so.2 to /lib64/ld-linux-x86-64.so.2: normal symbol `_r_debug' [GLIBC_2.2.5] 29982: symbol=__libc_memalign; lookup in file=/bin/sh 29982: symbol=__libc_memalign; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__libc_memalign; lookup in file=/lib64/libdl.so.2 29982: symbol=__libc_memalign; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/ld-linux-x86-64.so.2 to /lib64/tls/libc.so.6: normal symbol `__libc_memalign' [GLIBC_2.2.5] 29982: symbol=malloc; lookup in file=/bin/sh 29982: symbol=malloc; lookup in file=/lib64/libtermcap.so.2 29982: symbol=malloc; lookup in file=/lib64/libdl.so.2 29982: symbol=malloc; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/ld-linux-x86-64.so.2 to /lib64/tls/libc.so.6: normal symbol `malloc' [GLIBC_2.2.5] 29982: symbol=__tls_get_addr; lookup in file=/bin/sh 29982: symbol=__tls_get_addr; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__tls_get_addr; lookup in file=/lib64/libdl.so.2 29982: symbol=__tls_get_addr; lookup in file=/lib64/tls/libc.so.6 29982: symbol=__tls_get_addr; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/ld-linux-x86-64.so.2 to /lib64/ld-linux-x86-64.so.2: normal symbol `__tls_get_addr' [GLIBC_2.3] 29982: symbol=calloc; lookup in file=/bin/sh 29982: symbol=calloc; lookup in file=/lib64/libtermcap.so.2 29982: symbol=calloc; lookup in file=/lib64/libdl.so.2 29982: symbol=calloc; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/ld-linux-x86-64.so.2 to /lib64/tls/libc.so.6: normal symbol `calloc' [GLIBC_2.2.5] 29982: symbol=realloc; lookup in file=/bin/sh 29982: symbol=realloc; lookup in file=/lib64/libtermcap.so.2 29982: symbol=realloc; lookup in file=/lib64/libdl.so.2 29982: symbol=realloc; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/ld-linux-x86-64.so.2 to /lib64/tls/libc.so.6: normal symbol `realloc' [GLIBC_2.2.5] 29982: symbol=free; lookup in file=/bin/sh 29982: symbol=free; lookup in file=/lib64/libtermcap.so.2 29982: symbol=free; lookup in file=/lib64/libdl.so.2 29982: symbol=free; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/ld-linux-x86-64.so.2 to /lib64/tls/libc.so.6: normal symbol `free' [GLIBC_2.2.5] 29982: 29982: calling init: /lib64/tls/libc.so.6 29982: 29982: 29982: calling init: /lib64/libdl.so.2 29982: 29982: 29982: calling init: /lib64/libtermcap.so.2 29982: 29982: symbol=__libc_start_main; lookup in file=/bin/sh 29982: symbol=__libc_start_main; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__libc_start_main; lookup in file=/lib64/libdl.so.2 29982: symbol=__libc_start_main; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `__libc_start_main' [GLIBC_2.2.5] 29982: symbol=_dl_debug_printf; lookup in file=/bin/sh 29982: symbol=_dl_debug_printf; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_dl_debug_printf; lookup in file=/lib64/libdl.so.2 29982: symbol=_dl_debug_printf; lookup in file=/lib64/tls/libc.so.6 29982: symbol=_dl_debug_printf; lookup in file=/lib64/ld-linux-x86-64.so.2 29982: binding file /lib64/tls/libc.so.6 to /lib64/ld-linux-x86-64.so.2: normal symbol `_dl_debug_printf' [GLIBC_PRIVATE] 29982: 29982: initialize program: /bin/sh 29982: 29982: symbol=_init; lookup in file=/bin/sh 29982: binding file /bin/sh to /bin/sh: normal symbol `_init' 29982: 29982: transferring control: /bin/sh 29982: 29982: symbol=__sigsetjmp; lookup in file=/bin/sh 29982: symbol=__sigsetjmp; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__sigsetjmp; lookup in file=/lib64/libdl.so.2 29982: symbol=__sigsetjmp; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `__sigsetjmp' [GLIBC_2.2.5] 29982: symbol=open; lookup in file=/bin/sh 29982: symbol=open; lookup in file=/lib64/libtermcap.so.2 29982: symbol=open; lookup in file=/lib64/libdl.so.2 29982: symbol=open; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `open' [GLIBC_2.2.5] 29982: symbol=close; lookup in file=/bin/sh 29982: symbol=close; lookup in file=/lib64/libtermcap.so.2 29982: symbol=close; lookup in file=/lib64/libdl.so.2 29982: symbol=close; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `close' [GLIBC_2.2.5] 29982: symbol=setlocale; lookup in file=/bin/sh 29982: symbol=setlocale; lookup in file=/lib64/libtermcap.so.2 29982: symbol=setlocale; lookup in file=/lib64/libdl.so.2 29982: symbol=setlocale; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `setlocale' [GLIBC_2.2.5] 29982: symbol=malloc; lookup in file=/bin/sh 29982: symbol=malloc; lookup in file=/lib64/libtermcap.so.2 29982: symbol=malloc; lookup in file=/lib64/libdl.so.2 29982: symbol=malloc; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `malloc' [GLIBC_2.2.5] 29982: symbol=__libc_malloc; lookup in file=/bin/sh 29982: symbol=__libc_malloc; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__libc_malloc; lookup in file=/lib64/libdl.so.2 29982: symbol=__libc_malloc; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `__libc_malloc' [GLIBC_2.2.5] 29982: symbol=free; lookup in file=/bin/sh 29982: symbol=free; lookup in file=/lib64/libtermcap.so.2 29982: symbol=free; lookup in file=/lib64/libdl.so.2 29982: symbol=free; lookup in file=/lib64/tls/libc.so.6 29982: binding file /lib64/tls/libc.so.6 to /lib64/tls/libc.so.6: normal symbol `free' [GLIBC_2.2.5] 29982: symbol=strlen; lookup in file=/bin/sh 29982: symbol=strlen; lookup in file=/lib64/libtermcap.so.2 29982: symbol=strlen; lookup in file=/lib64/libdl.so.2 29982: symbol=strlen; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `strlen' [GLIBC_2.2.5] 29982: symbol=malloc; lookup in file=/bin/sh 29982: symbol=malloc; lookup in file=/lib64/libtermcap.so.2 29982: symbol=malloc; lookup in file=/lib64/libdl.so.2 29982: symbol=malloc; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `malloc' [GLIBC_2.2.5] 29982: symbol=strcpy; lookup in file=/bin/sh 29982: symbol=strcpy; lookup in file=/lib64/libtermcap.so.2 29982: symbol=strcpy; lookup in file=/lib64/libdl.so.2 29982: symbol=strcpy; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `strcpy' [GLIBC_2.2.5] 29982: symbol=getuid; lookup in file=/bin/sh 29982: symbol=getuid; lookup in file=/lib64/libtermcap.so.2 29982: symbol=getuid; lookup in file=/lib64/libdl.so.2 29982: symbol=getuid; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `getuid' [GLIBC_2.2.5] 29982: symbol=getgid; lookup in file=/bin/sh 29982: symbol=getgid; lookup in file=/lib64/libtermcap.so.2 29982: symbol=getgid; lookup in file=/lib64/libdl.so.2 29982: symbol=getgid; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `getgid' [GLIBC_2.2.5] 29982: symbol=geteuid; lookup in file=/bin/sh 29982: symbol=geteuid; lookup in file=/lib64/libtermcap.so.2 29982: symbol=geteuid; lookup in file=/lib64/libdl.so.2 29982: symbol=geteuid; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `geteuid' [GLIBC_2.2.5] 29982: symbol=getegid; lookup in file=/bin/sh 29982: symbol=getegid; lookup in file=/lib64/libtermcap.so.2 29982: symbol=getegid; lookup in file=/lib64/libdl.so.2 29982: symbol=getegid; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `getegid' [GLIBC_2.2.5] 29982: symbol=strncmp; lookup in file=/bin/sh 29982: symbol=strncmp; lookup in file=/lib64/libtermcap.so.2 29982: symbol=strncmp; lookup in file=/lib64/libdl.so.2 29982: symbol=strncmp; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `strncmp' [GLIBC_2.2.5] 29982: symbol=strrchr; lookup in file=/bin/sh 29982: symbol=strrchr; lookup in file=/lib64/libtermcap.so.2 29982: symbol=strrchr; lookup in file=/lib64/libdl.so.2 29982: symbol=strrchr; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `strrchr' [GLIBC_2.2.5] 29982: symbol=time; lookup in file=/bin/sh 29982: symbol=time; lookup in file=/lib64/libtermcap.so.2 29982: symbol=time; lookup in file=/lib64/libdl.so.2 29982: symbol=time; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `time' [GLIBC_2.2.5] 29982: symbol=setvbuf; lookup in file=/bin/sh 29982: symbol=setvbuf; lookup in file=/lib64/libtermcap.so.2 29982: symbol=setvbuf; lookup in file=/lib64/libdl.so.2 29982: symbol=setvbuf; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `setvbuf' [GLIBC_2.2.5] 29982: symbol=qsort; lookup in file=/bin/sh 29982: symbol=qsort; lookup in file=/lib64/libtermcap.so.2 29982: symbol=qsort; lookup in file=/lib64/libdl.so.2 29982: symbol=qsort; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `qsort' [GLIBC_2.2.5] 29982: symbol=strcmp; lookup in file=/bin/sh 29982: symbol=strcmp; lookup in file=/lib64/libtermcap.so.2 29982: symbol=strcmp; lookup in file=/lib64/libdl.so.2 29982: symbol=strcmp; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `strcmp' [GLIBC_2.2.5] 29982: symbol=sigemptyset; lookup in file=/bin/sh 29982: symbol=sigemptyset; lookup in file=/lib64/libtermcap.so.2 29982: symbol=sigemptyset; lookup in file=/lib64/libdl.so.2 29982: symbol=sigemptyset; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `sigemptyset' [GLIBC_2.2.5] 29982: symbol=sigaction; lookup in file=/bin/sh 29982: symbol=sigaction; lookup in file=/lib64/libtermcap.so.2 29982: symbol=sigaction; lookup in file=/lib64/libdl.so.2 29982: symbol=sigaction; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `sigaction' [GLIBC_2.2.5] 29982: symbol=sigprocmask; lookup in file=/bin/sh 29982: symbol=sigprocmask; lookup in file=/lib64/libtermcap.so.2 29982: symbol=sigprocmask; lookup in file=/lib64/libdl.so.2 29982: symbol=sigprocmask; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `sigprocmask' [GLIBC_2.2.5] 29982: symbol=sigdelset; lookup in file=/bin/sh 29982: symbol=sigdelset; lookup in file=/lib64/libtermcap.so.2 29982: symbol=sigdelset; lookup in file=/lib64/libdl.so.2 29982: symbol=sigdelset; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `sigdelset' [GLIBC_2.2.5] 29982: symbol=gethostname; lookup in file=/bin/sh 29982: symbol=gethostname; lookup in file=/lib64/libtermcap.so.2 29982: symbol=gethostname; lookup in file=/lib64/libdl.so.2 29982: symbol=gethostname; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `gethostname' [GLIBC_2.2.5] 29982: symbol=__xstat; lookup in file=/bin/sh 29982: symbol=__xstat; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__xstat; lookup in file=/lib64/libdl.so.2 29982: symbol=__xstat; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `__xstat' [GLIBC_2.2.5] 29982: symbol=free; lookup in file=/bin/sh 29982: symbol=free; lookup in file=/lib64/libtermcap.so.2 29982: symbol=free; lookup in file=/lib64/libdl.so.2 29982: symbol=free; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `free' [GLIBC_2.2.5] 29982: symbol=getpid; lookup in file=/bin/sh 29982: symbol=getpid; lookup in file=/lib64/libtermcap.so.2 29982: symbol=getpid; lookup in file=/lib64/libdl.so.2 29982: symbol=getpid; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `getpid' [GLIBC_2.2.5] 29982: symbol=memset; lookup in file=/bin/sh 29982: symbol=memset; lookup in file=/lib64/libtermcap.so.2 29982: symbol=memset; lookup in file=/lib64/libdl.so.2 29982: symbol=memset; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `memset' [GLIBC_2.2.5] 29982: symbol=__errno_location; lookup in file=/bin/sh 29982: symbol=__errno_location; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__errno_location; lookup in file=/lib64/libdl.so.2 29982: symbol=__errno_location; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `__errno_location' [GLIBC_2.2.5] 29982: symbol=__strtol_internal; lookup in file=/bin/sh 29982: symbol=__strtol_internal; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__strtol_internal; lookup in file=/lib64/libdl.so.2 29982: symbol=__strtol_internal; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `__strtol_internal' [GLIBC_2.2.5] 29982: symbol=getppid; lookup in file=/bin/sh 29982: symbol=getppid; lookup in file=/lib64/libtermcap.so.2 29982: symbol=getppid; lookup in file=/lib64/libdl.so.2 29982: symbol=getppid; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `getppid' [GLIBC_2.2.5] 29982: symbol=sprintf; lookup in file=/bin/sh 29982: symbol=sprintf; lookup in file=/lib64/libtermcap.so.2 29982: symbol=sprintf; lookup in file=/lib64/libdl.so.2 29982: symbol=sprintf; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `sprintf' [GLIBC_2.2.5] 29982: symbol=strchr; lookup in file=/bin/sh 29982: symbol=strchr; lookup in file=/lib64/libtermcap.so.2 29982: symbol=strchr; lookup in file=/lib64/libdl.so.2 29982: symbol=strchr; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `strchr' [GLIBC_2.2.5] 29982: symbol=getpgrp; lookup in file=/bin/sh 29982: symbol=getpgrp; lookup in file=/lib64/libtermcap.so.2 29982: symbol=getpgrp; lookup in file=/lib64/libdl.so.2 29982: symbol=getpgrp; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `getpgrp' [GLIBC_2.2.5] 29982: symbol=fileno; lookup in file=/bin/sh 29982: symbol=fileno; lookup in file=/lib64/libtermcap.so.2 29982: symbol=fileno; lookup in file=/lib64/libdl.so.2 29982: symbol=fileno; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `fileno' [GLIBC_2.2.5] 29982: symbol=isatty; lookup in file=/bin/sh 29982: symbol=isatty; lookup in file=/lib64/libtermcap.so.2 29982: symbol=isatty; lookup in file=/lib64/libdl.so.2 29982: symbol=isatty; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `isatty' [GLIBC_2.2.5] 29982: symbol=lseek; lookup in file=/bin/sh 29982: symbol=lseek; lookup in file=/lib64/libtermcap.so.2 29982: symbol=lseek; lookup in file=/lib64/libdl.so.2 29982: symbol=lseek; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `lseek' [GLIBC_2.2.5] 29982: symbol=read; lookup in file=/bin/sh 29982: symbol=read; lookup in file=/lib64/libtermcap.so.2 29982: symbol=read; lookup in file=/lib64/libdl.so.2 29982: symbol=read; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `read' [GLIBC_2.2.5] 29982: symbol=__ctype_b_loc; lookup in file=/bin/sh 29982: symbol=__ctype_b_loc; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__ctype_b_loc; lookup in file=/lib64/libdl.so.2 29982: symbol=__ctype_b_loc; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `__ctype_b_loc' [GLIBC_2.3] 29982: symbol=getdtablesize; lookup in file=/bin/sh 29982: symbol=getdtablesize; lookup in file=/lib64/libtermcap.so.2 29982: symbol=getdtablesize; lookup in file=/lib64/libdl.so.2 29982: symbol=getdtablesize; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `getdtablesize' [GLIBC_2.2.5] 29982: symbol=dup2; lookup in file=/bin/sh 29982: symbol=dup2; lookup in file=/lib64/libtermcap.so.2 29982: symbol=dup2; lookup in file=/lib64/libdl.so.2 29982: symbol=dup2; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `dup2' [GLIBC_2.2.5] 29982: symbol=fcntl; lookup in file=/bin/sh 29982: symbol=fcntl; lookup in file=/lib64/libtermcap.so.2 29982: symbol=fcntl; lookup in file=/lib64/libdl.so.2 29982: symbol=fcntl; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `fcntl' [GLIBC_2.2.5] 29982: symbol=__fxstat; lookup in file=/bin/sh 29982: symbol=__fxstat; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__fxstat; lookup in file=/lib64/libdl.so.2 29982: symbol=__fxstat; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `__fxstat' [GLIBC_2.2.5] 29982: symbol=__ctype_get_mb_cur_max; lookup in file=/bin/sh 29982: symbol=__ctype_get_mb_cur_max; lookup in file=/lib64/libtermcap.so.2 29982: symbol=__ctype_get_mb_cur_max; lookup in file=/lib64/libdl.so.2 29982: symbol=__ctype_get_mb_cur_max; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `__ctype_get_mb_cur_max' [GLIBC_2.2.5] 29982: symbol=mbrtowc; lookup in file=/bin/sh 29982: symbol=mbrtowc; lookup in file=/lib64/libtermcap.so.2 29982: symbol=mbrtowc; lookup in file=/lib64/libdl.so.2 29982: symbol=mbrtowc; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `mbrtowc' [GLIBC_2.2.5] 29982: symbol=memcpy; lookup in file=/bin/sh 29982: symbol=memcpy; lookup in file=/lib64/libtermcap.so.2 29982: symbol=memcpy; lookup in file=/lib64/libdl.so.2 29982: symbol=memcpy; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `memcpy' [GLIBC_2.2.5] 29982: symbol=printf; lookup in file=/bin/sh 29982: symbol=printf; lookup in file=/lib64/libtermcap.so.2 29982: symbol=printf; lookup in file=/lib64/libdl.so.2 29982: symbol=printf; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `printf' [GLIBC_2.2.5] 29982: symbol=_IO_putc; lookup in file=/bin/sh 29982: symbol=_IO_putc; lookup in file=/lib64/libtermcap.so.2 29982: symbol=_IO_putc; lookup in file=/lib64/libdl.so.2 29982: symbol=_IO_putc; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `_IO_putc' [GLIBC_2.2.5] ProxyChains-3.1 (http://proxychains.sf.net) 29982: symbol=fflush; lookup in file=/bin/sh 29982: symbol=fflush; lookup in file=/lib64/libtermcap.so.2 29982: symbol=fflush; lookup in file=/lib64/libdl.so.2 29982: symbol=fflush; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `fflush' [GLIBC_2.2.5] 29982: symbol=ferror; lookup in file=/bin/sh 29982: symbol=ferror; lookup in file=/lib64/libtermcap.so.2 29982: symbol=ferror; lookup in file=/lib64/libdl.so.2 29982: symbol=ferror; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `ferror' [GLIBC_2.2.5] 29982: symbol=strncpy; lookup in file=/bin/sh 29982: symbol=strncpy; lookup in file=/lib64/libtermcap.so.2 29982: symbol=strncpy; lookup in file=/lib64/libdl.so.2 29982: symbol=strncpy; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `strncpy' [GLIBC_2.2.5] 29982: symbol=siglongjmp; lookup in file=/bin/sh 29982: symbol=siglongjmp; lookup in file=/lib64/libtermcap.so.2 29982: symbol=siglongjmp; lookup in file=/lib64/libdl.so.2 29982: symbol=siglongjmp; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `siglongjmp' [GLIBC_2.2.5] 29982: symbol=execve; lookup in file=/bin/sh 29982: symbol=execve; lookup in file=/lib64/libtermcap.so.2 29982: symbol=execve; lookup in file=/lib64/libdl.so.2 29982: symbol=execve; lookup in file=/lib64/tls/libc.so.6 29982: binding file /bin/sh to /lib64/tls/libc.so.6: normal symbol `execve' [GLIBC_2.2.5] 29982: 29982: file=libproxychains.so; needed by bin/do-not-directly-run-secondlife-bin 29982: find library=libproxychains.so; searching 29982: search cache=/etc/ld.so.cache 29982: search path=/lib/tls/i686/mmx:/lib/tls/i686:/lib/tls/mmx:/lib/tls:/lib/i686/mmx:/lib/i686:/lib/mmx:/lib:/usr/lib/tls/i686/mmx:/usr/lib/tls/i686:/usr/lib/tls/mmx:/usr/lib/tls:/usr/lib/i686/mmx:/usr/lib/i686:/usr/lib/mmx:/usr/lib (system search path) 29982: trying file=/lib/tls/i686/mmx/libproxychains.so 29982: trying file=/lib/tls/i686/libproxychains.so 29982: trying file=/lib/tls/mmx/libproxychains.so 29982: trying file=/lib/tls/libproxychains.so 29982: trying file=/lib/i686/mmx/libproxychains.so 29982: trying file=/lib/i686/libproxychains.so 29982: trying file=/lib/mmx/libproxychains.so 29982: trying file=/lib/libproxychains.so 29982: trying file=/usr/lib/tls/i686/mmx/libproxychains.so 29982: trying file=/usr/lib/tls/i686/libproxychains.so 29982: trying file=/usr/lib/tls/mmx/libproxychains.so 29982: trying file=/usr/lib/tls/libproxychains.so 29982: trying file=/usr/lib/i686/mmx/libproxychains.so 29982: trying file=/usr/lib/i686/libproxychains.so 29982: trying file=/usr/lib/mmx/libproxychains.so 29982: trying file=/usr/lib/libproxychains.so 29982: bin/do-not-directly-run-secondlife-bin: error while loading shared libraries: libproxychains.so: cannot open shared object file: No such file or directory From jbglaw at lug-owl.de Fri Feb 16 12:58:24 2007 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Fri Feb 16 12:58:32 2007 Subject: [sldev] Socksifying linux client via LD_PRELOAD In-Reply-To: <55906.134.163.255.14.1171658796.squirrel@mail.thantosga.com> References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> <45D5ED0B.3010602@lindenlab.com> <55906.134.163.255.14.1171658796.squirrel@mail.thantosga.com> Message-ID: <20070216205824.GM23849@lug-owl.de> On Fri, 2007-02-16 14:46:36 -0600, Brandon wrote: > 29982: file=libproxychains.so; needed by > bin/do-not-directly-run-secondlife-bin > 29982: find library=libproxychains.so; searching > 29982: search cache=/etc/ld.so.cache > 29982: search > path=/lib/tls/i686/mmx:/lib/tls/i686:/lib/tls/mmx:/lib/tls:/lib/i686/mmx:/lib/i686:/lib/mmx:/lib:/usr/lib/tls/i686/mmx:/usr/lib/tls/i686:/usr/lib/tls/mmx:/usr/lib/tls:/usr/lib/i686/mmx:/usr/lib/i686:/usr/lib/mmx:/usr/lib > (system search path) > 29982: trying file=/lib/tls/i686/mmx/libproxychains.so > 29982: trying file=/lib/tls/i686/libproxychains.so > 29982: trying file=/lib/tls/mmx/libproxychains.so > 29982: trying file=/lib/tls/libproxychains.so > 29982: trying file=/lib/i686/mmx/libproxychains.so > 29982: trying file=/lib/i686/libproxychains.so > 29982: trying file=/lib/mmx/libproxychains.so > 29982: trying file=/lib/libproxychains.so > 29982: trying file=/usr/lib/tls/i686/mmx/libproxychains.so > 29982: trying file=/usr/lib/tls/i686/libproxychains.so > 29982: trying file=/usr/lib/tls/mmx/libproxychains.so > 29982: trying file=/usr/lib/tls/libproxychains.so > 29982: trying file=/usr/lib/i686/mmx/libproxychains.so > 29982: trying file=/usr/lib/i686/libproxychains.so > 29982: trying file=/usr/lib/mmx/libproxychains.so > 29982: trying file=/usr/lib/libproxychains.so > 29982: > bin/do-not-directly-run-secondlife-bin: error while loading shared > libraries: libproxychains.so: cannot open shared object file: No such file > or directory Where's your libproxychains.so located? Is it within the search path that's printed above? Maybe there's a shell script running that fiddles with LD_LIBRARY_PATH incorrectly (eg. without keeping its former contents). Alternatively, you can try to force it with LD_PRELOAD=/path/to/libproxychains.so (supplying the full path.) MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: ...und wenn Du denkst, es geht nicht mehr, the second : kommt irgendwo ein Lichtlein her. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070216/16192197/attachment.pgp From dimentox at dimentox.com Fri Feb 16 13:12:11 2007 From: dimentox at dimentox.com (Brandon) Date: Fri Feb 16 13:11:19 2007 Subject: [sldev] Socksifying linux client via LD_PRELOAD In-Reply-To: <20070216205824.GM23849@lug-owl.de> References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> <45D5ED0B.3010602@lindenlab.com> <55906.134.163.255.14.1171658796.squirrel@mail.thantosga.com> <20070216205824.GM23849@lug-owl.de> Message-ID: <2735.134.163.255.14.1171660331.squirrel@mail.thantosga.com> Yeah its in the path.. i also just did an export with the full path.. and even ran the binary directly with no scripts.. it works with GAIM binary and mozilla. the linker seems to go dumb when its trying preload for the SL binary. > On Fri, 2007-02-16 14:46:36 -0600, Brandon wrote: >> 29982: file=libproxychains.so; needed by >> bin/do-not-directly-run-secondlife-bin >> 29982: find library=libproxychains.so; searching >> 29982: search cache=/etc/ld.so.cache >> 29982: search >> path=/lib/tls/i686/mmx:/lib/tls/i686:/lib/tls/mmx:/lib/tls:/lib/i686/mmx:/lib/i686:/lib/mmx:/lib:/usr/lib/tls/i686/mmx:/usr/lib/tls/i686:/usr/lib/tls/mmx:/usr/lib/tls:/usr/lib/i686/mmx:/usr/lib/i686:/usr/lib/mmx:/usr/lib >> (system search path) >> 29982: trying file=/lib/tls/i686/mmx/libproxychains.so >> 29982: trying file=/lib/tls/i686/libproxychains.so >> 29982: trying file=/lib/tls/mmx/libproxychains.so >> 29982: trying file=/lib/tls/libproxychains.so >> 29982: trying file=/lib/i686/mmx/libproxychains.so >> 29982: trying file=/lib/i686/libproxychains.so >> 29982: trying file=/lib/mmx/libproxychains.so >> 29982: trying file=/lib/libproxychains.so >> 29982: trying file=/usr/lib/tls/i686/mmx/libproxychains.so >> 29982: trying file=/usr/lib/tls/i686/libproxychains.so >> 29982: trying file=/usr/lib/tls/mmx/libproxychains.so >> 29982: trying file=/usr/lib/tls/libproxychains.so >> 29982: trying file=/usr/lib/i686/mmx/libproxychains.so >> 29982: trying file=/usr/lib/i686/libproxychains.so >> 29982: trying file=/usr/lib/mmx/libproxychains.so >> 29982: trying file=/usr/lib/libproxychains.so >> 29982: >> bin/do-not-directly-run-secondlife-bin: error while loading shared >> libraries: libproxychains.so: cannot open shared object file: No such >> file >> or directory > > Where's your libproxychains.so located? Is it within the search path > that's printed above? Maybe there's a shell script running that > fiddles with LD_LIBRARY_PATH incorrectly (eg. without keeping its > former contents). Alternatively, you can try to force it with > LD_PRELOAD=/path/to/libproxychains.so (supplying the full path.) > > MfG, JBG > > -- > Jan-Benedict Glaw jbglaw@lug-owl.de > +49-172-7608481 > Signature of: ...und wenn Du denkst, es geht nicht mehr, > the second : kommt irgendwo ein Lichtlein her. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From mindtriggerz at gmail.com Fri Feb 16 13:16:55 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Fri Feb 16 13:16:59 2007 Subject: [sldev] Socksifying linux client via LD_PRELOAD In-Reply-To: <2735.134.163.255.14.1171660331.squirrel@mail.thantosga.com> References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> <45D5ED0B.3010602@lindenlab.com> <55906.134.163.255.14.1171658796.squirrel@mail.thantosga.com> <20070216205824.GM23849@lug-owl.de> <2735.134.163.255.14.1171660331.squirrel@mail.thantosga.com> Message-ID: Have you tried building for releasenoopt and running it that way? On 2/16/07, Brandon wrote: > Yeah its in the path.. i also just did an export with the full path.. and > even ran the binary directly with no scripts.. it works with GAIM binary > and mozilla. the linker seems to go dumb when its trying preload for the > SL binary. > > > > On Fri, 2007-02-16 14:46:36 -0600, Brandon wrote: > >> 29982: file=libproxychains.so; needed by > >> bin/do-not-directly-run-secondlife-bin > >> 29982: find library=libproxychains.so; searching > >> 29982: search cache=/etc/ld.so.cache > >> 29982: search > >> path=/lib/tls/i686/mmx:/lib/tls/i686:/lib/tls/mmx:/lib/tls:/lib/i686/mmx:/lib/i686:/lib/mmx:/lib:/usr/lib/tls/i686/mmx:/usr/lib/tls/i686:/usr/lib/tls/mmx:/usr/lib/tls:/usr/lib/i686/mmx:/usr/lib/i686:/usr/lib/mmx:/usr/lib > >> (system search path) > >> 29982: trying file=/lib/tls/i686/mmx/libproxychains.so > >> 29982: trying file=/lib/tls/i686/libproxychains.so > >> 29982: trying file=/lib/tls/mmx/libproxychains.so > >> 29982: trying file=/lib/tls/libproxychains.so > >> 29982: trying file=/lib/i686/mmx/libproxychains.so > >> 29982: trying file=/lib/i686/libproxychains.so > >> 29982: trying file=/lib/mmx/libproxychains.so > >> 29982: trying file=/lib/libproxychains.so > >> 29982: trying file=/usr/lib/tls/i686/mmx/libproxychains.so > >> 29982: trying file=/usr/lib/tls/i686/libproxychains.so > >> 29982: trying file=/usr/lib/tls/mmx/libproxychains.so > >> 29982: trying file=/usr/lib/tls/libproxychains.so > >> 29982: trying file=/usr/lib/i686/mmx/libproxychains.so > >> 29982: trying file=/usr/lib/i686/libproxychains.so > >> 29982: trying file=/usr/lib/mmx/libproxychains.so > >> 29982: trying file=/usr/lib/libproxychains.so > >> 29982: > >> bin/do-not-directly-run-secondlife-bin: error while loading shared > >> libraries: libproxychains.so: cannot open shared object file: No such > >> file > >> or directory > > > > Where's your libproxychains.so located? Is it within the search path > > that's printed above? Maybe there's a shell script running that > > fiddles with LD_LIBRARY_PATH incorrectly (eg. without keeping its > > former contents). Alternatively, you can try to force it with > > LD_PRELOAD=/path/to/libproxychains.so (supplying the full path.) > > > > MfG, JBG > > > > -- > > Jan-Benedict Glaw jbglaw@lug-owl.de > > +49-172-7608481 > > Signature of: ...und wenn Du denkst, es geht nicht mehr, > > the second : kommt irgendwo ein Lichtlein her. > > _______________________________________________ > > 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 > -- --Jesse From jbglaw at lug-owl.de Fri Feb 16 13:34:44 2007 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Fri Feb 16 13:34:51 2007 Subject: [sldev] Socksifying linux client via LD_PRELOAD In-Reply-To: <2735.134.163.255.14.1171660331.squirrel@mail.thantosga.com> References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> <45D5ED0B.3010602@lindenlab.com> <55906.134.163.255.14.1171658796.squirrel@mail.thantosga.com> <20070216205824.GM23849@lug-owl.de> <2735.134.163.255.14.1171660331.squirrel@mail.thantosga.com> Message-ID: <20070216213444.GN23849@lug-owl.de> On Fri, 2007-02-16 15:12:11 -0600, Brandon wrote: > > On Fri, 2007-02-16 14:46:36 -0600, Brandon wrote: > > > 29982: file=libproxychains.so; needed by > > > bin/do-not-directly-run-secondlife-bin > > > 29982: find library=libproxychains.so; searching > > > 29982: search cache=/etc/ld.so.cache > > > 29982: search > > > path=/lib/tls/i686/mmx:/lib/tls/i686:/lib/tls/mmx:/lib/tls:/lib/i686/mmx:/lib/i686:/lib/mmx:/lib:/usr/lib/tls/i686/mmx:/usr/lib/tls/i686:/usr/lib/tls/mmx:/usr/lib/tls:/usr/lib/i686/mmx:/usr/lib/i686:/usr/lib/mmx:/usr/lib > > > (system search path) > > > 29982: trying file=/lib/tls/i686/mmx/libproxychains.so > > > 29982: trying file=/lib/tls/i686/libproxychains.so > > > 29982: trying file=/lib/tls/mmx/libproxychains.so > > > 29982: trying file=/lib/tls/libproxychains.so > > > 29982: trying file=/lib/i686/mmx/libproxychains.so > > > 29982: trying file=/lib/i686/libproxychains.so > > > 29982: trying file=/lib/mmx/libproxychains.so > > > 29982: trying file=/lib/libproxychains.so > > > 29982: trying file=/usr/lib/tls/i686/mmx/libproxychains.so > > > 29982: trying file=/usr/lib/tls/i686/libproxychains.so > > > 29982: trying file=/usr/lib/tls/mmx/libproxychains.so > > > 29982: trying file=/usr/lib/tls/libproxychains.so > > > 29982: trying file=/usr/lib/i686/mmx/libproxychains.so > > > 29982: trying file=/usr/lib/i686/libproxychains.so > > > 29982: trying file=/usr/lib/mmx/libproxychains.so > > > 29982: trying file=/usr/lib/libproxychains.so > > > 29982: > > > bin/do-not-directly-run-secondlife-bin: error while loading shared > > > libraries: libproxychains.so: cannot open shared object file: No such > > > file > > > or directory > > > > Where's your libproxychains.so located? Is it within the search path > > that's printed above? Maybe there's a shell script running that > > fiddles with LD_LIBRARY_PATH incorrectly (eg. without keeping its > > former contents). Alternatively, you can try to force it with > > LD_PRELOAD=/path/to/libproxychains.so (supplying the full path.) > Yeah its in the path.. i also just did an export with the full path.. and > even ran the binary directly with no scripts.. it works with GAIM binary > and mozilla. the linker seems to go dumb when its trying preload for the > SL binary. You didn't actually answer all questions :) MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: God put me on earth to accomplish a certain number of the second : things. Right now I am so far behind I will never die. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070216/b2946a4e/attachment.pgp From dimentox at dimentox.com Fri Feb 16 13:46:36 2007 From: dimentox at dimentox.com (Brandon) Date: Fri Feb 16 13:45:45 2007 Subject: [sldev] Socksifying linux client via LD_PRELOAD In-Reply-To: <20070216213444.GN23849@lug-owl.de> References: <208C19A4-D9B0-440C-8B18-5EDC12F9F6E7@gmail.com> <45D5ED0B.3010602@lindenlab.com> <55906.134.163.255.14.1171658796.squirrel@mail.thantosga.com> <20070216205824.GM23849@lug-owl.de> <2735.134.163.255.14.1171660331.squirrel@mail.thantosga.com> <20070216213444.GN23849@lug-owl.de> Message-ID: <31417.134.163.255.14.1171662396.squirrel@mail.thantosga.com> I Supplied the full path... its loceaded in /lib/ i from a shell did export LD_PRELOAD=/lib/libproxychains.so then ./bin/do-not-run if i unset the LD_preload and do the /bin sl come sup if i have LD_PRELOAD and run any other internet app it works fine. > On Fri, 2007-02-16 15:12:11 -0600, Brandon wrote: >> > On Fri, 2007-02-16 14:46:36 -0600, Brandon >> wrote: >> > > 29982: file=libproxychains.so; needed by >> > > bin/do-not-directly-run-secondlife-bin >> > > 29982: find library=libproxychains.so; searching >> > > 29982: search cache=/etc/ld.so.cache >> > > 29982: search >> > > path=/lib/tls/i686/mmx:/lib/tls/i686:/lib/tls/mmx:/lib/tls:/lib/i686/mmx:/lib/i686:/lib/mmx:/lib:/usr/lib/tls/i686/mmx:/usr/lib/tls/i686:/usr/lib/tls/mmx:/usr/lib/tls:/usr/lib/i686/mmx:/usr/lib/i686:/usr/lib/mmx:/usr/lib >> > > (system search path) >> > > 29982: trying file=/lib/tls/i686/mmx/libproxychains.so >> > > 29982: trying file=/lib/tls/i686/libproxychains.so >> > > 29982: trying file=/lib/tls/mmx/libproxychains.so >> > > 29982: trying file=/lib/tls/libproxychains.so >> > > 29982: trying file=/lib/i686/mmx/libproxychains.so >> > > 29982: trying file=/lib/i686/libproxychains.so >> > > 29982: trying file=/lib/mmx/libproxychains.so >> > > 29982: trying file=/lib/libproxychains.so >> > > 29982: trying file=/usr/lib/tls/i686/mmx/libproxychains.so >> > > 29982: trying file=/usr/lib/tls/i686/libproxychains.so >> > > 29982: trying file=/usr/lib/tls/mmx/libproxychains.so >> > > 29982: trying file=/usr/lib/tls/libproxychains.so >> > > 29982: trying file=/usr/lib/i686/mmx/libproxychains.so >> > > 29982: trying file=/usr/lib/i686/libproxychains.so >> > > 29982: trying file=/usr/lib/mmx/libproxychains.so >> > > 29982: trying file=/usr/lib/libproxychains.so >> > > 29982: >> > > bin/do-not-directly-run-secondlife-bin: error while loading shared >> > > libraries: libproxychains.so: cannot open shared object file: No >> such >> > > file >> > > or directory >> > >> > Where's your libproxychains.so located? Is it within the search path >> > that's printed above? Maybe there's a shell script running that >> > fiddles with LD_LIBRARY_PATH incorrectly (eg. without keeping its >> > former contents). Alternatively, you can try to force it with >> > LD_PRELOAD=/path/to/libproxychains.so (supplying the full path.) >> Yeah its in the path.. i also just did an export with the full path.. >> and >> even ran the binary directly with no scripts.. it works with GAIM binary >> and mozilla. the linker seems to go dumb when its trying preload for the >> SL binary. > > You didn't actually answer all questions :) > > MfG, JBG > > -- > Jan-Benedict Glaw jbglaw@lug-owl.de > +49-172-7608481 > Signature of: God put me on earth to accomplish a certain > number of > the second : things. Right now I am so far behind I will never > die. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From seg at haxxed.com Fri Feb 16 20:26:10 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Feb 16 20:29:29 2007 Subject: [sldev] ELFIO usage? Message-ID: <1171686371.30902.15.camel@localhost.localdomain> I am working on packaging slviewer for Fedora. There are a few library requirements we don't already have packaged. ELFIO is one of them. Looking through the source, it appears ELFIO is used to produce backtraces that are supposedly better than standard glibc. Presumably this is mainly useful for the crash reporter. Which leads to another question, should a downstream client build even have the crash reporter enabled? Does Linden Lab want to be receiving crash reports from a non-stock Fedora build? Conversely, does Fedora want to be sending crash reports to Linden Lab? (At the moment, the crash reporter is not being packaged.) I'm inclined to just not build in ELFIO usage, and save us a library dep. Comments? -------------- 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/20070216/e267ada2/attachment.pgp From gigstaggart at gmail.com Fri Feb 16 20:59:03 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Feb 16 20:58:56 2007 Subject: [sldev] ELFIO usage? In-Reply-To: <1171686371.30902.15.camel@localhost.localdomain> References: <1171686371.30902.15.camel@localhost.localdomain> Message-ID: <45D68B97.2070804@gmail.com> Callum Lerwick wrote: > I'm inclined to just not build in ELFIO usage, and save us a library > dep. Comments? It came up earlier in relation to if LL wants performance related bug reports from self-compiled viewers, the answer was no. -Jason From dale at daleglass.net Sun Feb 18 16:59:11 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Feb 18 16:59:33 2007 Subject: [sldev] Avatar list ready for testing! Message-ID: <200702190159.18689.dale@daleglass.net> I've got a first release of my avatar list done. Here's what it looks like: http://daleglass.net/images/screenshots/avlist6_001.jpg Features: * Shows all avatar the client knows of (roughly render distance) * Retrieves ages and payment info * Retrieves TrustNet scores (needs attachment, ask me for one) * Shows activity (just appeared, moving, left) * Integrates Luskwood commands * Can show profiles, IM, place a beacon or mark selected avatars Get it here: http://svn.daleglass.net/secondlife/trunk/ Current version is based on the latest FirstLook release, art is in the repository but libraries aren't. I will appreciate feedback of any sort :-) Also, I'm looking for icons for the following: General: * Data unknown (got to fetch something, but didn't try yet, because it's disabled for example) * Fetching * Error Payment info: * None * Filled * Used * Charter member (lifetime account obtained during beta) * Linden * Special title (people with special info, like Philip Linden who appears as "El Presidente") Activity: * Just appeared * Rezzing objects * Playing sounds * Generating particles * Moving * Just left (people are kept in the list for a while) So far I'm using various icons from the client, but the result is less than ideal. So I'd appreciate if somebody could point me at some place where I could find something appropiate, or contribute some :-) -------------- 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/20070219/cea669ee/attachment.pgp From JesseMalthus at gmail.com Sun Feb 18 17:28:22 2007 From: JesseMalthus at gmail.com (Jesse Malthus) Date: Sun Feb 18 17:28:26 2007 Subject: [sldev] Avatar list ready for testing! In-Reply-To: <200702190159.18689.dale@daleglass.net> References: <200702190159.18689.dale@daleglass.net> Message-ID: I am inclined to say that this is pretty sexy. Will you be providing binaries? On 2/18/07, Dale Glass wrote: > I've got a first release of my avatar list done. Here's what it looks like: > http://daleglass.net/images/screenshots/avlist6_001.jpg > > Features: > * Shows all avatar the client knows of (roughly render distance) > * Retrieves ages and payment info > * Retrieves TrustNet scores (needs attachment, ask me for one) > * Shows activity (just appeared, moving, left) > * Integrates Luskwood commands > * Can show profiles, IM, place a beacon or mark selected avatars > > Get it here: > http://svn.daleglass.net/secondlife/trunk/ > > Current version is based on the latest FirstLook release, art is in the > repository but libraries aren't. > > I will appreciate feedback of any sort :-) > > Also, I'm looking for icons for the following: > > General: > * Data unknown (got to fetch something, but didn't try yet, because it's > disabled for example) > * Fetching > * Error > > Payment info: > * None > * Filled > * Used > * Charter member (lifetime account obtained during beta) > * Linden > * Special title (people with special info, like Philip Linden who appears > as "El Presidente") > > Activity: > * Just appeared > * Rezzing objects > * Playing sounds > * Generating particles > * Moving > * Just left (people are kept in the list for a while) > > So far I'm using various icons from the client, but the result is less than > ideal. So I'd appreciate if somebody could point me at some place where I > could find something appropiate, or contribute some :-) > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- --Jesse From dale at daleglass.net Sun Feb 18 17:50:16 2007 From: dale at daleglass.net (Dale Glass) Date: Sun Feb 18 17:50:36 2007 Subject: [sldev] Avatar list ready for testing! In-Reply-To: References: <200702190159.18689.dale@daleglass.net> Message-ID: <200702190250.28574.dale@daleglass.net> ? ????????? ?? 19 ??????? 2007 02:28 Jesse Malthus ???????(a): > I am inclined to say that this is pretty sexy. Will you be providing > binaries? Eventually, yes. Current plan for the windows installer is to ship just the .exe and added files, and make it go over the standard install, plus some sort of switcher to choose between standard and my version. I will announce anything of the sort here, so that we can standarize a bit, if people want to do that sort of thing as well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070219/aec2b411/attachment.pgp From jhurliman at wsu.edu Sun Feb 18 22:30:38 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Sun Feb 18 22:30:42 2007 Subject: [sldev] Avatar list ready for testing! In-Reply-To: <200702190250.28574.dale@daleglass.net> References: <200702190159.18689.dale@daleglass.net> <200702190250.28574.dale@daleglass.net> Message-ID: <45D9440E.1020906@wsu.edu> Dale Glass wrote: > ? ????????? ?? 19 ??????? 2007 02:28 Jesse Malthus ???????(a): > >> I am inclined to say that this is pretty sexy. Will you be providing >> binaries? >> > > Eventually, yes. > > Current plan for the windows installer is to ship just the .exe and added > files, and make it go over the standard install, plus some sort of switcher > to choose between standard and my version. > > I will announce anything of the sort here, so that we can standarize a bit, if > people want to do that sort of thing as well. > Here's an NSIS file I used for installing Second Life addons in to the current Second Life directory: !define APPNAME "Second Life Addon" !define APPVERSION "1.0" !define APPNAMEANDVERSION "${APPNAME} ${APPVERSION}" !define SL_INST_DIR $8 ;-------------------------------- Name "${APPNAMEANDVERSION}" InstallDir "" InstallDirRegKey HKLM "SOFTWARE\Linden Research, Inc.\SecondLife" "" OutFile "sladdon-${APPVERSION}-install.exe" ShowInstDetails show ;-------------------------------- Function .onInit ; read the installation directory from the registry ;ReadRegStr ${SL_INST_DIR} HKLM "SOFTWARE\Linden Research, Inc.\SecondLife" "" ; Check for SL installation existence StrCmp $INSTDIR "" 0 NoAbortInst MessageBox MB_OK "Second Life installation was not found. Please install Second Life before runing this installer." Abort NoAbortInst: FunctionEnd ;-------------------------------- ;Pages ;Page directory Page instfiles UninstPage uninstConfirm UninstPage instfiles ;-------------------------------- Section "" SetOutPath $INSTDIR File sladdon-${APPVERSION}.exe File sladdon-readme.txt CreateDirectory "$SMPROGRAMS\${APPNAME}" CreateShortCut "$SMPROGRAMS\${APPNAME}\Uninstall.lnk" "$INSTDIR\sladdon-${APPVERSION}-uninstall.exe" "" "$INSTDIR\sladdon-${APPVERSION}-uninstall.exe" 0 CreateShortCut "$SMPROGRAMS\${APPNAME}\Instructions.lnk" "$INSTDIR\sladdon-readme.txt" "" "$INSTDIR\sladdon-readme.txt" 0 CreateShortCut "$SMPROGRAMS\${APPNAME}\${APPNAME}.lnk" "$INSTDIR\sladdon-${APPVERSION}.exe" "" "$INSTDIR\sladdon-${APPVERSION}.exe" 0 WriteUninstaller "sladdon-${APPVERSION}-uninstall.exe" SectionEnd ;-------------------------------- Section "Uninstall" Delete $INSTDIR\sladdon-${APPVERSION}.exe Delete $INSTDIR\sladdon-${APPVERSION}-uninstall.exe Delete $INSTDIR\sladdon-readme.txt Delete "$SMPROGRAMS\${APPNAME}\*.*" RMDir "$SMPROGRAMS\${APPNAME}" SectionEnd ;-------------------------------- John Hurliman From christian at electricsheepcompany.com Sun Feb 18 22:31:24 2007 From: christian at electricsheepcompany.com (Christian Westbrook) Date: Sun Feb 18 22:31:39 2007 Subject: [sldev] Avatar list ready for testing! In-Reply-To: <200702190250.28574.dale@daleglass.net> References: <200702190159.18689.dale@daleglass.net> <200702190250.28574.dale@daleglass.net> Message-ID: <95FE8410-3D04-4E24-8FFA-29B675835E5F@electricsheepcompany.com> Hi Dale, I was speaking with Rob about progress on plugin architectures for SL and he suggested something that seems actually to make a lot of sense: if we could run your AV scanner as a plug-in that LL doesn't have to accept into their main code base, but that you can share and distribute through OpenMetaverse.org (we are changing from OpenSecondLife.org because of Trademark considerations). He specifically mentioned your scanner as an ideal candidate for turning into a plugin, so I was hoping to speak with you a bit on IRC or perhaps in-world (wherever you are most comfortable) about how receptive you might be to the possibility of pursuing that. Thanks in advance, Christian Westbrook SL: Christian Prior OpenMetaverse.org On Feb 18, 2007, at 8:50 PM, Dale Glass wrote: > ? ????????? ?? 19 ??????? 2007 02:28 Jesse > Malthus ???????(a): >> I am inclined to say that this is pretty sexy. Will you be providing >> binaries? > > Eventually, yes. > > Current plan for the windows installer is to ship just the .exe and > added > files, and make it go over the standard install, plus some sort of > switcher > to choose between standard and my version. > > I will announce anything of the sort here, so that we can > standarize a bit, if > people want to do that sort of thing as well. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From mrfrans at gmail.com Sun Feb 18 22:34:57 2007 From: mrfrans at gmail.com (Frans) Date: Sun Feb 18 22:34:59 2007 Subject: [sldev] Avatar list ready for testing! In-Reply-To: <200702190250.28574.dale@daleglass.net> References: <200702190159.18689.dale@daleglass.net> <200702190250.28574.dale@daleglass.net> Message-ID: <7765f2c60702182234u52a4be6fxeed469abe6ecec0d@mail.gmail.com> Looking cool so far. What is the colom on the most left used for, with the blue boxes, and what are luskwood commands and how are they usefull to the rest of the grid? On 2/19/07, Dale Glass wrote: > > ? ????????? ?? 19 ??????? 2007 02:28 Jesse Malthus ???????(a): > > I am inclined to say that this is pretty sexy. Will you be providing > > binaries? > > Eventually, yes. > > Current plan for the windows installer is to ship just the .exe and added > files, and make it go over the standard install, plus some sort of > switcher > to choose between standard and my version. > > I will announce anything of the sort here, so that we can standarize a > bit, if > people want to do that sort of thing as well. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- RL: Jeroen Frans SL: Frans Charming http://www.thevesuviusgroup.com http://www.fransinnovations.com http://secondslog.blogspot.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070219/707d80d2/attachment.htm From metalwheaties at gmail.com Sun Feb 18 23:03:51 2007 From: metalwheaties at gmail.com (Metal Wheaties) Date: Sun Feb 18 23:03:54 2007 Subject: [sldev] Useful in-world services performed by a "headless" client? Message-ID: Hi. New to this list. Has anyone thought of making a headless version of the SL client software that a specially made account (avatar name) could use to make a scripted CLIENT to provide special scripted in-world services? For example, an avatar you give textures to (as inventory drop) that could modify them in some way (e.g., something simple like colorizing them) and give them back to you. There should be no reason why you couldn't add a python scripting engine to the client to allow one to drop on such a pseudo-avatar - for example - objects containing python scripts in their inventory. These scripts could do pretty much ANYTHING you can do with the UI given proper hooks in the client. You could also register such a service as an XML entity to provide services via the web interfaces from scripted objects in-world as well. -- If you believe you are largely the sum of your experiences, you should choose experiences that make you who you want to become. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070218/a91415f2/attachment-0001.htm From dale at daleglass.net Mon Feb 19 01:25:14 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Feb 19 01:25:29 2007 Subject: [sldev] Avatar list ready for testing! In-Reply-To: <95FE8410-3D04-4E24-8FFA-29B675835E5F@electricsheepcompany.com> References: <200702190159.18689.dale@daleglass.net> <200702190250.28574.dale@daleglass.net> <95FE8410-3D04-4E24-8FFA-29B675835E5F@electricsheepcompany.com> Message-ID: <200702191025.14546.dale@daleglass.net> ? ????????? ?? 19 ??????? 2007 07:31 Christian Westbrook ???????(a): > Hi Dale, > > I was speaking with Rob about progress on plugin architectures for SL > and he suggested something that seems actually to make a lot of > sense: if we could run your AV scanner as a plug-in that LL doesn't > have to accept into their main code base, but that you can share and > distribute through OpenMetaverse.org (we are changing from > OpenSecondLife.org because of Trademark considerations). He > specifically mentioned your scanner as an ideal candidate for turning > into a plugin, so I was hoping to speak with you a bit on IRC or > perhaps in-world (wherever you are most comfortable) about how > receptive you might be to the possibility of pursuing that. Sure, I am interested in that as well :-) I posted an earlier message here detailing what the scanner needs to be able to do and have access to, and now you have the source as well, but of course I'll be glad to discuss whatever is needed. I definitely want it to be a plugin eventually, as when done it'll probably contain quite a lot of functionality that won't be very newbie-friendly, so I doubt it'd get integrated into the main client as-is. -------------- 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/20070219/af5848c1/attachment.pgp From dale at daleglass.net Mon Feb 19 01:31:39 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Feb 19 01:31:45 2007 Subject: [sldev] Avatar list ready for testing! In-Reply-To: <7765f2c60702182234u52a4be6fxeed469abe6ecec0d@mail.gmail.com> References: <200702190159.18689.dale@daleglass.net> <200702190250.28574.dale@daleglass.net> <7765f2c60702182234u52a4be6fxeed469abe6ecec0d@mail.gmail.com> Message-ID: <200702191031.39413.dale@daleglass.net> D'oh, pressed wrong button. Sending to list: ? ????????? ?? 19 ??????? 2007 07:34 ?? ????????: > Looking cool so far. > What is the colom on the most left used for, with the blue boxes, and what > are luskwood commands and how are they usefull to the rest of the grid? Activity. The idea is to indicate what's the avatar currently doing. So far I have: * Avatar just appeared * Avatar left (kept in list for a while) * Moving * Playing a sound Will add: * Generating particles * Rezzing objects > are luskwood commands and how are they usefull to the rest of the grid? Commands to interface with the Luskwood "gohomer" which allows people on the list to eject/temp ban/etc annoying people without having the land privileges. The point of having it there is making things easier for those people, as typing bizarre names during a coordinated attach at 2 FPS can be quite inconvenient. Not really useful for the rest of the grid, and it's there because I'm one of the people on the list :-) Longer term, this will probably not be normally visible, and have to be enabled somewhere. -------------- 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/20070219/bf184713/attachment.pgp From dani at protozoo.com Mon Feb 19 02:07:08 2007 From: dani at protozoo.com (Daniel Aguilar) Date: Mon Feb 19 02:07:12 2007 Subject: [sldev] Avatar list ready for testing! In-Reply-To: <200702190159.18689.dale@daleglass.net> References: <200702190159.18689.dale@daleglass.net> Message-ID: <1ec616de0702190207r70321515j3991ed42c863e1c0@mail.gmail.com> Hi Dale, maybe you'll find these icons interesting: http://www.famfamfam.com/lab/icons/ Hope it helps, Daniel On 2/19/07, Dale Glass wrote: > > I've got a first release of my avatar list done. Here's what it looks > like: > http://daleglass.net/images/screenshots/avlist6_001.jpg > > Features: > * Shows all avatar the client knows of (roughly render distance) > * Retrieves ages and payment info > * Retrieves TrustNet scores (needs attachment, ask me for one) > * Shows activity (just appeared, moving, left) > * Integrates Luskwood commands > * Can show profiles, IM, place a beacon or mark selected avatars > > Get it here: > http://svn.daleglass.net/secondlife/trunk/ > > Current version is based on the latest FirstLook release, art is in the > repository but libraries aren't. > > I will appreciate feedback of any sort :-) > > Also, I'm looking for icons for the following: > > General: > * Data unknown (got to fetch something, but didn't try yet, because it's > disabled for example) > * Fetching > * Error > > Payment info: > * None > * Filled > * Used > * Charter member (lifetime account obtained during beta) > * Linden > * Special title (people with special info, like Philip Linden who appears > as "El Presidente") > > Activity: > * Just appeared > * Rezzing objects > * Playing sounds > * Generating particles > * Moving > * Just left (people are kept in the list for a while) > > So far I'm using various icons from the client, but the result is less > than > ideal. So I'd appreciate if somebody could point me at some place where I > could find something appropiate, or contribute some :-) > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- Daniel Aguilar -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070219/252af41c/attachment.htm From guidoj at users.sourceforge.net Mon Feb 19 07:46:59 2007 From: guidoj at users.sourceforge.net (Guido) Date: Mon Feb 19 07:47:24 2007 Subject: [sldev] Let xmlrpc-epi use already installedversion of expat. Message-ID: <200702191647.00254.guidoj@users.sourceforge.net> Hi, The attached patch is for those that experience crashes of the SL viewer when logging in at the point where the viewer connects to a region. The viewer crashes (seg faults) inside the local copy expat that comes with xmlrpc-epi. This local copy of expat is several years old and apparently buggy. The patch lets xmlrpc-epi use the already installed version of expat (the SL viewer itself uses expat too!), which fixes the seg faults. - Guido -------------- next part -------------- A non-text attachment was scrubbed... Name: xmlrpc-epi-0.51-expat.patch Type: text/x-diff Size: 1453 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070219/f2aec3fa/xmlrpc-epi-0.51-expat.bin From phoenix at secondlife.com Mon Feb 19 08:16:37 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Feb 19 08:16:42 2007 Subject: [sldev] Let xmlrpc-epi use already installedversion of expat. In-Reply-To: <200702191647.00254.guidoj@users.sourceforge.net> References: <200702191647.00254.guidoj@users.sourceforge.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Patching xmlrpc is already covered on the SL wiki as part of the build instructions. http://wiki.secondlife.com/wiki/Patch_xmlrpc-epi http://wiki.secondlife.com/wiki/Get_source_and_compile On Feb 19, 2007, at 7:46 AM, Guido wrote: > Hi, > > The attached patch is for those that experience crashes of the SL > viewer when > logging in at the point where the viewer connects to a region. The > viewer > crashes (seg faults) inside the local copy expat that comes with > xmlrpc-epi. > This local copy of expat is several years old and apparently buggy. > The patch > lets xmlrpc-epi use the already installed version of expat (the SL > viewer > itself uses expat too!), which fixes the seg faults. > > - Guido > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFF2c1mwJCr4A9g8scRAuPOAJ4i+AthLA7GbTPmG/KlIec63QFNHACggw3L DSEajxrAErXIK8Q2/jwnuh8= =Axg9 -----END PGP SIGNATURE----- From mindtriggerz at gmail.com Mon Feb 19 08:24:42 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Mon Feb 19 08:24:48 2007 Subject: [sldev] Useful in-world services performed by a "headless" client? In-Reply-To: References: Message-ID: Headless clients, AKA bots, are more of the territory of libsecondlife, and would probably be more suitable for the task (as it can use any .NET library with minimal effort) http://libsecondlife.org/ On 2/19/07, Metal Wheaties wrote: > Hi. New to this list. > > Has anyone thought of making a headless version of the SL client software > that a specially made account (avatar name) could use to make a scripted > CLIENT to provide special scripted in-world services? > > For example, an avatar you give textures to (as inventory drop) that could > modify them in some way (e.g., something simple like colorizing them) and > give them back to you. > > There should be no reason why you couldn't add a python scripting engine to > the client to allow one to drop on such a pseudo-avatar - for example - > objects containing python scripts in their inventory. These scripts could > do pretty much ANYTHING you can do with the UI given proper hooks in the > client. > > You could also register such a service as an XML entity to provide services > via the web interfaces from scripted objects in-world as well. > > -- > If you believe you are largely the sum of your experiences, you should > choose experiences that make you who you want to become. > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > -- --Jesse From phoenix at secondlife.com Mon Feb 19 08:36:39 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Feb 19 08:36:46 2007 Subject: [sldev] ELFIO usage? In-Reply-To: <1171686371.30902.15.camel@localhost.localdomain> References: <1171686371.30902.15.camel@localhost.localdomain> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We turn off the crash reporter hook in the open source deploy in viewer.cpp by defining LL_SEND_CRASH_REPORTS as 0 in indra/newview/ viewer.cpp during the source deploy. If you have patches to reduce library dependencies based on conditional compilation or runtime choices, I can integrate that into our source deploy process. Our source deploy process has a simple packaging language to grep and sed the source to set these sorts of things. On Feb 16, 2007, at 8:26 PM, Callum Lerwick wrote: > I am working on packaging slviewer for Fedora. There are a few library > requirements we don't already have packaged. ELFIO is one of them. > Looking through the source, it appears ELFIO is used to produce > backtraces that are supposedly better than standard glibc. > > Presumably this is mainly useful for the crash reporter. Which > leads to > another question, should a downstream client build even have the crash > reporter enabled? Does Linden Lab want to be receiving crash reports > from a non-stock Fedora build? Conversely, does Fedora want to be > sending crash reports to Linden Lab? (At the moment, the crash > reporter > is not being packaged.) > > I'm inclined to just not build in ELFIO usage, and save us a library > dep. Comments? > _______________________________________________ > 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) iD8DBQFF2dIXwJCr4A9g8scRAgQDAKCKdcmb3RyBI0h6nodEYHIC1TL4yQCfRDLM dngVp/kDySFvfq7LkDA2kHI= =sSXm -----END PGP SIGNATURE----- From guidoj at users.sourceforge.net Mon Feb 19 09:36:16 2007 From: guidoj at users.sourceforge.net (Guido) Date: Mon Feb 19 09:36:38 2007 Subject: [sldev] Let xmlrpc-epi use already installedversion of expat. In-Reply-To: References: <200702191647.00254.guidoj@users.sourceforge.net> Message-ID: <200702191836.16161.guidoj@users.sourceforge.net> The proposed method on the wiki changes the sources (while it will build without these changes) and the generated Makefiles (they are not present in the tarball). IMHO that is a bad patch. My patch only changes the input files (Makefile.am and configure.in), so that the configure scipt properly checks for the presence of expat and the Makefiles will be generated correctly. It is still possible to build the samples and test code too. - Guido On Monday 19 February 2007 17:16, Phoenix hit keys in the following order: > Patching xmlrpc is already covered on the SL wiki as part of the > build instructions. > > http://wiki.secondlife.com/wiki/Patch_xmlrpc-epi > http://wiki.secondlife.com/wiki/Get_source_and_compile > > On Feb 19, 2007, at 7:46 AM, Guido wrote: > > Hi, > > > > The attached patch is for those that experience crashes of the SL > > viewer when > > logging in at the point where the viewer connects to a region. The > > viewer > > crashes (seg faults) inside the local copy expat that comes with > > xmlrpc-epi. > > This local copy of expat is several years old and apparently buggy. > > The patch > > lets xmlrpc-epi use the already installed version of expat (the SL > > viewer > > itself uses expat too!), which fixes the seg faults. > > > > - Guido > > From mindtriggerz at gmail.com Mon Feb 19 09:52:17 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Mon Feb 19 09:52:21 2007 Subject: [sldev] Useful in-world services performed by a "headless" client? In-Reply-To: References: Message-ID: There seems to already that kind of framework in the client, under Debug > Recorder, it just may need a little souping up. On 2/19/07, Metal Wheaties wrote: > OK, so what about a HEADFUL client that has scripted capabilities? A user > use this for various repetitive operations - for example a sequence of prim > create/enclosure operations for boxing up a finished product for a builder, > or setting protections properly for sale, etc. > > I agree the services idea is a good use for libsecondlife. I will check > that out too. > > Thanks. > > On 2/19/07, Jesse Nesbitt < mindtriggerz@gmail.com> wrote: > > Headless clients, AKA bots, are more of the territory of > > libsecondlife, and would probably be more suitable for the task (as it > > can use any .NET library with minimal effort) > > http://libsecondlife.org/ > > > > On 2/19/07, Metal Wheaties < metalwheaties@gmail.com> wrote: > > > Hi. New to this list. > > > > > > Has anyone thought of making a headless version of the SL client > software > > > that a specially made account (avatar name) could use to make a scripted > > > CLIENT to provide special scripted in-world services? > > > > > > For example, an avatar you give textures to (as inventory drop) that > could > > > modify them in some way (e.g., something simple like colorizing them) > and > > > give them back to you. > > > > > > There should be no reason why you couldn't add a python scripting engine > to > > > the client to allow one to drop on such a pseudo-avatar - for example - > > > objects containing python scripts in their inventory. These scripts > could > > > do pretty much ANYTHING you can do with the UI given proper hooks in the > > > client. > > > > > > You could also register such a service as an XML entity to provide > services > > > via the web interfaces from scripted objects in-world as well. > > > > > > -- > > > If you believe you are largely the sum of your experiences, you should > > > choose experiences that make you who you want to become. > > > > > > -- > > --Jesse > > > > -- --Jesse From gwardell at gwsystems.co.il Mon Feb 19 10:14:27 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Mon Feb 19 10:14:53 2007 Subject: [sldev] Useful in-world services performed by a "headless" client? In-Reply-To: Message-ID: <00fa01c75451$cb509ad0$a4689943@devgary> Hi, I could wonder if this is a good time to be developing such things; since the grid seems unable to deal with the current workload, adding more robot type workload would seem not to be a good thing. Maybe it would be good to look into ways to offload work from the servers instead? For example; is it really necessary to download the entire inventory if the inventory hasn't changed since logoff?? Or; Is it really necessary to re-download an area, when returning to an area recently visited, if that area hasn't changed? Just my 2 Linden cents. Gary > -----Original Message----- > From: sldev-bounces@lists.secondlife.com > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Jesse Nesbitt > Sent: Mon, February 19, 2007 12:52 PM > To: Metal Wheaties > Cc: Second Life Developer Mailing List > Subject: Re: [sldev] Useful in-world services performed by a > "headless" > client? > > > There seems to already that kind of framework in the client, under > Debug > Recorder, it just may need a little souping up. > > On 2/19/07, Metal Wheaties wrote: > > OK, so what about a HEADFUL client that has scripted > capabilities? A user > > use this for various repetitive operations - for example a > sequence of prim > > create/enclosure operations for boxing up a finished > product for a builder, > > or setting protections properly for sale, etc. > > > > I agree the services idea is a good use for libsecondlife. > I will check > > that out too. > > > > Thanks. > > > > On 2/19/07, Jesse Nesbitt < mindtriggerz@gmail.com> wrote: > > > Headless clients, AKA bots, are more of the territory of > > > libsecondlife, and would probably be more suitable for > the task (as it > > > can use any .NET library with minimal effort) > > > http://libsecondlife.org/ > > > > > > On 2/19/07, Metal Wheaties < metalwheaties@gmail.com> wrote: > > > > Hi. New to this list. > > > > > > > > Has anyone thought of making a headless version of the SL client > > software > > > > that a specially made account (avatar name) could use > to make a scripted > > > > CLIENT to provide special scripted in-world services? > > > > > > > > For example, an avatar you give textures to (as > inventory drop) that > > could > > > > modify them in some way (e.g., something simple like > colorizing them) > > and > > > > give them back to you. > > > > > > > > There should be no reason why you couldn't add a python > scripting engine > > to > > > > the client to allow one to drop on such a pseudo-avatar > - for example - > > > > objects containing python scripts in their inventory. > These scripts > > could > > > > do pretty much ANYTHING you can do with the UI given > proper hooks in the > > > > client. > > > > > > > > You could also register such a service as an XML entity > to provide > > services > > > > via the web interfaces from scripted objects in-world as well. > > > > > > > > -- > > > > If you believe you are largely the sum of your > experiences, you should > > > > choose experiences that make you who you want to become. > > > > > > > > > -- > > > --Jesse > > > > > > > > > > -- > --Jesse > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From mindtriggerz at gmail.com Mon Feb 19 10:27:19 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Mon Feb 19 10:27:22 2007 Subject: [sldev] Useful in-world services performed by a "headless" client? In-Reply-To: <00fa01c75451$cb509ad0$a4689943@devgary> References: <00fa01c75451$cb509ad0$a4689943@devgary> Message-ID: Bots are often more efficient than full clients, because you can choose what to download or not. On 2/19/07, Gary Wardell wrote: > Hi, > > I could wonder if this is a good time to be developing such things; since the grid seems unable to deal with the current workload, > adding more robot type workload would seem not to be a good thing. > > Maybe it would be good to look into ways to offload work from the servers instead? > > For example; is it really necessary to download the entire inventory if the inventory hasn't changed since logoff?? > > Or; Is it really necessary to re-download an area, when returning to an area recently visited, if that area hasn't changed? > > Just my 2 Linden cents. > > Gary > > > -----Original Message----- > > From: sldev-bounces@lists.secondlife.com > > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of Jesse Nesbitt > > Sent: Mon, February 19, 2007 12:52 PM > > To: Metal Wheaties > > Cc: Second Life Developer Mailing List > > Subject: Re: [sldev] Useful in-world services performed by a > > "headless" > > client? > > > > > > There seems to already that kind of framework in the client, under > > Debug > Recorder, it just may need a little souping up. > > > > On 2/19/07, Metal Wheaties wrote: > > > OK, so what about a HEADFUL client that has scripted > > capabilities? A user > > > use this for various repetitive operations - for example a > > sequence of prim > > > create/enclosure operations for boxing up a finished > > product for a builder, > > > or setting protections properly for sale, etc. > > > > > > I agree the services idea is a good use for libsecondlife. > > I will check > > > that out too. > > > > > > Thanks. > > > > > > On 2/19/07, Jesse Nesbitt < mindtriggerz@gmail.com> wrote: > > > > Headless clients, AKA bots, are more of the territory of > > > > libsecondlife, and would probably be more suitable for > > the task (as it > > > > can use any .NET library with minimal effort) > > > > http://libsecondlife.org/ > > > > > > > > On 2/19/07, Metal Wheaties < metalwheaties@gmail.com> wrote: > > > > > Hi. New to this list. > > > > > > > > > > Has anyone thought of making a headless version of the SL client > > > software > > > > > that a specially made account (avatar name) could use > > to make a scripted > > > > > CLIENT to provide special scripted in-world services? > > > > > > > > > > For example, an avatar you give textures to (as > > inventory drop) that > > > could > > > > > modify them in some way (e.g., something simple like > > colorizing them) > > > and > > > > > give them back to you. > > > > > > > > > > There should be no reason why you couldn't add a python > > scripting engine > > > to > > > > > the client to allow one to drop on such a pseudo-avatar > > - for example - > > > > > objects containing python scripts in their inventory. > > These scripts > > > could > > > > > do pretty much ANYTHING you can do with the UI given > > proper hooks in the > > > > > client. > > > > > > > > > > You could also register such a service as an XML entity > > to provide > > > services > > > > > via the web interfaces from scripted objects in-world as well. > > > > > > > > > > -- > > > > > If you believe you are largely the sum of your > > experiences, you should > > > > > choose experiences that make you who you want to become. > > > > > > > > > > > > -- > > > > --Jesse > > > > > > > > > > > > > > > > -- > > --Jesse > > _______________________________________________ > > 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 > -- --Jesse From gwardell at gwsystems.co.il Mon Feb 19 10:35:57 2007 From: gwardell at gwsystems.co.il (Gary Wardell) Date: Mon Feb 19 10:36:18 2007 Subject: [sldev] Useful in-world services performed by a "headless" client? In-Reply-To: Message-ID: <010e01c75454$cc9e2210$a4689943@devgary> And bots, by their very nature, may remain connected longer and one user may have multiple bots... > -----Original Message----- > From: Jesse Nesbitt [mailto:mindtriggerz@gmail.com] > Sent: Mon, February 19, 2007 1:27 PM > To: Gary Wardell > Cc: Second Life Developer Mailing List > Subject: Re: [sldev] Useful in-world services performed by a > "headless" > client? > > > Bots are often more efficient than full clients, because you can > choose what to download or not. > > > On 2/19/07, Gary Wardell wrote: > > Hi, > > > > I could wonder if this is a good time to be developing such > things; since the grid seems unable to deal with the current workload, > > adding more robot type workload would seem not to be a good thing. > > > > Maybe it would be good to look into ways to offload work > from the servers instead? > > > > For example; is it really necessary to download the entire > inventory if the inventory hasn't changed since logoff?? > > > > Or; Is it really necessary to re-download an area, when > returning to an area recently visited, if that area hasn't changed? > > > > Just my 2 Linden cents. > > > > Gary > > > > > -----Original Message----- > > > From: sldev-bounces@lists.secondlife.com > > > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of > Jesse Nesbitt > > > Sent: Mon, February 19, 2007 12:52 PM > > > To: Metal Wheaties > > > Cc: Second Life Developer Mailing List > > > Subject: Re: [sldev] Useful in-world services performed by a > > > "headless" > > > client? > > > > > > > > > There seems to already that kind of framework in the client, under > > > Debug > Recorder, it just may need a little souping up. > > > > > > On 2/19/07, Metal Wheaties wrote: > > > > OK, so what about a HEADFUL client that has scripted > > > capabilities? A user > > > > use this for various repetitive operations - for example a > > > sequence of prim > > > > create/enclosure operations for boxing up a finished > > > product for a builder, > > > > or setting protections properly for sale, etc. > > > > > > > > I agree the services idea is a good use for libsecondlife. > > > I will check > > > > that out too. > > > > > > > > Thanks. > > > > > > > > On 2/19/07, Jesse Nesbitt < mindtriggerz@gmail.com> wrote: > > > > > Headless clients, AKA bots, are more of the territory of > > > > > libsecondlife, and would probably be more suitable for > > > the task (as it > > > > > can use any .NET library with minimal effort) > > > > > http://libsecondlife.org/ > > > > > > > > > > On 2/19/07, Metal Wheaties < metalwheaties@gmail.com> wrote: > > > > > > Hi. New to this list. > > > > > > > > > > > > Has anyone thought of making a headless version of > the SL client > > > > software > > > > > > that a specially made account (avatar name) could use > > > to make a scripted > > > > > > CLIENT to provide special scripted in-world services? > > > > > > > > > > > > For example, an avatar you give textures to (as > > > inventory drop) that > > > > could > > > > > > modify them in some way (e.g., something simple like > > > colorizing them) > > > > and > > > > > > give them back to you. > > > > > > > > > > > > There should be no reason why you couldn't add a python > > > scripting engine > > > > to > > > > > > the client to allow one to drop on such a pseudo-avatar > > > - for example - > > > > > > objects containing python scripts in their inventory. > > > These scripts > > > > could > > > > > > do pretty much ANYTHING you can do with the UI given > > > proper hooks in the > > > > > > client. > > > > > > > > > > > > You could also register such a service as an XML entity > > > to provide > > > > services > > > > > > via the web interfaces from scripted objects > in-world as well. > > > > > > > > > > > > -- > > > > > > If you believe you are largely the sum of your > > > experiences, you should > > > > > > choose experiences that make you who you want to become. > > > > > > > > > > > > > > > -- > > > > > --Jesse > > > > > > > > > > > > > > > > > > > > > > -- > > > --Jesse > > > _______________________________________________ > > > 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 > > > > > -- > --Jesse > From mindtriggerz at gmail.com Mon Feb 19 10:38:56 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Mon Feb 19 10:38:59 2007 Subject: [sldev] Useful in-world services performed by a "headless" client? In-Reply-To: <010e01c75454$cc9e2210$a4689943@devgary> References: <010e01c75454$cc9e2210$a4689943@devgary> Message-ID: But if the bots are not heavily interacting with the database and asset server, they have negligible impact on the health of SL overall On 2/19/07, Gary Wardell wrote: > > And bots, by their very nature, may remain connected longer and one user may have multiple bots... > > > -----Original Message----- > > From: Jesse Nesbitt [mailto:mindtriggerz@gmail.com] > > Sent: Mon, February 19, 2007 1:27 PM > > To: Gary Wardell > > Cc: Second Life Developer Mailing List > > Subject: Re: [sldev] Useful in-world services performed by a > > "headless" > > client? > > > > > > Bots are often more efficient than full clients, because you can > > choose what to download or not. > > > > > > On 2/19/07, Gary Wardell wrote: > > > Hi, > > > > > > I could wonder if this is a good time to be developing such > > things; since the grid seems unable to deal with the current workload, > > > adding more robot type workload would seem not to be a good thing. > > > > > > Maybe it would be good to look into ways to offload work > > from the servers instead? > > > > > > For example; is it really necessary to download the entire > > inventory if the inventory hasn't changed since logoff?? > > > > > > Or; Is it really necessary to re-download an area, when > > returning to an area recently visited, if that area hasn't changed? > > > > > > Just my 2 Linden cents. > > > > > > Gary > > > > > > > -----Original Message----- > > > > From: sldev-bounces@lists.secondlife.com > > > > [mailto:sldev-bounces@lists.secondlife.com]On Behalf Of > > Jesse Nesbitt > > > > Sent: Mon, February 19, 2007 12:52 PM > > > > To: Metal Wheaties > > > > Cc: Second Life Developer Mailing List > > > > Subject: Re: [sldev] Useful in-world services performed by a > > > > "headless" > > > > client? > > > > > > > > > > > > There seems to already that kind of framework in the client, under > > > > Debug > Recorder, it just may need a little souping up. > > > > > > > > On 2/19/07, Metal Wheaties wrote: > > > > > OK, so what about a HEADFUL client that has scripted > > > > capabilities? A user > > > > > use this for various repetitive operations - for example a > > > > sequence of prim > > > > > create/enclosure operations for boxing up a finished > > > > product for a builder, > > > > > or setting protections properly for sale, etc. > > > > > > > > > > I agree the services idea is a good use for libsecondlife. > > > > I will check > > > > > that out too. > > > > > > > > > > Thanks. > > > > > > > > > > On 2/19/07, Jesse Nesbitt < mindtriggerz@gmail.com> wrote: > > > > > > Headless clients, AKA bots, are more of the territory of > > > > > > libsecondlife, and would probably be more suitable for > > > > the task (as it > > > > > > can use any .NET library with minimal effort) > > > > > > http://libsecondlife.org/ > > > > > > > > > > > > On 2/19/07, Metal Wheaties < metalwheaties@gmail.com> wrote: > > > > > > > Hi. New to this list. > > > > > > > > > > > > > > Has anyone thought of making a headless version of > > the SL client > > > > > software > > > > > > > that a specially made account (avatar name) could use > > > > to make a scripted > > > > > > > CLIENT to provide special scripted in-world services? > > > > > > > > > > > > > > For example, an avatar you give textures to (as > > > > inventory drop) that > > > > > could > > > > > > > modify them in some way (e.g., something simple like > > > > colorizing them) > > > > > and > > > > > > > give them back to you. > > > > > > > > > > > > > > There should be no reason why you couldn't add a python > > > > scripting engine > > > > > to > > > > > > > the client to allow one to drop on such a pseudo-avatar > > > > - for example - > > > > > > > objects containing python scripts in their inventory. > > > > These scripts > > > > > could > > > > > > > do pretty much ANYTHING you can do with the UI given > > > > proper hooks in the > > > > > > > client. > > > > > > > > > > > > > > You could also register such a service as an XML entity > > > > to provide > > > > > services > > > > > > > via the web interfaces from scripted objects > > in-world as well. > > > > > > > > > > > > > > -- > > > > > > > If you believe you are largely the sum of your > > > > experiences, you should > > > > > > > choose experiences that make you who you want to become. > > > > > > > > > > > > > > > > > > -- > > > > > > --Jesse > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > --Jesse > > > > _______________________________________________ > > > > 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 > > > > > > > > > -- > > --Jesse > > > > -- --Jesse From phoenix at secondlife.com Mon Feb 19 10:40:45 2007 From: phoenix at secondlife.com (Phoenix) Date: Mon Feb 19 10:41:05 2007 Subject: [sldev] Let xmlrpc-epi use already installedversion of expat. In-Reply-To: <200702191836.16161.guidoj@users.sourceforge.net> References: <200702191647.00254.guidoj@users.sourceforge.net> <200702191836.16161.guidoj@users.sourceforge.net> Message-ID: <6E267362-3A6E-4F34-8601-9910E1F895FB@secondlife.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree that a pre-configure patch is better. The content of the wiki reflects our build process and how we extracted the old and busted expat from xmlrpc-epi. I invite you to post the alternate patch on the wiki since that is the best place to disseminate that information the furthest. On Feb 19, 2007, at 9:36 AM, Guido wrote: > The proposed method on the wiki changes the sources (while it will > build > without these changes) and the generated Makefiles (they are not > present in > the tarball). IMHO that is a bad patch. > > My patch only changes the input files (Makefile.am and > configure.in), so that > the configure scipt properly checks for the presence of expat and the > Makefiles will be generated correctly. It is still possible to > build the > samples and test code too. > > - Guido > > > On Monday 19 February 2007 17:16, Phoenix hit keys in the following > order: >> Patching xmlrpc is already covered on the SL wiki as part of the >> build instructions. >> >> http://wiki.secondlife.com/wiki/Patch_xmlrpc-epi >> http://wiki.secondlife.com/wiki/Get_source_and_compile >> >> On Feb 19, 2007, at 7:46 AM, Guido wrote: >>> Hi, >>> >>> The attached patch is for those that experience crashes of the SL >>> viewer when >>> logging in at the point where the viewer connects to a region. The >>> viewer >>> crashes (seg faults) inside the local copy expat that comes with >>> xmlrpc-epi. >>> This local copy of expat is several years old and apparently buggy. >>> The patch >>> lets xmlrpc-epi use the already installed version of expat (the SL >>> viewer >>> itself uses expat too!), which fixes the seg faults. >>> >>> - Guido >>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFF2e82wJCr4A9g8scRAoB4AJoDJVc/j8+aoc4zxlMPsh3oqq/a6ACfUPcl 4QefW2z9uh6psmbPHw3p8YU= =D/F7 -----END PGP SIGNATURE----- From guidoj at users.sourceforge.net Mon Feb 19 12:20:17 2007 From: guidoj at users.sourceforge.net (Guido) Date: Mon Feb 19 12:20:39 2007 Subject: [sldev] Let xmlrpc-epi use already installedversion of expat. In-Reply-To: <6E267362-3A6E-4F34-8601-9910E1F895FB@secondlife.com> References: <200702191647.00254.guidoj@users.sourceforge.net> <200702191836.16161.guidoj@users.sourceforge.net> <6E267362-3A6E-4F34-8601-9910E1F895FB@secondlife.com> Message-ID: <200702192120.17325.guidoj@users.sourceforge.net> On Monday 19 February 2007 19:40, Phoenix hit keys in the following order: > I invite you to post the alternate patch on the wiki since that is > the best place to disseminate that information the furthest. Done From monkowsk at watson.ibm.com Tue Feb 20 09:57:55 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Feb 20 09:58:08 2007 Subject: [sldev] Avatar list ready for testing! Message-ID: <45DB36A3.60004@watson.ibm.com> On 2/19/07, Dale Glass wrote: > I definitely want it to be a plugin eventually, as when done it'll probably > contain quite a lot of functionality that won't be very newbie-friendly, so I > doubt it'd get integrated into the main client as-is. You might consider adding it to the Debug console (Ctrl-Alt-D). That stuff is not intended for newbies either. Mike From secret.argent at gmail.com Tue Feb 20 12:23:09 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 20 12:23:08 2007 Subject: [sldev] Re: proxies... In-Reply-To: <20070216204545.5104341AF21@stupor.lindenlab.com> References: <20070216204545.5104341AF21@stupor.lindenlab.com> Message-ID: <3AADF96A-6D11-44B1-8436-C067FA21018C@gmail.com> How about a MUCH simpler problem... just supporting HTTP/HTTPS proxies for the internal web browser and (eventually) textures? Has anyone gotten SL to work with curl's and gecko's built-in proxy support? From tateru.nino at gmail.com Tue Feb 20 16:53:33 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue Feb 20 16:53:39 2007 Subject: [sldev] Re: proxies... In-Reply-To: <3AADF96A-6D11-44B1-8436-C067FA21018C@gmail.com> References: <20070216204545.5104341AF21@stupor.lindenlab.com> <3AADF96A-6D11-44B1-8436-C067FA21018C@gmail.com> Message-ID: <45DB980D.8010900@gmail.com> Getting the internal browser to use a proxy is easily handled with a quick tweak to its prefs.js file, though that has to be done by hand. Argent Stonecutter wrote: > How about a MUCH simpler problem... just supporting HTTP/HTTPS proxies > for the internal web browser and (eventually) textures? Has anyone > gotten SL to work with curl's and gecko's built-in proxy support? > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- Tateru Nino http://dwellonit.blogspot.com/ From dale at daleglass.net Tue Feb 20 17:39:17 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 20 17:39:40 2007 Subject: [sldev] Avatar list ready for testing! In-Reply-To: <45DB36A3.60004@watson.ibm.com> References: <45DB36A3.60004@watson.ibm.com> Message-ID: <200702210239.25440.dale@daleglass.net> ? ????????? ?? 20 ??????? 2007 18:57 Mike Monkowski ???????(a): > You might consider adding it to the Debug console (Ctrl-Alt-D). That > stuff is not intended for newbies either. But that's not really the thing. I'm just saying that I consider the full purpose rather too specialized. Like all sorts of interesting functionality that is implemented a plugin in firefox instead of getting stuffed somewhere into about:config. My plan is to basically to add displays of useful information currently not available, but which could be obtained. For example, one thing that is already in the code is logging on the console the owners of sounds who aren't nearby. The intention of that is to help locate people who shoot from far away, while filtering out nearby ones. So my additions to the client can be expected to be around those lines. > > Mike > _______________________________________________ > 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/20070221/8cb701f0/attachment.pgp From david at fries.net Tue Feb 20 20:24:20 2007 From: david at fries.net (David Fries) Date: Tue Feb 20 20:24:36 2007 Subject: [sldev] OpenJPEG decoder update Message-ID: <20070221042420.GA1745@spacedout.fries.net> Francois Devaux has merged changes into OpenJPEG that limits decoding to the main OpenJPEG header. That version of OpenJPEG is currently in their svn repository. A new release of OpenJPEG will follow. The changes that were merged into OpenJPEG require a one line change to my original Second Life viewer patch in VWR-123. I've attached that patch to the bug report already. I'm going to suggest that now is a good time to apply the patches in VWR-123 to the viewer source tree. I've received positive feedback from people who have tried it, and the one Fedora Core RPM source package contained the original patch. The patches in VWR-123 need to be applied in the following order. llimagej2coj_bug_fixes.patch comment_typo.diff LLImageJ2COJ_OPJ_HEADER.patch Note OPJ_limit_tags_for_decode.patch is has been obsoleted by the version in svn. -- David Fries http://fries.net/~david/ (PGP encryption key available) -------------- 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/20070220/659588c6/attachment.pgp From robla at lindenlab.com Wed Feb 21 00:14:40 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Feb 21 00:14:54 2007 Subject: [sldev] First Look 1.13.3.58185 source code available Message-ID: <45DBFF70.8050900@lindenlab.com> Hi all, Source code for the First Look 1.13.3.58185 release is now available: https://wiki.secondlife.com/wiki/Source_downloads Changes are noted in Steve Linden's blog entry: http://blog.secondlife.com/2007/02/20/first-look-render-pipeline-update-58185-available/ 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/20070221/76696480/signature.pgp From monkowsk at watson.ibm.com Wed Feb 21 08:38:32 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Feb 21 08:38:40 2007 Subject: Plugin architecture; was: [sldev] Avatar list ready for testing! In-Reply-To: <200702210239.25440.dale@daleglass.net> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> Message-ID: <45DC7588.2020906@watson.ibm.com> Dale Glass wrote: > But that's not really the thing. I'm just saying that I consider the full > purpose rather too specialized. Like all sorts of interesting functionality > that is implemented a plugin in firefox instead of getting stuffed somewhere > into about:config. OK, I see your point. But maybe you could answer a question I've been trying to figure out concerning the plugin discussion here. I can understand in a browser how plugins can be inserted in the stream of data and act as a filter for specific file types. Would this mean that the SecondLife plugins would be inserted in the message stream between the client and server? Or would they work off of the local cache? Or would they reference a class that had accessors for each of the global variables? Mike From soft at softnoel.org Wed Feb 21 09:05:17 2007 From: soft at softnoel.org (soft@softnoel.org) Date: Wed Feb 21 09:05:19 2007 Subject: [sldev] re: Plugin architecture Message-ID: <38378.69.61.52.98.1172077517.squirrel@webmail.softnoel.org> Mike Monkowski wrote: > I can understand in a browser how plugins can be > inserted in the stream of data and act as a filter > for specific file types. Would this mean that the > SecondLife plugins would be inserted in the message > stream between the client and server? Or would they > work off of the local cache? Or would they > reference a class that had accessors for each of the > global variables? The proposal in the wiki is that the plugins would be dynamically linked libraries that can add callback hooks to existing functions. The plugin would run and then cause an early return, or merely take action before the regular SL code. Please reference this as a starter: http://wiki.secondlife.com/wiki/Plugin_architecture Much is up in the air. A class for accessors hasn't been mentioned except as implicit in the COM suggestion, as COM is usually implemented in a way not assuming a shared memory ABI. Relying on accessors - even with shared memory - is advisable if plugins aren't going to be tied to specific builds of the viewer. The answers to your questions, then, are: "possibly through SL code," "possibly through SL code," and a plain old "possibly." :) Now is a great time for putting suggestions out there. From dale at daleglass.net Wed Feb 21 09:11:07 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Feb 21 09:11:27 2007 Subject: Plugin architecture; was: [sldev] Avatar list ready for testing! In-Reply-To: <45DC7588.2020906@watson.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> Message-ID: <200702211811.12973.dale@daleglass.net> ? ????????? ?? 21 ??????? 2007 17:38 Mike Monkowski ???????(a): > But maybe you could answer a question I've been trying to figure out > concerning the plugin discussion here. I can understand in a browser > how plugins can be inserted in the stream of data and act as a filter > for specific file types. Would this mean that the SecondLife plugins > would be inserted in the message stream between the client and server? Something like that, although considerable work is needed here. For example, take my scanner. It queries the avatar's payment info and birth date. Now, when the reply arrives, the client gets a packet of the AvatarPropertiesReply type. A plugin would have to register itself and say "Hey, I want to know when one of those gets received too". Except that in the current code there can be only one handler per message type, so that will have to be fixed. > Or would they work off of the local cache? Or would they reference a Definitely not, there's not much you could do with that and it'd be ugly too. > class that had accessors for each of the global variables? A bit of everything would be needed. A plugin needs to be able to tell the viewer that it's interested in certain types of packets. It has to be able to access some internal state (avatar list, say). It's got to be able to do things like creating windows, sending commands to the sim, etc. Quite big changes are needed here. > > Mike > > _______________________________________________ > 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/20070221/9332cd1c/attachment.pgp From truxpin at adsl-209-233-23-82.dsl.snfc21.pacbell.net Wed Feb 21 12:25:19 2007 From: truxpin at adsl-209-233-23-82.dsl.snfc21.pacbell.net (truxpin@adsl-209-233-23-82.dsl.snfc21.pacbell.net) Date: Wed Feb 21 12:20:44 2007 Subject: [sldev] compile on ubuntu 6.06? Message-ID: <200702212025.l1LKPJJl009890@adsl-209-233-23-82.dsl.snfc21.pacbell.net> Has anyone tried to compile the linux tarballs on ubuntu 6.06 (dapper drake)? I have been attempting, getting simple and complex errors. FC From jbglaw at lug-owl.de Wed Feb 21 13:37:48 2007 From: jbglaw at lug-owl.de (Jan-Benedict Glaw) Date: Wed Feb 21 13:37:55 2007 Subject: [sldev] compile on ubuntu 6.06? In-Reply-To: <200702212025.l1LKPJJl009890@adsl-209-233-23-82.dsl.snfc21.pacbell.net> References: <200702212025.l1LKPJJl009890@adsl-209-233-23-82.dsl.snfc21.pacbell.net> Message-ID: <20070221213748.GE9712@lug-owl.de> On Wed, 2007-02-21 12:25:19 -0800, truxpin@adsl-209-233-23-82.dsl.snfc21.pacbell.net wrote: > Has anyone tried to compile the linux tarballs on ubuntu 6.06 > (dapper drake)? I have been attempting, getting simple and complex errors. It would certainly help if you'd post the actual error messages you get... MfG, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: The course of history shows that as a government grows, liberty the second : decreases." (Thomas Jefferson) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070221/9a67d066/attachment.pgp From signore at autistiche.org Wed Feb 21 13:52:34 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Wed Feb 21 13:52:42 2007 Subject: [sldev] compile on ubuntu 6.06? In-Reply-To: <200702212025.l1LKPJJl009890@adsl-209-233-23-82.dsl.snfc21.pacbell.net> Message-ID: In data 21/2/2007, "truxpin@adsl-209-233-23-82.dsl.snfc21.pacbell.net" ha scritto: > > Has anyone tried to compile the linux tarballs on ubuntu 6.06 >(dapper drake)? I have been attempting, getting simple and complex errors. I'm on Ubuntu 6.10 (Edgy) and I managed to get the viewer running compiling by sources. I didn't yet manage to produce a tarball for the end-user, though: see https://jira.secondlife.com/browse/VWR-131 . I'm not sure if this is a bug or a fault on my side. Here are the steps I made to set up the build environment and to compile the sources: http://signore.wordpress.com/tag/linux *Maybe* Ubuntu Dapper and Ubuntu Edgy don't differ too much from this point of view, so I think it would be great if you tried to follow the same steps and report here what happens. I also think that if we manage to produce a step-by-step guide for generic ubuntu users we may put it on wiki.secondlife.com. bye Signore Iredell From signore at autistiche.org Wed Feb 21 14:06:06 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Wed Feb 21 14:06:09 2007 Subject: [sldev] Linux client packaged for Ubuntu Dapper / Edgy Message-ID: I just found this: SecondLife Linux Alpha client, packaged for Ubuntu http://au.ubuntu.cafuego.net/dists/edgy-cafuego/secondlife http://au.ubuntu.cafuego.net/dists/dapper-cafuego/secondlife deb packages are for i386 platform only. They provide basic info about SL and installation instructions, so the pages are quite self-explaining. bye, Signore Iredell From tateru.nino at gmail.com Wed Feb 21 14:33:20 2007 From: tateru.nino at gmail.com (Tateru Nino) Date: Wed Feb 21 14:33:26 2007 Subject: Plugin architecture; was: [sldev] Avatar list ready for testing! In-Reply-To: <200702211811.12973.dale@daleglass.net> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> Message-ID: <45DCC8B0.9030709@gmail.com> Hmm. How about this? The plugin subsystem gets a feed of decoded messages forked from the network handlers. It can either use some interest-list/registration system, or just spew messages raw to the plugin and expect each plugin to discard what it is not interested in - as a preliminary measure. Additionally the viewer should be able to inject messages of it's own, destined for the plugin subsystem. This could indeed be done with a socket or local network port. The plugin subsystem in turn can generate messages to be injected asynchronously back into the viewer, either to trigger the viewer itself to take an action (make your own list of local actions and expand as necessary), or to generate a message to return to the grid via the data-stream (more based on what actions the viewer can take via the network protocol). Sure...it's cheap. In its simplest form, its potentially grossly _wasteful_, even. But heck, if you _really_ wanted a cheapass bot, plug a python script, have it tell the viewer to 'stop rendering' (to save all those CPU cycles, same as minimise mode), sit back and let python drive. Potentially, it could be used as a stopgap for exploring just what sort of facilities and layered interfaces you _want_ in a plugin architecture. Dale Glass wrote: > ? ????????? ?? 21 ??????? 2007 17:38 Mike Monkowski ???????(a): > >> But maybe you could answer a question I've been trying to figure out >> concerning the plugin discussion here. I can understand in a browser >> how plugins can be inserted in the stream of data and act as a filter >> for specific file types. Would this mean that the SecondLife plugins >> would be inserted in the message stream between the client and server? >> > Something like that, although considerable work is needed here. For example, > take my scanner. It queries the avatar's payment info and birth date. Now, > when the reply arrives, the client gets a packet of the AvatarPropertiesReply > type. A plugin would have to register itself and say "Hey, I want to know > when one of those gets received too". Except that in the current code there > can be only one handler per message type, so that will have to be fixed. > > >> Or would they work off of the local cache? Or would they reference a >> > Definitely not, there's not much you could do with that and it'd be ugly too. > > >> class that had accessors for each of the global variables? >> > A bit of everything would be needed. A plugin needs to be able to tell the > viewer that it's interested in certain types of packets. It has to be able to > access some internal state (avatar list, say). It's got to be able to do > things like creating windows, sending commands to the sim, etc. Quite big > changes are needed here. > > >> 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 >> -- Tateru Nino http://dwellonit.blogspot.com/ From andrew at lindenlab.com Wed Feb 21 15:23:06 2007 From: andrew at lindenlab.com (Andrew Meadows) Date: Wed Feb 21 15:23:11 2007 Subject: Plugin architecture; was: [sldev] Avatar list ready for testing! In-Reply-To: <45DCC8B0.9030709@gmail.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> Message-ID: <45DCD45A.1050308@lindenlab.com> This reminds me of an idea I had a long time ago for a simple plugin system for 3rd party scripts: use the apache runtime environment (APR) libs to add simple HTTP server capability to the SL client such that it could send and receive XML data (incidentally, the SL simualators already do this on their internal network). Properly formatted XML could trigger the client to execute callbacks that would trigger UI events, send SL packets, or reply back with XML packed data such as: avatar position, inventory contents, or whatever. Once a APR server were embedded in the client then making a quick plugin would be pretty easy. Pick the data stream you're interested, write some callbacks that supply the data on arrival or on request, and send it out through localhost to a "local plugin" or even out the ethernet port to an "external plugin". The plugins could be in any language that supported XML and network packets, and the client code would be OS agnostic. I affectionately call this idea "tank treads" because I was pitching it as a generalized solution to another developer's proposed feature (joystick input) and someone made a comment to the effect: "You're suggesting we build tank treads when all we really need is a bicycle wheel." The biggest disadvantage, as pointed out by one of the other LL developers, is that without some sort of encryption (SSH), unguessable URLs (capabilities), or other security measures this would be a wide open hole for all sorts of exploits. Even if the APR socket is on 127.0.0.1 javascript can trigger packets to localhost, so someone could set up a malicious website that could take some control of any currently running SL client. - Andrew Tateru Nino wrote: > Hmm. How about this? The plugin subsystem gets a feed of decoded > messages forked from the network handlers. It can either use some > interest-list/registration system, or just spew messages raw to the > plugin and expect each plugin to discard what it is not interested in - > as a preliminary measure. Additionally the viewer should be able to > inject messages of it's own, destined for the plugin subsystem. This > could indeed be done with a socket or local network port. > > The plugin subsystem in turn can generate messages to be injected > asynchronously back into the viewer, either to trigger the viewer itself > to take an action (make your own list of local actions and expand as > necessary), or to generate a message to return to the grid via the > data-stream (more based on what actions the viewer can take via the > network protocol). > > Sure...it's cheap. In its simplest form, its potentially grossly > _wasteful_, even. But heck, if you _really_ wanted a cheapass bot, plug > a python script, have it tell the viewer to 'stop rendering' (to save > all those CPU cycles, same as minimise mode), sit back and let python > drive. > > Potentially, it could be used as a stopgap for exploring just what sort > of facilities and layered interfaces you _want_ in a plugin architecture. > > Dale Glass wrote: >> ? ????????? ?? 21 ??????? 2007 17:38 Mike Monkowski ???????(a): >> >>> But maybe you could answer a question I've been trying to figure out >>> concerning the plugin discussion here. I can understand in a browser >>> how plugins can be inserted in the stream of data and act as a filter >>> for specific file types. Would this mean that the SecondLife plugins >>> would be inserted in the message stream between the client and server? >>> >> Something like that, although considerable work is needed here. For >> example, take my scanner. It queries the avatar's payment info and >> birth date. Now, when the reply arrives, the client gets a packet of >> the AvatarPropertiesReply type. A plugin would have to register itself >> and say "Hey, I want to know when one of those gets received too". >> Except that in the current code there can be only one handler per >> message type, so that will have to be fixed. >> >> >>> Or would they work off of the local cache? Or would they reference a >>> >> Definitely not, there's not much you could do with that and it'd be >> ugly too. >> >> >>> class that had accessors for each of the global variables? >>> >> A bit of everything would be needed. A plugin needs to be able to tell >> the viewer that it's interested in certain types of packets. It has to >> be able to access some internal state (avatar list, say). It's got to >> be able to do things like creating windows, sending commands to the >> sim, etc. Quite big changes are needed here. >> >> >>> 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 Wed Feb 21 15:24:28 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed Feb 21 15:24:33 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DCC8B0.9030709@gmail.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> Message-ID: <45DCD4AC.8020201@watson.ibm.com> Tateru Nino wrote: > The plugin subsystem in turn can generate messages to be injected > asynchronously back into the viewer, either to trigger the viewer itself > to take an action (make your own list of local actions and expand as > necessary)... This is what got me confused in the first place because the "list of local actions" would probably have to be expanded to include every method in the code base. And then you may as well just write your function as part of the code base. If the goal is to be able to write routines that do not need to be compiled into the code base, then it should probably be done by expanding the functionality of LSL scripts. If the goal is just to keep the executable file size small (does anybody really care?), then that might be achieved by compiling in a stub that provides direct access to needed data and methods and dynamically links in a library containing the bulk of the functionality if the function is an entry in a customizable user's menu. So what is the reason for having plugins anyway? Mike From dale at daleglass.net Wed Feb 21 16:20:53 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Feb 21 16:21:11 2007 Subject: [sldev] Linking fails with FL-1.13.3.58185 (cannot find llmozlib) Message-ID: <200702220121.00136.dale@daleglass.net> Builds all the way until it tries to link, then fails with: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lllmozlib It does work if disabling mozlib with "#define LL_LIBXUL_ENABLED 0", but I don't think that failed before on Linux. Anybody else had that problem? -------------- 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/20070222/991b8892/attachment.pgp From dale at daleglass.net Wed Feb 21 16:27:03 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Feb 21 16:27:16 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DCD4AC.8020201@watson.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> Message-ID: <200702220127.05008.dale@daleglass.net> ? ????????? ?? 22 ??????? 2007 00:24 Mike Monkowski ???????(a): > If the goal is to be able to write routines that do not need to be > compiled into the code base, then it should probably be done by > expanding the functionality of LSL scripts. LSL scripts will never be able to do some things. Like for example changing how rendering works. Or integrating things like text to speech and voip. > So what is the reason for having plugins anyway? The reason is that OSS developers aren't a company set on one specific target with some sort of management dictating where to go. I want to work on my stuff, somebody else wants to work on something different. People are going to disagree about how something should be done. Also, LL isn't going to integrate most of what people come up with, because it's not well written enough, outside the general scope, distasteful (guess what I'm hinting at here), or too weird to be generally integrated. So, without plugins what we get is: * SL official build * Dale's build * Opensecondlife build * Opensecondlife with X patch * Bob's tweaked client ... and so on. Want my scanner? Run my client. Want voip? Run Bob's. Both at once? Well, if you can't code and somebody doesn't bother to make a client with both, you're out of luck. Not hard to imagine how that situation is less than desirable. -------------- 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/20070222/1edc75ed/attachment-0001.pgp From gigstaggart at gmail.com Wed Feb 21 16:48:57 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Feb 21 16:48:43 2007 Subject: Plugin architecture; was: [sldev] Avatar list ready for testing! In-Reply-To: <45DCD45A.1050308@lindenlab.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> Message-ID: <45DCE879.6030006@gmail.com> Andrew Meadows wrote: > The biggest disadvantage, as pointed out by one of the other LL developers, > is that without some sort of encryption (SSH), unguessable URLs > (capabilities), > or other security measures this would be a wide open hole for all sorts of > exploits. Even if the APR socket is on 127.0.0.1 javascript can trigger > packets to localhost, so someone could set up a malicious website that > could > take some control of any currently running SL client. I don't see that as the biggest disadvantage. XML is a hell of a lot of overhead for something that's local, that you control both ends of, and that is going to potentially be pushing data with high transaction rates and strict latency requirements. That's a huge hit just to be buzzword compliant. As for security, I don't see that as totally intractable. There's already a level of trust required for plugins themselves, so the main concern is an exploit, like JS XMLHTTPRequest like you pointed out. This assumes that we should accept new plugins on the fly, without restarting the client. I'm not sure that's a reasonable design goal. If plugins were totally asynchronous like that, how would you start them when SL started? Or should they sit there as little daemons or services whenever the system is booted, just waiting for SL to start? Plugins only loaded when the client starts would prevent some random exploit from initiating a connection to the running server, since the client would know what connections it was expecting and from what plugins. -Jason From soft at softnoel.org Wed Feb 21 17:55:22 2007 From: soft at softnoel.org (soft@softnoel.org) Date: Wed Feb 21 17:55:24 2007 Subject: Plugin architecture; was: [sldev] Avatar list ready for testing! In-Reply-To: <45DCE879.6030006@gmail.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> Message-ID: <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> > This assumes that we should accept new plugins on the fly, without > restarting the client. I'm not sure that's a reasonable design goal. > If plugins were totally asynchronous like that, how would you start them > when SL started? Or should they sit there as little daemons or services > whenever the system is booted, just waiting for SL to start? Tank treads model aside, accepting/enabling/disabling new plugins without restarting is desirable. It will shorten iteration times for plugin developers. It will enable restarting the viewer in a plugin-free "safe mode" and manually reenabling plugins one at a time after a crash. It will make technologies like self-updating plugins and LL-triggered plugin invalidation possible. It's fair to say a plugin should never be activated on the fly without explicit action by the user, however. From signore at autistiche.org Wed Feb 21 18:11:22 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Wed Feb 21 18:11:29 2007 Subject: [sldev] Linking fails with FL-1.13.3.58185 (cannot find llmozlib) In-Reply-To: <200702220121.00136.dale@daleglass.net> Message-ID: In data 22/2/2007, "Dale Glass" ha scritto: >Builds all the way until it tries to link, then fails with: > >/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: >cannot find -lllmozlib > >It does work if disabling mozlib with "#define LL_LIBXUL_ENABLED 0", >but I don't think that failed before on Linux. > >Anybody else had that problem? I do. It didn't fail before here. Where do you disable mozlib please? bye, signore iredell From dale at daleglass.net Wed Feb 21 18:16:37 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Feb 21 18:17:52 2007 Subject: [sldev] Linking fails with FL-1.13.3.58185 (cannot find llmozlib) In-Reply-To: References: Message-ID: <200702220316.46246.dale@daleglass.net> ? ????????? ?? 22 ??????? 2007 03:11 signore@autistiche.org ???????(a): > I do. It didn't fail before here. Where do you disable mozlib please? > > bye, > signore iredell in indra/llcommon/llpreprocessor.h, line 54 change #define LL_LIBXUL_ENABLED 1 to #define LL_LIBXUL_ENABLED 0 -------------- 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/20070222/0e171a0d/attachment.pgp From dale at daleglass.net Wed Feb 21 19:09:29 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Feb 21 19:09:46 2007 Subject: [sldev] Avatar list updated for FL-1.13.3.58185, builds on Windows Message-ID: <200702220409.38537.dale@daleglass.net> Ok, if anybody wants to give it a try, I finally set up a windows build environment and got it to compile there. Source is here as usual: http://svn.daleglass.net/secondlife/trunk This has windows fixes committed, including all changes needed to build in VS Express 2005 (libraries not in repository) I run it in vmware, so I can't actually start the client, just check that it builds. This version is an initial test with new icons (which aren't perfect yet). On windows it also has a very ugly #ifdef in llfloateravatarlist.cpp that breaks age calculations, as Windows doesn't have strptime. Anybody has any suggestions for a portable replacement? -------------- 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/20070222/9d368b47/attachment.pgp From soft at softnoel.org Wed Feb 21 19:41:47 2007 From: soft at softnoel.org (soft@softnoel.org) Date: Wed Feb 21 19:41:49 2007 Subject: [sldev] Avatar list updated for FL-1.13.3.58185, builds on Windows In-Reply-To: <200702220409.38537.dale@daleglass.net> References: <200702220409.38537.dale@daleglass.net> Message-ID: <45805.64.81.228.9.1172115707.squirrel@webmail.softnoel.org> > Ok, if anybody wants to give it a try, I finally set up a windows build > environment and got it to compile there. Mac users, you're good to go too. Add Dale's indra/newview/llfloateravatarlist.(cpp|h) to macview->Sources->newview in the macview Xcode project, and boom. From sldev at bushing.mm.st Wed Feb 21 20:02:53 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Wed Feb 21 20:02:58 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> Message-ID: <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> On Feb 21, 2007, at 5:55 PM, soft@softnoel.org wrote: >> This assumes that we should accept new plugins on the fly, without >> restarting the client. I'm not sure that's a reasonable design goal. >> If plugins were totally asynchronous like that, how would you >> start them >> when SL started? Or should they sit there as little daemons or >> services >> whenever the system is booted, just waiting for SL to start? > > Tank treads model aside, accepting/enabling/disabling new plugins > without > restarting is desirable. What's a "tank treads model"? > It will shorten iteration times for plugin developers. Agreed. > It will enable restarting the viewer in a plugin-free "safe mode" > and manually reenabling plugins one at a time after a crash. Neither of those features requires the ability to install a new plugin without restarting. > It will make technologies like self-updating plugins [possible] ... nor does this one. Firefox lets you do all of those things, but will only install / uninstall / upgrade after restarting. > [...] and LL-triggered plugin invalidation possible. Whoa. Everyone, raise your hand if you think this is a good idea. -b From jhurliman at wsu.edu Wed Feb 21 21:32:25 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Feb 21 21:32:45 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> Message-ID: <45DD2AE9.8090504@wsu.edu> Ben Byer wrote: >> [...] and LL-triggered plugin invalidation possible. > > Whoa. Everyone, raise your hand if you think this is a good idea. > > -b That's the most plausible idea since DRM! John From soft at softnoel.org Wed Feb 21 23:40:47 2007 From: soft at softnoel.org (Soft Noel) Date: Wed Feb 21 23:40:49 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DD2AE9.8090504@wsu.edu> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <45DD2AE9.8090504@wsu.edu> Message-ID: <48505.64.81.228.9.1172130047.squirrel@webmail.softnoel.org> On Wed, February 21, 2007 9:32 pm, John Hurliman wrote: > Ben Byer wrote: >>> [...] and LL-triggered plugin invalidation possible. >> >> Whoa. Everyone, raise your hand if you think this is a good idea. >> >> -b > > That's the most plausible idea since DRM! Scenario: Non-malicious plugin Foo v0.9 has a design defect causing a hundred users to hammer Userserver with large packets and kill IMs for everyone. LL says "All Foo v0.9, please unload/refrain from loading." I don't begin to pretend that this would be useful for stopping malicious code. Any attacker has the source, can see how the viewer identifies the plugin, and can work around that. From ismail at pardus.org.tr Thu Feb 22 01:16:50 2007 From: ismail at pardus.org.tr (Ismail =?utf-8?q?D=C3=B6nmez?=) Date: Thu Feb 22 01:16:58 2007 Subject: [sldev] Login problems FirstLook Viewer Message-ID: <200702221116.50753.ismail@pardus.org.tr> Hi all, I built FL-1.13.3.58185 from source but I can't login to any grid, all says login or password is incorrect but I can login from web just fine. Anyone experiencing the same problem? Regards, ismail -- FFmpeg doxy @ http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs From carnildo at gmail.com Thu Feb 22 01:19:58 2007 From: carnildo at gmail.com (Mark Wagner) Date: Thu Feb 22 01:20:00 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> Message-ID: <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> On 2/21/07, Ben Byer wrote: > On Feb 21, 2007, at 5:55 PM, soft@softnoel.org wrote: > > > [...] and LL-triggered plugin invalidation possible. > > Whoa. Everyone, raise your hand if you think this is a good idea. Certainly. Particularly once the server code is open-sourced, it would be nice for a server to be able to say that certain plugins can't be used with it - say, an av scanner in a combat sim. -- Mark Carnildo Greenacre From sldev at bushing.mm.st Thu Feb 22 01:23:21 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Thu Feb 22 01:23:25 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <48505.64.81.228.9.1172130047.squirrel@webmail.softnoel.org> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <45DD2AE9.8090504@wsu.edu> <48505.64.81.228.9.1172130047.squirrel@webmail.softnoel.org> Message-ID: <5DAA708C-39D6-405E-994D-E89FECBBF514@bushing.mm.st> On Feb 21, 2007, at 11:40 PM, Soft Noel wrote: > On Wed, February 21, 2007 9:32 pm, John Hurliman wrote: >> Ben Byer wrote: >>>> [...] and LL-triggered plugin invalidation possible. >>> >>> Whoa. Everyone, raise your hand if you think this is a good idea. >>> >>> -b >> >> That's the most plausible idea since DRM! > > Scenario: Non-malicious plugin Foo v0.9 has a design defect causing a > hundred users to hammer Userserver with large packets and kill IMs for > everyone. LL says "All Foo v0.9, please unload/refrain from loading." Scenario: I find a bug in your remote-kill-switch and use it to turn off your plugins, randomly, as a fun joke. Ha ha! (Can you name any software, at all, that has similar functionality?) Alternate solution to above scenario: LL notices excessive load on server and starts scrutinizing server stats. Noticing a increase in network traffic, they somehow manage to divine that it's being caused by "large packets". They run a packet sniffer, see that these large packets are IMs, and probably deduce that they are being automatically sent. Somehow they figure out that it is a plugin, and which plugin it is, and which users are causing problems. They then A. send out the "All Foo v0.9 die die die" message, or B. temp-ban those users with a "reason message" of "You have a plugin that is malfunctioning and disrupting our service; please uninstall it." Hell, you could just point them at a "special" TOS. Then, they could go find the coder that isn't bounds-checking packets, slap him/ her on the wrists, and we could all be on our merry way. I'm noticing a trend here. Plugin systems are difficult to design in new products; they're even more difficult to integrate into large, complicated, multiplatform code bases with a wide range of users with a wide range of needs. We have an abundance of people who want to help influence the plugin system, and a dearth of people who are in a position to actually write code to make it happen. Instead, it seems like people are dredging up unlikely hypotheticals just to have something to talk about :( From sldev at bushing.mm.st Thu Feb 22 01:24:47 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Thu Feb 22 01:24:51 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> Message-ID: <193CE84E-BE5B-4C9D-A31F-F267B1D1B852@bushing.mm.st> On Feb 22, 2007, at 1:19 AM, Mark Wagner wrote: > On 2/21/07, Ben Byer wrote: >> On Feb 21, 2007, at 5:55 PM, soft@softnoel.org wrote: >> >> > [...] and LL-triggered plugin invalidation possible. >> >> Whoa. Everyone, raise your hand if you think this is a good idea. > > Certainly. Particularly once the server code is open-sourced, it > would be nice for a server to be able to say that certain plugins > can't be used with it - say, an av scanner in a combat sim. Why? To prevent cheating? If someone wants to cheat, they will change the name of the plugin to avoid the plugin ban. -b From ismail at pardus.org.tr Thu Feb 22 02:07:08 2007 From: ismail at pardus.org.tr (Ismail =?utf-8?q?D=C3=B6nmez?=) Date: Thu Feb 22 02:07:13 2007 Subject: [sldev] Login problems FirstLook Viewer In-Reply-To: <200702221116.50753.ismail@pardus.org.tr> References: <200702221116.50753.ismail@pardus.org.tr> Message-ID: <200702221207.08823.ismail@pardus.org.tr> On Thursday 22 February 2007 11:16:50 Ismail D?nmez wrote: > Hi all, > > I built FL-1.13.3.58185 from source but I can't login to any grid, all says > login or password is incorrect but I can login from web just fine. Anyone > experiencing the same problem? Never mind, it was a local problem. /ismail -- FFmpeg doxy @ http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs From tofu.linden at lindenlab.com Thu Feb 22 02:36:31 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Feb 22 02:35:51 2007 Subject: llmozlib (was: Re: [sldev] Linking fails with FL-1.13.3.58185 (cannot find llmozlib)) In-Reply-To: <200702220121.00136.dale@daleglass.net> References: <200702220121.00136.dale@daleglass.net> Message-ID: <45DD722F.3090409@lindenlab.com> Dale Glass wrote: > Builds all the way until it tries to link, then fails with: > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: > cannot find -lllmozlib > > It does work if disabling mozlib with "#define LL_LIBXUL_ENABLED 0", > but I don't think that failed before on Linux. > > Anybody else had that problem? Thanks for pointing that out - I've fixed the manifest so that the right libs are exported to the source release bundle. For those wondering where to get the source for llmozlib (which wraps a GL-embeddable patched Mozilla in a comfortable way), this has been open source for quite a long time at: http://ubrowser.com/ I need to poke Callum to issue a newer llmozlib source release with the new Linux port included - I'll post to this list to let people know when this happens. Meanwhile, playing with LL_LIBXUL_ENABLED and removing the moz libs from the SConstruct linkline is currently a safe option. - Tofu From tofu.linden at lindenlab.com Thu Feb 22 02:42:13 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Thu Feb 22 02:41:32 2007 Subject: [sldev] Let xmlrpc-epi use already installedversion of expat. In-Reply-To: <6E267362-3A6E-4F34-8601-9910E1F895FB@secondlife.com> References: <200702191647.00254.guidoj@users.sourceforge.net> <200702191836.16161.guidoj@users.sourceforge.net> <6E267362-3A6E-4F34-8601-9910E1F895FB@secondlife.com> Message-ID: <45DD7385.8030105@lindenlab.com> If I remember correctly, what we do for the Linden Linux client build is simply link against the *static* libxmlrpc.a which thankfully doesn't have a broken libexpat sucked inside it. - Tofu Phoenix wrote: > I agree that a pre-configure patch is better. The content of the wiki > reflects our build process and how we extracted the old and busted expat > from xmlrpc-epi. > > I invite you to post the alternate patch on the wiki since that is the > best place to disseminate that information the furthest. > > > > On Feb 19, 2007, at 9:36 AM, Guido wrote: >>> The proposed method on the wiki changes the sources (while it will build >>> without these changes) and the generated Makefiles (they are not >>> present in >>> the tarball). IMHO that is a bad patch. >>> >>> My patch only changes the input files (Makefile.am and configure.in), >>> so that >>> the configure scipt properly checks for the presence of expat and the >>> Makefiles will be generated correctly. It is still possible to build the >>> samples and test code too. >>> >>> - Guido >>> >>> >>> On Monday 19 February 2007 17:16, Phoenix hit keys in the following >>> order: >>>> Patching xmlrpc is already covered on the SL wiki as part of the >>>> build instructions. >>>> >>>> http://wiki.secondlife.com/wiki/Patch_xmlrpc-epi >>>> http://wiki.secondlife.com/wiki/Get_source_and_compile >>>> >>>> On Feb 19, 2007, at 7:46 AM, Guido wrote: >>>>> Hi, >>>>> >>>>> The attached patch is for those that experience crashes of the SL >>>>> viewer when >>>>> logging in at the point where the viewer connects to a region. The >>>>> viewer >>>>> crashes (seg faults) inside the local copy expat that comes with >>>>> xmlrpc-epi. >>>>> This local copy of expat is several years old and apparently buggy. >>>>> The patch >>>>> lets xmlrpc-epi use the already installed version of expat (the SL >>>>> viewer >>>>> itself uses expat too!), which fixes the seg faults. >>>>> >>>>> - Guido >>>>> > _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From baba at libsecondlife.org Thu Feb 22 03:05:00 2007 From: baba at libsecondlife.org (Baba) Date: Thu Feb 22 03:05:10 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <193CE84E-BE5B-4C9D-A31F-F267B1D1B852@bushing.mm.st> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> <193CE84E-BE5B-4C9D-A31F-F267B1D1B852@bushing.mm.st> Message-ID: <45DD78DC.6050509@libsecondlife.org> Ben Byer wrote: > > On Feb 22, 2007, at 1:19 AM, Mark Wagner wrote: > >> On 2/21/07, Ben Byer wrote: >>> On Feb 21, 2007, at 5:55 PM, soft@softnoel.org wrote: >>> >>> > [...] and LL-triggered plugin invalidation possible. >>> >>> Whoa. Everyone, raise your hand if you think this is a good idea. >> >> Certainly. Particularly once the server code is open-sourced, it >> would be nice for a server to be able to say that certain plugins >> can't be used with it - say, an av scanner in a combat sim. > > Why? To prevent cheating? If someone wants to cheat, they will > change the name of the plugin to avoid the plugin ban. > -b Punkbuster for SL! RIGHT ON! ;0 Baba From hud at zurich.ibm.com Thu Feb 22 06:37:03 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Feb 22 06:37:11 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <48505.64.81.228.9.1172130047.squirrel@webmail.softnoel.org> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <45DD2AE9.8090504@wsu.edu> <48505.64.81.228.9.1172130047.squirrel@webmail.softnoel.org> Message-ID: <45DDAA8F.7040902@zurich.ibm.com> Soft Noel wrote: > On Wed, February 21, 2007 9:32 pm, John Hurliman wrote: > >> Ben Byer wrote: >> >>>> [...] and LL-triggered plugin invalidation possible. >>>> >>> Whoa. Everyone, raise your hand if you think this is a good idea. >>> >>> -b >>> >> That's the most plausible idea since DRM! >> > > Scenario: Non-malicious plugin Foo v0.9 has a design defect causing a > hundred users to hammer Userserver with large packets and kill IMs for > everyone. LL says "All Foo v0.9, please unload/refrain from loading." > > I don't begin to pretend that this would be useful for stopping malicious > code. Any attacker has the source, can see how the viewer identifies the > plugin, and can work around that. > hmm...first they need to find out that it's Foo-0.9...i'd think it would make more sense to just send a message to the secondlife client informing the user that his client is going to be throttled. protect the servers...don't rely on clients to follow instructions (especially with OSS'd clients). cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070222/1d48d2cb/signature.pgp From hud at zurich.ibm.com Thu Feb 22 06:37:47 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Feb 22 06:37:51 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> Message-ID: <45DDAABB.2050908@zurich.ibm.com> Mark Wagner wrote: > On 2/21/07, Ben Byer wrote: >> On Feb 21, 2007, at 5:55 PM, soft@softnoel.org wrote: >> >> > [...] and LL-triggered plugin invalidation possible. >> >> Whoa. Everyone, raise your hand if you think this is a good idea. > > Certainly. Particularly once the server code is open-sourced, it > would be nice for a server to be able to say that certain plugins > can't be used with it - say, an av scanner in a combat sim. what exactly prevents me from running a client that just ignores this? cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070222/286d55a6/signature.pgp From mindtriggerz at gmail.com Thu Feb 22 06:39:56 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Thu Feb 22 06:39:59 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DDAABB.2050908@zurich.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> <45DDAABB.2050908@zurich.ibm.com> Message-ID: It's a throttle, and as such it's server side. On 2/22/07, dirk husemann wrote: > Mark Wagner wrote: > > On 2/21/07, Ben Byer wrote: > >> On Feb 21, 2007, at 5:55 PM, soft@softnoel.org wrote: > >> > >> > [...] and LL-triggered plugin invalidation possible. > >> > >> Whoa. Everyone, raise your hand if you think this is a good idea. > > > > Certainly. Particularly once the server code is open-sourced, it > > would be nice for a server to be able to say that certain plugins > > can't be used with it - say, an av scanner in a combat sim. > what exactly prevents me from running a client that just ignores this? > > cheers, > dirk > > > > -- > dr dirk husemann, pervasive computing, ibm zurich research lab > --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > -- --Jesse From hud at zurich.ibm.com Thu Feb 22 06:41:14 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Feb 22 06:41:19 2007 Subject: Plugin architecture; was: [sldev] Avatar list ready for testing! In-Reply-To: <45DCE879.6030006@gmail.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> Message-ID: <45DDAB8A.7010107@zurich.ibm.com> Jason Giglio wrote: > > Andrew Meadows wrote: > >> >> The biggest disadvantage, as pointed out by one of the other LL >> >> developers, >> >> is that without some sort of encryption (SSH), unguessable URLs >> >> (capabilities), >> >> or other security measures this would be a wide open hole for all >> >> sorts of >> >> exploits. Even if the APR socket is on 127.0.0.1 javascript can trigger >> >> packets to localhost, so someone could set up a malicious website >> >> that could >> >> take some control of any currently running SL client. >> > > > > I don't see that as the biggest disadvantage. XML is a hell of a lot > > of overhead for something that's local, that you control both ends of, > > and that is going to potentially be pushing data with high transaction > > rates and strict latency requirements. That's a huge hit just to be > > buzzword compliant. > i like the idea of having a localhost TCP interface through which plugins can asynchronously inject /receive pakets. i have my doubts as well with regards to XML, but on the other hand, if we keep string based (instead of going binary) you could have a shell script implement a plugin! [...] > > This assumes that we should accept new plugins on the fly, without > > restarting the client. I'm not sure that's a reasonable design goal. > > If plugins were totally asynchronous like that, how would you start > > them when SL started? Or should they sit there as little daemons or > > services whenever the system is booted, just waiting for SL to start? > how about having a plugin starter in the client (in the worst case that could be done as a shell script prelude to starting the client itself) that goes through a .secondlife/plugin.d directory and starts all plugins in that directory in alphabetical order (00-plugin-1, 05-plugin-2, ...). on shutdown the client will just send a "GOOD NIGHT" message out over the socket interface --- causing the plugins to shutdown. you could even make the port number random: the client (or prelude script) picks a random available port number, passes that in to the secondlife client, and also as a startup argument to the plugins. add a randomized password (generated anew for each SL session) and pass that in to the client and plugins and it becomes rather difficult to run an JS XMLHTTPRequest attack... cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070222/f369edec/signature.pgp From hud at zurich.ibm.com Thu Feb 22 06:41:57 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Feb 22 06:42:01 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: References: <45DB36A3.60004@watson.ibm.com> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> <45DDAABB.2050908@zurich.ibm.com> Message-ID: <45DDABB5.7060000@zurich.ibm.com> Jesse Nesbitt wrote: > It's a throttle, and as such it's server side. > exactly. it has to be. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070222/3369929f/signature.pgp From hud at zurich.ibm.com Thu Feb 22 06:43:53 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Feb 22 06:43:57 2007 Subject: Plugin architecture; was: [sldev] Avatar list ready for testing! In-Reply-To: <45DDAB8A.7010107@zurich.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <45DDAB8A.7010107@zurich.ibm.com> Message-ID: <45DDAC29.6060808@zurich.ibm.com> dirk husemann wrote: > [...] > > you could even make the port number random: the client (or prelude > script) picks a random available port number, passes that in to the > secondlife client, and also as a startup argument to the plugins. add a > randomized password (generated anew for each SL session) and pass that > in to the client and plugins and it becomes rather difficult to run an > JS XMLHTTPRequest attack... > and you could even write that information out to a .secondlife/plugin-socket file (if you wanted to) and then start additional plugins after client startup! cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070222/dde089c4/signature.pgp From jhurliman at wsu.edu Thu Feb 22 06:46:15 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Feb 22 06:46:25 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: References: <45DB36A3.60004@watson.ibm.com> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> <45DDAABB.2050908@zurich.ibm.com> Message-ID: <45DDACB7.3000304@wsu.edu> The original post on plugin invalidation was talking about runtime loading/unloading of plugins and had nothing to do with throttling or server-side code, I think you might have got sub-threads crossed. The mention of a server-side throttle was made by the same person you are responding to. Jesse Nesbitt wrote: > It's a throttle, and as such it's server side. > > On 2/22/07, dirk husemann wrote: >> Mark Wagner wrote: >> > On 2/21/07, Ben Byer wrote: >> >> On Feb 21, 2007, at 5:55 PM, soft@softnoel.org wrote: >> >> >> >> > [...] and LL-triggered plugin invalidation possible. >> >> >> >> Whoa. Everyone, raise your hand if you think this is a good idea. >> > >> > Certainly. Particularly once the server code is open-sourced, it >> > would be nice for a server to be able to say that certain plugins >> > can't be used with it - say, an av scanner in a combat sim. >> what exactly prevents me from running a client that just ignores this? >> >> cheers, >> dirk >> >> > > From secret.argent at gmail.com Thu Feb 22 06:50:17 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu Feb 22 06:50:12 2007 Subject: [sldev] Plugin API In-Reply-To: <20070221200006.3FC9541AFE4@stupor.lindenlab.com> References: <20070221200006.3FC9541AFE4@stupor.lindenlab.com> Message-ID: [also in the discussion section on the wiki] I don't like the idea of anonymous pointers for parameter passing. I think that some kind of parameter list is essential. typedef struct { int sl_param_id; // Defined in the particular function's API enum { SL_INT32, SL_INT64, SL_FLOAT32, SL_FLOAT64, SL_STRING, SL_ALLOCED_STRING, ... } sl_type; // Plugin may ignore parameters int sl_required; // If set, plugin MUST handle this parameter int sl_changed; // Zero before any plugin called, non-zero if any plugin has changed it int64_t sl_value; // If the type is only 32 bits long, high 32 bits must be zero. } sl_param; typedef enum { SL_OK, SL_INCOMPATIBLE, SL_ERROR, SL_BREAK } sl_result; sl_result sl_plugin(int count, sl_param params[], sl_param *error_info); The function calling the plugin can have all these set in a static structure, and only needs to zero out the sl_changed parameters and set up the initial values. Plugins do not call plugins, the list of plugins for the function are called sequentially by the sl_handle_plugins routine. if(my_plugins != NULL) { my_params[0].sl_changed = 0; my_params[0].sl_value = whatever; final_result = sl_handle_plugins(my_plugins, 1, my_params, &error_param); if(final_result == SL_BREAK) return success; if(final_result == SL_ERROR) { panic(error_param); return failure; } } The plugin must at a minimum: * verify that the sl_param_id values are what it expects and handle (even if by ignoring) the wrong values * handle (even if by ignoring the parameter) the "wrong" types * return SL_INCOMPATIBLE if any of the parameters it's ignoring have sl_required set. * set sl_changed for any parameters it's changed * fill in error_info if it returns SL_ERROR * free an SL_ALLOCED_STRING if it changes the string * make sure that the type of a string parameter is SL_ALLOCED_STRING or SL_STRING to let the caller or later plugins know how to deal with them The plugin may: * Handle changes to the order of parameters as indicated by sl_param_id * Handle changes to the types of parameters as indicated by sl_type * Behave differently if a previous plugin has changed a parameter Return values: * SL_OK - Normal return, go on to the next plugin * SL_INCOMPATIBLE - This plugin no longer works with this call. Let the user know and don't call this plugin again. * SL_ERROR - This plugin has detected an error sufficiently severe that this call must abort. Should be rare. o error_info must be set to { original_param_id, SL_STRING or SL_ALLOCED_STRING, TRUE, TRUE, error_message }. * SL_BREAK - Don't call any further plugins, don't run the rest of the function, the plugin has completely handled the call. From hud at zurich.ibm.com Thu Feb 22 07:53:20 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Feb 22 07:53:24 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DDACB7.3000304@wsu.edu> References: <45DB36A3.60004@watson.ibm.com> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> <45DDAABB.2050908@zurich.ibm.com> <45DDACB7.3000304@wsu.edu> Message-ID: <45DDBC70.6000209@zurich.ibm.com> John Hurliman wrote: > The original post on plugin invalidation was talking about runtime > loading/unloading of plugins and had nothing to do with throttling or > server-side code, I think you might have got sub-threads crossed. The > mention of a server-side throttle was made by the same person you are > responding to. yes and no. as far as i understood the "plugin invalidation" idea, it's purpose was to protect against broken plugin/rogue plugins that would cause pain on the grid --- for that it's better not to rely on properly functioning clients but instead have proper protections on the servers (i.e., protect by throttling the client link and signalling that to the user). -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070222/29a72abd/signature.pgp From plevexier at bellsouth.net Thu Feb 22 08:12:08 2007 From: plevexier at bellsouth.net (plevexier@bellsouth.net) Date: Thu Feb 22 08:12:13 2007 Subject: [sldev] mono embedded on SL client Message-ID: <20070222161208.LURX407.ibm61aec.bellsouth.net@mail.bellsouth.net> Hello All, Is someone working on embedding mono on the SL client in the list? Thanks, Patrice From jhurliman at wsu.edu Thu Feb 22 08:12:59 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Thu Feb 22 08:13:12 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DDBC70.6000209@zurich.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> <45DDAABB.2050908@zurich.ibm.com> <45DDACB7.3000304@wsu.edu> <45DDBC70.6000209@zurich.ibm.com> Message-ID: <45DDC10B.30607@wsu.edu> dirk husemann wrote: > John Hurliman wrote: > >> The original post on plugin invalidation was talking about runtime >> loading/unloading of plugins and had nothing to do with throttling or >> server-side code, I think you might have got sub-threads crossed. The >> mention of a server-side throttle was made by the same person you are >> responding to. >> > yes and no. as far as i understood the "plugin invalidation" idea, it's > purpose was to protect against broken plugin/rogue plugins that would > cause pain on the grid --- for that it's better not to rely on properly > functioning clients but instead have proper protections on the servers > (i.e., protect by throttling the client link and signalling that to the > user). > > I agree, but I'm not sure what server throttling has to do with plugin invalidation. If a client is flooding data it doesn't matter if it's coming from a plugin, a modified opensl, a libsecondlife client, etc, the idea is to throttle against the flood. The example that was given earlier was an IM flood which is fitting because two weeks ago or so I was working on a libsecondlife bot that would auto-respond to IMs. There was a race condition with people logging off before the reply IM got to them, and the grid would reply back with an IM that says that person is offline (shows up as a normal IM but from UUID NULL_KEY if I recall). The bot would blindly auto-respond to NULL_KEY which triggered another message from NULL_KEY, and things got caught in an infinite loop which managed to send tens, maybe hundreds of thousands of IMs to no one in a very short amount of time. This brought the sim dilation down to 0.05 and would eventually crash the sim. Even after bringing a Linden in no one could figure out what was going on other than a lot of traffic was coming from the client. Randomly one day we decided to turn IM forwarding to e-mail on for the bot and as soon as e-mail flood started coming in it was easy to figure out what was happening and fix it. I guess the moral of the story is that intelligent server throttling is good, proper logging mechanisms are better, and writing code that doesn't crash simulators is a good idea too. John From babbage at lindenlab.com Thu Feb 22 08:18:33 2007 From: babbage at lindenlab.com (Jim Purbrick) Date: Thu Feb 22 08:18:57 2007 Subject: [sldev] mono embedded on SL client In-Reply-To: <20070222161208.LURX407.ibm61aec.bellsouth.net@mail.bellsouth.net> References: <20070222161208.LURX407.ibm61aec.bellsouth.net@mail.bellsouth.net> Message-ID: <23B25F5A-761F-43AE-92E1-B7FF6945E79C@lindenlab.com> It's on my (very long) TODO list (somewhere near the end) Cheers, Jim/Babbage On 22 Feb 2007, at 16:12, wrote: > Hello All, > > Is someone working on embedding mono on the SL client in the list? > > Thanks, > > Patrice > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From mindtriggerz at gmail.com Thu Feb 22 09:21:01 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Thu Feb 22 09:21:04 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DDACB7.3000304@wsu.edu> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <44619.64.81.228.9.1172109322.squirrel@webmail.softnoel.org> <3BE54880-1CF8-4684-BF67-0293F332DCAA@bushing.mm.st> <31073ef90702220119i56811bf3ndb603e42d0addef1@mail.gmail.com> <45DDAABB.2050908@zurich.ibm.com> <45DDACB7.3000304@wsu.edu> Message-ID: I did in fact get my threads crossed >.< Sorry! As I see it, it's a courtesy feature, and the plugin could be re-enabled by the user after it was automatically unloaded, but most people care about the grid :P On 2/22/07, John Hurliman wrote: > The original post on plugin invalidation was talking about runtime > loading/unloading of plugins and had nothing to do with throttling or > server-side code, I think you might have got sub-threads crossed. The > mention of a server-side throttle was made by the same person you are > responding to. > > Jesse Nesbitt wrote: > > It's a throttle, and as such it's server side. > > > > On 2/22/07, dirk husemann wrote: > >> Mark Wagner wrote: > >> > On 2/21/07, Ben Byer wrote: > >> >> On Feb 21, 2007, at 5:55 PM, soft@softnoel.org wrote: > >> >> > >> >> > [...] and LL-triggered plugin invalidation possible. > >> >> > >> >> Whoa. Everyone, raise your hand if you think this is a good idea. > >> > > >> > Certainly. Particularly once the server code is open-sourced, it > >> > would be nice for a server to be able to say that certain plugins > >> > can't be used with it - say, an av scanner in a combat sim. > >> what exactly prevents me from running a client that just ignores this? > >> > >> cheers, > >> dirk > >> > >> > > > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- --Jesse From hud at zurich.ibm.com Thu Feb 22 09:27:21 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Feb 22 09:27:28 2007 Subject: Plugin architecture; was: [sldev] Avatar list ready for testing! In-Reply-To: <45DDAB8A.7010107@zurich.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <45DDAB8A.7010107@zurich.ibm.com> Message-ID: <45DDD279.1050602@zurich.ibm.com> dirk husemann wrote: [...] i've added a page to the wiki describing the approach: https://wiki.secondlife.com/wiki/Plugin_Separate_Process feel free to change... cheers, dirk -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070222/3b8d27a2/signature.pgp From monkowsk at watson.ibm.com Thu Feb 22 11:55:24 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Feb 22 11:55:31 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <200702220127.05008.dale@daleglass.net> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> Message-ID: <45DDF52C.8090907@watson.ibm.com> Dale Glass wrote: > LSL scripts will never be able to do some things. Like for example changing > how rendering works. Or integrating things like text to speech and voip. The reason I asked about plugins is because I'm trying to figure out how to implement lip-sync. After looking at the code and reading the replies in this forum, I can't see how a plugin could ever work for lip-sync. I can't see rendering being done in a plugin either. TTS probably could because TTS can get text from the message stream and add to the audio stream. It seems to me that plugins must have limited capabilities based on limited access to data. LSL operates on objects, so it would make sense that if you want to operate on objects in a way that's currently not possible, extend LSL. If you want to operate on the message stream, then use a message stream plugin. I could imagine audio plugins and access to floaters that you could fill with whatever content you like, but I can't imagine access to all of the internal data from a plugin. Mike From sldev at bushing.mm.st Thu Feb 22 12:30:23 2007 From: sldev at bushing.mm.st (Ben Byer) Date: Thu Feb 22 12:30:30 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DDD279.1050602@zurich.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <45DDAB8A.7010107@zurich.ibm.com> <45DDD279.1050602@zurich.ibm.com> Message-ID: <9F635A99-F638-4851-8D1F-86EFBAC98525@bushing.mm.st> On Feb 22, 2007, at 9:27 AM, dirk husemann wrote: > dirk husemann wrote: > > [...] > > i've added a page to the wiki describing the approach: > https://wiki.secondlife.com/wiki/Plugin_Separate_Process Why not just use SLProxy? -b From dale at daleglass.net Thu Feb 22 12:55:59 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Feb 22 12:56:31 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DDF52C.8090907@watson.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> Message-ID: <200702222156.07839.dale@daleglass.net> ? ????????? ?? 22 ??????? 2007 20:55 Mike Monkowski ???????(a): > Dale Glass wrote: > > LSL scripts will never be able to do some things. Like for example > > changing how rendering works. Or integrating things like text to speech > > and voip. > > The reason I asked about plugins is because I'm trying to figure out how > to implement lip-sync. After looking at the code and reading the > replies in this forum, I can't see how a plugin could ever work for > lip-sync. I can't see rendering being done in a plugin either. TTS Why not? Both things are perfectly doable. Not sure of what exactly you mean by "lip sync" (I'm guessing making the in-world avatar move the lips in sync with the RL person, by analyzing speech, webcam video or whatever), but there's nothing that'd prevent it being in a plugin. Rendering is more complex because it'd require quite a lot of reorganization, but it's doable as well. In fact it's nothing very strange, as there are games that let you choose between an OpenGL and a Direct3D renderer. 3D programs like 3D Studio Max allow that as well. > probably could because TTS can get text from the message stream and add > to the audio stream. TTS is trivial (to integrate, not the TTS technology itself), even without modifications to the client at all. All you have to do is to make a program that watches the chat logs, and pipes the new lines to an external TTS program. > > It seems to me that plugins must have limited capabilities based on > limited access to data. That "must" is rather doubtful. Yes, that's the ideal situation, but it's very complex. For now you should assume that a plugin can do whatever it pleases, including reformatting your disk, and indeed, an implementation based on loadable libraries like people are discussing will result in exactly that. Doing safe plugins is a very difficult problem if you want them to be able to do anything interesting. For example, said TTS plugin could take the text it processes, and secretly IM copies to an account, effectively eavesdropping on all you say. There are many potential issues like that that will be very hard to solve. > > LSL operates on objects, so it would make sense that if you want to what objects? There are no objects in LSL > operate on objects in a way that's currently not possible, extend LSL. I don't see what LSL has to do with this. LSL runs on the server side and is completely unsuitable to implement plugins. > If you want to operate on the message stream, then use a message stream > plugin. I could imagine audio plugins and access to floaters that you > could fill with whatever content you like, but I can't imagine access to > all of the internal data from a plugin. Well, you'll have to get used to that idea then, as the current talk of how plugins would work implies that there won't be any effective restrictions on them. -------------- 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/20070222/a3fb087c/attachment.pgp From ismail at pardus.org.tr Thu Feb 22 13:01:20 2007 From: ismail at pardus.org.tr (Ismail =?utf-8?q?D=C3=B6nmez?=) Date: Thu Feb 22 13:01:18 2007 Subject: [sldev] OpenJPEG decoder update In-Reply-To: <20070221042420.GA1745@spacedout.fries.net> References: <20070221042420.GA1745@spacedout.fries.net> Message-ID: <200702222301.20575.ismail@pardus.org.tr> On Wednesday 21 February 2007 06:24:20 David Fries wrote: > Francois Devaux has merged changes into OpenJPEG that limits decoding > to the main OpenJPEG header. That version of OpenJPEG is currently > in their svn repository. A new release of OpenJPEG will follow. > > The changes that were merged into OpenJPEG require a one line change > to my original Second Life viewer patch in VWR-123. I've attached > that patch to the bug report already. I'm going to suggest that now > is a good time to apply the patches in VWR-123 to the viewer source > tree. I've received positive feedback from people who have tried it, > and the one Fedora Core RPM source package contained the original > patch. > > The patches in VWR-123 need to be applied in the following order. > > llimagej2coj_bug_fixes.patch > comment_typo.diff > LLImageJ2COJ_OPJ_HEADER.patch > > Note OPJ_limit_tags_for_decode.patch is has been obsoleted by the > version in svn. I got very nice results using these patches and OpenJPEG from SVN, I hope gcc4 autovectorization and more stuff gets in. Maybe in the end it will be faster than Kakadu libs :) Regards, ismail -- FFmpeg doxy @ http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs From kelly at lindenlab.com Thu Feb 22 13:01:26 2007 From: kelly at lindenlab.com (Kelly Washington) Date: Thu Feb 22 13:01:39 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DDF52C.8090907@watson.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> Message-ID: <45DE04A6.5080003@lindenlab.com> Mike Monkowski wrote: > Dale Glass wrote: >> LSL scripts will never be able to do some things. Like for example >> changing how rendering works. Or integrating things like text to >> speech and voip. > > The reason I asked about plugins is because I'm trying to figure out > how to implement lip-sync. After looking at the code and reading the > replies in this forum, I can't see how a plugin could ever work for > lip-sync. I can't see rendering being done in a plugin either. TTS > probably could because TTS can get text from the message stream and > add to the audio stream. > > It seems to me that plugins must have limited capabilities based on > limited access to data. > > LSL operates on objects, so it would make sense that if you want to > operate on objects in a way that's currently not possible, extend LSL. > If you want to operate on the message stream, then use a message > stream plugin. I could imagine audio plugins and access to floaters > that you could fill with whatever content you like, but I can't > imagine access to all of the internal data from a plugin. > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev This is an excellent point. There will have to be a line drawn somewhere between what can be a plugin and what requires a separate client or re-compile. This line does not need to be fixed in stone at the creation of the plugin system. In fact the best approach may be to start conservatively with very little on the plugin side. This would allow the system to get out, get tested, get used and get refined quicker than building an all-encompassing plugin system from the start. The plugin system of course then needs to be extendable, but even an all-encompassing attempt should be extendable to allow for future core source changes and new features. Along this route, what is the minimal needed to create a plugin system that can at least make some useful plugins? My guess is the following: - create a floater, be able to populate and update data in the floater. By this I just mean set text, set images, add/remove items from scroll lists. - add UI to bring up the floater. As a first pass even just a 'plugins' menu with a menu item for each loaded plug in. - access to specific internal data - ie the list of visible avatars, region name, current location etc. Now that won't let you create just any plugin, it won't even let you create most plugins (I'm sure everyone noticed there is nothing about handling messages at all), but that is my guess as to the minimal needed by a plugin. From phoenix at secondlife.com Thu Feb 22 13:50:57 2007 From: phoenix at secondlife.com (Phoenix) Date: Thu Feb 22 13:51:06 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <200702222156.07839.dale@daleglass.net> References: <45DB36A3.60004@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <200702222156.07839.dale@daleglass.net> Message-ID: <6E0A6592-256B-41D2-92A7-49E20D86D5CD@secondlife.com> On 2007 Feb 22, at 12:55, Dale Glass wrote: > ? ????????? ?? 22 ??????? 2007 20:55 Mike > Monkowski ???????(a): >> Dale Glass wrote: >>> LSL scripts will never be able to do some things. Like for example >>> changing how rendering works. Or integrating things like text to >>> speech >>> and voip. >> >> The reason I asked about plugins is because I'm trying to figure >> out how >> to implement lip-sync. After looking at the code and reading the >> replies in this forum, I can't see how a plugin could ever work for >> lip-sync. I can't see rendering being done in a plugin either. TTS > Why not? Both things are perfectly doable. Not sure of what exactly > you mean > by "lip sync" (I'm guessing making the in-world avatar move the > lips in sync > with the RL person, by analyzing speech, webcam video or whatever), > but > there's nothing that'd prevent it being in a plugin. Just so everyone knows, we are already working on lip and gesture motions for the avatar. This is no promise of functionality or when it will be available, but it is in the pipeline and under active development. -------------- 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/20070222/b5dcfa39/PGP.pgp From phoenix at secondlife.com Thu Feb 22 14:06:13 2007 From: phoenix at secondlife.com (Phoenix) Date: Thu Feb 22 14:06:30 2007 Subject: [sldev] SL at FOSDEM Message-ID: <9A5A3D43-3FB3-4F77-934F-42951D3A51DD@secondlife.com> Howdy SL devs. I will be attending FOSDEM and would love to talk to the folks who have hacked on the client. I will be in the x.org room from 13:00 to 14:00 on Sunday and can talk about anything and everything about SL architecture and what we are planning to open in the future. I will also be hanging around for much of the conference other than (*sob*) the Friday beer event. So if you see my face, come say 'howdy.' http://www.fosdem.org/2007/schedule/events/xorg_second_life -------------- 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/20070222/af4dcbb1/PGP.pgp From monkowsk at watson.ibm.com Thu Feb 22 14:25:44 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu Feb 22 14:25:51 2007 Subject: [sldev] Lip-sync; was: Plugin architecture In-Reply-To: <6E0A6592-256B-41D2-92A7-49E20D86D5CD@secondlife.com> References: <45DB36A3.60004@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <200702222156.07839.dale@daleglass.net> <6E0A6592-256B-41D2-92A7-49E20D86D5CD@secondlife.com> Message-ID: <45DE1868.3080002@watson.ibm.com> Phoenix wrote: > Just so everyone knows, we are already working on lip and gesture > motions for the avatar. This is no promise of functionality or when it > will be available, but it is in the pipeline and under active development. Could you clarify this a bit. It appears to me that the avatars already have mouth morphs and gestures that can be synced to text chat. Are you saying that you will sync these to live speech, text-to-speech, recorded speech, or what? Mike From dale at daleglass.net Thu Feb 22 14:26:55 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Feb 22 14:27:10 2007 Subject: [sldev] Plan for executable switcher Message-ID: <200702222327.02886.dale@daleglass.net> Here's a rough idea I had: Since plugins will still take a while to materialize, and I think that getting testing for new features is a good thing, unless anybody has something like this already, I'm going to start work on a program that will allow the user to choose which version of SL to run. Idea so far: Switcher would be a .NET app written in C#. Source will be available under the GPL of course. Since most people don't have nearly the bandwidth capabilities of LL, making things compact is important. For that reason, alternative clients will be distributed in say, NSIS packages, but include only the changed files, as well as some metadata. The metadata indicates among other things on which LL release it's based. Switcher will assemble a working SL install based on the original files and the modifications from the installed package, then run that. If the third party client is based on a SL version that's not installed (say, firstlook based and user is running the stable client), then the switcher will try to automatically download the official version to use as a base. For an user, it would work like this: * User installs switcher program (which is standalone, and probably will have some sort of autoupdate system) * User goes to my site, and downloads my SL version * On install, it gets added to the list of available versions in the switcher * User selects the desired version, clicks "ok" * Switcher copies an original SL version into a directory, then my modifications over that, and launches it. Probably there would be some sort of auto-update system for third party clients, so that an updated version against the latest LL source can be downloaded easily. How does that sound? -------------- 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/20070222/ec65c55a/attachment-0001.pgp From tao.takashi at googlemail.com Thu Feb 22 14:47:24 2007 From: tao.takashi at googlemail.com (Tao Takashi) Date: Thu Feb 22 14:47:25 2007 Subject: [sldev] SL at FOSDEM In-Reply-To: <9A5A3D43-3FB3-4F77-934F-42951D3A51DD@secondlife.com> References: <9A5A3D43-3FB3-4F77-934F-42951D3A51DD@secondlife.com> Message-ID: <23bbb49e0702221447h2d9ca4bes4252363be2db32e7@mail.gmail.com> Howdy! 2007/2/22, Phoenix : > > Howdy SL devs. I will be attending FOSDEM and would love to talk to > the folks who have hacked on the client. I will be in the x.org room > from 13:00 to 14:00 on Sunday and can talk about anything and > everything about SL architecture and what we are planning to open in > the future. > > I will also be hanging around for much of the conference other than > (*sob*) the Friday beer event. So if you see my face, come say 'howdy.' Cool, I also hope to be there on sunday and attending the Plone event in the morning so I might come over later. I haven't really hacked the client (yet) though ;-) Hope to see you there! :-) - Tao http://www.fosdem.org/2007/schedule/events/xorg_second_life > > > _______________________________________________ > 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://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/20070222/f11ef0e6/attachment.htm From peekay at targetomega.com Thu Feb 22 15:12:57 2007 From: peekay at targetomega.com (Peekay Semyorka) Date: Thu Feb 22 15:13:11 2007 Subject: [sldev] Plan for executable switcher In-Reply-To: <200702222327.02886.dale@daleglass.net> References: <200702222327.02886.dale@daleglass.net> Message-ID: <1712.69.158.190.134.1172185977.squirrel@webmail.bluewax.com> Seems like a lot of work for no gain. Why not just rename your executable "MyCoolViewer.exe", and tell users to simply drop it into the Second Life directory? Then the user can run SecondLife.exe or MyCoolViewer.exe (or even both at once), without the need for having a switcher, etc. You can create an installer which simply copies the file over, creates a desktop shortcut, and be done with it. Maybe more interesting for the Mac? -peekay From dale at daleglass.net Thu Feb 22 15:17:27 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Feb 22 15:17:49 2007 Subject: [sldev] Plan for executable switcher In-Reply-To: <1712.69.158.190.134.1172185977.squirrel@webmail.bluewax.com> References: <200702222327.02886.dale@daleglass.net> <1712.69.158.190.134.1172185977.squirrel@webmail.bluewax.com> Message-ID: <200702230017.32150.dale@daleglass.net> ? ????????? ?? 23 ??????? 2007 00:12 Peekay Semyorka ???????(a): > Seems like a lot of work for no gain. > > Why not just rename your executable "MyCoolViewer.exe", and tell users to > simply drop it into the Second Life directory? Not that easy. For example, my avatar list adds XUI .xml files, and changes another to add text for messages. Latest version also adds new textures, which requires modifying textures.xml. Eventually, it's easy enough to end up with a situation where my changes conflict with somebody else's, or do something undesirable with the original executable. -------------- 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/20070223/961bf680/attachment.pgp From signore at autistiche.org Thu Feb 22 18:47:21 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Thu Feb 22 18:47:35 2007 Subject: llmozlib (was: Re: [sldev] Linking fails with FL-1.13.3.58185 (cannot find llmozlib)) In-Reply-To: <45DD722F.3090409@lindenlab.com> Message-ID: >Meanwhile, playing with LL_LIBXUL_ENABLED and removing the moz libs >from the SConstruct linkline is currently a safe option. > >- Tofu :) 1 I commented out in indra/SConstruct these lines: 126-147 and 194-195. 2 In indra/llcommon/llpreprocessor.h , as suggested here I changed #define LL_LIBXUL_ENABLED 1 to #define LL_LIBXUL_ENABLED 0 3 Since Ubuntu uses ?dash? instead of ?bash?, someone suggested me changing #!/bin/sh to #!/bin/bash in these files: linden/indra/newview/linux_tools/launch_url.sh linden/indra/newview/linux_tools/launch_url.sh linden/indra/newview/linux_tools/wrapper.sh linden/indra/newview/linux_tools/package-client.sh linden/libraries/include/boost/pool/detail/pool_construct_simple.sh linden/libraries/include/boost/pool/detail/pool_construct.sh linden/libraries/i686-linux/include/apr-1/arch/unix/apr_arch_threadproc.h Result: I managed to compile the Second Life viewer on Linux, using the BUILD=releasefordownload scon option. I extracted the resulting tar.bz2 package and the FL viewer runs quite smoothly :) I'm writing what i made at https://wiki.secondlife.com/wiki/User:Signore_Iredell, should I move it to a new page in the wiki, maybe Compiling the viewer (Linux Ubuntu) ? bye, signore iredell From rdw at lindenlab.com Thu Feb 22 18:49:24 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Thu Feb 22 18:49:26 2007 Subject: [sldev] Viewer Manifest In-Reply-To: <200702230017.32150.dale@daleglass.net> References: <200702222327.02886.dale@daleglass.net> <1712.69.158.190.134.1172185977.squirrel@webmail.bluewax.com> <200702230017.32150.dale@daleglass.net> Message-ID: <45DE5634.600@lindenlab.com> Dale Glass wrote: > ? ????????? ?? 23 ??????? 2007 00:12 Peekay Semyorka ???????(a): >> Seems like a lot of work for no gain. >> >> Why not just rename your executable "MyCoolViewer.exe", and tell users to >> simply drop it into the Second Life directory? > Not that easy. For example, my avatar list adds XUI .xml files, and changes > another to add text for messages. > > Latest version also adds new textures, which requires modifying textures.xml. > > Eventually, it's easy enough to end up with a situation where my changes > conflict with somebody else's, or do something undesirable with the original > executable. This seems like a great time to interject about an installer packaging script I'm introducing into the next release. The short story is that building an installer will be one step -- running a Python script. I don't know how much of our installer-making code has been released, but since the .nsi wasn't, probably "not much". Either way, with the next source release the installer-making capabilities should be fully operational. I provided documentation for the file here: https://wiki.secondlife.com/wiki/Viewer_Manifest I'm certainly interested in discussion about the design and implementation of the script. Of course, not much discussion can happen until everyone see the code, but I just wanted to give a heads-up. So, why is this relevant to the topic at hand? The script consolidates all the information about how to install the viewer, so you could easily modify it to install to a different directory with a different name on the recipient's machine. -RYaN From dale at daleglass.net Thu Feb 22 19:28:16 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Feb 22 19:33:06 2007 Subject: [sldev] Re: Viewer Manifest In-Reply-To: <45DE5634.600@lindenlab.com> References: <200702222327.02886.dale@daleglass.net> <200702230017.32150.dale@daleglass.net> <45DE5634.600@lindenlab.com> Message-ID: <200702230428.23320.dale@daleglass.net> ? ????????? ?? 23 ??????? 2007 03:49 Ryan Williams ???????(a): > I'm certainly interested in discussion about the design and > implementation of the script. Of course, not much discussion can happen > until everyone see the code, but I just wanted to give a heads-up. Thanks, will take a look. > So, why is this relevant to the topic at hand? The script consolidates > all the information about how to install the viewer, so you could easily > modify it to install to a different directory with a different name on > the recipient's machine. On my part, packaging isn't what I'm concerned about. Here my idea is to try to deliver alternate clients without having to redownload the whole thing, as that requires considerable bandwidth. So the idea is to just packaged the files that changed, and use a client-side program that would take care of reusing what was delivered by LL's official intstaller. > > -RYaN -------------- 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/20070223/411bfb0d/attachment.pgp From dale at daleglass.net Thu Feb 22 19:28:16 2007 From: dale at daleglass.net (Dale Glass) Date: Thu Feb 22 19:33:07 2007 Subject: [sldev] Re: Viewer Manifest In-Reply-To: <45DE5634.600@lindenlab.com> References: <200702222327.02886.dale@daleglass.net> <200702230017.32150.dale@daleglass.net> <45DE5634.600@lindenlab.com> Message-ID: <200702230428.23320.dale@daleglass.net> ? ????????? ?? 23 ??????? 2007 03:49 Ryan Williams ???????(a): > I'm certainly interested in discussion about the design and > implementation of the script. Of course, not much discussion can happen > until everyone see the code, but I just wanted to give a heads-up. Thanks, will take a look. > So, why is this relevant to the topic at hand? The script consolidates > all the information about how to install the viewer, so you could easily > modify it to install to a different directory with a different name on > the recipient's machine. On my part, packaging isn't what I'm concerned about. Here my idea is to try to deliver alternate clients without having to redownload the whole thing, as that requires considerable bandwidth. So the idea is to just packaged the files that changed, and use a client-side program that would take care of reusing what was delivered by LL's official intstaller. > > -RYaN -------------- 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/20070223/411bfb0d/attachment-0001.pgp From george.williams at gmail.com Thu Feb 22 22:15:58 2007 From: george.williams at gmail.com (George Williams) Date: Thu Feb 22 22:16:01 2007 Subject: [sldev] compile is ok, but i get error at startup Message-ID: <85e6f7f00702222215w126a8326hb83b39373f537cf7@mail.gmail.com> Hi, I think I'm being a bonehead - can someone help? I am building "slviewer-src-FL-1.13.3.58018". It builds ok. When a start the program, I get a dialogue a few seconds later: "Second Life is unable to access a file that it needs. This can be because you somehow have multiple copies running, or your system incorrectly thinks a file is open. If this message persists, restart your computer and try again. If it continues to persist, you may need to complete uninstall Second Life and reinstall it." Thank for your help, in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070222/ee74d5d6/attachment-0001.htm From carnildo at gmail.com Thu Feb 22 22:25:54 2007 From: carnildo at gmail.com (Mark Wagner) Date: Thu Feb 22 22:25:59 2007 Subject: [sldev] compile is ok, but i get error at startup In-Reply-To: <85e6f7f00702222215w126a8326hb83b39373f537cf7@mail.gmail.com> References: <85e6f7f00702222215w126a8326hb83b39373f537cf7@mail.gmail.com> Message-ID: <31073ef90702222225g26333330p5032978170196c7d@mail.gmail.com> On 2/22/07, George Williams wrote: > Hi, > > I think I'm being a bonehead - can someone help? > > I am building "slviewer-src-FL-1.13.3.58018". It builds ok. When a start > the program, I get a dialogue a few seconds later: > > "Second Life is unable to access a file that it needs. > > This can be because you somehow have multiple copies running, or your system > incorrectly thinks a file is open. If this message persists, restart your > computer and try again. If it continues to persist, you may need to > complete uninstall Second Life and reinstall it." What OS are you using? What compiler? Are you running the program in-place, or are you copying it somewhere? Are you building the support libraries yourself, or using the pre-packaged ones? -- Mark Carnildo Greenacre From karen at lindenlab.com Thu Feb 22 23:10:57 2007 From: karen at lindenlab.com (karen@lindenlab.com) Date: Thu Feb 22 23:10:59 2007 Subject: [sldev] compile is ok, but i get error at startup In-Reply-To: <85e6f7f00702222304j5f3b778dxacd11649fda4a79f@mail.gmail.com> References: <85e6f7f00702222215w126a8326hb83b39373f537cf7@mail.gmail.com> <62314.75.37.16.10.1172211780.squirrel@mail.lindenlab.com> <85e6f7f00702222247s1b8b981av5a84aa52afef2155@mail.gmail.com> <62520.75.37.16.10.1172213557.squirrel@mail.lindenlab.com> <85e6f7f00702222253r41e7897cpbed165373c8120ab@mail.gmail.com> <62542.75.37.16.10.1172213930.squirrel@mail.lindenlab.com> <85e6f7f00702222304j5f3b778dxacd11649fda4a79f@mail.gmail.com> Message-ID: <62770.75.37.16.10.1172214657.squirrel@mail.lindenlab.com> Alright, my last idea (before I turn in for the night) is to compile the debug version and run it from Dev Studio. A console window should open up when you launch which may give more detailed information. Have you reviewed the items on the Open Source Windows build page (http://wiki.secondlife.com/wiki/Compiling_the_viewer_%28MS_Windows_-_Visual_Studio_.NET_2003%29) to be sure you're not missing anything? -=-Karen > Karen, > > Thank you. > > I've found the SecondLife/logs directory. > > There is a file in there called debug_info.log. > > I didn't see anything useful in there, but you may know what to look for. > I've appended it... > > <<<< > > > SL Log: > Second Life version 1.13.3 build 3 > Not supported (3000 Mhz) > RAM: 2146676736 > OS: Microsoft Windows XP Service Pack 2 (Build 2600) > > StartAllDevices > StartDevice > DeviceName:Texas Instruments OHCI Compliant IEEE 1394 Host Controller > PCIString:PCI\VEN_104C&DEV_8023&SUBSYS_808B1043&REV_00\4&2411F011&0&5890 > Filename:1394bus.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:arp1394.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:enum1394.sys > Ver:5.01.2600.0000 > Date:8/17/2001 05:46:40 > Filename:nic1394.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:ohci1394.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:Silicon Image SiI 3132 SATALink Controller > PCIString:PCI\VEN_1095&DEV_3132&SUBSYS_819F1043&REV_01\4&29E3D116&0&0028 > Filename:SI3132.sys > Ver:1.00.0000.0009 > Date:1/19/2005 06:30:52 > Filename:SiWinAcc.sys > Ver:1.00.0000.0011 > Date:11/1/2004 03:21:32 > Filename:SilSupp.cpl > Ver:3.00.0000.0018 > Date:1/11/2005 02:56:46 > EndDevice > StartDevice > DeviceName:PCI standard ISA bridge > PCIString:PCI\VEN_10DE&DEV_0050&SUBSYS_00000000&REV_A4\3&267A616A&0&50 > Filename:isapnp.sys > Ver:5.01.2600.0000 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:NVIDIA nForce PCI System Management > PCIString:PCI\VEN_10DE&DEV_0052&SUBSYS_81621043&REV_A2\3&267A616A&0&51 > EndDevice > StartDevice > DeviceName:Standard Dual Channel PCI IDE Controller > PCIString:PCI\VEN_10DE&DEV_0053&SUBSYS_81621043&REV_F3\3&267A616A&0&78 > Filename:atapi.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:pciide.sys > Ver:5.01.2600.0000 > Date:8/4/2004 04:00:00 > Filename:pciidex.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:NVIDIA nForce4 Serial ATA Controller > PCIString:PCI\VEN_10DE&DEV_0054&SUBSYS_81621043&REV_F3\3&267A616A&0&80 > Filename:NVCOI.DLL > Ver:1.00.0000.0029 > Date:8/2/2005 22:52:08 > Filename:idecoi.dll > Ver:1.00.0000.0001 > Date:8/18/2005 01:52:08 > Filename:idecoins.dll > Ver:1.00.0000.0001 > Date:8/18/2005 01:52:08 > Filename:nvata.sys > Ver:5.10.2600.0552 > Date:8/18/2005 01:52:06 > EndDevice > StartDevice > DeviceName:NVIDIA nForce4 Serial ATA Controller > PCIString:PCI\VEN_10DE&DEV_0055&SUBSYS_81621043&REV_F3\3&267A616A&0&88 > Filename:NVCOI.DLL > Ver:1.00.0000.0029 > Date:8/2/2005 22:52:08 > Filename:idecoi.dll > Ver:1.00.0000.0001 > Date:8/18/2005 01:52:08 > Filename:idecoins.dll > Ver:1.00.0000.0001 > Date:8/18/2005 01:52:08 > Filename:nvata.sys > Ver:5.10.2600.0552 > Date:8/18/2005 01:52:06 > EndDevice > StartDevice > DeviceName:NVIDIA Network Bus Enumerator > PCIString:PCI\VEN_10DE&DEV_0057&SUBSYS_81D31043&REV_A3\3&267A616A&0&98 > Filename:bdco1.dll > Ver:1.00.0000.0000 > Date:7/26/2005 01:45:30 > Filename:bdco1ins.dll > Ver:1.00.0000.0000 > Date:7/26/2005 01:45:30 > Filename:nvconrm.dll > Ver:1.00.0000.0027 > Date:7/20/2005 01:08:20 > Filename:nvconrmins.dll > Ver:1.00.0000.0027 > Date:7/20/2005 01:08:20 > Filename:nvnetbus.sys > Ver:1.00.0000.0509 > Date:7/26/2005 01:48:30 > Filename:nvnrm.sys > Ver:1.00.0000.0509 > Date:7/26/2005 01:48:14 > Filename:nvsnpu.sys > Ver:1.00.0000.0509 > Date:7/26/2005 01:48:06 > EndDevice > StartDevice > DeviceName:Realtek AC'97 Audio > PCIString:PCI\VEN_10DE&DEV_0059&SUBSYS_812A1043&REV_A2\3&267A616A&0&68 > Filename:ALCXWDM.SYS > Ver:5.10.0000.5900 > Date:8/19/2005 01:31:52 > Filename:ALSNDMGR.CPL > Ver:2.02.0000.0048 > Date:8/17/2005 02:25:20 > Filename:ALSNDMGR.WAV > Ver: > Date:2/4/2002 21:54:58 > Filename:RTLCPAPI.dll > Ver:1.00.0000.0004 > Date:9/6/2004 22:23:16 > Filename:RTLCPL.EXE > Ver:1.00.0001.0050 > Date:8/17/2005 02:21:38 > Filename:SOUNDMAN.EXE > Ver:5.01.0000.0043 > Date:8/17/2005 02:39:58 > Filename:drmk.sys > Ver:5.01.2600.2180 > Date:8/3/2004 22:08:00 > Filename:ks.sys > Ver:5.03.2600.2180 > Date:8/3/2004 22:15:22 > Filename:ksproxy.ax > Ver:5.03.2600.2180 > Date:8/3/2004 23:56:58 > Filename:ksuser.dll > Ver:5.03.2600.2180 > Date:8/3/2004 23:56:44 > Filename:portcls.sys > Ver:5.01.2600.2180 > Date:8/3/2004 22:15:50 > Filename:stream.sys > Ver:5.03.2600.2180 > Date:8/3/2004 22:08:04 > Filename:wdmaud.drv > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:Standard OpenHCD USB Host Controller > PCIString:PCI\VEN_10DE&DEV_005A&SUBSYS_81621043&REV_A2\3&267A616A&0&58 > Filename:usbhub.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:usbohci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:usbport.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:usbui.dll > Ver:5.01.2600.2180 > Date:8/3/2004 16:56:48 > EndDevice > StartDevice > DeviceName:Standard Enhanced PCI to USB Host Controller > PCIString:PCI\VEN_10DE&DEV_005B&SUBSYS_81621043&REV_A4\3&267A616A&0&59 > Filename:hccoin.dll > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:usbehci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:usbhub.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:usbport.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > Filename:usbui.dll > Ver:5.01.2600.2180 > Date:8/3/2004 16:56:48 > EndDevice > StartDevice > DeviceName:PCI standard PCI-to-PCI bridge > PCIString:PCI\VEN_10DE&DEV_005C&SUBSYS_00000000&REV_A2\3&267A616A&0&90 > Filename:pci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:PCI standard PCI-to-PCI bridge > PCIString:PCI\VEN_10DE&DEV_005D&SUBSYS_00000000&REV_A3\3&267A616A&0&A0 > Filename:pci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:PCI standard PCI-to-PCI bridge > PCIString:PCI\VEN_10DE&DEV_005D&SUBSYS_00000000&REV_A3\3&267A616A&0&B0 > Filename:pci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:PCI standard PCI-to-PCI bridge > PCIString:PCI\VEN_10DE&DEV_005D&SUBSYS_00000000&REV_A3\3&267A616A&0&B8 > Filename:pci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:nForce4 HyperTransport Bridge > PCIString:PCI\VEN_10DE&DEV_005E&SUBSYS_81621043&REV_A4\3&267A616A&0&48 > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_006F&SUBSYS_81891043&REV_A1\3&267A616A&0&03 > EndDevice > StartDevice > DeviceName:PCI standard host CPU bridge > PCIString:PCI\VEN_10DE&DEV_0071&SUBSYS_00000000&REV_A3\3&267A616A&0&00 > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_0075&SUBSYS_81891043&REV_A1\3&267A616A&0&02 > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_0076&SUBSYS_81891043&REV_A1\3&267A616A&0&08 > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_0078&SUBSYS_81891043&REV_A1\3&267A616A&0&09 > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_0079&SUBSYS_81891043&REV_A1\3&267A616A&0&0A > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_007A&SUBSYS_81891043&REV_A1\3&267A616A&0&0B > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_007B&SUBSYS_81891043&REV_A1\3&267A616A&0&0C > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_007C&SUBSYS_81891043&REV_A1\3&267A616A&0&0D > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_007D&SUBSYS_81891043&REV_A1\3&267A616A&0&0E > EndDevice > StartDevice > DeviceName:PCI standard PCI-to-PCI bridge > PCIString:PCI\VEN_10DE&DEV_007E&SUBSYS_00000000&REV_A2\3&267A616A&0&10 > Filename:pci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:PCI standard PCI-to-PCI bridge > PCIString:PCI\VEN_10DE&DEV_007E&SUBSYS_00000000&REV_A2\3&267A616A&0&20 > Filename:pci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:PCI standard PCI-to-PCI bridge > PCIString:PCI\VEN_10DE&DEV_007E&SUBSYS_00000000&REV_A2\3&267A616A&0&28 > Filename:pci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:PCI standard PCI-to-PCI bridge > PCIString:PCI\VEN_10DE&DEV_007E&SUBSYS_00000000&REV_A2\3&267A616A&0&30 > Filename:pci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:PCI standard PCI-to-PCI bridge > PCIString:PCI\VEN_10DE&DEV_007E&SUBSYS_00000000&REV_A2\3&267A616A&0&38 > Filename:pci.sys > Ver:5.01.2600.2180 > Date:8/4/2004 04:00:00 > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_007F&SUBSYS_81891043&REV_A1\3&267A616A&0&01 > EndDevice > StartDevice > DeviceName:PCI standard RAM Controller > PCIString:PCI\VEN_10DE&DEV_00B4&SUBSYS_81891043&REV_A1\3&267A616A&0&04 > EndDevice > StartDevice > DeviceName:NVIDIA Quadro FX 1400 > PCIString:PCI\VEN_10DE&DEV_00CE&SUBSYS_024310DE&REV_A2\4&20C03BEB&0&0010 > Filename:nv4_disp.dll > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > Filename:nv4_mini.sys > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > Filename:nvapi.dll > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > Filename:nvcod.dll > Ver:1.00.0000.0032 > Date:11/4/2005 08:38:00 > Filename:nvcodins.dll > Ver:1.00.0000.0032 > Date:11/4/2005 08:38:00 > Filename:nvcpl.dll > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > Filename:nvcpl.hlp > Ver: > Date:11/4/2005 08:38:00 > Filename:nvhwvid.dll > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > Filename:nvmccs.dll > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > Filename:nvmctray.dll > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > Filename:nvnt4cpl.dll > Ver:6.14.0010.11009 > Date:11/4/2005 08:38:00 > Filename:nvoglnt.dll > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > Filename:nvsvc32.exe > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > Filename:nvwcplen.hlp > Ver: > Date:11/4/2005 08:38:00 > Filename:nvwddi.dll > Ver:6.14.0010.8167 > Date:11/4/2005 08:38:00 > EndDevice > StartDevice > DeviceName:Marvell Yukon 88E8053 PCI-E Gigabit Ethernet Controller > PCIString:PCI\VEN_11AB&DEV_4362&SUBSYS_532111AB&REV_22\4&2145A711&0&0038 > Filename:yk51x86.sys > Ver:8.24.0003.0003 > Date:3/30/2005 07:24:00 > EndDevice > EndAllDevices > > > > > > On 2/22/07, karen@lindenlab.com wrote: >> >> Unfortunately, I don't have a dev environment in front of me right now. >> When you run release_noopt, you should have a log console that shows you >> errors. Generally, the errors write to the normal SL log. To find that >> log, you will need to turn on "Show Hidden Files" in the Folder Options >> menu. Once you've done that, you can go to C:\Documents and >> Settings\(your >> user name)\Application Data\SecondLife\logs and you should find the log. >> >> Please let me know if this still doesn't help and I can take a look at >> the >> problem tomorrow when I'm in the office. >> >> -=-Karen >> >> >> > Karen, >> > >> > Yes, that one gave me the error. >> > >> > I am building the production version as I write this. >> > >> > >> > >> > On 2/22/07, karen@lindenlab.com wrote: >> >> >> >> Hi George, >> >> >> >> What option are you compiling with? Release_NoOpt? >> >> >> >> -=-Karen >> >> >> >> > Karen, >> >> > >> >> > I can't seem to find this log file anywhere under my src/build >> >> folders. >> >> > Is >> >> > it located somewhere else on the machine? >> >> > >> >> > Thank you. >> >> > >> >> > >> >> > >> >> > On 2/22/07, karen@lindenlab.com wrote: >> >> >> >> >> >> Hi George, >> >> >> >> >> >> There should be something useful in your logs/SecondLife.log file. >> >> Can >> >> >> you >> >> >> send in the last 50 lines or so? >> >> >> >> >> >> -=-Karen >> >> >> >> >> >> >> >> >> > Hi, >> >> >> > >> >> >> > I think I'm being a bonehead - can someone help? >> >> >> > >> >> >> > I am building "slviewer-src-FL-1.13.3.58018". It builds ok. >> When >> >> a >> >> >> start >> >> >> > the program, I get a dialogue a few seconds later: >> >> >> > >> >> >> > "Second Life is unable to access a file that it needs. >> >> >> > >> >> >> > This can be because you somehow have multiple copies running, or >> >> your >> >> >> > system >> >> >> > incorrectly thinks a file is open. If this message persists, >> >> restart >> >> >> your >> >> >> > computer and try again. If it continues to persist, you may >> need >> >> to >> >> >> > complete uninstall Second Life and reinstall it." >> >> >> > >> >> >> > Thank for your help, in advance. >> >> >> > _______________________________________________ >> >> >> > Click here to unsubscribe or manage your list subscription: >> >> >> > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> >> >> > >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> >> >> >> > >> >> >> > From robla at lindenlab.com Thu Feb 22 23:30:29 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Thu Feb 22 23:30:41 2007 Subject: llmozlib (was: Re: [sldev] Linking fails with FL-1.13.3.58185 (cannot find llmozlib)) In-Reply-To: References: Message-ID: <45DE9815.7040700@lindenlab.com> Hi Signore Thanks for sticking with it. The /bin/sh->/bin/bash changes should actually be submitted as a patch (or the incompatible bash-isms eradicated so that /bin/sh is a legitimate thing to claim), so I'd appreciate it if you actually filed a detailed bug report describing that problem (and attached a patch), which should make it easier for you and others the next time you embark on a fresh compile. It'd be pretty cool if it were easier to disable llmozlib without the need to comment out large swaths of the SConstruct file. Any volunteers to simplify this process? The SConstruct file is Python, so the addition of a boolean should be pretty straightforward if you can resist the temptation to refactor it into subroutines (which it's probably due for, imho, but don't take that to mean I'm volunteering to do it just yet). Rob On 2/22/07 6:47 PM, signore@autistiche.org wrote: >> Meanwhile, playing with LL_LIBXUL_ENABLED and removing the moz libs >> > >from the SConstruct linkline is currently a safe option. > >> - Tofu >> > > :) > > 1 > I commented out in indra/SConstruct these lines: 126-147 and 194-195. > > 2 > In indra/llcommon/llpreprocessor.h , as suggested here I changed > #define LL_LIBXUL_ENABLED 1 > to > #define LL_LIBXUL_ENABLED 0 > > 3 > Since Ubuntu uses ?dash? instead of ?bash?, someone suggested me > changing > #!/bin/sh > to > #!/bin/bash > in these files: > linden/indra/newview/linux_tools/launch_url.sh > linden/indra/newview/linux_tools/launch_url.sh > linden/indra/newview/linux_tools/wrapper.sh > linden/indra/newview/linux_tools/package-client.sh > linden/libraries/include/boost/pool/detail/pool_construct_simple.sh > linden/libraries/include/boost/pool/detail/pool_construct.sh > linden/libraries/i686-linux/include/apr-1/arch/unix/apr_arch_threadproc.h > > Result: > I managed to compile the Second Life viewer on Linux, using the > BUILD=releasefordownload scon option. I extracted the resulting > tar.bz2 package and the FL viewer runs quite smoothly :) > > I'm writing what i made at > https://wiki.secondlife.com/wiki/User:Signore_Iredell, > should I move it to a new page in the wiki, maybe > Compiling the viewer (Linux Ubuntu) ? > > bye, > signore iredell > _______________________________________________ > 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/20070222/0ca1a7a6/signature.pgp From hud at zurich.ibm.com Thu Feb 22 23:30:27 2007 From: hud at zurich.ibm.com (dirk husemann) Date: Thu Feb 22 23:30:56 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <9F635A99-F638-4851-8D1F-86EFBAC98525@bushing.mm.st> References: <45DB36A3.60004@watson.ibm.com> <200702210239.25440.dale@daleglass.net> <45DC7588.2020906@watson.ibm.com> <200702211811.12973.dale@daleglass.net> <45DCC8B0.9030709@gmail.com> <45DCD45A.1050308@lindenlab.com> <45DCE879.6030006@gmail.com> <45DDAB8A.7010107@zurich.ibm.com> <45DDD279.1050602@zurich.ibm.com> <9F635A99-F638-4851-8D1F-86EFBAC98525@bushing.mm.st> Message-ID: <45DE9813.5070305@zurich.ibm.com> Ben Byer wrote: > On Feb 22, 2007, at 9:27 AM, dirk husemann wrote: > >> dirk husemann wrote: >> >> [...] >> >> i've added a page to the wiki describing the approach: >> https://wiki.secondlife.com/wiki/Plugin_Separate_Process > > Why not just use SLProxy? simple: i don't know enough about SLProxy. :-( ... i guess my line of thought was that we might want to have additional packet types/data streams to communicate to the viewer (creating a GUI element through whatever). but, you are right, if the viewer would understand these packets, SLProxy might do the job. -- dr dirk husemann, pervasive computing, ibm zurich research lab --- hud@zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070223/19b6ed6a/signature.pgp From rdw at lindenlab.com Fri Feb 23 00:06:24 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Fri Feb 23 00:06:34 2007 Subject: [sldev] Plugin API In-Reply-To: References: <20070221200006.3FC9541AFE4@stupor.lindenlab.com> Message-ID: <45DEA080.6060105@lindenlab.com> It seems like the proper parameter passing data structure is LLSD. Actually, the overlap between the message system design and the plugin system design is probably substantial. Not to say that one should be the other, but something to ruminate on. -RYaN Argent Stonecutter wrote: > [also in the discussion section on the wiki] > > I don't like the idea of anonymous pointers for parameter passing. I > think that some kind of parameter list is essential. > > typedef struct { > int sl_param_id; // Defined in the particular function's API > enum { > SL_INT32, SL_INT64, SL_FLOAT32, SL_FLOAT64, SL_STRING, > SL_ALLOCED_STRING, ... > } sl_type; // Plugin may ignore parameters > int sl_required; // If set, plugin MUST handle this parameter > int sl_changed; // Zero before any plugin called, non-zero if any > plugin has changed it > int64_t sl_value; // If the type is only 32 bits long, high 32 bits > must be zero. > } sl_param; > typedef enum { SL_OK, SL_INCOMPATIBLE, SL_ERROR, SL_BREAK } sl_result; > > sl_result sl_plugin(int count, sl_param params[], sl_param *error_info); > > The function calling the plugin can have all these set in a static > structure, and only needs to zero out the sl_changed parameters and > set up the initial values. Plugins do not call plugins, the list of > plugins for the function are called sequentially by the > sl_handle_plugins routine. > > if(my_plugins != NULL) { > my_params[0].sl_changed = 0; > my_params[0].sl_value = whatever; > final_result = sl_handle_plugins(my_plugins, 1, my_params, > &error_param); > if(final_result == SL_BREAK) return success; > if(final_result == SL_ERROR) { > panic(error_param); > return failure; > } > } > > The plugin must at a minimum: > > * verify that the sl_param_id values are what it expects and > handle (even if by ignoring) the wrong values > * handle (even if by ignoring the parameter) the "wrong" types > * return SL_INCOMPATIBLE if any of the parameters it's ignoring > have sl_required set. > * set sl_changed for any parameters it's changed > * fill in error_info if it returns SL_ERROR > * free an SL_ALLOCED_STRING if it changes the string > * make sure that the type of a string parameter is > SL_ALLOCED_STRING or SL_STRING to let the caller or later plugins know > how to deal with them > > The plugin may: > > * Handle changes to the order of parameters as indicated by > sl_param_id > * Handle changes to the types of parameters as indicated by sl_type > * Behave differently if a previous plugin has changed a parameter > > Return values: > > * SL_OK - Normal return, go on to the next plugin > * SL_INCOMPATIBLE - This plugin no longer works with this call. > Let the user know and don't call this plugin again. > * SL_ERROR - This plugin has detected an error sufficiently severe > that this call must abort. Should be rare. > o error_info must be set to { original_param_id, SL_STRING > or SL_ALLOCED_STRING, TRUE, TRUE, error_message }. > * SL_BREAK - Don't call any further plugins, don't run the rest of > the function, the plugin has completely handled the > call._______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From peekay at targetomega.com Fri Feb 23 01:02:31 2007 From: peekay at targetomega.com (Peekay Semyorka) Date: Fri Feb 23 01:02:44 2007 Subject: [sldev] Plan for executable switcher In-Reply-To: <200702230017.32150.dale@daleglass.net> References: <200702222327.02886.dale@daleglass.net> <1712.69.158.190.134.1172185977.squirrel@webmail.bluewax.com> <200702230017.32150.dale@daleglass.net> Message-ID: <2977.69.158.190.134.1172221351.squirrel@webmail.bluewax.com> Dale Glass wrote: > Eventually, it's easy enough to end up with a situation where my changes > conflict with somebody else's, or do something undesirable with the > original executable. My concern is such a 'switcher' amounts to the exact opposite of a plug-in infrastructure; i.e., a mechanism where many plug-ins could co-exist at runtime (and maybe even 'co-operate' with each other through shared structures.) What's being proposed instead means only one feature-set could ever be active at one time. Either your set of changes or mine (or Jack's or Jill's) but never more than one. Ideally I'd like to see a framework where many plug-in "bundles" could co-exist, as long as each conforms to a well-defined API. (A "bundle" being a portable structure to deliver a plug-in along with its configuration, resources, and dependencies). For feature-sets which cannot be implemented within the plug-in framework (and wholesale downloading is to be avoided), then it would be cleaner if its installer would simply make a copy of the the SL distribution and modify the new copy to suit its needs. -peekay From dale at daleglass.net Fri Feb 23 02:35:58 2007 From: dale at daleglass.net (Dale Glass) Date: Fri Feb 23 02:36:25 2007 Subject: [sldev] Plan for executable switcher In-Reply-To: <2977.69.158.190.134.1172221351.squirrel@webmail.bluewax.com> References: <200702222327.02886.dale@daleglass.net> <200702230017.32150.dale@daleglass.net> <2977.69.158.190.134.1172221351.squirrel@webmail.bluewax.com> Message-ID: <200702231136.03338.dale@daleglass.net> ? ????????? ?? 23 ??????? 2007 10:02 Peekay Semyorka ???????(a): > Dale Glass wrote: > > Eventually, it's easy enough to end up with a situation where my changes > > conflict with somebody else's, or do something undesirable with the > > original executable. > > My concern is such a 'switcher' amounts to the exact opposite of a plug-in > infrastructure; i.e., a mechanism where many plug-ins could co-exist at > runtime (and maybe even 'co-operate' with each other through shared > structures.) Well, of course it's FAR from an ideal solution. I'm just doing it as a stopgap measure -- I think there is value in letting people try alternative versions even before plugins are ready, because plugins are complex and will take a long time to stabilize, and this is something I can get done this weekend. The other alternative to this that comes to mind while we lack proper plugins is creating a branch where everything usable is merged, and distributing that. -------------- 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/20070223/cb1f72ae/attachment.pgp From plevexier at bellsouth.net Fri Feb 23 07:16:37 2007 From: plevexier at bellsouth.net (Patrice Le Vexier) Date: Fri Feb 23 07:16:41 2007 Subject: [sldev] mono embedded on SL client In-Reply-To: <45DDED35.3010302@lindenlab.com> References: <20070222163139.MLAF407.ibm61aec.bellsouth.net@mail.bellsouth.net> <69F7B6B5-08E8-4F65-BC43-763F62F8DEFC@lindenlab.com> <45DDED35.3010302@lindenlab.com> Message-ID: <000301c7575d$9dd3ffc0$d97bff40$@net> Rob, Jim, That would be awesome. Patrice -----Original Message----- From: Rob Lanphier [mailto:robla@lindenlab.com] Sent: Thursday, February 22, 2007 2:21 PM To: Jim Purbrick Cc: PLV Subject: Re: [sldev] mono embedded on SL client On 2/22/07 9:10 AM, Jim Purbrick wrote: > Rob, Is this something we could usefully kick off? If we're going to > start embedding mono in the client I'd like to make sure it dovetails > nicely with where we're going to be with Mono on the simulators. Very possibly. > You will find that lots of the work I've done on the sim will cross > over to the viewer, so it might be better to wait until that's open > sourced before you start on this project. How self contained is this code? Perhaps we can actually release the bits of code that are useful for this task. Rob From tofu.linden at lindenlab.com Fri Feb 23 10:42:40 2007 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Fri Feb 23 10:41:58 2007 Subject: [sldev] LLMozLib Message-ID: <45DF35A0.9000702@lindenlab.com> Hi everyone, We've uploaded the source for the latest SL-compatible LLMozLib/uBrowser tree: http://s3.amazonaws.com/callum-linden/llmozlib-2007-02-23.tar.bz2 http://s3.amazonaws.com/callum-linden/llmozlib-2007-02-23.zip LLMozLib is a library (and set of Mozilla patches) written by Callum and others which we use to create our embedded Mozilla widgets inside the Second Life viewer (for web profiles, F1 Help, and the login screen currently) with a simplified API. It does not depend upon the Second Life source and can be used in your own programs. For more info about LLMozLib and uBrowser, see http://ubrowser.com/ You shouldn't generally need to download and build LLMozLib for a SL viewer build unless you're hacking on LLMozLib itself or porting SL to a platform which we don't supply pre-built libraries for. Regards, - Tofu From kow at sapinski.com Fri Feb 23 11:19:50 2007 From: kow at sapinski.com (k\o\w) Date: Fri Feb 23 11:20:15 2007 Subject: [sldev] Client crash bug when opening map view In-Reply-To: <45DF35A0.9000702@lindenlab.com> References: <45DF35A0.9000702@lindenlab.com> Message-ID: <45DF3E56.5040705@sapinski.com> Hello. Recently, I've been experiencing a crash bug when opening the map on the latest SVN checkout of OpenSL when compiled under VS2005. I open the large map view, and the sim names and textures start appearing, but after a few seconds the client closes. I suspect the error comes from the LLMapLayerResponder reply, specifically, somewhere in the loop at line 100 in llmapresponders.cpp The last output I get in the console is: INFO: LLMapLayerResponder::result from capabilities The client simply closes, with no other messages. VS outputs the following message: Microsoft Visual Studio C Runtime Library has detected a fatal error in newview_noopt.exe. Press Break to debug the program or Continue to terminate the program. When I break, I'm presented with Microsoft's debug hook template. Here are the last few lines from the stack: newview_noopt.exe!_crt_debugger_hook(int _Reserved=27402980) Line 65 C newview_noopt.exe!_invalid_parameter(const wchar_t * pszExpression=0x00000000, const wchar_t * pszFunction=0x00000000, const wchar_t * pszFile=0x00000000, unsigned int nLine=0, unsigned int pReserved=0) Line 86 + 0x7 bytes C++ newview_noopt.exe!_invalid_parameter_noinfo() Line 99 + 0xc bytes C++ newview_noopt.exe!std::_Vector_const_iterator >::operator!=(const std::_Vector_const_iterator > & _Right={impl=??? }) Line 203 + 0xc bytes C++ > newview_noopt.exe!LLMapLayerResponder::result(const LLSD & result={...}) Line 100 + 0x4e bytes C++ I have discussed this in IRC and received a lot of help from AdamZaius. Unfortunately, his input was lost on me as I don't have any C++ or debugging experience other than simple code edits. [23:28] Basically, it's trying to access an unset item. I think I actually had to fix this myself because Intel C 9.1 threw a hissy fit about the code that generates that. [23:29] Two bugs to fix there. [23:30] 1. Put if a if(ptr == null) { abort! } bit of code around the code in the != operator overload for the LLSD class. [23:30] 2. Find why it's null (have to go further up the trace), and fix that too. I wouldn't know where to start with that, and the reason I'm posting to the mailing list is because shortly after someone else came into the IRC channel experiencing the same problem: [10:08] is here someone who exp.problem with "crash on opening worldmap" ? [10:20] means when i open the Worldmap, around 5secs laters the Viewer crashes So now that I know this isn't an obscure problem with my setup and possibly a bug, my question is: Has anyone else experienced this bug and fixed it? Or, does anyone have any input on how I can go about fixing it? How has peoples experience been with compiling FL under VS2003? I tried converting it to 2005 format and went through the tutorial of changing the code but could never get it working. I would prefer to work on the FL code personally, so if switching to VS2003 is a good solution to avoiding the above problem, that would be good enough for me. Thanks -k\o\w From tshephard at gmail.com Fri Feb 23 15:37:58 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Feb 23 15:38:01 2007 Subject: [sldev] mono embedded on SL client In-Reply-To: <000301c7575d$9dd3ffc0$d97bff40$@net> References: <20070222163139.MLAF407.ibm61aec.bellsouth.net@mail.bellsouth.net> <69F7B6B5-08E8-4F65-BC43-763F62F8DEFC@lindenlab.com> <45DDED35.3010302@lindenlab.com> <000301c7575d$9dd3ffc0$d97bff40$@net> Message-ID: <3b19a500702231537u720f6cfcwf56d3ff7c5dceb26@mail.gmail.com> Hey Jim, maybe you can Open Source your mono VM API contracts now so we can fit in our mono vm in such a way that it can easily be replace with yours when it gets open sourced. Unless you can give us some ideas on what your timeline for your mono vm is going to be.. On 2/23/07, Patrice Le Vexier wrote: > Rob, Jim, > > That would be awesome. > > Patrice > > -----Original Message----- > From: Rob Lanphier [mailto:robla@lindenlab.com] > Sent: Thursday, February 22, 2007 2:21 PM > To: Jim Purbrick > Cc: PLV > Subject: Re: [sldev] mono embedded on SL client > > On 2/22/07 9:10 AM, Jim Purbrick wrote: > > Rob, Is this something we could usefully kick off? If we're going to > > start embedding mono in the client I'd like to make sure it dovetails > > nicely with where we're going to be with Mono on the simulators. > Very possibly. > > > You will find that lots of the work I've done on the sim will cross > > over to the viewer, so it might be better to wait until that's open > > sourced before you start on this project. > > How self contained is this code? Perhaps we can actually release the bits > of code that are useful for this task. > > Rob > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From awolenc at nycap.rr.com Fri Feb 23 16:18:59 2007 From: awolenc at nycap.rr.com (Adam W) Date: Fri Feb 23 16:19:06 2007 Subject: [sldev] compile is ok, but i get error at startup In-Reply-To: <85e6f7f00702222215w126a8326hb83b39373f537cf7@mail.gmail.com> Message-ID: <011901c757a9$61d1fdf0$6401a8c0@taller> George, My first guess is that you didn't get all the files you need. If you get a latest release, such as (20070131a), everything is all in one place (well, two places if you count the libraries). But, if you move on to one of the FL viewers, the files you need are broken up in several places on this page https://wiki.secondlife.com/wiki/Source_downloads Make sure you have all four (or five) of the following: 1 The Viewer (on of Windows (CRLF) OR * Mac/Linux (LF)) (Sounds like you already have that) 2 Artwork 3 Libs (on of windows / mac / linux ) 4 Texture files (will be included with source next release) 5 If you are on mac, * Mac OS X libcares libraries (will be included with libraries next release) When you uncompress them, you'll notice that they are all have linden/ subfolders. Consolidate them all in the same linden/ folder and voila, you have a complete source code package. -Adam _____ From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of George Williams Sent: Friday, February 23, 2007 06:16 To: sldev@lists.secondlife.com Subject: [sldev] compile is ok, but i get error at startup Hi, I think I'm being a bonehead - can someone help? I am building "slviewer-src-FL-1.13.3.58018". It builds ok. When a start the program, I get a dialogue a few seconds later: "Second Life is unable to access a file that it needs. This can be because you somehow have multiple copies running, or your system incorrectly thinks a file is open. If this message persists, restart your computer and try again. If it continues to persist, you may need to complete uninstall Second Life and reinstall it." Thank for your help, in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070224/5cbb31f6/attachment.htm From synthalor.mandelbrot at inbox.com Fri Feb 23 16:29:05 2007 From: synthalor.mandelbrot at inbox.com (Synthalor Mandelbrot) Date: Fri Feb 23 16:29:19 2007 Subject: [sldev] Client crash bug when opening map view In-Reply-To: <45DF3E56.5040705@sapinski.com> References: <45df35a0.9000702@lindenlab.com> Message-ID: <57EDEC45582.00000C90synthalor.mandelbrot@inbox.com> Count Synthalor Mandelbrot with the same experience! Open the map, it starts to hum but doesn't sing and then goes silent. Sorry, but I haven't found enough "copious free time" to tangle with it myself, yet. Synth > -----Original Message----- > From: kow@sapinski.com > Sent: Fri, 23 Feb 2007 14:19:50 -0500 > To: sldev@lists.secondlife.com > Subject: [sldev] Client crash bug when opening map view > > Hello. > > Recently, I've been experiencing a crash bug when opening the map on the > latest SVN checkout of OpenSL when compiled under VS2005. ____________________________________________________________ ONE-CLICK WEBMAIL ACCESS - Easily monitor & access your email accounts! Visit http://www.inbox.com/notifier and check it out! From mindtriggerz at gmail.com Fri Feb 23 18:05:17 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Fri Feb 23 18:05:21 2007 Subject: [sldev] Client crash bug when opening map view In-Reply-To: <45DF3E56.5040705@sapinski.com> References: <45DF35A0.9000702@lindenlab.com> <45DF3E56.5040705@sapinski.com> Message-ID: IIRC, disabeling CAPS for maps fixes that all quick and dirty like. On 2/23/07, kow wrote: > Hello. > > Recently, I've been experiencing a crash bug when opening the map on the > latest SVN checkout of OpenSL when compiled under VS2005. > > I open the large map view, and the sim names and textures start > appearing, but after a few seconds the client closes. I suspect the > error comes from the LLMapLayerResponder reply, specifically, somewhere > in the loop at line 100 in llmapresponders.cpp > > The last output I get in the console is: > INFO: LLMapLayerResponder::result from capabilities > > The client simply closes, with no other messages. VS outputs the > following message: > > Microsoft Visual Studio C Runtime Library has detected a fatal error in > newview_noopt.exe. > Press Break to debug the program or Continue to terminate the program. > > When I break, I'm presented with Microsoft's debug hook template. Here > are the last few lines from the stack: > newview_noopt.exe!_crt_debugger_hook(int _Reserved=27402980) Line > 65 C > newview_noopt.exe!_invalid_parameter(const wchar_t * > pszExpression=0x00000000, const wchar_t * pszFunction=0x00000000, const > wchar_t * pszFile=0x00000000, unsigned int nLine=0, unsigned int > pReserved=0) Line 86 + 0x7 bytes C++ > newview_noopt.exe!_invalid_parameter_noinfo() Line 99 + 0xc > bytes C++ > > newview_noopt.exe!std::_Vector_const_iterator > >::operator!=(const > std::_Vector_const_iterator > & > _Right={impl=??? }) Line 203 + 0xc bytes C++ > > newview_noopt.exe!LLMapLayerResponder::result(const LLSD & > result={...}) Line 100 + 0x4e bytes C++ > > > I have discussed this in IRC and received a lot of help from AdamZaius. > Unfortunately, his input was lost on me as I don't have any C++ or > debugging experience other than simple code edits. > > [23:28] Basically, it's trying to access an unset item. I > think I actually had to fix this myself because Intel C 9.1 threw a > hissy fit about the code that generates that. > [23:29] Two bugs to fix there. > [23:30] 1. Put if a if(ptr == null) { abort! } bit of code > around the code in the != operator overload for the LLSD class. > [23:30] 2. Find why it's null (have to go further up the > trace), and fix that too. > > I wouldn't know where to start with that, and the reason I'm posting to > the mailing list is because shortly after someone else came into the IRC > channel experiencing the same problem: > > [10:08] is here someone who exp.problem with "crash on opening > worldmap" ? > [10:20] means when i open the Worldmap, around 5secs laters the > Viewer crashes > > So now that I know this isn't an obscure problem with my setup and > possibly a bug, my question is: Has anyone else experienced this bug and > fixed it? Or, does anyone have any input on how I can go about fixing it? > > How has peoples experience been with compiling FL under VS2003? I tried > converting it to 2005 format and went through the tutorial of changing > the code but could never get it working. I would prefer to work on the > FL code personally, so if switching to VS2003 is a good solution to > avoiding the above problem, that would be good enough for me. > > Thanks > -k\o\w > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- --Jesse From kow at sapinski.com Fri Feb 23 19:11:41 2007 From: kow at sapinski.com (k\o\w) Date: Fri Feb 23 19:12:12 2007 Subject: [sldev] Client crash bug when opening map view In-Reply-To: References: <45DF35A0.9000702@lindenlab.com> <45DF3E56.5040705@sapinski.com> Message-ID: <45DFACED.5090405@sapinski.com> That fix worked, thanks! To elaborate, in llworldmap.cpp at line 340 -- if (!url.empty()) ++ if (0) Jesse Nesbitt wrote: > IIRC, disabeling CAPS for maps fixes that all quick and dirty like. > > On 2/23/07, kow wrote: From seg at haxxed.com Fri Feb 23 19:37:07 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Feb 23 19:37:22 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <200702220127.05008.dale@daleglass.net> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> Message-ID: <1172288228.4322.34.camel@localhost.localdomain> On Thu, 2007-02-22 at 01:27 +0100, Dale Glass wrote: > So, without plugins what we get is: > > * SL official build > * Dale's build > * Opensecondlife build > * Opensecondlife with X patch > * Bob's tweaked client > ... > > and so on. Want my scanner? Run my client. Want voip? Run Bob's. Both at once? > Well, if you can't code and somebody doesn't bother to make a client with > both, you're out of luck. Not hard to imagine how that situation is less than > desirable. The proper thing to do is bless, say, OpenSL as the de-facto non-linden fork, and keep everything merged into the OpenSL tree as much as possible. I have no idea what the intentions of the OpenSL people are though, and if they're up to being the Linus Torvalds of Second Life. They might be, and they might not be. All I know is their web site currently doesn't tell me a damn thing about how OpenSL differs from mainline. God damn, this whole plugin thing is hilarious. Everyone's sitting around shooting their mouths off about hypotheticals, and no one is writing any code. This absolutely takes the cake: https://wiki.secondlife.com/wiki/Plugin_architecture_RoadMap Step EIGHT is implementation? Step NINE is example plugins? Hahahahah OMFG who comes up with this stuff? Step ONE is write code (like Dale). Then you can worry about isolating it into a plugin once you know what API you need, then you can generate bindings for Mono and Javascript and Lua and Python and Java and Fortran and whatever the hell other crack you feel like smoking. Don't make me start smacking people with copies of "The Art of Unix Programming." http://c2.com/xp/YouArentGonnaNeedIt.html http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html -------------- 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/20070223/b8b7e759/attachment-0001.pgp From tshephard at gmail.com Fri Feb 23 19:57:32 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Feb 23 19:57:35 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <1172288228.4322.34.camel@localhost.localdomain> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> Message-ID: <3b19a500702231957g398f3fc8we31f09ad3fd414f6@mail.gmail.com> > Step ONE is write code (like Dale). If you think step one is write code, then write some code. I really don't think anyone is stopping you. However, no complaining when your code doesn't get merged in, you find out the lindens had a completely different idea in mind about what they want to see, and all your work goes to waste. From seg at haxxed.com Fri Feb 23 20:06:05 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Feb 23 20:06:08 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <3b19a500702231957g398f3fc8we31f09ad3fd414f6@mail.gmail.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> <3b19a500702231957g398f3fc8we31f09ad3fd414f6@mail.gmail.com> Message-ID: <1172289965.4322.37.camel@localhost.localdomain> On Fri, 2007-02-23 at 19:57 -0800, Tim Shephard wrote: > > Step ONE is write code (like Dale). > > If you think step one is write code, then write some code. I really > don't think anyone is stopping you. > > However, no complaining when your code doesn't get merged in, you find > out the lindens had a completely different idea in mind about what > they want to see, and all your work goes to waste. Read, Comprehend, Post. In that order. -------------- 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/20070223/738ad5a7/attachment.pgp From tshephard at gmail.com Fri Feb 23 20:20:08 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Feb 23 20:20:11 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <1172289965.4322.37.camel@localhost.localdomain> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> <3b19a500702231957g398f3fc8we31f09ad3fd414f6@mail.gmail.com> <1172289965.4322.37.camel@localhost.localdomain> Message-ID: <3b19a500702232020g22680430i5b7aee938b847757@mail.gmail.com> Not sure what that means, but in case you're misunderstanding what I mean: For those of us who can not afford to write code that doesn't get merged in, we generally want to understand what will have a high degree of probability of getting merged in before we start work. So we ask certain questions to the those who can wave the merging wand: do the Linden's care about security? Is performance important? Are they concerned about the instability that loaded DLLs might cause on the client versus an embedded VM that mono could provide? If we do develop a plugin architecture for Linden Labs, will our code be protected by copyright or will we have to open source that as well? Some of us have zero desire to work on a plugin architecture, have it merged in, and only to find that we have to release all our plugin code under GPL. Perhaps they don't yet know exactly what they want to merge in, which is why a dialogue of some sort might want to start up with the decision makers on their side. Like any complicated group endeavor in life, a certain amount of forethought and dialogue between stakeholders is always a profitable thing. Getting some indications from a leadership level, the decision makers, about what they probably want versus what they probably do not want can only help the process. That all being said - let me say again: if you have the spare time to develop prototypes that may or may not get merged in, than I will be first in line to support your work. Heck, I might even send some L$ your way, if you give me your Second Life account name. Cheers, Tim. On 2/23/07, Callum Lerwick wrote: > On Fri, 2007-02-23 at 19:57 -0800, Tim Shephard wrote: > > > Step ONE is write code (like Dale). > > > > If you think step one is write code, then write some code. I really > > don't think anyone is stopping you. > > > > However, no complaining when your code doesn't get merged in, you find > > out the lindens had a completely different idea in mind about what > > they want to see, and all your work goes to waste. > > Read, Comprehend, Post. > > In that order. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From bbyer at mm.st Fri Feb 23 20:26:19 2007 From: bbyer at mm.st (Ben Byer) Date: Fri Feb 23 20:26:23 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <1172288228.4322.34.camel@localhost.localdomain> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> Message-ID: On Feb 23, 2007, at 7:37 PM, Callum Lerwick wrote: > The proper thing to do is bless, say, OpenSL as the de-facto non- > linden > fork, and keep everything merged into the OpenSL tree as much as > possible. Who's doing the blessing here? What does that even mean? > I have no idea what the intentions of the OpenSL people are though, > and > if they're up to being the Linus Torvalds of Second Life. They > might be, > and they might not be. All I know is their web site currently doesn't > tell me a damn thing about how OpenSL differs from mainline. ... OpenSL currently hosts the only publicly available SVN repo for SecondLife viewer code. We have several other services available, feel free how to have a look around. Maybe you're looking for a ChangeLog? http://opensecondlife.org/svn/ index.cgi/opensl/trunk/?view=log There are some notes about intent here: http://opensecondlife.org/ wiki/OpenSL:About#mission > God damn, this whole plugin thing is hilarious. Everyone's sitting > around shooting their mouths off about hypotheticals, and no one is > writing any code. Thanks for the constructive input. > Step ONE is write code (like Dale). Then you can worry about isolating *cough* > it into a plugin once you know what API you need, then you can > generate > bindings for Mono and Javascript and Lua and Python and Java and > Fortran > and whatever the hell other crack you feel like smoking. > > Don't make me start smacking people with copies of "The Art of Unix > Programming." How about you start smacking people with some code, or at least take a slightly more helpful approach? -b From mathew at lifeart.net.au Fri Feb 23 20:27:04 2007 From: mathew at lifeart.net.au (Mathew Frank) Date: Fri Feb 23 20:27:05 2007 Subject: [sldev] Lip-sync; was: Plugin architecture In-Reply-To: <45DE1868.3080002@watson.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <200702222156.07839.dale@daleglass.net> <6E0A6592-256B-41D2-92A7-49E20D86D5CD@secondlife.com> <45DE1868.3080002@watson.ibm.com> Message-ID: <45DFBE98.9080501@lifeart.net.au> I'm also interested in this. Lip-sync is the perfect voice complement - is this what you mean? Or are you talking about just an improvement in what facial expressions are avilable? Cheers, Mathew Mike Monkowski wrote: > Phoenix wrote: >> Just so everyone knows, we are already working on lip and gesture >> motions for the avatar. This is no promise of functionality or when >> it will be available, but it is in the pipeline and under active >> development. > > Could you clarify this a bit. It appears to me that the avatars > already have mouth morphs and gestures that can be synced to text > chat. Are you saying that you will sync these to live speech, > text-to-speech, recorded speech, or what? > > Mike > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > __________ NOD32 2076 (20070222) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > From gigstaggart at gmail.com Fri Feb 23 20:37:22 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Feb 23 20:37:19 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <3b19a500702232020g22680430i5b7aee938b847757@mail.gmail.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> <3b19a500702231957g398f3fc8we31f09ad3fd414f6@mail.gmail.com> <1172289965.4322.37.camel@localhost.localdomain> <3b19a500702232020g22680430i5b7aee938b847757@mail.gmail.com> Message-ID: <45DFC102.3000900@gmail.com> Tim Shephard wrote: > Not sure what that means, but in case you're misunderstanding what I mean: > > For those of us who can not afford to write code that doesn't get > merged in, we generally want to understand what will have a high > degree of probability of getting merged in before we start work. We've been over that. It's not the way open source works. Hans Reiser devoted a large portion of his life to something that might have never been merged into Linux. If he wanted to wait for official sign-offs from Linus on code that didn't exist yet, he'd still be waiting. > > So we ask certain questions to the those who can wave the merging > wand: do the Linden's care about security? Is performance > important? Are they concerned about the instability that loaded > DLLs might cause on the client versus an embedded VM that mono could > provide? > No one is in a position to answer questions about a patch they haven't seen yet! The code *must* come first. > If we do develop a plugin architecture for Linden Labs, will our code > be protected by copyright or will we have to open source that as well? > Some of us have zero desire to work on a plugin architecture, have > it merged in, and only to find that we have to release all our plugin > code under GPL. > That is a valid question. Assuming there is a tight enough coupling to make a "derived work" legally (which is a gray area in copyright law regarding runtime loaded modules)... If you released your plugin as GPL, it wouldn't be compatible with the SL client license anyway, GPL+FLOSS exceptions is *not* GPL compatible. The idea many of us have is that the low level plugins would likely mainly expose higher level functionality. For example SL-Python might be a low level plugin, then you can actually write the guts of your plugin in Python and be free of license concerns. In the end though you are asking a legal question no one knows the answer to. No one really knows how tight coupling must be to create a derived work. Most people consider normal dynamic linking to be close enough, and the FSF would probably consider even runtime loading close enough (as per their views on Java and GPL). Even if LL says informally that it's "OK", that wouldn't change the legality of it without some official license exception from LL. > Perhaps they don't yet know exactly what they want to merge in, which > is why a dialogue of some sort might want to start up with the > decision makers on their side. > They can't know until the code is written. They've said they aren't going to buy into anything sight unseen. > Like any complicated group endeavor in life, a certain amount of > forethought and dialogue between stakeholders is always a profitable > thing. Getting some indications from a leadership level, the > decision makers, about what they probably want versus what they > probably do not want can only help the process. You have a PMI certification, am I right? -Jason From robla at lindenlab.com Fri Feb 23 20:37:24 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Feb 23 20:37:35 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <1172288228.4322.34.camel@localhost.localdomain> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> Message-ID: <45DFC104.4060308@lindenlab.com> Callum, First, let me pull out the parts that I agree with: http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html I agree that people should read and absorb that. I also agree that a really, really good thing to do would be to follow Dale's lead. Extend the client, figure out how to refactor things so that it's a clean extension, and integrate the patches. Now for the rest: On 2/23/07 7:37 PM, Callum Lerwick wrote: > The proper thing to do is bless, say, OpenSL as the de-facto non-linden > fork, and keep everything merged into the OpenSL tree as much as > possible. > The proper thing for who to do? > ...this whole plugin thing is hilarious. Everyone's sitting > around shooting their mouths off about hypotheticals, and no one is > writing any code. > I agree that a lot of talk and no code can be frustrating. Some people are talking because they aren't sure what code to write yet, other people are talking because that's all they know how to do. We're all still getting to know each other, and trying to figure out how to work together. Even people who can't code can actually be useful to this process. There's no need to be rude. If you know exactly what needs to be written, then I'd suggest you give it a shot. Since we don't really have a consensus at Linden Lab how plugins should work (that I'm aware of), I'm kinda skeptical that you'd get it right on the first crack. If you're up to the job of maintaining your own fork, fine, but if you expect us to incorporate it, you might want to check in with us before sinking a ton of time into it. One thing that's challenging about this particular piece of functionality is that Linden Lab would be expected to support whatever emerges for quite a while, where some people may even expect bug-for-bug compatibility of the interface in perpetuity. We don't plan to bend to every unrealistic expectation of every developer out there, but I think it's fair to expect at least some degree of interface stability. Therefore, I seriously doubt that we'd incorporate anything without serious deliberation on the subject. Regardless, would you please be respectful and courteous? The rules for this mailing list are more or less the same as the forum: http://secondlife.com/knowledgebase/article.php?id=061 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/20070223/89f1ba82/signature.pgp From seg at haxxed.com Fri Feb 23 20:43:39 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Feb 23 20:43:59 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <3b19a500702232020g22680430i5b7aee938b847757@mail.gmail.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> <3b19a500702231957g398f3fc8we31f09ad3fd414f6@mail.gmail.com> <1172289965.4322.37.camel@localhost.localdomain> <3b19a500702232020g22680430i5b7aee938b847757@mail.gmail.com> Message-ID: <1172292219.4322.42.camel@localhost.localdomain> On Fri, 2007-02-23 at 20:20 -0800, Tim Shephard wrote: > If we do develop a plugin architecture for Linden Labs, will our code > be protected by copyright or will we have to open source that as well? > Some of us have zero desire to work on a plugin architecture, have > it merged in, and only to find that we have to release all our plugin > code under GPL. So, you're saying the only reason you're interested in a plugin architecture is as a way to weasel your way around the GPL and implement proprietary extensions? Wow, no one ever thought of that one before! Good luck with that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070223/4e1cc2db/attachment-0001.pgp From tshephard at gmail.com Fri Feb 23 20:50:03 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Feb 23 20:50:06 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DFC102.3000900@gmail.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> <3b19a500702231957g398f3fc8we31f09ad3fd414f6@mail.gmail.com> <1172289965.4322.37.camel@localhost.localdomain> <3b19a500702232020g22680430i5b7aee938b847757@mail.gmail.com> <45DFC102.3000900@gmail.com> Message-ID: <3b19a500702232050l6608e880ue1e29aca9f0fff57@mail.gmail.com> > No one is in a position to answer questions about a patch they haven't > seen yet! The code *must* come first. No, I do not think that nor wish life to be black and white. I'm not looking for a contract signed in blood that they will merge my code, I'm just looking for some indications from the decision makers of what they're likely to merge and what they'd hate to merge. The more specific they can be, the more code I can write. From tshephard at gmail.com Fri Feb 23 20:51:29 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Feb 23 20:51:33 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <1172292219.4322.42.camel@localhost.localdomain> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> <3b19a500702231957g398f3fc8we31f09ad3fd414f6@mail.gmail.com> <1172289965.4322.37.camel@localhost.localdomain> <3b19a500702232020g22680430i5b7aee938b847757@mail.gmail.com> <1172292219.4322.42.camel@localhost.localdomain> Message-ID: <3b19a500702232051n7a6013f7ib1753ad4c2dfc89a@mail.gmail.com> On 2/23/07, Callum Lerwick wrote: > On Fri, 2007-02-23 at 20:20 -0800, Tim Shephard wrote: > > If we do develop a plugin architecture for Linden Labs, will our code > > be protected by copyright or will we have to open source that as well? > > Some of us have zero desire to work on a plugin architecture, have > > it merged in, and only to find that we have to release all our plugin > > code under GPL. > > So, you're saying the only reason you're interested in a plugin > architecture is as a way to weasel your way around the GPL and implement > proprietary extensions? Wow, no one ever thought of that one before! > I wouldn't use the word "weasel", but absolutely, that would be my only interest. I am glad we have come to a clear understanding! From tshephard at gmail.com Fri Feb 23 21:54:12 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Feb 23 21:54:15 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DE04A6.5080003@lindenlab.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <45DE04A6.5080003@lindenlab.com> Message-ID: <3b19a500702232154i33459bb1g875bf0b54641ce52@mail.gmail.com> I think some way to communicate from LSL to the Plugins would be very useful in many situations as well. LSL has access to listen, email, dataserver, sensor, llDetected() and many other critical information gathering events... communicating that information to the PlugIn could be very useful. Heuristic: I recommend surveying all the HUDs currently in use as potential plugins. On 2/22/07, Kelly Washington wrote: > Mike Monkowski wrote: > > Dale Glass wrote: > >> LSL scripts will never be able to do some things. Like for example > >> changing how rendering works. Or integrating things like text to > >> speech and voip. > > > > The reason I asked about plugins is because I'm trying to figure out > > how to implement lip-sync. After looking at the code and reading the > > replies in this forum, I can't see how a plugin could ever work for > > lip-sync. I can't see rendering being done in a plugin either. TTS > > probably could because TTS can get text from the message stream and > > add to the audio stream. > > > > It seems to me that plugins must have limited capabilities based on > > limited access to data. > > > > LSL operates on objects, so it would make sense that if you want to > > operate on objects in a way that's currently not possible, extend LSL. > > If you want to operate on the message stream, then use a message > > stream plugin. I could imagine audio plugins and access to floaters > > that you could fill with whatever content you like, but I can't > > imagine access to all of the internal data from a plugin. > > > > Mike > > _______________________________________________ > > Click here to unsubscribe or manage your list subscription: > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > This is an excellent point. There will have to be a line drawn > somewhere between what can be a plugin and what requires a separate > client or re-compile. This line does not need to be fixed in stone at > the creation of the plugin system. In fact the best approach may be to > start conservatively with very little on the plugin side. This would > allow the system to get out, get tested, get used and get refined > quicker than building an all-encompassing plugin system from the start. > The plugin system of course then needs to be extendable, but even an > all-encompassing attempt should be extendable to allow for future core > source changes and new features. > > Along this route, what is the minimal needed to create a plugin system > that can at least make some useful plugins? > My guess is the following: > - create a floater, be able to populate and update data in the > floater. By this I just mean set text, set images, add/remove items > from scroll lists. > - add UI to bring up the floater. As a first pass even just a > 'plugins' menu with a menu item for each loaded plug in. > - access to specific internal data - ie the list of visible avatars, > region name, current location etc. > > Now that won't let you create just any plugin, it won't even let you > create most plugins (I'm sure everyone noticed there is nothing about > handling messages at all), but that is my guess as to the minimal needed > by a plugin. > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From gigstaggart at gmail.com Fri Feb 23 22:21:32 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri Feb 23 22:21:32 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <3b19a500702232154i33459bb1g875bf0b54641ce52@mail.gmail.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <45DE04A6.5080003@lindenlab.com> <3b19a500702232154i33459bb1g875bf0b54641ce52@mail.gmail.com> Message-ID: <45DFD96C.3030804@gmail.com> Tim Shephard wrote: > I think some way to communicate from LSL to the Plugins would be very > useful in many situations as well. > It goes beyond plugins, we need a way to communicate from LSL to other built-in client enhancements we might develop too. I'm working on an idea for that. I'll put up a wiki page on it tomorrow. > LSL has access to listen, email, dataserver, sensor, llDetected() and > many other critical information gathering events... communicating that > information to the PlugIn could be very useful. And slow, considering the client can directly do some of that stuff a lot more efficiently, but it might be a start. > Heuristic: I recommend surveying all the HUDs currently in use as > potential plugins. That's very limited thinking. Most of the stuff I'd want to do with plugins have nothing in common with the stuff that HUDs do. -Jason From tshephard at gmail.com Fri Feb 23 22:39:15 2007 From: tshephard at gmail.com (Tim Shephard) Date: Fri Feb 23 22:39:18 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DFD96C.3030804@gmail.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <45DE04A6.5080003@lindenlab.com> <3b19a500702232154i33459bb1g875bf0b54641ce52@mail.gmail.com> <45DFD96C.3030804@gmail.com> Message-ID: <3b19a500702232239g4987f606sbb4dbab95eb9834e@mail.gmail.com> On 2/23/07, Jason Giglio wrote: > Tim Shephard wrote: > > I think some way to communicate from LSL to the Plugins would be very > > useful in many situations as well. > > > > It goes beyond plugins, we need a way to communicate from LSL to other > built-in client enhancements we might develop too. I'm working on an > idea for that. I'll put up a wiki page on it tomorrow. > You have in mind built-in client enhancements that shouldn't be apart of a plugin architecture? I'll look forward to your wiki page.. This is critical functionality for me. I'm glad that we both see that LSL <-> Client communication is important. From robla at lindenlab.com Fri Feb 23 22:59:00 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Fri Feb 23 22:59:11 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DFD96C.3030804@gmail.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <45DE04A6.5080003@lindenlab.com> <3b19a500702232154i33459bb1g875bf0b54641ce52@mail.gmail.com> <45DFD96C.3030804@gmail.com> Message-ID: <45DFE234.5030806@lindenlab.com> On 2/23/07 10:21 PM, Jason Giglio wrote: > Tim Shephard wrote: >> I think some way to communicate from LSL to the Plugins would be very >> useful in many situations as well. > It goes beyond plugins, we need a way to communicate from LSL to other > built-in client enhancements we might develop too. I'm working on an > idea for that. I'll put up a wiki page on it tomorrow. When you say "need", do you mean for the very first plugin interface? I really hope you aren't expecting LSL modifications to be a prerequisite for the first version of plugins. I think the most successful model for creating the first plugin interface is to collaborate with Dale Glass on his extension, figuring out what is necessary for that. Over time, we can evolve deeper and deeper hooks. However, I think it's /very/ important to start simple. 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/20070223/7d88dbc4/signature.pgp From seg at haxxed.com Fri Feb 23 23:33:13 2007 From: seg at haxxed.com (Callum Lerwick) Date: Fri Feb 23 23:33:23 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> Message-ID: <1172302393.4322.63.camel@localhost.localdomain> On Fri, 2007-02-23 at 20:26 -0800, Ben Byer wrote: > On Feb 23, 2007, at 7:37 PM, Callum Lerwick wrote: > > > The proper thing to do is bless, say, OpenSL as the de-facto non- > > linden > > fork, and keep everything merged into the OpenSL tree as much as > > possible. > > Who's doing the blessing here? What does that even mean? The community does the blessing. You cultivate a community around OpenSL. This is the very essence of a successful Open Source project. Unless that's not what your mission is. -------------- 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/20070224/1e1ca499/attachment.pgp From tshephard at gmail.com Sat Feb 24 00:12:34 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 00:12:38 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DFE234.5030806@lindenlab.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <45DE04A6.5080003@lindenlab.com> <3b19a500702232154i33459bb1g875bf0b54641ce52@mail.gmail.com> <45DFD96C.3030804@gmail.com> <45DFE234.5030806@lindenlab.com> Message-ID: <3b19a500702240012o4441e508s9ae486ec729fdaf4@mail.gmail.com> I hope Dale answers this thread, but I do recall that LSL -> Plugin communication was important to him in order to enable his TrustNet functionality. I believe his logic was that he needed the TrustNet server requests to come from SL in order to ensure that they were properly being authenticated (owner key is sent in requests headers), otherwise he'd have to set up a seperate authentication process. Question for the Lindens: is communication from the servers to the client unreliable because of the udp transport? Would you have to set up a seperate TCP channel (which I can imagine would be quite a lot of work) in order to ensure reliable communication between sims and client? Even then I guess communication would have reliability issues as compared to the current IPC via LSL llSay / lllisten.. On 2/23/07, Rob Lanphier wrote: > On 2/23/07 10:21 PM, Jason Giglio wrote: > > Tim Shephard wrote: > >> I think some way to communicate from LSL to the Plugins would be very > >> useful in many situations as well. > > It goes beyond plugins, we need a way to communicate from LSL to other > > built-in client enhancements we might develop too. I'm working on an > > idea for that. I'll put up a wiki page on it tomorrow. > When you say "need", do you mean for the very first plugin interface? I > really hope you aren't expecting LSL modifications to be a prerequisite > for the first version of plugins. > > I think the most successful model for creating the first plugin > interface is to collaborate with Dale Glass on his extension, figuring > out what is necessary for that. Over time, we can evolve deeper and > deeper hooks. However, I think it's /very/ important to start simple. > > Rob > > > From seg at haxxed.com Sat Feb 24 01:06:38 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Feb 24 01:06:53 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DFC104.4060308@lindenlab.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> <45DFC104.4060308@lindenlab.com> Message-ID: <1172307998.4322.112.camel@localhost.localdomain> On Fri, 2007-02-23 at 20:37 -0800, Rob Lanphier wrote: > On 2/23/07 7:37 PM, Callum Lerwick wrote: > > The proper thing to do is bless, say, OpenSL as the de-facto non-linden > > fork, and keep everything merged into the OpenSL tree as much as > > possible. > > > The proper thing for who to do? The proper thing for those interested in implementing features that LL is not. That was the context of my reply. > > ...this whole plugin thing is hilarious. Everyone's sitting > > around shooting their mouths off about hypotheticals, and no one is > > writing any code. > > > I agree that a lot of talk and no code can be frustrating. I'm not frustrated. I'm amused. > If you know exactly what needs to be written, then I'd suggest you give > it a shot. Since we don't really have a consensus at Linden Lab how > plugins should work (that I'm aware of), I don't know what needs to be written, YOU don't know what needs to be written, no one else at LL knows what needs to be written. That's the point. You start with what you do know, and you go from there. > I'm kinda skeptical that you'd get it right on the first crack. Exactly. No one in the world is going to get it right on the first crack. It doesn't happen that way. It just doesn't. That is why expecting to have a complete design done before writing any code is a waste of time, because your design is going to be wrong. Guaranteed. Embracing this reality is the essence of "Extreme Programming" or "Agile Development" or whatever they're calling it these days, as well as being a cornerstone of open source development. Besides, http://c2.com/xp/TheSourceCodeIsTheDesign.html "Design is not something that you do only before you code. Implementation is not the act of coding." At this point the plugin architecture is a solution looking for a problem. YAGNI. Its all a pointless waste of time until there's an actual need. Not a hypothetical one. Once there's an actual need, the way forward becomes clear. Just write code, the rest will follow. > If you're up to the job of maintaining > your own fork, fine, but if you expect us to incorporate it, you might > want to check in with us before sinking a ton of time into it. One > thing that's challenging about this particular piece of functionality is > that Linden Lab would be expected to support whatever emerges for quite > a while, where some people may even expect bug-for-bug compatibility of > the interface in perpetuity. We don't plan to bend to every unrealistic > expectation of every developer out there, but I think it's fair to > expect at least some degree of interface stability. Therefore, I > seriously doubt that we'd incorporate anything without serious > deliberation on the subject. The real point I'm trying to get at, is that the thinking behind plugins here is an artifact of close source development. Its Windows thinking. One person has admitted that the only reason they want plugins is so they can weasel around the GPL, shun the community and release proprietary code. Is this what Linden Lab wants? Proprietary extensions? If so, why was it licensed under the GPL rather than something BSDish? Proprietary plugins are completely and totally antithetical to the purpose of the GPL. Linden Lab has decided to share their source code with all of us, under the terms of the GPL. If you think you have any right to benefit from the viewer source without sharing with the community, you're wrong. Unless LL has granted you a different license... > Regardless, would you please be respectful and courteous? Sorry, I'll try and tone myself down a bit... -------------- 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/20070224/e2d353e3/attachment.pgp From tshephard at gmail.com Sat Feb 24 02:27:25 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 02:27:30 2007 Subject: [sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI Message-ID: <3b19a500702240227h52fcc2b7ld1f86db6b57cf923@mail.gmail.com> For those who like to see code and specifics and dislike the theoretical conversations, I'd like to propose two solutions that I hope are somewhat specific in concept so they can be easily discussed. The first one is inheritance across DLLs. The idea behind this one is that people could extend llFloater (and similar classes) in their DLL and then register that class with the main UI Factory in SL. Further hooks into the main message via macros that Bushing has prototyped would allow intercepting messages. SL itself could be broken up into DLL(s) and export functions which the plugin could import to add to the message queue. These functions would just be ones that currently exist. The advantage to this is that it would certainly get Dale's plugin up and running very quickly. I haven't seen the code, but I assuming he's just extending llFloater or a similar SL UI widget as recommended by the wiki. Well placed macros could call his code where he's updating his avatar list. I assume there needs to be a way to trigger a refresh of his UI (correct me if I'm wrong here) when new information comes in. The advantages of this approach is that it will work very well with what LL currently has, it will even be a great way to get people involved in the code base for future employment opportunities. The disadvantage, and I think this is a big one, is that I'm not entirely sure how stable this approach is or how cross platform it might be (the attached proof of concept is win32 only). Right now the biggest caveat you need to follow when doing this approach is making sure all DLLs are compiled with the same options. Questions for the DLL gurus: do all dlls/so's/mac equivalent maintain their own heap? How are vtables implemented on the various platforms and will it effect this solution? The other solution is NPAPI, here is a link: http://web.archive.org/web/20040203102018/devedge.netscape.com/library/manuals/2002/plugin/1.0/intro.html#998197 While I like is the simplicity of this model I am concerned with is that I'm not sure how it can enable Dale's plugin. Questions: How does Dale's floater panel get drawn? Do you have two UIFactories and loops? Would it be like a flash or java plugin? Possibly, we could export the widget drawing functions from an SL DLL and then call those on an internal window. Basically duplicate a copy of the SL widget loop, but have it changed so that it is only working on the internal window as described by the plugin. Kind of a mini client inside the client. Advantages: simple, stable, hopefully not processor intensive or memory intensive. Disadvantages: would require some re factoring of the UI system to work on a sub window (I think). Probably requires a seperate thread, which may create costly problems as they do battle for the CPU. We'd probably have to cut/paste the code and alter it in order to not interfere with LL engineering / introduce bugs in to the core code base. These are just two solutions and I propose them only for discussion. I hope this will not discourage people from discussing other ideas, such as the Separate Process / Proxy solution which I actually find very intriguing. Especially since it's ready to go, and because it will enable a significant amount of stability in the client. There is also a great deal of experience with this project. The concern, of course, is CPU sharing between processes. Cheers, Tim. -------------- next part -------------- A non-text attachment was scrubbed... Name: inherit.zip Type: application/zip Size: 88515 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070224/890c0120/inherit-0001.zip From seg at haxxed.com Sat Feb 24 02:41:35 2007 From: seg at haxxed.com (Callum Lerwick) Date: Sat Feb 24 02:41:45 2007 Subject: llmozlib (was: Re: [sldev] Linking fails with FL-1.13.3.58185 (cannot find llmozlib)) In-Reply-To: <45DE9815.7040700@lindenlab.com> References: <45DE9815.7040700@lindenlab.com> Message-ID: <1172313696.4322.117.camel@localhost.localdomain> On Thu, 2007-02-22 at 23:30 -0800, Rob Lanphier wrote: > It'd be pretty cool if it were easier to disable llmozlib without the > need to comment out large swaths of the SConstruct file. Any volunteers > to simplify this process? The SConstruct file is Python, so the > addition of a boolean should be pretty straightforward if you can resist > the temptation to refactor it into subroutines (which it's probably due > for, imho, but don't take that to mean I'm volunteering to do it just yet). Ugh. The stock SConstruct is an absolute disaster for those of us compiling without the binary library blob. I've already had to hack the hell out of it for my Fedora package. Making it into nice booleans that can be merged upstream is on my to do list. -------------- 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/20070224/4f21667b/attachment.pgp From tshephard at gmail.com Sat Feb 24 02:43:29 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 02:43:33 2007 Subject: [sldev] Re: Two potential plugin architectures: Inheritance across DLLs and NPAPI In-Reply-To: <3b19a500702240227h52fcc2b7ld1f86db6b57cf923@mail.gmail.com> References: <3b19a500702240227h52fcc2b7ld1f86db6b57cf923@mail.gmail.com> Message-ID: <3b19a500702240243n33f68f49k63ea5c3d654c7297@mail.gmail.com> The other idea for NPAPI, might be to create a shadow UI object in the main code base, call it llFloaterPlugin, and the virtual methods of that llFloater child would call out to procs which are exported by the plugin itself. When the SLPAPI function calls the plugin on initialization, it would call out to a list of these floaters and their function sets and how they're initiated by the user (eg, global keystrokes, menu items, etc). This probably wouldn't be too hard to do from where we stand right now. On 2/24/07, Tim Shephard wrote: > For those who like to see code and specifics and dislike the > theoretical conversations, I'd like to propose two solutions that I > hope are somewhat specific in concept so they can be easily discussed. > > > The first one is inheritance across DLLs. > > The idea behind this one is that people could extend llFloater (and > similar classes) in their DLL and then register that class with the > main UI Factory in SL. > > Further hooks into the main message via macros that Bushing has > prototyped would allow intercepting messages. > > SL itself could be broken up into DLL(s) and export functions which > the plugin could import to add to the message queue. These functions > would just be ones that currently exist. > > The advantage to this is that it would certainly get Dale's plugin up > and running very quickly. I haven't seen the code, but I assuming > he's just extending llFloater or a similar SL UI widget as recommended > by the wiki. Well placed macros could call his code where he's > updating his avatar list. I assume there needs to be a way to > trigger a refresh of his UI (correct me if I'm wrong here) when new > information comes in. > > The advantages of this approach is that it will work very well with > what LL currently has, it will even be a great way to get people > involved in the code base for future employment opportunities. > > The disadvantage, and I think this is a big one, is that I'm not > entirely sure how stable this approach is or how cross platform it > might be (the attached proof of concept is win32 only). > Right now the biggest caveat you need to follow when doing this > approach is making sure all DLLs are compiled with the same options. > > Questions for the DLL gurus: do all dlls/so's/mac equivalent maintain > their own heap? How are vtables implemented on the various platforms > and will it effect this solution? > > > > The other solution is NPAPI, here is a link: > > http://web.archive.org/web/20040203102018/devedge.netscape.com/library/manuals/2002/plugin/1.0/intro.html#998197 > > While I like is the simplicity of this model I am concerned with is > that I'm not sure how it can enable Dale's plugin. > > Questions: > > How does Dale's floater panel get drawn? > Do you have two UIFactories and loops? > Would it be like a flash or java plugin? > > Possibly, we could export the widget drawing functions from an SL DLL > and then call those on an internal window. Basically duplicate a > copy of the SL widget loop, but have it changed so that it is only > working on the internal window as described by the plugin. > Kind of a mini client inside the client. > > Advantages: simple, stable, hopefully not processor intensive or > memory intensive. > Disadvantages: would require some re factoring of the UI system to > work on a sub window (I think). Probably requires a seperate > thread, which may create costly problems as they do battle for the > CPU. > > We'd probably have to cut/paste the code and alter it in order to not > interfere with LL engineering / introduce bugs in to the core code > base. > > These are just two solutions and I propose them only for discussion. > > I hope this will not discourage people from discussing other ideas, > such as the Separate Process / Proxy solution which I actually find > very intriguing. > > Especially since it's ready to go, and because it will enable a > significant amount of stability in the client. There is also a great > deal of experience with this project. The concern, of course, is CPU > sharing between processes. > > Cheers, > > Tim. > > From tshephard at gmail.com Sat Feb 24 03:41:12 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 03:41:16 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <1172307998.4322.112.camel@localhost.localdomain> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> <45DFC104.4060308@lindenlab.com> <1172307998.4322.112.camel@localhost.localdomain> Message-ID: <3b19a500702240341n11ec6ddblb98e42e33f29d935@mail.gmail.com> > Proprietary plugins are completely and totally antithetical to the > purpose of the GPL. Linden Lab has decided to share their source code > with all of us, under the terms of the GPL. If you think you have any > right to benefit from the viewer source without sharing with the > community, you're wrong. Unless LL has granted you a different > license... I think everyone can benefit from proprietary extensions, much in the way both the users and the platform of Apple, Windows, or Linux benefit when someone develops proprietary 'extensions' for those operating systems. Anyways, this is a critical point, and I'm glad that you're dragging it out, because it needs clarification from LL legal (ie: Ginsu Yoon) Are we going to get an exception for our plugins or not? On 2/24/07, Callum Lerwick wrote: > On Fri, 2007-02-23 at 20:37 -0800, Rob Lanphier wrote: > > On 2/23/07 7:37 PM, Callum Lerwick wrote: > > > The proper thing to do is bless, say, OpenSL as the de-facto non-linden > > > fork, and keep everything merged into the OpenSL tree as much as > > > possible. > > > > > The proper thing for who to do? > > The proper thing for those interested in implementing features that LL > is not. That was the context of my reply. > > > > ...this whole plugin thing is hilarious. Everyone's sitting > > > around shooting their mouths off about hypotheticals, and no one is > > > writing any code. > > > > > I agree that a lot of talk and no code can be frustrating. > > I'm not frustrated. I'm amused. > > > If you know exactly what needs to be written, then I'd suggest you give > > it a shot. Since we don't really have a consensus at Linden Lab how > > plugins should work (that I'm aware of), > > I don't know what needs to be written, YOU don't know what needs to be > written, no one else at LL knows what needs to be written. That's the > point. You start with what you do know, and you go from there. > > > I'm kinda skeptical that you'd get it right on the first crack. > > Exactly. No one in the world is going to get it right on the first > crack. It doesn't happen that way. It just doesn't. That is why > expecting to have a complete design done before writing any code is a > waste of time, because your design is going to be wrong. Guaranteed. > > Embracing this reality is the essence of "Extreme Programming" or "Agile > Development" or whatever they're calling it these days, as well as being > a cornerstone of open source development. > > Besides, http://c2.com/xp/TheSourceCodeIsTheDesign.html > > "Design is not something that you do only before you code. > Implementation is not the act of coding." > > At this point the plugin architecture is a solution looking for a > problem. YAGNI. Its all a pointless waste of time until there's an > actual need. Not a hypothetical one. Once there's an actual need, the > way forward becomes clear. Just write code, the rest will follow. > > > If you're up to the job of maintaining > > your own fork, fine, but if you expect us to incorporate it, you might > > want to check in with us before sinking a ton of time into it. One > > thing that's challenging about this particular piece of functionality is > > that Linden Lab would be expected to support whatever emerges for quite > > a while, where some people may even expect bug-for-bug compatibility of > > the interface in perpetuity. We don't plan to bend to every unrealistic > > expectation of every developer out there, but I think it's fair to > > expect at least some degree of interface stability. Therefore, I > > seriously doubt that we'd incorporate anything without serious > > deliberation on the subject. > > The real point I'm trying to get at, is that the thinking behind plugins > here is an artifact of close source development. Its Windows thinking. > > One person has admitted that the only reason they want plugins is so > they can weasel around the GPL, shun the community and release > proprietary code. Is this what Linden Lab wants? Proprietary extensions? > If so, why was it licensed under the GPL rather than something BSDish? > > Proprietary plugins are completely and totally antithetical to the > purpose of the GPL. Linden Lab has decided to share their source code > with all of us, under the terms of the GPL. If you think you have any > right to benefit from the viewer source without sharing with the > community, you're wrong. Unless LL has granted you a different > license... > > > Regardless, would you please be respectful and courteous? > > Sorry, I'll try and tone myself down a bit... > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From awolenc at nycap.rr.com Sat Feb 24 07:33:23 2007 From: awolenc at nycap.rr.com (Adam W) Date: Sat Feb 24 07:33:41 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <1172307998.4322.112.camel@localhost.localdomain> Message-ID: <016601c75829$213d7e10$6401a8c0@taller> Hi, all. I'm new to open source, but not new to programming, and certainly not new to sitting down at the computer and writing code without a plan. My (innocent) question is, what happens when you code yourself into a corner, and realize you should have done it diffenerently, but now its too late, because everyone else already expects it to be the way it is. You can't undo what you've already released to the community. How do you back yourself out of mistakes, under this system? Adam -----Original Message----- From: sldev-bounces@lists.secondlife.com [mailto:sldev-bounces@lists.secondlife.com] On Behalf Of Callum Lerwick Sent: Saturday, February 24, 2007 09:07 To: sldev@lists.secondlife.com Subject: Re: [sldev] Re: Plugin architecture On Fri, 2007-02-23 at 20:37 -0800, Rob Lanphier wrote: > I'm kinda skeptical that you'd get it right on the first crack. Exactly. No one in the world is going to get it right on the first crack. It doesn't happen that way. It just doesn't. That is why expecting to have a complete design done before writing any code is a waste of time, because your design is going to be wrong. Guaranteed. Embracing this reality is the essence of "Extreme Programming" or "Agile Development" or whatever they're calling it these days, as well as being a cornerstone of open source development. Besides, http://c2.com/xp/TheSourceCodeIsTheDesign.html "Design is not something that you do only before you code. Implementation is not the act of coding." At this point the plugin architecture is a solution looking for a problem. YAGNI. Its all a pointless waste of time until there's an actual need. Not a hypothetical one. Once there's an actual need, the way forward becomes clear. Just write code, the rest will follow. From dale at daleglass.net Sat Feb 24 07:40:06 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Feb 24 07:40:28 2007 Subject: [sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI In-Reply-To: <3b19a500702240227h52fcc2b7ld1f86db6b57cf923@mail.gmail.com> References: <3b19a500702240227h52fcc2b7ld1f86db6b57cf923@mail.gmail.com> Message-ID: <200702241640.13985.dale@daleglass.net> ? ????????? ?? 24 ??????? 2007 11:27 Tim Shephard ???????(a): > The advantage to this is that it would certainly get Dale's plugin up > and running very quickly. I haven't seen the code, but I assuming > he's just extending llFloater or a similar SL UI widget as recommended Yep. For reference, source is here: http://svn.daleglass.net/secondlife/trunk/indra/newview/llfloateravatarlist.cpp Avatar list is initialized on line 232 > by the wiki. Well placed macros could call his code where he's > updating his avatar list. I assume there needs to be a way to > trigger a refresh of his UI (correct me if I'm wrong here) when new > information comes in. Client is patched to call LLFloaterAvatarList::updateAvatarList() every frame, which then goes over LLCharacter::sInstances and updates its internal list. See line 298. > How does Dale's floater panel get drawn? > Do you have two UIFactories and loops? > Would it be like a flash or java plugin? It gets drawn by the UI code, I don't need to do anything to make that work. Simply creating the widget and then never doing anything should result in a window that's movable on the screen with clickable buttons, etc. My code doesn't really draw anything, it just updates what will be drawn. > > Possibly, we could export the widget drawing functions from an SL DLL > and then call those on an internal window. Basically duplicate a > copy of the SL widget loop, but have it changed so that it is only > working on the internal window as described by the plugin. > Kind of a mini client inside the client. IMO, so much complication may not be necessary. Just look at the small amount of changes outside of llfloateravatarlist.cpp. Those are: registering a callback for the avatar info messages (make it so that I can do that from my llfloateravatarlist.cpp, and so that multiple callbacks can be registered (and unregistered) getting notified when a frame is drawn (add a callback system for "internal events", like "frame drawn", "logging out", etc). I also need to know when a sound is played, when somebody is typing, etc Access to internal lists of avatars My understanding is that DLL based plugins should allow the inheritance method of doing the UI work, so only those fairly minor changes should be 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/20070224/5baa6673/attachment.pgp From tshephard at gmail.com Sat Feb 24 08:06:39 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 08:06:42 2007 Subject: [sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI In-Reply-To: <200702241640.13985.dale@daleglass.net> References: <3b19a500702240227h52fcc2b7ld1f86db6b57cf923@mail.gmail.com> <200702241640.13985.dale@daleglass.net> Message-ID: <3b19a500702240806s2efd5902sde4be974920c398c@mail.gmail.com> > Client is patched to call LLFloaterAvatarList::updateAvatarList() every frame, > which then goes over LLCharacter::sInstances and updates its internal list. This is one of the problems with this style of architecture.. rather than simply invalidating your widgets and asking the UI control to redraw, you have to poll yourself very rapidly. This isn't ideal from a performance point of view. > > See line 298. > > > > How does Dale's floater panel get drawn? > > Do you have two UIFactories and loops? > > Would it be like a flash or java plugin? > > It gets drawn by the UI code, I don't need to do anything to make that work. > Simply creating the widget and then never doing anything should result in a > window that's movable on the screen with clickable buttons, etc. Sorry, I should have been more clear. The questions were rhetorical, ie: how would they be drawn with an NPAPI style architecture. > > My code doesn't really draw anything, it just updates what will be drawn. > > > > > Possibly, we could export the widget drawing functions from an SL DLL > > and then call those on an internal window. Basically duplicate a > > copy of the SL widget loop, but have it changed so that it is only > > working on the internal window as described by the plugin. > > Kind of a mini client inside the client. > > IMO, so much complication may not be necessary. Just look at the small amount > of changes outside of llfloateravatarlist.cpp. > > Those are: > registering a callback for the avatar info messages (make it so that I can do > that from my llfloateravatarlist.cpp, and so that multiple callbacks can be > registered (and unregistered) > > getting notified when a frame is drawn (add a callback system for "internal > events", like "frame drawn", "logging out", etc). I also need to know when a > sound is played, when somebody is typing, etc > > Access to internal lists of avatars > > My understanding is that DLL based plugins should allow the inheritance method > of doing the UI work, so only those fairly minor changes should be needed. > If you mean inheritance across DLLs, that is one possibility I mentioned.. However, the stability and cross platform suitability of such a solution is unclear to me. From dale at daleglass.net Sat Feb 24 08:38:01 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Feb 24 08:38:22 2007 Subject: [sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI In-Reply-To: <3b19a500702240806s2efd5902sde4be974920c398c@mail.gmail.com> References: <3b19a500702240227h52fcc2b7ld1f86db6b57cf923@mail.gmail.com> <200702241640.13985.dale@daleglass.net> <3b19a500702240806s2efd5902sde4be974920c398c@mail.gmail.com> Message-ID: <200702241738.15589.dale@daleglass.net> ? ????????? ?? 24 ??????? 2007 17:06 Tim Shephard ???????(a): > > Client is patched to call LLFloaterAvatarList::updateAvatarList() every > > frame, which then goes over LLCharacter::sInstances and updates its > > internal list. > > This is one of the problems with this style of architecture.. rather > than simply invalidating your widgets and asking the UI control to > redraw, you have to poll yourself very rapidly. This isn't ideal > from a performance point of view. What do you mean? It doesn't HAVE to update itself every frame. It's just that the code that updates the internal list runs every frame because I made it like that. I could make it be every 5 frames instead, or time it to be every second. Skipping frames wouldn't have been good for the people with low framerates. And since it doesn't seem to have a noticeable effect on framerate anyway, I just left it like that. The UI doesn't get updated if it's hidden, too. The alternative to this would be getting events "avatar Alice moved", "avatar Bob appeared", etc. But the update of the internal list has very little performance impact anyway, so that'd be too much complexity for very little benefit. -------------- 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/20070224/19045588/attachment.pgp From tshephard at gmail.com Sat Feb 24 10:00:36 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 10:00:38 2007 Subject: [sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI In-Reply-To: <200702241738.15589.dale@daleglass.net> References: <3b19a500702240227h52fcc2b7ld1f86db6b57cf923@mail.gmail.com> <200702241640.13985.dale@daleglass.net> <3b19a500702240806s2efd5902sde4be974920c398c@mail.gmail.com> <200702241738.15589.dale@daleglass.net> Message-ID: <3b19a500702241000y7f87aa60t50c21235622a331e@mail.gmail.com> Well, the question is how much the plugin will call back into the main code and how much it will simply provide an API for the main code to call. It would be easiest (in some ways) if we could just provide an interface for the system to call and the DLL does not have to be aware of functions in the main client. We could create floaters by create llFloaterProxy or llFloaterPlugin and then use a Decorator pattern (ala GOF) to implement the behaviour of the proxy floater. Unfortunately, everything keeps twisting back into a requirement to call code in the main code base. This might be doable for simple classes that are stateless, however I am concerned that at some point it starts getting more complicated, less stable, less cross platform and more crash prone. If we do export functions to be used in the Plugin DLLs, we may want to export C methods only rather than C++ classes. On 2/24/07, Dale Glass wrote: > ? ????????? ?? 24 ??????? 2007 17:06 Tim Shephard ???????(a): > > > Client is patched to call LLFloaterAvatarList::updateAvatarList() every > > > frame, which then goes over LLCharacter::sInstances and updates its > > > internal list. > > > > This is one of the problems with this style of architecture.. rather > > than simply invalidating your widgets and asking the UI control to > > redraw, you have to poll yourself very rapidly. This isn't ideal > > from a performance point of view. > What do you mean? > > It doesn't HAVE to update itself every frame. It's just that the code that > updates the internal list runs every frame because I made it like that. I > could make it be every 5 frames instead, or time it to be every second. > > Skipping frames wouldn't have been good for the people with low framerates. > And since it doesn't seem to have a noticeable effect on framerate anyway, I > just left it like that. > > The UI doesn't get updated if it's hidden, too. > > The alternative to this would be getting events "avatar Alice moved", "avatar > Bob appeared", etc. But the update of the internal list has very little > performance impact anyway, so that'd be too much complexity for very little > benefit. > > From soft at softnoel.org Sat Feb 24 11:29:49 2007 From: soft at softnoel.org (Soft Noel) Date: Sat Feb 24 11:29:56 2007 Subject: [sldev] Plugin work so far Message-ID: <37625.64.81.228.9.1172345389.squirrel@webmail.softnoel.org> I wish the plugin discussions would continue without people worrying that no code is being written. I've been working, and the discussions have been helpful. I'll go over what I've got so far and where I'm going so people can make comments on the broad strategy, or at least have confidence that we're not wasting time. Currently my work is Mac-only, though I hope to get my hands on a Windows machine this weekend so I can do the DLL work. I'll drop a version on the list after I get Windows and Mac both working to my satisfaction, but before Linux. Linux should be easy once Mac is 100%. Sadly, my only Debian install within viewing distance is on a G4 mini, so it's useless here. :( I'm not averse to purging or rewriting big chunks of this after I drop my first release if it does things we don't want, or if others suggest better ways of doing things. Here's what a very basic plugin looks like. It's (on mac) a dylib linked against the static lib libPluginBase: ### start HelloWorld.cpp ### #include "linden_plugin_common.h" // Find extra interface types in llpluginterfaceshared.h PlugInterfaceType interfaces_requested[] = { PI_TYPE_IO, PI_TYPE_END }; // plugin name, your plugin version, SL name, plugin homepage, plugin flags, interfaces requested PLUGIN_DECLARE( "Hello Printer", "0.01", "Soft Noel", "http://foo.org/", PLUGIN_FLAGS_DEFAULT, interfaces_requested ); bool PluginStartup() { pIO->LogPrint( "Hello world." ); return true; } void PluginShutdown( bool crash ) { if( !crash ) pIO->LogPrint( "Goodbye world." ); } ### end HelloWorld.cpp ### These are the interesting things here: interfaces_requested is a taglist of enums representing interfaces we need. These would be things like IO, UI, SYSTEM. END terminates the list. PLUGIN_DECLARE tells the library that "Hello Printer" is the name of this plugin, "0.01" is our version number, "Soft Noel" is the author, and "http://foo.org" is where the user can go browse for updates. All of the information so far will (later) be displayed in a floater in an SL plugin manager. For now, I hard-load plugins unconditionally. The flags will be used for identifying plugins that should default to being disabled in certain circumstances, for example when an author wants to send out a plugin he prefers to be used on a beta grid for now. Everything in PLUGIN_DECLARE gets turned into an accessor function so that the viewer can inspect a plugin's requirements before deciding whether to activate it. In addition, PLUGIN_DECLARE creates an accessor with the version of libPluginBase in use, which is used in negotiating an interface bundle. (More on that in a bit.) PluginStartup gets called when a plugin is activated. By this point, all interfaces have already been acquired. No plugin developer code is ever called before this point. PluginShutdown is called when a plugin is terminated, either politely by (later) the plugin management floater or viewer exit, or rudely by crash protection. Ideally, interface functions will scrutinize input for dangerous data/behaviors, print a warning to the log, and terminate a plugin before it has a chance to crash the viewer. I'm thinking more about plugin developer iteration time here than I am about end users. I'm adamant about quick iteration times for casual developers, or they lose interest fast, so if we can unload/deactivate (Mac doesn't unload dylibs, just abandons them!) their plugin without booting them from the viewer and sit ready to load their next plugin build, it's a big win. Note that I'm far from married to the pINTERFACENAME->Method() calling convention in the example above. Suggestions about what methods and accessors should look like to plugin developers are welcome. On to the viewer... Currently all new viewer files reside in indra/llplug, and patches outside this directory are minimal. A plug (as in the directory name) is the client side of plugin. Here are the major actors and their roles: LLPlugInterface, base of LLPlugInterfaceIO, LLPlugInterfaceUI, etc The LLPlugInterfaceIO was that pIO we saw in the plugin. Each LLPlugInterface derivative implements a subset of the overall available API. Originally I was going to put it all in one glom, but after a discussion with Rob Linden about the specialized interfaces in Real's plugin SDK, I came to realize that parceling this out would be helpful. The main reason is that some interfaces like a graphic interface will deprecate more quickly than something like an IO interface. If we try to maintain backward compatibility, it will be better if it's not an all-or-nothing affair. (More on that in a bit.) LLPlugInterfaces come from an LLPlugInterfaceFactory and are retained by an LLPlugInterfaceManager. LLPlugInterfaceFactory takes a request for an LLPlugInterface type and a version and returns a compatible interface or declines the request if an interface version is deprecated or newer than the viewer. Interface versioning was the source of some contentious discussion, but it really isn't the headache it sounds like, so I'll prove that out here: ### start llpluginterfacefactory.cpp ### #include "linden_common.h" #include "llplugshared.h" #include "llpluginterfaceio.h" #include "llpluginterfacesystem.h" #include "llpluginterfaceui.h" #include "llpluginterfacefactory.h" typedef LLPlugInterface *(*IFMakerFunc)(); struct InterfaceMakerEntry { const char *min_ver, *max_ver; PlugInterfaceType type; IFMakerFunc maker_func; bool nearly_deprecated; }; // C++ has no type variable or name-based construction, so: LLPlugInterface *PIFMakeIO_Head() { return new LLPlugInterfaceIO; } LLPlugInterface *PIFMakeSystem_Head() { return new LLPlugInterfaceSystem; } LLPlugInterface *PIFMakeUI_Head() { return new LLPlugInterfaceUI; } static InterfaceMakerEntry InterfaceMakers[]= { // Always put newest interfaces at the top. Engine uses the first fit. { "2007.02.22 00", pluginEngineVersion, PI_TYPE_IO, PIFMakeIO_Head, false }, { "2007.02.22 00", pluginEngineVersion, PI_TYPE_SYSTEM, PIFMakeSystem_Head, false }, { "2007.02.22 00", pluginEngineVersion, PI_TYPE_UI, PIFMakeUI_Head, false }, // Old interfaces on the way out: }; static S16 InterfaceMakerFindIndex( const char *version, PlugInterfaceType type ) { for( S16 i = 0; i < sizeof(InterfaceMakers)/sizeof(*InterfaceMakers); i++ ) { InterfaceMakerEntry *ime; ime = &InterfaceMakers[i]; if( type != ime->type ) continue; // This is not intuitive. Think of it like this: "v01Bogo", "v00Zippy" - strcmp // will get to the third char and return '1'-'0' = 1, meaning the requested // version of v00Zippy is too old, as it's "less" than v01Bogo. if( strcmp( ime->min_ver, version ) > 0 ) continue; if( strcmp( ime->max_ver, version ) < 0 ) continue; return i; } return -1; } static IFMakerFunc InterfaceMakerFind( const char *version, PlugInterfaceType type ) { S16 i; index = InterfaceMakerFindIndex( version, type ); if( i >= 0 ) return InterfaceMakers[i].maker_func; return NULL; } static bool InterfaceMakerIsNearlyDeprecated( const char *version, PlugInterfaceType type ) { S16 index; index = InterfaceMakerFindIndex( version, type ); if( index >= 0 ) return InterfaceMakers[index].nearly_deprecated; return false; } bool LLPlugInterfaceFactory::canCreate( const char *version, PlugInterfaceType type ) { IFMakerFunc ifm; ifm = InterfaceMakerFind( version, type ); return ifm ? true : false; } LLPlugInterface *LLPlugInterfaceFactory::create( const char *version, PlugInterfaceType type ) { LLPlugInterface *pi = NULL; IFMakerFunc ifm; ifm = InterfaceMakerFind( version, type ); if( ifm ) pi = ifm(); if( pi ) { if( InterfaceMakerIsNearlyDeprecated( version, type ) ) pi->deprecationWarningSet(); } return pi; } ### end llpluginterfacefactory.cpp ### The main item of interest is that InterfaceMakerEntry. For a given plug PlugInterfaceType, it declares the earliest and latest supported version, and tells how to make that interface. LLPlugInterfaceFactory::create (through helpers) scans for a compatible interface and builds it. Note that there can be multiple entries per PlugInterfaceType, so if PlugInterfaceIO is revised, we can keep an older version of the class around with a slightly different name and everything where older plugins expect it to be. This won't mean a bunch of duplicated code thanks to the PlugInterface compatibility_slave construct. (More on that in a bit.) The deprecation flag is for (later) informing a user via his plugin management panel that his plugin is likely to break in a coming release. These would be set when planning to prune the InterfaceMakers/legacy LLPlugInterfaces. The compatibility_slave construct: When freezing a version of an interface for backward compatibility, we create a version of the interface with an old version number, ie LLPlugInterfaceIOv1 which is derived from LLPlugInterface (not LLPlugInterfaceIO), and copy the old list of virtual functions into the new class. The new class would then create the next NEWER class and stuff it in its compatibility_slave pointer, and all functions would be direct calls to the compatibility_slave except where we need to add/remove function arguments, or otherwise make tweaks to make old-style calls continue to work. We can keep an arbitrary number of compatibility interfaces without further work, as they all simply chain upward through their compatibility slaves. This isn't done with class inheritance as we want to be able to reorder, add, and remove items in newer versions. We can't inherit older classes from newer classes without affecting the old structure. We can't inherit new classes from older classes without losing the ability to remove functions or change data formats. The LLPlugInterfaces are passed to the client in an LLPlugBundle. The bundle is never seen by plugin developers, only libPluginBase. The plugin developer just sees all those LLPlugInterfaces. LLPlugBundle comes from LLPlugBundleManager/LLPlugBundleFactory. The LLPlugBundle is an old fashioned struct, which contains LLPlugInterface pointers for all possible LLPlugInterface types, ex: struct LLPlugBundle { LLPlugBundle() { memset( this, 0, sizeof( *this ) ); } char *version; // 1. Don't re-order // 2. New interfaces must always be added to the BOTTOM. // // This struct may get passed to a plugin anticipating an older // version of the struct. // These are deliberately anonymous/downcast because we'll stuff // combinations of versions in to satisfy older interface version // requests. LLPlugInterface *plug_io; LLPlugInterface *plug_sys; LLPlugInterface *plug_ui; }; Jumping back up a bit, we've got our LLPlugBundle with LLPlugInterfaces getting passed to the plugin and turned into globals. Where this all happens is in an LLPlug, via LLPlugManager/LLPlugFactory. An LLPlug is created with the path of the corresponding plugin dylib as an argument. Straight away, LLPlugin::load() dlopen()s the plugin with RTLD_LAZY binding, and grabs its version and user displayable information. From this point on, LLPlugBundleFactory can tell us whether it will be able to create a compatible set of LLInterfaces, and we can decide if we want to LLPlugin::enable(), which acquires the interfaces and tells libPluginBase to set things up and call the plugin developer's PluginStartup(). Of note, each LLPlug has a unique serial number that will be attached to and used for cleaning up orphaned resources like floaters, menu entries, and hooks. And this brings us to hooks. I'm in the middle of a rework on hooks right now after a discussion at Rob Linden's office. Originally, I was having the plugin author create a class implementing all possible hooks, just as a hack to get things working. This isn't maintainable of course, and I'm waffling between two approaches. One is a class like the above, but specialized for each API subset. The other is moving to a subscription model similar to what Bushing proposed. You can see his sample at https://wiki.secondlife.com/wiki/Hook_example_code ... the main differences would be that I'd want to work with templated versions based on parameter structures to avoid anonymous data, and I'd have an instance of the class per hookable code point rather than trying to keep it generic like the above example. I'll hand off the above soon, then everyone can start nitpicking about the implementation and I'll happily iterate to make this shiny. I'm hoping people will step in at that point to start filling out the LLPlugInterfaces with a useful set of API calls and hooks. I want to get Kelly's suggested data floater example going, then convert Dale's scanner early on, so my own API calls will revolve around those. If you have a pet project, now's a good time to start proposing APIs. There are other useful areas for ongoing discussion if you want to continue to help me. One that I'm coming up against when we start adding plugin-driven floaters is the question of where we want to install plugins and supplemental data. My thinking is something like this: SLDATADIR = ~/Library/Application Support/SecondLife (or Windows/Linux equivalent) SLPLUGDIR = $SLDATADIR/plugins SLPLUGDIR would contain all the plugin dylibs, DLLs, etc Optional folders for data would use the the plugin's self-provided name, ex: SLPLUGDIR/Hello World/hellotext.xml For simplicity, we could give plugin developers a function that opened files with this path. Similarly, for dynamic data, do we want functions to facilitate creating and accessing per-user-perplugin data directories like this? SLPLUGDATADIR = SLDATADIR/$SLNAME/$PLUGINNAME/settings.xml ? Another coming issue is that I'd like to avoid doing too much UI work myself. If someone's eager to create the plugin management floater xml and related dialogs and own future changes, I'd be grateful. What the floater should look like and what dialogs it needs would be another good area for discussion. From gigstaggart at gmail.com Sat Feb 24 11:56:07 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Feb 24 11:56:02 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45DFE234.5030806@lindenlab.com> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <45DE04A6.5080003@lindenlab.com> <3b19a500702232154i33459bb1g875bf0b54641ce52@mail.gmail.com> <45DFD96C.3030804@gmail.com> <45DFE234.5030806@lindenlab.com> Message-ID: <45E09857.2020309@gmail.com> Rob Lanphier wrote: > On 2/23/07 10:21 PM, Jason Giglio wrote: >> Tim Shephard wrote: >>> I think some way to communicate from LSL to the Plugins would be very >>> useful in many situations as well. >> It goes beyond plugins, we need a way to communicate from LSL to other >> built-in client enhancements we might develop too. I'm working on an >> idea for that. I'll put up a wiki page on it tomorrow. > When you say "need", do you mean for the very first plugin interface? I > really hope you aren't expecting LSL modifications to be a prerequisite > for the first version of plugins. > Rob, no like I said this is larger than just plugins. Some plugin stuff could be done before this of course. But arbitrary LSL->Client communication is going to be a critical piece to a lot of OpenSL efforts. Luckily what I have in mind should be simple. > I think the most successful model for creating the first plugin > interface is to collaborate with Dale Glass on his extension, figuring > out what is necessary for that. Over time, we can evolve deeper and > deeper hooks. However, I think it's /very/ important to start simple. My thoughts exactly. -Jason From gigstaggart at gmail.com Sat Feb 24 13:18:56 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Feb 24 13:18:55 2007 Subject: [sldev] Generic LSL->Client Comms Message-ID: <45E0ABC0.2040302@gmail.com> Please review this proposal carefully. I believe it would be a great stepping stone toward a ton of new features. It is a very simple solution that will let us prototype new LSL-client interaction features without any committment from LL. https://wiki.secondlife.com/wiki/LSL_To_Client_Comms From dale at daleglass.net Sat Feb 24 14:15:22 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Feb 24 14:18:28 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <45E0ABC0.2040302@gmail.com> References: <45E0ABC0.2040302@gmail.com> Message-ID: <200702242315.30140.dale@daleglass.net> ? ????????? ?? 24 ??????? 2007 22:18 Jason Giglio ???????(a): > Please review this proposal carefully. I believe it would be a great > stepping stone toward a ton of new features. It is a very simple > solution that will let us prototype new LSL-client interaction features > without any committment from LL. > > https://wiki.secondlife.com/wiki/LSL_To_Client_Comms I already hacked in such a thing into my client. Here's how it works: Client to LSL: speaks on a channel directly. Nothing special here. LSL to Client: llOwnerSay, with this format: $VwrComm$VERSION$COMPONENT$DATA VwrComm: Header, must be present VERSION: Protocol version COMPONENT: Component inside the viewer the message is for DATA: Data being sent Example: $VwrComm$0$AvatarScanner$LoginComplete Source here: http://svn.daleglass.net/secondlife/trunk/indra/newview/llviewermessage.cpp line 2047. -------------- 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/20070224/1563a6ba/attachment.pgp From soft at softnoel.org Sat Feb 24 14:34:32 2007 From: soft at softnoel.org (Soft Noel) Date: Sat Feb 24 14:34:39 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <200702242315.30140.dale@daleglass.net> References: <45E0ABC0.2040302@gmail.com> <200702242315.30140.dale@daleglass.net> Message-ID: <39532.64.81.228.9.1172356472.squirrel@webmail.softnoel.org> On Sat, February 24, 2007 2:15 pm, Dale Glass wrote: >> >> https://wiki.secondlife.com/wiki/LSL_To_Client_Comms > > I already hacked in such a thing into my client. Here's how it works: > > Client to LSL: speaks on a channel directly. Nothing special here. > > LSL to Client: llOwnerSay, with this format: Gigs' proposal was for an attribute on the object. Presumably this is passed to the viewer when the object is first made known to the viewer. Accomplishing the same thing with regular communications would require an LSL script that scanned for people to tell, or would require the viewer to keep pinging a channel for compatible objects. From dale at daleglass.net Sat Feb 24 14:48:16 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Feb 24 14:48:33 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <39532.64.81.228.9.1172356472.squirrel@webmail.softnoel.org> References: <45E0ABC0.2040302@gmail.com> <200702242315.30140.dale@daleglass.net> <39532.64.81.228.9.1172356472.squirrel@webmail.softnoel.org> Message-ID: <200702242348.20898.dale@daleglass.net> ? ????????? ?? 24 ??????? 2007 23:34 Soft Noel ???????(a): > Gigs' proposal was for an attribute on the object. Presumably this is > passed to the viewer when the object is first made known to the viewer. > Accomplishing the same thing with regular communications would require an > LSL script that scanned for people to tell, or would require the viewer to > keep pinging a channel for compatible objects. Obviously, my way of doing it is a hack. A quite ugly one at that. But the proposed solution does require LL help, so meanwhile I do what I explained, because a LL response could take a long time to materialize. That said, I'd like to see it done both ways: The property way, and the chat way. The property way is good when you want the object to communicate something to the viewer automatically, but it's not good for active communication (like my scanner wants), since now you'd have to implement some sort of serial number for instance. Also, talking to multiple viewers complicates things considerably. Here's what I think what a complete solution should have: 1. Some sort of hidden property for communicating metadata to viewer 2. Ability to receive chat-like messages from viewer (optional, channel can be used already) 3. Ability to talk to a viewer on some sort of hidden channel 4. Ability to talk to multiple viewers at once without confusion 5. Guaranteed order of delivery 6. Delivery confirmation Points 2, 3 and 4 I can provide with my hack (4 by sending IMs to viewers, but the delay is a problem here. LL help with a specific channel with no delay for this would be nice). Now, guaranteed order of delivery is the big one. During lag sometimes IMs get reordered. This breaks some nicely simplistic protocols, for example: ClearList AddElement foo AddElement bar If this arrives out of order, the result is not what it should be. Point 6: I'd like some sort of error notification when delivery fails (object vanishes, viewer disconnects, 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/20070224/864287d2/attachment.pgp From soft at softnoel.org Sat Feb 24 15:06:23 2007 From: soft at softnoel.org (Soft Noel) Date: Sat Feb 24 15:06:25 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <200702242348.20898.dale@daleglass.net> References: <45E0ABC0.2040302@gmail.com> <200702242315.30140.dale@daleglass.net> <39532.64.81.228.9.1172356472.squirrel@webmail.softnoel.org> <200702242348.20898.dale@daleglass.net> Message-ID: <40220.64.81.228.9.1172358383.squirrel@webmail.softnoel.org> On Sat, February 24, 2007 2:48 pm, Dale Glass wrote: > > Obviously, my way of doing it is a hack. A quite ugly one at that. Actually, it's clever and I plan on stealing it for another project. :) My point was that yours was a solution to a different problem. #1 and #2-6 in your list are two different problems. > 1. Some sort of hidden property for communicating metadata to viewer > 2. Ability to receive chat-like messages from viewer (optional, channel > can be > used already) > 3. Ability to talk to a viewer on some sort of hidden channel > 4. Ability to talk to multiple viewers at once without confusion > 5. Guaranteed order of delivery > 6. Delivery confirmation Is #2-6 in the wiki or elsewhere where we can point and beg support? Also, did I read somewhere that messaging might go TCP, and would that take care of #5? From gigstaggart at gmail.com Sat Feb 24 15:06:58 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Feb 24 15:06:52 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <39532.64.81.228.9.1172356472.squirrel@webmail.softnoel.org> References: <45E0ABC0.2040302@gmail.com> <200702242315.30140.dale@daleglass.net> <39532.64.81.228.9.1172356472.squirrel@webmail.softnoel.org> Message-ID: <45E0C512.9060300@gmail.com> Soft Noel wrote: > Gigs' proposal was for an attribute on the object. Presumably this is > passed to the viewer when the object is first made known to the viewer. > Accomplishing the same thing with regular communications would require an > LSL script that scanned for people to tell, or would require the viewer to > keep pinging a channel for compatible objects. Yes, a better name for it might be generic extensible prim attribute tagging. This could even be used to implement something like full boolean CSG rendering. There's nothing that says the tags must be set by LSL in the final implementation necessarily, though during the development it would be set from LSL using the generic function in my page. From dale at daleglass.net Sat Feb 24 15:29:41 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Feb 24 15:29:53 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <40220.64.81.228.9.1172358383.squirrel@webmail.softnoel.org> References: <45E0ABC0.2040302@gmail.com> <200702242348.20898.dale@daleglass.net> <40220.64.81.228.9.1172358383.squirrel@webmail.softnoel.org> Message-ID: <200702250029.46631.dale@daleglass.net> ? ????????? ?? 25 ??????? 2007 00:06 Soft Noel ???????(a): > On Sat, February 24, 2007 2:48 pm, Dale Glass wrote: > > Obviously, my way of doing it is a hack. A quite ugly one at that. > > Actually, it's clever and I plan on stealing it for another project. :) Just two things here: 1. If possible, use the same protocol (or bump the version number) so we don't end up having to make the viewer deal with 20 versions of the same stuff 2. Have in mind that the code I linked is incomplete and insecure. The viewer actually has no way of telling that something is being delivered with llOwnerSay. So the code as implemented parses any messages from objects, from anybody. So to close that hole, the code will have to pass the object's and the owner's key to the code doing the text parsing, so that they can be verified. If you do that, I'd appreciate a patch, as I'm working on other things ATM. > My > point was that yours was a solution to a different problem. #1 and #2-6 in > your list are two different problems. Right, the "Generic LSL->Client Comms" confused me a bit, as #2-6 is precisely what it makes me think of. > Also, did I read somewhere that messaging might go TCP, and would that > take care of #5? Yep, that'd do nicely. -------------- 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/20070225/c3dbba62/attachment.pgp From baba at libsecondlife.org Sat Feb 24 16:10:30 2007 From: baba at libsecondlife.org (Baba) Date: Sat Feb 24 16:10:33 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <1172307998.4322.112.camel@localhost.localdomain> References: <45DB36A3.60004@watson.ibm.com> <45DCC8B0.9030709@gmail.com> <45DCD4AC.8020201@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <1172288228.4322.34.camel@localhost.localdomain> <45DFC104.4060308@lindenlab.com> <1172307998.4322.112.camel@localhost.localdomain> Message-ID: <45E0D3F6.5050208@libsecondlife.org> Callum Lerwick wrote: > The real point I'm trying to get at, is that the thinking behind plugins > here is an artifact of close source development. Its Windows thinking. > > One person has admitted that the only reason they want plugins is so > they can weasel around the GPL, shun the community and release > proprietary code. Is this what Linden Lab wants? Proprietary extensions? > If so, why was it licensed under the GPL rather than something BSDish? > > Proprietary plugins are completely and totally antithetical to the > purpose of the GPL. Linden Lab has decided to share their source code > with all of us, under the terms of the GPL. If you think you have any > right to benefit from the viewer source without sharing with the > community, you're wrong. Unless LL has granted you a different > license... > This has nothing to do with closed source development. The same way Apache httpd or Firefox are able to be extended, the Second Life client should be extensible. Nobody needs every extension nor wants the same things from the software that another person wants. I am absolutely sure nobody wants a client that does every little thing anyone could want. As for the GPL, it will be honored to the letter of the law. Any commitment beyond that is left up to the individual. I don't let Richard M. Stallman stand by me and whisper sweet nothings into my ear. Honestly he creeps me out. Baba From tshephard at gmail.com Sat Feb 24 17:10:47 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 17:10:50 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <200702250029.46631.dale@daleglass.net> References: <45E0ABC0.2040302@gmail.com> <200702242348.20898.dale@daleglass.net> <40220.64.81.228.9.1172358383.squirrel@webmail.softnoel.org> <200702250029.46631.dale@daleglass.net> Message-ID: <3b19a500702241710s56dd0897kcb8b9d6a623ef6fc@mail.gmail.com> At a minimum, I'd like to see Dale's version implemented, though it should probably have an escape character that the beginning which is a little more rare. Perhaps |? On 2/24/07, Dale Glass wrote: > ? ????????? ?? 25 ??????? 2007 00:06 Soft Noel ???????(a): > > On Sat, February 24, 2007 2:48 pm, Dale Glass wrote: > > > Obviously, my way of doing it is a hack. A quite ugly one at that. > > > > Actually, it's clever and I plan on stealing it for another project. :) > > Just two things here: > 1. If possible, use the same protocol (or bump the version number) so we don't > end up having to make the viewer deal with 20 versions of the same stuff > > 2. Have in mind that the code I linked is incomplete and insecure. The viewer > actually has no way of telling that something is being delivered with > llOwnerSay. So the code as implemented parses any messages from objects, from > anybody. > > So to close that hole, the code will have to pass the object's and the owner's > key to the code doing the text parsing, so that they can be verified. > > If you do that, I'd appreciate a patch, as I'm working on other things ATM. > > > My > > point was that yours was a solution to a different problem. #1 and #2-6 in > > your list are two different problems. > Right, the "Generic LSL->Client Comms" confused me a bit, as #2-6 is precisely > what it makes me think of. > > > Also, did I read somewhere that messaging might go TCP, and would that > > take care of #5? > Yep, that'd do nicely. > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > > From tshephard at gmail.com Sat Feb 24 17:22:53 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 17:22:56 2007 Subject: [sldev] Plugin work so far In-Reply-To: <37625.64.81.228.9.1172345389.squirrel@webmail.softnoel.org> References: <37625.64.81.228.9.1172345389.squirrel@webmail.softnoel.org> Message-ID: <3b19a500702241722v619ff7f3wef9f578731213cc@mail.gmail.com> I think the immediate and key challenges in any plugin solution are: 1. how do UI widgets get instantiated? 2. how do we hook into the message protocol? I think the answer to the second problem isn't that mysterious (they probably all involve simple hooks) but there are different approaches for 1. I've detailed them elsewhere, but a couple of them are: a) Inheritance across DLLS. Fast to develop, but stability could be an issue b) NPAPI style plugin - seperate thread with a plugin widget loop? callbacks from a proxy llFloater object? I believe these are the critical issues because they will most impact plugin developers. Issues such as loading, initialization, destruction, and specification are important, however the time to refactor our code to match those contracts will probably be minor compared to reworking all the UI / Communication code. On 2/24/07, Soft Noel wrote: > I wish the plugin discussions would continue without people worrying that > no code is being written. I've been working, and the discussions have been > helpful. I'll go over what I've got so far and where I'm going so people > can make comments on the broad strategy, or at least have confidence that > we're not wasting time. > > Currently my work is Mac-only, though I hope to get my hands on a Windows > machine this weekend so I can do the DLL work. I'll drop a version on the > list after I get Windows and Mac both working to my satisfaction, but > before Linux. Linux should be easy once Mac is 100%. Sadly, my only Debian > install within viewing distance is on a G4 mini, so it's useless here. :( > > I'm not averse to purging or rewriting big chunks of this after I drop my > first release if it does things we don't want, or if others suggest better > ways of doing things. > > > Here's what a very basic plugin looks like. It's (on mac) a dylib linked > against the static lib libPluginBase: > > > ### start HelloWorld.cpp ### > > #include "linden_plugin_common.h" > > // Find extra interface types in llpluginterfaceshared.h > PlugInterfaceType interfaces_requested[] = > { > PI_TYPE_IO, > > PI_TYPE_END > }; > > // plugin name, your plugin version, SL name, plugin homepage, plugin > flags, interfaces requested > PLUGIN_DECLARE( "Hello Printer", "0.01", "Soft Noel", "http://foo.org/", > PLUGIN_FLAGS_DEFAULT, interfaces_requested ); > > > bool PluginStartup() > { > pIO->LogPrint( "Hello world." ); > > return true; > } > > > void PluginShutdown( bool crash ) > { > if( !crash ) > pIO->LogPrint( "Goodbye world." ); > } > > ### end HelloWorld.cpp ### > > These are the interesting things here: > > interfaces_requested is a taglist of enums representing interfaces we > need. These would be things like IO, UI, SYSTEM. END terminates the list. > > PLUGIN_DECLARE tells the library that "Hello Printer" is the name of this > plugin, "0.01" is our version number, "Soft Noel" is the author, and > "http://foo.org" is where the user can go browse for updates. All of the > information so far will (later) be displayed in a floater in an SL plugin > manager. For now, I hard-load plugins unconditionally. The flags will be > used for identifying plugins that should default to being disabled in > certain circumstances, for example when an author wants to send out a > plugin he prefers to be used on a beta grid for now. > > Everything in PLUGIN_DECLARE gets turned into an accessor function so that > the viewer can inspect a plugin's requirements before deciding whether to > activate it. In addition, PLUGIN_DECLARE creates an accessor with the > version of libPluginBase in use, which is used in negotiating an interface > bundle. (More on that in a bit.) > > PluginStartup gets called when a plugin is activated. By this point, all > interfaces have already been acquired. No plugin developer code is ever > called before this point. > > PluginShutdown is called when a plugin is terminated, either politely by > (later) the plugin management floater or viewer exit, or rudely by crash > protection. Ideally, interface functions will scrutinize input for > dangerous data/behaviors, print a warning to the log, and terminate a > plugin before it has a chance to crash the viewer. I'm thinking more about > plugin developer iteration time here than I am about end users. I'm > adamant about quick iteration times for casual developers, or they lose > interest fast, so if we can unload/deactivate (Mac doesn't unload dylibs, > just abandons them!) their plugin without booting them from the viewer and > sit ready to load their next plugin build, it's a big win. > > Note that I'm far from married to the pINTERFACENAME->Method() calling > convention in the example above. Suggestions about what methods and > accessors should look like to plugin developers are welcome. > > > On to the viewer... > > Currently all new viewer files reside in indra/llplug, and patches outside > this directory are minimal. A plug (as in the directory name) is the > client side of plugin. Here are the major actors and their roles: > > LLPlugInterface, base of LLPlugInterfaceIO, LLPlugInterfaceUI, etc > > The LLPlugInterfaceIO was that pIO we saw in the plugin. Each > LLPlugInterface derivative implements a subset of the overall available > API. Originally I was going to put it all in one glom, but after a > discussion with Rob Linden about the specialized interfaces in Real's > plugin SDK, I came to realize that parceling this out would be helpful. > The main reason is that some interfaces like a graphic interface will > deprecate more quickly than something like an IO interface. If we try to > maintain backward compatibility, it will be better if it's not an > all-or-nothing affair. (More on that in a bit.) > > LLPlugInterfaces come from an LLPlugInterfaceFactory and are retained by > an LLPlugInterfaceManager. LLPlugInterfaceFactory takes a request for an > LLPlugInterface type and a version and returns a compatible interface or > declines the request if an interface version is deprecated or newer than > the viewer. Interface versioning was the source of some contentious > discussion, but it really isn't the headache it sounds like, so I'll prove > that out here: > > ### start llpluginterfacefactory.cpp ### > > #include "linden_common.h" > > #include "llplugshared.h" > #include "llpluginterfaceio.h" > #include "llpluginterfacesystem.h" > #include "llpluginterfaceui.h" > > #include "llpluginterfacefactory.h" > > > typedef LLPlugInterface *(*IFMakerFunc)(); > > > struct InterfaceMakerEntry > { > const char *min_ver, *max_ver; > PlugInterfaceType type; > IFMakerFunc maker_func; > bool nearly_deprecated; > }; > > > // C++ has no type variable or name-based construction, so: > LLPlugInterface *PIFMakeIO_Head() { return new LLPlugInterfaceIO; } > LLPlugInterface *PIFMakeSystem_Head() { return new LLPlugInterfaceSystem; } > LLPlugInterface *PIFMakeUI_Head() { return new LLPlugInterfaceUI; } > > > static InterfaceMakerEntry InterfaceMakers[]= > { > // Always put newest interfaces at the top. Engine uses the first fit. > { "2007.02.22 00", pluginEngineVersion, PI_TYPE_IO, PIFMakeIO_Head, false }, > { "2007.02.22 00", pluginEngineVersion, PI_TYPE_SYSTEM, > PIFMakeSystem_Head, false }, > { "2007.02.22 00", pluginEngineVersion, PI_TYPE_UI, PIFMakeUI_Head, false }, > > // Old interfaces on the way out: > }; > > > static S16 InterfaceMakerFindIndex( const char *version, PlugInterfaceType > type ) > { > for( S16 i = 0; i < sizeof(InterfaceMakers)/sizeof(*InterfaceMakers); i++ ) > { > InterfaceMakerEntry *ime; > ime = &InterfaceMakers[i]; > > if( type != ime->type ) > continue; > > // This is not intuitive. Think of it like this: "v01Bogo", "v00Zippy" - > strcmp > // will get to the third char and return '1'-'0' = 1, meaning the requested > // version of v00Zippy is too old, as it's "less" than v01Bogo. > if( strcmp( ime->min_ver, version ) > 0 ) > continue; > > if( strcmp( ime->max_ver, version ) < 0 ) > continue; > > return i; > } > > return -1; > } > > > static IFMakerFunc InterfaceMakerFind( const char *version, > PlugInterfaceType type ) > { > S16 i; > index = InterfaceMakerFindIndex( version, type ); > > if( i >= 0 ) > return InterfaceMakers[i].maker_func; > > return NULL; > } > > > static bool InterfaceMakerIsNearlyDeprecated( const char *version, > PlugInterfaceType type ) > { > S16 index; > index = InterfaceMakerFindIndex( version, type ); > > if( index >= 0 ) > return InterfaceMakers[index].nearly_deprecated; > > return false; > } > > > bool LLPlugInterfaceFactory::canCreate( const char *version, > PlugInterfaceType type ) > { > IFMakerFunc ifm; > > ifm = InterfaceMakerFind( version, type ); > > return ifm ? true : false; > } > > > LLPlugInterface *LLPlugInterfaceFactory::create( const char *version, > PlugInterfaceType type ) > { > LLPlugInterface *pi = NULL; > IFMakerFunc ifm; > > ifm = InterfaceMakerFind( version, type ); > if( ifm ) > pi = ifm(); > > if( pi ) > { > if( InterfaceMakerIsNearlyDeprecated( version, type ) ) > pi->deprecationWarningSet(); > } > > return pi; > } > > ### end llpluginterfacefactory.cpp ### > > The main item of interest is that InterfaceMakerEntry. For a given plug > PlugInterfaceType, it declares the earliest and latest supported version, > and tells how to make that interface. LLPlugInterfaceFactory::create > (through helpers) scans for a compatible interface and builds it. Note > that there can be multiple entries per PlugInterfaceType, so if > PlugInterfaceIO is revised, we can keep an older version of the class > around with a slightly different name and everything where older plugins > expect it to be. This won't mean a bunch of duplicated code thanks to the > PlugInterface compatibility_slave construct. (More on that in a bit.) The > deprecation flag is for (later) informing a user via his plugin management > panel that his plugin is likely to break in a coming release. These would > be set when planning to prune the InterfaceMakers/legacy LLPlugInterfaces. > > The compatibility_slave construct: When freezing a version of an interface > for backward compatibility, we create a version of the interface with an > old version number, ie LLPlugInterfaceIOv1 which is derived from > LLPlugInterface (not LLPlugInterfaceIO), and copy the old list of virtual > functions into the new class. The new class would then create the next > NEWER class and stuff it in its compatibility_slave pointer, and all > functions would be direct calls to the compatibility_slave except where we > need to add/remove function arguments, or otherwise make tweaks to make > old-style calls continue to work. We can keep an arbitrary number of > compatibility interfaces without further work, as they all simply chain > upward through their compatibility slaves. This isn't done with class > inheritance as we want to be able to reorder, add, and remove items in > newer versions. We can't inherit older classes from newer classes without > affecting the old structure. We can't inherit new classes from older > classes without losing the ability to remove functions or change data > formats. > > The LLPlugInterfaces are passed to the client in an LLPlugBundle. The > bundle is never seen by plugin developers, only libPluginBase. The plugin > developer just sees all those LLPlugInterfaces. LLPlugBundle comes from > LLPlugBundleManager/LLPlugBundleFactory. The LLPlugBundle is an old > fashioned struct, which contains LLPlugInterface pointers for all possible > LLPlugInterface types, ex: > > struct LLPlugBundle > { > LLPlugBundle() > { > memset( this, 0, sizeof( *this ) ); > } > > char *version; > > // 1. Don't re-order > // 2. New interfaces must always be added to the BOTTOM. > // > // This struct may get passed to a plugin anticipating an older > // version of the struct. > > // These are deliberately anonymous/downcast because we'll stuff > // combinations of versions in to satisfy older interface version > // requests. > > LLPlugInterface *plug_io; > LLPlugInterface *plug_sys; > LLPlugInterface *plug_ui; > }; > > > Jumping back up a bit, we've got our LLPlugBundle with LLPlugInterfaces > getting passed to the plugin and turned into globals. Where this all > happens is in an LLPlug, via LLPlugManager/LLPlugFactory. An LLPlug is > created with the path of the corresponding plugin dylib as an argument. > Straight away, LLPlugin::load() dlopen()s the plugin with RTLD_LAZY > binding, and grabs its version and user displayable information. From this > point on, LLPlugBundleFactory can tell us whether it will be able to > create a compatible set of LLInterfaces, and we can decide if we want to > LLPlugin::enable(), which acquires the interfaces and tells libPluginBase > to set things up and call the plugin developer's PluginStartup(). > > Of note, each LLPlug has a unique serial number that will be attached to > and used for cleaning up orphaned resources like floaters, menu entries, > and hooks. And this brings us to hooks. > > I'm in the middle of a rework on hooks right now after a discussion at Rob > Linden's office. Originally, I was having the plugin author create a class > implementing all possible hooks, just as a hack to get things working. > This isn't maintainable of course, and I'm waffling between two > approaches. One is a class like the above, but specialized for each API > subset. The other is moving to a subscription model similar to what > Bushing proposed. You can see his sample at > https://wiki.secondlife.com/wiki/Hook_example_code ... the main > differences would be that I'd want to work with templated versions based > on parameter structures to avoid anonymous data, and I'd have an instance > of the class per hookable code point rather than trying to keep it generic > like the above example. > > > I'll hand off the above soon, then everyone can start nitpicking about the > implementation and I'll happily iterate to make this shiny. I'm hoping > people will step in at that point to start filling out the > LLPlugInterfaces with a useful set of API calls and hooks. I want to get > Kelly's suggested data floater example going, then convert Dale's scanner > early on, so my own API calls will revolve around those. If you have a pet > project, now's a good time to start proposing APIs. > > There are other useful areas for ongoing discussion if you want to > continue to help me. One that I'm coming up against when we start adding > plugin-driven floaters is the question of where we want to install plugins > and supplemental data. My thinking is something like this: > > SLDATADIR = ~/Library/Application Support/SecondLife (or Windows/Linux > equivalent) > SLPLUGDIR = $SLDATADIR/plugins > > SLPLUGDIR would contain all the plugin dylibs, DLLs, etc > > Optional folders for data would use the the plugin's self-provided name, ex: > SLPLUGDIR/Hello World/hellotext.xml > > For simplicity, we could give plugin developers a function that opened > files with this path. > > Similarly, for dynamic data, do we want functions to facilitate creating > and accessing per-user-perplugin data directories like this? > SLPLUGDATADIR = SLDATADIR/$SLNAME/$PLUGINNAME/settings.xml ? > > Another coming issue is that I'd like to avoid doing too much UI work > myself. If someone's eager to create the plugin management floater xml and > related dialogs and own future changes, I'd be grateful. What the floater > should look like and what dialogs it needs would be another good area for > discussion. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dale at daleglass.net Sat Feb 24 17:24:34 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Feb 24 17:24:51 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <3b19a500702241710s56dd0897kcb8b9d6a623ef6fc@mail.gmail.com> References: <45E0ABC0.2040302@gmail.com> <200702250029.46631.dale@daleglass.net> <3b19a500702241710s56dd0897kcb8b9d6a623ef6fc@mail.gmail.com> Message-ID: <200702250224.40063.dale@daleglass.net> ? ????????? ?? 25 ??????? 2007 02:10 Tim Shephard ???????(a): > At a minimum, I'd like to see Dale's version implemented, though it It already is in my repository http://svn.daleglass.net/secondlife/trunk/ > should probably have an escape character that the beginning which is a > little more rare. > > Perhaps |? Perhaps, but I don't think it's very important, as a false match is unlikely anyway. The current way it works is: 1. Message must come from an object. Normal chat doesn't trigger it 2. String gets split by "$" and must have at least 4 tokens 3. First token must be VwrComm If those 3 things aren't matched, the string is passed as-is, and the code doesn't suppress its display. 4. Second token must be "0" (version number, this will change) If this doesn't match, the text won't appear on screen, but the code won't continue further either 5. Third token matches the name of a known component. If this matches, the remaining data is passed to the code that handles it, otherwise it's ignored. -------------- 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/20070225/4614b4b9/attachment.pgp From tshephard at gmail.com Sat Feb 24 17:27:25 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 17:27:27 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <200702250224.40063.dale@daleglass.net> References: <45E0ABC0.2040302@gmail.com> <200702250029.46631.dale@daleglass.net> <3b19a500702241710s56dd0897kcb8b9d6a623ef6fc@mail.gmail.com> <200702250224.40063.dale@daleglass.net> Message-ID: <3b19a500702241727sd4802d4vc6afa74085471dfd@mail.gmail.com> Yeah, you're right, it isn't important :) But, the cpu cycles to check the first character versus tokenize the whole string everytime seems to me to be a bit more :) But, I agree, it is a minor implementation detail. ;) On 2/24/07, Dale Glass wrote: > ? ????????? ?? 25 ??????? 2007 02:10 Tim Shephard ???????(a): > > At a minimum, I'd like to see Dale's version implemented, though it > It already is in my repository > http://svn.daleglass.net/secondlife/trunk/ > > > should probably have an escape character that the beginning which is a > > little more rare. > > > > Perhaps |? > > Perhaps, but I don't think it's very important, as a false match is unlikely > anyway. The current way it works is: > > 1. Message must come from an object. Normal chat doesn't trigger it > 2. String gets split by "$" and must have at least 4 tokens > 3. First token must be VwrComm > > If those 3 things aren't matched, the string is passed as-is, and the code > doesn't suppress its display. > > 4. Second token must be "0" (version number, this will change) > > If this doesn't match, the text won't appear on screen, but the code won't > continue further either > > 5. Third token matches the name of a known component. > > If this matches, the remaining data is passed to the code that handles it, > otherwise it's ignored. > > > From robla at lindenlab.com Sat Feb 24 17:52:34 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sat Feb 24 17:52:48 2007 Subject: [sldev] Viewer Manifest In-Reply-To: <45DE5634.600@lindenlab.com> References: <200702222327.02886.dale@daleglass.net> <1712.69.158.190.134.1172185977.squirrel@webmail.bluewax.com> <200702230017.32150.dale@daleglass.net> <45DE5634.600@lindenlab.com> Message-ID: <45E0EBE2.2010201@lindenlab.com> Hi Ryan, Thanks for posting this. For everyone else reading this list, I'm hoping you can give your comments on this. One way to make it more likely that Lindens engage with you on your ideas is when you return the favor. Comments inline: On 2/22/07 6:49 PM, Ryan Williams wrote: > This seems like a great time to interject about an installer packaging > script I'm introducing into the next release. > > The short story is that building an installer will be one step -- > running a Python script. I don't know how much of our installer-making > code has been released, but since the .nsi wasn't, probably "not much". > Ooops. That certainly wasn't by design. How does one go about building the installer? I'm assuming it's just a different build target. Has anyone actually tried to build an installer to date? > Either way, with the next source release the installer-making > capabilities should be fully operational. > Cool! Let me know which branch you checked your stuff into. Whether or not these changes make it into the very next release depends greatly on which branch it gets into. Certainly, though, "soon" is a correct answer. > I provided documentation for the file here: > https://wiki.secondlife.com/wiki/Viewer_Manifest > > I'm certainly interested in discussion about the design and > implementation of the script. Of course, not much discussion can happen > until everyone see the code, but I just wanted to give a heads-up. > There seems to be plenty there for discussion, actually. One question that I have (because I know I'll get asked this down the road)...is there existing technology that does this same function that isn't too burdensome to switch to? This is a question for everyone, not just Ryan. I ask this sincerely, because even though I know this problem has been tackled a gazillion times, I also know that the solutions out there are often difficult to extract from the projects that created them. Just to narrow the scope of what would be considered overlapping technology, the idea is that this Python script creates a NSIS installer on Windows, a .dmg on Mac, and a tarball on Linux, right? Since switching installer technologies (at least on Windows and Mac...on Linux, something like Autopackage would be kinda cool) is probably harder than writing a simple python wrapper from scratch, any viable competing technology would need to be able to create an identical installer, and have to have the same simplicity of being just a Python script (or /maybe/ Perl). I wasn't able to find anything. If this is truly unique, one thing that would be very cool to see is someone take the ball and run with it. We're not exactly in the cross-platform installer business, and this seems like a problem that a lot of folks have (see http://www.wxwidgets.org/wiki/index.php/Installers ). If there's someone out there looking to form their own little independent open source project, this might prove to be a great starting point (assuming Ryan hasn't grown too attached to it just yet). I could see this either taking on a life of its own, or perhaps being incorporated in a bigger project. One piece of feedback regarding the platform magic (e.g. derive from LLManifest and name your class "HP-UXManifest", and that will be selected for use on HP-UX) Platform isn't the only relevant variable in choosing which class to use. For example, down the road, we may wish to have Linux .rpm, Linux .deb, Linux autopackage, etc. Additionally, it may very well be that FreeBSD autopackage and Linux autopackage will share more in common than Linux .rpm and Linux autopackage. So, building out the class tree based exclusively on platform may not be the best thing. 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/20070224/fed2bb57/signature-0001.pgp From soft at softnoel.org Sat Feb 24 17:54:57 2007 From: soft at softnoel.org (Soft Noel) Date: Sat Feb 24 17:54:58 2007 Subject: [sldev] Plugin work so far In-Reply-To: <3b19a500702241722v619ff7f3wef9f578731213cc@mail.gmail.com> References: <37625.64.81.228.9.1172345389.squirrel@webmail.softnoel.org> <3b19a500702241722v619ff7f3wef9f578731213cc@mail.gmail.com> Message-ID: <41817.64.81.228.9.1172368497.squirrel@webmail.softnoel.org> 110% agreed that some big questions are unanswered. I dumped my progress so far on the list to try to encourage continued discussion. Several people have complained about the talk:code ratio, suggesting it isn't being written. I *am* writing code, and the discussions *are* useful. Please please discuss the UI API specifically. I'm still hoping for a way to expose this without a hundred individual accessors, and without having the plugin interface becoming incompatible with every last UI system change. If we can tackle the problem there, the same concepts will be useful with other APIs. When I get to the UI stuff, I'm going brute force on accessors to support versioned interfaces, which will mean a lot of work on my part. If a nice, clean alternative is found on the list, it could save many evenings! On Sat, February 24, 2007 5:22 pm, Tim Shephard wrote: > I think the immediate and key challenges in any plugin solution are: > > 1. how do UI widgets get instantiated? > 2. how do we hook into the message protocol? > > I think the answer to the second problem isn't that mysterious (they > probably all involve simple hooks) but there are different approaches > for 1. > > I've detailed them elsewhere, but a couple of them are: > > a) Inheritance across DLLS. Fast to develop, but stability could be an > issue > b) NPAPI style plugin - seperate thread with a plugin widget loop? > callbacks from a proxy llFloater object? > > I believe these are the critical issues because they will most impact > plugin developers. > > Issues such as loading, initialization, destruction, and specification > are important, however the time to refactor our code to match those > contracts will probably be minor compared to reworking all the UI / > Communication code. > > > > > > > On 2/24/07, Soft Noel wrote: >> I wish the plugin discussions would continue without people worrying >> that >> no code is being written. I've been working, and the discussions have >> been >> helpful. I'll go over what I've got so far and where I'm going so people >> can make comments on the broad strategy, or at least have confidence >> that >> we're not wasting time. >> >> Currently my work is Mac-only, though I hope to get my hands on a >> Windows >> machine this weekend so I can do the DLL work. I'll drop a version on >> the >> list after I get Windows and Mac both working to my satisfaction, but >> before Linux. Linux should be easy once Mac is 100%. Sadly, my only >> Debian >> install within viewing distance is on a G4 mini, so it's useless here. >> :( >> >> I'm not averse to purging or rewriting big chunks of this after I drop >> my >> first release if it does things we don't want, or if others suggest >> better >> ways of doing things. >> >> >> Here's what a very basic plugin looks like. It's (on mac) a dylib linked >> against the static lib libPluginBase: >> >> >> ### start HelloWorld.cpp ### >> >> #include "linden_plugin_common.h" >> >> // Find extra interface types in llpluginterfaceshared.h >> PlugInterfaceType interfaces_requested[] = >> { >> PI_TYPE_IO, >> >> PI_TYPE_END >> }; >> >> // plugin name, your plugin version, SL name, plugin homepage, plugin >> flags, interfaces requested >> PLUGIN_DECLARE( "Hello Printer", "0.01", "Soft Noel", "http://foo.org/", >> PLUGIN_FLAGS_DEFAULT, interfaces_requested ); >> >> >> bool PluginStartup() >> { >> pIO->LogPrint( "Hello world." ); >> >> return true; >> } >> >> >> void PluginShutdown( bool crash ) >> { >> if( !crash ) >> pIO->LogPrint( "Goodbye world." ); >> } >> >> ### end HelloWorld.cpp ### >> >> These are the interesting things here: >> >> interfaces_requested is a taglist of enums representing interfaces we >> need. These would be things like IO, UI, SYSTEM. END terminates the >> list. >> >> PLUGIN_DECLARE tells the library that "Hello Printer" is the name of >> this >> plugin, "0.01" is our version number, "Soft Noel" is the author, and >> "http://foo.org" is where the user can go browse for updates. All of the >> information so far will (later) be displayed in a floater in an SL >> plugin >> manager. For now, I hard-load plugins unconditionally. The flags will be >> used for identifying plugins that should default to being disabled in >> certain circumstances, for example when an author wants to send out a >> plugin he prefers to be used on a beta grid for now. >> >> Everything in PLUGIN_DECLARE gets turned into an accessor function so >> that >> the viewer can inspect a plugin's requirements before deciding whether >> to >> activate it. In addition, PLUGIN_DECLARE creates an accessor with the >> version of libPluginBase in use, which is used in negotiating an >> interface >> bundle. (More on that in a bit.) >> >> PluginStartup gets called when a plugin is activated. By this point, all >> interfaces have already been acquired. No plugin developer code is ever >> called before this point. >> >> PluginShutdown is called when a plugin is terminated, either politely by >> (later) the plugin management floater or viewer exit, or rudely by crash >> protection. Ideally, interface functions will scrutinize input for >> dangerous data/behaviors, print a warning to the log, and terminate a >> plugin before it has a chance to crash the viewer. I'm thinking more >> about >> plugin developer iteration time here than I am about end users. I'm >> adamant about quick iteration times for casual developers, or they lose >> interest fast, so if we can unload/deactivate (Mac doesn't unload >> dylibs, >> just abandons them!) their plugin without booting them from the viewer >> and >> sit ready to load their next plugin build, it's a big win. >> >> Note that I'm far from married to the pINTERFACENAME->Method() calling >> convention in the example above. Suggestions about what methods and >> accessors should look like to plugin developers are welcome. >> >> >> On to the viewer... >> >> Currently all new viewer files reside in indra/llplug, and patches >> outside >> this directory are minimal. A plug (as in the directory name) is the >> client side of plugin. Here are the major actors and their roles: >> >> LLPlugInterface, base of LLPlugInterfaceIO, LLPlugInterfaceUI, etc >> >> The LLPlugInterfaceIO was that pIO we saw in the plugin. Each >> LLPlugInterface derivative implements a subset of the overall available >> API. Originally I was going to put it all in one glom, but after a >> discussion with Rob Linden about the specialized interfaces in Real's >> plugin SDK, I came to realize that parceling this out would be helpful. >> The main reason is that some interfaces like a graphic interface will >> deprecate more quickly than something like an IO interface. If we try to >> maintain backward compatibility, it will be better if it's not an >> all-or-nothing affair. (More on that in a bit.) >> >> LLPlugInterfaces come from an LLPlugInterfaceFactory and are retained by >> an LLPlugInterfaceManager. LLPlugInterfaceFactory takes a request for an >> LLPlugInterface type and a version and returns a compatible interface or >> declines the request if an interface version is deprecated or newer than >> the viewer. Interface versioning was the source of some contentious >> discussion, but it really isn't the headache it sounds like, so I'll >> prove >> that out here: >> >> ### start llpluginterfacefactory.cpp ### >> >> #include "linden_common.h" >> >> #include "llplugshared.h" >> #include "llpluginterfaceio.h" >> #include "llpluginterfacesystem.h" >> #include "llpluginterfaceui.h" >> >> #include "llpluginterfacefactory.h" >> >> >> typedef LLPlugInterface *(*IFMakerFunc)(); >> >> >> struct InterfaceMakerEntry >> { >> const char *min_ver, *max_ver; >> PlugInterfaceType type; >> IFMakerFunc maker_func; >> bool nearly_deprecated; >> }; >> >> >> // C++ has no type variable or name-based construction, so: >> LLPlugInterface *PIFMakeIO_Head() { return new LLPlugInterfaceIO; } >> LLPlugInterface *PIFMakeSystem_Head() { return new >> LLPlugInterfaceSystem; } >> LLPlugInterface *PIFMakeUI_Head() { return new LLPlugInterfaceUI; } >> >> >> static InterfaceMakerEntry InterfaceMakers[]= >> { >> // Always put newest interfaces at the top. Engine uses the >> first fit. >> { "2007.02.22 00", pluginEngineVersion, PI_TYPE_IO, >> PIFMakeIO_Head, false }, >> { "2007.02.22 00", pluginEngineVersion, PI_TYPE_SYSTEM, >> PIFMakeSystem_Head, false }, >> { "2007.02.22 00", pluginEngineVersion, PI_TYPE_UI, >> PIFMakeUI_Head, false }, >> >> // Old interfaces on the way out: >> }; >> >> >> static S16 InterfaceMakerFindIndex( const char *version, >> PlugInterfaceType >> type ) >> { >> for( S16 i = 0; i < >> sizeof(InterfaceMakers)/sizeof(*InterfaceMakers); i++ ) >> { >> InterfaceMakerEntry *ime; >> ime = &InterfaceMakers[i]; >> >> if( type != ime->type ) >> continue; >> >> // This is not intuitive. Think of it like this: >> "v01Bogo", "v00Zippy" - >> strcmp >> // will get to the third char and return '1'-'0' = 1, >> meaning the requested >> // version of v00Zippy is too old, as it's "less" than >> v01Bogo. >> if( strcmp( ime->min_ver, version ) > 0 ) >> continue; >> >> if( strcmp( ime->max_ver, version ) < 0 ) >> continue; >> >> return i; >> } >> >> return -1; >> } >> >> >> static IFMakerFunc InterfaceMakerFind( const char *version, >> PlugInterfaceType type ) >> { >> S16 i; >> index = InterfaceMakerFindIndex( version, type ); >> >> if( i >= 0 ) >> return InterfaceMakers[i].maker_func; >> >> return NULL; >> } >> >> >> static bool InterfaceMakerIsNearlyDeprecated( const char *version, >> PlugInterfaceType type ) >> { >> S16 index; >> index = InterfaceMakerFindIndex( version, type ); >> >> if( index >= 0 ) >> return InterfaceMakers[index].nearly_deprecated; >> >> return false; >> } >> >> >> bool LLPlugInterfaceFactory::canCreate( const char *version, >> PlugInterfaceType type ) >> { >> IFMakerFunc ifm; >> >> ifm = InterfaceMakerFind( version, type ); >> >> return ifm ? true : false; >> } >> >> >> LLPlugInterface *LLPlugInterfaceFactory::create( const char *version, >> PlugInterfaceType type ) >> { >> LLPlugInterface *pi = NULL; >> IFMakerFunc ifm; >> >> ifm = InterfaceMakerFind( version, type ); >> if( ifm ) >> pi = ifm(); >> >> if( pi ) >> { >> if( InterfaceMakerIsNearlyDeprecated( version, type ) ) >> pi->deprecationWarningSet(); >> } >> >> return pi; >> } >> >> ### end llpluginterfacefactory.cpp ### >> >> The main item of interest is that InterfaceMakerEntry. For a given plug >> PlugInterfaceType, it declares the earliest and latest supported >> version, >> and tells how to make that interface. LLPlugInterfaceFactory::create >> (through helpers) scans for a compatible interface and builds it. Note >> that there can be multiple entries per PlugInterfaceType, so if >> PlugInterfaceIO is revised, we can keep an older version of the class >> around with a slightly different name and everything where older plugins >> expect it to be. This won't mean a bunch of duplicated code thanks to >> the >> PlugInterface compatibility_slave construct. (More on that in a bit.) >> The >> deprecation flag is for (later) informing a user via his plugin >> management >> panel that his plugin is likely to break in a coming release. These >> would >> be set when planning to prune the InterfaceMakers/legacy >> LLPlugInterfaces. >> >> The compatibility_slave construct: When freezing a version of an >> interface >> for backward compatibility, we create a version of the interface with an >> old version number, ie LLPlugInterfaceIOv1 which is derived from >> LLPlugInterface (not LLPlugInterfaceIO), and copy the old list of >> virtual >> functions into the new class. The new class would then create the next >> NEWER class and stuff it in its compatibility_slave pointer, and all >> functions would be direct calls to the compatibility_slave except where >> we >> need to add/remove function arguments, or otherwise make tweaks to make >> old-style calls continue to work. We can keep an arbitrary number of >> compatibility interfaces without further work, as they all simply chain >> upward through their compatibility slaves. This isn't done with class >> inheritance as we want to be able to reorder, add, and remove items in >> newer versions. We can't inherit older classes from newer classes >> without >> affecting the old structure. We can't inherit new classes from older >> classes without losing the ability to remove functions or change data >> formats. >> >> The LLPlugInterfaces are passed to the client in an LLPlugBundle. The >> bundle is never seen by plugin developers, only libPluginBase. The >> plugin >> developer just sees all those LLPlugInterfaces. LLPlugBundle comes from >> LLPlugBundleManager/LLPlugBundleFactory. The LLPlugBundle is an old >> fashioned struct, which contains LLPlugInterface pointers for all >> possible >> LLPlugInterface types, ex: >> >> struct LLPlugBundle >> { >> LLPlugBundle() >> { >> memset( this, 0, sizeof( *this ) ); >> } >> >> char *version; >> >> // 1. Don't re-order >> // 2. New interfaces must always be added to the BOTTOM. >> // >> // This struct may get passed to a plugin anticipating an older >> // version of the struct. >> >> // These are deliberately anonymous/downcast because we'll stuff >> // combinations of versions in to satisfy older interface >> version >> // requests. >> >> LLPlugInterface *plug_io; >> LLPlugInterface *plug_sys; >> LLPlugInterface *plug_ui; >> }; >> >> >> Jumping back up a bit, we've got our LLPlugBundle with LLPlugInterfaces >> getting passed to the plugin and turned into globals. Where this all >> happens is in an LLPlug, via LLPlugManager/LLPlugFactory. An LLPlug is >> created with the path of the corresponding plugin dylib as an argument. >> Straight away, LLPlugin::load() dlopen()s the plugin with RTLD_LAZY >> binding, and grabs its version and user displayable information. From >> this >> point on, LLPlugBundleFactory can tell us whether it will be able to >> create a compatible set of LLInterfaces, and we can decide if we want to >> LLPlugin::enable(), which acquires the interfaces and tells >> libPluginBase >> to set things up and call the plugin developer's PluginStartup(). >> >> Of note, each LLPlug has a unique serial number that will be attached to >> and used for cleaning up orphaned resources like floaters, menu entries, >> and hooks. And this brings us to hooks. >> >> I'm in the middle of a rework on hooks right now after a discussion at >> Rob >> Linden's office. Originally, I was having the plugin author create a >> class >> implementing all possible hooks, just as a hack to get things working. >> This isn't maintainable of course, and I'm waffling between two >> approaches. One is a class like the above, but specialized for each API >> subset. The other is moving to a subscription model similar to what >> Bushing proposed. You can see his sample at >> https://wiki.secondlife.com/wiki/Hook_example_code ... the main >> differences would be that I'd want to work with templated versions based >> on parameter structures to avoid anonymous data, and I'd have an >> instance >> of the class per hookable code point rather than trying to keep it >> generic >> like the above example. >> >> >> I'll hand off the above soon, then everyone can start nitpicking about >> the >> implementation and I'll happily iterate to make this shiny. I'm hoping >> people will step in at that point to start filling out the >> LLPlugInterfaces with a useful set of API calls and hooks. I want to get >> Kelly's suggested data floater example going, then convert Dale's >> scanner >> early on, so my own API calls will revolve around those. If you have a >> pet >> project, now's a good time to start proposing APIs. >> >> There are other useful areas for ongoing discussion if you want to >> continue to help me. One that I'm coming up against when we start adding >> plugin-driven floaters is the question of where we want to install >> plugins >> and supplemental data. My thinking is something like this: >> >> SLDATADIR = ~/Library/Application Support/SecondLife (or Windows/Linux >> equivalent) >> SLPLUGDIR = $SLDATADIR/plugins >> >> SLPLUGDIR would contain all the plugin dylibs, DLLs, etc >> >> Optional folders for data would use the the plugin's self-provided name, >> ex: >> SLPLUGDIR/Hello World/hellotext.xml >> >> For simplicity, we could give plugin developers a function that opened >> files with this path. >> >> Similarly, for dynamic data, do we want functions to facilitate creating >> and accessing per-user-perplugin data directories like this? >> SLPLUGDATADIR = SLDATADIR/$SLNAME/$PLUGINNAME/settings.xml ? >> >> Another coming issue is that I'd like to avoid doing too much UI work >> myself. If someone's eager to create the plugin management floater xml >> and >> related dialogs and own future changes, I'd be grateful. What the >> floater >> should look like and what dialogs it needs would be another good area >> for >> discussion. >> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev >> > From dale at daleglass.net Sat Feb 24 18:00:55 2007 From: dale at daleglass.net (Dale Glass) Date: Sat Feb 24 18:01:14 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <3b19a500702241727sd4802d4vc6afa74085471dfd@mail.gmail.com> References: <45E0ABC0.2040302@gmail.com> <200702250224.40063.dale@daleglass.net> <3b19a500702241727sd4802d4vc6afa74085471dfd@mail.gmail.com> Message-ID: <200702250301.03136.dale@daleglass.net> ? ????????? ?? 25 ??????? 2007 02:27 Tim Shephard ???????(a): > But, the cpu cycles to check the first character versus tokenize the > whole string everytime seems to me to be a bit more :) That overhead is completely trivial compared with pretty much anything in the client. And this is a very rare task, as chat messages are a very infrequent event (relatively speaking) -------------- 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/20070225/1cad9d46/attachment.pgp From gigstaggart at gmail.com Sat Feb 24 18:08:23 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sat Feb 24 18:08:21 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <200702250301.03136.dale@daleglass.net> References: <45E0ABC0.2040302@gmail.com> <200702250224.40063.dale@daleglass.net> <3b19a500702241727sd4802d4vc6afa74085471dfd@mail.gmail.com> <200702250301.03136.dale@daleglass.net> Message-ID: <45E0EF97.9060706@gmail.com> I renamed the article to be clearer: https://wiki.secondlife.com/wiki/Extensible_Prim_Attributes_from_LSL I'll add a section on using this feature for something like CSG too. -Jason From christian at electricsheepcompany.com Sat Feb 24 18:08:19 2007 From: christian at electricsheepcompany.com (Christian Westbrook) Date: Sat Feb 24 18:08:28 2007 Subject: [sldev] Viewer Manifest In-Reply-To: <45E0EBE2.2010201@lindenlab.com> References: <200702222327.02886.dale@daleglass.net> <1712.69.158.190.134.1172185977.squirrel@webmail.bluewax.com> <200702230017.32150.dale@daleglass.net> <45DE5634.600@lindenlab.com> <45E0EBE2.2010201@lindenlab.com> Message-ID: <946187B0-693B-401D-A437-84AE01F23764@electricsheepcompany.com> Agreed, Ryan, I appreciate your sharing the news about the new installer. Thraxis was good enough to quickly turn out a NSIS script that would allow us to ship OpenSL alongside SecondLife without running over user settings, or (eventually) things like using different kinds of caches, and upgrade independently. It's good to hear you say everyone will soon "see the code" -- does this mean the install script itself will be GPL'd as well? Thanks once again, Christian Westbrook SL: Christian Prior christian@openmetaverse.org On Feb 24, 2007, at 8:52 PM, Rob Lanphier wrote: > Hi Ryan, > > Thanks for posting this. > > For everyone else reading this list, I'm hoping you can give your > comments on this. One way to make it more likely that Lindens engage > with you on your ideas is when you return the favor. > > Comments inline: > > On 2/22/07 6:49 PM, Ryan Williams wrote: >> This seems like a great time to interject about an installer >> packaging >> script I'm introducing into the next release. >> >> The short story is that building an installer will be one step -- >> running a Python script. I don't know how much of our installer- >> making >> code has been released, but since the .nsi wasn't, probably "not >> much". >> > Ooops. That certainly wasn't by design. How does one go about > building > the installer? I'm assuming it's just a different build target. > > Has anyone actually tried to build an installer to date? >> Either way, with the next source release the installer-making >> capabilities should be fully operational. >> > Cool! Let me know which branch you checked your stuff into. > Whether or > not these changes make it into the very next release depends > greatly on > which branch it gets into. Certainly, though, "soon" is a correct > answer. >> I provided documentation for the file here: >> https://wiki.secondlife.com/wiki/Viewer_Manifest >> >> I'm certainly interested in discussion about the design and >> implementation of the script. Of course, not much discussion can >> happen >> until everyone see the code, but I just wanted to give a heads-up. >> > There seems to be plenty there for discussion, actually. > > One question that I have (because I know I'll get asked this down the > road)...is there existing technology that does this same function that > isn't too burdensome to switch to? This is a question for > everyone, not > just Ryan. I ask this sincerely, because even though I know this > problem has been tackled a gazillion times, I also know that the > solutions out there are often difficult to extract from the projects > that created them. > > Just to narrow the scope of what would be considered overlapping > technology, the idea is that this Python script creates a NSIS > installer > on Windows, a .dmg on Mac, and a tarball on Linux, right? Since > switching installer technologies (at least on Windows and Mac...on > Linux, something like Autopackage would be kinda cool) is probably > harder than writing a simple python wrapper from scratch, any viable > competing technology would need to be able to create an identical > installer, and have to have the same simplicity of being just a Python > script (or /maybe/ Perl). > > I wasn't able to find anything. If this is truly unique, one thing > that > would be very cool to see is someone take the ball and run with it. > We're not exactly in the cross-platform installer business, and this > seems like a problem that a lot of folks have (see > http://www.wxwidgets.org/wiki/index.php/Installers ). If there's > someone out there looking to form their own little independent open > source project, this might prove to be a great starting point > (assuming > Ryan hasn't grown too attached to it just yet). I could see this > either > taking on a life of its own, or perhaps being incorporated in a bigger > project. > > One piece of feedback regarding the platform magic (e.g. derive from > LLManifest and name your class "HP-UXManifest", and that will be > selected for use on HP-UX) Platform isn't the only relevant > variable in > choosing which class to use. For example, down the road, we may > wish to > have Linux .rpm, Linux .deb, Linux autopackage, etc. Additionally, it > may very well be that FreeBSD autopackage and Linux autopackage will > share more in common than Linux .rpm and Linux autopackage. So, > building out the class tree based exclusively on platform may not > be the > best thing. > > Rob > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From tshephard at gmail.com Sat Feb 24 18:35:05 2007 From: tshephard at gmail.com (Tim Shephard) Date: Sat Feb 24 18:35:08 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <200702250301.03136.dale@daleglass.net> References: <45E0ABC0.2040302@gmail.com> <200702250224.40063.dale@daleglass.net> <3b19a500702241727sd4802d4vc6afa74085471dfd@mail.gmail.com> <200702250301.03136.dale@daleglass.net> Message-ID: <3b19a500702241835i29d35b70s9d0284b354006c09@mail.gmail.com> hah! You probably don't use ownersay like I do :) That being said, I'm nitpicking and we both know it. On 2/24/07, Dale Glass wrote: > ? ????????? ?? 25 ??????? 2007 02:27 Tim Shephard ???????(a): > > But, the cpu cycles to check the first character versus tokenize the > > whole string everytime seems to me to be a bit more :) > > That overhead is completely trivial compared with pretty much anything in the > client. And this is a very rare task, as chat messages are a very infrequent > event (relatively speaking) > > From adri at metaversatility.com Sat Feb 24 18:42:18 2007 From: adri at metaversatility.com (Adrienne Haik) Date: Sat Feb 24 18:42:21 2007 Subject: [sldev] Open Source Panel Discussion at AMD in SL Tomorrow Message-ID: <71da16920702241842r2a64a0f3l5a26dea7013cb113@mail.gmail.com> AMD and Metaversatility present: "Open source movements in Second Life: Challenges and opportunities" Panel and Q&A featuring: Christian Prior (OpenSL), Gigs Taggart (OpenSL), and Frank Bogomil (Metaversatility) Location: AMD Developer Central (surl ) Time: 1:00-2:30 p.m. PST/SLT Join some of our community's leading authorities on open source projects in Second Life for an afternoon of substantive discussion. This event is bound to fill up quickly, so please be sure to join the AMD Developer Central group to secure priority admission. Panelists will answer the following questions as well as speaking on their projects' specific goals. - In what ways might open source software enrich the experience of Second Life residents who do not consider themselves to be programmers? - What significant initiatives have been launched within the development community since Linden announced it would open-source the client? - What pathways will lead to the creation of standards-compliant virtual world programming tools? - What will virtual worlds look like five, ten and fifteen years from now? Audience members will have the opportunity to pose their own questions to the panelists. Don't miss this opportunity to speak with some of the leaders in the SL Open Source community. [Posted with permission per Rob Linden] -- *Adrienne Haik* Adri Saarinen (SL) Metaverse Consultant Metaversatility (210) 683 - 1166 (866) 517 - 1408 (fax) [image: View Adrienne Haik's profile on LinkedIn] -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070224/6f2a37fe/attachment.htm From robla at lindenlab.com Sat Feb 24 21:54:57 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Sat Feb 24 21:55:12 2007 Subject: [sldev] First Look 1.13.3.58390 source code available Message-ID: <45E124B1.2080709@lindenlab.com> Hi all, The First Look 1.13.3.58390 source code is available now: https://wiki.secondlife.com/wiki/Source_downloads (as of this writing, the libraries are still uploading. should be up in 30 minutes or so) Changes documented here: http://blog.secondlife.com/2007/02/23/first-look-render-pipeline-update-58390-now-available/ 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/20070224/0a9f2aad/signature.pgp From rdw at lindenlab.com Sun Feb 25 02:37:24 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Sun Feb 25 02:37:30 2007 Subject: [sldev] Viewer Manifest In-Reply-To: <45E0EBE2.2010201@lindenlab.com> References: <200702222327.02886.dale@daleglass.net> <1712.69.158.190.134.1172185977.squirrel@webmail.bluewax.com> <200702230017.32150.dale@daleglass.net> <45DE5634.600@lindenlab.com> <45E0EBE2.2010201@lindenlab.com> Message-ID: <45E166E4.5000501@lindenlab.com> Rob Lanphier wrote: > Hi Ryan, > > Thanks for posting this. > > For everyone else reading this list, I'm hoping you can give your > comments on this. One way to make it more likely that Lindens engage > with you on your ideas is when you return the favor. > Thanks for the cheerleading! I am quite impressed by how much depth you are able to get at without looking at any code. > Comments inline: > > On 2/22/07 6:49 PM, Ryan Williams wrote: > >> This seems like a great time to interject about an installer packaging >> script I'm introducing into the next release. >> >> The short story is that building an installer will be one step -- >> running a Python script. I don't know how much of our installer-making >> code has been released, but since the .nsi wasn't, probably "not much". >> >> > Ooops. That certainly wasn't by design. How does one go about building > the installer? I'm assuming it's just a different build target. > > Packaging the installer is not part of the build process anywhere but Linux. Prior to the viewer_manifest, you built the installer like so: - On Windows: run the .bat file for the grid that you want the client to connect to. The .bat files did some housekeeping and then ran NSIS to generate an exe. I don't know if the .bat files were open-sourced; probably not. - On OS X: 'make -f Makefile_Mac image' called createimage.sh which built a .dmg. - On Linux it was part of the client build target. For backward compatibility, these methods are all rewired to use the viewer_manifest now. I think there is merit to the notion that building the installer should be an explicit action, since most builds don't use or need the installer, so it's just a waste of time unless you're specifically ready to make a release. Making it an optional part of the build would be cool, though. Going forward, the canonical way to package an installer will be simply running viewer_manifest.py with the appropriate arguments (though it could be hidden in the build process for sure). I express here the hope that viewer_manifest.py will not become a tangled pile of code. The crud I had to write to get the nsi file generation working correctly is far gnarlier than I'd ever want it to be. > Has anyone actually tried to build an installer to date? > >> Either way, with the next source release the installer-making >> capabilities should be fully operational. >> >> > Cool! Let me know which branch you checked your stuff into. Whether or > not these changes make it into the very next release depends greatly on > which branch it gets into. Certainly, though, "soon" is a correct answer. > >> I provided documentation for the file here: >> https://wiki.secondlife.com/wiki/Viewer_Manifest >> >> I'm certainly interested in discussion about the design and >> implementation of the script. Of course, not much discussion can happen >> until everyone see the code, but I just wanted to give a heads-up. >> >> > There seems to be plenty there for discussion, actually. > > One question that I have (because I know I'll get asked this down the > road)...is there existing technology that does this same function that > isn't too burdensome to switch to? This is a question for everyone, not > just Ryan. I ask this sincerely, because even though I know this > problem has been tackled a gazillion times, I also know that the > solutions out there are often difficult to extract from the projects > that created them. > > Just to narrow the scope of what would be considered overlapping > technology, the idea is that this Python script creates a NSIS installer > on Windows, a .dmg on Mac, and a tarball on Linux, right? Since > switching installer technologies (at least on Windows and Mac...on > Linux, something like Autopackage would be kinda cool) is probably > harder than writing a simple python wrapper from scratch, any viable > competing technology would need to be able to create an identical > installer, and have to have the same simplicity of being just a Python > script (or /maybe/ Perl). > That's the correct scope, though I'm not sure what you mean at the end there. Do you mean that if we were to find something to supplant llmanifest, that it would have to be at least as easy to switch to as it is to pile more functionality into llmanifest? Something like InstallAnywhere (http://www.zerog.com/)? It looks like they have an easy 11-step process to building an installer. :-P > I wasn't able to find anything. If this is truly unique, one thing that > would be very cool to see is someone take the ball and run with it. > We're not exactly in the cross-platform installer business, and this > seems like a problem that a lot of folks have (see > http://www.wxwidgets.org/wiki/index.php/Installers ). If there's > someone out there looking to form their own little independent open > source project, this might prove to be a great starting point (assuming > Ryan hasn't grown too attached to it just yet). I could see this either > taking on a life of its own, or perhaps being incorporated in a bigger > project. > > That sounds rad to me, though I doubt if this is truly new. I don't have any plans for developing this outside of our local needs, but I'd certainly support anyone who's interested in turning it into an independent project with a life of its own. > One piece of feedback regarding the platform magic (e.g. derive from > LLManifest and name your class "HP-UXManifest", and that will be > selected for use on HP-UX) Platform isn't the only relevant variable in > choosing which class to use. For example, down the road, we may wish to > have Linux .rpm, Linux .deb, Linux autopackage, etc. Additionally, it > may very well be that FreeBSD autopackage and Linux autopackage will > share more in common than Linux .rpm and Linux autopackage. So, > building out the class tree based exclusively on platform may not be the > best thing. > That's a great point. I think you're right -- it should move away from a class-hierarchy model towards a composition model, wherein you say something like "llm = LLManifest(); llm.construct = WindowsManifest.construct; llm.package_finish = MSIpackage_finish". (yes I know that using semicolons as statement delimiters is so unpythonic) Using Python's functional features is probably key here. Then the knowledge about how to find all the files for a particular platform is decoupled from knowledge on how to bundle them into an installer. Another thing to consider is making the manifest more developer-extensible. I hear talk about custom install locations, custom settings files, etc. All that stuff is hardcoded into the manifest at the moment, and it would be nice to be able to break them out into config files, command-line arguments, or something so that developers don't have to modify the manifest itself just to release a custom viewer. What are the most useful variables to break out in this way? I can think of a few: - Name of app (Install directory on Windows, .app name on Mac, name of directory in Linux tarball) - Default command-line arguments to client - Name/location of settings - Login screen url (already a command line argument to viewer_manifest) Thanks for the insight! -RYaN From ch.nolte at noltec.org Wed Feb 21 09:56:33 2007 From: ch.nolte at noltec.org (Christian Nolte) Date: Sun Feb 25 12:25:53 2007 Subject: [sldev] Re: Second Life client packaged for Fedora In-Reply-To: <1171618531.2953.14.camel@localhost.localdomain> References: <1171618531.2953.14.camel@localhost.localdomain> Message-ID: <45DC87D1.9060505@noltec.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Callum! Callum Lerwick schrieb: > Okay, after much pain, sorrow and apparently duplicated effort[*] I > finally managed to get a vaguely usable Second Life package + deps: > > http://www.haxxed.com/rpms/secondlife/ > > * spot has some packages too: > > http://www.auroralinux.org/people/spot/SecondLife/ > > Don't expect his and mine to be interchangeable just yet. I guess we > have some merging to do... > Thanks for your time and effort with this! The only problem I've encountered was that it is explicitly necessary to define ARCH=i686 before the secondlife-firstlook SRPM can be built. This is a problem of the linden/indra/Scons script which only accepts i686 as valid arch. Best regards! Christian - -- Christian Nolte key : http://www.noltec.org/christian-nolte.asc or : www.keyserver.net GPG-fingerprint: 1088 6C2D 1496 0A34 D159 1108 08D8 C0D2 77E1 5BBC - ---------------------------------------------------------------- For more than 4 generations the IT Professionals were the guardians of quality and stability in software. Before the dark times. Before Microsoft... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFF3IfRCNjA0nfhW7wRAjF5AJ4wBqLGlDXobHwTh1MdlqP/7d7tywCfR5nl ppn7qW4tkfnGj70aaVdB8+Q= =7S4U -----END PGP SIGNATURE----- From patricelevexier at bellsouth.net Wed Feb 21 13:31:06 2007 From: patricelevexier at bellsouth.net (patricelevexier@bellsouth.net) Date: Sun Feb 25 12:25:56 2007 Subject: [sldev] embedded mono on the SL client Message-ID: <20070221213106.EVDO20344.ibm56aec.bellsouth.net@mail.bellsouth.net> Hello all, I would like to know what is the status of embedding Mono on the SL client. Someone already begun to work on it? Thanks. Patrice From alissa_sabre at yahoo.co.jp Sat Feb 24 22:49:06 2007 From: alissa_sabre at yahoo.co.jp (alissa_sabre@yahoo.co.jp) Date: Sun Feb 25 12:25:57 2007 Subject: [sldev] Re: Plugin architecture Message-ID: <45E09857.2020309@gmail.com> I'm concerned with recent plugin/LSL discussion. I don't want to see any script that requires some particular plugin and/or non-standard Viewer feature. I want all scripts to be able to run on all official Viewer without any specific plugin. Hence, I don't want to have any LSL extention that allows script writer to access to some particular plugin and/or some particular Viewer feature. The key concern here is the interoperability between Viewers with different sets of plugins. Assume one in-world object, say XYZ necklace, has an embedded script, and the script accesses the XYZ plugin's own feature. What happens if I wear the XYZ neckalce and walk around? I'm afraid of the disruption of the SL users. Plugin mechanism is OK, but I hope it doen't break interoperability that we have today. Alis -------------------------------------- Start Yahoo! Auction now! Check out the cool campaign http://pr.mail.yahoo.co.jp/auction/ From mindtriggerz at gmail.com Sun Feb 25 12:47:03 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Sun Feb 25 12:47:07 2007 Subject: [sldev] Re: Plugin architecture In-Reply-To: <45E09857.2020309@gmail.com> References: <45E09857.2020309@gmail.com> Message-ID: Well, with LSL object metadata, there's no risk of noninteroperability. The client can either interpret the metadata or just not add the feature. On 2/25/07, alissa_sabre@yahoo.co.jp wrote: > I'm concerned with recent plugin/LSL discussion. > > I don't want to see any script that requires some particular plugin > and/or non-standard Viewer feature. I want all scripts to be able to > run on all official Viewer without any specific plugin. > > Hence, I don't want to have any LSL extention that allows script > writer to access to some particular plugin and/or some particular > Viewer feature. > > The key concern here is the interoperability between Viewers with > different sets of plugins. > > Assume one in-world object, say XYZ necklace, has an embedded script, > and the script accesses the XYZ plugin's own feature. What happens if > I wear the XYZ neckalce and walk around? > > I'm afraid of the disruption of the SL users. > > Plugin mechanism is OK, but I hope it doen't break interoperability > that we have today. > > Alis > > > -------------------------------------- > 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 > -- --Jesse From gigstaggart at gmail.com Sun Feb 25 17:38:00 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Sun Feb 25 17:37:49 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <45E09857.2020309@gmail.com> References: <45E09857.2020309@gmail.com> Message-ID: <45E239F8.5010301@gmail.com> You have misunderstood the intent of the LSL-initiated prim metadata. The intent is not to permanently create features this way, in fact it's unsuitable for this, by design. Because there would only be one LSL accessible metatag, it would be difficult to coordinate the use of it between more than one plugin/new feature. The idea is that the features will become "official" after being prototyped using this LSL initiated metadata. The higher metatag numbers would be reserved for only accepted features that Linden Lab has begun laying the framework for on the back end. It would not be practical for a retail product to ever rely on a "tag 0" feature, since such a feature, by definition, is of limited deployment, and may in fact even crash clients with a different tag 0 feature enabled. It is purely for temporary use during development. alissa_sabre@yahoo.co.jp wrote: > I'm concerned with recent plugin/LSL discussion. > > I don't want to see any script that requires some particular plugin > and/or non-standard Viewer feature. I want all scripts to be able to > run on all official Viewer without any specific plugin. > From prince.jah at gmail.com Mon Feb 26 00:29:20 2007 From: prince.jah at gmail.com (m t) Date: Mon Feb 26 00:29:22 2007 Subject: [sldev] SecondLife_i686_1_13_3_58018_FIRSTLOOK the last client which works with aterm on linux Message-ID: <5d040edd0702260029v11509d44kebe2ed7317cd8fe2@mail.gmail.com> Wanted to write that 58018 was the last client which worked for me, but just realized that the client only stoped to work when i start it from aterm. When i start from xterm or from a menu it starts flawlessly Regards, Miron From prince.jah at gmail.com Mon Feb 26 00:42:08 2007 From: prince.jah at gmail.com (m t) Date: Mon Feb 26 00:42:10 2007 Subject: [sldev] Re: SecondLife_i686_1_13_3_58018_FIRSTLOOK the last client which works with aterm on linux In-Reply-To: <5d040edd0702260029v11509d44kebe2ed7317cd8fe2@mail.gmail.com> References: <5d040edd0702260029v11509d44kebe2ed7317cd8fe2@mail.gmail.com> Message-ID: <5d040edd0702260042i175965dco49a10925f7da534b@mail.gmail.com> Don't know what happend but now it starts also from aterm, before i started it from xterm i allways had a crash after logging in. 2007/2/26, m t : > Wanted to write that 58018 was the last client which worked for me, > but just realized that the client only stoped to work when i start it > from aterm. When i start from xterm or from a menu it starts > flawlessly > Regards, Miron > From kamilion at gmail.com Mon Feb 26 00:52:07 2007 From: kamilion at gmail.com (Kamilion) Date: Mon Feb 26 00:52:11 2007 Subject: [sldev] Plugin Archatecture Message-ID: Well, apparently, the last time I sent this to the list in January, a few hours after the viewer was open sourced, nobody was on the list yet. So here we go a second time. (Edit: After checking the list archives, it appears my message was never posted... I think this was because I was trying to be smaert and subscribed as Kamilion+sldev@gmail.com instead of Kamilion@gmail.com, and the message was moderated out because I "wasn't" subscribed to the list. Here's the message again, dated 1/11/2007, 3:42PM. >> On 1/11/2007 3:42 PM, Kamilion The Great wrote: It's my feeling that the simplest way to implement a pluggable architecture in SL and remain agnostic would be to implement three phased designs... The first would be clientside; and basically open a local TCP stream port, netcat/telnet style. This port would accept LLSD serialized commands to be executed on behalf of an external application, including such functions as: #1: Packet interception and routing/rerouting: Register a callback when certain packet types arrive, or certain caps are active. #2: Chat interception and transmission on positive and negative channels: for instance, MYLSLMonitorDump.sh asks SecondLife.exe to pass a note to the server asking for traffic on channel - 1276384, and when traffic of this type is received, passed on to the application. #3: Specific status messages, and sideband control commands: Console messages can be redirected, as well as internal status counters and graphs such as Fast Timers and it's friends. Specific commands could also be targeted at subsystems, such as flipping DebugSettings (within reason, we'd likely want to keep a DebugSetting of AllowLLSDPluginHosts = 127.0.0.1 as a default) #4: Inventory Control commands: Enumerating the inventory list, performing actions on the enumerated list, Item information requests and item transfer requests. (This data really should be cached most of the time, and we should just ask if it's changed instead of asking for the data) #5: Control level commands: Sending movement and camera commands to the client. Such a thing would be utilized for many different kinds of human interfaces, ranging from a P5 data glove to even a wiimote, game pad or HMD visor head tracker. -- That takes care of most of the interfacing. Now comes the serverside: Linden Labs needs to start a certification authority; Certificates should be free and instantly available by going to something like certs.secondlife.com. Certificates can be used for many many things, just like SSL certificates -- they're basically bytestamps that can be *revoked*. Other than that, they're really just unique public keys. Things this could be used for: Signing Plugin Aggregation proxies; When a LLSD client connects to SecondLife.exe, SL should ask for a certificate ID, which it can then verify as not being revoked, and allow the client aggregation proxy to connect. Other more specific 'plug ins' can connect to the proxy in any nessicary protocol (for instance, an aggregation plug in might connect to SecondLife.exe, and link to the chat and inventory functions, perform inventory functions internally, and provide *another* port on 6667 for an IRC client to connect (like bitlbee) to interface with chat, or XMPP for a jabber client.) Signing Scripts -- One or many certificates can be an object type in SL, like a calling card. This can be 'applied' to a script for specific functionality... For instance, without the proper level of certificate, you cannot use llRezObject more than 10 times per minute. Should you need to perform rezzing faster than this, apply for a certificate, receive it instantly or provisionally, and apply your certificate to a script. If you go out and do harm with it, for instance, use it to generate grey goo, then the certificate can be revoked and the script will be again limited to no more than 10 times per minute. Participation certificates: Let's say I went to SLCC '06. (I did.) While I was at SLCC '06, I got a badge, which means I had to register for it. During this registration process, say a linden (we'll use our favorite Watermelinden in this case...) adds a certificate for someone who shows up; and now I've got an SLCC '06 participation certificate. A neat way to show this off would be listing active, expired, and revoked certificates in the profile, with different color codes. Finding a scripter with multiple red certificates might be a warning sign that you'd want to stay away from them. -- That takes care of authentication. And the third step -- SCRIPT PRIORITIES & CERTIFICATION (once we have the Mono VM). I run a vendor system, which has quite a few servers. I'd like to apply for a certificate so that my vendor servers would run in my sim with a raised priority. Also, I'd also like to apply for a certificate that would allow me to run scripts with a *dropped* priority, simply by dropping my certificate on the script. This would be very handy for simple scripts that I use everywhere, for instance, the lights in my sim that turn on and off at dawn. They really don't need to have very high priority at all. It would also be useful for many other things to have dropped priority such as certain scripts in my vendor for instance (the advertising display comes to mind)... Now this doesn't necessarily have to require certificates, but it seems like the easiest way to agree on and set properties on something securely -- as well as being extensible in the future if 3rd party servers are ever allowed in the simulator cloud, while still keeping control in Linden Labs' hands. This could be extended as well, for instance, "Bob" has an OpenSIM server he runs on his personal linux server in a datacenter somewhere. Bob gets a certificate to connect to the simulator cloud. Bob decides he'd like some money, so he decides to modify his sim to funnel more money than he's really paid in his personal space. Well, this is quite unacceptable, and one of these transfers is noticed! Oh no, Bob's certificate has just been revoked, and now his simulator cannot interact with the cloud (or interacts in a more loose way, such as now disabling monitary transfers in the region entirely, while still allowing it to connect). Or, Bob could decide he'd like to write an automated script to spam people. Most of this hinges on keeping people honest, while still allowing full access to the service with a minimum of hassle. It really shouldn't be too hard to open your web browser at 3:17 in the morning, surf to secondlife.com, login, and head to certs.secondlife.com to register for a specific privilege. The key factor here is the ability to revoke these certificates/capibilites -- giving people Carte Blanche to work on their products until they do something wrong. It also becomes much easier to punish residents for transgressions, once we have some kind of a courthouse system... Anyway, that's just my two cents. -- Kamilion Schnook > This concludes the message that would have been posted a while back had I not attempted to amuse myself with gmail's filters.... Good thing I kept the message, eh? Anyway, A lot of people seem to have had the same ideas as I did; but I think I might have originated the certificate idea. It goes well in conjunction with everything -- as long as they're free and easy to obtain without too much hassle. Interested to see what responses people have to this, now that it's actually being read. (Man, I feel like a goof now.) Cheers~! -- Kamilion Schnook (Graham Cantin) From signore at autistiche.org Mon Feb 26 02:42:59 2007 From: signore at autistiche.org (signore@autistiche.org) Date: Mon Feb 26 02:43:06 2007 Subject: [sldev] Re: SecondLife_i686_1_13_3_58018_FIRSTLOOK the last client which works with aterm on linux In-Reply-To: <5d040edd0702260042i175965dco49a10925f7da534b@mail.gmail.com> Message-ID: Could this be due to the "locale" recent problem? That would be a known bug: https://jira.secondlife.com/browse/VWR-133 Did you try (both of you) running this command before starting the viewer? export LANG=en_US.UTF-8 If that works, you may also add export LANG=en_US.UTF-8 in the "secondlife" script - that should work too. hope it helps / bye, Signore Iredell -- http://signore.wordpress.com In data 26/2/2007, "m t" ha scritto: >Don't know what happend but now it starts also from aterm, before i >started it from xterm i allways had a crash after logging in. > >2007/2/26, m t : >> Wanted to write that 58018 was the last client which worked for me, >> but just realized that the client only stoped to work when i start it >> from aterm. When i start from xterm or from a menu it starts >> flawlessly >> Regards, Miron >> >_______________________________________________ >Click here to unsubscribe or manage your list subscription: >https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev From soft at softnoel.org Mon Feb 26 09:59:30 2007 From: soft at softnoel.org (Soft Noel) Date: Mon Feb 26 09:59:34 2007 Subject: [sldev] Plugin system - first code drop Message-ID: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> I've started creating accessors and hooks for the UI system, which is turning into a heck of a lot of calls as I'd predicted. Some other ideas were floated for the interface, such as overriding existing classes instead of using callback hooks. Here's a drop of the plugin system before I added callback hooks and started on my UI stuff. If someone wants to write some test code for another approach, please feel free. Otherwise, I'll drop my UI stuff on the list with callback hooks once I've got Dale's scanner working as a plugin. Right now, the system works with Mac and probably Linux. Linux needs the contents of indra/lljack added to the viewer project, plus a build project for the SDK and the plugin sample. For Windows, you'd need to do a wide string conversion in LLPlugin::loadSys() and double-check that host-side PLUGIN_CALLSPEC define. If nobody else does this, I'll fix it myself next time I'm near a Windows machine. My Parallels install gave up the ghost when I tried upgrading to the Parallels beta, and the release version couldn't actually run the client anyway. Build & run instructions: apply plugin system patch: http://softnoel.org/pluginsystem.patch copy select headers from viewer source: cd to plugin/PluginSDK/utils ./comhead_cp.sh put your plugin path in temporary plugin manager: LLPluginManager::pluginsEnumerate (LLPluginManager is placeholder until we have a nice GUI for the plugins.) Build DEBUG plugin/PluginSDK project Build DEBUG plugin/HelloWorldPlugin project Build any target macview project Activate plugins via the edit menu If you see "Hello World" on the ctrl-shift-4 debug console, you're properly loading and running the HelloWorldPlugin plugin. You're ready to create your own plugin interfaces by editing lljackio, lljacksystem, and lljackui. Use the single function in lljacksystem as a reference example. All you need to do to expose a feature to a plugin is add to these interfaces. If anyone wants to hang around in-world and talk plugins after Rob's office hours today, I'd be eager to do so. From emaslows at umich.edu Mon Feb 26 11:25:00 2007 From: emaslows at umich.edu (Eric Maslowski) Date: Mon Feb 26 11:25:07 2007 Subject: [sldev] Stereoscopic Viewer Message-ID: <038001c759db$cee9d7d0$f21fd58d@adsroot.itcs.umich.edu> Hello all, Some of you may have already heard that we have created a prototype for stereoscopic viewing of SL. (http://um3d.dc.umich.edu/) We're looking at building a version that is more robust, works with all visual features of SL, is easily enabled/disabled, and is suitable for inclusion in the regular SL distribution. I have several questions for the group here. 1) which distro should we be using? (SL, FL, OpenSL, etc.) We have an interested 3rd party which is driving the stereo viewer's development and we would like to create a version that would absolve us from updating our code every time a new change is made to the linden source. Thus, allowing our 3rd party and everyone else in the SL community to obtain it worry-free. 2) Is there anyone from Linden Labs (or otherwise) that we could contact for specific questions about the rendering pipeline? We ran into some issues with the 3D HUD showing properly for the second eye and may need some tips and hints to speed up the debugging process. 3) I've read through the wiki about adding features, but was curious as to what the turn around time is for code to make it into the standard distribution. Thanks all E. --- Eric Maslowski Research Computer Specialist University of Michigan 3D Lab Autodesk 3D Studio Max Certified Trainer email: emaslows@umich.edu office: 734-615-9699 mobile: 734-730-9904 From monkowsk at watson.ibm.com Mon Feb 26 11:35:30 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon Feb 26 11:36:44 2007 Subject: [sldev] Lip-sync In-Reply-To: <45DFBE98.9080501@lifeart.net.au> References: <45DB36A3.60004@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <200702222156.07839.dale@daleglass.net> <6E0A6592-256B-41D2-92A7-49E20D86D5CD@secondlife.com> <45DE1868.3080002@watson.ibm.com> <45DFBE98.9080501@lifeart.net.au> Message-ID: <45E33682.3030405@watson.ibm.com> Mathew Frank wrote: > I'm also interested in this. Lip-sync is the perfect voice complement - Mathew, I've summarized some ideas regarding lip-sync at https://wiki.secondlife.com/wiki/Talk:Linden_Lab_Bounties Maybe you could add your ideas there. I've just started looking at the audio parts of SecondLife, but I see that it uses FMOD 3.7.4 for streaming audio, although I don't imagine that includes voice. It's not clear what's going on there. Will it be converted to FMOD Ex 4? (see http://www.fmod.org/ ) Will it rely on ViVox for voice? (see http://www.vivox.com/millionmins.html ) Mike From davep at lindenlab.com Mon Feb 26 11:46:36 2007 From: davep at lindenlab.com (Dave Parks) Date: Mon Feb 26 11:46:45 2007 Subject: [sldev] Stereoscopic Viewer In-Reply-To: <038001c759db$cee9d7d0$f21fd58d@adsroot.itcs.umich.edu> References: <038001c759db$cee9d7d0$f21fd58d@adsroot.itcs.umich.edu> Message-ID: <45E3391C.2030204@lindenlab.com> Cool. If you're working on top of the core render pipeline classes (LLDrawPool, LLViewerObject, LLDrawable, LLPipeline), you'll want to build against first look, as there are significant architectural changes to the renderer. If you're just doing everything at the window creation level, that code hasn't changed. The work from first look will be merged down into the main distribution when it's done. As for the HUD objects, the render path for those objects has been completely removed and rewritten from scratch in FL. They now use the same pipeline as the rest of the world, but use a custom camera transform. If you check out the FL client, you'll want to look in LLViewerDisplay.cpp setup_hud_matrices. Fenagling that matrix should do what you want. After you submit the patch set, send me an e-mail and I'll look at integrating it. What stereo hardware would you recommend for testing? Eric Maslowski wrote: > Hello all, > Some of you may have already heard that we have created a prototype for > stereoscopic viewing of SL. (http://um3d.dc.umich.edu/) We're looking at > building a version that is more robust, works with all visual features of > SL, is easily enabled/disabled, and is suitable for inclusion in the regular > SL distribution. I have several questions for the group here. > > 1) which distro should we be using? (SL, FL, OpenSL, etc.) We have an > interested 3rd party which is driving the stereo viewer's development and we > would like to create a version that would absolve us from updating our code > every time a new change is made to the linden source. Thus, allowing our 3rd > party and everyone else in the SL community to obtain it worry-free. > > 2) Is there anyone from Linden Labs (or otherwise) that we could contact for > specific questions about the rendering pipeline? We ran into some issues > with the 3D HUD showing properly for the second eye and may need some tips > and hints to speed up the debugging process. > > 3) I've read through the wiki about adding features, but was curious as to > what the turn around time is for code to make it into the standard > distribution. > > Thanks all > > E. > > --- > Eric Maslowski > Research Computer Specialist > University of Michigan 3D Lab > > Autodesk 3D Studio Max Certified Trainer > > email: emaslows@umich.edu > office: 734-615-9699 > mobile: 734-730-9904 > > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From satwik at mit.edu Mon Feb 26 16:24:40 2007 From: satwik at mit.edu (Satwik Seshasai) Date: Mon Feb 26 16:24:43 2007 Subject: [sldev] SL data gathering? Message-ID: <6378c0b90702261624n60811328t5174362f671b2dce@mail.gmail.com> I am a graduate student at MIT and looking to do some gathering of usage data for a class project. Does anyone have any suggestions on who to contact or where to go for this information? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070226/bbc985f7/attachment.htm From tshephard at gmail.com Mon Feb 26 16:59:32 2007 From: tshephard at gmail.com (Tim Shephard) Date: Mon Feb 26 16:59:35 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> Message-ID: <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> Can you post a couple of sample hooks? Are you doing it via a proxy llFloater class? Great energy. Let me know your secret on how you can afford to spend the time. Cheers, Tim. On 2/26/07, Soft Noel wrote: > I've started creating accessors and hooks for the UI system, which is > turning into a heck of a lot of calls as I'd predicted. Some other ideas > were floated for the interface, such as overriding existing classes > instead of using callback hooks. Here's a drop of the plugin system before > I added callback hooks and started on my UI stuff. If someone wants to > write some test code for another approach, please feel free. Otherwise, > I'll drop my UI stuff on the list with callback hooks once I've got Dale's > scanner working as a plugin. > > Right now, the system works with Mac and probably Linux. Linux needs the > contents of indra/lljack added to the viewer project, plus a build project > for the SDK and the plugin sample. For Windows, you'd need to do a wide > string conversion in LLPlugin::loadSys() and double-check that host-side > PLUGIN_CALLSPEC define. If nobody else does this, I'll fix it myself next > time I'm near a Windows machine. My Parallels install gave up the ghost > when I tried upgrading to the Parallels beta, and the release version > couldn't actually run the client anyway. > > Build & run instructions: > > apply plugin system patch: > http://softnoel.org/pluginsystem.patch > > copy select headers from viewer source: > cd to plugin/PluginSDK/utils > ./comhead_cp.sh > > put your plugin path in temporary plugin manager: > LLPluginManager::pluginsEnumerate > (LLPluginManager is placeholder until we have a nice GUI for the plugins.) > > Build DEBUG plugin/PluginSDK project > > Build DEBUG plugin/HelloWorldPlugin project > > Build any target macview project > > Activate plugins via the edit menu > > If you see "Hello World" on the ctrl-shift-4 debug console, you're > properly loading and running the HelloWorldPlugin plugin. You're ready to > create your own plugin interfaces by editing lljackio, lljacksystem, and > lljackui. Use the single function in lljacksystem as a reference example. > All you need to do to expose a feature to a plugin is add to these > interfaces. > > If anyone wants to hang around in-world and talk plugins after Rob's > office hours today, I'd be eager to do so. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dale at daleglass.net Mon Feb 26 17:05:16 2007 From: dale at daleglass.net (Dale Glass) Date: Mon Feb 26 17:05:41 2007 Subject: [sldev] What are the active grids? Message-ID: <200702270205.24184.dale@daleglass.net> I've heard something about a grid being available for client testing, which I think might be Uma (based on an earlier message), but I never managed to log in there. First it wasn't available, now it says my version is too old (with the latest firstlook version!) Could somebody provide a full list of grids and what they're for? The list on the wiki seems incomplete. -------------- 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/20070227/434041b0/attachment.pgp From josh at secondlife.com Mon Feb 26 17:29:21 2007 From: josh at secondlife.com (Joshua Bell) Date: Mon Feb 26 17:29:26 2007 Subject: [sldev] What are the active grids? In-Reply-To: <200702270205.24184.dale@daleglass.net> References: <200702270205.24184.dale@daleglass.net> Message-ID: <45E38971.3090104@secondlife.com> Dale Glass wrote: > I've heard something about a grid being available for client testing, which I > think might be Uma (based on an earlier message), but I never managed to log > in there. First it wasn't available, now it says my version is too old (with > the latest firstlook version!) > > Could somebody provide a full list of grids and what they're for? The list on > the wiki seems incomplete. > Hey there - one of the hats I wear is grid management, so I guess I should jump in and answer. We have a bunch of internal development grids, but here are the ones typically open for non-Linden access: Agni - the live, main, real grid - runs the released code (by definition) - frequently updated with rolling updates (which may or may not be visible to residents) - often unavailable on Wednesday mornings (PST) for maintenance or updates - thousands of hosts/regions - try not to grief the grid. :) Aditi - the beta test grid - intended for getting public feedback on upcoming releases - we may change what grid is used for a public beta test (it used to be siva, for example) - often (but not always) runs server code which is incompatible with what's released - as code passes internal QA and merges into our release candidate branch we update this grid - usually public, but we may close the doors if no compatible public viewers are available. - may be down for updates at any time, although we try to keep the grid up and available when the main grid is down - tens of hosts/regions Uma - open source grid - intended for Open Source developers testing potentially dangerous client changes - we haven't gotten into a habit of updating this frequently to track the Open Source code drops, but we need to - fortunately we have added Lindens in this area to help, so this should track the release code more closely - only a couple of hosts/handful of regions Sorry about the state of Uma - we'll be updating it shortly after a quick consult with RobLa about what versions we want there. Please let me know if you need any more details. Joshua From soft at softnoel.org Mon Feb 26 20:22:25 2007 From: soft at softnoel.org (Soft Noel) Date: Mon Feb 26 20:22:27 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> Message-ID: <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> On Mon, February 26, 2007 4:59 pm, Tim Shephard wrote: > Can you post a couple of sample hooks? > > Are you doing it via a proxy llFloater class? I'm not ready to drop this code yet. It's still in a gross hack state while I'm proving out an approach for myself. I'm also hoping someone will try out the class inheritance model (I think that's what you mean by the proxy llFloater class), and if I put the hook stuff out there that's less likely. Right now, the hooks are all into viewer-side code that's a regular client to the UI classes, creating subscribers as needed. I'm experimenting with seeing how much I can make the client-side plugin code self-contained, as a huge third-party patch set spidering into every last system will make LL balk. > Great energy. Let me know your secret on how you can afford to spend the > time. Evenings at home with a Costco pallet of Diet Mountain Dew: It actually ends up being cheaper than going out or SL clothes-shopping. :) From tshephard at gmail.com Mon Feb 26 21:50:54 2007 From: tshephard at gmail.com (Tim Shephard) Date: Mon Feb 26 21:50:57 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> Message-ID: <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> Ahh, not so much looking for a full patch.. just perhaps an example of how you're doing this and what your thoughts are. The key, I think, is to make sure that the plugin developer has to do as little work as possible and that we add minimal technical risk to the client in use today. APIs are successful when they're clear, well documented, simple to use, and don't add to general system complexity. When I mentioned the floater proxy, I didn't mean inheritance across DLLs. Inheritance across DLLs would be the exactly the same as what you find in the wiki or in Dale's code. What I'm thinking is something along these lines (rough example): Basically we extend llFloater with a class called LLFloaterPluginProxy. It would roughly be implemented as follows: LLFloaterPluginProxy::LLFloaterPluginProxy() : LLFloater("floater_plugin") gUICtrlFactory->buildFloater(this, pluginTable->getXMLSpec()); listOfCommitCallBacks = pluginTable->getListOfCommitCallBacks(); loop through listOfEvents childSetCommitCallback(list.name, list.function, this); .. do for setAction, etc } void LLFloaterPluginProxy::show(void*) { sInstance = new LLFloaterProxy(); sInstance->open(); pluginTable->plugInProxy(); } LLFloaterPluginProxy::~LLFloaterPluginProxy() { pluginTable->destruct(); sInstance=NULL; } Basically there would be an instance of LLFloaterPluginProxy for every plugin floater created. The advantage of this approach is we don't touch core code, which I personally think is critical. Not just for getting merged, but also to ensure we minimize risk to the client that are not using plugins. Let me know what you think, Soft. Cheers, Tim. On 2/26/07, Soft Noel wrote: > On Mon, February 26, 2007 4:59 pm, Tim Shephard wrote: > > Can you post a couple of sample hooks? > > > > Are you doing it via a proxy llFloater class? > > I'm not ready to drop this code yet. It's still in a gross hack state > while I'm proving out an approach for myself. I'm also hoping someone will > try out the class inheritance model (I think that's what you mean by the > proxy llFloater class), and if I put the hook stuff out there that's less > likely. > > Right now, the hooks are all into viewer-side code that's a regular client > to the UI classes, creating subscribers as needed. I'm experimenting with > seeing how much I can make the client-side plugin code self-contained, as > a huge third-party patch set spidering into every last system will make LL > balk. > > > > Great energy. Let me know your secret on how you can afford to spend the > > time. > > Evenings at home with a Costco pallet of Diet Mountain Dew: It actually > ends up being cheaper than going out or SL clothes-shopping. :) > > > From soft at softnoel.org Mon Feb 26 23:02:50 2007 From: soft at softnoel.org (Soft Noel) Date: Mon Feb 26 23:02:55 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> Message-ID: <45668.64.81.228.9.1172559770.squirrel@webmail.softnoel.org> On Mon, February 26, 2007 9:50 pm, Tim Shephard wrote: > Ahh, not so much looking for a full patch.. just perhaps an example of > how you're doing this and what your thoughts are. Gotcha! Actually, Bushing has a very nice, succinct example of hooking IMs: http://wiki.secondlife.com/wiki/Hook_example_code http://wiki.secondlife.com/wiki/Hooking_sending_IMs Mine's more complex because I'm building it around a system that supports interface versioning, similar to my LLJack/LLBundle work. > The key, I think, is to make sure that the plugin developer has to do > as little work as possible and that we add minimal technical risk to > the client in use today. Fully agreed. The quickest way we get the friendly API is to (a) find something similar we can copy, or (b) run ahead with a couple simple plugins, knowing we'll have to iterate over the implementation a few times and throw some work away. I'm still looking for (a) while I (b). In the end, the user friendliness aspect will probably happen more on the plugin SDK library side, while the design of the client<->plugin interface places primary focus on remaining unobtrusive to the client code. This means, for a very basic example, that the sys->PrintLog() function you see in the HelloWorldPlugin example would probably be replaced by a complement of functions doing formatted printing, etc, which all back end to the one call. This also lets us more rapidly evolve the plugin development environment as we can iterate on releases of the plugin SDK independent of the viewer. > What I'm thinking is something along these lines (rough example): > > Basically we extend llFloater with a class called > LLFloaterPluginProxy. It would roughly be implemented as follows: > > LLFloaterPluginProxy::LLFloaterPluginProxy() > : LLFloater("floater_plugin") ... > > Basically there would be an instance of LLFloaterPluginProxy for every > plugin floater created. I initially rejected the derivation idea, as a class derived from the floater class meant that this class would change any time the floater did. What I didn't think about was that this derived class would be used by the plugin and remain 100% viewer-side, it wouldn't be -part- of the plugin interface (now "jack" in my code) itself. I've got more thinking to do. The rest of your example is inspiring. I'd hoped to sleep tonight, but it's clear that I'm going to comb over the UI code so I can think about a layer implementation instead of just facing up to it as a client. :( One tempting approach is to more or less replicate the LLFloater interface inside the plugin SDK, with the floater proxy as a bridge between the real and plugin implementations, boiling things down to the simplest representation of events and data changes that can be expressed through LLJack versioned interfaces. > The advantage of this approach is we don't touch core code, which I > personally think is critical. Yes! > Not just for getting merged, but also > to ensure we minimize risk to the client that are not using plugins. Yes. > Let me know what you think, Soft. Mulling this over a bit more, but I may run with it. :) From soft at softnoel.org Mon Feb 26 23:12:17 2007 From: soft at softnoel.org (Soft Noel) Date: Mon Feb 26 23:12:31 2007 Subject: [sldev] Go, AMD! Message-ID: <45784.64.81.228.9.1172560337.squirrel@webmail.softnoel.org> I indicated that I don't have a Windows machine for the DLL plugin work, and the viewer wasn't running on my Mac under Parallels. Dually Goalpost of AMD has stepped up and offered to get me VPN access to a fast Windows machine at AMD for my work. Yay! Windows plugin support should be at parity with the Mac work in my next drop, and going forward. Thank AMD's Open Source crew when it happens. :) From tshephard at gmail.com Mon Feb 26 23:26:52 2007 From: tshephard at gmail.com (Tim Shephard) Date: Mon Feb 26 23:27:35 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <45668.64.81.228.9.1172559770.squirrel@webmail.softnoel.org> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> <45668.64.81.228.9.1172559770.squirrel@webmail.softnoel.org> Message-ID: <3b19a500702262326j16236edfy29d98edcaba48a5f@mail.gmail.com> > > Basically there would be an instance of LLFloaterPluginProxy for every > > plugin floater created. > > I initially rejected the derivation idea, as a class derived from the > floater class meant that this class would change any time the floater did. OK, that concern makes sense. However, looking through the code, llFloater seems likely to be very resistant to change. If it does change, it would likely impact a very significant amount of code and therefore would only occur when absolutely necessary. Perhaps a linden can comment.. > What I didn't think about was that this derived class would be used by the > plugin and remain 100% viewer-side, it wouldn't be -part- of the plugin > interface (now "jack" in my code) itself. By this, I understand that you mean that the derived class would sit in the core code base and changes to it wouldn't necessarily impact the plugin api / function pointer table which is the real contract. I agree. This is important as that contract should be ideally near-perfect and very resistant to change as it would be the function pointer table loaded from the DLL that the plugin developer exposes and relies on. > One tempting approach is to more or less replicate the LLFloater interface > inside the plugin SDK, with the floater proxy as a bridge between the real > and plugin implementations, boiling things down to the simplest > representation of events and data changes that can be expressed through > LLJack versioned interfaces. I think you're saying here that plugin developers would create a plugin-side class and would export that class or at least its individual functions to the core code base. That seems like an ideal approach if you can expose the functions in the plugin to the core code base in a safe way. However, my understanding is the best way to expose across dlls is with C extern stubs rather than classes, even if no inheritance goes on. C++ has a lot of mysterious things happening which I'm not sure translate very well on a cross platform basis. Not being a cross platform expert, I certainly can not comment confidently. It would be also interesting to see a proven example with a history of working that uses classes across DLLs. However, that being said, it would be nice if someone had the cross platform expertise to proof of concept that if they had the sufficient motivation to do so. It might be an opportunity to make history in the world of plugin architectures... :) I included a win32 proof of concept for exposing classes across DLLs in a recent attachment on a previous email, so they could start with that. Thanks for the comments Soft. You're really moving all of this forward very rapidly. I hope your contribution is well recognized :) From soft at softnoel.org Tue Feb 27 00:28:08 2007 From: soft at softnoel.org (Soft Noel) Date: Tue Feb 27 00:28:10 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <3b19a500702262326j16236edfy29d98edcaba48a5f@mail.gmail.com> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> <45668.64.81.228.9.1172559770.squirrel@webmail.softnoel.org> <3b19a500702262326j16236edfy29d98edcaba48a5f@mail.gmail.com> Message-ID: <46559.64.81.228.9.1172564888.squirrel@webmail.softnoel.org> On Mon, February 26, 2007 11:26 pm, Tim Shephard wrote: > I agree. This is important as that contract should be ideally > near-perfect and very resistant to change as it would be the function > pointer table loaded from the DLL that the plugin developer exposes > and relies on. Sure, this is the reasoning for the LLJack versioning system and for breaking up the bridge API into multiple interface types. This lets us invalidate only select portions of the API. I don't want to rule out interfaces handing over a raw mesh and letting someone go all medieval on it for a SIGGraph paper. But I want to be sure that kind of flexibility doesn't screw things up for the plugin that only requests a UI interface and a simple object positioning and texturing interface. The deep graphics API can last just one client version, while the others can be maintained over a dozen releases. >> One tempting approach is to more or less replicate the LLFloater >> interface >> inside the plugin SDK, with the floater proxy as a bridge between the >> real >> and plugin implementations, boiling things down to the simplest >> representation of events and data changes that can be expressed through >> LLJack versioned interfaces. > > I think you're saying here that plugin developers would create a > plugin-side class and would export that class or at least its > individual functions to the core code base. I'm figuring we do the LLFloater reimplementation work ourselves, not the plugin developer. I see as much work to be done on the plugin SDK library side as on the viewer side. The things that make an interface clean and safe don't always make them pretty. > That seems like an ideal approach if you can expose the functions in > the plugin to the core code base in a safe way. > > However, my understanding is the best way to expose across dlls is > with C extern stubs rather than classes, even if no inheritance goes > on. > > C++ has a lot of mysterious things happening which I'm not sure > translate very well on a cross platform basis. Not being a cross > platform expert, I certainly can not comment confidently. You have three main concerns when exposing C++ classes in a shared library. The first is that virtual function table implementations are not specified by the language specification, and are compiler-dependent. The second is that you can't extern "C" a class method to avoid name mangling which can yield strange symbols and give binding problems. The third is that objects with inline or statically called methods attach an implementation contract. For example if we pass an LLString class, the plugin has to carry exactly the same LLString implementation or it can stomp on data when its copy of the statically bound functions think the string pointer was the second item in the class, rather than the third. In practice, Visual Studio is the law of the land under Windows and MS won't change the C++ ABI for legacy reasons. If we decide we want to support Borland Builder or other compilers, I can research whether they've made their ABI match MS'. Linux (g++) migrated to the common Itanium ABI in 2001, and Apple have committed to backward ABI compatibility as well. That takes care of the first two points. Unfortunately, the third pitfall is with us even if we use named C-style binding, so long as we pass even a single class as a parameter. :/ It's something we just have to avoid doing unless passing std library classes (ie std::string), as if those ever change in an incompatible way, we're going to be rebuilding the client and plugin SDK anyway. We *do* get two big things by expressing the interface via C++ classes. The first is that the names carry mangling. This lets us know immediately if we screw up and make a change to the number of parameters a function takes, try building with signed ints on one side and unsigned on the other, or add a return value to a method. The second is that it also gives us link errors instead of run-time errors if we mess up a function name between the two sides. > However, that being said, it would be nice if someone had the cross > platform expertise to proof of concept that if they had the sufficient > motivation to do so. It might be an opportunity to make history in > the world of plugin architectures... :) > > I included a win32 proof of concept for exposing classes across DLLs > in a recent attachment on a previous email, so they could start with > that. The LLJacks in the LLJackBundle are already C++ classes exposed across. It's working via dylibs right now, but as soon as AMD gets me going with the Windows VPN, I'll show it working there as well. Or I'll suffer humiliating defeat after being so cock-sure about it! From tshephard at gmail.com Tue Feb 27 01:19:35 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 01:19:38 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <46559.64.81.228.9.1172564888.squirrel@webmail.softnoel.org> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> <45668.64.81.228.9.1172559770.squirrel@webmail.softnoel.org> <3b19a500702262326j16236edfy29d98edcaba48a5f@mail.gmail.com> <46559.64.81.228.9.1172564888.squirrel@webmail.softnoel.org> Message-ID: <3b19a500702270119o3e1ad6e1r4802b6a3e229220f@mail.gmail.com> > I'm figuring we do the LLFloater reimplementation work ourselves, not the > plugin developer. I see as much work to be done on the plugin SDK library > side as on the viewer side. The things that make an interface clean and > safe don't always make them pretty. Ahh, sure, so extern C stubs exported across the dlls and then the llFloaterPluginSideProxy would be called via the extern C stubs? That's a pretty interesting and perhaps novel idea. Have you seen this sort of thing done before? I can't see why it wouldn't work other than that some people might not want to implement their plug in C++. > > > > That seems like an ideal approach if you can expose the functions in > > the plugin to the core code base in a safe way. > > > > However, my understanding is the best way to expose across dlls is > > with C extern stubs rather than classes, even if no inheritance goes > > on. > > > > C++ has a lot of mysterious things happening which I'm not sure > > translate very well on a cross platform basis. Not being a cross > > platform expert, I certainly can not comment confidently. > > You have three main concerns when exposing C++ classes in a shared > library. The first is that virtual function table implementations are not > specified by the language specification, and are compiler-dependent. The > second is that you can't extern "C" a class method to avoid name mangling > which can yield strange symbols and give binding problems. The third is > that objects with inline or statically called methods attach an > implementation contract. For example if we pass an LLString class, the > plugin has to carry exactly the same LLString implementation or it can > stomp on data when its copy of the statically bound functions think the > string pointer was the second item in the class, rather than the third. > > In practice, Visual Studio is the law of the land under Windows and MS > won't change the C++ ABI for legacy reasons. If we decide we want to > support Borland Builder or other compilers, I can research whether they've > made their ABI match MS'. Linux (g++) migrated to the common Itanium ABI > in 2001, and Apple have committed to backward ABI compatibility as well. > That takes care of the first two points. > > Unfortunately, the third pitfall is with us even if we use named C-style > binding, so long as we pass even a single class as a parameter. :/ It's > something we just have to avoid doing unless passing std library classes > (ie std::string), as if those ever change in an incompatible way, we're > going to be rebuilding the client and plugin SDK anyway. > > We *do* get two big things by expressing the interface via C++ classes. > The first is that the names carry mangling. This lets us know immediately > if we screw up and make a change to the number of parameters a function > takes, try building with signed ints on one side and unsigned on the > other, or add a return value to a method. The second is that it also gives > us link errors instead of run-time errors if we mess up a function name > between the two sides. > Yes, your summary is great. Another problem is heap management, which I don't think is done the same way over all three platforms either. For all those reasons, and probably more, exposing classes over DLLs seems a tad risky. > > > However, that being said, it would be nice if someone had the cross > > platform expertise to proof of concept that if they had the sufficient > > motivation to do so. It might be an opportunity to make history in > > the world of plugin architectures... :) > > > > I included a win32 proof of concept for exposing classes across DLLs > > in a recent attachment on a previous email, so they could start with > > that. > > The LLJacks in the LLJackBundle are already C++ classes exposed across. > It's working via dylibs right now, but as soon as AMD gets me going with > the Windows VPN, I'll show it working there as well. Or I'll suffer > humiliating defeat after being so cock-sure about it! > Hmmm.. To be honest, I missed that. I probably wouldn't have gone in that direction because it seems a bit novel, but I admire your courage! From tshephard at gmail.com Tue Feb 27 02:29:07 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 02:29:10 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <46559.64.81.228.9.1172564888.squirrel@webmail.softnoel.org> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> <45668.64.81.228.9.1172559770.squirrel@webmail.softnoel.org> <3b19a500702262326j16236edfy29d98edcaba48a5f@mail.gmail.com> <46559.64.81.228.9.1172564888.squirrel@webmail.softnoel.org> Message-ID: <3b19a500702270229q1414608fx53e9ffeb91a69a4a@mail.gmail.com> > The LLJacks in the LLJackBundle are already C++ classes exposed across. > It's working via dylibs right now, but as soon as AMD gets me going with > the Windows VPN, I'll show it working there as well. Or I'll suffer > humiliating defeat after being so cock-sure about it! Hmmm, one thing to think about: I believe LL builds with Visual Studio 2003, and I'm not sure a lot of us use that platform anymore. My understanding is that exposing classes across DLLs should generally be done with the same compiler. Something to ponder. From secret.argent at gmail.com Tue Feb 27 06:20:00 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 06:20:00 2007 Subject: [sldev] Re: SLDev Digest, Vol 2, Issue 44 In-Reply-To: <20070224033723.EE2B341AF8C@stupor.lindenlab.com> References: <20070224033723.EE2B341AF8C@stupor.lindenlab.com> Message-ID: > Step ONE is write code (like Dale). Then you can worry about isolating > it into a plugin once you know what API you need, then you can > generate > bindings for Mono and Javascript and Lua and Python and Java and > Fortran > and whatever the hell other crack you feel like smoking. That's how you end up with really really bad APIs. That's how you end up with Winsock, where a file and a BSD-style socket on Windows use different calls to read and write. That's how you end up with Multics, where you had to use a DIFFERENT API to open a file depending on whether it was 256 kilobytes or more, because the original API assumed you could map the whole file into memory. And that's why (to get back to 'The Art of UNIX Programming') UNIX *isn't* just a baby version of Multics. The thing that's REALLY stupid is that Linden Labs has an encapsulation API already, as mentioned in the reply to my message about how to encapsulate parameters to plugins, and nobody's talking about how to use that. From tshephard at gmail.com Tue Feb 27 06:31:34 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 06:31:37 2007 Subject: [sldev] Re: SLDev Digest, Vol 2, Issue 44 In-Reply-To: References: <20070224033723.EE2B341AF8C@stupor.lindenlab.com> Message-ID: <3b19a500702270631x726a040fwf25dac5097c09a3e@mail.gmail.com> > > The thing that's REALLY stupid is that Linden Labs has an > encapsulation API already, as mentioned in the reply to my message > about how to encapsulate parameters to plugins, and nobody's talking > about how to use that. > Are you referring to Ryan's email regarding the message subsystem? How would you use it to instantiate widgets and react to widget events, like the ones in Dales plugin for example? From soft at softnoel.org Tue Feb 27 06:35:14 2007 From: soft at softnoel.org (Soft Noel) Date: Tue Feb 27 06:35:16 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <3b19a500702270119o3e1ad6e1r4802b6a3e229220f@mail.gmail.com> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> <45668.64.81.228.9.1172559770.squirrel@webmail.softnoel.org> <3b19a500702262326j16236edfy29d98edcaba48a5f@mail.gmail.com> <46559.64.81.228.9.1172564888.squirrel@webmail.softnoel.org> <3b19a500702270119o3e1ad6e1r4802b6a3e229220f@mail.gmail.com> Message-ID: <48028.64.81.228.9.1172586914.squirrel@webmail.softnoel.org> On Tue, February 27, 2007 1:19 am, Tim Shephard wrote: >> >> You have three main concerns when exposing C++ classes in a shared [...] > > Yes, your summary is great. Another problem is heap management, which > I don't think is done the same way over all three platforms either. > For all those reasons, and probably more, exposing classes over DLLs > seems a tad risky. Heap management is a problem whether you use C++ or C, if you mean the potential problem of allocating on one side and freeing on the other, or holding dangling pointers after a library unloads and its heap(s) are destroyed. We should try to follow the LL coding standard's suggestion of keeping handles rather than pointers as much as possible to avoid this. Or did you mean something else? >> > I included a win32 proof of concept for exposing classes across DLLs >> > in a recent attachment on a previous email, so they could start with >> > that. >> >> The LLJacks in the LLJackBundle are already C++ classes exposed across. >> It's working via dylibs right now, but as soon as AMD gets me going with >> the Windows VPN, I'll show it working there as well. Or I'll suffer >> humiliating defeat after being so cock-sure about it! > > Hmmm.. To be honest, I missed that. I probably wouldn't have gone in > that direction because it seems a bit novel, but I admire your > courage! Going from that to a COM-style struct of pointers would be little work, just a little bit annoying. The calling convention doesn't change, only the class declaration and function prototypes. Basically: class LLJackFoo : public LLJack { void FooFunc(); U32 *BarFunc(); }; void LLJackFoo::FooFunc() { } becomes: struct LLJackFoo : public LLJack { LLJackFoo(); void (*FooFunc)(); U32 *(*BarFunc)(); } void LLJackFoo_FooFunc() { } LLJackFoo::LLJackFoo() { FooFunc = LLJackFoo_FooFunc; BarFunc = LLJackFoo_BarFunc; } You'd still call both with: void SomeFunc( LLJackFoo *jf ) { jf->FooFunc(); } Of course, they also lose the "this" pointer, but we're not storing data in the LLJacks. From secret.argent at gmail.com Tue Feb 27 06:41:32 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 06:41:32 2007 Subject: [sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI In-Reply-To: <20070224102731.985CC41AFDE@stupor.lindenlab.com> References: <20070224102731.985CC41AFDE@stupor.lindenlab.com> Message-ID: <75101B77-731D-4E6E-9774-4929E398A468@gmail.com> > The idea behind this one is that people could extend llFloater (and > similar classes) in their DLL and then register that class with the > main UI Factory in SL. The absolute deal-breaking potential gotcha with this one is, as you say, portability. > The other solution is NPAPI, here is a link: There are other similar APIs, this one has the advantage that it's probably already in the client through the Gecko engine. It has the disadvantage that there's a big old security hole waiting for us: if you register a plugin with this it could potentially be invoked without your knowledge by HTML provided by an attacker (say, in someone's profile) with parameters supplied by the attacker, rather than being invoked by the user through their plugin preferences pane. If it's used, utmost care is required. There's two common approaches to a plugin API. They both start the same way... the plugin has some well-defined function name that's used to initialize it. Where they differ is how you register callbacks. With some, the callbacks are implicit in the names of functions. If your plugin has a PLUGIN_foo function, then you're providing the foo callback. With others, you explicitly register every callback in the initialization routine. NSAPI seems to be the former. I prefer the latter, because it's more stable over the long term, and more portable. The names you use to register the callback are independent of the language you write the plugin in, and they're not subject to the restrictions of third party code like compilers, librarians, and other parts of toolchains. From secret.argent at gmail.com Tue Feb 27 07:09:47 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 07:09:50 2007 Subject: [sldev] Re: Plugin work so far. In-Reply-To: <20070224200006.DA06541B016@stupor.lindenlab.com> References: <20070224200006.DA06541B016@stupor.lindenlab.com> Message-ID: <07FF669B-54AE-4801-B53A-A0AB43E99344@gmail.com> These comments seem related, so I'll comment on them together. > Unfortunately, everything keeps twisting back into a requirement to > call code in the main code base. This might be doable for simple > classes that are stateless, however I am concerned that at some point > it starts getting more complicated, less stable, less cross platform > and more crash prone. > > If we do export functions to be used in the Plugin DLLs, we may want > to export C methods only rather than C++ classes. This would also make gluing the plugin code to other languages (especially scripting languages) infinitely easier. Continuing on to Soft Noel's comment, then. I think that plugin initialization and callback should use as language-independant and API as possible, and ironically these days that lowest common denominator happens to be a programming language called C. No classes, just "old fashioned structs" and pointers to old fashioned functions. I agree that explicitly registering hooks is definitely the way to go, but the hooks really need to use some kind of formal encapsulation of parameters. I suggested one, but it seems that Linden Labs has one already so we should use it. From tshephard at gmail.com Tue Feb 27 07:11:10 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 07:11:13 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <48028.64.81.228.9.1172586914.squirrel@webmail.softnoel.org> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> <45668.64.81.228.9.1172559770.squirrel@webmail.softnoel.org> <3b19a500702262326j16236edfy29d98edcaba48a5f@mail.gmail.com> <46559.64.81.228.9.1172564888.squirrel@webmail.softnoel.org> <3b19a500702270119o3e1ad6e1r4802b6a3e229220f@mail.gmail.com> <48028.64.81.228.9.1172586914.squirrel@webmail.softnoel.org> Message-ID: <3b19a500702270711rcae9ab0h7625bef9f23af944@mail.gmail.com> > struct LLJackFoo : public LLJack > { > LLJackFoo(); > void (*FooFunc)(); > U32 *(*BarFunc)(); > } > Not sure I understand the ": public LLJack". Is that for documentation purposes only? From secret.argent at gmail.com Tue Feb 27 07:21:19 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 07:21:19 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <20070225011052.546DD41AFCA@stupor.lindenlab.com> References: <20070225011052.546DD41AFCA@stupor.lindenlab.com> Message-ID: <5728C888-B1B6-41C3-97C2-F51C1FE7BC66@gmail.com> Dale Glass's hack is really the only way to do it without LL support. Dale: ever thought about taking your code and combining it with side- chat on a well known port to let people start writing scripts that talk to LSL directly, now, without waiting for an internal plugin architecture? EG, from tcl: set sock [socket localhost 1337] puts $sock "MyName,1.0,1331" Now whatever I write to "sock" goes to chat on channel 1331, and when any program sends "$VwrComm$1.0$Myname$Data" then "Data" gets written back to me. For security purposes, how about this? $VwrComm$CHANNEL$VERSION$COMPONENT$data" Where CHANNEL has to match the channel the original message was sent on. This would at least allow you to use the "secret channel number" technique to prevent scripted objects around you impersonating responses. It's not the greatest, but it's what SL already depends on in many many places so it's as good as what we already use. From soft at softnoel.org Tue Feb 27 07:28:42 2007 From: soft at softnoel.org (Soft Noel) Date: Tue Feb 27 07:28:44 2007 Subject: [sldev] Re: Plugin work so far. In-Reply-To: <07FF669B-54AE-4801-B53A-A0AB43E99344@gmail.com> References: <20070224200006.DA06541B016@stupor.lindenlab.com> <07FF669B-54AE-4801-B53A-A0AB43E99344@gmail.com> Message-ID: <48590.64.81.228.9.1172590122.squirrel@webmail.softnoel.org> On Tue, February 27, 2007 7:09 am, Argent Stonecutter wrote: >> >> If we do export functions to be used in the Plugin DLLs, we may want >> to export C methods only rather than C++ classes. > > This would also make gluing the plugin code to other languages > (especially scripting languages) infinitely easier. > > Continuing on to Soft Noel's comment, then. I think that plugin > initialization and callback should use as language-independant and > API as possible, and ironically these days that lowest common > denominator happens to be a programming language called C. No > classes, just "old fashioned structs" and pointers to old fashioned > functions. I'd envisioned scripting systems and other plugins being built against a library-side plugin SDK, not directly making/receiving calls. As I said in my message, it's not a deal breaker -- transitioning between the two isn't much more than a search and replace operation. > I agree that explicitly registering hooks is definitely the way to > go, but the hooks really need to use some kind of formal > encapsulation of parameters. I suggested one, but it seems that > Linden Labs has one already so we should use it. Any chance you can quote the message you referred to for this? Scanning back through the list archives, I think I'm missing something. From secret.argent at gmail.com Tue Feb 27 07:32:34 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 07:32:34 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <20070226085212.8818941B02D@stupor.lindenlab.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> Message-ID: <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> > It would not be practical for a retail product to ever rely on a > "tag 0" > feature, since such a feature, by definition, is of limited > deployment, > and may in fact even crash clients with a different tag 0 feature > enabled. I strongly suggest that the tags be text, even for test features, rather than numbers. They could be a four character code encoded in a 32-bit integer, if you like, or better two integers encoding an Apple/ Palm style "owner" and "type" code. At the very least you need to have some way of separating different developers, otherwise how would you EVER test something in public, or test two features in the same client? From soft at softnoel.org Tue Feb 27 07:37:10 2007 From: soft at softnoel.org (Soft Noel) Date: Tue Feb 27 07:37:12 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <3b19a500702270711rcae9ab0h7625bef9f23af944@mail.gmail.com> References: <34620.64.81.228.9.1172512770.squirrel@webmail.softnoel.org> <3b19a500702261659mb35a055s34571d267f1defbc@mail.gmail.com> <41192.64.81.228.9.1172550145.squirrel@webmail.softnoel.org> <3b19a500702262150q27411412pd7760adafd198958@mail.gmail.com> <45668.64.81.228.9.1172559770.squirrel@webmail.softnoel.org> <3b19a500702262326j16236edfy29d98edcaba48a5f@mail.gmail.com> <46559.64.81.228.9.1172564888.squirrel@webmail.softnoel.org> <3b19a500702270119o3e1ad6e1r4802b6a3e229220f@mail.gmail.com> <48028.64.81.228.9.1172586914.squirrel@webmail.softnoel.org> <3b19a500702270711rcae9ab0h7625bef9f23af944@mail.gmail.com> Message-ID: <48634.64.81.228.9.1172590630.squirrel@webmail.softnoel.org> On Tue, February 27, 2007 7:11 am, Tim Shephard wrote: >> struct LLJackFoo : public LLJack >> { >> LLJackFoo(); >> void (*FooFunc)(); >> U32 *(*BarFunc)(); >> } >> > > Not sure I understand the ": public LLJack". Is that for > documentation purposes only? In the current implementation, the LLJack base carries a function for returning the version of the interface, which is common to all derived interface types. Similar to the reworked LLJackFoo, LLJack would be reworked to turn that into a stored pointer in a struct rather than a virtual function pointer. From tshephard at gmail.com Tue Feb 27 07:56:44 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 07:56:47 2007 Subject: [sldev] Re: Plugin work so far. In-Reply-To: <48590.64.81.228.9.1172590122.squirrel@webmail.softnoel.org> References: <20070224200006.DA06541B016@stupor.lindenlab.com> <07FF669B-54AE-4801-B53A-A0AB43E99344@gmail.com> <48590.64.81.228.9.1172590122.squirrel@webmail.softnoel.org> Message-ID: <3b19a500702270756j740ebec2kc4329d5b101e24b6@mail.gmail.com> > Any chance you can quote the message you referred to for this? Scanning > back through the list archives, I think I'm missing something. Pretty sure he's looking at this https://lists.secondlife.com/pipermail/sldev/2007-February/000513.html and https://lists.secondlife.com/pipermail/sldev/2007-February/000541.html It's an interesting idea. Obviously makes sense in message parameter passing, though I wonder if there is a simpler way to handle the UI stuff.. From monkowsk at watson.ibm.com Tue Feb 27 08:09:58 2007 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue Feb 27 08:10:13 2007 Subject: [sldev] Lip-sync In-Reply-To: <45E33682.3030405@watson.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <200702222156.07839.dale@daleglass.net> <6E0A6592-256B-41D2-92A7-49E20D86D5CD@secondlife.com> <45DE1868.3080002@watson.ibm.com> <45DFBE98.9080501@lifeart.net.au> <45E33682.3030405@watson.ibm.com> Message-ID: <45E457D6.9030201@watson.ibm.com> Mike Monkowski wrote: > I've just started looking at the audio parts of SecondLife, but I see > that it uses FMOD 3.7.4 for streaming audio, although I don't imagine > that includes voice. It's not clear what's going on there. Will it be > converted to FMOD Ex 4? (see http://www.fmod.org/ ) Will it rely on > ViVox for voice? (see http://www.vivox.com/millionmins.html ) Well, I think I got my answer in a C|NET article today: http://news.com.com/Integrated+voice+coming+to+Second+Life/2100-1043_3-6162410.html?tag=nefd.top Some excerpts: > Next week, Second Life publisher Linden Lab plans to unveil a small beta trial in which, > for the first time, people will have access to integrated voice chat. > > The company plans to launch the beta for all users by the end of March, it said. > "We've been working on this for quite a while," said Joe Miller, Linden Lab's vice > president of platform and technology development. "I think there was some skepticism > that we'd be putting something out this soon. It's been in the works for 8 to 10 months > in earnest. Voice has been viewed as a key missing piece to the overall solution." > The technology is being provided by two Linden Lab partners: Vivox and DiamondWare. So now my question is: I've been looking at the SL releases. Is this code in the First Look source release now? From tshephard at gmail.com Tue Feb 27 08:48:30 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 08:48:33 2007 Subject: [sldev] Two potential plugin architectures: Inheritance across DLLs and NPAPI In-Reply-To: <75101B77-731D-4E6E-9774-4929E398A468@gmail.com> References: <20070224102731.985CC41AFDE@stupor.lindenlab.com> <75101B77-731D-4E6E-9774-4929E398A468@gmail.com> Message-ID: <3b19a500702270848g66774a3ake9c01c619191353e@mail.gmail.com> > With others, you explicitly register every callback in the > initialization routine. > > NSAPI seems to be the former. > > I prefer the latter, because it's more stable over the long term, and > more portable. I think the newer mozilla plugin has some of that. Regardless, I agree with what you're saying, especially as we may want to register multiple callbacks for the same thing (eg, more than one floater type..). The names you use to register the callback are > independent of the language you write the plugin in, and they're not > subject to the restrictions of third party code like compilers, > librarians, and other parts of toolchains. Well... I think C is the intersection as you've mentioned. But I agree where you're going with that. From gigstaggart at gmail.com Tue Feb 27 09:06:29 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 27 09:06:28 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> Message-ID: <45E46515.4060608@gmail.com> Argent Stonecutter wrote: >> It would not be practical for a retail product to ever rely on a "tag 0" >> feature, since such a feature, by definition, is of limited deployment, >> and may in fact even crash clients with a different tag 0 feature >> enabled. > > I strongly suggest that the tags be text, even for test features, rather > than numbers. They could be a four character code encoded in a 32-bit > integer, if you like, or better two integers encoding an Apple/Palm > style "owner" and "type" code. > > At the very least you need to have some way of separating different > developers, otherwise how would you EVER test something in public, or > test two features in the same client? The tags are text. Tag 0 is a string 1024 bytes long. If developers wanted to coordinate to test two features at once, they can come up with some kind of delimiter inside the field. This is hard partly by design, to discourage retail products based off beta features that are not accepted by LL. If Linden Lab didn't care about that as much and wanted it to be more extensible, then you could just expose a small range of tags like 0-5 for development purposes, and add a tag number parameter to the LSL function. -Jason From richard at lindenlab.com Tue Feb 27 09:58:23 2007 From: richard at lindenlab.com (Richard Nelson) Date: Tue Feb 27 09:58:28 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <45E46B21.5090700@lindenlab.com> References: <45E46B21.5090700@lindenlab.com> Message-ID: Just jumping in here to comment on LLFloater stability. In general, we can't guarantee that our UI class interfaces will remain stable. For example, we recently changed LLFloaters and LLPanels to implement LLUICtrl in order to sanitize our keyboard focus model and let them participate fully in focus management (LLView's can't delegate keyboard focus, they can only contain LLUICtrls, or widgets). We've also made many changes in the move over to XML-driven UI. These changes are not complete, and we will continue to tease out architectural abstractions and refactor our UI code based on use cases as they arise. That said, most changes can be considered extensions to existing functionality, implemented in the base class, with no extra burden on derived classes. There are still large architectural decisions to be made, though. Richard On Tue, 27 Feb 2007 09:32:17 -0800, Rob Lanphier wrote: > >> > Basically there would be an instance of LLFloaterPluginProxy for every >> > plugin floater created. >> >> I initially rejected the derivation idea, as a class derived from the >> floater class meant that this class would change any time the floater did. > > OK, that concern makes sense. However, looking through the code, > llFloater seems likely to be very resistant to change. If it does > change, it would likely impact a very significant amount of code and > therefore would only occur when absolutely necessary. > > Perhaps a linden can comment.. > From secret.argent at gmail.com Tue Feb 27 10:02:29 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 10:02:28 2007 Subject: [sldev] Plugin hooks In-Reply-To: <3b19a500702270631x726a040fwf25dac5097c09a3e@mail.gmail.com> References: <20070224033723.EE2B341AF8C@stupor.lindenlab.com> <3b19a500702270631x726a040fwf25dac5097c09a3e@mail.gmail.com> Message-ID: On Feb 27, 2007, at 8:31 AM, Tim Shephard wrote: >> The thing that's REALLY stupid is that Linden Labs has an >> encapsulation API already, as mentioned in the reply to my message >> about how to encapsulate parameters to plugins, and nobody's talking >> about how to use that. > How would you use it to instantiate widgets and react to widget > events, like the ones in Dales plugin for example? That's a hairier problem because C++ APIs are so much more complex than C, and one that's best addressed by some kind of automation. There are packages that automatically generate glue code for calling native routines from scripting languages, and while these are usually for C rather than C++ I don't see that as an insurmountable barrier. It's a pity the SL GUI is in such an awkward language, rather than a low level one with a well defined calling convention or a real high level language like Objective C, one that supports dynamic method calls at runtime and provides pretty much all the hooks you need without extra work. From secret.argent at gmail.com Tue Feb 27 10:29:35 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 10:29:34 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <45E46515.4060608@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> Message-ID: <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> > The tags are text. Tag 0 is a string 1024 bytes long. If > developers wanted to coordinate to test two features at once, they > can come up with some kind of delimiter inside the field. OK, you're using "tag" to describe the entire parameter list, not the identifier of the parameter list. Then "I strongly suggest that tags be identified by a guaranteed unique string, otherwise how would you EVER test something in public?". > This is hard partly by design, to discourage retail products based > off beta features that are not accepted by LL. Are you're saying is that it's acceptable, if I'm got a prim with a tag I'm testing in an attachment, to randomly crash people around me who might have an incompatible plugin (remember the plugin architecture discussion)? Because someone might create and sell a product that needs you to be running a plugin? People are going to do that anyway. You know what's going to happen if they do this? People are going to write plugins that use Linden tags in undefined ways, the way people have products that use llSetPrimitiveParams() or llMessageLinked() in technically illegal and undefined ways, and then Linden Labs will likely find themselves in a situation where they feel themselves constrained by those products, the way they've found themselves bending over backwards to maintain hacks like invisiprims. From gigstaggart at gmail.com Tue Feb 27 11:25:47 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 27 11:25:52 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> Message-ID: <45E485BB.7030402@gmail.com> Argent Stonecutter wrote: -snip bunch of irrelevant crap- I think we need to go over how this works again, you are completely missing the point. Please read carefully. Suppose I want to implement the client side part web textures, so that Linden Lab can easily pick up the patches and make minor server side changes to support it and then it'll be done. Right now, it's kinda hard to do that, because there's no way to associate this new metadata with a prim, without using something hacky like the description field, or having it OwnerSay the stuff over and over. Either method means that it'll have to be rewritten later on when the actual protocol is updated to take advantage of the feature. My proposal eliminates that rewriting. This system allows me to implement web textures in a way that can be easily picked up by Linden Lab and transitioned into a real feature. You notice this has *nothing* to do with plugins, not directly. Here's how it would work. 1. I make up my mini API for web textures: webtext, face, 2. Then, on my testing prims I insert the LSL Script: llSetMetaInformation("webtext, face1, http://www.m.com/webtexture.php?text=my%20text"); //inserts string into tag 0 for this prim. 3. Then, in the client I begin to make my modifications, which read tag 0 and use that data. I ensure that it's easy to change which tag number that my feature is assigned to, for the day when it is accepted and moved to a real tag number. 4. I test the feature, and encourage other *developers* (including linden lab) to test it too, by applying my client side patches, and using the LSL to set tag 0 on some test prims to the strings that my feature is expecting. 5. Feedback is gotten from Linden Lab developers on the feature, and the feature is patched/updated/further developed. 6. The feature is accepted by Linden Lab. Linden Lab can then assign the feature a unique tag number, lets say 1001. 7. Linden Lab implements: llSetWebTexture(string url, integer face); //Updates prim tag 1001 with "webtext, face, " Note that this uses my same API except it is now on a high tag that can't be modified directly by users. The client is updated by changing a single constant, that tells the web texture feature to look for tag 1001 instead of tag 0. 8. Done! You'll notice that this is entirely a development tool. It is not meant to be used by end users, ever. There is no way for anyone except Linden Lab to modify any tag other than tag 0. Tag 0 is solely for development testing purposes. There is no chance for any "support for undocumented features" problem like you mention. From peter at metaversatility.com Tue Feb 27 11:30:27 2007 From: peter at metaversatility.com (Peter Haik) Date: Tue Feb 27 11:30:30 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <45E485BB.7030402@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> Message-ID: <6b5e28fa0702271130v141b0f6p875749064d1d4e1d@mail.gmail.com> > > > There is no chance for any "support for undocumented features" problem > like you mention. Famous last words... This of course really depends on how it actually gets implemented. -- Peter Haik Co-Founder Metaversatility -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070227/4cd8e1e9/attachment.htm From tshephard at gmail.com Tue Feb 27 11:52:12 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 11:52:15 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: References: <45E46B21.5090700@lindenlab.com> Message-ID: <3b19a500702271152o2b8da98bicebd7929e608a022@mail.gmail.com> Thanks Richard. That was a real eye opener, especially the bit about "large architectural decisions to be made". Can you shed some light on that? Are these decisions strictly GUI hierarchy related? Timelines? My main concern here would be developing a contract of Ansi C function pointers across DLLs and then after the architecture upgrade is done a significant impedance mismatch occurs, and everyone needs to rewrite their plugins. Or, worse, we keep you guys from doing the upgrades you need to do because you have to support a bunch of legacy plugins... ;) Heh. I hope I'm not the only one that doesn't see the curious challenge trying to architect when you have no clue what the over all technical roadmap looks like... I am beginning to think whatever we come up with in this environment is going to be sub-optimal at best. Though I can imagine that we can probably come up with something that works... On 2/27/07, Richard Nelson wrote: > Just jumping in here to comment on LLFloater stability. In general, we can't guarantee that our UI class interfaces will remain stable. For example, we recently changed LLFloaters and LLPanels to implement LLUICtrl in order to sanitize our keyboard focus model and let them participate fully in focus management (LLView's can't delegate keyboard focus, they can only contain LLUICtrls, or widgets). We've also made many changes in the move over to XML-driven UI. These changes are not complete, and we will continue to tease out architectural abstractions and refactor our UI code based on use cases as they arise. > > That said, most changes can be considered extensions to existing functionality, implemented in the base class, with no extra burden on derived classes. There are still large architectural decisions to be made, though. > > Richard > > > On Tue, 27 Feb 2007 09:32:17 -0800, Rob Lanphier wrote: > > > > >> > Basically there would be an instance of LLFloaterPluginProxy for every > >> > plugin floater created. > >> > >> I initially rejected the derivation idea, as a class derived from the > >> floater class meant that this class would change any time the floater did. > > > > OK, that concern makes sense. However, looking through the code, > > llFloater seems likely to be very resistant to change. If it does > > change, it would likely impact a very significant amount of code and > > therefore would only occur when absolutely necessary. > > > > Perhaps a linden can comment.. > > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From jhurliman at wsu.edu Tue Feb 27 12:29:10 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Feb 27 12:29:28 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <3b19a500702271152o2b8da98bicebd7929e608a022@mail.gmail.com> References: <45E46B21.5090700@lindenlab.com> <3b19a500702271152o2b8da98bicebd7929e608a022@mail.gmail.com> Message-ID: <45E49496.7080204@wsu.edu> Tim Shephard wrote: > Thanks Richard. > > That was a real eye opener, especially the bit about "large > architectural decisions to be made". > > Can you shed some light on that? Are these decisions strictly GUI > hierarchy related? Timelines? > > My main concern here would be developing a contract of Ansi C function > pointers across DLLs and then after the architecture upgrade is done a > significant impedance mismatch occurs, and everyone needs to rewrite > their plugins. Or, worse, we keep you guys from doing the upgrades > you need to do because you have to support a bunch of legacy > plugins... ;) > > Heh. I hope I'm not the only one that doesn't see the curious > challenge trying to architect when you have no clue what the over all > technical roadmap looks like... > > I am beginning to think whatever we come up with in this environment > is going to be sub-optimal at best. > > Though I can imagine that we can probably come up with something that > works... > > Continuing on with what Richard was saying, everything has changed, is changing, and will continue to change in the future. Second Life is more like a research project than a product, and expecting that you can write anything for it and walk away for two months and have it still 100% functional is completely out of the question. Forget about UI architectures changing, what if the functionality your plugin uses doesn't exist on the grid in another two weeks? What if the packets that you are intercepting and sending out are now using the REST protocol? With World of Warcraft plugins, every time a big functional change is made to WoW or the plugin API changes they bump a version number and every plugin breaks. The plugin developers take a look at the latest changes, adapt to them, and release again. It's not an ideal situation, it's probably not even good, but it works and in reality it's probably the only way to build a plugin system on top of something with such a rapid development cycle. I would focus on a versioning system for different components of the client, so if message_template.msg changes all plugins that send and receive packets break. If the UI system changes all plugins that have UIs break. Same for the rendering pipeline, etc. Just throwing a wish out, but if the API exposed C functions instead of C++ that would make my day. John Hurliman From tshephard at gmail.com Tue Feb 27 12:58:13 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 12:58:16 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <45E49496.7080204@wsu.edu> References: <45E46B21.5090700@lindenlab.com> <3b19a500702271152o2b8da98bicebd7929e608a022@mail.gmail.com> <45E49496.7080204@wsu.edu> Message-ID: <3b19a500702271258s1999d164r1adf4d0e2adce307@mail.gmail.com> Another way to deal with the chaos is to develop a layer which shields the plugin developer from a majority of it. ie: instead of tight bindings to the current UI architecture, we could loosen it up. A layer of facades that are divorced from the current system and plugin facing contracts will not be majorly impacted by changes to the core code base. Provide the client with a bit of an internal capabilities API, so if something is not longer present, they can detect it on startup / on the fly. Also, if things are going to be getting busted so much, I believe this means that dynamic on the fly, behing the scenes updating of plugins is becoming more critical. Users should be able to get updates without feeling the upgrade pain, cause it sounds like they'll be feeling enough as it is.. Also, I hope we don't let this "all is chaos" approach become an excuse not to have a dialogue with the Lindens. That would be awfully unfortunate.. On 2/27/07, John Hurliman wrote: > Tim Shephard wrote: > > Thanks Richard. > > > > That was a real eye opener, especially the bit about "large > > architectural decisions to be made". > > > > Can you shed some light on that? Are these decisions strictly GUI > > hierarchy related? Timelines? > > > > My main concern here would be developing a contract of Ansi C function > > pointers across DLLs and then after the architecture upgrade is done a > > significant impedance mismatch occurs, and everyone needs to rewrite > > their plugins. Or, worse, we keep you guys from doing the upgrades > > you need to do because you have to support a bunch of legacy > > plugins... ;) > > > > Heh. I hope I'm not the only one that doesn't see the curious > > challenge trying to architect when you have no clue what the over all > > technical roadmap looks like... > > > > I am beginning to think whatever we come up with in this environment > > is going to be sub-optimal at best. > > > > Though I can imagine that we can probably come up with something that > > works... > > > > > > Continuing on with what Richard was saying, everything has changed, is > changing, and will continue to change in the future. Second Life is more > like a research project than a product, and expecting that you can write > anything for it and walk away for two months and have it still 100% > functional is completely out of the question. Forget about UI > architectures changing, what if the functionality your plugin uses > doesn't exist on the grid in another two weeks? What if the packets that > you are intercepting and sending out are now using the REST protocol? > With World of Warcraft plugins, every time a big functional change is > made to WoW or the plugin API changes they bump a version number and > every plugin breaks. The plugin developers take a look at the latest > changes, adapt to them, and release again. It's not an ideal situation, > it's probably not even good, but it works and in reality it's probably > the only way to build a plugin system on top of something with such a > rapid development cycle. I would focus on a versioning system for > different components of the client, so if message_template.msg changes > all plugins that send and receive packets break. If the UI system > changes all plugins that have UIs break. Same for the rendering > pipeline, etc. > > Just throwing a wish out, but if the API exposed C functions instead of > C++ that would make my day. > > John Hurliman > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From secret.argent at gmail.com Tue Feb 27 13:14:13 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 13:14:21 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <45E485BB.7030402@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> Message-ID: On Feb 27, 2007, at 1:25 PM, Jason Giglio wrote: -snip bunch of irrelevant crap- > You notice this has *nothing* to do with plugins, not directly. It doesn't matter whether you think it's got anything to do with plugins or not. If this is implemented in the server, people will use it for whatever they can use it for. If people can add code to a prim to pass information to the client, people will use it for that, no matter what you intend. And you still have the problem that since it's untagged (and it is untagged, the way you describe it) then two people testing different features will step on each other's toes. No matter what you intend. > llSetWebTexture(string url, integer face); //Updates prim tag 1001 > with "webtext, face, " > > Note that this uses my same API except it is now on a high tag that > can't be modified directly by users. Linden Labs already has a mechanism to pass actual property lists, real *lists*, typechecked in LSL, serialized for transport, and you want to jam it into strings? At the very least the tagged data needs to be a list, like all the other prim properties (primitive parameters, particle systems, etc). > There is no chance for any "support for undocumented features" > problem like you mention. I wish I was as wise as you. From dale at daleglass.net Tue Feb 27 13:26:27 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 27 13:26:57 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <5728C888-B1B6-41C3-97C2-F51C1FE7BC66@gmail.com> References: <20070225011052.546DD41AFCA@stupor.lindenlab.com> <5728C888-B1B6-41C3-97C2-F51C1FE7BC66@gmail.com> Message-ID: <200702272226.40737.dale@daleglass.net> ? ????????? ?? 27 ??????? 2007 16:21 Argent Stonecutter ???????(a): > Dale Glass's hack is really the only way to do it without LL support. > > Dale: ever thought about taking your code and combining it with side- > chat on a well known port to let people start writing scripts that > talk to LSL directly, now, without waiting for an internal plugin > architecture? I'm not entirely sure what's the point of that though. Why use the viewer to pass chat messages through when you could use libsecondlife instead? If I was doing the client listening on a socket thing I'd use a much more complete protocol for program/viewer communication. Probably formatted in XML (since the viewer already uses a parser might as well use that) and with the ability to talk to the viewer itself. Then this would be a minor part of the available functionality. If you just use the viewer to pass chat messages back and forth then it's hard to write anything very interesting, and any GUI would be problematic, as you'd lose it if using SL fullscreen for example. > For security purposes, how about this? > > $VwrComm$CHANNEL$VERSION$COMPONENT$data" > > Where CHANNEL has to match the channel the original message was sent on. > > This would at least allow you to use the "secret channel number" > technique to prevent scripted objects around you impersonating > responses. It's not the greatest, but it's what SL already depends on > in many many places so it's as good as what we already use. Why use the channel? For basic security I'd check the object's key and owner, and if you want to be really sure you're talking to the right thing, use CRAM-MD5, which is very easy to implement in LSL. > _______________________________________________ > 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/20070227/fa109852/attachment.pgp From gigstaggart at gmail.com Tue Feb 27 13:48:16 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 27 13:48:15 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> Message-ID: <45E4A720.7010001@gmail.com> Argent Stonecutter wrote: > On Feb 27, 2007, at 1:25 PM, Jason Giglio wrote: > -snip bunch of irrelevant crap- >> You notice this has *nothing* to do with plugins, not directly. > > It doesn't matter whether you think it's got anything to do with plugins > or not. If this is implemented in the server, people will use it for > whatever they can use it for. If people can add code to a prim to pass > information to the client, people will use it for that, no matter what > you intend. > They can use it for whatever they want, it creates no burden on Linden Lab if they abuse it. It's not suitable for this use, as you continue to point out, as if it's a flaw. > And you still have the problem that since it's untagged (and it is > untagged, the way you describe it) then two people testing different > features will step on each other's toes. No matter what you intend. That is why it is not suitable for generic non-linden approved communications to the client. That *is* the intent. It is suitable only for *development*. Not for deployment. That is by design. It seems that you want something else, something that can be used for deployment of arbitrary prim-property features without linden implementation, that is not the intent of this, and it is unsuitable for this use, as you pointed out. > Linden Labs already has a mechanism to pass actual property lists, real > *lists*, typechecked in LSL, serialized for transport, and you want to > jam it into strings? This has little to do with LSL. LSL is only a convenient server side way to modify these properties *during feature development*. In many cases the end server-side feature target might not be LSL. The client feature surely has no idea about LSL lists and types, and it shouldn't need to. My CSG example on the wiki, for instance, that would more often be set from the build tools, and might have nothing to do with LSL after initial development. > At the very least the tagged data needs to be a list, like all the other > prim properties (primitive parameters, particle systems, etc). > No. There will never be a need for the user to modify any tag other than 0 directly. You still seem to be under the impression that every tag used this way will be directly script-accessible. Some tags might get LSL wrapper functions, and some may not, either way it's an irrelevant high level detail. -Jason From secret.argent at gmail.com Tue Feb 27 14:37:41 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 14:37:50 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <45E4A720.7010001@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> Message-ID: <6803E597-E9DA-4079-BBAE-C0458E493E73@gmail.com> On Feb 27, 2007, at 3:48 PM, Jason Giglio wrote: > It is suitable only for *development*. Not for deployment. That > is by design. Not even that: since it's untagged (and it is untagged, the way you describe it) then two people (developers) testing (developing) different features will step on each other's toes. > It seems that you want something else, something that can be used > for deployment of arbitrary prim-property features without linden > implementation, What I "want" is irrelevant. It doesn't matter what I want, or what you want, people will still do the same things no matter what your intention or my intention is. So, basically, I'm just telling you what will happen if this is implemented the way you describe. Because it's what's happened every time something like this has been implemented in any software system ever. > This has little to do with LSL. LSL is only a convenient server > side way to modify these properties *during feature development*. > In many cases the end server-side feature target might not be LSL. Whether the server side target is LSL or not, prim properties are still serialized LSL lists. > The client feature surely has no idea about LSL lists and types, > and it shouldn't need to. Any client feature dealing with prim properties will be dealing with serialized LSL lists. > My CSG example on the wiki, for instance, that would more often be > set from the build tools, and might have nothing to do with LSL > after initial development. The parameters set from build tools are also LSL lists. From secret.argent at gmail.com Tue Feb 27 14:51:23 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 14:51:28 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <200702272226.40737.dale@daleglass.net> References: <20070225011052.546DD41AFCA@stupor.lindenlab.com> <5728C888-B1B6-41C3-97C2-F51C1FE7BC66@gmail.com> <200702272226.40737.dale@daleglass.net> Message-ID: On Feb 27, 2007, at 3:26 PM, Dale Glass wrote: > ? ????????? ?? 27 ??????? 2007 16:21 Argent > Stonecutter ???????(a): >> Dale: ever thought about taking your code and combining it with side- >> chat on a well known port to let people start writing scripts that >> talk to LSL directly, now, without waiting for an internal plugin >> architecture? > I'm not entirely sure what's the point of that though. Why use the > viewer to > pass chat messages through when you could use libsecondlife instead? Because connecting to a socket is a few lines of code, because you can connect to a socket in just about any scripting language on any platform, because you're using the viewer anyway, because libsl doesn't connect through the viewer. > If I was doing the client listening on a socket thing I'd use a > much more > complete protocol for program/viewer communication. Probably > formatted in XML > (since the viewer already uses a parser might as well use that) and > with the > ability to talk to the viewer itself. Then this would be a minor > part of the > available functionality. This isn't about program-viewer communication, this is about script- script communication. > If you just use the viewer to pass chat messages back and forth > then it's hard > to write anything very interesting, and any GUI would be > problematic, as > you'd lose it if using SL fullscreen for example. The majority of the cases I'm thinking of need no GUI at all, or the whole point is to add a GUI to something on the computer inside SL, in a HUD attachment for example. Doing it through the existing communication channels is cumbersome and requires running a mailserver or a webserver that's not NATted to initiate the connection even with XMLRPC. A couple of obvious applications: Controls sending chat messages to vehicles. This wouldn't even need return messages, and could be used with existing vehicles. Local scripts communicating with HUDs, to provide in-world UI for local applications. From jacek.antonelli at gmail.com Tue Feb 27 15:16:22 2007 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Tue Feb 27 15:16:25 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <45E4A720.7010001@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> Message-ID: On 2/27/07, Jason Giglio wrote: > That is why it is not suitable for generic non-linden approved > communications to the client. That *is* the intent. > > It is suitable only for *development*. Not for deployment. That is by > design. > > It seems that you want something else, something that can be used for > deployment of arbitrary prim-property features without linden > implementation, that is not the intent of this, and it is unsuitable for > this use, as you pointed out. Perhaps I am ignorant and blind, but it seems to me that implementing "arbitrary prim attributes for use" yields "... for testing" at no additional cost, in addition to being a genuinely useful idea in itself. To put it briefly: for-use has everything we want from for-testing, plus a cherry on top. So, given that the for-testing-only design is admittedly unsuitable for the purposes of for-use, and given that for-use is broader and more useful, what reason is there to consider for-testing-only? What are the concerns about for-use? Less secure? More work to implement? People doing things that we don't personally approve of? I wrote a blog post about "arbitrary prim attributes" some time ago. (I am loathe to plug my own blog, so I won't link to it. I'm sure Google can help you find it, if you want to.) To summarize what I said there: SL could follow the route of XML, where each element can have many tags, each with a label and a data string (e.g. foo="42 bar"). This makes it more like a hash table/dictionary than an array, which is a good thing in my view. (Registering "attribute #1001" for a particular use seems like too much of a "magic number". Better to give it a descriptive name.) The server would be completely ignorant of the tags, except for storing them (probably enforcing a data-size limit per prim) and passing them along to each client that sees the prim. It would be up to each client to a) pay attention to any particular attribute, b) verify that the data is proper, well-formed, not malicious, etc., and c) act in some way based on the attribute. As far as accessing the attributes goes: - from LSL: `llGetAttribute(string label)' and `llSetAttribute(string label, string data)' would seem to be all that is needed. Maybe later, functions which accept a list of [label, data, label, data, ...] to get/set multiple attributes at once, for efficiency. Perhaps also a separate `llDeleteAttribute(string label)' function to delete the attribute entirely (instead of just making its data blank). - from client code: similar functions to LSL, but with an additional function to set an attribute locally, without modifying the object on the server. - from the UI: assuming that you have permission to modify a prim, I see no reason why you shouldn't be able to edit its arbitrary attributes from the UI, like you edit its name, description, and other parameters. This could be written later, in terms of the client code functions mentioned above. Perhaps it would also be useful to have "hidden" attributes, which are not visible to clients. (This would be quite handy as persistent data storage for LSL scripts!) Any thoughts, comments, suggestions, etc.? - Jacek Antonelli From jhurliman at wsu.edu Tue Feb 27 15:27:11 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Feb 27 15:27:18 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <3b19a500702271258s1999d164r1adf4d0e2adce307@mail.gmail.com> References: <45E46B21.5090700@lindenlab.com> <3b19a500702271152o2b8da98bicebd7929e608a022@mail.gmail.com> <45E49496.7080204@wsu.edu> <3b19a500702271258s1999d164r1adf4d0e2adce307@mail.gmail.com> Message-ID: <45E4BE4F.5000508@wsu.edu> Tim Shephard wrote: > Another way to deal with the chaos is to develop a layer which shields > the plugin developer from a majority of it. > > ie: instead of tight bindings to the current UI architecture, we > could loosen it up. A layer of facades that are divorced from the > current system and plugin facing contracts will not be majorly > impacted by changes to the core code base. > From what I have seen in the last year of SL development, it might not even be worth it to try. No matter how abstracted away things are, it only takes one functional change in how things work to break plugins. If a plugin is utilizing something that no longer exists in a new version, it's not going to work until changes are made to the plugin. > Provide the client with a bit of an internal capabilities API, so if > something is not longer present, they can detect it on startup / on > the fly. It could work in theory, but it would have to be fairly complex. To throw an example out there, you used to be able to send ViewerEffect packets without specifying an AgentID or SessionID, which made for a mild but entertaining exploit. I implemented the libsecondlife ViewerEffect functions to work against what currently existed, and wrote some SLProxy code against what currently existed. After reporting the exploit, the next release fixed the problem which meant a protocol change. The ViewerEffect packet was still called ViewerEffect, it still worked in the exact same way, but there were new required fields where the packet wouldn't work if they didn't exist. libsecondlife had to be updated and the SLProxy code had to be updated to reflect that. Unless the "internal capabilities API" either attached version numbers to every packet, or had a way of analyzing code to make sure that every field is set properly it would have no way of detecting whether an OpenSL plugin was using ViewerEffect correctly. You could always abstract away from every packet and make a proxy interface to building each packet, but with over 500 packets (the exact number changes almost every release) it's not feasible. It might be beneficial to define a set of goals and determine a cost-benefit for them, and then go back and reassess the goals. A goal of making an interface where plugin developers never have to update their code is not going to be reasonable. A goal of having plugin developers only have to update their code every month or so might be attainable in some circumstances, but how much work would it take to maintain an interface like that, versus the amount of work it would take for plugin developers to keep their code up to date? > > Also, if things are going to be getting busted so much, I believe this > means that dynamic on the fly, behing the scenes updating of plugins > is becoming more critical. Users should be able to get updates > without feeling the upgrade pain, cause it sounds like they'll be > feeling enough as it is.. I agree completely. Something like the Firefox model where it automatically checks for updates and can install them almost painlessly. There's no reason to put the burden of development on the end users as well. > > Also, I hope we don't let this "all is chaos" approach become an > excuse not to have a dialogue with the Lindens. That would be > awfully unfortunate.. Aren't we having a dialog right now? John From gigstaggart at gmail.com Tue Feb 27 15:36:57 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 27 15:37:01 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> Message-ID: <45E4C099.80009@gmail.com> Jacek Antonelli wrote: > On 2/27/07, Jason Giglio wrote: >> That is why it is not suitable for generic non-linden approved >> communications to the client. That *is* the intent. >> >> It is suitable only for *development*. Not for deployment. That is by >> design. >> >> It seems that you want something else, something that can be used for >> deployment of arbitrary prim-property features without linden >> implementation, that is not the intent of this, and it is unsuitable for >> this use, as you pointed out. > > Perhaps I am ignorant and blind, but it seems to me that implementing > "arbitrary prim attributes for use" yields "... for testing" at no > additional cost, in addition to being a genuinely useful idea in > itself. To put it briefly: for-use has everything we want from > for-testing, plus a cherry on top. That is a valid avenue to explore. I considered this when writing my proposal and rejected it for the following reasons: 1. Fracturing the metaverse with content only viewable with certain plugins, like the web is/was. 2. Because of this, it's a controversial change. 3. The main reason, it was not necessary to accomplish what I wanted to accomplish with my proposal. Simple is better. > What > are the concerns about for-use? Less secure? More work to implement? > People doing things that we don't personally approve of? None of those. It wouldn't be much harder, but it may not be desirable. > This makes it more like a hash table/dictionary than an array, which > is a good thing in my view. (Registering "attribute #1001" for a > particular use seems like too much of a "magic number". Better to give > it a descriptive name.) That is a valid alternative to numeric tagging. One concern I would have is that 15,000 of these things will be flying at the client when you enter a sim. It could be slow to process string keyed tags. > The server would be completely ignorant of the tags, except for > storing them (probably enforcing a data-size limit per prim) and > passing them along to each client that sees the prim. It would be up > to each client to a) pay attention to any particular attribute, b) > verify that the data is proper, well-formed, not malicious, etc., and > c) act in some way based on the attribute. Yep. > As far as accessing the attributes goes: > > - from LSL: `llGetAttribute(string label)' and `llSetAttribute(string > label, string data)' would seem to be all that is needed. Maybe later, > functions which accept a list of [label, data, label, data, ...] to > get/set multiple attributes at once, for efficiency. Perhaps also a > separate `llDeleteAttribute(string label)' function to delete the > attribute entirely (instead of just making its data blank). That sounds good to me for what you are trying to do. I think you should write this up as a new wiki page and link it from mine as an alternative implementation, with different design goals. > - from client code: similar functions to LSL, but with an additional > function to set an attribute locally, without modifying the object on > the server. What does this serve? > > - from the UI: assuming that you have permission to modify a prim, I > see no reason why you shouldn't be able to edit its arbitrary > attributes from the UI, like you edit its name, description, and other > parameters. This could be written later, in terms of the client code > functions mentioned above. That's a lot of nastiness to show to the user. Best leave it to LSL scripters to wrap it in something user friendly. It's not unprecedented, there's no UI to create a particle system, for example. > Perhaps it would also be useful to have "hidden" attributes, which are > not visible to clients. (This would be quite handy as persistent data > storage for LSL scripts!) I doubt LL wants this, or they would have done it already. That was one of the reasons my proposal doesn't have a "Get" function, so that it can't be used for LSL data storage, and only used for the intended purpose. -Jason From mindtriggerz at gmail.com Tue Feb 27 15:51:50 2007 From: mindtriggerz at gmail.com (Jesse Nesbitt) Date: Tue Feb 27 15:51:55 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <45E4C099.80009@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> <45E4C099.80009@gmail.com> Message-ID: I'd also like to point out that LL already has a packet called ObjectExtraParams in the message template, so it seems that they're already possibly working toward letting us embed metadata. Also, Argent, prim parameters are sent to the client as an ObjectUpdate packet, with strongly-typed variables, not stored/sent as LSL lists. On 2/27/07, Jason Giglio wrote: > Jacek Antonelli wrote: > > On 2/27/07, Jason Giglio wrote: > >> That is why it is not suitable for generic non-linden approved > >> communications to the client. That *is* the intent. > >> > >> It is suitable only for *development*. Not for deployment. That is by > >> design. > >> > >> It seems that you want something else, something that can be used for > >> deployment of arbitrary prim-property features without linden > >> implementation, that is not the intent of this, and it is unsuitable for > >> this use, as you pointed out. > > > > Perhaps I am ignorant and blind, but it seems to me that implementing > > "arbitrary prim attributes for use" yields "... for testing" at no > > additional cost, in addition to being a genuinely useful idea in > > itself. To put it briefly: for-use has everything we want from > > for-testing, plus a cherry on top. > > That is a valid avenue to explore. I considered this when writing my > proposal and rejected it for the following reasons: > > 1. Fracturing the metaverse with content only viewable with certain > plugins, like the web is/was. > > 2. Because of this, it's a controversial change. > > 3. The main reason, it was not necessary to accomplish what I wanted to > accomplish with my proposal. Simple is better. > > > > What > > are the concerns about for-use? Less secure? More work to implement? > > People doing things that we don't personally approve of? > > None of those. It wouldn't be much harder, but it may not be desirable. > > > This makes it more like a hash table/dictionary than an array, which > > is a good thing in my view. (Registering "attribute #1001" for a > > particular use seems like too much of a "magic number". Better to give > > it a descriptive name.) > > That is a valid alternative to numeric tagging. One concern I would > have is that 15,000 of these things will be flying at the client when > you enter a sim. It could be slow to process string keyed tags. > > > > The server would be completely ignorant of the tags, except for > > storing them (probably enforcing a data-size limit per prim) and > > passing them along to each client that sees the prim. It would be up > > to each client to a) pay attention to any particular attribute, b) > > verify that the data is proper, well-formed, not malicious, etc., and > > c) act in some way based on the attribute. > > Yep. > > > > As far as accessing the attributes goes: > > > > - from LSL: `llGetAttribute(string label)' and `llSetAttribute(string > > label, string data)' would seem to be all that is needed. Maybe later, > > functions which accept a list of [label, data, label, data, ...] to > > get/set multiple attributes at once, for efficiency. Perhaps also a > > separate `llDeleteAttribute(string label)' function to delete the > > attribute entirely (instead of just making its data blank). > > That sounds good to me for what you are trying to do. I think you > should write this up as a new wiki page and link it from mine as an > alternative implementation, with different design goals. > > > > - from client code: similar functions to LSL, but with an additional > > function to set an attribute locally, without modifying the object on > > the server. > > What does this serve? > > > > > - from the UI: assuming that you have permission to modify a prim, I > > see no reason why you shouldn't be able to edit its arbitrary > > attributes from the UI, like you edit its name, description, and other > > parameters. This could be written later, in terms of the client code > > functions mentioned above. > > That's a lot of nastiness to show to the user. Best leave it to LSL > scripters to wrap it in something user friendly. It's not > unprecedented, there's no UI to create a particle system, for example. > > > Perhaps it would also be useful to have "hidden" attributes, which are > > not visible to clients. (This would be quite handy as persistent data > > storage for LSL scripts!) > > I doubt LL wants this, or they would have done it already. That was one > of the reasons my proposal doesn't have a "Get" function, so that it > can't be used for LSL data storage, and only used for the intended purpose. > > -Jason > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > -- --Jesse From dale at daleglass.net Tue Feb 27 15:54:55 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 27 15:55:11 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: References: <20070225011052.546DD41AFCA@stupor.lindenlab.com> <200702272226.40737.dale@daleglass.net> Message-ID: <200702280055.01446.dale@daleglass.net> ? ????????? ?? 27 ??????? 2007 23:51 Argent Stonecutter ???????(a): > Because connecting to a socket is a few lines of code, because you > can connect to a socket in just about any scripting language on any > platform, because you're using the viewer anyway, because libsl > doesn't connect through the viewer. Why "anyway"? If all you have is a chat channel, and none of the client's benefits, then about the only benefit over using libsecondlife is that you get the viewer to speak for you. You could do the socket thing in libsecondlife as well, or even easier, a pipe. > This isn't about program-viewer communication, this is about script- > script communication. What I mean here is: You lose a LOT of things if all you do is to pass messages back and forth. So why limit it to that? Make the viewer accept complex commands, or at least make it so that they can be added later without breaking the protocol. Make it so that you can request the viewer to control the music, accept external keypresses, upload files, etc. And one of the available commands would be setting up this message stuff. In fact, that was one of the things in my TODO list: Make a socket protocol that would allow me to tell the viewer to accept scripts, compile them, and automatically send to the right place in my inventory. > A couple of obvious applications: > > Controls sending chat messages to vehicles. This wouldn't even need > return messages, and could be used with existing vehicles. This is far less than ideal. First, if the code is outside the client and all you have is message relay it means you must shift focus to app doing the control stuff. I suppose you could capture the input while SL is active, but then it'd conflict. Also, without changing the viewer you don't have the ability to make the vehicle move on screen before the command gets to the server. That results in annoying lag. I think a better approach would be to have an app tell the viewer "Act as if this key was pressed". Then you get the benefits of client-side prediction. > Local scripts communicating with HUDs, to provide in-world UI for > local applications. This is also very not ideal. For example, my avatar list would lose the ability to get the avatar list from the viewer itself, and would have to run a sensor in the LSL script, which is must limited in its capability. It would also lose the ability to open IM and profile windows, making the avatar speak and setting beacons. Now, if you want to use my hack to talk to in-world objects that way, sure, go ahead. But like I said, I'd use a more complex protocol for the communication. The hack was done to be as simple as possible for the LSL side, but it's not all that great if you have more powerful things available. Here's how I'd do it: Client to viewer on socket: Hi there! LSL script replies: $VwrComm$0$Foo$Widget online Viewer outputs this on the socket: Widget online And so on. Doesn't have to be specifically XML of course, but I do think it shouldn't be as simple as plain text with no metadata at all as that limits the possible functionality. > > _______________________________________________ > 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/20070228/a6f9f11d/attachment-0001.pgp From gigstaggart at gmail.com Tue Feb 27 16:03:31 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 27 16:03:30 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: <6803E597-E9DA-4079-BBAE-C0458E493E73@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> <6803E597-E9DA-4079-BBAE-C0458E493E73@gmail.com> Message-ID: <45E4C6D3.5020505@gmail.com> Argent Stonecutter wrote: > Not even that: since it's untagged (and it is untagged, the way you > describe it) then two people (developers) testing (developing) different > features will step on each other's toes. Not unless they happen to be in the same sim at the same time. If their feature does something bad when it encounters invalid data, that's a bug they should fix anyway. >prim properties are still serialized LSL lists. No, they aren't. Most of them are U8's, not even compatible with LSL. -Jason From secret.argent at gmail.com Tue Feb 27 16:16:01 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 16:16:14 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> Message-ID: A useful scheme, one that wouldn't be intended just for testing, *also* sounds like a good idea. > - from LSL: `llGetAttribute(string label)' and `llSetAttribute(string > label, string data)' would seem to be all that is needed. Maybe later, > functions which accept a list of [label, data, label, data, ...] to > get/set multiple attributes at once, for efficiency. Perhaps also a > separate `llDeleteAttribute(string label)' function to delete the > attribute entirely (instead of just making its data blank). Good so far. Making the data a list rather than a string (so you can have an attribute similar to llParticleSystem without having to trust the script properly encoding it) would be good, but not essential. To reduce network traffic, the sim wouldn't broadcast the attributes, it would broadcast a list of attribute names, so the client could only fetch the attributes it's interested in. Also: llGetAttributeKey(key id, string label) This would let you implement code that could handle attributes on nearby objects, so if you're standing in front of a vendor using llHTMLtexture your HUD could alert you. llSetAttributeKey(key id, string label, string data); For building tools, and to set attributes on avatars. Eg: change(integer what) { if((what & CHANGED_LINK) && llGetAttached()) { llSetAttributeKey(llGetOwner(),"extended-skeleton","centaur"); llSetAttribute("attach-point","hind-leg"); } } llGetAttributeLink(integer link, string label) llSetAttributeLink(integer link, string label, string data) To head off the people who might otherwise create 300 prim wings with a script in each prim. > - from the UI: assuming that you have permission to modify a prim, I > see no reason why you shouldn't be able to edit its arbitrary > attributes from the UI, like you edit its name, description, and other > parameters. This would tend to work against the idea of making the attributes a list, but it's definitely a worthwhile tradeoff. > Perhaps it would also be useful to have "hidden" attributes, which are > not visible to clients. (This would be quite handy as persistent data > storage for LSL scripts!) Start the attribute name with a "." and it wouldn't be sent to the client in the list? (half-smiley) From secret.argent at gmail.com Tue Feb 27 16:22:17 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 16:22:25 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> <45E4C099.80009@gmail.com> Message-ID: On Feb 27, 2007, at 5:51 PM, Jesse Nesbitt wrote: > Also, Argent, prim parameters are sent to the client as an > ObjectUpdate packet, with strongly-typed variables, not stored/sent as > LSL lists. That's isomorphic to an LSL list. The point isn't how the data is marshalled, the point is that it's typed. The way Jason described it the only change that would be made when it's finalized would be changing the tag, which means that it should already be strongly typed (IE, exposed to LSL as a list) before that point. From secret.argent at gmail.com Tue Feb 27 16:40:31 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 16:40:40 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <200702280055.01446.dale@daleglass.net> References: <20070225011052.546DD41AFCA@stupor.lindenlab.com> <200702272226.40737.dale@daleglass.net> <200702280055.01446.dale@daleglass.net> Message-ID: On Feb 27, 2007, at 5:54 PM, Dale Glass wrote: > Why "anyway"? If all you have is a chat channel, and none of the > client's > benefits, then about the only benefit over using libsecondlife is > that you > get the viewer to speak for you. Which is a pretty damn important one. It's kind of essential for HUD and vehicle control. > What I mean here is: You lose a LOT of things if all you do is to pass > messages back and forth. So why limit it to that? Because I'm looking at making this easy to use for the kind of people I find myself helping with LSL scripting on a regular basis. > Make the viewer accept > complex commands, or at least make it so that they can be added > later without > breaking the protocol. Fair enough. But the format for the simple case needs to be simpler than XML. > First, if the code is outside the client and all you have is > message relay it > means you must shift focus to app doing the control stuff. Not at all. The app doing the control stuff wouldn't ever have focus. There's no reason it should, in the usual case it's not taking input from the keyboard-mouse stream, it's taking it from a third device that's not even in the normal GUI stream, like foot pedals for acceleration and braking. > Also, without changing the viewer you don't have the ability to > make the > vehicle move on screen before the command gets to the server. That > results in > annoying lag. Um, the vehicle movements in SL are controlled by the linear and rotational motors, the user's control inputs aren't meaningful to the client at all... they're passed to the script which changes the motor parameters. There's nothing to base client-side prediction on... for aircraft, at least, the only controls that are near universal are left and right and how they behave differs from one craft to another. And things that I'm interested in are things like throttle, weapons and payload, and flight mode, and they're way outside anything client prediction would be useful for. > This is also very not ideal. For example, my avatar list would lose > the > ability to get the avatar list from the viewer itself, and would > have to run > a sensor in the LSL script, which is must limited in its capability. What does your avatar list have to do with this? I'm talking about things like music player controls, local environment sensors, scriptable applications you're running anyway that you want to keep an eye on while you're full-screen *and* in world. Moving towards "SL as desktop". > And so on. Doesn't have to be specifically XML of course, but I do > think it > shouldn't be as simple as plain text with no metadata at all as > that limits > the possible functionality. The structured format shouldn't be as simple as plain XML either, because socket communication is streamed... if the viewer or application lags you can get multiple messages concatenated in a single "read"... and as your example shows a complex protocol needs to be able to embed newlines. What I generally do is something like this: If the message starts with a pound sign, it's followed by a byte count and a formatted message. Otherwise the message is a single-line unformatted message. I've used this scheme in several applications over the years. The unformatted message makes debugging easy, and the counted formatted message avoids quoting hell. From jhurliman at wsu.edu Tue Feb 27 16:46:50 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Feb 27 16:46:58 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> <45E4C099.80009@gmail.com> Message-ID: <45E4D0FA.1080702@wsu.edu> Jesse Nesbitt wrote: > I'd also like to point out that LL already has a packet called > ObjectExtraParams in the message template, so it seems that they're > already possibly working toward letting us embed metadata. That is a viewer->sim packet, and is used to set things like lighting and flexible parameters. Has nothing to do with what you're thinking of. There are a couple of different places to drop metadata in (the TextureEntry field being the cleanest one I'm aware of), but the biggest limitation is staying under the MTU for packets. The more data you pack in to each object, the less objects you can fit in each packet and the more packets have to be sent to the viewer for the simulator to properly render. From secret.argent at gmail.com Tue Feb 27 16:51:52 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Tue Feb 27 16:52:02 2007 Subject: [sldev] So what's in the "80%" part of the API? In-Reply-To: <20070227235512.5582041AF7B@stupor.lindenlab.com> References: <20070227235512.5582041AF7B@stupor.lindenlab.com> Message-ID: <0DA8EBDA-DC67-4065-B6DB-F9C5EC86BB23@gmail.com> > It might be beneficial to define a set of goals and determine a > cost-benefit for them, and then go back and reassess the goals. A goal > of making an interface where plugin developers never have to update > their code is not going to be reasonable. A goal of having plugin > developers only have to update their code every month or so might be > attainable in some circumstances, but how much work would it take to > maintain an interface like that, versus the amount of work it would > take > for plugin developers to keep their code up to date? Depends on how much you can automate the interface, and how well the interface is designed. One goal could be an 80:20 API that tries to handle the things 80% of the plugins need, and the other 20% of the developers have to update on every release. Anyone talking to raw packets is probably in the 20%, but someone who's just mapping "USB Consumer Control AC Home" to requesting your home location displayed on the world map might be able to go a year without having to change anything. From gigstaggart at gmail.com Tue Feb 27 17:13:19 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 27 17:13:24 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> Message-ID: <45E4D72F.5050605@gmail.com> Argent Stonecutter wrote: > Good so far. Making the data a list rather than a string (so you can > have an attribute similar to llParticleSystem without having to trust > the script properly encoding it) would be good, but not essential. > In case you weren't paying attention (and it appears you weren't), "the script" doesn't encode the data under my proposal, except during development. After development is complete the new built-in LL-provided LSL functions might indeed take a list, which it will then convert into the proper string. > To reduce network traffic, the sim wouldn't broadcast the attributes, it > would broadcast a list of attribute names, so the client could only > fetch the attributes it's interested in. > > Also: > > llGetAttributeKey(key id, string label) Attributes would be prim specific under both proposals, not object specific. This won't work. > llSetAttributeKey(key id, string label, string data); > > For building tools, and to set attributes on avatars. Eg: > > change(integer what) > { > if((what & CHANGED_LINK) && llGetAttached()) { > llSetAttributeKey(llGetOwner(),"extended-skeleton","centaur"); > llSetAttribute("attach-point","hind-leg"); > } > } > Just keep piling on the crap. Maybe when this proposal hits 1 million new lines of code required, you'll win some kind of award. KISS. > llGetAttributeLink(integer link, string label) > llSetAttributeLink(integer link, string label, string data) > > To head off the people who might otherwise create 300 prim wings with a > script in each prim. Yes. Such a functionality would be desirable under this tagging-for-use-not-just-development scenario. -Jason From gigstaggart at gmail.com Tue Feb 27 17:20:40 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue Feb 27 17:20:39 2007 Subject: [sldev] LSL initiated Prim metadata was Re: Plugin architecture In-Reply-To: References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> <45E4C099.80009@gmail.com> Message-ID: <45E4D8E8.8000104@gmail.com> Argent Stonecutter wrote: > The point isn't how the data is marshalled, the point is that it's > typed. The way Jason described it the only change that would be made > when it's finalized would be changing the tag, which means that it > should already be strongly typed (IE, exposed to LSL as a list) before > that point. No, changing the tag isn't the only change. UI and/or new built-in LSL functions must be made, those would generate the proper string on the new tag number from then on. Any validation and strong typing would happen there. For most LSL-tied features, it wouldn't require a list at all, rather, the string would be constructed from fixed function parameters. Changing the tag is the only change as far as the feature implementation is concerned. It is not, however, the only change. -Jason From rdw at lindenlab.com Tue Feb 27 17:34:23 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Tue Feb 27 17:34:24 2007 Subject: [sldev] Lip-sync In-Reply-To: <45E457D6.9030201@watson.ibm.com> References: <45DB36A3.60004@watson.ibm.com> <200702220127.05008.dale@daleglass.net> <45DDF52C.8090907@watson.ibm.com> <200702222156.07839.dale@daleglass.net> <6E0A6592-256B-41D2-92A7-49E20D86D5CD@secondlife.com> <45DE1868.3080002@watson.ibm.com> <45DFBE98.9080501@lifeart.net.au> <45E33682.3030405@watson.ibm.com> <45E457D6.9030201@watson.ibm.com> Message-ID: <45E4DC1F.70709@lindenlab.com> Mike Monkowski wrote: > So now my question is: I've been looking at the SL releases. Is this > code in the First Look source release now? Nope! The current First Look is just for texture pipeline improvements. -RYaN From rdw at lindenlab.com Tue Feb 27 17:36:33 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Tue Feb 27 17:37:19 2007 Subject: [sldev] Viewer Manifest In-Reply-To: <946187B0-693B-401D-A437-84AE01F23764@electricsheepcompany.com> References: <200702222327.02886.dale@daleglass.net> <1712.69.158.190.134.1172185977.squirrel@webmail.bluewax.com> <200702230017.32150.dale@daleglass.net> <45DE5634.600@lindenlab.com> <45E0EBE2.2010201@lindenlab.com> <946187B0-693B-401D-A437-84AE01F23764@electricsheepcompany.com> Message-ID: <45E4DCA1.6030006@lindenlab.com> Christian Westbrook wrote: > Agreed, Ryan, I appreciate your sharing the news about the new > installer. Thraxis was good enough to quickly turn out a NSIS script > that would allow us to ship OpenSL alongside SecondLife without running > over user settings, or (eventually) things like using different kinds of > caches, and upgrade independently. It's good to hear you say everyone > will soon "see the code" -- does this mean the install script itself > will be GPL'd as well? Sorry for the delay, the answer is yes. Of course, the OpenSL nsi might still be better, but that's OK, viewer_manifest.py can be modified to use that, too. -RYaN > > Thanks once again, > > Christian Westbrook > SL: Christian Prior > christian@openmetaverse.org > > On Feb 24, 2007, at 8:52 PM, Rob Lanphier wrote: > >> Hi Ryan, >> >> Thanks for posting this. >> >> For everyone else reading this list, I'm hoping you can give your >> comments on this. One way to make it more likely that Lindens engage >> with you on your ideas is when you return the favor. >> >> Comments inline: >> >> On 2/22/07 6:49 PM, Ryan Williams wrote: >>> This seems like a great time to interject about an installer packaging >>> script I'm introducing into the next release. >>> >>> The short story is that building an installer will be one step -- >>> running a Python script. I don't know how much of our installer-making >>> code has been released, but since the .nsi wasn't, probably "not much". >>> >> Ooops. That certainly wasn't by design. How does one go about building >> the installer? I'm assuming it's just a different build target. >> >> Has anyone actually tried to build an installer to date? >>> Either way, with the next source release the installer-making >>> capabilities should be fully operational. >>> >> Cool! Let me know which branch you checked your stuff into. Whether or >> not these changes make it into the very next release depends greatly on >> which branch it gets into. Certainly, though, "soon" is a correct >> answer. >>> I provided documentation for the file here: >>> https://wiki.secondlife.com/wiki/Viewer_Manifest >>> >>> I'm certainly interested in discussion about the design and >>> implementation of the script. Of course, not much discussion can happen >>> until everyone see the code, but I just wanted to give a heads-up. >>> >> There seems to be plenty there for discussion, actually. >> >> One question that I have (because I know I'll get asked this down the >> road)...is there existing technology that does this same function that >> isn't too burdensome to switch to? This is a question for everyone, not >> just Ryan. I ask this sincerely, because even though I know this >> problem has been tackled a gazillion times, I also know that the >> solutions out there are often difficult to extract from the projects >> that created them. >> >> Just to narrow the scope of what would be considered overlapping >> technology, the idea is that this Python script creates a NSIS installer >> on Windows, a .dmg on Mac, and a tarball on Linux, right? Since >> switching installer technologies (at least on Windows and Mac...on >> Linux, something like Autopackage would be kinda cool) is probably >> harder than writing a simple python wrapper from scratch, any viable >> competing technology would need to be able to create an identical >> installer, and have to have the same simplicity of being just a Python >> script (or /maybe/ Perl). >> >> I wasn't able to find anything. If this is truly unique, one thing that >> would be very cool to see is someone take the ball and run with it. >> We're not exactly in the cross-platform installer business, and this >> seems like a problem that a lot of folks have (see >> http://www.wxwidgets.org/wiki/index.php/Installers ). If there's >> someone out there looking to form their own little independent open >> source project, this might prove to be a great starting point (assuming >> Ryan hasn't grown too attached to it just yet). I could see this either >> taking on a life of its own, or perhaps being incorporated in a bigger >> project. >> >> One piece of feedback regarding the platform magic (e.g. derive from >> LLManifest and name your class "HP-UXManifest", and that will be >> selected for use on HP-UX) Platform isn't the only relevant variable in >> choosing which class to use. For example, down the road, we may wish to >> have Linux .rpm, Linux .deb, Linux autopackage, etc. Additionally, it >> may very well be that FreeBSD autopackage and Linux autopackage will >> share more in common than Linux .rpm and Linux autopackage. So, >> building out the class tree based exclusively on platform may not be the >> best thing. >> >> Rob >> >> >> _______________________________________________ >> Click here to unsubscribe or manage your list subscription: >> https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From dale at daleglass.net Tue Feb 27 19:22:36 2007 From: dale at daleglass.net (Dale Glass) Date: Tue Feb 27 19:22:55 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: References: <20070225011052.546DD41AFCA@stupor.lindenlab.com> <200702280055.01446.dale@daleglass.net> Message-ID: <200702280422.45669.dale@daleglass.net> ? ????????? ?? 28 ??????? 2007 01:40 Argent Stonecutter ???????(a): > Because I'm looking at making this easy to use for the kind of people > I find myself helping with LSL scripting on a regular basis. But by trying to make it too simple you'll very possibly end up complicating it. IMO, simple things far too often end up as a complicated mess when there is a limitation and it has to be worked around in some strange way. I also thought you wanted to implement plugins in this way, by doing it all through a socket. > Fair enough. But the format for the simple case needs to be simpler > than XML. I think XML comes quite nicely here, IMO. After all this is a moving codebase we don't have control of. Tomorrow a new message type could appear, and you'll need the protocol to deal with that sort of thing gracefully. And by then you're half the way to reinventing XML. Of course, there are alternatives (YAML for example), but it all seems to reduce to the same thing: ability to represent nested structures, possibility of adding extra data without breaking the parser, dealing with delimiters and unicode, etc. Might as well use XML since the parser is already in the client. > Um, the vehicle movements in SL are controlled by the linear and > rotational motors, the user's control inputs aren't meaningful to the > client at all... they're passed to the script which changes the motor > parameters. There's nothing to base client-side prediction on... for > aircraft, at least, the only controls that are near universal are > left and right and how they behave differs from one craft to another. Hm, ok, that was a bad example. I was thinking that something could be predicted based on the vehicle's params, but I guess not. Anyway, you still can do prediction for the avatar, so I still think sending keypresses would be the better way. Will work better if you want to control the avatar, and doesn't need a script to support it. > What does your avatar list have to do with this? I'm talking about Just using it for the sake of an example > things like music player controls, local environment sensors, LSL is rather weak for this. If you want stats, just get them from the client itself, which gets a whole lot more, and you don't even need to request anything extra. > What I generally do is something like this: > > If the message starts with a pound sign, it's followed by a byte sounds 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/20070228/d8069331/attachment.pgp From tshephard at gmail.com Tue Feb 27 20:03:42 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 20:03:45 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <45E4BE4F.5000508@wsu.edu> References: <45E46B21.5090700@lindenlab.com> <3b19a500702271152o2b8da98bicebd7929e608a022@mail.gmail.com> <45E49496.7080204@wsu.edu> <3b19a500702271258s1999d164r1adf4d0e2adce307@mail.gmail.com> <45E4BE4F.5000508@wsu.edu> Message-ID: <3b19a500702272003o60a218a7wdbcc0a7ed4a1c263@mail.gmail.com> > If a plugin is utilizing something that no longer exists in a new version, My experience tells me that the probability that widgets will not be available in an upgrade is likely to be pretty low. I'd be willing to take that chance :) > Aren't we having a dialog right now? > I guess there are varying shades of what that means. From truxpin at adsl-209-233-23-82.dsl.snfc21.pacbell.net Tue Feb 27 20:14:17 2007 From: truxpin at adsl-209-233-23-82.dsl.snfc21.pacbell.net (truxpin@adsl-209-233-23-82.dsl.snfc21.pacbell.net) Date: Tue Feb 27 20:09:51 2007 Subject: [sldev] Ubuntu Runtime Error SDL Message-ID: <200702280414.l1S4EHp8019334@adsl-209-233-23-82.dsl.snfc21.pacbell.net> Client built on Linux Ubuntu Dapper-Drake (without llmozlib) has start-up failure trying to create window. Pertinent messages: ..... 2007-02-28T03:50:27Z INFO: createContext, fullscreen=0 size=800x600 2007-02-28T03:50:28Z INFO: createContext: Compiled against SDL 1.2.5 2007-02-28T03:50:28Z INFO: createContext: Running against SDL 1.2.11 2007-02-28T03:50:28Z INFO: createContext: creating window 800x600x32 2007-02-28T03:50:28Z WARNING: createContext: window creation failure. SDL: Couldn't find matching GLX visual 2007-02-28T03:50:28Z INFO: destroyContext begins ...... Same error running from build dir, or unpacked tarball. I get the error even if X display is set to 800x600. Suggestions? Fremont Cunningham From david at fries.net Tue Feb 27 21:00:24 2007 From: david at fries.net (David Fries) Date: Tue Feb 27 21:00:52 2007 Subject: [sldev] Ubuntu Runtime Error SDL In-Reply-To: <200702280414.l1S4EHp8019334@adsl-209-233-23-82.dsl.snfc21.pacbell.net> References: <200702280414.l1S4EHp8019334@adsl-209-233-23-82.dsl.snfc21.pacbell.net> Message-ID: <20070228050023.GA1000@spacedout.fries.net> What graphics card do you have? Is your display using hardware OpenGL acceleration? Second Life is setup to only try a fixed number of OpenGL visuals. The default is a 24 bit depth buffer. I've include a patch that tries a 16 bit depth buffer if the initial OpenGL context fails. Let me know if it helps. If it doesn't help post the visuals of glxinfo for your display. On Tue, Feb 27, 2007 at 08:14:17PM -0800, truxpin@adsl-209-233-23-82.dsl.snfc21.pacbell.net wrote: > > Client built on Linux Ubuntu Dapper-Drake (without llmozlib) has start-up > failure trying to create window. Pertinent messages: > ..... > 2007-02-28T03:50:27Z INFO: createContext, fullscreen=0 size=800x600 > 2007-02-28T03:50:28Z INFO: createContext: Compiled against SDL 1.2.5 > 2007-02-28T03:50:28Z INFO: createContext: Running against SDL 1.2.11 > 2007-02-28T03:50:28Z INFO: createContext: creating window 800x600x32 > 2007-02-28T03:50:28Z WARNING: createContext: window creation failure. SDL: > Couldn't find matching GLX visual > 2007-02-28T03:50:28Z INFO: destroyContext begins ...... > > Same error running from build dir, or unpacked tarball. I get the error even > if X display is set to 800x600. > > Suggestions? > > Fremont Cunningham > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev -- David Fries http://fries.net/~david/ (PGP encryption key available) -------------- next part -------------- Index: llwindowsdl.cpp =================================================================== RCS file: /home/david/src/.cvs/programming/SecondLife/linden/indra/llwindow/llwindowsdl.cpp,v retrieving revision 1.1 diff -u -r1.1 llwindowsdl.cpp --- llwindowsdl.cpp 28 Feb 2007 04:43:12 -0000 1.1 +++ llwindowsdl.cpp 28 Feb 2007 04:52:45 -0000 @@ -393,6 +393,13 @@ } mWindow = SDL_SetVideoMode(width, height, bits, sdlflags | SDL_FULLSCREEN); + if (!mWindow) + { + llwarns << "createContext: window creation failure. SDL: " << SDL_GetError() << llendl; + llwarns << "createContext: Trying again with 16 bit depth buffer" << llendl; + SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16); + mWindow = SDL_SetVideoMode(width, height, bits, sdlflags); + } if (mWindow) { @@ -435,6 +442,13 @@ llinfos << "createContext: creating window " << width << "x" << height << "x" << bits << llendl; mWindow = SDL_SetVideoMode(width, height, bits, sdlflags); + if (!mWindow) + { + llwarns << "createContext: window creation failure. SDL: " << SDL_GetError() << llendl; + llwarns << "createContext: Trying again with 16 bit depth buffer" << llendl; + SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 16); + mWindow = SDL_SetVideoMode(width, height, bits, sdlflags); + } if (!mWindow) { From jhurliman at wsu.edu Tue Feb 27 22:41:11 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Tue Feb 27 22:41:20 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <3b19a500702272003o60a218a7wdbcc0a7ed4a1c263@mail.gmail.com> References: <45E46B21.5090700@lindenlab.com> <3b19a500702271152o2b8da98bicebd7929e608a022@mail.gmail.com> <45E49496.7080204@wsu.edu> <3b19a500702271258s1999d164r1adf4d0e2adce307@mail.gmail.com> <45E4BE4F.5000508@wsu.edu> <3b19a500702272003o60a218a7wdbcc0a7ed4a1c263@mail.gmail.com> Message-ID: <45E52407.2000303@wsu.edu> Tim Shephard wrote: > >> Aren't we having a dialog right now? >> > > I guess there are varying shades of what that means. Well by all means, let's upgrade this dialog to a higher caliber then. What does that entail? From tshephard at gmail.com Tue Feb 27 22:47:28 2007 From: tshephard at gmail.com (Tim Shephard) Date: Tue Feb 27 22:47:32 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <45E52407.2000303@wsu.edu> References: <45E46B21.5090700@lindenlab.com> <3b19a500702271152o2b8da98bicebd7929e608a022@mail.gmail.com> <45E49496.7080204@wsu.edu> <3b19a500702271258s1999d164r1adf4d0e2adce307@mail.gmail.com> <45E4BE4F.5000508@wsu.edu> <3b19a500702272003o60a218a7wdbcc0a7ed4a1c263@mail.gmail.com> <45E52407.2000303@wsu.edu> Message-ID: <3b19a500702272247v1fce45fbn8923fd441530240c@mail.gmail.com> On 2/27/07, John Hurliman wrote: > Tim Shephard wrote: > > > >> Aren't we having a dialog right now? > >> > > > > I guess there are varying shades of what that means. > > Well by all means, let's upgrade this dialog to a higher caliber then. > What does that entail? Oh, I don't think anyone here is saying the dialogue is low caliber .. the problem definitely is not quality. But, sure, let's start up some questions we have for lindens. I'll start a new thread. From robla at lindenlab.com Tue Feb 27 23:55:38 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Tue Feb 27 23:55:57 2007 Subject: [sldev] Source release: beta 1.13.4.3 Message-ID: <45E5357A.6050609@lindenlab.com> Hi everyone, New source code is available for the beta client that was released Monday is available: https://wiki.secondlife.com/wiki/Source_archive Most of the release notes are here: http://blog.secondlife.com/2007/02/26/preview-of-second-life-11343-up-on-the-beta-test-grid/ To be very clear: the 1.13.4.3 viewer will only work correctly with the aditi grid. You really shouldn't try to use it with the main grid (agni); it won't fail right away, but many features won't work (e.g. crossing region boundaries), and it'll be generally unpredictable as it wasn't designed to interoperate with the current production grid. The first big batch of patches from the development community was accepted into this source code. One thing that I only thought to check as I composed this mail was to make sure that the contributions.txt file was added. Turns out it wasn't (doh!). So, I've included it below, and promise it'll be in the next beta source release (I just checked in the change that will hopefully ensure it happens). Please let me know if there are any omissions or corrections to make. Note, we've incorporated more patches than this in the as yet unreleased code (landing release TBD), but hopefully, this is an accurate picture of what has been released so far. Rob --- Linden Lab would like to acknowledge source code contributions from the following residents. The Second Life resident name is given below, along with the issue identifier corresponding to the patches we've received from them. To see more about these contributions, visit http://jira.secondlife.com/ , and enter the issue identifier. Alissa Sabre - VWR-81, VWR-83 blino Nakamura - VWR-17 Drewan Keats - VWR-28 Dylan Haskell - VWR-72 Eddy Stryker - VWR-15, VWR-23 Joghert LeSabre - VWR-64 Kage Pixel - VWR-11 Kunnis Basiat - VWR-82 Paul Churchill - VWR-20 Paula Innis - VWR-30 Peekay Semyorka - VWR-7, VWR-19, VWR-49 SpacedOut Frye - VWR-57 Strife Onizuka - VWR-74, VWR-85, SVC-9 Zipherius Turas - VWR-76, VWR-77 -------------- 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/20070227/e347590c/signature.pgp From gsharma at adroit-inc.com Wed Feb 28 01:07:05 2007 From: gsharma at adroit-inc.com (Gaurav Sharma) Date: Wed Feb 28 01:03:40 2007 Subject: [sldev] Unit Test Harness Message-ID: <007f01c75b17$d32bd8b0$2201a8c0@abs1ffhkdl6vy1> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: unittest.patch Type: application/octet-stream Size: 111269 bytes Desc: not available Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070228/2ee17d5c/unittest-0001.obj From secret.argent at gmail.com Wed Feb 28 06:31:48 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Feb 28 06:31:54 2007 Subject: [sldev] Prim metadata formats was Re: LSL initiated Prim metadata... In-Reply-To: <45E4D72F.5050605@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> <45E4D72F.5050605@gmail.com> Message-ID: <3D25FDC8-BC1B-4AD9-BA63-6638FE9E9C88@gmail.com> On Feb 27, 2007, at 7:13 PM, Jason Giglio wrote: > In case you weren't paying attention (and it appears you weren't), I wasn't responding to your proposal here, I was responding to Jacek's proposal. However, I do think you're missing one point to my suggestion of using a list, and that is that both ends of the system need structured data. > "the script" doesn't encode the data under my proposal, except > during development. After development is complete the new built-in > LL-provided LSL functions might indeed take a list, which it will > then convert into the proper string. In other words you're serializing the data as a string. Linden Labs already has a mechanism for serializing prim attributes for storage and transmission to the client, and it's a strongly typed format that's bidirectionally convertible to an LSL list. The "new built-in LL-provided LSL functions" should convert the prim parameters into that format, not a string, and the client-side code should accept that format. To really use this to prototype code that's going to be used unchanged by Linden Labs, the call should either be: llSetExperimentalAttribute(list attribute); Where attribute is a list of type-value pairs, describing the serialized format for the attribute, eg: [ATTR_U8,taste,ATTR_F32,angle,ATTR_F32,wobble]. Or: llSetExperimentalAttribute(string format, list attribute); Where format is a string like "U8,F32,F32" that describes the format of the attribute. That way when the capability goes into production the prim data will be in the right format, and the client code will already be seeing and interpreting the data in Linden Labs' preferred format. Note that I am not re-introducing an identifier here. This message is not about Jacek's proposal, and to avoid further crossed wires I'll change the subject line. From secret.argent at gmail.com Wed Feb 28 06:56:49 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Feb 28 06:56:58 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <200702280422.45669.dale@daleglass.net> References: <20070225011052.546DD41AFCA@stupor.lindenlab.com> <200702280055.01446.dale@daleglass.net> <200702280422.45669.dale@daleglass.net> Message-ID: <3B72C460-DC48-4C3F-8DE9-3CBDE42E15F9@gmail.com> On Feb 27, 2007, at 9:22 PM, Dale Glass wrote: > I also thought you wanted to implement plugins in this way, by > doing it all > through a socket. Not really. For a lot of plugins the extra trip through the kernel and network stack is a lot of overhead, particularly for transformation plugins and things like Jesse's prim attributes, or for your floater for that matter if it's polling for avatar data. What I'm looking at here is communication between applications on the client's computer and applications running in LSL. This is a subset where the latency and overhead of a socket is lost in the noise, and where there's already a lot of people in SL who are doing similar things between objects using chat. I think a lot of these people would be able to effectively use a simple system like I'm talking about, but would be overwhelmed by XML. Having a socket that applications can connect to that maps into chat doesn't preclude having a more complex and powerful protocol running over the same connection or over a related link. Consider this: @32,throttle up Say "throttle up" on channel 32. All chat messages must be preceded by "@" throttle up Say "throttle up" on channel 32. All single-line XML messages must begin with "<". #66 throttle up Say "throttle up" on channel 32. All multi-line XML messages are preceded by "#" followed by the number of bytes in the message and a newline. Other meta-control messages could include "register-id" for the $VwrComm$ response, or something to request a feed of all chat, all llOwnerSay messages, all llInstantMessage messages, all user-user IMs, and so on. > Anyway, you still can do prediction for the avatar, so I still > think sending > keypresses would be the better way. Will work better if you want to > control > the avatar, and doesn't need a script to support it. Maybe. I'd like to have more control than that over cyberflight, though. >> things like music player controls, local environment sensors, > LSL is rather weak for this. If you want stats, just get them from > the client > itself, which gets a whole lot more, and you don't even need to > request > anything extra. Heh, you read that exactly the opposite way that I meant it. Sorry, let me clarify: I'm talking about controls in your HUD to make iTunes do stuff, or to tell you what your local outside temperature is, or how much mail you have, so that you can get the kind of info you put in your desktop / dashboard / icon-tray / panel / insert-your- preferred-desktop-plugin-here when you have SL in full screen mode. From secret.argent at gmail.com Wed Feb 28 07:10:03 2007 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed Feb 28 07:10:09 2007 Subject: [sldev] Patches In-Reply-To: <20070228090343.D805641AF7B@stupor.lindenlab.com> References: <20070228090343.D805641AF7B@stupor.lindenlab.com> Message-ID: <631180BD-9F83-4BBF-9D2D-217E0DC4009C@gmail.com> > Linden Lab would like to acknowledge source code contributions from > the > following residents. The Second Life resident name is given below, > along with the issue identifier corresponding to the patches we've > received from them. To see more about these contributions, visit > http://jira.secondlife.com/ , and enter the issue identifier. I assume these are only patches have all been incorporated into the production viewer, then, since I don't see (VWR-68) on the list. Can you say which release of the viewer each of these patches are (or will be) in? From jhurliman at wsu.edu Wed Feb 28 08:40:45 2007 From: jhurliman at wsu.edu (John Hurliman) Date: Wed Feb 28 08:41:01 2007 Subject: [sldev] Unit Test Harness In-Reply-To: <007f01c75b17$d32bd8b0$2201a8c0@abs1ffhkdl6vy1> References: <007f01c75b17$d32bd8b0$2201a8c0@abs1ffhkdl6vy1> Message-ID: <45E5B08D.2080406@wsu.edu> Gaurav Sharma wrote: > > > Please let us know if there are specific classes that you would like us to > prioritize. > > Thanks, > Gaurav Sharma > Software Development Engineer > Adroit Business Solutions (P) Ltd. > India > > I've had the most problems with the LLJoint class, specifically with the use of STL iterators in it. The Cal3D export crashes most of the time, I can see about submitting a patch that enables it in the client so you can try it out and see. John Hurliman jhurliman@wsu.edu From tshephard at gmail.com Wed Feb 28 09:10:53 2007 From: tshephard at gmail.com (Tim Shephard) Date: Wed Feb 28 09:10:56 2007 Subject: [sldev] Unit Test Harness In-Reply-To: <45E5B08D.2080406@wsu.edu> References: <007f01c75b17$d32bd8b0$2201a8c0@abs1ffhkdl6vy1> <45E5B08D.2080406@wsu.edu> Message-ID: <3b19a500702280910s18119988sddaee021f783de0b@mail.gmail.com> Cool unit testing patch, Gaurav. Just a quick question, can someone give me an idea of who's working for Linden Lab and who isn't here? I'm getting kinda confused... On 2/28/07, John Hurliman wrote: > Gaurav Sharma wrote: > > > > > > Please let us know if there are specific classes that you would like us to > > prioritize. > > > > Thanks, > > Gaurav Sharma > > Software Development Engineer > > Adroit Business Solutions (P) Ltd. > > India > > > > > > I've had the most problems with the LLJoint class, specifically with the > use of STL iterators in it. The Cal3D export crashes most of the time, I > can see about submitting a patch that enables it in the client so you > can try it out and see. > > John Hurliman > jhurliman@wsu.edu > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > From gigstaggart at gmail.com Wed Feb 28 09:23:50 2007 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed Feb 28 09:23:46 2007 Subject: [sldev] Prim metadata formats was Re: LSL initiated Prim metadata... In-Reply-To: <3D25FDC8-BC1B-4AD9-BA63-6638FE9E9C88@gmail.com> References: <20070226085212.8818941B02D@stupor.lindenlab.com> <9B7FDDD3-E966-49FF-9955-86E9B064BFE0@gmail.com> <45E46515.4060608@gmail.com> <067B8698-36DB-4891-8A77-1857D3DE8E59@gmail.com> <45E485BB.7030402@gmail.com> <45E4A720.7010001@gmail.com> <45E4D72F.5050605@gmail.com> <3D25FDC8-BC1B-4AD9-BA63-6638FE9E9C88@gmail.com> Message-ID: <45E5BAA6.8060108@gmail.com> Argent Stonecutter wrote: > llSetExperimentalAttribute(list attribute); > > Where attribute is a list of type-value pairs, describing the serialized > format for the attribute, eg: > [ATTR_U8,taste,ATTR_F32,angle,ATTR_F32,wobble]. > > Or: > > llSetExperimentalAttribute(string format, list attribute); > > Where format is a string like "U8,F32,F32" that describes the format of > the attribute. > > That way when the capability goes into production the prim data will be > in the right format, and the client code will already be seeing and > interpreting the data in Linden Labs' preferred format. That's acceptable, I guess. LSL can't enforce type checking on those types though, so I don't see that it gains much of anything. -Jason From robla at lindenlab.com Wed Feb 28 09:29:40 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Feb 28 09:29:57 2007 Subject: [sldev] Unit Test Harness In-Reply-To: <3b19a500702280910s18119988sddaee021f783de0b@mail.gmail.com> References: <007f01c75b17$d32bd8b0$2201a8c0@abs1ffhkdl6vy1> <45E5B08D.2080406@wsu.edu> <3b19a500702280910s18119988sddaee021f783de0b@mail.gmail.com> Message-ID: <45E5BC04.2080604@lindenlab.com> On 2/28/07 9:10 AM, Tim Shephard wrote: > Cool unit testing patch, Gaurav. > > Just a quick question, can someone give me an idea of who's working > for Linden Lab and who isn't here? I'm getting kinda confused... We contracted Adroit to help us out with some of the prerelease security auditing as well as now helping out with unit tests. Everyone posting to this list has been up-front about their affiliation with Linden Lab, as near as I know. Rob > On 2/28/07, John Hurliman wrote: >> Gaurav Sharma wrote: >> > >> > >> > Please let us know if there are specific classes that you would >> like us to >> > prioritize. >> > >> > Thanks, >> > Gaurav Sharma >> > Software Development Engineer >> > Adroit Business Solutions (P) Ltd. >> > India >> > >> > >> >> I've had the most problems with the LLJoint class, specifically with the >> use of STL iterators in it. The Cal3D export crashes most of the time, I >> can see about submitting a patch that enables it in the client so you >> can try it out and see. >> >> John Hurliman >> jhurliman@wsu.edu >> _______________________________________________ >> 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/20070228/9fce0adb/signature.pgp From tshephard at gmail.com Wed Feb 28 09:38:27 2007 From: tshephard at gmail.com (Tim Shephard) Date: Wed Feb 28 09:38:29 2007 Subject: [sldev] Unit Test Harness In-Reply-To: <45E5BC04.2080604@lindenlab.com> References: <007f01c75b17$d32bd8b0$2201a8c0@abs1ffhkdl6vy1> <45E5B08D.2080406@wsu.edu> <3b19a500702280910s18119988sddaee021f783de0b@mail.gmail.com> <45E5BC04.2080604@lindenlab.com> Message-ID: <3b19a500702280938u643a3dbax1ab1280775ebac83@mail.gmail.com> ahh, gotcha. A part of the confusion was that I didn't get Gaurav's original post, just John's, so the lack of context was a bit puzzling. Good to see this sort of thing getting done. It's very critical to any successful software project. Cheers, Tim. On 2/28/07, Rob Lanphier wrote: > On 2/28/07 9:10 AM, Tim Shephard wrote: > > Cool unit testing patch, Gaurav. > > > > Just a quick question, can someone give me an idea of who's working > > for Linden Lab and who isn't here? I'm getting kinda confused... > We contracted Adroit to help us out with some of the prerelease security > auditing as well as now helping out with unit tests. > > Everyone posting to this list has been up-front about their affiliation > with Linden Lab, as near as I know. > > Rob > > On 2/28/07, John Hurliman wrote: > >> Gaurav Sharma wrote: > >> > > >> > > >> > Please let us know if there are specific classes that you would > >> like us to > >> > prioritize. > >> > > >> > Thanks, > >> > Gaurav Sharma > >> > Software Development Engineer > >> > Adroit Business Solutions (P) Ltd. > >> > India > >> > > >> > > >> > >> I've had the most problems with the LLJoint class, specifically with the > >> use of STL iterators in it. The Cal3D export crashes most of the time, I > >> can see about submitting a patch that enables it in the client so you > >> can try it out and see. > >> > >> John Hurliman > >> jhurliman@wsu.edu > >> _______________________________________________ > >> 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 christian at electricsheepcompany.com Wed Feb 28 12:23:03 2007 From: christian at electricsheepcompany.com (Christian Westbrook) Date: Wed Feb 28 12:23:09 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: References: <45E46B21.5090700@lindenlab.com> Message-ID: <735A2E53-ACFB-4A24-9487-F63AB24BF810@electricsheepcompany.com> > Nope! The current First Look is just for texture pipeline > improvements. > > -RYaN Richard, Thanks for the heads up on LLFloater and the mutability of the code in general. I can't deny this is a little alarming but is certainly worth hearing, yet I think it sheds light on a larger issue, also illuminated somewhat by the discussion yesterday about attempting to protect plugin developers from changes via abstraction: it's very difficult (some might say impossible) to develop meaningful code on a codebase that is changing with only vague hints as to how it will be changing. I understand and appreciate that LL is not [yet?] an organization that has completely accepted open source development, but firmly believe that there is a happier medium between a closed, proprietary software company and an open source platform -- happier for LL, the community, and third party/independent developers -- to which LL must move for any of these discussions about plugins, etc., to bear fruit. It's been a full month since the last code drop of the "real" viewer source code. First Look has been pushed out with some regularity throughout February, but was first done so with the caveat that it was an experimental branch that should not be incorporated into our trunk. It sure seems like all LL devs are working on FL -- when did this change? Without any transparency, this feels like a simple bait-and- switch. Please consider this a call to the LL dev team to come out and play! Even cognizant that some features like lip sync/VoIP will remain in- house only, there is a huge disparity between dropping code (at any interval) and developing *with* the community. How can we all help push the metaversal envelope without compromising LL's business plan? Regards, Christian On Feb 27, 2007, at 12:58 PM, Richard Nelson wrote: > Just jumping in here to comment on LLFloater stability. In > general, we can't guarantee that our UI class interfaces will > remain stable. For example, we recently changed LLFloaters and > LLPanels to implement LLUICtrl in order to sanitize our keyboard > focus model and let them participate fully in focus management > (LLView's can't delegate keyboard focus, they can only contain > LLUICtrls, or widgets). We've also made many changes in the move > over to XML-driven UI. These changes are not complete, and we will > continue to tease out architectural abstractions and refactor our > UI code based on use cases as they arise. > > That said, most changes can be considered extensions to existing > functionality, implemented in the base class, with no extra burden > on derived classes. There are still large architectural decisions > to be made, though. > > Richard > > > On Tue, 27 Feb 2007 09:32:17 -0800, Rob Lanphier > wrote: > >> >>>> Basically there would be an instance of LLFloaterPluginProxy for >>>> every >>>> plugin floater created. >>> >>> I initially rejected the derivation idea, as a class derived from >>> the >>> floater class meant that this class would change any time the >>> floater did. >> >> OK, that concern makes sense. However, looking through the code, >> llFloater seems likely to be very resistant to change. If it does >> change, it would likely impact a very significant amount of code and >> therefore would only occur when absolutely necessary. >> >> Perhaps a linden can comment.. >> > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev > > From rdw at lindenlab.com Wed Feb 28 12:32:31 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Wed Feb 28 12:33:08 2007 Subject: [sldev] Source release: beta 1.13.4.3 In-Reply-To: <45E5357A.6050609@lindenlab.com> References: <45E5357A.6050609@lindenlab.com> Message-ID: <45E5E6DF.9010503@lindenlab.com> Rob Lanphier wrote: > Hi everyone, > > New source code is available for the beta client that was released > Monday is available: > https://wiki.secondlife.com/wiki/Source_archive > > Most of the release notes are here: > http://blog.secondlife.com/2007/02/26/preview-of-second-life-11343-up-on-the-beta-test-grid/ ....and this release contains viewer_manifest.py. Nice! -RYaN From tshephard at gmail.com Wed Feb 28 12:33:23 2007 From: tshephard at gmail.com (Tim Shephard) Date: Wed Feb 28 12:33:25 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <735A2E53-ACFB-4A24-9487-F63AB24BF810@electricsheepcompany.com> References: <45E46B21.5090700@lindenlab.com> <735A2E53-ACFB-4A24-9487-F63AB24BF810@electricsheepcompany.com> Message-ID: <3b19a500702281233r4554e49ewba405457df200383@mail.gmail.com> Thanks Christian. Hopefully, your comments won't go unanswered. To add to this, I have heard rumblings that LL doesn't want to merge in auto loading / automated dynamic updating of Plugins. This would sadden me somewhat if it were true, as auto upgrading is a critical feature to avoid having to do costly support. Keeping prices low means automation everywhere... having 10,000 users surfing around trying to upgrade and then emailing support when they get confused is a non starter. So is this a reasonable statement, or is this just mistaken speculation? Would you prefer not merge in that type of code? We definitely need direction on these sorts of things. Cheers, Tim. From rdw at lindenlab.com Wed Feb 28 13:00:29 2007 From: rdw at lindenlab.com (Ryan Williams) Date: Wed Feb 28 13:01:10 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <735A2E53-ACFB-4A24-9487-F63AB24BF810@electricsheepcompany.com> References: <45E46B21.5090700@lindenlab.com> <735A2E53-ACFB-4A24-9487-F63AB24BF810@electricsheepcompany.com> Message-ID: <45E5ED6D.7070801@lindenlab.com> Christian Westbrook wrote: >> Nope! The current First Look is just for texture pipeline improvements. >> >> -RYaN > > Richard, > > Thanks for the heads up on LLFloater and the mutability of the code > in general. I can't deny this is a little alarming but is certainly > worth hearing, yet I think it sheds light on a larger issue, also > illuminated somewhat by the discussion yesterday about attempting to > protect plugin developers from changes via abstraction: it's very > difficult (some might say impossible) to develop meaningful code on > a codebase that is changing with only vague hints as to how it will > be changing. I understand and appreciate that LL is not [yet?] an > organization that has completely accepted open source development, > but firmly believe that there is a happier medium between a closed, > proprietary software company and an open source platform -- happier > for LL, the community, and third party/independent developers -- to > which LL must move for any of these discussions about plugins, etc., > to bear fruit. Absolutely. I think robla has been pretty consistent about this being a gradual process. I mean, I didn't read this list really until the past few weeks, and more and more devs are starting to get involved. It's individual choice whether someone decides to participate in sldev or not -- LL is not a monolithic organization. > It's been a full month since the last code drop of the "real" viewer > source code. First Look has been pushed out with some regularity > throughout February, but was first done so with the caveat that it was an > experimental branch that should not be incorporated into our trunk. > It sure seems like all LL devs are working on FL -- when did this > change? Without any transparency, this feels like a simple bait-and- > switch. Only a few people are working on it, though the project, like all projects it seems, is slowly extending its tentacles into everything else. I think it will be ready for release once everyone in the company has touched one line of code for it. :-) But seriously, not all developers are working on it, though we do expect it to be merged with the trunk once it's ready. > Please consider this a call to the LL dev team to come out and play! > Even cognizant that some features like lip sync/VoIP will remain in- > house only, there is a huge disparity between dropping code (at any > interval) and developing *with* the community. How can we all help > push the metaversal envelope without compromising LL's business plan? Well, I definitely feel that a major step will be achieved when we all develop against a world-viewable source repository. I don't think it's a business plan thing, I think it's just a technical matter of communicating code. Example: I sent out my announcement of viewer_manifest.py and it was sort of lame because no one could see the code until today. I guess I could have sent an attachment, but that's awkward. However, a public LL scm won't solve the problem of the codebase changing underneath you, it will just close the loop quicker. I don't think any set of programmers can work on the same project for any length of time without stepping on each other's toes or rearchitecting the floor out from under each other. To alleviate this, I think the most important thing code-wise is keeping things as modular as possible. The current viewer is pretty bad in this regard, but there's no reason that new code can't be good about it. -RYaN From richard at lindenlab.com Wed Feb 28 13:33:14 2007 From: richard at lindenlab.com (Richard Nelson) Date: Wed Feb 28 13:33:17 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: <45E5ED6D.7070801@lindenlab.com> References: <45E46B21.5090700@lindenlab.com> <735A2E53-ACFB-4A24-9487-F63AB24BF810@electricsheepcompany.com> <45E5ED6D.7070801@lindenlab.com> Message-ID: What Ryan said...:) Specifically, my best hope is that we can collaboratively decide where the extensibility points are in the architecture. I just don't think the LLFloater class is it, but I'm willing to be proven wrong. I believe we need to be careful in picking our extensibility points. Build in too few abstraction layers and the code is brittle and non-extensible. Too many, and you get COMtamination. Right now, I'd say we were on the side of too few. Over the past months, we have gradually introduced abstraction at key points in the architecture. Data abstraction is handled via LLSD and UI layout will eventually be entirely handled by our XML files. One question we haven't fully answered is how the data "model" and ui "view" will talk to each other. Others use data binding languages such as XBL/XAML combined with scripting languages such as ECMAscript. We currently use C++ classes that derive from LLPanel and LLFloater...probably not the best choice for the long term. Whatever we settle on will not only affect the customization of our UI, but most likely any plugin system as well. There are many other architectural decisions to be made, such as how do we multi-thread the UI and have it update asynchronously with respect to the renderer framerate? It would also be nice to cache UI elements into textures and perform lazy updates instead of drawing into the framebuffer every frame. How much do we integrate HTML into our UI or base our UI on HTML? I can't give you a long-term schedule for these features and design decisions, because I have none. This is not even an official list, but more of my perception of the general consensus. We are hiring like mad, and the open source community can contribute significantly here, so let's figure this out. Richard On Wed, 28 Feb 2007 13:00:29 -0800, Ryan Williams wrote: > To alleviate this, I think the most important thing code-wise is keeping > things as modular as possible. The current viewer is pretty bad in this > regard, but there's no reason that new code can't be good about it. > > -RYaN > From tshephard at gmail.com Wed Feb 28 14:07:49 2007 From: tshephard at gmail.com (Tim Shephard) Date: Wed Feb 28 14:07:52 2007 Subject: [sldev] Plugin system - first code drop In-Reply-To: References: <45E46B21.5090700@lindenlab.com> <735A2E53-ACFB-4A24-9487-F63AB24BF810@electricsheepcompany.com> <45E5ED6D.7070801@lindenlab.com> Message-ID: <3b19a500702281407r426963d2oafc102bf0637a334@mail.gmail.com> > Others use data binding languages such as XBL/XAML combined with scripting languages such as ECMAscript. Question: Any concerns about portability issues around XBL/XAML? Have strides been made to provide support for the other two platforms? What do you think about XUL? From robla at lindenlab.com Wed Feb 28 15:30:02 2007 From: robla at lindenlab.com (Rob Lanphier) Date: Wed Feb 28 15:30:29 2007 Subject: [sldev] About Linden Lab has not "completely accepted open source development" In-Reply-To: <735A2E53-ACFB-4A24-9487-F63AB24BF810@electricsheepcompany.com> References: <45E46B21.5090700@lindenlab.com> <735A2E53-ACFB-4A24-9487-F63AB24BF810@electricsheepcompany.com> Message-ID: <45E6107A.3080207@lindenlab.com> Christian, I take extremely strong issue with the statement "LL is not [yet?] an organization that has completely accepted open source development". We're an organization who is working out the kinks in the process. We're very pleasantly surprised with how quickly people have been able to get up to speed with the code, but as many non-coding customers have pointed out, we have many very important things to work on that have nothing to do with our new open source initiative. As we scale up our team to deal with the long list of challenges we face, we'll get better at collaborating with the community, in part because we'll now be hiring from a pool of people who know they'll be working for an open source company, and in part because we'll likely be hiring people who start off as community contributors. One thing that's very well established in open source culture is that it's typically a meritocracy, not a democracy. We can't listen to everyone with an email account; we have to pick and choose who we respond to. I haven't been very good at the filtering process to date, but one thing I'm going to be looking at in determining who to listen to is who is actually contributing patches and trying to build a relationship with our dev team in a valuable way (with code that fixes problems). How many patches have you contributed? Looking through Jira, I don't see a bug report, let alone anything with a patch attached. This codebase took years and millions of dollars to build, and we've put it out under an open source license at time when we didn't have to. While we realize that there's a lot of work we have to do to get things working the way we all want it to, I'm having a difficult time mustering an apology. We posted more than a patch; we posted the product. I'm not saying we're above reproach, or that we aren't grateful for the flood of patches that have come in, or that we don't want to see criticism. Just understand that we had to disrupt quite a bit of our operations just to publish the code. We're doing more, but big part of my job is to make sure this initiative is successful both in-and-of itself, /and/ more importantly, doesn't kill Linden Lab in the process. So, beyond the nudging I've done, I'm not inclined to tell our development staff "stop working on grid stability, we need plugins". Please be patient. As to the elephant in the room, which are the many outstanding legal questions on the list. Sorry, we've got very good reasons why those are taking longer than everyone would like, most of which I can't get into on this list yet. I would /love/ to resolve these issues, but not being a lawyer, I can't do it alone. What's more, these aren't strictly legal issues, some of them have pretty profound business implications that we need to explore. As we staff up in this area, we'll be able to do more here. Once again, please be patient. Sorry if I'm coming off as harsh, but as people who have worked with me a while know, I try to be a fair broker. I can very forcefully make arguments for the community within Linden Lab once I'm convinced that there's an argument to be made. I've actively encouraged more involvement by Linden Lab developers on this mailing list, and I'm emphasizing transparency right now over collaboration, because I think that's the first step. I'm trying to get them to share their priorities with you, not change their priorities to match yours. I have some half-baked ideas for making the plugin conversation go more smoothly, but I still need to sort out some loose ends. One thing that will help is for us to have contributor agreements from everyone who is contributing code and substantial ideas to the conversation (which so far, we don't). Quite frankly, I should probably advise /against/ having our developers listen to anyone who hasn't signed an agreement, since it would be really bad to come up with a design, and then have someone claim it was their idea and they didn't license it to us. Perhaps it might make sense to actually have a separate mailing list where only those who actually sign contributor agreements can post, and make it clear that mailing list postings are contributions. Rob On 2/28/07 12:23 PM, Christian Westbrook wrote: >> Nope! The current First Look is just for texture pipeline improvements. >> >> -RYaN > > Richard, > > Thanks for the heads up on LLFloater and the mutability of the code > in general. I can't deny this is a little alarming but is certainly > worth hearing, yet I think it sheds light on a larger issue, also > illuminated somewhat by the discussion yesterday about attempting to > protect plugin developers from changes via abstraction: it's very > difficult (some might say impossible) to develop meaningful code on > a codebase that is changing with only vague hints as to how it will > be changing. I understand and appreciate that LL is not [yet?] an > organization that has completely accepted open source development, > but firmly believe that there is a happier medium between a closed, > proprietary software company and an open source platform -- happier > for LL, the community, and third party/independent developers -- to > which LL must move for any of these discussions about plugins, etc., > to bear fruit. > > It's been a full month since the last code drop of the "real" viewer > source code. First Look has been pushed out with some regularity > throughout February, but was first done so with the caveat that it was an > experimental branch that should not be incorporated into our trunk. > It sure seems like all LL devs are working on FL -- when did this > change? Without any transparency, this feels like a simple bait-and- > switch. > > Please consider this a call to the LL dev team to come out and play! > Even cognizant that some features like lip sync/VoIP will remain in- > house only, there is a huge disparity between dropping code (at any > interval) and developing *with* the community. How can we all help > push the metaversal envelope without compromising LL's business plan? > > Regards, > > Christian > > On Feb 27, 2007, at 12:58 PM, Richard Nelson wrote: > >> Just jumping in here to comment on LLFloater stability. In general, >> we can't guarantee that our UI class interfaces will remain stable. >> For example, we recently changed LLFloaters and LLPanels to implement >> LLUICtrl in order to sanitize our keyboard focus model and let them >> participate fully in focus management (LLView's can't delegate >> keyboard focus, they can only contain LLUICtrls, or widgets). We've >> also made many changes in the move over to XML-driven UI. These >> changes are not complete, and we will continue to tease out >> architectural abstractions and refactor our UI code based on use >> cases as they arise. >> >> That said, most changes can be considered extensions to existing >> functionality, implemented in the base class, with no extra burden on >> derived classes. There are still large architectural decisions to be >> made, though. >> >> Richard >> >> >> On Tue, 27 Feb 2007 09:32:17 -0800, Rob Lanphier >> wrote: >> >>> >>>>> Basically there would be an instance of LLFloaterPluginProxy for >>>>> every >>>>> plugin floater created. >>>> >>>> I initially rejected the derivation idea, as a class derived from the >>>> floater class meant that this class would change any time the >>>> floater did. >>> >>> OK, that concern makes sense. However, looking through the code, >>> llFloater seems likely to be very resistant to change. If it does >>> change, it would likely impact a very significant amount of code and >>> therefore would only occur when absolutely necessary. >>> >>> Perhaps a linden can comment.. >>> >> _______________________________________________ >> 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/20070228/3ac06700/signature-0001.pgp From dale at daleglass.net Wed Feb 28 16:38:36 2007 From: dale at daleglass.net (Dale Glass) Date: Wed Feb 28 16:38:59 2007 Subject: [sldev] Generic LSL->Client Comms In-Reply-To: <3B72C460-DC48-4C3F-8DE9-3CBDE42E15F9@gmail.com> References: <20070225011052.546DD41AFCA@stupor.lindenlab.com> <200702280422.45669.dale@daleglass.net> <3B72C460-DC48-4C3F-8DE9-3CBDE42E15F9@gmail.com> Message-ID: <200703010138.43035.dale@daleglass.net> ? ????????? ?? 28 ??????? 2007 15:56 Argent Stonecutter ???????(a): > On Feb 27, 2007, at 9:22 PM, Dale Glass wrote: > > I also thought you wanted to implement plugins in this way, by > > doing it all > > through a socket. > > Not really. For a lot of plugins the extra trip through the kernel > and network stack is a lot of overhead, particularly for > transformation plugins and things like Jesse's prim attributes, or > for your floater for that matter if it's polling for avatar data. I don't really get why everybody keeps bringing up context switches and network stack overhead, when both are constant, not all that big, and getting progressively smaller as CPU speeds increase. I think that a much better argument could be made that there's going to be a significant impact from converting internal data into some format like XML, then parsing it again on the same box, when all that data could be accessed for free if the plugin was loaded into the client. Now, I still think this way of doing things is interesting. It sure is inefficient for things that would involve sending megabytes of data back and forth, but some light communication like "process this key", "start streaming", etc would be really useful. > What I'm looking at here is communication between applications on the > client's computer and applications running in LSL. This is a subset > where the latency and overhead of a socket is lost in the noise, and > where there's already a lot of people in SL who are doing similar > things between objects using chat. I think a lot of these people > would be able to effectively use a simple system like I'm talking > about, but would be overwhelmed by XML. I don't know why, XML isn't all that complicated. Granted, it's not the prettiest thing, but it's not anything all that weird either. Anybody working on something like this can be assumed to have seen at least some HTML, and if you get that, you're 90% there regarding XML. After all, you can make a simple XML protocol. There's no need to use every esoteric piece of functionality in it. > Having a socket that applications can connect to that maps into chat > doesn't preclude having a more complex and powerful protocol running > over the same connection or over a related link. Consider this: > > @32,throttle up > > Say "throttle up" on channel 32. All chat messages must be preceded > by "@" Well, here you have what I'm talking about. This is nice and simple on the surface. Now: What is the "," for? There you have a weird bit of syntax already. Will the parser handle a negative channel? How do you indicate shout or whisper? Will the parser correctly deal with unicode? Specifically, will it correctly detect characters it's looking for, while avoiding the pitfall of that a character can be both itself and a part of a multibyte UTF8 character? What if you want to send multiple lines? I have a quite strong dislike for homebrew protocols for this reason. Are you sure that a couple months later you won't have to keep adding weird hacks to keep this compatible? Such a thing would need to be properly made to deal with eventual expansions. I think PNG has a good idea in this regard: You can add new sections to it, and the section's header specifies whether handling it is necessary or not in other to display the right result. > > throttle up > > Say "throttle up" on channel 32. All single-line XML messages must > begin with "<". > > #66 > > throttle up > > > Say "throttle up" on channel 32. All multi-line XML messages are > preceded by "#" followed by the number of bytes in the message and a > newline. And now you have the problem of having to implement the same thing twice. That almost guarantees that one version will have a bug and another won't, or the functionality will slightly differ. That's bad. > Heh, you read that exactly the opposite way that I meant it. Sorry, > let me clarify: I'm talking about controls in your HUD to make iTunes > do stuff, or to tell you what your local outside temperature is, or > how much mail you have, so that you can get the kind of info you put > in your desktop / dashboard / icon-tray / panel / insert-your- > preferred-desktop-plugin-here when you have SL in full screen mode. Ahh. Ok, that makes sense. -------------- 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/20070301/1f81d83b/attachment.pgp From soft at softnoel.org Wed Feb 28 21:16:21 2007 From: soft at softnoel.org (Soft Noel) Date: Wed Feb 28 21:16:23 2007 Subject: [sldev] beta-1.13.4.3 Mac build problems Message-ID: <44413.64.81.228.9.1172726181.squirrel@webmail.softnoel.org> The current Intel Mac beta source drop doesn't work. * Packaged without two directories needed by the bundler Workaround: Modify line 479 of indra/lib/python/indra/ llmanifest.py as below so the build error lets you know where to make the missing directories. raise RuntimeError, "Path " + os.getcwd() + "/" + path + " doesn't exist" * Development configuration depends on Universal libcurl Workaround: Build AutoUpdater target in Universal build configuration * LLImageJ2COJ::decodeImpl() stomps memory Workaround: Work without valid textures by adding an "if (false)" before line 157 At the point where the viewer would previously crash on an image, we now see this in the log over and over: [ERROR] read error [INFO] tile 1 of 1 [ERROR] tcd_decode: incomplete bistream [INFO] - tiers-1 took 0.043426 s [INFO] - dwt took 0.120042 s [INFO] - tile decoded in 0.225041 s * The Deployment configuration can't find libares.a Workaround: Add libares to the AutoUpdater and CrashReporter targets In the end, it's not a rewarding target, but hopefully this points to everything needing some love.