From lists.secondlife.com at trap.wereanimal.net Wed Apr 1 00:49:59 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Wed, 1 Apr 2009 03:49:59 -0400 Subject: [sldev] Code review for those of you with commit access Message-ID: <200904010349.59565.lists.secondlife.com@trap.wereanimal.net> On Monday 30 March 2009 08:23:55 pm Rob Lanphier wrote: > > More info can be found here: > https://wiki.secondlife.com/wiki/HTTP_Texture_Development > > Comments welcome. > > Rob > There been some chatter about the http-texture branch on IRC lately. Just wanted to chime in that on my gentoo overlay, I've update the secondlife-http- texture ebuild to work with the current branch. This overlay is for the benefit of gentoo users to test or use the secondlife client. There is more then just the main seccondlife client. Its my contribution to the effort here. For gentoo users, to add the overlay layman -f -a techwolf -o 'http://gentoo.techwolf.net/overlays.xml' Then you have your choice of what branch of the secondlife client to test or use. emerge -av secondlife emerge -av secondlife-http-texture emerge -av secondlife-trunk emerge -av secondlife-featurettes emerge -av secondlife-render-pipeline emerge -av secondlife-maint-viewer emerge -av secondlife-webkit Plus some alternate third party viewers. They all can be emerge/install at the same time. To use a branch/version, one can use the menu or the command line of the name. ie:secondlife-http-texture Some more info is at gentoo.techwolf.net --Techwolf Lupindo From robin.cornelius at gmail.com Wed Apr 1 02:51:19 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed, 1 Apr 2009 10:51:19 +0100 Subject: [sldev] [VWR] Non standalone 64bit builds of http-texture Message-ID: Hey everyone, I've been playing with the http-texture branch in a "non-standalone" capacity on a linux 64 bit host. As everyone knows this is an unsupported combination and its usual for us on 64bit to build with --standalone to use system supplied libraries. So i decided to see how much pain was still involved to complete this process for building the "LL way" on a 64bit system. It turns out that the total pain is not that bad, I have noticed that linux64 packages have appeared in install.xml quite a while back and the ones that are listed there DO work fine, there are just a few missing. By substituting the missing ones the build on a 64bit system completes almost with out hitch (2 pretty minor issues related to 64bit ness already in jira and imported). All the other scripts work and produce 1) a working viewer built on 64 bit 2) a distribution tarball. SO everything looks pretty good, it just needs some one to finish off the last few packages, push to S3 and update install.xml, which I can't believe is that much work. The particular packages that seem to be missing are:- SDL dbusglib elfio fontconfig glib google gtk-atk-pango-glib libuuid ndofdev tut out of that list the only ones that seemed to break the build were dbusglib,elfio,glib,gtk-atk-pango-glib and ndofdev. Its possible that the remaining few were optional extras and cmake excluded them or they got found in implicit search paths on my system (SDL should have been a breaker). Anyway by just adding in the missing header files the build completed successfully and produced a working viewer. Although mozlib was not found for some reason but that is listed as a linux64 package as well, but that needs checking. So basically can we do something about the missing packages? I've opened a jira for this VWR-12656 This releases a bunch of pain and even opens the possibility of automated 64bit builds of the http-texture branch. Thanks Robin From Anders at Arnholm.se Wed Apr 1 04:07:20 2009 From: Anders at Arnholm.se (Anders Arnholm) Date: Wed, 1 Apr 2009 13:07:20 +0200 Subject: [sldev] Updated streaming patch, would like to commit In-Reply-To: <200904010219.22070.dale@daleglass.net> References: <200904010120.20187.dale@daleglass.net> <200904010134.23309.dale@daleglass.net> <49D2AAA1.5010900@lindenlab.com> <200904010219.22070.dale@daleglass.net> Message-ID: <20090401110720.GA11647@arnholm.se> On Wed, Apr 01, 2009 at 02:19:08AM +0200, Dale Glass wrote: > On ????? 01 ?????? 2009 01:43:29 Tofu Linden wrote: > > FMOD has its own streaming audio implementation which is used by > > default when FMOD is enabled - gst/qt are always used for streaming > > video, but are only used for streaming *audio* when FMOD is > > disabled (i.e. you're using OpenAL). > > Ahh, I see I've not been digging deep enough. > > Ok. And with OpenAL there, what prevents the removal of FMOD? With > OpenAL getting added, I imagine FMOD should disappear at some point? Imho, sadly OpenAL + PulseAudio + Unbuntu is noit stable. However 1.22.x was the last I tested it much and imho the imprudance version i hacked was stable. Now this are two different machined my development and my runtime. Maybe, just maybe flash video in firefox, locks some sound resource interfearing with this. As long LL can send and the FMOD code don't need extra suppport i like to see it included. > But I guess this means fmod support will be needed for the time being at > least. I'll try to add support for that as well then. FMod don't have as nice support for this a gstreamer, the patch you did was the obvius next step when i hacked openal for imprudance. / Balp -- o_ Anders Arnholm, o/ /\ anders at arnholm.se /|_, \\ http://anders.arnholm.se/ / ` -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090401/fdde8ca3/attachment-0001.pgp From maggie at matrisync.com Wed Apr 1 05:23:03 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Wed, 1 Apr 2009 08:23:03 -0400 Subject: [sldev] SLDev Digest, Vol 28, Issue 1 In-Reply-To: References: Message-ID: > From: Philip Rosedale > Subject: Re: [sldev] Code review for those of you with commit access > I want to help create a high-value viewer that lots of people use. ?That > means we can't just put every random thing into it, given we > (collectively) have limited time and people. ?Right? ?So we thought > stabilizing the new map code and getting that viewer out there was a > good starting point. We do hope to see people participating on the open-source side who are also more-than-casual eaters of the dogfood. The map project resulted in an improved map, but also broke some very high-quality in-world content; when this was pointed out, the map project folk simply shrugged and expressed surprise. "Gee, we didn't know anybody would do that." The technical debt that is incurred when you don't have stable, documented interfaces and rich-enough services is: hacks like Lex Mars' map texture UUID server, which was allowed to serve as a de-facto response to a long-standing new-function PJIRA. The payment you make on that technical debt is: you must have a better knowledge of the use-cases that content developers and end-users see every day; you can't fall back on a more formal API that lets you make broad assertions about what dependencies content has. Absent such architectural formalisms, the way you get the knowledge to replace them is to spend time in-world looking at and understanding things real people have done. Just hanging out with the gang that built the last twenty shiny chrome deserted corporate islands may teach you that "people are using megaprims and you have to support them", but it won't expose you to more complex devices (more complex than a notecard-giver or a conference table) that are in routine use amongst the real residents. Having a "high-value viewer" is vital. But the most sophisticated viewer on the planet won't mean much without high-value content. The number one complaint from the best scripters in-world is the instability of the vaguely defined interfaces they work with. And as plans to measure and ration scripting resources move forward, Second Life will need even more to improve its retention of talented scripters. The viewer is capable of breaking content too, it doesn't all happen on the server side...it's just that the most painful cases lately have been on the server. From soft at lindenlab.com Wed Apr 1 06:25:55 2009 From: soft at lindenlab.com (Soft) Date: Wed, 1 Apr 2009 08:25:55 -0500 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From merov at lindenlab.com Wed Apr 1 09:26:11 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 1 Apr 2009 09:26:11 -0700 Subject: [sldev] SLDev Digest, Vol 28, Issue 1 In-Reply-To: References: Message-ID: <1BBFC722-3DDF-4259-BC22-07218F67CF6F@lindenlab.com> Hi Maggie, On Apr 1, 2009, at 5:23 AM, Maggie Leber (sl: Maggie Darwin) wrote: > The map project resulted > in an improved map, but also broke some very high-quality in-world > content; when this was pointed out, the map project folk simply > shrugged and expressed surprise. "Gee, we didn't know anybody would do > that." I haven't seen anything logged in PJIRA since we posted that http- texture branch containing the new map code that is related to breaking IW content. Would you mind describing what problem you see? (on which region, etc...). Logging an issue in PJIRA and posting here would be best. Thanks. Cheers, - Merov From gcanaday at gmail.com Wed Apr 1 09:28:31 2009 From: gcanaday at gmail.com (Glen) Date: Wed, 01 Apr 2009 12:28:31 -0400 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D2EC76.8020909@lindenlab.com> References: <49D1629B.1030500@lindenlab.com> <49D29DFD.9070800@watson.ibm.com> <49D2B745.2030709@lindenlab.com> <49D2D1A3.40903@gmail.com> <49D2EC76.8020909@lindenlab.com> Message-ID: <49D3962F.7010809@gmail.com> LOL! Naw, it wasn't me who was tough, it's the guys who are submitting the regular patches who will be. I have huge faith in open development in that it tends to produce code far more robust than deadline-based "get it out the door" commercial production-based development. The guys who go elbows-deep in it tend to become fast experts in their chosen portion of the project! Therefore I thought "concrete" was fitting :) --GC Philip Rosedale wrote: > Man Glen, you are tough! "humor the ex-CEO"... really? Actually I very > much wanted to work more on open source. I feel like it is a huge > chance for greatness, but that we (as a company) need to do more to > support it. > > Also, I think that the broader question of how people do great work > together in an environment which is more open than the conventional work > relationship/organization is an important opportunity. There haven't > been many open source projects as compared to companies or societies - > seems like a change for doing something really great. > > I want to help create a high-value viewer that lots of people use. That > means we can't just put every random thing into it, given we > (collectively) have limited time and people. Right? So we thought > stabilizing the new map code and getting that viewer out there was a > good starting point. > > P > > Glen wrote: >> How about "Project Concrete"? >> >> Rob Lanphier wrote: >>> On 3/31/09 3:49 PM, Mike Monkowski wrote: >>>> Maybe I'm missing something. The blog post seems to talk about an >>>> alternate viewer where all kinds of ideas could be quickly >>>> implemented. But then, this post points to the HTTP texture >>>> project. There's one disconnect. >>> We're in the process of coming up with a name for the project. More >>> details soon on that front. In the meantime, we're using the >>> "http-texture" name as one that will almost certainly not stick, so that >>> we're not stuck with our working title as the name of the project. >>> >>> We do want to be focused on HTTP texture and general stability for a >>> while, since moving to HTTP delivery of textures is a big architectural >>> win, and it's going to take determination and focus to get this code to >>> production quality. >>> >>>> And then how do changes in this alternate viewer get into the official >>>> viewer? Or is this just a way to humor the ex-CEO. Tell him he can >>>> do his project, but don't give haim any people to work with him, so he >>>> has to get volunteers to code his project. >>>> >>>> What, me cynical? ;-) >>> No kidding! :) >>> >>> This isn't an "all hands on deck" thing, but it's more than a token >>> project. We don't have all of the details sorted out as to how the >>> changes get into the mainline viewer, but there are a lot of us that are >>> motivated to get those details sorted out. >>> >>> Are you thinking about helping? >>> >>> Rob >>> >>>> Rob Lanphier wrote: >>>>> Hi folks, >>>>> >>>>> As you probably saw in Philip's blog post (which if you haven't >>>>> read it, >>>>> do so[1]), we're going to be doing a lot more development out in the >>>>> fishbowl, in a branch with community members who have direct commit >>>>> access. >>>>> >>>>> There's a few of you that already have commit access, and others >>>>> that I >>>>> imagine will be asking for it. Here's the procedure we'd like to >>>>> follow >>>>> for commits for new committers to the http-texture: >>>>> >>>>> * File the patch in JIRA if it isn't already there >>>>> * Mail sldev with a link to the JIRA issue, and noting you'd like to >>>>> commit the patch >>>>> * Nag me in a couple of days if we haven't responded >>>>> * Assuming you get the nod, commit the change >>>>> >>>>> This isn't set in stone....there's a number of aspects about this >>>>> process I'm going to guess we haven't thought of. We want to be >>>>> nimble, >>>>> but we also want to make sure there's lots of eyeballs on every >>>>> commit. >>>>> >>>>> More info can be found here: >>>>> https://wiki.secondlife.com/wiki/HTTP_Texture_Development >>>>> >>>>> Comments welcome. >>>>> >>>>> Rob >>>>> >>>>> [1] Philip's blog post: >>>>> https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Policies and (un)subscribe information available here: >>>>> http://wiki.secondlife.com/wiki/SLDev >>>>> Please read the policies before posting to keep unmoderated posting >>>>> privileges >>>>> >>>>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > From gcanaday at gmail.com Wed Apr 1 09:30:24 2009 From: gcanaday at gmail.com (Glen) Date: Wed, 01 Apr 2009 12:30:24 -0400 Subject: [sldev] [VWR] Non standalone 64bit builds of http-texture In-Reply-To: References: Message-ID: <49D396A0.1030002@gmail.com> nice! I'll try it out tonight again. --GC Robin Cornelius wrote: > Hey everyone, > > I've been playing with the http-texture branch in a "non-standalone" > capacity on a linux 64 bit host. As everyone knows this is an > unsupported combination and its usual for us on 64bit to build with > --standalone to use system supplied libraries. So i decided to see how > much pain was still involved to complete this process for building the > "LL way" on a 64bit system. > > It turns out that the total pain is not that bad, I have noticed that > linux64 packages have appeared in install.xml quite a while back and > the ones that are listed there DO work fine, there are just a few > missing. By substituting the missing ones the build on a 64bit system > completes almost with out hitch (2 pretty minor issues related to > 64bit ness already in jira and imported). All the other scripts work > and produce 1) a working viewer built on 64 bit 2) a distribution > tarball. SO everything looks pretty good, it just needs some one to > finish off the last few packages, push to S3 and update install.xml, > which I can't believe is that much work. > > The particular packages that seem to be missing are:- > > SDL > dbusglib > elfio > fontconfig > glib > google > gtk-atk-pango-glib > libuuid > ndofdev > tut > > out of that list the only ones that seemed to break the build were > dbusglib,elfio,glib,gtk-atk-pango-glib and ndofdev. > > Its possible that the remaining few were optional extras and cmake > excluded them or they got found in implicit search paths on my system > (SDL should have been a breaker). Anyway by just adding in the missing > header files the build completed successfully and produced a working > viewer. Although mozlib was not found for some reason but that is > listed as a linux64 package as well, but that needs checking. > > So basically can we do something about the missing packages? I've > opened a jira for this VWR-12656 > > This releases a bunch of pain and even opens the possibility of > automated 64bit builds of the http-texture branch. > > Thanks > > Robin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From carlo at alinoe.com Wed Apr 1 10:26:38 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 1 Apr 2009 19:26:38 +0200 Subject: [sldev] Updated streaming patch, would like to commit In-Reply-To: <200904010120.20187.dale@daleglass.net> References: <200904010120.20187.dale@daleglass.net> Message-ID: <20090401172638.GA3177@alinoe.com> Some general remarks... On Wed, Apr 01, 2009 at 01:20:14AM +0200, Dale Glass wrote: > + > + LLMediaBase * getStreamMedia() { return mInternetStreamMedia; } Are we not following const correctness? Normally this should be: LLMediaBase* getStreamMedia() const { return mInternetStreamMedia; } > public: > F32 mMaxWindGain; // Hack. Public to set before fade in? > > diff --git a/indra/llmedia/llmediaimplgstreamer.cpp b/indra/llmedia/llmediaimplgstreamer.cpp > index 51614c5..d4e8fc2 100644 > --- a/indra/llmedia/llmediaimplgstreamer.cpp > +++ b/indra/llmedia/llmediaimplgstreamer.cpp > @@ -73,7 +73,8 @@ LLMediaImplGStreamer () : > mTextureFormatType ( LL_MEDIA_UNSIGNED_INT_8_8_8_8_REV ), > mPump ( NULL ), > mPlaybin ( NULL ), > - mVideoSink ( NULL ) > + mVideoSink ( NULL ), > + mLastTitle ( "" ) A std::string is empty by default, there is no need to list it in the initialization list like this. > #ifdef LL_GST_SOUNDSINK > ,mAudioSink ( NULL ) > #endif // LL_GST_SOUNDSINK > @@ -300,6 +301,8 @@ LLMediaImplGStreamer::bus_callback (GstBus *bus, > case GST_STATE_PAUSED: > break; > case GST_STATE_PLAYING: > + impl->mLastTitle = ""; > + impl->mLastTitle.clear(); is faster. > + case GST_MESSAGE_TAG: > + { > + DEBUGMSG("GST message tag"); > + GstTagList *new_tags = NULL; > + > + gst_message_parse_tag( message, &new_tags ); > + > + if ( new_tags ) > + { > + gchar *title = NULL; > + if ( gst_tag_list_get_string(new_tags, GST_TAG_TITLE, &title) ) > + { > + gst_tag_list_free(new_tags); > + std::string newtitle(title); > + > + if ( newtitle != impl->mLastTitle && newtitle != "" ) ... && !newtitle.empty() is faster, in fact I'd turn this around: if (!newtitle.empty() && newtitle != impl->mLastTitle) > + { > + impl->mLastTitle = newtitle; > + LLMediaEvent event( impl, impl->mLastTitle ); > + impl->getEventEmitter().update( &LLMediaObserver::onMediaTitleChange, event ); > + } > + > + g_free(title); I'd move this up, to directly below the std::string newtitle(title) > +class LLTitleObserver > + : public LLMediaObserver > +{ > +public: > + void init(std::string url); Pass by value?? This isn't java or LSL :p Surely you meant: void init(std::string const& url); > + /*virtual*/ void onMediaTitleChange(const EventType& event_in); > +private: > + LLMediaBase* mMediaSource; > +}; > + > +static LLTitleObserver sTitleObserver; > + > +static LLRegisterWidget r("media_remote"); static is not used anymore in C++. You'd normally an anonymous namespace. More importantly however, global variables are the root of all evil. I'm worried when I see things like this. -- Carlo Wood From monkowsk at watson.ibm.com Wed Apr 1 10:28:15 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 01 Apr 2009 13:28:15 -0400 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D2B745.2030709@lindenlab.com> References: <49D1629B.1030500@lindenlab.com> <49D29DFD.9070800@watson.ibm.com> <49D2B745.2030709@lindenlab.com> Message-ID: <49D3A42F.4040106@watson.ibm.com> Rob Lanphier wrote: > We do want to be focused on HTTP texture and general stability for a > while, since moving to HTTP delivery of textures is a big architectural > win, and it's going to take determination and focus to get this code to > production quality. ... > This isn't an "all hands on deck" thing, but it's more than a token > project. We don't have all of the details sorted out as to how the > changes get into the mainline viewer, but there are a lot of us that are > motivated to get those details sorted out. > > Are you thinking about helping? Not interested in HTTP textures, although it is a worthy cause. I've already started too many other things. I wanted to know whether this was a new route to getting features added. It seems not. It sounds, rather, like a project to engage those with some interest but no current project. Do I understand this correctly? Mike From monkowsk at watson.ibm.com Wed Apr 1 10:45:17 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 01 Apr 2009 13:45:17 -0400 Subject: [sldev] Code review for those of you with commit access In-Reply-To: <49D2EC76.8020909@lindenlab.com> References: <49D1629B.1030500@lindenlab.com> <49D29DFD.9070800@watson.ibm.com> <49D2B745.2030709@lindenlab.com> <49D2D1A3.40903@gmail.com> <49D2EC76.8020909@lindenlab.com> Message-ID: <49D3A82D.40004@watson.ibm.com> Philip Rosedale wrote: > Man Glen, you are tough! "humor the ex-CEO"... really? Actually I very > much wanted to work more on open source. I feel like it is a huge > chance for greatness, but that we (as a company) need to do more to > support it. Don't blame Glen. I'm the one who suggested this was a way to humor the ex-CEO. Of course I smile when I say that. You don't think just because you used to be the boss that we'd cut you some slack, do you? :-) It does make sense, or course. If one person can maintain the Dale Glass viewer, or the Nicolas viewer, or Kirsten's viewer, it must be possible to find one person in Linden that could maintain an alternate viewer. However, no one has a problem with Dale or Nicolas or Kirsten deciding what they want to incorporate in their viewers. But this won't be perceived as "Philip's viewer," it'll be seen as "Linden's alternate viewer" and hey, why can't I get my shiny new feechur in there? I'm not clear what the criteria would be to decide who gets commit access. Mike From maggie at matrisync.com Wed Apr 1 11:19:20 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Wed, 1 Apr 2009 14:19:20 -0400 Subject: [sldev] SLDev Digest, Vol 28, Issue 2 In-Reply-To: References: Message-ID: > From: "Philippe Bossut (Merov Linden)" > Subject: Re: [sldev] SLDev Digest, Vol 28, Issue 1 > I haven't seen anything logged in PJIRA since we posted that http- > texture branch containing the new map code that is related to breaking > IW content. Would you mind describing what problem you see? (on which > region, etc...). Logging an issue in PJIRA and posting here would be > best. Thanks. See http://www.subnova.com/news/?nid=2178 Subnova published an API providing UUIDs for the map textures when nothing moved on https://jira.secondlife.com/browse/VWR-2178 The shoulder-shrug was: http://forums.secondlife.com/showthread.php?t=303761&page=7&pp=15#post2312696 Any content that depends on Subnova serving a region texture UUID is in serious trouble with the new map system. See the forum discussion for some examples (Novatech, Jer Straff's "Heavily Scripted Industries" vehicle products, Quantum Core radar etc.). I myself was about to build a moving-map navigation device for vehicles that would have leveraged the llDetectedTouch API, but with no in-world map textures anymore, that one goes in the toity. It might make sense to pull the new textures out of the Amazon S3 cloud, but with no real per-face HTML-on-a-prim yet (as opposed to the per-parcel dealie we got somewhere about SLV 1.19), that's just a dream. We currently can only address face textures with UUIDs, not URLs. As for filing a JIRA...some PJIRAcop would just close "working as designed", since there's no formal API promising in-world map tiles. Just content that depends on a now-broken third-party server. Maggie Darwin From poppy at lindenlab.com Wed Apr 1 12:10:45 2009 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Wed, 01 Apr 2009 12:10:45 -0700 Subject: [sldev] How can I use distcc outside LL? In-Reply-To: <1dvdkwGGdcdsh24xfY5ccd5.alissa_sabre@yahoo.co.jp> References: <1G64f76ds8feefe5eY9u8rds.alissa_sabre@yahoo.co.jp> <1dvdkwGGdcdsh24xfY5ccd5.alissa_sabre@yahoo.co.jp> Message-ID: <49D3BC35.7030109@lindenlab.com> Alissa Sabre wrote: > This is just an execuse, but I was confused to see a lot of > distcc-specific codes and an option (--no-distcc) in develop.py and to > find that all those distcc features are only for LL developpers... Yeah, we should change that to use a hosts file. Not currently a high priority. The existing distcc setup is currently broken internally for a number of devs. make -j # should work as normal. + poppy From tom at streamsense.net Wed Apr 1 12:49:16 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed, 01 Apr 2009 20:49:16 +0100 Subject: [sldev] AppendedAcks Message-ID: <49D3C53C.90201@streamsense.net> Hey all, I was just wondering if there was any practical reason why AppendedAcks are not zerocoded in the packet data? Saving a few bytes means fitting more Acks into each message, potentially reducing the number of PacketAck messages being sent, which means a potentially substantial protocol overhead reduction. This could also be implemented with backward compatibility by using a new flag to indicate zerocoded appendedacks. ~T From gbrandon at gmail.com Wed Apr 1 13:31:17 2009 From: gbrandon at gmail.com (Brandon Lockaby) Date: Wed, 1 Apr 2009 16:31:17 -0400 Subject: [sldev] AppendedAcks In-Reply-To: <49D3C53C.90201@streamsense.net> References: <49D3C53C.90201@streamsense.net> Message-ID: My thoughts: * Under the current circumstances a packet ID occupies 4 bytes * While the packet ID's are below 256 (not for very long), you can save one byte for every packet ID * Once they get into the range of 256-65535, zero coding would save nothing * Once they get into the range of 65536-16777215, zero coding start to require 5 bytes for each packet ID I wonder if I understand correctly though? On Wed, Apr 1, 2009 at 3:49 PM, Thomas Grimshaw wrote: > Hey all, > > I was just wondering if there was any practical reason why AppendedAcks > are not zerocoded in the packet data? > > Saving a few bytes means fitting more Acks into each message, > potentially reducing the number of PacketAck messages being sent, which > means a potentially substantial protocol overhead reduction. > > This could also be implemented with backward compatibility by using a > new flag to indicate zerocoded appendedacks. > > ~T > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090401/c8b45a2c/attachment.htm From tom at streamsense.net Wed Apr 1 13:38:15 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed, 01 Apr 2009 21:38:15 +0100 Subject: [sldev] AppendedAcks In-Reply-To: References: <49D3C53C.90201@streamsense.net> Message-ID: <49D3D0B7.9030906@streamsense.net> Yes, you're right. For some reason I was thinking they were 64bit ID's, when I know they're not. Apologies ~T Brandon Lockaby wrote: > My thoughts: > * Under the current circumstances a packet ID occupies 4 bytes > * While the packet ID's are below 256 (not for very long), you can > save one byte for every packet ID > * Once they get into the range of 256-65535, zero coding would save > nothing > * Once they get into the range of 65536-16777215, zero coding start to > require 5 bytes for each packet ID > > I wonder if I understand correctly though? > > On Wed, Apr 1, 2009 at 3:49 PM, Thomas Grimshaw > wrote: > > Hey all, > > I was just wondering if there was any practical reason why > AppendedAcks > are not zerocoded in the packet data? > > Saving a few bytes means fitting more Acks into each message, > potentially reducing the number of PacketAck messages being sent, > which > means a potentially substantial protocol overhead reduction. > > This could also be implemented with backward compatibility by using a > new flag to indicate zerocoded appendedacks. > > ~T > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > From gigstaggart at gmail.com Wed Apr 1 13:43:07 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 01 Apr 2009 16:43:07 -0400 Subject: [sldev] Updated streaming patch, would like to commit In-Reply-To: <20090401110720.GA11647@arnholm.se> References: <200904010120.20187.dale@daleglass.net> <200904010134.23309.dale@daleglass.net> <49D2AAA1.5010900@lindenlab.com> <200904010219.22070.dale@daleglass.net> <20090401110720.GA11647@arnholm.se> Message-ID: <49D3D1DB.6030801@gmail.com> I should point out that "OpenAL" is an unmaintained sample implementation. http://kcat.strangesoft.net/openal.html OpenAL Soft is an attempt to maintain OpenAL and make it a usable library instead of a sample implementation. -Jason Anders Arnholm wrote: > On Wed, Apr 01, 2009 at 02:19:08AM +0200, Dale Glass wrote: >> On ????? 01 ?????? 2009 01:43:29 Tofu Linden wrote: >>> FMOD has its own streaming audio implementation which is used by >>> default when FMOD is enabled - gst/qt are always used for streaming >>> video, but are only used for streaming *audio* when FMOD is >>> disabled (i.e. you're using OpenAL). >> Ahh, I see I've not been digging deep enough. >> >> Ok. And with OpenAL there, what prevents the removal of FMOD? With >> OpenAL getting added, I imagine FMOD should disappear at some point? > > Imho, sadly OpenAL + PulseAudio + Unbuntu is noit stable. However 1.22.x > was the last I tested it much and imho the imprudance version i hacked > was stable. Now this are two different machined my development and my > runtime. Maybe, just maybe flash video in firefox, locks some sound > resource interfearing with this. As long LL can send and the FMOD code > don't need extra suppport i like to see it included. > >> But I guess this means fmod support will be needed for the time being at >> least. I'll try to add support for that as well then. > > FMod don't have as nice support for this a gstreamer, the patch you did > was the obvius next step when i hacked openal for imprudance. > > / Balp > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090401/26eba79d/attachment.bin From tofu.linden at lindenlab.com Wed Apr 1 13:50:31 2009 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Wed, 01 Apr 2009 13:50:31 -0700 Subject: [sldev] Updated streaming patch, would like to commit In-Reply-To: <49D3D1DB.6030801@gmail.com> References: <200904010120.20187.dale@daleglass.net> <200904010134.23309.dale@daleglass.net> <49D2AAA1.5010900@lindenlab.com> <200904010219.22070.dale@daleglass.net><20090401110720.GA11647@arnholm.se> <49D3D1DB.6030801@gmail.com> Message-ID: <49D3D397.6060609@lindenlab.com> FYI - OpenAL Soft is what the official SL builds ship with on Linux. Jason Giglio wrote: > I should point out that "OpenAL" is an unmaintained sample implementation. > > http://kcat.strangesoft.net/openal.html > > OpenAL Soft is an attempt to maintain OpenAL and make it a usable > library instead of a sample implementation. > > -Jason > > > Anders Arnholm wrote: >> On Wed, Apr 01, 2009 at 02:19:08AM +0200, Dale Glass wrote: >>> On ????? 01 ?????? 2009 01:43:29 Tofu Linden wrote: >>>> FMOD has its own streaming audio implementation which is used by >>>> default when FMOD is enabled - gst/qt are always used for streaming >>>> video, but are only used for streaming *audio* when FMOD is >>>> disabled (i.e. you're using OpenAL). >>> Ahh, I see I've not been digging deep enough. >>> >>> Ok. And with OpenAL there, what prevents the removal of FMOD? With >>> OpenAL getting added, I imagine FMOD should disappear at some point? >> Imho, sadly OpenAL + PulseAudio + Unbuntu is noit stable. However 1.22.x >> was the last I tested it much and imho the imprudance version i hacked >> was stable. Now this are two different machined my development and my >> runtime. Maybe, just maybe flash video in firefox, locks some sound >> resource interfearing with this. As long LL can send and the FMOD code >> don't need extra suppport i like to see it included. >> >>> But I guess this means fmod support will be needed for the time being at >>> least. I'll try to add support for that as well then. >> FMod don't have as nice support for this a gstreamer, the patch you did >> was the obvius next step when i hacked openal for imprudance. >> >> / Balp >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From merov at lindenlab.com Wed Apr 1 14:31:13 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 1 Apr 2009 14:31:13 -0700 Subject: [sldev] SLDev Digest, Vol 28, Issue 2 In-Reply-To: References: Message-ID: <7E1CE68B-34BF-4980-9877-63B3AEB99DB9@lindenlab.com> Hi Maggie, On Apr 1, 2009, at 11:19 AM, Maggie Leber (sl: Maggie Darwin) wrote: > Any content that depends on Subnova serving a region texture UUID is > in serious trouble with the new map system. See the forum discussion > for some examples (Novatech, Jer Straff's "Heavily Scripted > Industries" vehicle products, Quantum Core radar etc.). > > I myself was about to build a moving-map navigation device for > vehicles that would have leveraged the llDetectedTouch API, but with > no in-world map textures anymore, that one goes in the toity. It might > make sense to pull the new textures out of the Amazon S3 cloud, but > with no real per-face HTML-on-a-prim yet (as opposed to the per-parcel > dealie we got somewhere about SLV 1.19), that's just a dream. We > currently can only address face textures with UUIDs, not URLs. Ah well. I see now. This has to do with the changes to the mapserver (and, yes, I did work on that too with James and Philip), not the newly minted "http-texture" (temporary name...) branch. I'm not going to reopen the long thread that was on the forum, let's try to focus on your use case. Ideally, you want to get a prim to be able to address a texture with a URL as you mentioned. This is one of the objective of the work on this branch (hence its name) but it's a massive and deep change that will require lots of testing in virtually every area of the viewer. Working in the open here is one way to make this happen faster and make sure we leave no stone unturned, checking use cases that we have little ideas people do count on working. We hope with all those pairs of eyeballs on the code and builds, we'll get a better viewer in the end and avoid last minute surprise. Good. Still, getting there will take times so, what can you do in the meantime? Well, we still produce the j2c map tiles for the asset server. We have to or existing viewers wouldn't be able to display the map. Is the problem that you can't guess the UUID for a region tile? It's somewhere for sure (the viewer map gets it) though I don't know if it's accessible from an LSL script (I guess it's not or no one would have any problem...). Cheers, - Merov From philip at lindenlab.com Wed Apr 1 15:15:14 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Wed, 01 Apr 2009 15:15:14 -0700 Subject: [sldev] AppendedAcks In-Reply-To: <49D3D0B7.9030906@streamsense.net> References: <49D3C53C.90201@streamsense.net> <49D3D0B7.9030906@streamsense.net> Message-ID: <49D3E772.1080804@lindenlab.com> I have a special place in my heart, though, for anyone who spots a case where we are inefficiently sending data. We need every byte we can get, both in terms of latency and total bandwidth implications. One project I'd love to get to (and perhaps have community help with) is a careful examination of all existing messages to look for bytes we could save. Thomas Grimshaw wrote: > Yes, you're right. For some reason I was thinking they were 64bit ID's, > when I know they're not. > > Apologies > > ~T > > Brandon Lockaby wrote: > >> My thoughts: >> * Under the current circumstances a packet ID occupies 4 bytes >> * While the packet ID's are below 256 (not for very long), you can >> save one byte for every packet ID >> * Once they get into the range of 256-65535, zero coding would save >> nothing >> * Once they get into the range of 65536-16777215, zero coding start to >> require 5 bytes for each packet ID >> >> I wonder if I understand correctly though? >> >> On Wed, Apr 1, 2009 at 3:49 PM, Thomas Grimshaw > > wrote: >> >> Hey all, >> >> I was just wondering if there was any practical reason why >> AppendedAcks >> are not zerocoded in the packet data? >> >> Saving a few bytes means fitting more Acks into each message, >> potentially reducing the number of PacketAck messages being sent, >> which >> means a potentially substantial protocol overhead reduction. >> >> This could also be implemented with backward compatibility by using a >> new flag to indicate zerocoded appendedacks. >> >> ~T >> >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated >> posting privileges >> >> >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090401/43bff90f/attachment-0001.htm From tom at streamsense.net Wed Apr 1 15:18:23 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Wed, 01 Apr 2009 23:18:23 +0100 Subject: [sldev] AppendedAcks In-Reply-To: <49D3E772.1080804@lindenlab.com> References: <49D3C53C.90201@streamsense.net> <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com> Message-ID: <49D3E82F.3010101@streamsense.net> In order for that to be accomplished, it will be massively helpful for somebody from the lab to spend some time updating the protocol details on the wiki with information on which parameters do what, etc. While the community (libsecondlife / opensimulator) have deciphered a majority of the messages, nothing is certain or definate, and having to reverse engineer something which is technically open is a little counterproductive. ~T Philip Rosedale wrote: > I have a special place in my heart, though, for anyone who spots a > case where we are inefficiently sending data. We need every byte we > can get, both in terms of latency and total bandwidth implications. > One project I'd love to get to (and perhaps have community help with) > is a careful examination of all existing messages to look for bytes we > could save. > > Thomas Grimshaw wrote: >> Yes, you're right. For some reason I was thinking they were 64bit ID's, >> when I know they're not. >> >> Apologies >> >> ~T >> >> Brandon Lockaby wrote: >> >>> My thoughts: >>> * Under the current circumstances a packet ID occupies 4 bytes >>> * While the packet ID's are below 256 (not for very long), you can >>> save one byte for every packet ID >>> * Once they get into the range of 256-65535, zero coding would save >>> nothing >>> * Once they get into the range of 65536-16777215, zero coding start to >>> require 5 bytes for each packet ID >>> >>> I wonder if I understand correctly though? >>> >>> On Wed, Apr 1, 2009 at 3:49 PM, Thomas Grimshaw >> > wrote: >>> >>> Hey all, >>> >>> I was just wondering if there was any practical reason why >>> AppendedAcks >>> are not zerocoded in the packet data? >>> >>> Saving a few bytes means fitting more Acks into each message, >>> potentially reducing the number of PacketAck messages being sent, >>> which >>> means a potentially substantial protocol overhead reduction. >>> >>> This could also be implemented with backward compatibility by using a >>> new flag to indicate zerocoded appendedacks. >>> >>> ~T >>> >>> >>> >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated >>> posting privileges >>> >>> >>> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> From philip at lindenlab.com Wed Apr 1 15:19:12 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Wed, 01 Apr 2009 15:19:12 -0700 Subject: [sldev] SLDev Digest, Vol 28, Issue 2 In-Reply-To: <7E1CE68B-34BF-4980-9877-63B3AEB99DB9@lindenlab.com> References: <7E1CE68B-34BF-4980-9877-63B3AEB99DB9@lindenlab.com> Message-ID: <49D3E860.6090404@lindenlab.com> Like merov says, we are still making the in-world textures so Subnova,etc will still work. Once we get http references working for prims, we can directly access the S3 machines. Another LL dev team is starting work now on the server side of delivering HTTP textures, and this build has the majority of the client side work. They are also going to be doing their work in the open source code, so you should see them starting soon. We should not be too far away from the correct solution. P Philippe Bossut (Merov Linden) wrote: > Hi Maggie, > > On Apr 1, 2009, at 11:19 AM, Maggie Leber (sl: Maggie Darwin) wrote: > >> Any content that depends on Subnova serving a region texture UUID is >> in serious trouble with the new map system. See the forum discussion >> for some examples (Novatech, Jer Straff's "Heavily Scripted >> Industries" vehicle products, Quantum Core radar etc.). >> >> I myself was about to build a moving-map navigation device for >> vehicles that would have leveraged the llDetectedTouch API, but with >> no in-world map textures anymore, that one goes in the toity. It might >> make sense to pull the new textures out of the Amazon S3 cloud, but >> with no real per-face HTML-on-a-prim yet (as opposed to the per-parcel >> dealie we got somewhere about SLV 1.19), that's just a dream. We >> currently can only address face textures with UUIDs, not URLs. >> > > > Ah well. I see now. This has to do with the changes to the mapserver > (and, yes, I did work on that too with James and Philip), not the > newly minted "http-texture" (temporary name...) branch. > > I'm not going to reopen the long thread that was on the forum, let's > try to focus on your use case. > > Ideally, you want to get a prim to be able to address a texture with a > URL as you mentioned. This is one of the objective of the work on this > branch (hence its name) but it's a massive and deep change that will > require lots of testing in virtually every area of the viewer. Working > in the open here is one way to make this happen faster and make sure > we leave no stone unturned, checking use cases that we have little > ideas people do count on working. We hope with all those pairs of > eyeballs on the code and builds, we'll get a better viewer in the end > and avoid last minute surprise. Good. > > Still, getting there will take times so, what can you do in the > meantime? Well, we still produce the j2c map tiles for the asset > server. We have to or existing viewers wouldn't be able to display the > map. Is the problem that you can't guess the UUID for a region tile? > It's somewhere for sure (the viewer map gets it) though I don't know > if it's accessible from an LSL script (I guess it's not or no one > would have any problem...). > > Cheers, > - Merov > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090401/658a1d50/attachment.htm From soft at lindenlab.com Wed Apr 1 15:28:10 2009 From: soft at lindenlab.com (Soft) Date: Wed, 1 Apr 2009 17:28:10 -0500 Subject: [sldev] AppendedAcks In-Reply-To: <49D3E82F.3010101@streamsense.net> References: <49D3C53C.90201@streamsense.net> <49D3E772.1080804@lindenlab.com> <49D3E82F.3010101@streamsense.net> Message-ID: Fuller protocol documentation is on the long list. But ask away any time if there are specific fields/messages you're curious about. On Wed, Apr 1, 2009 at 5:18 PM, Thomas Grimshaw wrote: > In order for that to be accomplished, it will be massively helpful for > somebody from the lab to spend some time updating the protocol details > on the wiki with information on which parameters do what, etc. > > While the community (libsecondlife / opensimulator) have deciphered a > majority of the messages, nothing is certain or definate, and having to > reverse engineer something which is technically open is a little > counterproductive. From maggie at matrisync.com Wed Apr 1 16:19:54 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Wed, 1 Apr 2009 19:19:54 -0400 Subject: [sldev] SLDev Digest, Vol 28, Issue 4 In-Reply-To: References: Message-ID: > From: "Philippe Bossut (Merov Linden)" > Subject: Re: [sldev] SLDev Digest, Vol 28, Issue 2 > Still, getting there will take times so, what can you do in the > meantime? Well, we still produce the j2c map tiles for the asset > server. We have to or existing viewers wouldn't be able to display the > map. Is the problem that you can't guess the UUID for a region tile? > It's somewhere for sure (the viewer map gets it) though I don't know > if it's accessible from an LSL script (I guess it's not or no one > would have any problem...). It's not available in LSL, which was, of course, the subject of the cited feature req JIRA. That's why Lex put his off-grid service up, to map region names to UUIDs. But Philip held forth at one point on how expensive it was to have this stuff in the asset server...but now you're telling us it's still there. Hmmm. Something is going on here, and I may not have good (or maybe "complete") information. The Subnova server is currently serving UUIDs for textures that are (at least in the case of my region, "Harrington", a lot more recent than I would expect given the announcement that everything was going to go static when the new maps went up. Maybe something's been done to address this, and the word just hasn't gotten out. Anybody know? --Maggie Darwin-- From philip at lindenlab.com Wed Apr 1 16:38:32 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Wed, 01 Apr 2009 16:38:32 -0700 Subject: [sldev] SLDev Digest, Vol 28, Issue 4 In-Reply-To: References: Message-ID: <49D3FAF8.2000009@lindenlab.com> To repeat: We can't shutdown the support for in-world map tiles yet, because the existing production SL viewers need to access those tiles to display the map. Only after we deploy an official SL viewer that uses the S3 tiles, can we consider not creating the in-world map images. To my knowledge, this info is totally consistent with what we said at release of the new webmap. Maggie Leber (sl: Maggie Darwin) wrote: >> From: "Philippe Bossut (Merov Linden)" >> Subject: Re: [sldev] SLDev Digest, Vol 28, Issue 2 >> Still, getting there will take times so, what can you do in the >> meantime? Well, we still produce the j2c map tiles for the asset >> server. We have to or existing viewers wouldn't be able to display the >> map. Is the problem that you can't guess the UUID for a region tile? >> It's somewhere for sure (the viewer map gets it) though I don't know >> if it's accessible from an LSL script (I guess it's not or no one >> would have any problem...). >> > > It's not available in LSL, which was, of course, the subject of the > cited feature req JIRA. > > That's why Lex put his off-grid service up, to map region names to UUIDs. > > But Philip held forth at one point on how expensive it was to have > this stuff in the asset server...but now you're telling us it's still > there. Hmmm. > > Something is going on here, and I may not have good (or maybe > "complete") information. The Subnova server is currently serving UUIDs > for textures that are (at least in the case of my region, > "Harrington", a lot more recent than I would expect given the > announcement that everything was going to go static when the new maps > went up. > > Maybe something's been done to address this, and the word just hasn't > gotten out. > > Anybody know? > > --Maggie Darwin-- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090401/513b856c/attachment.htm From maggie at matrisync.com Wed Apr 1 17:15:20 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Wed, 1 Apr 2009 20:15:20 -0400 Subject: [sldev] Map times Message-ID: On Wed, Apr 1, 2009 at 7:38 PM, Philip Rosedale wrote: > Only after we deploy an official SL viewer that uses the > S3 tiles, can we consider not creating the in-world map images.??? To my > knowledge, this info is totally consistent with what we said at release of > the new webmap. OK, that makes more sense. So what I'm hearing is: it hasn't broken content yet, but at some future time it will. My original points were: ?It sounded like the whole map tile issue was a surprise, and there's apparently ?no official remedy. ?The more that scripting interfaces and behaviors can be formalized, the fewer nasty surprises there will be, and the longer we'll retain resident content creators who can update their products to track architectural changes, as opposed to content creators who quit in frustration leaving behind orphaned content that will *never* be fixed when interfaces and behaviors change. ?The stronger the available scripting languages are, the fewer stupid scripting hacks will find their way into content. Like all the tomfoolery around list manipulation. From lenglish5 at cox.net Wed Apr 1 17:21:49 2009 From: lenglish5 at cox.net (Lawson English) Date: Wed, 01 Apr 2009 17:21:49 -0700 Subject: [sldev] AppendedAcks In-Reply-To: References: <49D3C53C.90201@streamsense.net> <49D3E772.1080804@lindenlab.com> <49D3E82F.3010101@streamsense.net> Message-ID: <49D4051D.1000701@cox.net> Soft wrote: > Fuller protocol documentation is on the long list. But ask away any > time if there are specific fields/messages you're curious about. > > On Wed, Apr 1, 2009 at 5:18 PM, Thomas Grimshaw wrote: > >> In order for that to be accomplished, it will be massively helpful for >> somebody from the lab to spend some time updating the protocol details >> on the wiki with information on which parameters do what, etc. >> >> While the community (libsecondlife / opensimulator) have deciphered a >> majority of the messages, nothing is certain or definate, and having to >> reverse engineer something which is technically open is a little >> counterproductive. >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > Hey check out the AWG docs, Libsl docs, and the inline packet handlers Enus made for pyogp. L. From gigstaggart at gmail.com Wed Apr 1 22:25:53 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Thu, 02 Apr 2009 01:25:53 -0400 Subject: [sldev] Updated streaming patch, would like to commit In-Reply-To: <49D3D397.6060609@lindenlab.com> References: <200904010120.20187.dale@daleglass.net> <200904010134.23309.dale@daleglass.net> <49D2AAA1.5010900@lindenlab.com> <200904010219.22070.dale@daleglass.net><20090401110720.GA11647@arnholm.se> <49D3D1DB.6030801@gmail.com> <49D3D397.6060609@lindenlab.com> Message-ID: <49D44C61.1000602@gmail.com> Tofu Linden wrote: > FYI - OpenAL Soft is what the official SL builds ship with on Linux. > Excellent, I did not know that. -Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3266 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090402/462dedbe/attachment.bin From chaosstar at gmail.com Thu Apr 2 00:02:21 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 2 Apr 2009 09:02:21 +0200 Subject: [sldev] AppendedAcks In-Reply-To: <49D4051D.1000701@cox.net> References: <49D3C53C.90201@streamsense.net> <49D3E772.1080804@lindenlab.com> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> Message-ID: <9bb32d430904020002g5514ed9j6c7db0fa9382650a@mail.gmail.com> Speaking of saving bytes, it was mentioned on this list a longer time ago, and for some reason rejected: The idea of using Google Protocol Buffers instead of the currently rather unflexible implementation of LLSD. http://code.google.com/intl/de-DE/apis/protocolbuffers/ The protocol buffers serve pretty much the same purpose, are less verbose, and support -optional- fields, which means that in some cases quite alot of overhead could be saved. Headers and cpp files for the messages can be autoconstructed as well. Worth a look, IMO. On Thu, Apr 2, 2009 at 02:21, Lawson English wrote: > Soft wrote: >> Fuller protocol documentation is on the long list. But ask away any >> time if there are specific fields/messages you're curious about. >> >> On Wed, Apr 1, 2009 at 5:18 PM, Thomas Grimshaw wrote: >> >>> In order for that to be accomplished, it will be massively helpful for >>> somebody from the lab to spend some time updating the protocol details >>> on the wiki with information on which parameters do what, etc. >>> >>> While the community (libsecondlife / opensimulator) have deciphered a >>> majority of the messages, nothing is certain or definate, and having to >>> reverse engineer something which is technically open is a little >>> counterproductive. >>> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > > Hey check out the AWG docs, Libsl docs, and the inline packet handlers > Enus made for pyogp. > > L. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From tom at streamsense.net Thu Apr 2 02:35:35 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu, 02 Apr 2009 10:35:35 +0100 Subject: [sldev] AppendedAcks In-Reply-To: <9bb32d430904020002g5514ed9j6c7db0fa9382650a@mail.gmail.com> References: <49D3C53C.90201@streamsense.net> <49D3E772.1080804@lindenlab.com> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> <9bb32d430904020002g5514ed9j6c7db0fa9382650a@mail.gmail.com> Message-ID: <49D486E7.1070101@streamsense.net> Or alternatively EBML, which is essentially binary XML, would be the most efficient.. http://en.wikipedia.org/wiki/Extensible_Binary_Meta_Language =) ~T Ambrosia wrote: > Speaking of saving bytes, it was mentioned on this list a longer time > ago, and for some reason rejected: > > The idea of using Google Protocol Buffers instead of the currently > rather unflexible implementation of LLSD. > > http://code.google.com/intl/de-DE/apis/protocolbuffers/ > > The protocol buffers serve pretty much the same purpose, are less > verbose, and support -optional- fields, > which means that in some cases quite alot of overhead could be saved. > Headers and cpp files for the > messages can be autoconstructed as well. Worth a look, IMO. > > On Thu, Apr 2, 2009 at 02:21, Lawson English wrote: > >> Soft wrote: >> >>> Fuller protocol documentation is on the long list. But ask away any >>> time if there are specific fields/messages you're curious about. >>> >>> On Wed, Apr 1, 2009 at 5:18 PM, Thomas Grimshaw wrote: >>> >>> >>>> In order for that to be accomplished, it will be massively helpful for >>>> somebody from the lab to spend some time updating the protocol details >>>> on the wiki with information on which parameters do what, etc. >>>> >>>> While the community (libsecondlife / opensimulator) have deciphered a >>>> majority of the messages, nothing is certain or definate, and having to >>>> reverse engineer something which is technically open is a little >>>> counterproductive. >>>> >>>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >>> >>> >> Hey check out the AWG docs, Libsl docs, and the inline packet handlers >> Enus made for pyogp. >> >> L. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> >> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From secret.argent at gmail.com Thu Apr 2 05:08:52 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 2 Apr 2009 07:08:52 -0500 Subject: [sldev] SLDev Digest, Vol 28, Issue 1 In-Reply-To: References: Message-ID: <33BA2BA9-861D-49EA-893A-2443CD80FA30@gmail.com> Merov: what Maggie's talking about is that people were using the map tiles by UUID as textures on the surface of prims to create in-world maps for a variety of purposes. When the way the tiles were generated changed, that apparently broke content... there was discussion about it on the forum and Philip Linden came in and pointed out that using the tiles in-world was never supported. From secret.argent at gmail.com Thu Apr 2 05:50:41 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 2 Apr 2009 07:50:41 -0500 Subject: [sldev] Map times In-Reply-To: References: Message-ID: On the subject of APIs... I know scripting and server-side stuff is really off topic, but I'd like to suggest that LL consider some of the JIRA entries for features that reduce the number of scripts in-world (like llGetLinkPrimitiveParams https://jira.secondlife.com/browse/SVC-224 or some kind of per-prim keyed data store like https://jira.secondlife.com/browse/SVC-1406) alongside the new script limits. People are using all kinds of scripting hacks and weird tricks in existing APIs to work around these... and I'm sure many are going to be effectively broken by script limits. From lenglish5 at cox.net Thu Apr 2 06:14:24 2009 From: lenglish5 at cox.net (Lawson English) Date: Thu, 02 Apr 2009 06:14:24 -0700 Subject: [sldev] python client discussion group Message-ID: <49D4BA30.8030102@cox.net> hey all, a reminder for anyone interested in the python second life client, pyogp, we have our own irc channel on freenode called pyogp, and our own in-world discussion group, also called pyogp. Lawson (Saijanai in Second Life) From lenglish5 at cox.net Thu Apr 2 06:22:58 2009 From: lenglish5 at cox.net (Lawson English) Date: Thu, 02 Apr 2009 06:22:58 -0700 Subject: [sldev] SLDev Digest, Vol 28, Issue 1 In-Reply-To: <33BA2BA9-861D-49EA-893A-2443CD80FA30@gmail.com> References: <33BA2BA9-861D-49EA-893A-2443CD80FA30@gmail.com> Message-ID: <49D4BC32.5050300@cox.net> Argent Stonecutter wrote: > Merov: what Maggie's talking about is that people were using the map > tiles by UUID as textures on the surface of prims to create in-world > maps for a variety of purposes. When the way the tiles were generated > changed, that apparently broke content... there was discussion about > it on the forum and Philip Linden came in and pointed out that using > the tiles in-world was never supported. > _______________________________________________ > Hey but we used to be able to write an LSL second life client and grab the textures via TCP caps, and they stopped supporting that too. What's up with that? ;-) Lawson From lenglish5 at cox.net Thu Apr 2 06:25:42 2009 From: lenglish5 at cox.net (Lawson English) Date: Thu, 02 Apr 2009 06:25:42 -0700 Subject: [sldev] AppendedAcks In-Reply-To: <9bb32d430904020002g5514ed9j6c7db0fa9382650a@mail.gmail.com> References: <49D3C53C.90201@streamsense.net> <49D3E772.1080804@lindenlab.com> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> <9bb32d430904020002g5514ed9j6c7db0fa9382650a@mail.gmail.com> Message-ID: <49D4BCD6.2060901@cox.net> Ambrosia wrote: > Speaking of saving bytes, it was mentioned on this list a longer time > ago, and for some reason rejected: > > The idea of using Google Protocol Buffers instead of the currently > rather unflexible implementation of LLSD. > > http://code.google.com/intl/de-DE/apis/protocolbuffers/ > > The protocol buffers serve pretty much the same purpose, are less > verbose, and support -optional- fields, > which means that in some cases quite alot of overhead could be saved. > Headers and cpp files for the > messages can be autoconstructed as well. Worth a look, IMO. > There's been much discussion on the MMOX mailing list about LLSD vs google protocol buffers. I'm not sure that the rejection was concerning that particular form of serialization or merely concerns about insisting that we use that particular way of describing the on-the-wire protocol. Lawson mmox mailing list mmox at ietf.org https://www.ietf.org/mailman/listinfo/mmox From carlo at alinoe.com Thu Apr 2 07:27:26 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 2 Apr 2009 16:27:26 +0200 Subject: [sldev] AppendedAcks In-Reply-To: <49D3C53C.90201@streamsense.net> References: <49D3C53C.90201@streamsense.net> Message-ID: <20090402142726.GA24161@alinoe.com> On Wed, Apr 01, 2009 at 08:49:16PM +0100, Thomas Grimshaw wrote: > Hey all, > > I was just wondering if there was any practical reason why AppendedAcks > are not zerocoded in the packet data? > > Saving a few bytes means fitting more Acks into each message, > potentially reducing the number of PacketAck messages being sent, which > means a potentially substantial protocol overhead reduction. > > This could also be implemented with backward compatibility by using a > new flag to indicate zerocoded appendedacks. There is another way that might be even more efficient, especially if/once most values are (much) larger than 256 but smaller than 16384; which seems to be a possibility in the future(?). This method works as follows: the first bit of every byte is flag, if the flag is set - then it's the last byte. Let p point the start of such an encoding, then you could decode it as follows: unsigned char* p = data; int count = 1; while (!(*p & 0x80)) { ++p; ++count; } unsigned long val = *p & 0x7f; while (--count) { val <<= 7; val |= *--p; } This would take: range #bytes 0-127 1 128-16383 2 16384-2097151 3 -- Carlo Wood From carlo at alinoe.com Thu Apr 2 07:51:06 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 2 Apr 2009 16:51:06 +0200 Subject: [sldev] AppendedAcks In-Reply-To: <49D3E772.1080804@lindenlab.com> References: <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com> Message-ID: <20090402145106.GB24161@alinoe.com> On Wed, Apr 01, 2009 at 03:15:14PM -0700, Philip Rosedale wrote: > I have a special place in my heart, though, for anyone who spots a case where > we are inefficiently sending data. We need every byte we can get, both in > terms of latency and total bandwidth implications. One project I'd love to get > to (and perhaps have community help with) is a careful examination of all > existing messages to look for bytes we could save. Hey - well, I know an obvious case where we can save lots and lots of bandwidth: Stop re-sending the same textures over and over again. I'm sure I have my cache not a single byte smaller than most people (I have the slider all the way to the max, 1 GB), but everytime I go to a new sim and then return home, everything is gray and apparently has to be re-downloaded. I frequent maybe 10 or so sims a lot - some more than others. And the textures that are in those sims have to be downloaded, again and again and again. I'm not the only one either. It is completely normal that friends (people who hang out in the same sims as me, and are all the time where I am) say "Sorry, still rezzing" after they arrive, and are zombies, waiting for the same data to have been downloaded, again, for a few minutes, before they see things. That this is necessary if I go to completely new sim that I just found with search, of course - but this shouldn't happen in places that I visit *every* day! One "solution" would be blow up the cache to huge sizes, but more logical would be to only blow it up to -say- five or ten times the size that is needed for all the textures in one sim, and somehow remember which sim a texture was download on. The client should keep track of the *sims* that are frequently visited and give textures that are downloaded on these sims a special priority and not erase them from the cache for textures with a lower priorty. In the simplest case, then priority could be single bit: 0 meaning "not frequently visited sim" and 1 meaning "frequently visited sim", but I'd prefer to make a difference between my home and a dancing that I visit maybe once a week too (meaning, the textures in my home should never be removed by textures from ANY other sim). So, I'd go for at least 2 bit. Thus, in pseudo-code, if (new texture not already in cache) { texture priority = priority of current region if (cache is full) { replace texture in cache with the lowest priority } } It appears to me that 1 GB is enough to contain all textures of one sim. I see no reason whatsoever to not increase the cache (with the above changes) to 10 GB. Why 1 GB is the *maximum* that is possible is beyond me. -- Carlo Wood From tom at streamsense.net Thu Apr 2 08:30:19 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu, 02 Apr 2009 16:30:19 +0100 Subject: [sldev] AgentSetAppearance Message-ID: <49D4DA0B.4090305@streamsense.net> Hey, I'm doing some work with the protocol, and i'm attempting to populate an AgentSetAppearance packet, however i'm not sure where to get the data from. How does a client populate the AgentSetAppearance packet, when the visualparams are unknown to it (and not available in a local datastore)? Or, how do I request an AvatarAppearance packet to be sent? Thanks ~T From robin.cornelius at gmail.com Thu Apr 2 08:51:39 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 2 Apr 2009 16:51:39 +0100 Subject: [sldev] AgentSetAppearance In-Reply-To: <49D4DA0B.4090305@streamsense.net> References: <49D4DA0B.4090305@streamsense.net> Message-ID: On Thu, Apr 2, 2009 at 4:30 PM, Thomas Grimshaw wrote: > Hey, > > I'm doing some work with the protocol, and i'm attempting to populate an > AgentSetAppearance packet, however i'm not sure where to get the data from. > > How does a client populate the AgentSetAppearance packet, when the > visualparams are unknown to it (and not available in a local datastore)? > > Or, how do I request an AvatarAppearance packet to be sent? > I recommend having a peek at the libomv AppearanceManager.cs class, it mostly works and does show the steps necessary to get an appearance set in world. But the steps in brief are :- Listen for a AgentWearablesUpdate, this contains assetIDs of current wearables Download Wearable all assets, you need these for various param settings and the textures later Check the bake hashes on the simulator and decide if you need to bake new nextures and upload the temporary assets or request cache bakes only Send Agent Is Now wearing, the list of currently worn wearables Now send the AgentSetAppearance packet, you need to iterate the current wearables to get certain parameters like shoe hight etc to set all the visual params correctly and set the currently worn/baked textures. This should then be enough info to sent the AgentSetAppearance packe back. * or something like this anyway Hope this in some way helpful ;-p Robin From JAR0727 at ecu.edu Thu Apr 2 09:59:06 2009 From: JAR0727 at ecu.edu (Regan, James A) Date: Thu, 2 Apr 2009 12:59:06 -0400 Subject: [sldev] e-mail Message-ID: Jar0727 at ecu.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090402/9c5abe63/attachment.htm From tateru.nino at gmail.com Thu Apr 2 10:27:50 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Fri, 03 Apr 2009 04:27:50 +1100 Subject: [sldev] AppendedAcks In-Reply-To: <20090402145106.GB24161@alinoe.com> References: <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com> <20090402145106.GB24161@alinoe.com> Message-ID: <49D4F596.2070200@gmail.com> Carlo Wood wrote: > On Wed, Apr 01, 2009 at 03:15:14PM -0700, Philip Rosedale wrote: > >> I have a special place in my heart, though, for anyone who spots a case where >> we are inefficiently sending data. We need every byte we can get, both in >> terms of latency and total bandwidth implications. One project I'd love to get >> to (and perhaps have community help with) is a careful examination of all >> existing messages to look for bytes we could save. >> > > Hey - well, I know an obvious case where we can save lots > and lots of bandwidth: > > Stop re-sending the same textures over and over again. > > I'm sure I have my cache not a single byte smaller than most > people (I have the slider all the way to the max, 1 GB), but > everytime I go to a new sim and then return home, everything > is gray and apparently has to be re-downloaded. > > I frequent maybe 10 or so sims a lot - some more than > others. And the textures that are in those sims have to > be downloaded, again and again and again. Concur. The discard algorithm seems to be *far* too agressive, and this issue keeps coming up over and over. From monitoring the viewer's activity, there are textures that get downloaded absurd numbers of times, and many times within comparatively short periods of time. Add another level of hash-buckets to the directory store, if there are performance issues in dealing with a single directory full of files, but the goal is to keep the content transfers to a minimum to accomplish the job, right? Saves bandwidth for all, and should reduce the impact on the grid. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090403/bdb7c3ae/attachment.htm From gareth at litesim.com Thu Apr 2 12:08:46 2009 From: gareth at litesim.com (Gareth Nelson) Date: Thu, 2 Apr 2009 20:08:46 +0100 Subject: [sldev] e-mail In-Reply-To: References: Message-ID: <61dbdd7d0904021208x67c8c71eq9160b8e6c75e045b@mail.gmail.com> Is this just a mistake or an attempt to subscribe to the list? On Thu, Apr 2, 2009 at 5:59 PM, Regan, James A wrote: > Jar0727 at ecu.edu > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From missannotoole at yahoo.com Thu Apr 2 12:12:34 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 2 Apr 2009 12:12:34 -0700 (PDT) Subject: [sldev] AppendedAcks In-Reply-To: <49D4F596.2070200@gmail.com> References: <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com> <20090402145106.GB24161@alinoe.com> <49D4F596.2070200@gmail.com> Message-ID: <332860.97221.qm@web59106.mail.re1.yahoo.com> RE: Texture Reloading You can stand still in a fairly empty skybox at 4000 meters and after so many minutes things have to reload. The cache doesn't work as expected at all. But it is doing something. I think issues like this need discourse with the LL person working it so they can hear what all is going on. Hey maybe we need to make twitter accounts for each issue and get a whole defect social network going so everyone can input observations. Something other than jira where defect reports go to die lol. Yea make jira work better via constant interaction by the people working on stuff so people like me won't be coming up with ideas like twittering defects rofl. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090402/98d8f28e/attachment.htm From merov at lindenlab.com Thu Apr 2 13:59:14 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 2 Apr 2009 13:59:14 -0700 Subject: [sldev] Texture caching [was: AppendedAcks] In-Reply-To: <49D4F596.2070200@gmail.com> References: <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com><20090402145106.GB24161@alinoe.com> <49D4F596.2070200@gmail.com> Message-ID: <3DE55F23-60AC-483C-938C-D2DD13B39EBD@lindenlab.com> Hi guys, Improving the texture cache performance is one of the things we want to get right in this new http-texture branch. There has been quite a bit of discussion on this and we haven't forgotten it (see http://wiki.secondlife.com/wiki/Talk:Texture_Cache) . There are a couple of changes being merged right now (CG working on it as I type) in the branch that are related to this. May be steve will tell us more about it (I don't want to say something stupid here before I have a chance to experiment with the new code myself). Anyway, yes, the discard algorithm has issues, the LRU is not adequate, we need cataloging of textures and these are all things we will be working on in the http-texture branch. Again, a massive change and a reason why we need to make that in the open. Cheers, - Merov On Apr 2, 2009, at 10:27 AM, Tateru Nino wrote: > Carlo Wood wrote: >> >> On Wed, Apr 01, 2009 at 03:15:14PM -0700, Philip Rosedale wrote: >> >>> I have a special place in my heart, though, for anyone who spots a >>> case where >>> we are inefficiently sending data. We need every byte we can get, >>> both in >>> terms of latency and total bandwidth implications. One project >>> I'd love to get >>> to (and perhaps have community help with) is a careful examination >>> of all >>> existing messages to look for bytes we could save. >>> >> Hey - well, I know an obvious case where we can save lots >> and lots of bandwidth: >> >> Stop re-sending the same textures over and over again. >> >> I'm sure I have my cache not a single byte smaller than most >> people (I have the slider all the way to the max, 1 GB), but >> everytime I go to a new sim and then return home, everything >> is gray and apparently has to be re-downloaded. >> >> I frequent maybe 10 or so sims a lot - some more than >> others. And the textures that are in those sims have to >> be downloaded, again and again and again. > Concur. The discard algorithm seems to be *far* too agressive, and > this issue keeps coming up over and over. From monitoring the > viewer's activity, there are textures that get downloaded absurd > numbers of times, and many times within comparatively short periods > of time. > > Add another level of hash-buckets to the directory store, if there > are performance issues in dealing with a single directory full of > files, but the goal is to keep the content transfers to a minimum to > accomplish the job, right? Saves bandwidth for all, and should > reduce the impact on the grid. From soft at lindenlab.com Thu Apr 2 14:04:07 2009 From: soft at lindenlab.com (Soft) Date: Thu, 2 Apr 2009 16:04:07 -0500 Subject: [sldev] AppendedAcks In-Reply-To: <49D4F596.2070200@gmail.com> References: <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com> <20090402145106.GB24161@alinoe.com> <49D4F596.2070200@gmail.com> Message-ID: On Thu, Apr 2, 2009 at 12:27 PM, Tateru Nino wrote: > Carlo Wood wrote: >> >> Hey - well, I know an obvious case where we can save lots >> and lots of bandwidth: >> >> Stop re-sending the same textures over and over again. >> >> I'm sure I have my cache not a single byte smaller than most >> people (I have the slider all the way to the max, 1 GB), but >> everytime I go to a new sim and then return home, everything >> is gray and apparently has to be re-downloaded. > > Concur. The discard algorithm seems to be *far* too agressive, and this > issue keeps coming up over and over. From monitoring the viewer's activity, > there are textures that get downloaded absurd numbers of times, and many > times within comparatively short periods of time. > > Add another level of hash-buckets to the directory store, if there are > performance issues in dealing with a single directory full of files, but the > goal is to keep the content transfers to a minimum to accomplish the job, > right? Saves bandwidth for all, and should reduce the impact on the grid. Are you certain these are cache misses? Superficially, the situation would look the same if the viewer only queued so many decode requests at a time, and all the queue slots were filled with network fetches. From maggie at matrisync.com Thu Apr 2 14:18:56 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Thu, 2 Apr 2009 17:18:56 -0400 Subject: [sldev] SLDev Digest, Vol 28, Issue 7 In-Reply-To: References: Message-ID: From: Tateru Nino Subject: Re: [sldev] AppendedAcks > Concur. The discard algorithm seems to be *far* too agressive, and this > issue keeps coming up over and over. From monitoring the viewer's > activity, there are textures that get downloaded absurd numbers of > times, and many times within comparatively short periods of time. > > Add another level of hash-buckets to the directory store, if there are > performance issues in dealing with a single directory full of files, but > the goal is to keep the content transfers to a minimum to accomplish the > job, right? Saves bandwidth for all, and should reduce the impact on the > grid. Something needs to be done about improving texture handling Real Soon Now. And not just for performance reasons, (although there's little excuse for needing to sit in a mall shop for five minutes while textures load to the point of legibility when I'm on 15/15 FiOS fiber). You may notice that ISPs are starting to get aggressive about monitoring and capping download volume, see http://tinyurl.com/cdpkz6 Retransferring the same image over and over again when most folks have bucketloads of cheap disk space for caching makes no sense. And when residents start getting dinged a buck every gig their download volume is over cap, this issue will surface like a breaching attack sub. From dmahalko at gmail.com Thu Apr 2 17:31:39 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu, 2 Apr 2009 19:31:39 -0500 Subject: [sldev] AppendedAcks In-Reply-To: <20090402145106.GB24161@alinoe.com> References: <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com> <20090402145106.GB24161@alinoe.com> Message-ID: On Thu, Apr 2, 2009 at 9:51 AM, Carlo Wood wrote: > I'm sure I have my cache not a single byte smaller than most > people (I have the slider all the way to the max, 1 GB), but > everytime I go to a new sim and then return home, everything > is gray and apparently has to be re-downloaded. > What you're seeing is discarding from the decompressed texture cache, not from the on-disk texture cache. There is a hidden texture cache in memory that never gets written to disk, which contains raw RGB bitmaps of the JPEG2000 data. It is never written to disk apparently for obfuscation purposes. I have never delved deep enough to determine if this raw bitmap cache is part of the 3D card's texture cache, or if it is an entire duplication of the 3D VRAM cache. So, you have the following hogging system memory with the client running: - Operating system - Client software - VFS cache that is held fully in memory all the time - Hidden decompressed raw bitmap texture cache of unknown size - (possibly separate?) 3D card texture caching When you teleport somewhere, it was previously reported by someone here on SLDev that the decompressed raw-bitmap image cache is completely dumped, and then the world must be completely re-decompressed from the JPEG2000's on disk, which is extremely slow and CPU intensive. This is why the world appears gray anytime you teleport. It simply threw all the previous decoded texture data away and starts redecoding anew. - Scalar Tardis / Dale Mahalko From teravus at gmail.com Thu Apr 2 20:52:08 2009 From: teravus at gmail.com (Teravus Ovares) Date: Thu, 2 Apr 2009 23:52:08 -0400 Subject: [sldev] AppendedAcks In-Reply-To: References: <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com> <20090402145106.GB24161@alinoe.com> Message-ID: <34cc66250904022052p7ee1e2eese926dfaf082825bd@mail.gmail.com> In testing with OpenSimulator, I note, that there doesn't seem to be a problem with the disk texture cache. In fact, the persistant cache often makes it more difficult to notice when there is a problem with the texture sender. People don't start noticing an issue until they clear their client cache. Before they do that, everything seems normal to the client even if the textures don't exist anymore. Best Regards Teravus On 4/2/09, Dale Mahalko wrote: > On Thu, Apr 2, 2009 at 9:51 AM, Carlo Wood wrote: > > I'm sure I have my cache not a single byte smaller than most > > people (I have the slider all the way to the max, 1 GB), but > > everytime I go to a new sim and then return home, everything > > is gray and apparently has to be re-downloaded. > > > > What you're seeing is discarding from the decompressed texture cache, > not from the on-disk texture cache. > > There is a hidden texture cache in memory that never gets written to > disk, which contains raw RGB bitmaps of the JPEG2000 data. It is never > written to disk apparently for obfuscation purposes. > > > I have never delved deep enough to determine if this raw bitmap cache > is part of the 3D card's texture cache, or if it is an entire > duplication of the 3D VRAM cache. > > So, you have the following hogging system memory with the client running: > - Operating system > - Client software > - VFS cache that is held fully in memory all the time > - Hidden decompressed raw bitmap texture cache of unknown size > - (possibly separate?) 3D card texture caching > > > When you teleport somewhere, it was previously reported by someone > here on SLDev that the decompressed raw-bitmap image cache is > completely dumped, and then the world must be completely > re-decompressed from the JPEG2000's on disk, which is extremely slow > and CPU intensive. > > This is why the world appears gray anytime you teleport. It simply > threw all the previous decoded texture data away and starts redecoding > anew. > > - Scalar Tardis / Dale Mahalko > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From chaosstar at gmail.com Fri Apr 3 00:30:21 2009 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 3 Apr 2009 09:30:21 +0200 Subject: [sldev] AppendedAcks In-Reply-To: <49D4BCD6.2060901@cox.net> References: <49D3C53C.90201@streamsense.net> <49D3E772.1080804@lindenlab.com> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> <9bb32d430904020002g5514ed9j6c7db0fa9382650a@mail.gmail.com> <49D4BCD6.2060901@cox.net> Message-ID: <9bb32d430904030030g36c3cd10t75eb61c4ca7ed0a@mail.gmail.com> > There's been much discussion on the MMOX mailing list about LLSD vs google > protocol buffers. > > I'm not sure that the rejection was concerning that particular form of > serialization or merely concerns > about insisting that we use that particular way of describing the > on-the-wire protocol. Sounds to me like a 'We're not sure if we want to use this, or if there is something better. We can't quite tell why, so better not change it.' thing ;P Seriously, compared to current LLSD I don't see a single disadvantage in the protocol buffers. It's less static, smaller, more flexible. All in all..more modern. I'm not sure how easily the EBML language that Thomas mentioned would be to implement. it certainly seems like an even bigger data/traffic-saver. The question is, how easily implementable it is, and how it fares in regards to unompression/decompression/translation time. > I see no reason whatsoever to not increase the cache > (with the above changes) to 10 GB. Why 1 GB is the > *maximum* that is possible is beyond me. The 1GB are the maximum that gets stored on hdd between restarts of the client. I think the limit was much higher once (10gb or so), before there was a notice about texture corruption, and it has been since lowered to those 1GB. I've not found any real issues with having it higher. As for files that are -not- stored (normally) on hdd between reboots, but get wiped...uncompressed sound files, prim data, etc. the limit is actually way higher than 1 GB. There, basically, is none. I've my client set up to keep the uncompressed sound files that normally get tossed out, and the cache folder is at around 15gb by now. Makes sound loading ALOT faster, but eats your hdd like popcorn. >I'm sure I have my cache not a single byte smaller than most >people (I have the slider all the way to the max, 1 GB), but >everytime I go to a new sim and then return home, everything >is gray and apparently has to be re-downloaded. If this is really the case, then there definitely is a bug somewhere. It shouldn't purge textures from cache on TP immediately. Download new ones, sure, but not purge others from the hdd cache and re-download if it hasn't hit the 1 GB limit. > I frequent maybe 10 or so sims a lot - some more than > others. And the textures that are in those sims have to > be downloaded, again and again and again. This really surprises me. The viewer should not purge those textures completely from the cache unless it hits that 1 GB cap. If it does, something is rather..wrong. From rdw at lindenlab.com Fri Apr 3 00:41:44 2009 From: rdw at lindenlab.com (Ryan Williams (Which)) Date: Fri, 03 Apr 2009 00:41:44 -0700 Subject: [sldev] AppendedAcks In-Reply-To: <9bb32d430904030030g36c3cd10t75eb61c4ca7ed0a@mail.gmail.com> References: <49D3C53C.90201@streamsense.net><49D3E772.1080804@linden lab.com> <49D3E82F.3010101@streamsense.net><49D4051D.1000701@cox.net><9bb32d 430904020002g5514ed9j6c7db0fa9382650a@mail.gmail.com><49D4BCD6.2060901@cox.net> <9bb32d430904030030g36c3cd10t75eb61c4ca7ed0a@mail.gmail.com> Message-ID: <49D5BDB8.5090900@lindenlab.com> On 4/3/09 12:30 AM, Ambrosia wrote: >> There's been much discussion on the MMOX mailing list about LLSD vs google >> protocol buffers. >> >> I'm not sure that the rejection was concerning that particular form of >> serialization or merely concerns >> about insisting that we use that particular way of describing the >> on-the-wire protocol. >> > > Sounds to me like a 'We're not sure if we want to use this, or if > there is something better. We can't quite tell why, so better not > change it.' thing ;P > > Seriously, compared to current LLSD I don't see a single disadvantage > in the protocol buffers. It's less static, smaller, more flexible. All > in all..more modern. > > I think you're confusing LLSD[1] with the Binary UDP Message System[2]. Different things for different use cases. [1] http://wiki.secondlife.com/wiki/LLSD [2] https://wiki.secondlife.com/wiki/Protocol#Binary_UDP From chaosstar at gmail.com Fri Apr 3 02:24:43 2009 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 3 Apr 2009 11:24:43 +0200 Subject: [sldev] AppendedAcks In-Reply-To: <49D5BDB8.5090900@lindenlab.com> References: <49D3C53C.90201@streamsense.net> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> <49D4BCD6.2060901@cox.net> <9bb32d430904030030g36c3cd10t75eb61c4ca7ed0a@mail.gmail.com> <49D5BDB8.5090900@lindenlab.com> Message-ID: <9bb32d430904030224j3c02fbf3tb620346357639e4e@mail.gmail.com> > I think you're confusing LLSD[1] with the Binary UDP Message System[2]. > ?Different things for different use cases. > > [1] http://wiki.secondlife.com/wiki/LLSD > [2] https://wiki.secondlife.com/wiki/Protocol#Binary_UDP > Indeed, I was referring to the latter. The former is what EBML might be a candidate for. From chaosstar at gmail.com Fri Apr 3 02:26:44 2009 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 3 Apr 2009 11:26:44 +0200 Subject: [sldev] AppendedAcks In-Reply-To: <9bb32d430904030224j3c02fbf3tb620346357639e4e@mail.gmail.com> References: <49D3C53C.90201@streamsense.net> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> <49D4BCD6.2060901@cox.net> <9bb32d430904030030g36c3cd10t75eb61c4ca7ed0a@mail.gmail.com> <49D5BDB8.5090900@lindenlab.com> <9bb32d430904030224j3c02fbf3tb620346357639e4e@mail.gmail.com> Message-ID: <9bb32d430904030226t3a14a950id15f0a45a2145d2@mail.gmail.com> > > Indeed, I was referring to the latter. The former is what EBML might > be a ?candidate for. > Then again, EBML is not as flexible. From tom at streamsense.net Fri Apr 3 02:51:38 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Fri, 03 Apr 2009 10:51:38 +0100 Subject: [sldev] AppendedAcks In-Reply-To: <9bb32d430904030226t3a14a950id15f0a45a2145d2@mail.gmail.com> References: <49D3C53C.90201@streamsense.net> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> <49D4BCD6.2060901@cox.net> <9bb32d430904030030g36c3cd10t75eb61c4ca7ed0a@mail.gmail.com> <49D5BDB8.5090900@lindenlab.com> <9bb32d430904030224j3c02fbf3tb620346357639e4e@mail.gmail.com> <9bb32d430904030226t3a14a950id15f0a45a2145d2@mail.gmail.com> Message-ID: <49D5DC2A.6070202@streamsense.net> We're generally aiming towards replacing the UDP binary transfer system entirely with HTTP / Caps, are we not? ~T Ambrosia wrote: >> Indeed, I was referring to the latter. The former is what EBML might >> be a candidate for. >> >> > > Then again, EBML is not as flexible. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From secret.argent at gmail.com Fri Apr 3 03:06:34 2009 From: secret.argent at gmail.com (Argent) Date: Fri, 3 Apr 2009 05:06:34 -0500 Subject: [sldev] AppendedAcks In-Reply-To: <49D5DC2A.6070202@streamsense.net> References: <49D3C53C.90201@streamsense.net> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> <49D4BCD6.2060901@cox.net> <9bb32d430904030030g36c3cd10t75eb61c4ca7ed0a@mail.gmail.com> <49D5BDB8.5090900@lindenlab.com> <9bb32d430904030224j3c02fbf3tb620346357639e4e@mail.gmail.com> <9bb32d430904030226t3a14a950id15f0a45a2145d2@mail.gmail.com> <49D5DC2A.6070202@streamsense.net> Message-ID: <16309a040904030306j7ee57d94ta7459b59bce1e025@mail.gmail.com> The on-disk texture cache could easily be simplified to a three level directory tree with no VFS shenanigans. This would allow arbitrarily large cache with no corruption issues, less space taken up in memory by VFS, and MASSIVELY fewer downloads. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090403/8ab494a8/attachment.htm From tateru.nino at gmail.com Fri Apr 3 09:01:28 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Sat, 04 Apr 2009 03:01:28 +1100 Subject: [sldev] AppendedAcks In-Reply-To: <16309a040904030306j7ee57d94ta7459b59bce1e025@mail.gmail.com> References: <49D3C53C.90201@streamsense.net> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> <49D4BCD6.2060901@cox.net> <9bb32d430904030030g36c3cd10t75eb61c4ca7ed0a@mail.gmail.com> <49D5BDB8.5090900@lindenlab.com> <9bb32d430904030224j3c02fbf3tb620346357639e4e@mail.gmail.com> <9bb32d430904030226t3a14a950id15f0a45a2145d2@mail.gmail.com> <49D5DC2A.6070202@streamsense.net> <16309a040904030306j7ee57d94ta7459b59bce1e025@mail.gmail.com> Message-ID: <49D632D8.7000901@weblogsinc.com> And we can lift some tried and true expiration algorithms from existing caching http proxies. Argent wrote: > The on-disk texture cache could easily be simplified to a three level > directory tree with no VFS shenanigans. This would allow arbitrarily > large cache with no corruption issues, less space taken up in memory > by VFS, and MASSIVELY fewer downloads. > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090404/f6698327/attachment.htm From robin.cornelius at gmail.com Fri Apr 3 07:00:55 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri, 3 Apr 2009 15:00:55 +0100 Subject: [sldev] [VWR[[PATCH] LLTextureCache::writeToCache() does not cache textures smaller than TEXTURE_CACHE_ENTRY_SIZE Message-ID: As discussed at Rob's hour yesterday, i've detected an issue with the texture caching that is preventing saving very small textures in to the cache. I've opened a JIRA and attached a patch to http://jira.secondlife.com/browse/VWR-12686. I'm well aware that the first 600 bytes are stored in an index file. but the code path i have identified will not make any attempt to save any data if the data is smaller than TEXTURE_CACHE_ENTRY_SIZE. It will just delete the WriteResponder and return. After the llTextureFetch has finished running and decoded it moves to state cache. this invokes LLtextureCache::WriteToCache() which is the only path of saving to the disk cache. I would quite like to commit this to http-texture as it seems very relevant to that branch currently as textures are the focus. So Merov, i think this is your area currently? Regards Robin From carlo at alinoe.com Fri Apr 3 05:53:55 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 3 Apr 2009 14:53:55 +0200 Subject: [sldev] AppendedAcks In-Reply-To: References: <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com> <20090402145106.GB24161@alinoe.com> Message-ID: <20090403125355.GA15677@alinoe.com> On Thu, Apr 02, 2009 at 07:31:39PM -0500, Dale Mahalko wrote: > When you teleport somewhere, it was previously reported by someone > here on SLDev that the decompressed raw-bitmap image cache is > completely dumped, and then the world must be completely > re-decompressed from the JPEG2000's on disk, which is extremely slow > and CPU intensive. > > This is why the world appears gray anytime you teleport. It simply > threw all the previous decoded texture data away and starts redecoding > anew. I can't believe that, since my system is extremely fast. It laughs when you mention 'cpu intensive'. Nevertheless, if this is really true then why is the viewer only using one of my CPU's? In the VERY least it could start using the other three while decompressing JPEG2000 images! But I see the viewer NEVER use more than one cpu. -- Carlo Wood From open at autistici.org Fri Apr 3 06:09:50 2009 From: open at autistici.org (Opensource Obscure) Date: Fri, 03 Apr 2009 13:09:50 +0000 Subject: [sldev] AppendedAcks In-Reply-To: <16309a040904030306j7ee57d94ta7459b59bce1e025@mail.gmail.com> References: <49D3C53C.90201@streamsense.net> <49D3E82F.3010101@streamsense.net> <49D4051D.1000701@cox.net> <49D4BCD6.2060901@cox.net> <9bb32d430904030030g36c3cd10t75eb61c4ca7ed0a@mail.gmail.com> <49D5BDB8.5090900@lindenlab.com> <9bb32d430904030224j3c02fbf3tb620346357639e4e@mail.gmail.com> <9bb32d430904030226t3a14a950id15f0a45a2145d2@mail.gmail.com> <49D5DC2A.6070202@streamsense.net> <16309a040904030306j7ee57d94ta7459b59bce1e025@mail.gmail.com> Message-ID: <28f7717071a193f1c659b829ed4df198@localhost> On Fri, 3 Apr 2009 05:06:34 -0500, Argent wrote: > The on-disk texture cache could easily be simplified to a three level > directory tree with no VFS shenanigans. This would allow arbitrarily large > cache with no corruption issues, less space taken up in memory by VFS, and > MASSIVELY fewer downloads. 'easily' means that you or someone else here could write a viewer patch that allows that? I'd be glad to test such a patch, do benchmarking and report results. I could do that for Linux and maybe Windows too. Opensource Obscure From robla at lindenlab.com Fri Apr 3 11:02:33 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 03 Apr 2009 11:02:33 -0700 Subject: [sldev] Tuesday Hippotropolis Meeting w/voice Message-ID: <49D64F39.90406@lindenlab.com> Hi folks, As a supplement to our normal weekly meetings on Thursdays, we'd like to have a one-time meeting using voice: Tuesday, 11am PDT Hippotropolis meeting area Philip and the crew will be there to talk about the new http-texture project and to fill in more detail about how we plan to work together. Rob From soft at lindenlab.com Fri Apr 3 11:08:22 2009 From: soft at lindenlab.com (Soft) Date: Fri, 3 Apr 2009 13:08:22 -0500 Subject: [sldev] Tuesday Hippotropolis Meeting w/voice In-Reply-To: <49D64F39.90406@lindenlab.com> References: <49D64F39.90406@lindenlab.com> Message-ID: On Fri, Apr 3, 2009 at 1:02 PM, Rob Lanphier wrote: > As a supplement to our normal weekly meetings on Thursdays, we'd like to > have a one-time meeting using voice: > > Tuesday, 11am PDT > Hippotropolis meeting area > > Philip and the crew will be there to talk about the new http-texture > project and to fill in more detail about how we plan to work together. This will be much like the Joe Linden or Kitware presentations. Text is totally okay for questions for those with no headsets or other voice objections/constraints. But please do try to have voice working for listening. From markl at lindenlab.com Fri Apr 3 11:24:11 2009 From: markl at lindenlab.com (Mark Lentczner) Date: Fri, 3 Apr 2009 11:24:11 -0700 Subject: [sldev] Zero's Office Hours, April 7th Message-ID: <14FA8471-0BA2-42C8-8A09-3BEA6AA50E69@lindenlab.com> My in-world (Second Life) office hours will be held next Tuesday, April 7th, from 1pm to 3pm. Please place agenda items for consideration on my wiki page: https://wiki.secondlife.com/wiki/User:Zero_Linden Preference will be given to agenda items with concrete technical discussion, especially those with written documentation available prior to the meeting. Please link documentation from the wiki page. For those that haven't attended before, my office hours are held once a month to discuss the development of the OGP protocol, and other technical issues about the architecture of systems that can/could support OGP. The discussion is held in Second Life, using text chat, and transcripts are published publicly (see the wiki page.) - Mark / Zero Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl at lindenlab.com Zero Linden zero.linden at secondlife.com From philip at lindenlab.com Fri Apr 3 12:16:03 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Fri, 03 Apr 2009 12:16:03 -0700 Subject: [sldev] [VWR[[PATCH] LLTextureCache::writeToCache() does not cache textures smaller than TEXTURE_CACHE_ENTRY_SIZE In-Reply-To: References: Message-ID: <49D66073.50903@lindenlab.com> This is exactly the kind of work we should all be doing together! We'll have a look right away at this one. Also, there are going to be a number of texture pipeline changes checked in by Bao in the next few days that will be important to examine. Also, if anyone wants to work on automated/instrumented testing of whether we are optimally downloading and displaying textures, go for it. It would be so great, for example, to have a repeatable test where we login to a known sim/content and measure the timing and performance of the texture system. P Robin Cornelius wrote: > As discussed at Rob's hour yesterday, i've detected an issue with the > texture caching that is preventing saving very small textures in to > the cache. > > I've opened a JIRA and attached a patch to > http://jira.secondlife.com/browse/VWR-12686. > > I'm well aware that the first 600 bytes are stored in an index file. > but the code path i have identified will not make any attempt to save > any data if the data is smaller than TEXTURE_CACHE_ENTRY_SIZE. It will > just delete the WriteResponder and return. After the llTextureFetch > has finished running and decoded it moves to state cache. this invokes > LLtextureCache::WriteToCache() which is the only path of saving to the > disk cache. > > I would quite like to commit this to http-texture as it seems very > relevant to that branch currently as textures are the focus. So Merov, > i think this is your area currently? > > Regards > > Robin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From merov at lindenlab.com Fri Apr 3 13:37:08 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 3 Apr 2009 13:37:08 -0700 Subject: [sldev] [VWR[[PATCH] LLTextureCache::writeToCache() does not cache textures smaller than TEXTURE_CACHE_ENTRY_SIZE In-Reply-To: References: Message-ID: <386D3918-8AE6-4281-8D92-A9F7745932FD@lindenlab.com> Hi Robin, Thanks for filing a JIRA and for the patch. I'll test and review within 48 hours. Cheers, - Merov On Apr 3, 2009, at 7:00 AM, Robin Cornelius wrote: > As discussed at Rob's hour yesterday, i've detected an issue with the > texture caching that is preventing saving very small textures in to > the cache. > > I've opened a JIRA and attached a patch to > http://jira.secondlife.com/browse/VWR-12686. > > I'm well aware that the first 600 bytes are stored in an index file. > but the code path i have identified will not make any attempt to save > any data if the data is smaller than TEXTURE_CACHE_ENTRY_SIZE. It will > just delete the WriteResponder and return. After the llTextureFetch > has finished running and decoded it moves to state cache. this invokes > LLtextureCache::WriteToCache() which is the only path of saving to the > disk cache. > > I would quite like to commit this to http-texture as it seems very > relevant to that branch currently as textures are the focus. So Merov, > i think this is your area currently? > > Regards > > Robin From merov at lindenlab.com Fri Apr 3 13:54:29 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 3 Apr 2009 13:54:29 -0700 Subject: [sldev] AppendedAcks In-Reply-To: <20090403125355.GA15677@alinoe.com> References: <49D3D0B7.9030906@streamsense.net> <49D3E772.1080804@lindenlab.com> <20090402145106.GB24161@alinoe.com> <20090403125355.GA15677@alinoe.com> Message-ID: <1EF8E28D-8D0B-460A-B501-91B14FB5069A@lindenlab.com> Hi Carlo, On Apr 3, 2009, at 5:53 AM, Carlo Wood wrote: > I can't believe that, since my system is extremely fast. It laughs > when you mention 'cpu intensive'. Nevertheless, if this is really > true then why is the viewer only using one of my CPU's? In the VERY > least it could start using the other three while decompressing > JPEG2000 images! But I see the viewer NEVER use more than one cpu. The odd thing is that the viewer is using threads to fetch and decode textures. There's actually a thread just for image decoding. That doesn't mean that this is making best use of the existing cpu on your machines though but, it should... One way though to turn the entire viewer into a single threaded app is to turn MEM_TRACK_MEM to true when building. This define is supposed to be used for tracking memory leaks and the like (if I'm reading the code correctly). It's not turned on in the svn repo but, in any case, if you are building your own viewer, you may want to check this just on the outside chance it's turned on. Cheers, - Merov From markl at lindenlab.com Fri Apr 3 17:13:02 2009 From: markl at lindenlab.com (Mark Lentczner) Date: Fri, 3 Apr 2009 17:13:02 -0700 Subject: [sldev] Zero's Office Hours, April 7th -- now with timezone info! Message-ID: D'oh, forgot the timezone info: My in-world (Second Life) office hours will be held next Tuesday, April 7th, from 1pm to 3pm ** PDT or UTC-0700 ** - Mark / Zero Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl at lindenlab.com Zero Linden zero.linden at secondlife.com From robla at lindenlab.com Fri Apr 3 17:19:13 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 03 Apr 2009 17:19:13 -0700 Subject: [sldev] [VWR[[PATCH] LLTextureCache::writeToCache() does notcache textures smaller than TEXTURE_CACHE_ENTRY_SIZE In-Reply-To: <386D3918-8AE6-4281-8D92-A9F7745932FD@lindenlab.com> References: <386D3918-8AE6-4281-8D92-A9F7745932FD@lindenlab.com> Message-ID: <49D6A781.4050908@lindenlab.com> Hi Robin, Any chance you (or someone) could make a unit test that tickles this bug? I suspect that'd really help out with the analysis. Rob On 04/03/2009 01:37 PM, Philippe Bossut (Merov Linden) wrote: > Hi Robin, > > Thanks for filing a JIRA and for the patch. I'll test and review > within 48 hours. > > Cheers, > - Merov > > On Apr 3, 2009, at 7:00 AM, Robin Cornelius wrote: > > >> As discussed at Rob's hour yesterday, i've detected an issue with the >> texture caching that is preventing saving very small textures in to >> the cache. >> >> I've opened a JIRA and attached a patch to >> http://jira.secondlife.com/browse/VWR-12686. >> >> I'm well aware that the first 600 bytes are stored in an index file. >> but the code path i have identified will not make any attempt to save >> any data if the data is smaller than TEXTURE_CACHE_ENTRY_SIZE. It will >> just delete the WriteResponder and return. After the llTextureFetch >> has finished running and decoded it moves to state cache. this invokes >> LLtextureCache::WriteToCache() which is the only path of saving to the >> disk cache. >> >> I would quite like to commit this to http-texture as it seems very >> relevant to that branch currently as textures are the focus. So Merov, >> i think this is your area currently? >> >> Regards >> >> Robin >> > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From alissa_sabre at yahoo.co.jp Fri Apr 3 19:39:29 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat, 04 Apr 2009 11:39:29 +0900 Subject: [sldev] tunk viewer build fails on MacOS In-Reply-To: References: <1kwz8zwwok5GJPGee.alissa_sabre@yahoo.co.jp> Message-ID: <90dsafo4ds4ds4ds4dxc8rio.alissa_sabre@yahoo.co.jp> > > ld: can't vm_allocate() buffer for output file of size 1130223472 ((os/kern) no space available) > Anyone have an idea of what could be going on here, without resorting > to chopping through trunk version builds? I heard no workaround/solution to this for a week, so I filed this issue on JIRA as VWR-12693. Alissa -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From schlenk at uni-oldenburg.de Sat Apr 4 04:03:13 2009 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Sat, 4 Apr 2009 13:03:13 +0200 Subject: [sldev] tunk viewer build fails on MacOS In-Reply-To: <90dsafo4ds4ds4ds4dxc8rio.alissa_sabre@yahoo.co.jp> References: <1kwz8zwwok5GJPGee.alissa_sabre@yahoo.co.jp> <90dsafo4ds4ds4ds4dxc8rio.alissa_sabre@yahoo.co.jp> Message-ID: <28C67935-75DA-453A-8EAE-8DD604B2E942@uni-oldenburg.de> Am 04.04.2009 um 04:39 schrieb Alissa Sabre: >>> ld: can't vm_allocate() buffer for output file of size 1130223472 >>> ((os/kern) no space available) > >> Anyone have an idea of what could be going on here, without resorting >> to chopping through trunk version builds? > > I heard no workaround/solution to this for a week, so I filed this > issue on JIRA as VWR-12693. Not sure if its related, but getting a crash in ld on OS X too, when trying to link (XCode 3.1.2, os 10.5, using llvm-g++-4.2), there ld dies with a BUS ERROR after churning away for a while and eating over 2 GB virtual memory, and close to the same amount of physical memory. I'll retry with a non-llvm build to see if that goes any better... Ld "/Users/schlenk/xcode/secondlife/svn/linden/indra/build-darwin-i386/ newview/Release/Second Life.app/Contents/MacOS/Second Life" normal i386 cd /Users/schlenk/xcode/secondlife/svn/linden/indra/build-darwin- i386 /Developer/usr/bin/llvm-g++-4.2 -arch i386 -L/Users/schlenk/xcode/ secondlife/svn/linden/indra/build-darwin-i386/newview/Release -L/Users/ schlenk/xcode/secondlife/svn/linden/indra/../libraries/universal- darwin/lib_release/Release -L/Users/schlenk/xcode/secondlife/svn/ linden/indra/../libraries/universal-darwin/lib_release -F/Users/ schlenk/xcode/secondlife/svn/linden/indra/build-darwin-i386/newview/ Release -filelist "/Users/schlenk/xcode/secondlife/svn/linden/indra/ build-darwin-i386/newview/SecondLife.build/Release/Second Life.build/ Objects-normal/i386/Second Life.LinkFileList" -Wl,- headerpad_max_install_names,-search_paths_first /Users/schlenk/xcode/ secondlife/svn/linden/indra/build-darwin-i386/llaudio/Release/ libllaudio.a /Users/schlenk/xcode/secondlife/svn/linden/indra/build- darwin-i386/llcharacter/Release/libllcharacter.a /Users/schlenk/xcode/ secondlife/svn/linden/indra/build-darwin-i386/llimage/Release/ libllimage.a /Users/schlenk/xcode/secondlife/svn/linden/indra/build- darwin-i386/llimagej2coj/Release/libllimagej2coj.a /Users/schlenk/ xcode/secondlife/svn/linden/indra/build-darwin-i386/llinventory/ Release/libllinventory.a /Users/schlenk/xcode/secondlife/svn/linden/ indra/build-darwin-i386/llmedia/Release/libllmedia.a /Users/schlenk/ xcode/secondlife/svn/linden/indra/build-darwin-i386/llmessage/Release/ libllmessage.a /Users/schlenk/xcode/secondlife/svn/linden/indra/build- darwin-i386/llprimitive/Release/libllprimitive.a /Users/schlenk/xcode/ secondlife/svn/linden/indra/build-darwin-i386/llrender/Release/ libllrender.a -lfreetype /Users/schlenk/xcode/secondlife/svn/linden/ indra/build-darwin-i386/llui/Release/libllui.a /Users/schlenk/xcode/ secondlife/svn/linden/indra/build-darwin-i386/llvfs/Release/ libllvfs.a /Users/schlenk/xcode/secondlife/svn/linden/indra/build- darwin-i386/llwindow/Release/libllwindow.a /Users/schlenk/xcode/ secondlife/svn/linden/indra/build-darwin-i386/llxml/Release/ libllxml.a /Users/schlenk/xcode/secondlife/svn/linden/indra/build- darwin-i386/lscript/lscript_compile/Release/liblscript_compile.a / Users/schlenk/xcode/secondlife/svn/linden/indra/build-darwin-i386/ lscript/lscript_execute/Release/liblscript_execute.a /Users/schlenk/ xcode/secondlife/svn/linden/indra/build-darwin-i386/lscript/ lscript_library/Release/liblscript_library.a /Users/schlenk/xcode/ secondlife/svn/linden/indra/build-darwin-i386/llmath/Release/ libllmath.a /Users/schlenk/xcode/secondlife/svn/linden/indra/build- darwin-i386/llcommon/Release/libllcommon.a -lndofdev -framework Cocoa - framework AGL -framework IOKit -lboost_program_options-mt - lboost_regex-mt -framework AGL -framework OpenGL /Users/schlenk/xcode/ secondlife/svn/linden/indra/build-darwin-i386/newview/Release/ libfmodwrapper.dylib -framework AGL -framework OpenGL /Users/schlenk/ xcode/secondlife/svn/linden/indra/../libraries/universal-darwin/ lib_release/libllmozlib2.dylib -framework QuickTime -lxmlrpc-epi - lvorbisenc -lvorbisfile -lvorbis -logg /Users/schlenk/xcode/secondlife/ svn/linden/indra/../libraries/universal-darwin/lib_release/liblljpeg.a -lpng12 -lopenjpeg -lcurl /Users/schlenk/xcode/secondlife/svn/linden/ indra/../libraries/universal-darwin/lib_release/libcares.a -lssl - lllcrypto -framework IOKit -lboost_program_options-mt -lboost_regex- mt /Users/schlenk/xcode/secondlife/svn/linden/indra/../libraries/ universal-darwin/lib_release/libllmozlib2.dylib -framework QuickTime - lxmlrpc-epi -lboost_signals-mt /Users/schlenk/xcode/secondlife/svn/ linden/indra/../libraries/universal-darwin/lib_release/libaprutil-1.a / Users/schlenk/xcode/secondlife/svn/linden/indra/../libraries/universal- darwin/lib_release/libapr-1.a -lz -lexpat /Users/schlenk/xcode/ secondlife/svn/linden/libraries/universal-darwin/lib_release/libfmod.a -framework Carbon -o "/Users/schlenk/xcode/secondlife/svn/linden/indra/ build-darwin-i386/newview/Release/Second Life.app/Contents/MacOS/ Second Life" collect2: ld terminated with signal 10 [Bus error] From carlo at alinoe.com Sat Apr 4 07:16:56 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 4 Apr 2009 16:16:56 +0200 Subject: [sldev] [VWR[[PATCH] LLTextureCache::writeToCache() does notcache textures smaller than TEXTURE_CACHE_ENTRY_SIZE In-Reply-To: <49D6A781.4050908@lindenlab.com> References: <386D3918-8AE6-4281-8D92-A9F7745932FD@lindenlab.com> <49D6A781.4050908@lindenlab.com> Message-ID: <20090404141656.GA20369@alinoe.com> I'm not so sure this is a bug... Isn't the cache using a limit on the number of textures it saves? Or is it purely the total size of all textures together? If it's the first, then it would make sense to not store small textures in order to make room for larger ones. That being said, if that is the intention then it's the most broken "algorithm" I've ever seen, lol. On Fri, Apr 03, 2009 at 05:19:13PM -0700, Rob Lanphier wrote: > Hi Robin, > > Any chance you (or someone) could make a unit test that tickles this > bug? I suspect that'd really help out with the analysis. > > Rob > > On 04/03/2009 01:37 PM, Philippe Bossut (Merov Linden) wrote: > > Hi Robin, > > > > Thanks for filing a JIRA and for the patch. I'll test and review > > within 48 hours. > > > > Cheers, > > - Merov > > > > On Apr 3, 2009, at 7:00 AM, Robin Cornelius wrote: > > > > > >> As discussed at Rob's hour yesterday, i've detected an issue with the > >> texture caching that is preventing saving very small textures in to > >> the cache. > >> > >> I've opened a JIRA and attached a patch to > >> http://jira.secondlife.com/browse/VWR-12686. > >> > >> I'm well aware that the first 600 bytes are stored in an index file. > >> but the code path i have identified will not make any attempt to save > >> any data if the data is smaller than TEXTURE_CACHE_ENTRY_SIZE. It will > >> just delete the WriteResponder and return. After the llTextureFetch > >> has finished running and decoded it moves to state cache. this invokes > >> LLtextureCache::WriteToCache() which is the only path of saving to the > >> disk cache. > >> > >> I would quite like to commit this to http-texture as it seems very > >> relevant to that branch currently as textures are the focus. So Merov, > >> i think this is your area currently? > >> > >> Regards > >> > >> Robin > >> > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting privileges > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From merov at lindenlab.com Sat Apr 4 18:35:36 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Sat, 4 Apr 2009 18:35:36 -0700 Subject: [sldev] [VWR[[PATCH] LLTextureCache::writeToCache() does notcache textures smaller than TEXTURE_CACHE_ENTRY_SIZE In-Reply-To: <386D3918-8AE6-4281-8D92-A9F7745932FD@lindenlab.com> References: <386D3918-8AE6-4281-8D92-A9F7745932FD@lindenlab.com> Message-ID: Hi Robin, I reviewed the patch and commented in the JIRA. The skinny: I think you're right, there's definitely something fishy there as the doWrite() on the worker does take care of writing the header. There is actually another piece of code in the doWrite() that is also weird as I mentioned in the JIRA. Looking at it, that's a classic case of unclear separation of concerns between a collection of objects. (/me chanting "unit test! unit test!") In any case, I'll check Monday first thing on my office's machine (better dev environment than I have at home...) and we'll get to the bottom of this. Thanks for the hawk eye! :) Cheers, - Merov On Apr 3, 2009, at 1:37 PM, Philippe Bossut (Merov Linden) wrote: > Hi Robin, > > Thanks for filing a JIRA and for the patch. I'll test and review > within 48 hours. > > Cheers, > - Merov > > On Apr 3, 2009, at 7:00 AM, Robin Cornelius wrote: > >> As discussed at Rob's hour yesterday, i've detected an issue with the >> texture caching that is preventing saving very small textures in to >> the cache. >> >> I've opened a JIRA and attached a patch to >> http://jira.secondlife.com/browse/VWR-12686. >> >> I'm well aware that the first 600 bytes are stored in an index file. >> but the code path i have identified will not make any attempt to save >> any data if the data is smaller than TEXTURE_CACHE_ENTRY_SIZE. It >> will >> just delete the WriteResponder and return. After the llTextureFetch >> has finished running and decoded it moves to state cache. this >> invokes >> LLtextureCache::WriteToCache() which is the only path of saving to >> the >> disk cache. >> >> I would quite like to commit this to http-texture as it seems very >> relevant to that branch currently as textures are the focus. So >> Merov, >> i think this is your area currently? >> >> Regards >> >> Robin > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From alissa_sabre at yahoo.co.jp Sat Apr 4 20:27:48 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun, 05 Apr 2009 12:27:48 +0900 Subject: [sldev] Build procedure for viewer from svn trunk? In-Reply-To: <200903220046.33366.johnniecarling@gmail.com> References: <200903220046.33366.johnniecarling@gmail.com> Message-ID: <74dx4Gcadx4e04ds4s0udz60.alissa_sabre@yahoo.co.jp> > > Where are the artwork files that match with the trunc viewer? What is > > the appropriate procedure to build the viewer from svn trunk? > > You can find the URLs in /doc/asset_urls.txt The procedure Johnnie taught me worked fine until recently. I grabbed the HEAD of the public svn trunk code (r2048), and found that the artwork file pointed to by the doc/asset_urls.txt in that revision, slviewer-artwork-trunk-r116340.zip, lacks several files that are referred to by indra/newview/CMakeLists.txt, and the develop.py fails. Is this "Hey, its's usual. Just ignore such errors when you use trunk source."-type of issue? Or, should I file this on JIRA? Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From robla at lindenlab.com Sat Apr 4 21:16:59 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Sat, 04 Apr 2009 21:16:59 -0700 Subject: [sldev] Build procedure for viewer from svn trunk? In-Reply-To: <74dx4Gcadx4e04ds4s0udz60.alissa_sabre@yahoo.co.jp> References: <200903220046.33366.johnniecarling@gmail.com> <74dx4Gcadx4e04ds4s0udz60.alissa_sabre@yahoo.co.jp> Message-ID: <49D830BB.6080709@lindenlab.com> On 04/04/2009 08:27 PM, Alissa Sabre wrote: > I grabbed the HEAD of the public svn trunk code (r2048), and found > that the artwork file pointed to by the doc/asset_urls.txt in that > revision, slviewer-artwork-trunk-r116340.zip, lacks several files that > are referred to by indra/newview/CMakeLists.txt, and the develop.py > fails. > > Is this "Hey, its's usual. Just ignore such errors when you use > trunk source."-type of issue? Or, should I file this on JIRA? > It's almost always worth noting errors in JIRA. Is the correct fix for this removing some files from the CMakeLists.txt file (a low priority problem), or are these newly added files that just haven't been exported yet (a higher priority problem)? Rob From alissa_sabre at yahoo.co.jp Sun Apr 5 00:19:02 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sun, 05 Apr 2009 16:19:02 +0900 Subject: [sldev] artwork-common bundle (was: Build procedure for viewer from svn trunk?) In-Reply-To: <49D830BB.6080709@lindenlab.com> References: <200903220046.33366.johnniecarling@gmail.com> <74dx4Gcadx4e04ds4s0udz60.alissa_sabre@yahoo.co.jp> <49D830BB.6080709@lindenlab.com> Message-ID: > > I grabbed the HEAD of the public svn trunk code (r2048), and found > > that the artwork file pointed to by the doc/asset_urls.txt in that > > revision, slviewer-artwork-trunk-r116340.zip, lacks several files that > > are referred to by indra/newview/CMakeLists.txt, and the develop.py > > fails. > It's almost always worth noting errors in JIRA. Is the correct fix for > this removing some files from the CMakeLists.txt file (a low priority > problem), or are these newly added files that just haven't been exported > yet (a higher priority problem)? Neither. Ater seding the last message, I found that the cause of the problem I experienced was: - Several files were moved from slviewer-artwork-*.zip file to artwork-common-*.tar.bz2 file, somewhere between r1928 and r2048 (in public svn trunk.) - The new artwork-common-*.tar.bz2 file is listed in install.xml (in the trunk source tree) with other 3rd party libraries. - I tried a standalone build, so install.xml was not used and some artwork files were missing. Does this mean the contents of the artwork-common file will soon be included in major Linux distributions as a standard package? :-) I filed this issue, modified by new findings, as VWR-12708 on JIRA. Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From drakth at gmail.com Sun Apr 5 03:29:27 2009 From: drakth at gmail.com (Matias A. V.) Date: Sun, 05 Apr 2009 07:29:27 -0300 Subject: [sldev] CMake error Message-ID: <49D88807.7030207@gmail.com> When running cmake im getting this error: C:\Dev\1.22.9\linden\indra>python develop.py -G VC80 Running 'cmake -G "Visual Studio 8 2005" -DSTANDALONE:BOOL=OFF -DUNATTENDED:BOOL=OFF "" "C:\\Dev\\1.22.9\\linden\\indra"' in 'build-VC80' -- Check for working C compiler: cl -- Check for working C compiler: cl -- works -- Check size of void* -- Check size of void* - done -- Check for working CXX compiler: cl -- Check for working CXX compiler: cl -- works Traceback (most recent call last): File "install.py", line 62, in ? from indra.base import llsd File "C:\Dev\1.22.9\linden\indra\lib\python\indra\base\llsd.py", line 36, in ? from indra.util.fastest_elementtree import ElementTreeError, fromstring File "C:\Dev\1.22.9\linden\indra\lib\python\indra\util\fastest_elementtree.py" , line 62, in ? from xml.etree.ElementTree import * ImportError: No module named etree.ElementTree CMake Error: Failed to download or unpack prebuilt 'ogg-vorbis'. Process returne d 1. -- Configuring done Cleaning 'build-VC80' Error: the command 'cmake' exited with -1 Any ideas?? Thanks. From sllists at boroon.dasgupta.ch Sun Apr 5 04:18:25 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sun, 05 Apr 2009 13:18:25 +0200 Subject: [sldev] CMake error In-Reply-To: <49D88807.7030207@gmail.com> References: <49D88807.7030207@gmail.com> Message-ID: <49D89381.5010901@boroon.dasgupta.ch> Matias A. V. schrieb: > "C:\Dev\1.22.9\linden\indra\lib\python\indra\util\fastest_elementtree.py" > , line 62, in ? > from xml.etree.ElementTree import * > ImportError: No module named etree.ElementTree This looks similar to https://lists.secondlife.com/pipermail/sldev/2008-July/011080.html You're probably missing the ElementTree python API. It's included in python 2.5 and newer, so try upgrading your python installation. I hope this helps Boroondas From blindwanderer at gmail.com Sun Apr 5 05:28:02 2009 From: blindwanderer at gmail.com (Strife Onizuka) Date: Sun, 5 Apr 2009 08:28:02 -0400 Subject: [sldev] New LSL Feature Idea... bool typecast Message-ID: <89ca6da00904050528m444b359ei9edc2fbc0d264d23@mail.gmail.com> LSL doesn't have a dedicated bool type but when you use any type with a conditional, it gets implicitly cast to a bool. Having this functionality is nice but it's limitations are annoying. After giving the problem some thought I came up with this solution: http://jira.secondlife.com/browse/SVC-4068 It's a bool typecast, it might not be the best solution but it should work. I've included both LSO and Mono implementations that *should* work... asuming i haven't forgotten something important. My ability to actually apply my patch and build with it are non-existant at the present. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090405/4a5814e8/attachment.htm From open at autistici.org Sun Apr 5 06:11:27 2009 From: open at autistici.org (Opensource Obscure) Date: Sun, 05 Apr 2009 13:11:27 +0000 Subject: [sldev] =?utf-8?q?=5BWEB=5D_=5BHELP=5D_How_do_I_unlink_PJIRA_issu?= =?utf-8?b?ZXM/?= Message-ID: <5fc4c79e954309a1a230d837b43b9596@localhost> Is it possible for normal PJIRA users to unlink two issues? If yes, how can I do that? (Editing the issue in Basic or Advanced Mode doesn't seem to allow this) I marked http://jira.secondlife.com/browse/VWR-6189 as a duplicate of http://jira.secondlife.com/browse/VWR-7677 by error, while it should simply 'relate' to it. If I'm not supposed to have powers to do that myself, someone please delete that relationship and let me know. Thanks. ciao Opensource Obscure From latifer at streamgrid.net Sun Apr 5 06:20:37 2009 From: latifer at streamgrid.net (Latif Khalifa) Date: Sun, 5 Apr 2009 15:20:37 +0200 Subject: [sldev] [WEB] [HELP] How do I unlink PJIRA issues? In-Reply-To: <5fc4c79e954309a1a230d837b43b9596@localhost> References: <5fc4c79e954309a1a230d837b43b9596@localhost> Message-ID: <5ebce2ec0904050620y2c3e4a2cqa3ff59ae48a7df23@mail.gmail.com> Yes, click on the link "Issue Links:" left of the list of links themselves. (http://jira.secondlife.com/secure/ManageLinks.jspa?id=20956) -- L On Sun, Apr 5, 2009 at 3:11 PM, Opensource Obscure wrote: > > Is it possible for normal PJIRA users to unlink two issues? > If yes, how can I do that? (Editing the issue in Basic or > Advanced Mode doesn't seem to allow this) > > I marked http://jira.secondlife.com/browse/VWR-6189 as a duplicate > of http://jira.secondlife.com/browse/VWR-7677 by error, while it > should simply 'relate' to it. > > If I'm not supposed to have powers to do that myself, someone please > delete that relationship and let me know. Thanks. > > ciao > Opensource Obscure > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From open at autistici.org Sun Apr 5 06:50:44 2009 From: open at autistici.org (Opensource Obscure) Date: Sun, 05 Apr 2009 13:50:44 +0000 Subject: [sldev] Windlight / Making easier use of Sky Presets Message-ID: <5300b6e3240ed72b395aeb21b5d5ceda@localhost> I made some linking between issues about server-side management of sky settings and other 'Windlight' things. Meta-Issue : Estate Improvements http://jira.secondlife.com/browse/SVC-541 Estate / Sim Windlight preset / day cycle options http://jira.secondlife.com/browse/VWR-7677 The Windlight Project is unfinished http://jira.secondlife.com/browse/SVC-2736 Please read/comment/vote as you feel appropriate on http://jira.secondlife.com/browse/VWR-7677 and related issues. Personally I think that the most important issue is described by Lex Neva in the first comment at http://jira.secondlife.com/browse/SVC-2736 What is the status of this topic as a whole? Did anyone work on it at Linden Lab since last year? An idea: what about creating a new GUI widget that lets users choose Sky Presets more easily than the current 5-steps way e.g. World > Env.Settings > Env.Editor > Adv.Sky > Sky Presets ? Then at least land managers could suggest to visitors which Sky preset to choose, and visitors could do it more easily. Or, in alternative, a new shortcut that directly opens the Sky Presets floater may do the trick as well. I quickly tried to do that myself by reading wiki instructions and modifying XML files, but I had no luck yet. This wouldn't solve the issue of custom presets - but it may be an easier task to accomplish as (I think) it wouldn't require heavy reworking of the whole subsystem. Maybe an idea for the open source project? (note - I didn't found an existing specific PJIRA issue about this idea and I did not create one yet) ciao Opensource Obscure From carlo at alinoe.com Sun Apr 5 07:13:04 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sun, 5 Apr 2009 16:13:04 +0200 Subject: [sldev] Estate Manager are not able to upload and download RAW terrain files Message-ID: <20090405141304.GA3607@alinoe.com> What is the status on this issue? See http://jira.secondlife.com/browse/SVC-925 It should be extremely easy to fix this; there are are 37 voters, which is pretty high for something only Estate managers would vote for. The Bug is listed as *critical* and is now 1.5 YEARS old :( Assignee: Unassigned It can't take longer than 10 minutes to fix this? -- Carlo Wood From soft at lindenlab.com Sun Apr 5 08:57:35 2009 From: soft at lindenlab.com (Soft) Date: Sun, 5 Apr 2009 10:57:35 -0500 Subject: [sldev] artwork-common bundle (was: Build procedure for viewer fromsvn trunk?) In-Reply-To: References: <200903220046.33366.johnniecarling@gmail.com> <74dx4Gcadx4e04ds4s0udz60.alissa_sabre@yahoo.co.jp> <49D830BB.6080709@lindenlab.com> Message-ID: On Sun, Apr 5, 2009 at 2:19 AM, Alissa Sabre wrote: >> > I grabbed the HEAD of the public svn trunk code (r2048), and found >> > that the artwork file pointed to by the doc/asset_urls.txt in that >> > revision, slviewer-artwork-trunk-r116340.zip, lacks several files that >> > are referred to by indra/newview/CMakeLists.txt, and the develop.py >> > fails. > >> It's almost always worth noting errors in JIRA. Is the correct fix for >> this removing some files from the CMakeLists.txt file (a low priority >> problem), or are these newly added files that just haven't been exported >> yet (a higher priority problem)? > > Neither. > > Ater seding the last message, I found that the cause of the problem I > experienced was: > > - Several files were moved from slviewer-artwork-*.zip file to > ?artwork-common-*.tar.bz2 file, somewhere between r1928 and r2048 (in > ?public svn trunk.) > > - The new artwork-common-*.tar.bz2 file is listed in install.xml (in > ?the trunk source tree) with other 3rd party libraries. > > - I tried a standalone build, so install.xml was not used and some > ?artwork files were missing. > > Does this mean the contents of the artwork-common file will soon be > included in major Linux distributions as a standard package? :-) > > I filed this issue, modified by new findings, as VWR-12708 on JIRA. Thanks. I'll import this and pass it on to the responsible dev who realllllly shouldn't have been doing this directly in trunk. From kf6kjg at gmail.com Sun Apr 5 09:27:19 2009 From: kf6kjg at gmail.com (Ricky) Date: Sun, 5 Apr 2009 09:27:19 -0700 Subject: [sldev] New LSL Feature Idea... bool typecast In-Reply-To: <89ca6da00904050528m444b359ei9edc2fbc0d264d23@mail.gmail.com> References: <89ca6da00904050528m444b359ei9edc2fbc0d264d23@mail.gmail.com> Message-ID: <3bb9647e0904050927p2ea72c4fraaf2b403f3e1bbc0@mail.gmail.com> Not sure of the use cases for this, but my full comment is on the JIRA entry. Ricky aka Cron Stardust On Sun, Apr 5, 2009 at 5:28 AM, Strife Onizuka wrote: > LSL doesn't have a dedicated bool type but when you use any type with a > conditional, it gets implicitly cast to a bool. Having this functionality is > nice but it's limitations are annoying. > > After giving the problem some thought I came up with this solution: > http://jira.secondlife.com/browse/SVC-4068 > > It's a bool typecast, it might not be the best solution but it should work. > I've included both LSO and Mono implementations that *should* work... > asuming i haven't forgotten something important. My ability to actually > apply my patch and build with it are non-existant at the present. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090405/334ffec6/attachment.htm From robin.cornelius at gmail.com Sun Apr 5 11:39:50 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sun, 05 Apr 2009 19:39:50 +0100 Subject: [sldev] [VWR[[PATCH] LLTextureCache::writeToCache() does notcache textures smaller than TEXTURE_CACHE_ENTRY_SIZE In-Reply-To: References: <386D3918-8AE6-4281-8D92-A9F7745932FD@lindenlab.com> Message-ID: <49D8FAF6.6000503@gmail.com> Philippe Bossut (Merov Linden) wrote: > Hi Robin, > > I reviewed the patch and commented in the JIRA. The skinny: I think > you're right, there's definitely something fishy there as the > doWrite() on the worker does take care of writing the header. There is > actually another piece of code in the doWrite() that is also weird as > I mentioned in the JIRA. Looking at it, that's a classic case of > unclear separation of concerns between a collection of objects. (/me > chanting "unit test! unit test!") As i mentioed on the JIRA comment, i did most testing on 1.22.11 which does not have the 2nd code that you found, so thats an additional problem that has very recently been introduced. As for the unit tests, they don't appear to be in a great shape for outside of LL builds currently. Although you have a couple working the majority in test are not even included in the (exported) CMake rules and they seem to require quite a bit of TLC to build, I've given up for the moment. But will have to play a lot more. > > In any case, I'll check Monday first thing on my office's machine > (better dev environment than I have at home...) and we'll get to the > bottom of this. Thanks Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090405/9eb7f0e0/attachment.pgp From stickman at gmail.com Sun Apr 5 15:23:46 2009 From: stickman at gmail.com (Stickman) Date: Sun, 5 Apr 2009 15:23:46 -0700 Subject: [sldev] Estate Manager are not able to upload and download RAW terrain files In-Reply-To: <20090405141304.GA3607@alinoe.com> References: <20090405141304.GA3607@alinoe.com> Message-ID: Soft replied on Jira. Response summary: Terrain upload has a built-in support cost. Get more votes to convince us it's worth it. Quoted from Jira: ------- Soft Linden added a comment - 05/Apr/09 08:25 AM Carlo posted on the open source list, but this isn't an open source issue, so I thought I'd reply here. I see no internal activity, save some discussion about how much it would increase support loads. Estate owners upload bad terrain files and cause all or most objects on a sim to get returned, then file emergency tickets. The impact would be multiplied if more people had access to the feature, so the development time is just a tiny percentage of the cost. I'd fish for more votes if you think there's demand sufficient to convince the land team. They'd make the call on this. [ Permlink | ? Hide ] Soft Linden added a comment - 05/Apr/09 08:28 AM Lowering to normal priority. Critical and showstopper are really reserved for things that fundamentally break SL for most users. Experience says shooting for lots of votes at a realistic priority is more likely to convince the land guys. From merov at lindenlab.com Sun Apr 5 16:30:25 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Sun, 5 Apr 2009 16:30:25 -0700 Subject: [sldev] [VWR[[PATCH] LLTextureCache::writeToCache() does notcache textures smaller than TEXTURE_CACHE_ENTRY_SIZE In-Reply-To: <49D8FAF6.6000503@gmail.com> References: <386D3918-8AE6-4281-8D92-A9F7745932FD@lindenlab.com> <49D8FAF6.6000503@gmail.com> Message-ID: <16514E30-67B7-4A34-8E9C-E8D3AF643646@lindenlab.com> Hi Robin, On Apr 5, 2009, at 11:39 AM, Robin Cornelius wrote: > As for the unit tests, they don't appear to be in a great shape for > outside of LL builds currently. Although you have a couple working the > majority in test are not even included in the (exported) CMake rules > and > they seem to require quite a bit of TLC to build, I've given up for > the > moment. But will have to play a lot more. I wasn't blaming you a second for the lack of unit test! That chant for mostly for me and my fellow Lindens. This is something we are trying to get right now but it takes a lot of effort and sometimes we wonder if those would ever catch anything serious. In that case, I do think though that this particular bug would have been caught by unit tests on lltexturecache.cpp if we had written any (in that case, cache a small texture, verify that you can access it using its UUID, this would have failed right there). But you're right, I should write this one as an example rather than ranting about it :) Cheers, - Merov From carlo at alinoe.com Mon Apr 6 10:55:34 2009 From: carlo at alinoe.com (Carlo Wood) Date: Mon, 6 Apr 2009 19:55:34 +0200 Subject: [sldev] openjpeg bug on 64bit Message-ID: <20090406175534.GA7852@alinoe.com> Hey Callum, can you have a look at this bug and write a patch for it? http://groups.google.com/group/openjpeg/browse_thread/thread/4683bba9660c2779 -- Carlo Wood From lev.neiman at gmail.com Mon Apr 6 13:31:36 2009 From: lev.neiman at gmail.com (Lev Neiman) Date: Mon, 6 Apr 2009 16:31:36 -0400 Subject: [sldev] weird llviewerinventory.h include problem Message-ID: Hello. I have successfully downloaded 1.22.11 source code and compiled it using VS2005 on WinXP machine. However I have ran into a weird problem. If I include a #include "llviewerinventory.h" it generates a whole bunch of error messages in compiler. Here is what they are: 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : error C2220: warning treated as error - no 'object' file generated 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(151) : error C2061: syntax error : identifier 'LLFILE' 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(152) : error C2061: syntax error : identifier 'LLFILE' 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(152) : error C2059: syntax error : ')' 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(152) : error C2143: syntax error : missing ')' before ';' 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d ide\new sl en\sl_1_22_11\linden\indra\llinventory\llpermissions.h(305) : error C2061: syntax error : identifier 'LLFILE' 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d ide\new sl en\sl_1_22_11\linden\indra\llinventory\llpermissions.h(306) : error C2061: syntax error : identifier 'LLFILE' 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d ide\new sl en\sl_1_22_11\linden\indra\llinventory\llpermissions.h(364) : fatal error C1903: unable to recover from previous error(s); stopping compilation If I omitt the include then everything compiles fine. I am talking about including this just from an otherwise empty .h file (with macroguards). It wasn't empty originally but I commented everything out to find source of the problem, and the source is definetly this line that includes llviewerinventory.h Any help is highly appreciated. Sincerely, Lev A. Neiman. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090406/ee2d8fc3/attachment.htm From blakar at gmail.com Mon Apr 6 13:52:04 2009 From: blakar at gmail.com (Dirk Moerenhout) Date: Mon, 6 Apr 2009 22:52:04 +0200 Subject: [sldev] weird llviewerinventory.h include problem In-Reply-To: References: Message-ID: <7992d0d60904061352l392c3167q8363303ea039731f@mail.gmail.com> It stops here for sure: 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : error C2220: warning treated as error - no 'object' file generated 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : warning C4996: 'strncpy': This function or variable may be unsafe. Consider using strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. As you can see both of these refer to line 68. The first says it treats the warning as an error and will hence not give an object file. The second gives you the warning and possible solutions. Dirk Moerenhout aka Blakar Ogre On Mon, Apr 6, 2009 at 10:31 PM, Lev Neiman wrote: > Hello. ?I have successfully downloaded?1.22.11 source code and compiled it > using VS2005 on WinXP machine. ?However I have ran into a weird problem. ?If > I include a #include "llviewerinventory.h" it generates a whole bunch of > error messages in compiler. > Here is what they are: > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : error > C2220: warning treated as error - no 'object' file generated > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : warning > C4996: 'strncpy': This function or variable may be unsafe. Consider using > strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See > online help for details. > 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d > IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(151) : error C2061: > syntax error : identifier 'LLFILE' > 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d > IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(152) : error C2061: > syntax error : identifier 'LLFILE' > 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d > IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(152) : error C2059: > syntax error : ')' > 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d > IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(152) : error C2143: > syntax error : missing ')' before ';' > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > ide\new sl en\sl_1_22_11\linden\indra\llinventory\llpermissions.h(305) : > error C2061: syntax error : identifier 'LLFILE' > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > ide\new sl en\sl_1_22_11\linden\indra\llinventory\llpermissions.h(306) : > error C2061: syntax error : identifier 'LLFILE' > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > ide\new sl en\sl_1_22_11\linden\indra\llinventory\llpermissions.h(364) : > fatal error C1903: unable to recover from previous error(s); stopping > compilation > If I omitt the include then everything compiles fine. ?I am talking about > including this just from an otherwise empty .h file (with macroguards). ?It > wasn't empty originally but I commented everything out to find source of the > problem, and the source is definetly this line that > includes?llviewerinventory.h > Any help is highly appreciated. > Sincerely, > ? ?Lev A. Neiman. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From lev.neiman at gmail.com Mon Apr 6 14:06:40 2009 From: lev.neiman at gmail.com (Lev Neiman) Date: Mon, 6 Apr 2009 17:06:40 -0400 Subject: [sldev] weird llviewerinventory.h include problem In-Reply-To: <7992d0d60904061352l392c3167q8363303ea039731f@mail.gmail.com> References: <7992d0d60904061352l392c3167q8363303ea039731f@mail.gmail.com> Message-ID: Nope, that is not the problem. I disabled warnings as errors and it complains about errors in llxmlnode and llpermisions. Please notice that these problems are only present if i include llviewerinventory.h. Also I have not modified the files that generate these errors in any way, they are official source code release. Sincerely, Lev A. Neiman. On Mon, Apr 6, 2009 at 4:52 PM, Dirk Moerenhout wrote: > It stops here for sure: > > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : > error C2220: warning treated as error - no 'object' file generated > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : > warning C4996: 'strncpy': This function or variable may be unsafe. > Consider using strncpy_s instead. To disable deprecation, use > _CRT_SECURE_NO_WARNINGS. See online help for details. > > As you can see both of these refer to line 68. The first says it > treats the warning as an error and will hence not give an object file. > The second gives you the warning and possible solutions. > > Dirk Moerenhout aka Blakar Ogre > > On Mon, Apr 6, 2009 at 10:31 PM, Lev Neiman wrote: > > Hello. I have successfully downloaded 1.22.11 source code and compiled > it > > using VS2005 on WinXP machine. However I have ran into a weird problem. > If > > I include a #include "llviewerinventory.h" it generates a whole bunch of > > error messages in compiler. > > Here is what they are: > > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > > ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : > error > > C2220: warning treated as error - no 'object' file generated > > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > > ide\new sl en\sl_1_22_11\linden\indra\llcommon\llstringtable.h(68) : > warning > > C4996: 'strncpy': This function or variable may be unsafe. Consider using > > strncpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. > See > > online help for details. > > 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d > > IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(151) : error > C2061: > > syntax error : identifier 'LLFILE' > > 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d > > IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(152) : error > C2061: > > syntax error : identifier 'LLFILE' > > 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d > > IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(152) : error > C2059: > > syntax error : ')' > > 1>C:\Documents and Settings\Entheogen\My Documents\school\VITAL Lab\3d > > IDE\new SL EN\sl_1_22_11\linden\indra\llxml\llxmlnode.h(152) : error > C2143: > > syntax error : missing ')' before ';' > > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > > ide\new sl en\sl_1_22_11\linden\indra\llinventory\llpermissions.h(305) : > > error C2061: syntax error : identifier 'LLFILE' > > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > > ide\new sl en\sl_1_22_11\linden\indra\llinventory\llpermissions.h(306) : > > error C2061: syntax error : identifier 'LLFILE' > > 1>c:\documents and settings\entheogen\my documents\school\vital lab\3d > > ide\new sl en\sl_1_22_11\linden\indra\llinventory\llpermissions.h(364) : > > fatal error C1903: unable to recover from previous error(s); stopping > > compilation > > If I omitt the include then everything compiles fine. I am talking about > > including this just from an otherwise empty .h file (with macroguards). > It > > wasn't empty originally but I commented everything out to find source of > the > > problem, and the source is definetly this line that > > includes llviewerinventory.h > > Any help is highly appreciated. > > Sincerely, > > Lev A. Neiman. > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090406/4c9f3699/attachment.htm From monkowsk at watson.ibm.com Mon Apr 6 15:03:31 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 06 Apr 2009 18:03:31 -0400 Subject: [sldev] weird llviewerinventory.h include problem In-Reply-To: References: <7992d0d60904061352l392c3167q8363303ea039731f@mail.gmail.com> Message-ID: <49DA7C33.70905@watson.ibm.com> This may be a silly question, but if it compiles fine without the #include, why are you inserting the #include? And why do you have an otherwise empty .h file that just has this include in it? Where are you using this otherwise empty file? Mike Lev Neiman wrote: > Nope, that is not the problem. I disabled warnings as errors and it > complains about errors in llxmlnode and llpermisions. Please notice > that these problems are only present if i include llviewerinventory.h. > Also I have not modified the files that generate these errors in any > way, they are official source code release. > Sincerely, > Lev A. Neiman. ... > On Mon, Apr 6, 2009 at 10:31 PM, Lev Neiman > wrote: > > Hello. I have successfully downloaded 1.22.11 source code and > compiled it > > using VS2005 on WinXP machine. However I have ran into a weird > problem. If > > I include a #include "llviewerinventory.h" it generates a whole > bunch of > > error messages in compiler. ... > > If I omitt the include then everything compiles fine. I am > talking about > > including this just from an otherwise empty .h file (with > macroguards). It > > wasn't empty originally but I commented everything out to find > source of the > > problem, and the source is definetly this line that > > includes llviewerinventory.h From robla at lindenlab.com Tue Apr 7 09:42:07 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 07 Apr 2009 09:42:07 -0700 Subject: [sldev] Today: Hippotropolis Meeting w/voice @ 11am PDT In-Reply-To: References: <49D64F39.90406@lindenlab.com> Message-ID: <49DB825F.3020905@lindenlab.com> Just a reminder that this is happening in just over an hour.... Rob On 04/03/2009 11:08 AM, Soft wrote: > On Fri, Apr 3, 2009 at 1:02 PM, Rob Lanphier wrote: > >> As a supplement to our normal weekly meetings on Thursdays, we'd like to >> have a one-time meeting using voice: >> >> Tuesday, 11am PDT >> Hippotropolis meeting area >> >> Philip and the crew will be there to talk about the new http-texture >> project and to fill in more detail about how we plan to work together. >> > > This will be much like the Joe Linden or Kitware presentations. Text > is totally okay for questions for those with no headsets or other > voice objections/constraints. But please do try to have voice working > for listening. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From me at signpostmarv.name Tue Apr 7 12:27:20 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue, 07 Apr 2009 20:27:20 +0100 Subject: [sldev] Web Textures and error responses: pass error handling into http_response Message-ID: <49DBA918.2030407@signpostmarv.name> Problem: JPEG requested, server refuses or fouls up request. What gets displayed ? Potential solution: Use an LSL function to request an asset UUID for a given URL. * key llRequestWebTexture(string url); * request headers similar to those sent with llHTTPRequest() would be sent (thus allowing servers to allow/deny based on the Requesting Resident, region of origin etc.) If the fetch gets a 200, the texture can immediately be used with llSetTexture() etc. Any other code then fires off http_response(), where the request_id parameter matches the one returned by llRequestWebTexture(). This would then allow scripts to make intelligent responses based on standard HTTP response codes (401, 402, 403) http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error Retaining the ability for the viewer to disable 3rd-party web textures would then be switched to not obeying 301/302 redirects. Caveats: 1) Would require HTTP asset server & viewer to support 301/302 redirects 2) Would likely force LL to impose file size restrictions (no multi-megabyte poorly compressed PNG/MNG/aPNG) ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090407/4decc0cb/attachment.bin From monkowsk at watson.ibm.com Tue Apr 7 12:59:05 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 07 Apr 2009 15:59:05 -0400 Subject: [sldev] Philip's viewer; was: Tuesday Hippotropolis Meeting w/voice In-Reply-To: <49D64F39.90406@lindenlab.com> References: <49D64F39.90406@lindenlab.com> Message-ID: <49DBB089.6000506@watson.ibm.com> Very good meeting, but I still have questions about the process. One thing that was brought up was that code review is a good thing. So make the code review the gatekeeper. Nothing gets into Philip's branch unless it goes through a code review, which could be a regularly scheduled meeting on Hippotropolis (or elsewhere) or it could be called by Philip whenever he feels like it. Anyone could comment on the code, but Philip would be the ultimate "go" or "no go" authority. Is documentation (on the wiki?) required for a "go"? Before I spend my time coding, I might want to know whether it has a chance of making it into Philip's viewer. Do we need a design review as well? That gets stuff in, but how does it get back out to trunk? How often? Who does it? And how do other changes to trunk (or RC?) get into Philip's branch? Who keeps the two in sync? What happens when LL code changes break the new features? What about when my feature breaks your feature? Who is responsible for fixing them? If I fix something that came from trunk or RC, how does it get fixed back there? If someone abandons his code, how does it get removed? I'll probably think of more questions, but this will do for now. Mike Mm Alder From robin.cornelius at gmail.com Tue Apr 7 13:56:15 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 07 Apr 2009 21:56:15 +0100 Subject: [sldev] Philip's viewer; was: Tuesday Hippotropolis Meeting w/voice In-Reply-To: <49DBB089.6000506@watson.ibm.com> References: <49D64F39.90406@lindenlab.com> <49DBB089.6000506@watson.ibm.com> Message-ID: <49DBBDEF.20806@gmail.com> Mike Monkowski wrote: > Very good meeting, but I still have questions about the process. > > One thing that was brought up was that code review is a good thing. So > make the code review the gatekeeper. Nothing gets into Philip's branch > unless it goes through a code review, which could be a regularly > scheduled meeting on Hippotropolis (or elsewhere) or it could be called > by Philip whenever he feels like it. Anyone could comment on the code, > but Philip would be the ultimate "go" or "no go" authority. A possible idea is for one or more peers from either side of the firewall to review and mark as signed off/sign there name to the fact they are happy with the code. This happens now routinely with in the Linux kernel, many patches you will see added with multiple signed-off by lines by someone who has reviewed the code and ITHO it is ok. So maybe if someone has a patch then they can request a RFC on there patch? sounds a bit formal but i hope you know what i mean. > Before I spend my time coding, I might want to know whether it has a > chance of making it into Philip's viewer. Do we need a design review as > well? I think thats a good idea. Whats the scope of *this* change set that is permitted, we need some kind of short term and ideally longer term road map for this branch. May be at some point we have multiple branches of this nature but they do need defining. We have the current working title of http-texture, which clearly implements the http-texture fetching, bit has also touched the map. > > That gets stuff in, but how does it get back out to trunk? How often? > Who does it? > Yea, part of the roadmap can be a merge to trunk "plan" whats the victory conditions on this patch set? again this is down to the scope of the current branch. Regards Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090407/54d3683e/attachment.pgp From robin.cornelius at gmail.com Tue Apr 7 14:47:07 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 07 Apr 2009 22:47:07 +0100 Subject: [sldev] Viewer documentation & doxygen Message-ID: <49DBC9DB.6040209@gmail.com> As briefly mentioned in Phillips meeting, doxygen[1] is a nice code documentation system. The viewer has previously had the doxygen treatment by Dale Glass [2], but this is now over a year old. I've created a new run of the doxygen reporting against http-texture [3] For those of you not familiar, it parses the C/C++/H files and generates class,namespace,file etc documentation based on there contents. Even with raw files such as the secondlife viewer, useful documentation of the classes functions is shown. What is not clear from [2] & [3] is that doxygen also supports a simple comment/mark up system for documenting the code. What this means is comments can be added explaining API functions and interfaces through out the code and this will be used when generating the html pages to provide more thorough documentation, with clickable links directly to the code and class references. One of the advantages I can see is this can be a slow and ongoing project, as code is re-factored and unit tests written comments can be dropped around the APIs to document them. It does not all need to be done at once and clearly this is something that could be chipped away at with little extra overhead (as you would only add API docs when you were digging in for re-factoring/unit testing/new coding). [1] http://www.stack.nl/~dimitri/doxygen/ [2] http://doc.daleglass.net/index.html [3] http://omvviewer.byteme.org.uk/http-texture/ Regards Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090407/d77670eb/attachment.pgp From carlo at alinoe.com Tue Apr 7 16:02:33 2009 From: carlo at alinoe.com (Carlo Wood) Date: Wed, 8 Apr 2009 01:02:33 +0200 Subject: [sldev] Viewer documentation & doxygen In-Reply-To: <49DBC9DB.6040209@gmail.com> References: <49DBC9DB.6040209@gmail.com> Message-ID: <20090407230233.GA12265@alinoe.com> On Tue, Apr 07, 2009 at 10:47:07PM +0100, Robin Cornelius wrote: > What is not clear from [2] & [3] is that doxygen also supports a simple > comment/mark up system for documenting the code. What this means is > comments can be added explaining API functions and interfaces through > out the code and this will be used when generating the html pages to > provide more thorough documentation, with clickable links directly to > the code and class references. Let me add that (the use of) doxygen in itself is not very useful. What makes the end-product (the documentation) useful is extensive documentation by the coders, not just having (for example) a class hierarchy. So, why doxygen? One of the strong points of doxygen (over, for example documentation on a wiki) is that the documentation and the code are kept very close together. This motivates coders a lot more to keep the documentation up to date: when code is changed, the documentation is updated and changed as well, in the same file. This makes it also easier to make it part of the review of patches to demand that documentation is kept up to date. I hate to do this (cause it's of course my own project ;), but here is an example of how documentation can look like: http://www.xs4all.nl/~carlo17/cwchessboard/index.html If you click around, you will note that only the somewhat larger blocks of text really tell you something, not the one-liners. However, if a developer would really dig deep into this project, one of the strong points (of using doxygen) is that this documentation is almost fully automated hyperlinked! While reading about what class does what in a summary, you can click directly through to that class for a quick overview. -- Carlo Wood From gcanaday at gmail.com Tue Apr 7 16:59:37 2009 From: gcanaday at gmail.com (Glen) Date: Tue, 07 Apr 2009 19:59:37 -0400 Subject: [sldev] Viewer documentation & doxygen In-Reply-To: <20090407230233.GA12265@alinoe.com> References: <49DBC9DB.6040209@gmail.com> <20090407230233.GA12265@alinoe.com> Message-ID: <49DBE8E9.10107@gmail.com> Another very good example of doxygen in use is the KDevelop source and http://www.libqglviewer.com/. --GC Carlo Wood wrote: > On Tue, Apr 07, 2009 at 10:47:07PM +0100, Robin Cornelius wrote: >> What is not clear from [2] & [3] is that doxygen also supports a simple >> comment/mark up system for documenting the code. What this means is >> comments can be added explaining API functions and interfaces through >> out the code and this will be used when generating the html pages to >> provide more thorough documentation, with clickable links directly to >> the code and class references. > > Let me add that (the use of) doxygen in itself is not very useful. > What makes the end-product (the documentation) useful is extensive > documentation by the coders, not just having (for example) a class > hierarchy. > > So, why doxygen? One of the strong points of doxygen (over, for example > documentation on a wiki) is that the documentation and the code > are kept very close together. This motivates coders a lot more to > keep the documentation up to date: when code is changed, the > documentation is updated and changed as well, in the same file. > This makes it also easier to make it part of the review of patches > to demand that documentation is kept up to date. > > I hate to do this (cause it's of course my own project ;), but here > is an example of how documentation can look like: > > http://www.xs4all.nl/~carlo17/cwchessboard/index.html > > If you click around, you will note that only the somewhat larger > blocks of text really tell you something, not the one-liners. > However, if a developer would really dig deep into this project, > one of the strong points (of using doxygen) is that this documentation > is almost fully automated hyperlinked! While reading about what > class does what in a summary, you can click directly through to > that class for a quick overview. > From jacek.antonelli at gmail.com Tue Apr 7 18:05:24 2009 From: jacek.antonelli at gmail.com (Jacek Antonelli) Date: Tue, 7 Apr 2009 20:05:24 -0500 Subject: [sldev] Viewer documentation & doxygen In-Reply-To: <49DBC9DB.6040209@gmail.com> References: <49DBC9DB.6040209@gmail.com> Message-ID: <105c09f0904071805w64706768y73ce00bcd22790cf@mail.gmail.com> On Tue, Apr 7, 2009 at 4:47 PM, Robin Cornelius wrote: > > What is not clear from [2] & [3] is that doxygen also supports a simple > comment/mark up system for documenting the code. What this means is > comments can be added explaining API functions and interfaces through > out the code and this will be used when generating the html pages to > provide more thorough documentation, with clickable links directly to > the code and class references. Even with the lack of documentation comments in the viewer, Doxygen has helped me a lot while developing Imprudence. In particular, being able to see the class inheritance tree and being able to get a list of all members and methods of a class (including inherited ones) is handy for the UI widget classes, where there's a lot of inheritance going on. Of course, it'd be even more useful with plentiful comments, so I think putting in some effort to improve the documentation is a very good idea. > It does not all need to be > done at once and clearly this is something that could be chipped away at > with little extra overhead (as you would only add API docs when you were > digging in for re-factoring/unit testing/new coding). I hope this is not meant to exclude those of us who might like to contribute documentation by itself. :-) One thought is that it would be good to have established style guidelines for the documentation. (Something more specific and concrete than "Doxygen compatible markup".) The "Coding standard" wiki page [1] refers to a missing "Using Doxygen" page, which I assume is/was located on the Linden's internal wiki, and may perhaps have some style guidelines or usage tips. Could a Linden please take a look and see whether it has anything useful that could be "declassified"? [1] http://wiki.secondlife.com/wiki/Coding_standard#Comments - Jacek From merov at lindenlab.com Tue Apr 7 21:46:43 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 7 Apr 2009 21:46:43 -0700 Subject: [sldev] Philip's viewer; was: Tuesday Hippotropolis Meeting w/voice In-Reply-To: <49DBB089.6000506@watson.ibm.com> References: <49D64F39.90406@lindenlab.com> <49DBB089.6000506@watson.ibm.com> Message-ID: <8B670E5B-5F32-42A5-85B8-EB3F89501B72@lindenlab.com> Hi Mike, On Apr 7, 2009, at 12:59 PM, Mike Monkowski wrote: > One thing that was brought up was that code review is a good thing. > So > make the code review the gatekeeper. Nothing gets into Philip's > branch > unless it goes through a code review, which could be a regularly > scheduled meeting on Hippotropolis (or elsewhere) or it could be > called > by Philip whenever he feels like it. Anyone could comment on the > code, > but Philip would be the ultimate "go" or "no go" authority. I don't think that Philip will be the unique gatekeeper for patch blessing. The plan right now is to have a (initially small) group of committers which role will be to review, sign off and commit the patches. These committers will held regular meetings with Philip who, as the BDFL, will keep them in line with the broad objectives of that branch. > Is documentation (on the wiki?) required for a "go"? Depends on the extend of the fix/feature. For sure, a PJIRA entry *is* required. > Before I spend my time coding, I might want to know whether it has a > chance of making it into Philip's viewer. Do we need a design > review as > well? Light process which should include: PJIRA and discussion on sldev. The go / no go should be made public so, in the end, everybody will internalize what kind of work is done on that branch. > That gets stuff in, but how does it get back out to trunk? How often? > Who does it? Good question! We'll have to log a request and lobby internally to get a patch merged back to trunk. The point is that those features / bug fixes, will have been battle tested by the community and their value (and popularity) well established. > And how do other changes to trunk (or RC?) get into Philip's branch? > Who keeps the two in sync? The Lindens on the committer group will be doing merge from trunk on a regular basis. CG has been doing this since a week (see the svn log). I'm expecting to be doing that on a regular basis as well. > What happens when LL code changes break the > new features? What about when my feature breaks your feature? Who is > responsible for fixing them? This is a common problem of multi branch development. This is a reason actually to avoid messing with parts of the code we know are under construction on the trunk. The http-texture part of the code though won't be modified by other development for a while, is critical for perf improvement and will require lots and lots of testing. That being said, when something gets broken as part of a merge, that's the person doing the merge who's in charge of fixing things up, potentially with the help of the developers. > If I fix something that came from trunk or > RC, how does it get fixed back there? See above about merge back to trunk. Fixes on RC will likely be migrated as patches. > If someone abandons his code, how does it get removed? Code doesn't rust and shouldn't be that badly designed / documented that only its designer can do something with it. If it's the case, it shouldn't make it into the branch in the first place. If it's a problem of copyright or attribution you're alluding to, remember that each dev must sign a contribution license agreement. So the net-net is that I don't see the rationale to remove code unless it's bad. Cheers - Merov From robin.cornelius at gmail.com Tue Apr 7 22:49:09 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed, 08 Apr 2009 06:49:09 +0100 Subject: [sldev] Viewer documentation & doxygen In-Reply-To: <105c09f0904071805w64706768y73ce00bcd22790cf@mail.gmail.com> References: <49DBC9DB.6040209@gmail.com> <105c09f0904071805w64706768y73ce00bcd22790cf@mail.gmail.com> Message-ID: <49DC3AD5.2070509@gmail.com> Jacek Antonelli wrote: >> It does not all need to be >> done at once and clearly this is something that could be chipped away at >> with little extra overhead (as you would only add API docs when you were >> digging in for re-factoring/unit testing/new coding). > > I hope this is not meant to exclude those of us who might like to > contribute documentation by itself. :-) > > heh, of cause not ;-p I was addressing some previous concerns about manpower and effort this would take when this subject was broached previously at Rob's office hour (no reference). My comments were directed the other side of the firewall where I suspect LL devs are going to have to add it ad-hoc rather than sit down and just document due to limited resources. If people from this side of the firewall could contribute documentation I see that as a big win for all concerned. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090408/ea536d90/attachment.pgp From kf6kjg at gmail.com Wed Apr 8 00:19:21 2009 From: kf6kjg at gmail.com (Ricky) Date: Wed, 8 Apr 2009 00:19:21 -0700 Subject: [sldev] Viewer documentation & doxygen In-Reply-To: <49DC3AD5.2070509@gmail.com> References: <49DBC9DB.6040209@gmail.com> <105c09f0904071805w64706768y73ce00bcd22790cf@mail.gmail.com> <49DC3AD5.2070509@gmail.com> Message-ID: <3bb9647e0904080019m52d17497w3de358dbea33687d@mail.gmail.com> Should there be a JIRA entry for this project? Also what about a meta issue to track all embedded documentation issues? Ricky aka Cron Stardust On Tue, Apr 7, 2009 at 10:49 PM, Robin Cornelius wrote: > Jacek Antonelli wrote: > > >> It does not all need to be > >> done at once and clearly this is something that could be chipped away at > >> with little extra overhead (as you would only add API docs when you were > >> digging in for re-factoring/unit testing/new coding). > > > > I hope this is not meant to exclude those of us who might like to > > contribute documentation by itself. :-) > > > > > > heh, of cause not ;-p > > I was addressing some previous concerns about manpower and effort this > would take when this subject was broached previously at Rob's office > hour (no reference). My comments were directed the other side of the > firewall where I suspect LL devs are going to have to add it ad-hoc > rather than sit down and just document due to limited resources. If > people from this side of the firewall could contribute documentation I > see that as a big win for all concerned. > > Robin > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090408/6637a36b/attachment.htm From robin.cornelius at gmail.com Wed Apr 8 01:12:04 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Wed, 8 Apr 2009 09:12:04 +0100 Subject: [sldev] Viewer documentation & doxygen In-Reply-To: <49DC3AD5.2070509@gmail.com> References: <49DBC9DB.6040209@gmail.com> <105c09f0904071805w64706768y73ce00bcd22790cf@mail.gmail.com> <49DC3AD5.2070509@gmail.com> Message-ID: On Wed, Apr 8, 2009 at 6:49 AM, Robin Cornelius wrote: > heh, of cause not ;-p >> I was addressing some previous concerns about manpower and effort this > would take when this subject was broached previously at Rob's office > hour (no reference). My comments were directed the other side of the > firewall where I suspect LL devs are going to have to add it ad-hoc > rather than sit down and just document due to limited resources. If > people from this side of the firewall could contribute documentation I > see that as a big win for all concerned. > Replying to myself in the best possible etiquette, I've had some private feedback that the doxygen markup is too intrusive as comments inline in the code and it was suggested that these could be added at the end of a file. Actually this is a win-win. The comments are not interrupting anyones overview of the code reading it in a straight code editor . But the biggest win is merge conflicts. If the documentation is all contained after the code it would be less likely to be/cause merge conflicts due to small code changes etc and makes it a whole lot easier for 3rd parties to contribute documentation without someone having to hand rebase because the code reference points in the diff have changed. Robin From secret.argent at gmail.com Wed Apr 8 05:27:37 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Wed, 8 Apr 2009 07:27:37 -0500 Subject: [sldev] Web Textures and error responses: pass error handling into http_response In-Reply-To: <49DBA918.2030407@signpostmarv.name> References: <49DBA918.2030407@signpostmarv.name> Message-ID: On 2009-04-07, at 14:27, SignpostMarv Martin wrote: > Problem: JPEG requested, server refuses or fouls up request. What > gets displayed ? > > Potential solution: > > Use an LSL function to request an asset UUID for a given URL. Linden Labs has frequently stated that they won't allow scripted creation of assets. From alissa_sabre at yahoo.co.jp Wed Apr 8 06:55:11 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed, 08 Apr 2009 22:55:11 +0900 Subject: [sldev] Web Textures and error responses: pass error handling into http_response In-Reply-To: <49DBA918.2030407@signpostmarv.name> References: <49DBA918.2030407@signpostmarv.name> Message-ID: > Problem: JPEG requested, server refuses or fouls up request. What gets > displayed ? What is a problem? -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From janai.moses at gmail.com Wed Apr 8 12:36:27 2009 From: janai.moses at gmail.com (janai moses) Date: Wed, 8 Apr 2009 15:36:27 -0400 Subject: [sldev] what Message-ID: <6f824b410904081236y57cc080oe2a38613a3994165@mail.gmail.com> what do you want and who are you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090408/ca7ffb4a/attachment.htm From robla at lindenlab.com Wed Apr 8 12:58:36 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 08 Apr 2009 12:58:36 -0700 Subject: [sldev] Viewer documentation & doxygen In-Reply-To: <105c09f0904071805w64706768y73ce00bcd22790cf@mail.gmail.com> References: <49DBC9DB.6040209@gmail.com> <105c09f0904071805w64706768y73ce00bcd22790cf@mail.gmail.com> Message-ID: <49DD01EC.1010609@lindenlab.com> On 04/07/2009 06:05 PM, Jacek Antonelli wrote: > One thought is that it would be good to have established style > guidelines for the documentation. (Something more specific and > concrete than "Doxygen compatible markup".) The "Coding standard" wiki > page [1] refers to a missing "Using Doxygen" page, which I assume > is/was located on the Linden's internal wiki, and may perhaps have > some style guidelines or usage tips. Could a Linden please take a look > and see whether it has anything useful that could be "declassified"? > > [1] http://wiki.secondlife.com/wiki/Coding_standard#Comments > Done: https://wiki.secondlife.com/wiki/Using_Doxygen Probably not much there that you'd be interested in, though. Rob From me at signpostmarv.name Wed Apr 8 13:50:48 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed, 08 Apr 2009 21:50:48 +0100 Subject: [sldev] Web Textures and error responses: pass error handling into http_response In-Reply-To: References: <49DBA918.2030407@signpostmarv.name> Message-ID: <49DD0E28.10405@signpostmarv.name> I'm just wondering about what the viewer is going to do to indicate that a request for a HTTP texture resource failed. Render nothing ? Render greyness ? ~ Marv. Argent Stonecutter wrote: > On 2009-04-07, at 14:27, SignpostMarv Martin wrote: > > >> Problem: JPEG requested, server refuses or fouls up request. What >> gets displayed ? >> >> Potential solution: >> >> Use an LSL function to request an asset UUID for a given URL. >> > > Linden Labs has frequently stated that they won't allow scripted > creation of assets. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090408/e3bfdf7a/attachment.bin From teravus at gmail.com Wed Apr 8 14:27:58 2009 From: teravus at gmail.com (Teravus Ovares) Date: Wed, 8 Apr 2009 17:27:58 -0400 Subject: [sldev] Web Textures and error responses: pass error handling into http_response In-Reply-To: <49DD0E28.10405@signpostmarv.name> References: <49DBA918.2030407@signpostmarv.name> <49DD0E28.10405@signpostmarv.name> Message-ID: <34cc66250904081427l515d1491v94527c279fc3c5a2@mail.gmail.com> Missing Image FTW! :D Best Regards Teravus On 4/8/09, SignpostMarv Martin wrote: > I'm just wondering about what the viewer is going to do to indicate that a > request for a HTTP texture resource failed. > > Render nothing ? Render greyness ? > > > ~ Marv. > > > Argent Stonecutter wrote: > > On 2009-04-07, at 14:27, SignpostMarv Martin wrote: > > > > > > > > > Problem: JPEG requested, server refuses or fouls up request. What gets > displayed ? > > > > > > Potential solution: > > > > > > Use an LSL function to request an asset UUID for a given URL. > > > > > > > > > > Linden Labs has frequently stated that they won't allow scripted creation > of assets. > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > privileges > > > > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > From philip at lindenlab.com Thu Apr 9 10:32:41 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Thu, 09 Apr 2009 10:32:41 -0700 Subject: [sldev] Viewer documentation & doxygen In-Reply-To: <49DC3AD5.2070509@gmail.com> References: <49DBC9DB.6040209@gmail.com> <105c09f0904071805w64706768y73ce00bcd22790cf@mail.gmail.com> <49DC3AD5.2070509@gmail.com> Message-ID: <49DE3139.1040701@lindenlab.com> definitely getting community help with documenting code would be great! Robin Cornelius wrote: > Jacek Antonelli wrote: > > >>> It does not all need to be >>> done at once and clearly this is something that could be chipped away at >>> with little extra overhead (as you would only add API docs when you were >>> digging in for re-factoring/unit testing/new coding). >>> >> I hope this is not meant to exclude those of us who might like to >> contribute documentation by itself. :-) >> >> >> > > heh, of cause not ;-p > > I was addressing some previous concerns about manpower and effort this > would take when this subject was broached previously at Rob's office > hour (no reference). My comments were directed the other side of the > firewall where I suspect LL devs are going to have to add it ad-hoc > rather than sit down and just document due to limited resources. If > people from this side of the firewall could contribute documentation I > see that as a big win for all concerned. > > Robin > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090409/5e3ad88c/attachment.htm From philip at lindenlab.com Thu Apr 9 11:46:49 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Thu, 09 Apr 2009 11:46:49 -0700 Subject: [sldev] Philip's viewer; was: Tuesday Hippotropolis Meeting w/voice In-Reply-To: <49DBB089.6000506@watson.ibm.com> References: <49D64F39.90406@lindenlab.com> <49DBB089.6000506@watson.ibm.com> Message-ID: <49DE4299.8010700@lindenlab.com> Adding some thoughts... Robin and Merov have made some good responses too... I am a huge believer in transparency and freedom: Inotherwards, if you are fearless about telling people early and often what you are doing, you are probably doing the right things without needing to be told. At Linden most folks (about 85%+) publish weekly emails to the entire company listing what their objectives are for the week, and how they did last week. Perhaps we could do that here too!! It might be interesting. So in that spirit, I'd say that sending mail to SL-dev saying "I am about to start working on X, what do folks think?" seems like a great idea. Design review suggests an approval process barring further work, which I don't think would be appropriate. But talk on this list about what you think would make sense to put into this viewer before starting coding work - Yes! Also I agree with what merov said about committers, it seems like building a growing list of committers who distribute the load of giving feedback on what should/shouldn't go in is the right strategy. P Mike Monkowski wrote: > Very good meeting, but I still have questions about the process. > > One thing that was brought up was that code review is a good thing. > So make the code review the gatekeeper. Nothing gets into Philip's > branch unless it goes through a code review, which could be a > regularly scheduled meeting on Hippotropolis (or elsewhere) or it > could be called by Philip whenever he feels like it. Anyone could > comment on the code, but Philip would be the ultimate "go" or "no go" > authority. > > Is documentation (on the wiki?) required for a "go"? > > Before I spend my time coding, I might want to know whether it has a > chance of making it into Philip's viewer. Do we need a design review > as well? > > That gets stuff in, but how does it get back out to trunk? How often? > Who does it? > > And how do other changes to trunk (or RC?) get into Philip's branch? > Who keeps the two in sync? What happens when LL code changes break > the new features? What about when my feature breaks your feature? > Who is responsible for fixing them? If I fix something that came from > trunk or RC, how does it get fixed back there? > > If someone abandons his code, how does it get removed? > > I'll probably think of more questions, but this will do for now. > > Mike > Mm Alder From gcanaday at gmail.com Thu Apr 9 16:00:00 2009 From: gcanaday at gmail.com (Glen) Date: Thu, 09 Apr 2009 19:00:00 -0400 Subject: [sldev] Philip's viewer; was: Tuesday Hippotropolis Meeting w/voice In-Reply-To: <49DE4299.8010700@lindenlab.com> References: <49D64F39.90406@lindenlab.com> <49DBB089.6000506@watson.ibm.com> <49DE4299.8010700@lindenlab.com> Message-ID: <49DE7DF0.3000300@gmail.com> I thought I'd start. I wrote a 3-paragraph novel-in-a-nutshell response. Decided that was a bad idea since it was all whining anyway. Deleted it. If next week goes the same as this week, I'll delete my response again. lol ;P At work we call these "battle plans" and the work finished "stats" since they can be graphed. Management is funny that way. Weekly progress reports and personal targets are an excellent idea. They keep others informed of what's going on... sorta like turn signals on the car. --GC Philip Rosedale wrote: > Adding some thoughts... Robin and Merov have made some good responses > too... > > I am a huge believer in transparency and freedom: Inotherwards, if you > are fearless about telling people early and often what you are doing, > you are probably doing the right things without needing to be told. At > Linden most folks (about 85%+) publish weekly emails to the entire > company listing what their objectives are for the week, and how they did > last week. Perhaps we could do that here too!! It might be interesting. > > So in that spirit, I'd say that sending mail to SL-dev saying "I am > about to start working on X, what do folks think?" seems like a great > idea. Design review suggests an approval process barring further work, > which I don't think would be appropriate. But talk on this list about > what you think would make sense to put into this viewer before starting > coding work - Yes! > > Also I agree with what merov said about committers, it seems like > building a growing list of committers who distribute the load of giving > feedback on what should/shouldn't go in is the right strategy. > > P > > Mike Monkowski wrote: >> Very good meeting, but I still have questions about the process. >> >> One thing that was brought up was that code review is a good thing. >> So make the code review the gatekeeper. Nothing gets into Philip's >> branch unless it goes through a code review, which could be a >> regularly scheduled meeting on Hippotropolis (or elsewhere) or it >> could be called by Philip whenever he feels like it. Anyone could >> comment on the code, but Philip would be the ultimate "go" or "no go" >> authority. >> >> Is documentation (on the wiki?) required for a "go"? >> >> Before I spend my time coding, I might want to know whether it has a >> chance of making it into Philip's viewer. Do we need a design review >> as well? >> >> That gets stuff in, but how does it get back out to trunk? How often? >> Who does it? >> >> And how do other changes to trunk (or RC?) get into Philip's branch? >> Who keeps the two in sync? What happens when LL code changes break >> the new features? What about when my feature breaks your feature? >> Who is responsible for fixing them? If I fix something that came from >> trunk or RC, how does it get fixed back there? >> >> If someone abandons his code, how does it get removed? >> >> I'll probably think of more questions, but this will do for now. >> >> Mike >> Mm Alder > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From carlo at alinoe.com Thu Apr 9 16:59:02 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 10 Apr 2009 01:59:02 +0200 Subject: [sldev] Viewer documentation & doxygen In-Reply-To: References: <49DBC9DB.6040209@gmail.com> <105c09f0904071805w64706768y73ce00bcd22790cf@mail.gmail.com> <49DC3AD5.2070509@gmail.com> Message-ID: <20090409235902.GA31385@alinoe.com> While this could be true for headerfiles, I'm inclined to think that in the case of source files it's better to keep the documentation close to the function for the sake of keeping it up to date. If documentation is put somewhere at the end of a file, it might as well be on a wiki-- it's less likely that people will take the time to keep it updated, imho. It is also harder to find the documentation while browsing the source code itself. The concern about merge conflicts are valid for headers, but not really for source files, since in general there will always be a context of 3 lines inbetween the documentation and the functions. A class has obviously inline functions, which have to be documented in the headerfile. But inline functions are usually very small and will not change much; therefore it might be sufficient to add their documentation at the end of the headerfile; also, small inline functions are often understandable if need be without documentation. On Wed, Apr 08, 2009 at 09:12:04AM +0100, Robin Cornelius wrote: > I've had some private feedback that the doxygen markup is too > intrusive as comments inline in the code and it was suggested that > these could be added at the end of a file. > > Actually this is a win-win. The comments are not interrupting anyones > overview of the code reading it in a straight code editor . But the > biggest win is merge conflicts. If the documentation is all contained > after the code it would be less likely to be/cause merge conflicts due > to small code changes etc and makes it a whole lot easier for 3rd > parties to contribute documentation without someone having to hand > rebase because the code reference points in the diff have changed. > > Robin -- Carlo Wood From poppy at lindenlab.com Thu Apr 9 22:38:55 2009 From: poppy at lindenlab.com (Paul Oppenheim (Poppy Linden)) Date: Thu, 09 Apr 2009 22:38:55 -0700 Subject: [sldev] Philip's viewer; was: Tuesday Hippotropolis Meeting w/voice In-Reply-To: <49DE4299.8010700@lindenlab.com> References: <49D64F39.90406@lindenlab.com> <49DBB089.6000506@watson.ibm.com> <49DE4299.8010700@lindenlab.com> Message-ID: <49DEDB6F.2060406@lindenlab.com> Philip Rosedale wrote: > I am a huge believer in transparency and freedom: Inotherwards, if you > are fearless about telling people early and often what you are doing, > you are probably doing the right things without needing to be told. At > Linden most folks (about 85%+) publish weekly emails to the entire > company listing what their objectives are for the week, and how they did > last week. Perhaps we could do that here too!! It might be interesting. Public A&O... what next, public Review-O-Matic? ;) + poppy /me goes to double-check his ROM... From alissa_sabre at yahoo.co.jp Fri Apr 10 08:21:52 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Sat, 11 Apr 2009 00:21:52 +0900 Subject: [sldev] Projects that I'm working on (was: Philip's viewer) In-Reply-To: <49DE4299.8010700@lindenlab.com> References: <49DE4299.8010700@lindenlab.com> Message-ID: <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> > I am a huge believer in transparency and freedom: Me too. > if you > are fearless about telling people early and often what you are doing, > you are probably doing the right things without needing to be told. At > Linden most folks (about 85%+) publish weekly emails to the entire > company listing what their objectives are for the week, and how they did > last week. Perhaps we could do that here too!! It might be interesting. Indeed. The following are my projects: * GTK immodule support in Linux viewer (VWR-2261) This is the major project I'm currently working on. Subprojects are: * Porting my work based on 1.22.4 to the latest svn trunk codebase. Almost done, but having some trouble in XRandR code. * Isolating _too_new_ GTK features in the above code, as a preparation for the dlopen based re-implementation. 40-50%. * Thinking of yet another approach to live with very old GTK. Possibilities include: A raw GLX window in a GTK container, or a 1x1 GTK widget entirely stealing keyboard focus from SDL window. * Also thinking how I can persuade Tofu Linden to abondon the idea sticking on the three-year-old-but-still-officially-supported Ubuntu 6.06. :-) * Better locale handling Rewriting locale (as in C setlocale() function) related workarounds and problematic codes with a consistent and clean handling. The goal is to allow viewer to run under the user's locale in most places, still maintaining locale independent data representation stability whereever needed. The motivation is to eliminate recurring problems, e.g., VWR-12161, VWR-11898, VWR-5365, VWR-5056, and pre-opensource issue SL-35450. I believe I have done 80-90% of required changes, but the viewer still goes wild on German locale... * Pango based text drawing (VWR-10131) This is my number 1 priority project in my mind, but I've not been working on this project recently. No major progress in last three months. See the following page for more on this project: http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer My latest code: * Can draw most of the left-to-right scripts, including so-called complex scripts, e.g. Devanagar (Hindi) or Tamil. * Can also draw some simple texts using right-to-left scripts (e.g. Arabic and Hebrew), with or without mixing with left-to-right scripts. * As a bonus feature, dos a better line folding on languages written with no spaces between words, e.g., Chinese or Japanese. * Doesn't handle well text input features including typing, moving text cursor, and range-selection of a middle of a text, for such complex scripts and right-to-left scripts yet. * Also needs a lot rewriting to go into the latest viewer codes, because in svn trunk viwer font handling codes have largely changed. Comments? Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From sardonyx at lindenlab.com Fri Apr 10 10:22:44 2009 From: sardonyx at lindenlab.com (Sardonyx Linden) Date: Fri, 10 Apr 2009 10:22:44 -0700 Subject: [sldev] Distributed revision control pilot underway Message-ID: As part of our effort to remove barriers to collaboration with the open source community, we are piloting some source code branches using Mercurial at the moment. For details, please see https://wiki.secondlife.com/wiki/Mercurial_repositories The advantages to us and to our friends in the open source community are several: you'll be able to more easily track and merge our source code, and we'll more easily be able to accept contributions back from you. Once we have some internal infrastructure in place (to deal with automated builds, for instance), we will probably be switching open source development over to Mercurial. Your comments are welcome. Sardonyx. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090410/8ffdd7cb/attachment.htm From philip at lindenlab.com Fri Apr 10 10:31:54 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Fri, 10 Apr 2009 10:31:54 -0700 Subject: [sldev] Can you help find curl crash? Message-ID: <49DF828A.2040201@lindenlab.com> Hiya, I think a/the blocker to getting a version of this new open source viewer onto the SL download pages is going to be this curl crash - we are sometimes crashing in a curl thread. Anyone out there who wants to spend some time looking or trying to repro, that would be so very cool. Respond here - coordinate with merov. P From dzonatas at dzonux.net Fri Apr 10 09:22:56 2009 From: dzonatas at dzonux.net (Dzonatas) Date: Fri, 10 Apr 2009 09:22:56 -0700 Subject: [sldev] Projects that I'm working on In-Reply-To: <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> Message-ID: <49DF7260.5010603@dzonux.net> Alissa Sabre wrote: > * Thinking of yet another approach to live with very old GTK. > Possibilities include: A raw GLX window in a GTK container, or a > 1x1 GTK widget entirely stealing keyboard focus from SDL window. > Gnome has already started to support this option (officially): http://bugzilla.gnome.org/show_bug.cgi?id=119189#c54 > > * Pango based text drawing (VWR-10131) > > This is my number 1 priority project in my mind, but I've not been > working on this project recently. No major progress in last three > months. > > See the following page for more on this project: > http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer > > This is pretty simple in GTK#. Just saying... From merov at lindenlab.com Fri Apr 10 14:01:35 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 10 Apr 2009 14:01:35 -0700 Subject: [sldev] [VWR[[PATCH] LLTextureCache::writeToCache()does notcache textures smaller than TEXTURE_CACHE_ENTRY_SIZE In-Reply-To: <16514E30-67B7-4A34-8E9C-E8D3AF643646@lindenlab.com> References: <386D3918-8AE6-4281-8D92-A9F7745932FD@lindenlab.com><49D8FAF6.6000503@gmai l.com> <16514E30-67B7-4A34-8E9C-E8D3AF643646@lindenlab.com> Message-ID: Hi, Robin's fix for that bug as well as my own contribution to it has been committed to the branch and built. Details: http://jira.secondlife.com/browse/VWR-12686 Builds available off: https://wiki.secondlife.com/wiki/Open_Source_Portal Thanks again to Robin for pointing that one out. First contribution on that new branch! Whohoo! :) Cheers, - Merov From robla at lindenlab.com Fri Apr 10 17:35:56 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 10 Apr 2009 17:35:56 -0700 Subject: [sldev] Pango (Re: Projects that I'm working on ) In-Reply-To: <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> Message-ID: <49DFE5EC.1080905@lindenlab.com> Alissa, This is really cool! I'm breaking up my response into a couple of threads. More below.... On 04/10/2009 08:21 AM, Alissa Sabre wrote: > * Pango based text drawing (VWR-10131) > > This is my number 1 priority project in my mind, but I've not been > working on this project recently. No major progress in last three > months. > > See the following page for more on this project: > http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer > My understanding from a number of places (including from our internal devs, as well as some previous discussion that I think happened on this list) is that this is still pretty slow. The biggest problem for this solution (and to a lesser extent, our existing solution) is that we render the text with every frame. We're dabbling with the idea of caching the UI rendering, but getting that feature done seems like a nasty task until we get our UI refactored well enough to make that a maintainable proposition. We're definitely keeping an eye on this work, though, because we are working toward a day when we'll be able to make use of it, so it'll be good to have prototype implementations around, as well developers like yourself who already have a ton of experience working with the code. Rob From robla at lindenlab.com Fri Apr 10 18:08:13 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 10 Apr 2009 18:08:13 -0700 Subject: [sldev] Linux variants to support (Re: Projects that I'm working on) In-Reply-To: <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> Message-ID: <49DFED7D.4060503@lindenlab.com> On 04/10/2009 08:21 AM, Alissa Sabre wrote: > * GTK immodule support in Linux viewer (VWR-2261) > > This is the major project I'm currently working on. > Subprojects are: > > * Porting my work based on 1.22.4 to the latest svn trunk codebase. > Almost done, but having some trouble in XRandR code. > > * Isolating _too_new_ GTK features in the above code, as a > preparation for the dlopen based re-implementation. 40-50%. > > * Thinking of yet another approach to live with very old GTK. > Possibilities include: A raw GLX window in a GTK container, or a > 1x1 GTK widget entirely stealing keyboard focus from SDL window. > > * Also thinking how I can persuade Tofu Linden to abondon the idea > sticking on the three-year-old-but-still-officially-supported > Ubuntu 6.06. :-) I'm going to guess that it's going to take more than Tofu. It's entirely reasonable for us to drop support for older desktop distros. Since desktop Linux (the platform, not just our Linux viewer) is in a seemingly perpetual beta, and that distros are pretty much designed to be upgraded free of charge, it doesn't make as much sense to support old versions. If there were some statistics that seem accurate enough to back up the case that virtually no one is still running Ubuntu 6.06 that expects to run Second Life, that'd pretty much seal the deal from a business perspective. However, there's also a logistical hurdle that we also have to get over. I'm going to guess that some of this is driven by the fact that we run Debian Etch on our server infrastructure, and that our build farms and common libraries (e.g. the ones we package up and provide, as well as use ourselves) are tuned for supporting them. I don't know for sure if this is at the heart of the issue, but it's a reason I've at least heard before. So, I'm going to let other Lindens on this list speak up about it. Rob From tigrospottystripes at gmail.com Fri Apr 10 19:00:49 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Fri, 10 Apr 2009 23:00:49 -0300 Subject: [sldev] Question involving the rendering of interface windows from someone that doesn't know much about the stuff involved (was Re: Pango (Re: Projects that I'm working on ) ) In-Reply-To: <49DFE5EC.1080905@lindenlab.com> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> <49DFE5EC.1080905@lindenlab.com> Message-ID: <49DFF9D1.7090106@Gmail.com> I can probably be considered an outsider in regards to the client code, C(++) programming in general, and the technical, practical and other limitations involved etc, but I'm curious, what would be in the way of rendering each interface window to a texture and applying the texture to a quad with the dimensions of the window ? ps: is it ok to ask things like this in this list or should I refrain from doing it again in the future? Rob Lanphier escreveu: > ... > > The biggest problem for this solution (and to a lesser extent, our > existing solution) is that we render the text with every frame. We're > dabbling with the idea of caching the UI rendering, but getting that > feature done seems like a nasty task until we get our UI refactored well > enough to make that a maintainable proposition. > > ... > > Rob > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From sldev at free.fr Sat Apr 11 01:13:02 2009 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 11 Apr 2009 10:13:02 +0200 Subject: [sldev] Projects that I'm working on (was: Philip's viewer) In-Reply-To: <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> Message-ID: <20090411101302.308cb997.sldev@free.fr> On Sat, 11 Apr 2009 00:21:52 +0900, Alissa Sabre wrote: Greetings, > The following are my projects: > > .../... > > * Better locale handling > > Rewriting locale (as in C setlocale() function) related workarounds > and problematic codes with a consistent and clean handling. The > goal is to allow viewer to run under the user's locale in most > places, still maintaining locale independent data representation > stability whereever needed. > > The motivation is to eliminate recurring problems, e.g., VWR-12161, > VWR-11898, VWR-5365, VWR-5056, and pre-opensource issue SL-35450. > > I believe I have done 80-90% of required changes, but the viewer > still goes wild on German locale... Please make sure that: - the viewer will keep working properly on non-UTF-8 systems (using a French locale with ISO-8859-15 charset, here, and not going to switch to UTF-8 ever !). - the locale used by the viewer can still be configured independantly from the system locale (i.e., I want to be able to run the viewer using the English locale, even though my system is configured for the French locale: I just can't stand the poor translations, and it's much easier for a merchant to use the most common locale for supporting their customers and guiding them through the menus). - the date and numbers conventions parts of the locale can be kept separate from the locale chosen by the user. I.e., I don't want to have to use a comma instead of a decimal point for decimal numbers should I use the French locale, or be imposed a specific date format (see my patch proposal for https://jira.secondlife.com/browse/VWR-721 about the latter issue). > * Pango based text drawing (VWR-10131) Please, make sure that Pango usage can be disabled altogether if the user does not need it (i.e. when the viewer runs on a system not using UTF-8, but an 8 bits charset). Pango is bloated and painfully slow. It would slow down needlessly the viewer for people not needing the extended character sets brought by UTF-8 (i.e. the large majority of the SL residents). For an example of a wise usage of Pango, see Firefox (you can disable Pango altogether in Firefox simply by setting MOZ_DISABLE_PANGO=1: doing so makes the renderer fly at (well over) twice the speed you get when Pango is enabled). Regards, Henri. From carlo at alinoe.com Sat Apr 11 11:55:41 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 11 Apr 2009 20:55:41 +0200 Subject: [sldev] Linux variants to support (Re: Projects that I'm working on) In-Reply-To: <49DFED7D.4060503@lindenlab.com> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> <49DFED7D.4060503@lindenlab.com> Message-ID: <20090411185541.GA5086@alinoe.com> On Fri, Apr 10, 2009 at 06:08:13PM -0700, Rob Lanphier wrote: > I'm going to guess that some of this is driven by the fact that we run > Debian Etch on our server infrastructure, and that our build farms and > common libraries (e.g. the ones we package up and provide, as well as I don't want to go into details (I wouldn't even know them from the top of my head), but I know that the difference between etch and lenny (which was released in Februari) is pretty huge library and C++ wise. You should seriously think about moving to Lenny. -- Carlo Wood From jan.ciger at gmail.com Sat Apr 11 12:35:58 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Sat, 11 Apr 2009 21:35:58 +0200 Subject: [sldev] Linux variants to support (Re: Projects that I'm working on) In-Reply-To: <49DFED7D.4060503@lindenlab.com> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> <49DFED7D.4060503@lindenlab.com> Message-ID: <49E0F11E.2040108@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Rob, Rob Lanphier wrote: > > I'm going to guess that it's going to take more than Tofu. > > It's entirely reasonable for us to drop support for older desktop > distros. Since desktop Linux (the platform, not just our Linux viewer) > is in a seemingly perpetual beta, and that distros are pretty much > designed to be upgraded free of charge, it doesn't make as much sense to > support old versions. ... You should not have to "support" any specific linux distros explicitly. Instead, work with the distro packagers to get your stable releases in their distributions. Then the users download a tested and guaranteed working version from the official distro repositories using the regular tools. That has many advantages - proper QA, proper desktop integration, not having to ship lots of libraries which most distros have anyway, not having to deal with the distro-specific hacks etc. The packagers will do a lot of the "support" work for you if you make their job easy. One issue you will encounter are the proprietary pieces - e.g. FMOD, Kakadu and Vivox. These will be obstacles e.g. for Debian and Mandriva to include your viewer into the regular repositories. FMOD and Kakadu can be worked around by using OpenAL and OpenJPG, but Vivox could be a problem if it is not redistributable by 3rd-parties. Also, do not focus on Ubuntu - it is far from the most popular desktop distro in Europe. Here is the market more diverse due to the language diversity and you will find a lot of specialized distributions. Again, it is an argument against trying to "support" distributions - the logistics wouldn't scale. Just work with the packagers to get your code in their product. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJ4PEbn11XseNj94gRAgBAAKC9E496VwSpgFRUwebD0Z3xleGgugCgv5yw a+O7oLSQ8OMEqJhwqhoB+WA= =MggX -----END PGP SIGNATURE----- From robin.cornelius at gmail.com Sat Apr 11 12:00:03 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat, 11 Apr 2009 20:00:03 +0100 Subject: [sldev] Linux variants to support (Re: Projects that I'm working on) In-Reply-To: <49DFED7D.4060503@lindenlab.com> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> <49DFED7D.4060503@lindenlab.com> Message-ID: <49E0E8B3.6010507@gmail.com> Rob Lanphier wrote: > > It's entirely reasonable for us to drop support for older desktop > distros. Since desktop Linux (the platform, not just our Linux viewer) > is in a seemingly perpetual beta, and that distros are pretty much > designed to be upgraded free of charge, it doesn't make as much sense to > support old versions. If there were some statistics that seem accurate > enough to back up the case that virtually no one is still running Ubuntu > 6.06 that expects to run Second Life, that'd pretty much seal the deal > from a business perspective. > > However, there's also a logistical hurdle that we also have to get over. > I'm going to guess that some of this is driven by the fact that we run > Debian Etch on our server infrastructure, and that our build farms and > common libraries (e.g. the ones we package up and provide, as well as > use ourselves) are tuned for supporting them. I don't know for sure if > this is at the heart of the issue, but it's a reason I've at least heard > before. So, I'm going to let other Lindens on this list speak up about it. Debian etch was getting increasingly difficult to build the viewer with its shared libraries. Before lenny came out i was having to back port increasing numbers of packages to keep my etch buildings running. There is also the mesa bug of etch that causes crashes with the viewers built on that platform. As you are using Debian for the servers, i will continue with that Distro for my viewer discussion and because Debian has focus on security and stability it is one of the slower turn around distros. Most others are updating the desktop at a much more regular interval. IMHO, its probably not worth the effort of supporting desktops older than Debian Stable. Or at least phasing out support for old-stable at some point during the life of stable. Which is about 2 years. By this i mean you would still be supporting etch now but looking to phase out this year. This would actually bring the viewer support not that far out of line with the server. Although the server OS upgrades do seem a little over cautiously behind, not that i'm recommending jumping to lenny now, but I think it would be good by say the 12 month point of stable to have a migration strategy in place from oldstable->stable and start implmenting this in the 2nd half of the stable life. So you are fully migrated before stable +1 appears. This would not be a bad time frame for viewer support as well. And in theory would give quite a long "minimum version window" Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090411/c96afb55/attachment.pgp From mike.dickson at hp.com Sat Apr 11 14:13:49 2009 From: mike.dickson at hp.com (Mike Dickson) Date: Sat, 11 Apr 2009 16:13:49 -0500 Subject: [sldev] Linux variants to support (Re: Projects that I'm working on) In-Reply-To: <20090411185541.GA5086@alinoe.com> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> <49DFED7D.4060503@lindenlab.com> <20090411185541.GA5086@alinoe.com> Message-ID: <1239484429.6830.36.camel@mdickson-laptop> Not to mention the kernel version is old enough now to cause some issues getting hardware supported. But then you probably know that :-) Mike On Sat, 2009-04-11 at 18:55 +0000, Carlo Wood wrote: > On Fri, Apr 10, 2009 at 06:08:13PM -0700, Rob Lanphier wrote: > > I'm going to guess that some of this is driven by the fact that we run > > Debian Etch on our server infrastructure, and that our build farms and > > common libraries (e.g. the ones we package up and provide, as well as > > I don't want to go into details (I wouldn't even know > them from the top of my head), but I know that the > difference between etch and lenny (which was released > in Februari) is pretty huge library and C++ wise. > > You should seriously think about moving to Lenny. > -- Mike Dickson BladeSystem infrastructure R&D From josh at lindenlab.com Mon Apr 13 09:29:01 2009 From: josh at lindenlab.com (Joshua Bell) Date: Mon, 13 Apr 2009 09:29:01 -0700 Subject: [sldev] Question involving the rendering of interface windows fromsomeone that doesn't know much about the stuff involved (was Re: Pango (Re:Projects that I'm working on ) ) In-Reply-To: <49DFF9D1.7090106@Gmail.com> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp><49DFE5EC.1080905@lindenlab.com> <49DFF9D1.7090106@Gmail.com> Message-ID: <49E3684D.3000702@lindenlab.com> Tigro Spottystripes wrote: > I can probably be considered an outsider in regards to the client code, > C(++) programming in general, and the technical, practical and other > limitations involved etc, but I'm curious, what would be in the way of > rendering each interface window to a texture and applying the texture to > a quad with the dimensions of the window ? From a casual chat with a developer last week: since the current code re-renders everything every frame, traditional notions of region invalidation* just don't exist in the codebase and would need to be shoehorned in. That's work that would be necessary either for efficiently rendering all UI to one texture, or individual window to separate textures. Giving each window its own texture is just icing on the cake afterwards, and then we have to slap whoever implements wobbly window dragging. (More seriously: all modern windowing systems have moved to this approach and it would probably result in cleaner UI code for things like translucent floaters, but the short term** benefits are limited vs. the cost to implement.) > ps: is it ok to ask things like this in this list or should I refrain > from doing it again in the future? Entirely appropriate. (For bonus points, though, always check the list archives and/or wiki to see if the question has been asked/answered before. For extra bonus points, summarize the discussion to the wiki afterwards if there is information worth sharing/preserving.) Joshua * For non-UI devs: a typical UI implementation pattern is that when the content of a UI element changes (new text arrives, state changes, window moves, contents scrolled, etc) the widget "invalidates", or marks as "dirty", a region (part or all of the rectangle the widget occupies); in the next render pass (often asynchronously, often batched up) only the "dirty" parts are redrawn. Plenty of tricks are done to minimize the number of pixels touched vs. overhead (e.g. combining dirty regions) and the ability of underlying control to render only specific portions of their content is limited and the source of much optimization work. ** The long term benefits are that each window of the UI can take care of itself, darn it, and not have to deal with invalidation caused by other windows in the system covering/uncovering it at unpredictable times. Internally, the window usually still needs to manage what parts are invalidated/dirty, so you do need that foundation. (In simple UIs you can just re-render directly, e.g. re-draw the pixels of a button during the mouse event, but that's not generally the case.) From lenglish5 at cox.net Mon Apr 13 12:08:46 2009 From: lenglish5 at cox.net (Lawson English) Date: Mon, 13 Apr 2009 12:08:46 -0700 Subject: [sldev] Question involving the rendering of interface windows fromsomeone that doesn't know much about the stuff involved (was Re: Pango (Re:Projects that I'm working on ) ) In-Reply-To: <49E3684D.3000702@lindenlab.com> References: <49DE4299.8010700@lindenlab.com> <1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp><49DFE5EC.1080905@lindenlab.com> <49DFF9D1.7090106@Gmail.com> <49E3684D.3000702@lindenlab.com> Message-ID: <49E38DBE.5030805@cox.net> Joshua Bell wrote: > Tigro Spottystripes wrote: > >> I can probably be considered an outsider in regards to the client code, >> C(++) programming in general, and the technical, practical and other >> limitations involved etc, but I'm curious, what would be in the way of >> rendering each interface window to a texture and applying the texture to >> a quad with the dimensions of the window ? >> > > From a casual chat with a developer last week: since the current code > re-renders everything every frame, traditional notions of region > invalidation* just don't exist in the codebase and would need to be > shoehorned in. That's work that would be necessary either for > efficiently rendering all UI to one texture, or individual window to > separate textures. > What little I could grok from looking at the code suggests that everything ends up in teh same pipeline at pretty much the same place at pretty much the same time. That includes 3D stuff and the 2D interface stuff including text. Lawson From q at lindenlab.com Mon Apr 13 16:25:34 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon, 13 Apr 2009 16:25:34 -0700 Subject: [sldev] Current OS trunk not well-suited for use against 1.25 Message-ID: I need to warn anyone who's tracking trunk that we had a bit of a funky merge issue -- some stuff that's dependent on the 1.26 server got merged into trunk last week, but 1.26 isn't live on the grid yet. In particular, some of the search and some of the code relating to the Adults-only changes won't operate properly until 1.26 gets rolled out. This was a process failure for which I'll take most of the blame. To make testing simpler during a transition, I was developing viewer code in the server branch while we waited for an official viewer branch. That code was then migrated to a viewer branch, but I failed to remove it from the server branch, and it got merged to trunk. This means that the viewer-side changes that have made it to trunk are incomplete and probably buggy. It's probably best to just ignore trunk for a few days until we get this straightened out. Sorry about that. Q From GordonWendt at gmail.com Mon Apr 13 18:41:21 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon, 13 Apr 2009 21:41:21 -0400 Subject: [sldev] Current OS trunk not well-suited for use against 1.25 In-Reply-To: References: Message-ID: <493033a70904131841v26db9acbg3a9e59c4ae8d2012@mail.gmail.com> That only effects people who are grabbing the code and building right from the trunk though right? To my knowledge there isn't even a BSI nightly yet for the new 1.26 feature set viewer.... You don't happen to know when that's expected btw do you? -Gordon On Mon, Apr 13, 2009 at 7:25 PM, Kent Quirk (Q Linden) wrote: > I need to warn anyone who's tracking trunk that we had a bit of a > funky merge issue -- some stuff that's dependent on the 1.26 server > got merged into trunk last week, but 1.26 isn't live on the grid yet. > In particular, some of the search and some of the code relating to the > Adults-only changes won't operate properly until 1.26 gets rolled out. > > This was a process failure for which I'll take most of the blame. To > make testing simpler during a transition, I was developing viewer code > in the server branch while we waited for an official viewer branch. > That code was then migrated to a viewer branch, but I failed to remove > it from the server branch, and it got merged to trunk. > > This means that the viewer-side changes that have made it to trunk are > incomplete and probably buggy. It's probably best to just ignore trunk > for a few days until we get this straightened out. Sorry about that. > > Q > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090413/8464cd75/attachment.htm From q at lindenlab.com Mon Apr 13 20:50:10 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Mon, 13 Apr 2009 20:50:10 -0700 Subject: [sldev] Current OS trunk not well-suited for use against 1.25 In-Reply-To: <493033a70904131841v26db9acbg3a9e59c4ae8d2012@mail.gmail.com> References: <493033a70904131841v26db9acbg3a9e59c4ae8d2012@mail.gmail.com> Message-ID: <9EE85217-E271-466B-8B8A-307A390EFA8A@lindenlab.com> Correct; only affects you if you're building/merging from trunk. We'll be releasing the BSI nightly within days. I don't want to promise anything tighter than that to avoid tempting Murphy. Q On Apr 13, 2009, at 6:41 PM, Gordon Wendt wrote: > That only effects people who are grabbing the code and building > right from the trunk though right? To my knowledge there isn't even > a BSI nightly yet for the new 1.26 feature set viewer.... You don't > happen to know when that's expected btw do you? > > -Gordon > > On Mon, Apr 13, 2009 at 7:25 PM, Kent Quirk (Q Linden) > wrote: > I need to warn anyone who's tracking trunk that we had a bit of a > funky merge issue -- some stuff that's dependent on the 1.26 server > got merged into trunk last week, but 1.26 isn't live on the grid yet. > In particular, some of the search and some of the code relating to the > Adults-only changes won't operate properly until 1.26 gets rolled out. > > This was a process failure for which I'll take most of the blame. To > make testing simpler during a transition, I was developing viewer code > in the server branch while we waited for an official viewer branch. > That code was then migrated to a viewer branch, but I failed to remove > it from the server branch, and it got merged to trunk. > > This means that the viewer-side changes that have made it to trunk are > incomplete and probably buggy. It's probably best to just ignore trunk > for a few days until we get this straightened out. Sorry about that. > > Q > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090413/9d015e8e/attachment.htm From lists.secondlife.com at trap.wereanimal.net Mon Apr 13 20:55:44 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Mon, 13 Apr 2009 23:55:44 -0400 Subject: [sldev] Current OS trunk not well-suited for use against 1.25 In-Reply-To: References: Message-ID: <200904132355.44552.lists.secondlife.com@trap.wereanimal.net> On Monday 13 April 2009 7:25:34 pm Kent Quirk (Q Linden) wrote: > > This means that the viewer-side changes that have made it to trunk are > incomplete and probably buggy. It's probably best to just ignore trunk > for a few days until we get this straightened out. Sorry about that. > What was the revision number before the mess up? --Techwolf Lupindo From zzyun at ustc.edu Mon Apr 13 23:20:46 2009 From: zzyun at ustc.edu (Phil Zhou) Date: Mon, 13 Apr 2009 23:20:46 -0700 (PDT) Subject: [sldev] Earn L$100 by Participating in an Online Survey: Call for Participants for An Explorative Study on Second Life Usage Message-ID: <27828041.31951.1239690046341.JavaMail.questionpro@qpmail> Apologies for cross-postings... Dear Sir/Ms. I?m a PhD candidate on Management Information Systems at the College of Business of City University of Hong Kong. I?m searching for participants for a self-administered online survey on Second Life usage. As a participant, all you have to do is to answer five open-ended questions (in conjunction with several demographical questions), which should take you no more than 20 minutes. Your participation will mean a lot to us, and your responses will be a salient piece of contribution to a research report. In appreciation of your effort and contribution, we will pay L$100 to the first 250 respondents who give valuable / comprehensive answers. An extra bonus of L$100 for each will be given to the ?Top 30? respondents who give the ?most? valuable / comprehensive answers (based on the evaluations by a group of three professional researchers). Moreover, we will thereafter send a brief report of the results to each respondent who is willing to leave his/her email address. All the personal information will be confidential and the data will be used only for research. The address of this online survey is http://www.questionpro.com/akira/gateway/1210447-32685391-0. If you have questions, please contact Mr. Phil Zhou at zzyun at ustc.edu. Thank you very much in advance! All the best wishes! Sincerely yours, Phil Zhou __________________________________________________________________________ This email was sent to sldev at lists.secondlife.com on behalf of: Phil Zhou Unsubscribe: http://www.questionpro.com//akira/unsubscribeEmail.do?id=48990454 Report Abuse: http://www.questionpro.com/akira/rptabuse/1-32685391-574164 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090413/0ec74a5a/attachment.htm From alissa_sabre at yahoo.co.jp Tue Apr 14 06:51:44 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Tue, 14 Apr 2009 22:51:44 +0900 Subject: [sldev] ELF .so relocation problem? Message-ID: <1fo4ds6kwPds6s0Js09dv4s7.alissa_sabre@yahoo.co.jp> Dear Developers, I'm having a problem apparently related to ELF relocation mechanism of .so on Linux. I have no idea what causes it, and spent a whole weekend with no success. Any hint or suggestion is appreciated. THE PROBLEM A standalone viewer build apparently succeeded, but, when started, it crushed after the initial black screen appeared. The log says: ** ERROR **: g_thread_init() must be called before dbus_threads_init() OBSERVATION No-standalone viewer built from the same source runs fine. The message is from the function dbus_threads_init(), defined in libdbus-glib-1.so. In glib, there is a global variable, g_threads_got_initialized to indicate whether g_thread_init() has been called. Because Linux uses ELF and the variable is defined in a .so, the main executable, secondlife-bin, has a copy of the variable, and all references to the variable should be directed to the one in secondlife-bin upon relocation. However, for whatever reason, dbus_threads_init()'s access to the variable is directed to the one in libglib-2.0.so. Hence, the above message. I have no idea why the reloc for libdbus-glib-1.so makes the reference to the variable g_threads_got_initialized to point to the _prototype_ in libglib-2.0.so and not the copy in the main executable. DETAILS The viewer was crushing inside the function dbus_thread_init(). After some examination with gdb, I found that the message was wrong, i.e., g_thread_init() was surely called before dbus_threads_init(), but the dbus_threads_init() aborted with the above message. The source of the function looks as: and g_thread_availabe() is a macro defined as: where g_threads_got_initialized is declared as: I also found that the variable g_threads_got_initialized was set to 1 during the call to g_thread_init(), and was kept to the value 1 immediately before the dbus_threads_init() was first invoked. And it still aborted. I disassembled the function (fortunately it is small) and single stepped over machine instructions. Then, I found the particular if statement examined a different location than g_threads_got_initialized. WoW! The location was, the _prototype_ location for the variable g_thread_got_initialized in libglib.so. I have no idea what caused the particular reloc entry to fix up to refer to the prototype location instead of the actual variable location in the secondlife-bin executable. A suspicious fact is that the SL viewer loads libdbus-glib-1.so in an unusual way through apr_dso_load. I'm afraid it caused a strange effects, although the no-standalone built viewer should do exactly the same thing and still runs fine. ENVIRONMENT I'm using Fedora 10 x86. It contains: kernel 2.6.27.21 glibc 2.9-3 dbus-glib 0.76-3 glib 1.2.10-30 Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From robla at lindenlab.com Tue Apr 14 10:55:18 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 14 Apr 2009 10:55:18 -0700 Subject: [sldev] Current OS trunk not well-suited for use against 1.25 In-Reply-To: <200904132355.44552.lists.secondlife.com@trap.wereanimal.net> References: <200904132355.44552.lists.secondlife.com@trap.wereanimal.net> Message-ID: <49E4CE06.3090602@lindenlab.com> On 04/13/2009 08:55 PM, lists.secondlife.com at trap.wereanimal.net wrote: > On Monday 13 April 2009 7:25:34 pm Kent Quirk (Q Linden) wrote: > >> This means that the viewer-side changes that have made it to trunk are >> incomplete and probably buggy. It's probably best to just ignore trunk >> for a few days until we get this straightened out. Sorry about that. >> >> > > What was the revision number before the mess up? I don't know the answer to that, but I suspect it happened around Thursday of last week. Internal rev 116950 (iirc) is a possible culprit. Rob From robla at lindenlab.com Tue Apr 14 11:02:03 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 14 Apr 2009 11:02:03 -0700 Subject: [sldev] http-texture builds Message-ID: <49E4CF9B.50608@lindenlab.com> Hi folks, We could really use your help. We think we've got the crash reporter in good working order to give us good data, and now we need people hammering on builds and giving us a good baseline. Below is the notification of the latest set of builds off of the http-texture branch. Note: these are PREBUILT...you don't need to be a developer to be useful! Download it, try it, and give it a whirl. Also note: this build is KNOWN to crash a lot, so beware. We're encouraging you to try it out not because we're proud of that fact or we think it's going to be the best experience today, but to get the data we need to narrow down the crash bugs we're seeing. Let us know what happens. If you find a crash, and you submit the crash report, let me know if you'd like the processed version of the crash report. I should be able to pull it up and give it to you. Patches to actually fix those bugs would also be greatly appreciated. Rob -------- Original Message -------- Subject: [sldev-commits] Successful Build for http-texture (2105) Date: Mon, 13 Apr 2009 20:08:12 -0700 (PDT) From: buildadmin at lindenlab.com To: sldev-commits at lists.secondlife.com Linux: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2105/SecondLife-i686-1.23.0.2105.tar.bz2 http://secondlife.com/developers/opensource/downloads/2009/http-texture/2105/good-build.Linux Darwin: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2105/SecondLife_1_23_0_2105_OSS.dmg http://secondlife.com/developers/opensource/downloads/2009/http-texture/2105/good-build.Darwin CYGWIN: http://secondlife.com/developers/opensource/downloads/2009/http-texture/2105/Second_Life_1-23-0-2105_OSS_Setup.exe http://secondlife.com/developers/opensource/downloads/2009/http-texture/2105/good-build.CYGWIN ------------------------------------------------------------------------ r2098 | cg.linden | 2009-04-11 09:49:28 -0700 (Sat, 11 Apr 2009) | 1 line Changed paths: M /projects/2009/http-texture/scripts/automated_build_scripts/opensrc-build.sh Run the update_versions helper from the top of the source tree, that seems to be the place it is designed to work... ------------------------------------------------------------------------ r2100 | merov.linden | 2009-04-13 14:52:55 -0700 (Mon, 13 Apr 2009) | 2 lines Changed paths: M /projects/2009/http-texture/indra/newview/lltexturefetch.cpp Reviewed by Bao Part of the fix for DEV-30500. Correct use of inNull() and notNull() on mFormattedImage. ------------------------------------------------------------------------ r2101 | cg.linden | 2009-04-13 15:13:18 -0700 (Mon, 13 Apr 2009) | 1 line Changed paths: M /projects/2009/http-texture/scripts/automated_build_scripts/opensrc-build.sh Upload .pdb, .map and .exe files someplace where our crash reporter can find them for stack traces ------------------------------------------------------------------------ r2103 | cg.linden | 2009-04-13 16:55:49 -0700 (Mon, 13 Apr 2009) | 1 line Changed paths: M /projects/2009/http-texture/scripts/automated_build_scripts/opensrc-build.sh Removed "_" from symbol_files to make symbolfiles, as used in the loop - I hate bash ------------------------------------------------------------------------ r2105 | cg.linden | 2009-04-13 18:39:49 -0700 (Mon, 13 Apr 2009) | 1 line Changed paths: M /projects/2009/http-texture/scripts/automated_build_scripts/opensrc-build.sh Fix path to .pdb, .map and .exe files ------------------------------------------------------------------------ _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits From robin.cornelius at gmail.com Tue Apr 14 11:55:54 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Tue, 14 Apr 2009 19:55:54 +0100 Subject: [sldev] [PATCH] VWR-12758, can not find tut/tut.hpp Message-ID: <49E4DC3A.20409@gmail.com> Sorry if this appears twice/first copy gets held for moderation. I sent it from the wrong email address which is not subscribed to sldev..... Hey Guys, Right i was suppose to raise this on sldev after Rob's hour last Thursday, but with easter and all,... here we are. I'm now not happy with the patch, and some further self review has opened some questions:- Firstly, on http-texture tut is a build dependency and the build fails ungracefully if its not found. I believe all non trivial build dependencies should be tested for and error out at the configure stage if they are not found. This is what the current patch does. What the patch also does is attempt to find tut.h in either /usr/include or /usr/local/include. Now this is pointless as i'm not using the output variable TUT_INCLUDE_DIR in anyway and those folders are the implicit default search folders anyway. That said if you are going to go to the bother of checking the presence of a critical file, it makes sense to cache its location just in case some other code needs it. The original bug description of VWR-12578 had an issue when the tut headers were placed with in the linden include dirs when doing a standalone build which is not a supported configuration, on standalone tut.h and friends need to be in /usr/include/ or /usr/local/include/ My patch does not actually address that but just does a check that tut.h is present in a system searched location that would ensure its usable for build. Any comments or views on this? Thanks Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090414/08d9da10/attachment.pgp From merov at lindenlab.com Tue Apr 14 14:33:49 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 14 Apr 2009 14:33:49 -0700 Subject: [sldev] VWR-12811: crash on Mac Message-ID: Hi, Following up on Rob's email (and just so you know that we are working actively on this...), we know that the most recent Mac build is crash happy and I logged a PJIRA about it: https://jira.secondlife.com/browse/VWR-12811 I'm trying to track this but it's rather hairy. Help appreciated. Hint of situations that make the code more likely to crash or, even, knowledge of Mac configuration that do not crash, will be appreciated. Please comment in the PJIRA. Cheers, - Merov From sldev at free.fr Tue Apr 14 17:22:32 2009 From: sldev at free.fr (Henri Beauchamp) Date: Wed, 15 Apr 2009 02:22:32 +0200 Subject: [sldev] ELF .so relocation problem? In-Reply-To: <1fo4ds6kwPds6s0Js09dv4s7.alissa_sabre@yahoo.co.jp> References: <1fo4ds6kwPds6s0Js09dv4s7.alissa_sabre@yahoo.co.jp> Message-ID: <20090415022232.63b84c40.sldev@free.fr> On Tue, 14 Apr 2009 22:51:44 +0900, Alissa Sabre , wrote: > ENVIRONMENT > > I'm using Fedora 10 x86. It contains: > > kernel 2.6.27.21 > glibc 2.9-3 > dbus-glib 0.76-3 > glib 1.2.10-30 Err... glib v1.2.10 is for use with GTK+ v1.2.10, not with GTK+ v2... The viewer should be linked against glib 2. from inside the viewer directory, try: LD_LIBRARY_PATH="`pwd`"/lib:"`pwd`"/app_settings/mozilla-runtime-linux-i686:"${LD_LIBRARY_PATH}" ldd bin/do-not-directly-run-secondlife-bin to check for actual dependencies. Henri. From tofu.linden at lindenlab.com Tue Apr 14 17:47:23 2009 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Tue, 14 Apr 2009 17:47:23 -0700 Subject: [sldev] Linux variants to support (Re: Projects that I'm working on) In-Reply-To: <49DFED7D.4060503@lindenlab.com> References: <49DE4299.8010700@lindenlab.com><1s7rf9ae07dw4G44s0Gds9kw.alissa_sabre@yahoo.co.jp> <49DFED7D.4060503@lindenlab.com> Message-ID: <49E52E9B.4020908@lindenlab.com> Rob Lanphier wrote: > However, there's also a logistical hurdle that we also have to get over. > I'm going to guess that some of this is driven by the fact that we run > Debian Etch on our server infrastructure, and that our build farms and > common libraries (e.g. the ones we package up and provide, as well as > use ourselves) are tuned for supporting them. I don't know for sure if > this is at the heart of the issue, but it's a reason I've at least heard > before. So, I'm going to let other Lindens on this list speak up about it. There is a logistical hurdle, but it's probably not - dominantly - this one; we've (I've) gone to agonising lengths to ensure that the build farm's toolchain and selection of common libraries does not have much influence on the library version dependencies of the resulting package. (A nice side-effect of being able to control version dependencies is that we can err on the side of conservative [older] version choices until there is a clear reason to bump them, but this is not the primary reason.) The larger hurdle in mandating a really recent Linux distribution (before we even get to the issue of cutting-off users on older distros) is in two halves: * Getting all Linux-enabled devs and QA onto those distributions. * The resulting homogeny in dev and testing environments is going to hurt more than help the effectiveness of QA. Right now having a good spread of distros for testing is serving us really well for QA+repros given how burdened QA is. I'm actually pretty happy to offer *support* for more recent library features, but I want to keep the generic Linden builds as conservative and distro-agnostic as possible; this means either dynamic feature discovery or distro-specific builds. Both is ideal; I love distro- specific builds and I'd like them to be the common delivery mechanism for the Second Life viewer, with the generic Linden builds as a fallback for other distros. We're still talking about how this actually sustainably happens (how it can be automated, how well this meshes with the packaging policies for various distros, etc). Input is always welcome from those with experience in being upstream package providers. From lists.secondlife.com at trap.wereanimal.net Tue Apr 14 22:09:22 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Wed, 15 Apr 2009 01:09:22 -0400 Subject: [sldev] [PATCH] VWR-12758, can not find tut/tut.hpp In-Reply-To: <49E4DC3A.20409@gmail.com> References: <49E4DC3A.20409@gmail.com> Message-ID: <200904150109.22902.lists.secondlife.com@trap.wereanimal.net> On Tuesday 14 April 2009 2:55:54 pm Robin Cornelius wrote: > > The original bug description of VWR-12578 had an issue when the tut > headers were placed with in the linden include dirs when doing a > standalone build which is not a supported configuration, on standalone > tut.h and friends need to be in /usr/include/ or /usr/local/include/ My > patch does not actually address that but just does a check that tut.h is > present in a system searched location that would ensure its usable for > build. > The reason I was placing the tut file within the linden build was due there is no gentoo package for tut. Sence SL supplied the tut files, I use the path in install.xml to download and unpack it in the linden build. I've looked around the net and seen that only about one or two distros supply tut in there package repository. If LL did not supplied tut, I would have been force to either disable tut or make a separate ebuild and put a depends on it. --Techwolf Lupindo From me at signpostmarv.name Wed Apr 15 04:46:34 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Wed, 15 Apr 2009 12:46:34 +0100 Subject: [sldev] fresh shadow draft binaries Message-ID: <49E5C91A.1040407@signpostmarv.name> Any fresh shadow draft builds floating about ? ~ Marv. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090415/3f534c57/attachment.bin From open at autistici.org Wed Apr 15 05:26:14 2009 From: open at autistici.org (Opensource Obscure) Date: Wed, 15 Apr 2009 12:26:14 +0000 Subject: [sldev] fresh shadow draft binaries In-Reply-To: <49E5C91A.1040407@signpostmarv.name> References: <49E5C91A.1040407@signpostmarv.name> Message-ID: On Wed, 15 Apr 2009 12:46:34 +0100, SignpostMarv Martin wrote: > Any fresh shadow draft builds floating about ? the http-texture binaries linked from the open source portal page were built 1-2 days ago: https://wiki.secondlife.com/wiki/Category:Open_Source_Portal you can also look for emails with subject "Successful Build for http-texture" in sldev-commits archives https://lists.secondlife.com/pipermail/sldev-commits/2009-April if you're on Linux, here are two unofficial March builds from render-pipeline branch (could disappear soon): http://drop.io/linuxshadows If you don't mind to compile, I'd suggest to build yourself a viewer from render-pipeline branch, as unfortunately, new "projected texture" features weren't committed to the http-texture branch. And those features kick asses (custom textures that cast shadows from objects - not from sun/moon only) http://www.youtube.com/watch?v=18zR_XXNdLY http://www.youtube.com/watch?v=bqiOsAE3FYI http://www.youtube.com/watch?v=R_CQPRcHZGU http://www.youtube.com/watch?v=c5VCcO7NFpo bye Opensource Obscure -- twitter.com/oobscure - friendfeed.com/oobscure From alissa_sabre at yahoo.co.jp Wed Apr 15 05:37:36 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Wed, 15 Apr 2009 21:37:36 +0900 Subject: [sldev] ELF .so relocation problem? Message-ID: > > ENVIRONMENT > > > > I'm using Fedora 10 x86. It contains: > > > > kernel 2.6.27.21 > > glibc 2.9-3 > > dbus-glib 0.76-3 > > glib 1.2.10-30 > > Err... glib v1.2.10 is for use with GTK+ v1.2.10, not with GTK+ v2... > The viewer should be linked against glib 2. Oops, you are right. My real glib version was: 2.18.4-1. -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From soft at lindenlab.com Wed Apr 15 08:34:27 2009 From: soft at lindenlab.com (Soft) Date: Wed, 15 Apr 2009 10:34:27 -0500 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda From robla at lindenlab.com Wed Apr 15 15:43:53 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 15 Apr 2009 15:43:53 -0700 Subject: [sldev] A few call stacks from crash reports Message-ID: <49E66329.5090906@lindenlab.com> Hi everyone, Thanks for answering the call to download the latest viewer build off the open source portal and give it a whirl. If you haven't done it yet, the latest is here: https://wiki.secondlife.com/wiki/Open_Source_Portal Here's a few call stacks for you to look at if you're interested. It seems all of the call stacks we have so far are unique to an individual...we don't have any reports yet from two different accounts getting the exact same stack, but I could be reading things wrong. We do have several cases where one individual reports the same crasher multiple times. Total of 31 crashes so far in the 2105 version of the viewer (unclear what our session and/or agent count is...still investigating where to get reliable numbers, but it's still tiny). We'd really love some help getting these crashing bugs figured out. We'd like to be able to offer this version of the viewer in a much more prominent place, but obviously can't feel good about doing that until we get to the bottom of the crashing issues (at a minimum). Rob -------- call stack #1: [0] usleep$NOCANCEL$UNIX2003 [libsystem.b.dylib unknown] [1] abort [libsystem.b.dylib unknown] [2] 0x9080f000 [libstdc++.6.dylib unknown] [3] __gxx_personality_v0 [libstdc++.6.dylib unknown] [4] std::terminate() [libstdc++.6.dylib unknown] [5] std::type_info::~type_info() [libstdc++.6.dylib unknown] [6] LLMenuItemBranchGL::getChildView(std::basic_string, std::allocator > const&, int, int) const [com.secondlife.indra.viewer unknown] [7] LLView::getChildView(std::basic_string, std::allocator > const&, int, int) const [com.secondlife.indra.viewer unknown] [8] LLView::getChildView(std::basic_string, std::allocator > const&, int, int) const [com.secondlife.indra.viewer unknown] [9] LLPanel::getChildView(std::basic_string, std::allocator > const&, int, int) const [com.secondlife.indra.viewer unknown] [10] LLInventoryPanel* LLView::getChild(std::basic_string, std::allocator > const&, int, int) const [com.secondlife.indra.viewer unknown] [11] LLInventoryView::~LLInventoryView() [com.secondlife.indra.viewer unknown] [12] LLView::~LLView() [com.secondlife.indra.viewer unknown] [13] LLFloaterView::~LLFloaterView() [com.secondlife.indra.viewer unknown] [14] LLView::~LLView() [com.secondlife.indra.viewer unknown] [15] LLRootView::~LLRootView() [com.secondlife.indra.viewer unknown] [16] LLViewerWindow::shutdownViews() [com.secondlife.indra.viewer unknown] [17] LLAppViewer::cleanup() [com.secondlife.indra.viewer unknown] [18] main [com.secondlife.indra.viewer unknown] [19] _start [com.secondlife.indra.viewer unknown] [20] start [com.secondlife.indra.viewer unknown] Call stack #2: [0] LLError::crashAndLoop [secondlife-bin llerror.cpp:1214] [1] LLError::Log::flush [secondlife-bin llerror.cpp:1138] [2] LLVertexBuffer::setupVertexBuffer [secondlife-bin llvertexbuffer.cpp:1132] [3] LLVertexBuffer::setBuffer [secondlife-bin llvertexbuffer.cpp:1117] [4] LLRenderPass::pushBatch [secondlife-bin lldrawpool.cpp:505] [5] LLRenderPass::pushBatches [secondlife-bin lldrawpool.cpp:457] [6] LLRenderPass::renderTexture [secondlife-bin lldrawpool.cpp:448] [7] LLDrawPoolSimple::render [secondlife-bin lldrawpoolsimple.cpp:147] [8] LLPipeline::renderGeom [secondlife-bin pipeline.cpp:2641] [9] display [secondlife-bin llviewerdisplay.cpp:802] [10] LLAppViewer::mainLoop [secondlife-bin llappviewer.cpp:938] [11] WinMain [secondlife-bin llappviewerwin32.cpp:193] [12] __tmainCRTStartup [secondlife-bin crtexe.c:589] [13] Unknown [kernel32.dll ] [14] Unknown [ntdll.dll ] [15] Unknown [ntdll.dll ] Call stack #3: [0] LLTextureFetchWorker::callbackDecoded [secondlife-bin lltexturefetch.cpp:1302] [1] LLTextureFetchWorker::DecodeResponder::completed [secondlife-bin lltexturefetch.cpp:123] [2] LLImageDecodeThread::ImageRequest::finishRequest [secondlife-bin llimageworker.cpp:154] [3] LLQueuedThread::processNextRequest [secondlife-bin llqueuedthread.cpp:430] [4] LLQueuedThread::run [secondlife-bin llqueuedthread.cpp:485] [5] LLThread::staticRun [secondlife-bin llthread.cpp:78] [6] apr_threadattr_guardsize_set [secondlife-bin unknownfile:0] [7] Unknown [msvcr80.dll ] Call stack #4: [0] Curl_llist_insert_next [secondlife-bin unknownfile:0] [1] Curl_hash_add [secondlife-bin unknownfile:0] [2] Curl_cache_addr [secondlife-bin unknownfile:0] [3] curl_getdate [secondlife-bin unknownfile:0] [4] Curl_addrinfo4_callback [secondlife-bin unknownfile:0] [5] Curl_cookie_clearall [secondlife-bin unknownfile:0] [6] Unknown [msvcr80.dll ] [7] Unknown [msvcr80.dll ] [8] Unknown [kernel32.dll ] [9] Unknown [msvcr80.dll ] Call stack #5: 0] Curl_llist_insert_next [secondlife-bin unknownfile:0] [1] Curl_hash_add [secondlife-bin unknownfile:0] [2] Curl_cache_addr [secondlife-bin unknownfile:0] [3] curl_getdate [secondlife-bin unknownfile:0] [4] Curl_addrinfo4_callback [secondlife-bin unknownfile:0] [5] Curl_cookie_clearall [secondlife-bin unknownfile:0] [6] Unknown [msvcr80.dll ] [7] Unknown [msvcr80.dll ] [8] Unknown [ntdll.dll ] [9] Unknown [ntdll.dll ] Call stack #6: 0] semaphore_wait_signal_trap [libsystem.b.dylib unknown] [1] LLQueuedThread::updateQueue(unsigned) [com.secondlife.indra.viewer unknown] [2] LLImageDecodeThread::update(unsigned) [com.secondlife.indra.viewer unknown] [3] LLAppViewer::mainLoop() [com.secondlife.indra.viewer unknown] [4] main [com.secondlife.indra.viewer unknown] [5] _start [com.secondlife.indra.viewer unknown] [6] start [com.secondlife.indra.viewer unknown] From merov at lindenlab.com Wed Apr 15 16:04:29 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 15 Apr 2009 16:04:29 -0700 Subject: [sldev] A few call stacks from crash reports In-Reply-To: <49E66329.5090906@lindenlab.com> References: <49E66329.5090906@lindenlab.com> Message-ID: Hi, As it happened, I was logging PJIRA records with comments to cover some of those stack trace (the ones I investigated). Note that there's a "non-crashing" bug that I'm also investigating as it was mentioned to me on IRC yesterday and I was able to repro it: - https://jira.secondlife.com/browse/VWR-12811 : everything renders "gray" . See the JIRA for specifics My comments on the stack trace here under: On Apr 15, 2009, at 3:43 PM, Rob Lanphier wrote: > call stack #1: > [0] usleep$NOCANCEL$UNIX2003 [libsystem.b.dylib unknown] > [1] abort [libsystem.b.dylib unknown] > [2] 0x9080f000 [libstdc++.6.dylib unknown] > [3] __gxx_personality_v0 [libstdc++.6.dylib unknown] > [4] std::terminate() [libstdc++.6.dylib unknown] > [5] std::type_info::~type_info() [libstdc++.6.dylib unknown] > [6] LLMenuItemBranchGL::getChildView(std::basic_string, > std::allocator > > const&, int, int) const [com.secondlife.indra.viewer unknown] > [7] LLView::getChildView(std::basic_string, std::allocator > const&, > int, int) const [com.secondlife.indra.viewer unknown] > [8] LLView::getChildView(std::basic_string, std::allocator > const&, > int, int) const [com.secondlife.indra.viewer unknown] > [9] LLPanel::getChildView(std::basic_string, std::allocator > const&, > int, int) const [com.secondlife.indra.viewer unknown] > [10] LLInventoryPanel* LLView::getChild(std::basic_string, > std::allocator > const&, int, int) const [com.secondlife.indra.viewer > unknown] > [11] LLInventoryView::~LLInventoryView() [com.secondlife.indra.viewer > unknown] > [12] LLView::~LLView() [com.secondlife.indra.viewer unknown] > [13] LLFloaterView::~LLFloaterView() [com.secondlife.indra.viewer > unknown] > [14] LLView::~LLView() [com.secondlife.indra.viewer unknown] > [15] LLRootView::~LLRootView() [com.secondlife.indra.viewer unknown] > [16] LLViewerWindow::shutdownViews() [com.secondlife.indra.viewer > unknown] > [17] LLAppViewer::cleanup() [com.secondlife.indra.viewer unknown] > [18] main [com.secondlife.indra.viewer unknown] > [19] _start [com.secondlife.indra.viewer unknown] > [20] start [com.secondlife.indra.viewer unknown] That one is new to me. Someone has repro steps? > Call stack #2: > [0] LLError::crashAndLoop [secondlife-bin llerror.cpp:1214] > [1] LLError::Log::flush [secondlife-bin llerror.cpp:1138] > [2] LLVertexBuffer::setupVertexBuffer [secondlife-bin > llvertexbuffer.cpp:1132] > [3] LLVertexBuffer::setBuffer [secondlife-bin llvertexbuffer.cpp:1117] > [4] LLRenderPass::pushBatch [secondlife-bin lldrawpool.cpp:505] > [5] LLRenderPass::pushBatches [secondlife-bin lldrawpool.cpp:457] > [6] LLRenderPass::renderTexture [secondlife-bin lldrawpool.cpp:448] > [7] LLDrawPoolSimple::render [secondlife-bin lldrawpoolsimple.cpp:147] > [8] LLPipeline::renderGeom [secondlife-bin pipeline.cpp:2641] > [9] display [secondlife-bin llviewerdisplay.cpp:802] > [10] LLAppViewer::mainLoop [secondlife-bin llappviewer.cpp:938] > [11] WinMain [secondlife-bin llappviewerwin32.cpp:193] > [12] __tmainCRTStartup [secondlife-bin crtexe.c:589] > [13] Unknown [kernel32.dll ] > [14] Unknown [ntdll.dll ] > [15] Unknown [ntdll.dll ] This one was first reported by Philip and I was able to repro. Also someone on IRC mentioned that same issue to me yesterday. JIRA: https://jira.secondlife.com/browse/VWR-12827 The skinny: this is *not* an http-texture specific bug. I get that same crash using the trunk build or any 1.24 code base. Doesn't repro with 1.23 (to the relief of QA...). > Call stack #3: > [0] LLTextureFetchWorker::callbackDecoded [secondlife-bin > lltexturefetch.cpp:1302] > [1] LLTextureFetchWorker::DecodeResponder::completed [secondlife-bin > lltexturefetch.cpp:123] > [2] LLImageDecodeThread::ImageRequest::finishRequest [secondlife-bin > llimageworker.cpp:154] > [3] LLQueuedThread::processNextRequest [secondlife-bin > llqueuedthread.cpp:430] > [4] LLQueuedThread::run [secondlife-bin llqueuedthread.cpp:485] > [5] LLThread::staticRun [secondlife-bin llthread.cpp:78] > [6] apr_threadattr_guardsize_set [secondlife-bin unknownfile:0] > [7] Unknown [msvcr80.dll ] That one seems to be Mac specific and I was able to repro and step through it. JIRA: - https://jira.secondlife.com/browse/VWR-12811 - https://jira.secondlife.com/browse/VWR-12775 I know, that's 2 JIRA but I logged them thinking that was 2 different bugs. It's not. Note that I have a patch to avoid the crash condition but, after talking to bao, we decided not to commit the patch so that we can understand *why* we get into that state (we should *not* get to that decoder code part with an unexisting image...). I'm tracking that one down as it is clearly an http-texture bug. > Call stack #4: > [0] Curl_llist_insert_next [secondlife-bin unknownfile:0] > [1] Curl_hash_add [secondlife-bin unknownfile:0] > [2] Curl_cache_addr [secondlife-bin unknownfile:0] > [3] curl_getdate [secondlife-bin unknownfile:0] > [4] Curl_addrinfo4_callback [secondlife-bin unknownfile:0] > [5] Curl_cookie_clearall [secondlife-bin unknownfile:0] > [6] Unknown [msvcr80.dll ] > [7] Unknown [msvcr80.dll ] > [8] Unknown [kernel32.dll ] > [9] Unknown [msvcr80.dll ] > Call stack #5: > 0] Curl_llist_insert_next [secondlife-bin unknownfile:0] > [1] Curl_hash_add [secondlife-bin unknownfile:0] > [2] Curl_cache_addr [secondlife-bin unknownfile:0] > [3] curl_getdate [secondlife-bin unknownfile:0] > [4] Curl_addrinfo4_callback [secondlife-bin unknownfile:0] > [5] Curl_cookie_clearall [secondlife-bin unknownfile:0] > [6] Unknown [msvcr80.dll ] > [7] Unknown [msvcr80.dll ] > [8] Unknown [ntdll.dll ] > [9] Unknown [ntdll.dll ] Nice to see those Curl crashers again. I haven't experienced them in a while though (too busy crashing before that I guess...). Not logged yet though. > Call stack #6: > 0] semaphore_wait_signal_trap [libsystem.b.dylib unknown] > [1] LLQueuedThread::updateQueue(unsigned) [com.secondlife.indra.viewer > unknown] > [2] LLImageDecodeThread::update(unsigned) [com.secondlife.indra.viewer > unknown] > [3] LLAppViewer::mainLoop() [com.secondlife.indra.viewer unknown] > [4] main [com.secondlife.indra.viewer unknown] > [5] _start [com.secondlife.indra.viewer unknown] > [6] start [com.secondlife.indra.viewer unknown] I think this is another symptom of your #3. I could track that the worker can be in a weird state and get the decoder to crash or not (most of the time, not). We basically have those 2 possible stack trace when crashing in that state. Cheers, - Merov From dmahalko at gmail.com Thu Apr 16 01:08:41 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu, 16 Apr 2009 03:08:41 -0500 Subject: [sldev] A few call stacks from crash reports In-Reply-To: <49E66329.5090906@lindenlab.com> References: <49E66329.5090906@lindenlab.com> Message-ID: This test viewer just freezes on me with XP SP3 after about 10 minutes, flying around with the texture console open and 256 meter view. It does not display any errors, I can't move, and the window resize box grays out with (Not Responding) in the title bar. I can end task on it, but then it doesn't do a crash report. Therefore I have nothing useful to report to the JIRA... Also it is annoying that as a beta client, it reuses my normal client's preferences folder in "Application Data". I really do not like starting up a beta client only to see that it immediately decides to completely expunge the cache of the regular non-crashing client. Ack! Why can't it make its own test preferences folder in "Application Data" and leave my regular client preferences/cache alone? - Dale Mahalko / Scalar Tardis On Wed, Apr 15, 2009 at 5:43 PM, Rob Lanphier wrote: > Hi everyone, > > Thanks for answering the call to download the latest viewer build off > the open source portal and give it a whirl. ?If you haven't done it yet, > the latest is here: > https://wiki.secondlife.com/wiki/Open_Source_Portal > From teravus at gmail.com Thu Apr 16 01:16:49 2009 From: teravus at gmail.com (Teravus Ovares) Date: Thu, 16 Apr 2009 04:16:49 -0400 Subject: [sldev] A few call stacks from crash reports In-Reply-To: References: <49E66329.5090906@lindenlab.com> Message-ID: <34cc66250904160116s35b312a7n5ee2143025db5daf@mail.gmail.com> Hmm, at least for me.. it froze for about 2 minutes, the debug console said 'Entering win32 error handler', then it popped up the crash reporter. You might just have to wait a few minutes for it to 'enter the win32 error handler' Best Regards Teravus On 4/16/09, Dale Mahalko wrote: > This test viewer just freezes on me with XP SP3 after about 10 > minutes, flying around with the texture console open and 256 meter > view. It does not display any errors, I can't move, and the window > resize box grays out with (Not Responding) in the title bar. I can end > task on it, but then it doesn't do a crash report. Therefore I have > nothing useful to report to the JIRA... > > > Also it is annoying that as a beta client, it reuses my normal > client's preferences folder in "Application Data". I really do not > like starting up a beta client only to see that it immediately decides > to completely expunge the cache of the regular non-crashing client. > Ack! Why can't it make its own test preferences folder in "Application > Data" and leave my regular client preferences/cache alone? > > - Dale Mahalko / Scalar Tardis > > > On Wed, Apr 15, 2009 at 5:43 PM, Rob Lanphier wrote: > > Hi everyone, > > > > Thanks for answering the call to download the latest viewer build off > > the open source portal and give it a whirl. If you haven't done it yet, > > the latest is here: > > https://wiki.secondlife.com/wiki/Open_Source_Portal > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From xuxiix at gmail.com Thu Apr 16 01:22:25 2009 From: xuxiix at gmail.com (Mikkel Hansen) Date: Thu, 16 Apr 2009 10:22:25 +0200 Subject: [sldev] Compiling error on Linux Message-ID: <2da30a0e0904160122s3c0a5e8sdc12af14a361cea0@mail.gmail.com> Hello, I'm trying to build the SL viewer on Linux. However... I can only get this far: [ 1%] Built target llaudio [ 4%] Built target llcharacter [ 11%] Built target llcommon [ 13%] Built target llimage [ 13%] Built target llimagej2coj [ 14%] Built target llinventory [ 18%] Built target llmath [ 19%] Built target llmedia [ 29%] Built target llmessage [ 30%] Built target llprimitive [ 32%] Built target llrender [ 33%] Built target llvfs [ 34%] Built target llwindow [ 34%] Built target llxml [ 36%] Built target lscript_compile [ 37%] Built target lscript_execute [ 37%] Built target lscript_library [ 37%] Built target llcrashlogger [ 44%] Built target llui [ 44%] Built target linux-crash-logger [100%] Built target secondlife-bin make[2]: *** No rule to make target `../newview/SecondLife-i686-1.22.11.5.tar.bz2', needed by `newview/CMakeFiles/package'. Stop. make[1]: *** [newview/CMakeFiles/package.dir/all] Error 2 make: *** [all] Error 2 Anyone know why that's happening and how I can fix it? Thanks, Mikkel -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090416/d4e2ecae/attachment.htm From robin.cornelius at gmail.com Thu Apr 16 01:32:26 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 16 Apr 2009 09:32:26 +0100 Subject: [sldev] Compiling error on Linux In-Reply-To: <2da30a0e0904160122s3c0a5e8sdc12af14a361cea0@mail.gmail.com> References: <2da30a0e0904160122s3c0a5e8sdc12af14a361cea0@mail.gmail.com> Message-ID: On Thu, Apr 16, 2009 at 9:22 AM, Mikkel Hansen wrote: > Hello, > > I'm trying to build the SL viewer on Linux. However... I can only get this > far: > > `../newview/SecondLife-i686-1.22.11.5.tar.bz2', needed by > `newview/CMakeFiles/package'. Stop. > make[1]: *** [newview/CMakeFiles/package.dir/all] Error 2 > make: *** [all] Error 2 > > What version of cmake are you using? I'm guessing your using 2.6.0?, if so please upgrade to 2.6.2. If not you may want to manually go in to the build directory which is indra/viewer-linux***/ (can't remember exact name) and run :- make VERBOSE=1 for some more detailed output Regards Robin From josh at lindenlab.com Thu Apr 16 08:47:13 2009 From: josh at lindenlab.com (Joshua Bell) Date: Thu, 16 Apr 2009 08:47:13 -0700 Subject: [sldev] A few call stacks from crash reports In-Reply-To: References: <49E66329.5090906@lindenlab.com> Message-ID: <49E75301.7080802@lindenlab.com> Dale Mahalko wrote: > > Also it is annoying that as a beta client, it reuses my normal > client's preferences folder in "Application Data". I really do not > like starting up a beta client only to see that it immediately decides > to completely expunge the cache of the regular non-crashing client. > Ack! Why can't it make its own test preferences folder in "Application > Data" and leave my regular client preferences/cache alone? There's a flag "--settings" that can be passed into the viewer that specifies the preferences filename to use. This is usually specified in the shortcuts (Windows)/arguments.txt (MacOS) created used for viewers in different distribution channels or test grids (e.g. "--settings settings_aditi_beta.xml"). Depending on how your viewer is packaged or how you're running it you may need to specify it manually. It doesn't modify the cache location, though, and it uses the same directories. So... that'd maybe solve half your problem. From jessesa at gmail.com Thu Apr 16 09:37:57 2009 From: jessesa at gmail.com (Jesse Barnett) Date: Thu, 16 Apr 2009 12:37:57 -0400 Subject: [sldev] A few call stacks from crash reports In-Reply-To: References: <49E66329.5090906@lindenlab.com> Message-ID: On Thu, Apr 16, 2009 at 4:08 AM, Dale Mahalko wrote: > Also it is annoying that as a beta client, it reuses my normal > client's preferences folder in "Application Data". I really do not > like starting up a beta client only to see that it immediately decides > to completely expunge the cache of the regular non-crashing client. > Ack! Why can't it make its own test preferences folder in "Application > Data" and leave my regular client preferences/cache alone? > > - Dale Mahalko / Scalar Tardis > Seconded! I run 3 different versions of SL and this poisoned the lot. The crashes propogated out to the other stable viewers. I had to delete the cache files to clear the problem. Jesse Barnett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090416/880c1a37/attachment.htm From jessesa at gmail.com Thu Apr 16 09:55:58 2009 From: jessesa at gmail.com (Jesse Barnett) Date: Thu, 16 Apr 2009 12:55:58 -0400 Subject: [sldev] A few call stacks from crash reports In-Reply-To: References: <49E66329.5090906@lindenlab.com> Message-ID: > > > Seconded! I run 3 different versions of SL and this poisoned the lot. The > crashes propogated out to the other stable viewers. I had to delete the > cache files to clear the problem. > > Jesse Barnett > I am amending that to I am just going to have to uninstall all the viewers and clean up before reinstall. Everything had been stable for months before this. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090416/09e45aa7/attachment.htm From soft at lindenlab.com Thu Apr 16 09:56:32 2009 From: soft at lindenlab.com (Soft) Date: Thu, 16 Apr 2009 11:56:32 -0500 Subject: [sldev] A few call stacks from crash reports In-Reply-To: <49E75301.7080802@lindenlab.com> References: <49E66329.5090906@lindenlab.com> <49E75301.7080802@lindenlab.com> Message-ID: On Thu, Apr 16, 2009 at 10:47 AM, Joshua Bell wrote: > Dale Mahalko wrote: >> >> Also it is annoying that as a beta client, it reuses my normal >> client's preferences folder in "Application Data". I really do not >> like starting up a beta client only to see that it immediately decides >> to completely expunge the cache of the regular non-crashing client. >> Ack! Why can't it make its own test preferences folder in "Application >> Data" and leave my regular client preferences/cache alone? > > There's a flag "--settings" that can be passed into the viewer that > specifies the preferences filename to use. This is usually specified in > the shortcuts (Windows)/arguments.txt (MacOS) created used for viewers > in different distribution channels or test grids (e.g. "--settings > settings_aditi_beta.xml"). Depending on how your viewer is packaged or > how you're running it you may need to specify it manually. > > It doesn't modify the cache location, though, and it uses the same > directories. So... that'd maybe solve half your problem. The settings can specify a cache location though, so pointing to a different settings file can still specify an alternate cache. With existing code, one can create a different settings file for the everyday release build by pointing to a different settings group with the above command line option. Then, all the dev branches would go on using the default location and wouldn't run the risk of screwing up the day-to-day viewer's cache or settings. From robla at lindenlab.com Thu Apr 16 12:06:01 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 16 Apr 2009 12:06:01 -0700 Subject: [sldev] Writing a FindNDOF.cmake Message-ID: <49E78199.1050709@lindenlab.com> Hi folks, Work on the easybuild branch continues apace. Here's a recent commit for NDOF (support library for the 3DConnexion Space Navigator) which makes Linux 64-bit support less painful. Anyone care to write the missing FindNDOF referred to in the patch below? Rob -------- Original Message -------- Subject: [sldev-commits] r2122 - projects/2009/easybuild/indra/cmake Date: Thu, 16 Apr 2009 13:25:08 -0500 (CDT) From: king.broadfoot at svn.secondlife.com Reply-To: noreply at lindenlab.com To: sldev-commits at lists.secondlife.com Author: king.broadfoot Date: 2009-04-16 13:25:08 -0500 (Thu, 16 Apr 2009) New Revision: 2122 Modified: projects/2009/easybuild/indra/cmake/NDOF.cmake Trac: http://svn.secondlife.com/trac/linden/changeset/2122 Log: Do not request prebuilt ndofdev in STANDALONE mode This disables NDOF support on linux64, but allows the build to complete. Support can be re-enabled when a proper FindNDOF module is written. Modified: projects/2009/easybuild/indra/cmake/NDOF.cmake =================================================================== --- projects/2009/easybuild/indra/cmake/NDOF.cmake 2009-04-16 17:35:31 UTC (rev 2121) +++ projects/2009/easybuild/indra/cmake/NDOF.cmake 2009-04-16 18:25:08 UTC (rev 2122) @@ -1,7 +1,16 @@ # -*- cmake -*- include(Prebuilt) -use_prebuilt_binary(ndofdev) +if (STANDALONE) + # No ndofdev is available for linux64. + if(LINUX AND "${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64") + message(STATUS "Building without N-DoF joystick support") + return() + endif(LINUX AND "${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64") + # TODO: include(FindNDOF) +else (STANDALONE) + use_prebuilt_binary(ndofdev) +endif (STANDALONE) if (WINDOWS OR DARWIN OR LINUX) add_definitions(-DLIB_NDOF=1) _______________________________________________ Click here to unsubscribe or manage your list subscription: https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits From dmahalko at gmail.com Thu Apr 16 14:28:43 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu, 16 Apr 2009 16:28:43 -0500 Subject: [sldev] 1.21 change makes SL work better for enterprises Message-ID: I see a change is being made to how the client stores cache data. The cache was previously going into \Documents and Settings\Username\Application Data\SecondLife\cache Which was bad for corporations and schools like me that use roaming profiles, since this would mean the SL cache is roaming with the user on the network, being stored on the servers. This reduces both network performance and server backup storage, and was a strike against using Second Life in a business environment. With 1.21 the cache is now being put into: \Documents and Settings\Username\Local Settings\Application Data\SecondLife\cache This is a far better way to do it. Local Settings does not roam with the user, and can stay on the computer until the user logs in again, and their account picks up the previously cached data. In my case the local account data gets deleted when roaming users log off (volitale profile) to keep lab computers from running out of disk space due to storing so much old unused profile data from many different users. It would be nice if there could be a centralized "cross-user local workstation cache" for networks using roaming. This would allow a single large cache on the local lab computer that isn't deleted when people log off and can be reused by different roaming students for class lab sessions going to the same parts of the world. A possible shared-cache location might be: \Documents and Settings\All Users\Application Data\SecondLife\cache Though I believe special write privileges are needed for programs to write data into All Users. Students login using the restricted Users group so they don't have write access to anywhere they want, but programs storing data in All Users have proper write privileges even if the logged-in user does not. - Dale Mahalko / Scalar Tardis ============================== Reference: http://svn.secondlife.com/trac/linden/browser/trunk/indra/newview/llappviewer.cpp 2626 #if LL_WINDOWS || LL_DARWIN 2627 // NOTE: (Nyx) as of 1.21, cache for mac is moving to /library/caches/SecondLife from 2628 // /library/application support/SecondLife/cache This should clear/delete the old dir. 2629 2630 // As of 1.23 the Windows cache moved from 2631 // C:\Documents and Settings\James\Application Support\SecondLife\cache 2632 // to 2633 // C:\Documents and Settings\James\Local Settings\Application Support\SecondLife 2634 // 2635 // The Windows Vista equivalent is from 2636 // C:\Users\James\AppData\Roaming\SecondLife\cache 2637 // to 2638 // C:\Users\James\AppData\Local\SecondLife 2639 // 2640 // Note the absence of \cache on the second path. James. 2641 2642 // Only do this once per fresh install of this version. 2643 if (gSavedSettings.getBOOL("MigrateCacheDirectory")) From dmahalko at gmail.com Thu Apr 16 14:29:01 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu, 16 Apr 2009 16:29:01 -0500 Subject: [sldev] 1.21 change makes SL work better for enterprises Message-ID: I see a change is being made to how the client stores cache data. The cache was previously going into \Documents and Settings\Username\Application Data\SecondLife\cache Which was bad for corporations and schools like me that use roaming profiles, since this would mean the SL cache is roaming with the user on the network, being stored on the servers. This reduces both network performance and server backup storage, and was a strike against using Second Life in a business environment. With 1.21 the cache is now being put into: \Documents and Settings\Username\Local Settings\Application Data\SecondLife\cache This is a far better way to do it. Local Settings does not roam with the user, and can stay on the computer until the user logs in again, and their account picks up the previously cached data. In my case the local account data gets deleted when roaming users log off (volitale profile) to keep lab computers from running out of disk space due to storing so much old unused profile data from many different users. It would be nice if there could be a centralized "cross-user local workstation cache" for networks using roaming. This would allow a single large cache on the local lab computer that isn't deleted when people log off and can be reused by different roaming students for class lab sessions going to the same parts of the world. A possible shared-cache location might be: \Documents and Settings\All Users\Application Data\SecondLife\cache Though I believe special write privileges are needed for programs to write data into All Users. Students login using the restricted Users group so they don't have write access to anywhere they want, but programs storing data in All Users have proper write privileges even if the logged-in user does not. - Dale Mahalko / Scalar Tardis ============================== Reference: http://svn.secondlife.com/trac/linden/browser/trunk/indra/newview/llappviewer.cpp 2626 #if LL_WINDOWS || LL_DARWIN 2627 // NOTE: (Nyx) as of 1.21, cache for mac is moving to /library/caches/SecondLife from 2628 // /library/application support/SecondLife/cache This should clear/delete the old dir. 2629 2630 // As of 1.23 the Windows cache moved from 2631 // C:\Documents and Settings\James\Application Support\SecondLife\cache 2632 // to 2633 // C:\Documents and Settings\James\Local Settings\Application Support\SecondLife 2634 // 2635 // The Windows Vista equivalent is from 2636 // C:\Users\James\AppData\Roaming\SecondLife\cache 2637 // to 2638 // C:\Users\James\AppData\Local\SecondLife 2639 // 2640 // Note the absence of \cache on the second path. James. 2641 2642 // Only do this once per fresh install of this version. 2643 if (gSavedSettings.getBOOL("MigrateCacheDirectory")) From tigrospottystripes at gmail.com Thu Apr 16 15:06:52 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Thu, 16 Apr 2009 19:06:52 -0300 Subject: [sldev] 1.21 change makes SL work better for enterprises In-Reply-To: References: Message-ID: <49E7ABFC.6030408@Gmail.com> what prevents you from manually configuring and/or orienting the other users to do so, the cache to use a folder where network usage, write permissions and any other concerns are dealt with? Dale Mahalko escreveu: > I see a change is being made to how the client stores cache data. > > The cache was previously going into > \Documents and Settings\Username\Application Data\SecondLife\cache > > Which was bad for corporations and schools like me that use roaming > profiles, since this would mean the SL cache is roaming with the user > on the network, being stored on the servers. This reduces both network > performance and server backup storage, and was a strike against using > Second Life in a business environment. > > > With 1.21 the cache is now being put into: > \Documents and Settings\Username\Local Settings\Application > Data\SecondLife\cache > > This is a far better way to do it. Local Settings does not roam with > the user, and can stay on the computer until the user logs in again, > and their account picks up the previously cached data. > > > In my case the local account data gets deleted when roaming users log > off (volitale profile) to keep lab computers from running out of disk > space due to storing so much old unused profile data from many > different users. > > It would be nice if there could be a centralized "cross-user local > workstation cache" for networks using roaming. This would allow a > single large cache on the local lab computer that isn't deleted when > people log off and can be reused by different roaming students for > class lab sessions going to the same parts of the world. > > A possible shared-cache location might be: > \Documents and Settings\All Users\Application Data\SecondLife\cache > > Though I believe special write privileges are needed for programs to > write data into All Users. Students login using the restricted Users > group so they don't have write access to anywhere they want, but > programs storing data in All Users have proper write privileges even > if the logged-in user does not. > > - Dale Mahalko / Scalar Tardis > > > ============================== > Reference: > > http://svn.secondlife.com/trac/linden/browser/trunk/indra/newview/llappviewer.cpp > > 2626 #if LL_WINDOWS || LL_DARWIN > 2627 // NOTE: (Nyx) as of 1.21, cache for mac is moving to > /library/caches/SecondLife from > 2628 // /library/application support/SecondLife/cache This > should clear/delete the old dir. > 2629 > 2630 // As of 1.23 the Windows cache moved from > 2631 // C:\Documents and Settings\James\Application > Support\SecondLife\cache > 2632 // to > 2633 // C:\Documents and Settings\James\Local > Settings\Application Support\SecondLife > 2634 // > 2635 // The Windows Vista equivalent is from > 2636 // C:\Users\James\AppData\Roaming\SecondLife\cache > 2637 // to > 2638 // C:\Users\James\AppData\Local\SecondLife > 2639 // > 2640 // Note the absence of \cache on the second path. James. > 2641 > 2642 // Only do this once per fresh install of this version. > 2643 if (gSavedSettings.getBOOL("MigrateCacheDirectory")) > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > From dmahalko at gmail.com Thu Apr 16 15:29:15 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Thu, 16 Apr 2009 17:29:15 -0500 Subject: [sldev] 1.21 change makes SL work better for enterprises In-Reply-To: <49E7ABFC.6030408@Gmail.com> References: <49E7ABFC.6030408@Gmail.com> Message-ID: Whoops, gmail locked up on me, and then this got posted twice before I was done. The comments in the source say the change occurs at 1.23, rather than 1.21 The problem with a totally custom centralized cache config like you mention is the fact that it is custom. It would only work for my users rather than being available to all business and education users of roaming profiles and the Second Life viewer. While I suppose I could hack up the client to do this only for me, the likelihood of anyone else benefitting from the same network and client performace gains is close to zero. Roaming is such an arcane issue as it is, that I don't expect most administrators to know they should implement this themselves manually.. A home user would never notice or care if the cache went into All Users/Application Data, so centralized cross-user caching could apply to home users without issue. - Dale Mahalko / Scalar Tardis On Thu, Apr 16, 2009 at 5:06 PM, Tigro Spottystripes wrote: > what prevents you from manually configuring and/or orienting the other > users to do so, the cache to use a folder where network usage, write > permissions and any other concerns are dealt with? > From kf6kjg at gmail.com Thu Apr 16 15:32:54 2009 From: kf6kjg at gmail.com (Ricky) Date: Thu, 16 Apr 2009 15:32:54 -0700 Subject: [sldev] Writing a FindNDOF.cmake In-Reply-To: <49E78199.1050709@lindenlab.com> References: <49E78199.1050709@lindenlab.com> Message-ID: <3bb9647e0904161532p3cd0b9d7o848702e3347ab230@mail.gmail.com> ummm... I thought I had already done this. But I did it a while ago. Here's the JIRA entry: https://jira.secondlife.com/browse/VWR-10579 I also commented on VWR-12838. Ricky Cron Stardust On Thu, Apr 16, 2009 at 12:06 PM, Rob Lanphier wrote: > Hi folks, > > Work on the easybuild branch continues apace. Here's a recent commit > for NDOF (support library for the 3DConnexion Space Navigator) which > makes Linux 64-bit support less painful. Anyone care to write the > missing FindNDOF referred to in the patch below? > > Rob > -------- Original Message -------- > Subject: [sldev-commits] r2122 - projects/2009/easybuild/indra/cmake > Date: Thu, 16 Apr 2009 13:25:08 -0500 (CDT) > From: king.broadfoot at svn.secondlife.com > Reply-To: noreply at lindenlab.com > To: sldev-commits at lists.secondlife.com > > > > Author: king.broadfoot > Date: 2009-04-16 13:25:08 -0500 (Thu, 16 Apr 2009) > New Revision: 2122 > > Modified: > projects/2009/easybuild/indra/cmake/NDOF.cmake > Trac: http://svn.secondlife.com/trac/linden/changeset/2122 > Log: > Do not request prebuilt ndofdev in STANDALONE mode > > This disables NDOF support on linux64, but allows the build to complete. > Support can be re-enabled when a proper FindNDOF module is written. > > Modified: projects/2009/easybuild/indra/cmake/NDOF.cmake > =================================================================== > --- projects/2009/easybuild/indra/cmake/NDOF.cmake 2009-04-16 17:35:31 > UTC (rev 2121) > +++ projects/2009/easybuild/indra/cmake/NDOF.cmake 2009-04-16 18:25:08 > UTC (rev 2122) > @@ -1,7 +1,16 @@ > # -*- cmake -*- > include(Prebuilt) > > -use_prebuilt_binary(ndofdev) > +if (STANDALONE) > + # No ndofdev is available for linux64. > + if(LINUX AND "${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64") > + message(STATUS "Building without N-DoF joystick support") > + return() > + endif(LINUX AND "${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64") > + # TODO: include(FindNDOF) > +else (STANDALONE) > + use_prebuilt_binary(ndofdev) > +endif (STANDALONE) > > if (WINDOWS OR DARWIN OR LINUX) > add_definitions(-DLIB_NDOF=1) > > _______________________________________________ > Click here to unsubscribe or manage your list subscription: > https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev-commits > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090416/c46f87d8/attachment.htm From khyota at redhyena.net Thu Apr 16 17:10:00 2009 From: khyota at redhyena.net (Khyota) Date: Thu, 16 Apr 2009 20:10:00 -0400 Subject: [sldev] Terrible performance in http-texture Message-ID: <200904162010.00442.khyota@redhyena.net> Just finished compiling http-texture on linux x86_64 with my usual O2 optimization but the performance is about 75% worse then trunk, running make with VERBOSE=1 does reveal -O2 was passed to gcc. Also when opening fast timers to check for bottlenecks all readings disapear after a few seconds leaving the window empty so thats broken too. Heres a screenshot http://imagebin.org/45829 has anyone else noticed this? From josh at lindenlab.com Thu Apr 16 17:19:33 2009 From: josh at lindenlab.com (Joshua Bell) Date: Thu, 16 Apr 2009 17:19:33 -0700 Subject: [sldev] 1.21 change makes SL work better for enterprises In-Reply-To: References: Message-ID: <49E7CB15.9050303@lindenlab.com> Dale Mahalko wrote: > > A possible shared-cache location might be: > \Documents and Settings\All Users\Application Data\SecondLife\cache Hrm, I sense security/privacy issues: * Do we pull down script sources into the local cache? If so, the next user who comes along can read your script source. * If two of us are sharing a computer and we both have read/write access to the same cache, I can inspect the cache to find out what you've been looking at (ow, my eyes!) I'll admit these are semi-obvious cases of "don't do such-and-such on public/shared computers!" and on everyone's-running-as-admin hosts we're already in that state. > Though I believe special write privileges are needed for programs to > write data into All Users. Students login using the restricted Users > group so they don't have write access to anywhere they want, but > programs storing data in All Users have proper write privileges even > if the logged-in user does not. From schlenk at uni-oldenburg.de Thu Apr 16 18:06:21 2009 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Fri, 17 Apr 2009 03:06:21 +0200 Subject: [sldev] A few call stacks from crash reports In-Reply-To: <49E66329.5090906@lindenlab.com> References: <49E66329.5090906@lindenlab.com> Message-ID: <768DEA43-92E8-4A18-9894-DEBEC37687E6@uni-oldenburg.de> Am 16.04.2009 um 00:43 schrieb Rob Lanphier: > We'd really love some help getting these crashing bugs figured out. > We'd like to be able to offer this version of the viewer in a much > more > prominent place, but obviously can't feel good about doing that > until we > get to the bottom of the crashing issues (at a minimum). > > Call stack #3: > [0] LLTextureFetchWorker::callbackDecoded [secondlife-bin > lltexturefetch.cpp:1302] > [1] LLTextureFetchWorker::DecodeResponder::completed [secondlife-bin > lltexturefetch.cpp:123] > [2] LLImageDecodeThread::ImageRequest::finishRequest [secondlife-bin > llimageworker.cpp:154] > [3] LLQueuedThread::processNextRequest [secondlife-bin > llqueuedthread.cpp:430] > [4] LLQueuedThread::run [secondlife-bin llqueuedthread.cpp:485] > [5] LLThread::staticRun [secondlife-bin llthread.cpp:78] > [6] apr_threadattr_guardsize_set [secondlife-bin unknownfile:0] > [7] Unknown [msvcr80.dll ] > Okay, some comments on this one. I see it with the OS X viewer too, just built from SVN. It crashes because mFormattedImage is a pretty NULL pointer inside CallbackDecoded(), but its alive and healthy outside in stack levels 1 and 2 and 3 inside the request. The refcount is 1, which looks wrong from my cursory inspection. Not sure how it got there, but from what i can see the mFormattedImage pointer gets NULL'ed. I guess its a race condition between the Main thread that NULLs the mFormattedImage pointer of the request and the callback that accesses it for the discard level. This might fix it, but guess its not enough because there is still a race between the notNull() check and the call: Index: indra/newview/lltexturefetch.cpp =================================================================== --- indra/newview/lltexturefetch.cpp (revision 2123) +++ indra/newview/lltexturefetch.cpp (working copy) @@ -111,6 +111,7 @@ DecodeResponder(LLTextureFetch* fetcher, const LLUUID& id, LLTextureFetchWorker* worker) : mFetcher(fetcher), mID(id), mWorker(worker) { + } virtual void completed(bool success, LLImageRaw* raw, LLImageRaw* aux) { @@ -1299,12 +1300,18 @@ if ((mRawImage.notNull() && mRawImage->getDataSize() > 0) && (!mNeedsAux || (mAuxImage.notNull() && mAuxImage->getDataSize() > 0))) { - mDecodedDiscard = mFormattedImage->getDiscardLevel(); + if (mFormattedImage.notNull()) { + mDecodedDiscard = mFormattedImage->getDiscardLevel(); + } // llinfos << mID << " : DECODE FINISHED. DISCARD: " << mDecodedDiscard << llendl; } else { - llwarns << "DECODE FAILED: " << mID << " Discard: " << (S32)mFormattedImage->getDiscardLevel() << llendl; + if (mFormattedImage.notNull()) { + llwarns << "DECODE FAILED: " << mID << " Discard: " << (S32)mFormattedImage->getDiscardLevel() << llendl; + } else { + llwarns << "DECODE FAILED: " << mID << llendl; + } removeFromCache(); } // llinfos << mID << " : DECODE COMPLETE " << llendl; From merov at lindenlab.com Thu Apr 16 18:10:14 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 16 Apr 2009 18:10:14 -0700 Subject: [sldev] Terrible performance in http-texture In-Reply-To: <200904162010.00442.khyota@redhyena.net> References: <200904162010.00442.khyota@redhyena.net> Message-ID: <9227D3B8-F781-466A-B2C9-FE69F5D2289D@lindenlab.com> Yahuza! I haven't noticed that bad of a perf drop *unless* I turn the shadow rendering on in which case it is, indeed, unbearable. I usually don't turn on the fast timer so I haven't noticed the disappearance though I noticed when using it (on a trunk build) that one can easily get spurious clicks captured on the hierarchical display (and then display closed) especially when the perf are bad. Cheers, - Merov On Apr 16, 2009, at 5:10 PM, Khyota wrote: > Just finished compiling http-texture on linux x86_64 with my usual O2 > optimization but the performance is about 75% worse then trunk, > running make > with VERBOSE=1 does reveal -O2 was passed to gcc. Also when opening > fast > timers to check for bottlenecks all readings disapear after a few > seconds > leaving the window empty so thats broken too. > > Heres a screenshot > http://imagebin.org/45829 > > has anyone else noticed this? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From merov at lindenlab.com Thu Apr 16 18:16:20 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 16 Apr 2009 18:16:20 -0700 Subject: [sldev] A few call stacks from crash reports In-Reply-To: <768DEA43-92E8-4A18-9894-DEBEC37687E6@uni-oldenburg.de> References: <49E66329.5090906@lindenlab.com> <768DEA43-92E8-4A18-9894-DEBEC37687E6@uni-oldenburg.de> Message-ID: <782D6DFC-3B72-4DCD-934F-9B97D1EF3176@lindenlab.com> Hi Michael, Yes, this is also what I found and my patch (attached to http://jira.secondlife.com/browse/VWR-12775) is similar to yours. I didn't apply it but I'm trying to determine the condition of the race condition, as, according to the dev who put that code together, that is *not* supposed to happen. Doing research today, I think that the problem has been magnified by the newly introduced "caching of small texture" that Robin and myself have been working on last week: all the textures that trigger the bug are small (<= 600 bytes). Still digging though I think I'll have good news tonight or tomorrow :) Cheers, - Merov On Apr 16, 2009, at 6:06 PM, Michael Schlenker wrote: > > Am 16.04.2009 um 00:43 schrieb Rob Lanphier: >> We'd really love some help getting these crashing bugs figured out. >> We'd like to be able to offer this version of the viewer in a much >> more >> prominent place, but obviously can't feel good about doing that >> until we >> get to the bottom of the crashing issues (at a minimum). >> >> Call stack #3: >> [0] LLTextureFetchWorker::callbackDecoded [secondlife-bin >> lltexturefetch.cpp:1302] >> [1] LLTextureFetchWorker::DecodeResponder::completed [secondlife-bin >> lltexturefetch.cpp:123] >> [2] LLImageDecodeThread::ImageRequest::finishRequest [secondlife-bin >> llimageworker.cpp:154] >> [3] LLQueuedThread::processNextRequest [secondlife-bin >> llqueuedthread.cpp:430] >> [4] LLQueuedThread::run [secondlife-bin llqueuedthread.cpp:485] >> [5] LLThread::staticRun [secondlife-bin llthread.cpp:78] >> [6] apr_threadattr_guardsize_set [secondlife-bin unknownfile:0] >> [7] Unknown [msvcr80.dll ] >> > Okay, some comments on this one. > > I see it with the OS X viewer too, just built from SVN. > > It crashes because mFormattedImage is a pretty NULL pointer inside > CallbackDecoded(), but its alive and healthy outside in stack levels 1 > and 2 and 3 inside the request. The refcount is 1, which looks wrong > from my cursory inspection. > > Not sure how it got there, but from what i can see the mFormattedImage > pointer gets NULL'ed. > > I guess its a race condition between the Main thread that NULLs the > mFormattedImage pointer of the request and the callback that accesses > it for the discard level. > > This might fix it, but guess its not enough because there is still a > race between the notNull() check and the call: > > Index: indra/newview/lltexturefetch.cpp > =================================================================== > --- indra/newview/lltexturefetch.cpp (revision 2123) > +++ indra/newview/lltexturefetch.cpp (working copy) > @@ -111,6 +111,7 @@ > DecodeResponder(LLTextureFetch* fetcher, const LLUUID& id, > LLTextureFetchWorker* worker) > : mFetcher(fetcher), mID(id), mWorker(worker) > { > + > } > virtual void completed(bool success, LLImageRaw* raw, LLImageRaw* > aux) > { > @@ -1299,12 +1300,18 @@ > if ((mRawImage.notNull() && mRawImage->getDataSize() > 0) && > (!mNeedsAux || (mAuxImage.notNull() && mAuxImage->getDataSize() > > 0))) > { > - mDecodedDiscard = mFormattedImage->getDiscardLevel(); > + if (mFormattedImage.notNull()) { > + mDecodedDiscard = mFormattedImage->getDiscardLevel(); > + } > // llinfos << mID << " : DECODE FINISHED. DISCARD: " << > mDecodedDiscard << llendl; > } > else > { > - llwarns << "DECODE FAILED: " << mID << " Discard: " << > (S32)mFormattedImage->getDiscardLevel() << llendl; > + if (mFormattedImage.notNull()) { > + llwarns << "DECODE FAILED: " << mID << " Discard: " << > (S32)mFormattedImage->getDiscardLevel() << llendl; > + } else { > + llwarns << "DECODE FAILED: " << mID << llendl; > + } > removeFromCache(); > } > // llinfos << mID << " : DECODE COMPLETE " << llendl; > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From khyota at redhyena.net Thu Apr 16 19:27:14 2009 From: khyota at redhyena.net (Khyota) Date: Thu, 16 Apr 2009 22:27:14 -0400 Subject: [sldev] Terrible performance in http-texture In-Reply-To: <9227D3B8-F781-466A-B2C9-FE69F5D2289D@lindenlab.com> References: <200904162010.00442.khyota@redhyena.net> <9227D3B8-F781-466A-B2C9-FE69F5D2289D@lindenlab.com> Message-ID: <200904162227.14340.khyota@redhyena.net> I feel silly, an earlier session of the viewer crashed so i had a crash report window hidden that diddnt show up until i went to reboot, so i was really running 2 instances of the viewer causing the bad performance. Fast timer is still broken though. :( but thanks Philippe On Thursday 16 April 2009 9:10:14 Philippe Bossut (Merov Linden) wrote: > Yahuza! I haven't noticed that bad of a perf drop *unless* I turn the > shadow rendering on in which case it is, indeed, unbearable. > > I usually don't turn on the fast timer so I haven't noticed the > disappearance though I noticed when using it (on a trunk build) that > one can easily get spurious clicks captured on the hierarchical > display (and then display closed) especially when the perf are bad. > > Cheers, > - Merov From ghost at ghostmenjou.com Fri Apr 17 01:12:18 2009 From: ghost at ghostmenjou.com (Ghost Menjou) Date: Fri, 17 Apr 2009 10:12:18 +0200 Subject: [sldev] fresh shadow draft binaries Message-ID: <000701c9bf34$3c26a520$b473ef60$@com> The builds of April crash for me, I have yet to try out earlier builds. The thing is, I am running a newer system configuration that might give problems(And Well ATI and SecondLife, bleh.) Core i7(Which SecondLife reports as a P3 all the time) and a ATI 4870 x2. We shall see what the next builds will bring. -----Oorspronkelijk bericht----- Van: sldev-bounces at lists.secondlife.com [mailto:sldev-bounces at lists.secondlife.com] Namens Opensource Obscure Verzonden: woensdag 15 april 2009 14:26 Aan: SignpostMarv Martin CC: SLDev Onderwerp: Re: [sldev] fresh shadow draft binaries On Wed, 15 Apr 2009 12:46:34 +0100, SignpostMarv Martin wrote: > Any fresh shadow draft builds floating about ? the http-texture binaries linked from the open source portal page were built 1-2 days ago: https://wiki.secondlife.com/wiki/Category:Open_Source_Portal you can also look for emails with subject "Successful Build for http-texture" in sldev-commits archives https://lists.secondlife.com/pipermail/sldev-commits/2009-April if you're on Linux, here are two unofficial March builds from render-pipeline branch (could disappear soon): http://drop.io/linuxshadows If you don't mind to compile, I'd suggest to build yourself a viewer from render-pipeline branch, as unfortunately, new "projected texture" features weren't committed to the http-texture branch. And those features kick asses (custom textures that cast shadows from objects - not from sun/moon only) http://www.youtube.com/watch?v=18zR_XXNdLY http://www.youtube.com/watch?v=bqiOsAE3FYI http://www.youtube.com/watch?v=R_CQPRcHZGU http://www.youtube.com/watch?v=c5VCcO7NFpo bye Opensource Obscure -- twitter.com/oobscure - friendfeed.com/oobscure _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges From jan.ciger at gmail.com Fri Apr 17 01:39:12 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 17 Apr 2009 10:39:12 +0200 Subject: [sldev] Writing a FindNDOF.cmake In-Reply-To: <49E78199.1050709@lindenlab.com> References: <49E78199.1050709@lindenlab.com> Message-ID: <49E84030.6000405@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rob Lanphier wrote: > Hi folks, > > Work on the easybuild branch continues apace. Here's a recent commit > for NDOF (support library for the 3DConnexion Space Navigator) which > makes Linux 64-bit support less painful. Anyone care to write the > missing FindNDOF referred to in the patch below? Hi, Just for info - is there a problem with NDOF on 64bits? I didn't test it there (do not have 64bit system around), but it should work. Let me know if there is a problem with it. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJ6EArn11XseNj94gRAsFkAKCcjfGd/JS1+hoOfNoCX8MG/3azRwCghQQA 9xs+HLH5zl5xR9HSNBbfa/o= =YwbA -----END PGP SIGNATURE----- From robin.cornelius at gmail.com Fri Apr 17 01:53:15 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri, 17 Apr 2009 09:53:15 +0100 Subject: [sldev] Writing a FindNDOF.cmake In-Reply-To: <49E84030.6000405@gmail.com> References: <49E78199.1050709@lindenlab.com> <49E84030.6000405@gmail.com> Message-ID: On Fri, Apr 17, 2009 at 9:39 AM, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Just for info - is there a problem with NDOF on 64bits? I didn't test it > there (do not have 64bit system around), but it should work. > No the only problem is that LL do not supply a prebuilt binary for 64bit, so its necessary for a (64 bit) builder to compile it themselves then copy to an appropriate location such as /usr/local/lib and /usr/local/include/ then with the FindNDOF.cmake all is well in the world. Robin From robin.cornelius at gmail.com Fri Apr 17 02:04:58 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Fri, 17 Apr 2009 10:04:58 +0100 Subject: [sldev] easybuild branch Message-ID: As Rob mentioned yesterday at his office hour, merging easybuild into http-texture ASAP is probably a good idea so it gets exposure and we can chase out any bug/ issues that have appeared with the changes to the build, I agree if its left in its current branch it will get next to no testing and when it does get merged some of us may then be upset as its caused build breakage to our way of doing things. I've started some testing and hit a few snags already. 1) Firstly i was under the impression that develop.py was going/being replaced and/or that the build would be started by invoking cmake directly? I'm personally against invoking cmake directly for people who *just* want to build as although the number of parameters passed to cmake have been reduced by various autodetection its still a messy process. (but i am 100% for invoking it directly with fine grained control when generating packages for linux etc) For standalone it looks like cmake -DSTANDALONE:BOOL=true and thats not the end of it, that makes a mess in the indra/ folder that is then difficult to clean, its normal (and what develop.py does) to create a working folder for the cmake build. Then when you want to do a clean you can kill that working folder, cmake does not provide a make clean target, so this is the accepted way of building. without develop.py this would end up with a command line like :- mkdir build ; cd build ; cmake -DSTANDALONE:BOOL=true .. (with or without standalone) thats not so friendly. So i'm not really sure if this is just a rumor or what is actually happening in this area. The information has come from inside LL so it would be good to get clarification on this issue and what the goal is for the initial invoking process. 2) There is a subtle change to the develop.py on that branch, it passes the standalone parameter to cmake for both the build and configure stages (but with the approprate ON/OFF flag set). What this means in practice (which i panicked over) is that ./develop.py --standalone ./develop.py build will no longer work, the build stage will start to download prebuilt packages., because the build call to develop.py has an implicit STANDALONE:BOOL=FALSE, What this needs to be is now :- ./develop.py --standalone ./develop.py --standalone build 3) Testing on windows today has failed with missing cursors ( Cannot find source file "arrow.cur".) at the configure stage. Now i'm not sure at this point if this is a work in progress and may be today some more commits will finish this off, but i was under the impression that artwork-common would now be downloaded and installed by the process. But i also now notice that artwork-common is not in the install.xml in easybuild, so i guess this is something gone ahead in trunk and not ported to the branch that needs it most. 4) Compiler detection and generators Running the default develop.py on my system from a command prompt (no generator specified) with the path/lib/include set up to point at a visual studio 2008 install (eg a Visual studio 2008 command prompt) resulted in the cmake stage finding and testing cl and friends from VC 2008, then generating a project for Visual studio 2003. Basically the "Check for working CXX compiler" will first test the compiler it finds in the PATH but seems to also find VS2003 professional edition (registry search?) if one is not in the path. So i guess it searches PATh then registry. But testing any old compiler in the path or registry is not a great idea when the user has specified a specific generator on the command line. The compiler being tested is then NOT the one that will be used for the build and we already know 2005 express can manage to fail to install correctly and not have windows SDK available as default, so in this case my 2003 (not supported for secondlife build) would be found and pass the cmake check but then when i tried to compile in visual studio 2005 it would fail with missing user32.lib and friends. 5) VSTool.exe and develop.py and express The combination still fails in a big heap, we know that VSTool.exe itself is of no use to express builders but the current develop.py still does not have the express edition patches so will not detect an express and fails in an ungraceful and confusing manor to a builder, please see http://jira.secondlife.com/browse/VWR-11138 for a solution I'll carry on with some further testing and report back any other issues Regards Robin From jan.ciger at gmail.com Fri Apr 17 03:09:35 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 17 Apr 2009 12:09:35 +0200 Subject: [sldev] Writing a FindNDOF.cmake In-Reply-To: References: <49E78199.1050709@lindenlab.com> <49E84030.6000405@gmail.com> Message-ID: <49E8555F.4000109@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robin Cornelius wrote: > No the only problem is that LL do not supply a prebuilt binary for > 64bit, so its necessary for a (64 bit) builder to compile it > themselves then copy to an appropriate location such as /usr/local/lib > and /usr/local/include/ then with the FindNDOF.cmake all is well in > the world. > > Robin Aha, OK. I thought that the binary is not supplied, because the library does not work or does not compile. BTW, can we get a better joystick support? E.g. moving forward and turning (roll/yaw) at the same time should be possible. I was trying to use some more advanced hardware with SL (full body tracking) and it is pretty much pointless until the joystick code is somewhat fixed. Right now one has to stop moving forward before you can turn, due to the flawed prioritisation of the controls. This is seriously annoying if one tries to fly or steer a vehicle using a joystick. Once this is done, I can add VRPN support (http://www.cs.unc.edu/Research/vrpn/) to NDOF as well. That would bring e.g. Wiimote support, various trackers (Polhemus, Ascension), original SpaceBall and what not, without having to support any of these explicitly in SL. This library is well known among VR researchers. The second bug I have noticed in the recent 1.22.x viewers is flickering of local lights when in FlyCam mode. It doesn't happen when camera is moved by mouse or the local lights are off, only in FlyCam with local lights on. Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJ6FVZn11XseNj94gRAtQjAJ4y5jXRKGAPHnyfi18bSJ5dYPA6nwCcD8Qc kT912PHn5FjuHL9c0fZKDts= =n/Zg -----END PGP SIGNATURE----- From maggie at matrisync.com Fri Apr 17 06:41:29 2009 From: maggie at matrisync.com (Maggie Leber (sl: Maggie Darwin) ) Date: Fri, 17 Apr 2009 09:41:29 -0400 Subject: [sldev] SLDev Digest, Vol 28, Issue 29 In-Reply-To: References: Message-ID: > Date: Thu, 16 Apr 2009 18:16:20 -0700 > From: "Philippe Bossut (Merov Linden)" > > I didn't apply it but I'm trying to determine the condition of the race condition... Maggie cues song: http://www.youtube.com/watch?v=HlN0UcshIFg From tofu.linden at lindenlab.com Fri Apr 17 08:15:11 2009 From: tofu.linden at lindenlab.com (Tofu Linden) Date: Fri, 17 Apr 2009 08:15:11 -0700 Subject: [sldev] Writing a FindNDOF.cmake In-Reply-To: <49E8555F.4000109@gmail.com> References: <49E78199.1050709@lindenlab.com> <49E84030.6000405@gmail.com> <49E8555F.4000109@gmail.com> Message-ID: <49E89CFF.1080406@lindenlab.com> Jan Ciger wrote: > BTW, can we get a better joystick support? Yes - lots of fixes in 1.23, mostly thanks to Aimee Triscothick. From moriz.gupte at gmail.com Fri Apr 17 09:27:33 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Fri, 17 Apr 2009 10:27:33 -0600 Subject: [sldev] Writing a FindNDOF.cmake In-Reply-To: <49E89CFF.1080406@lindenlab.com> References: <49E78199.1050709@lindenlab.com> <49E84030.6000405@gmail.com> <49E8555F.4000109@gmail.com> <49E89CFF.1080406@lindenlab.com> Message-ID: Thanks a lot guys, I have waited almost one year to see those patches integrated in the standard client. local IT from a federal institution had prevented me from installing patched clients (because of FISMA regulations) and I had to pull off any plans that involved using the space navigator. Thanks Aimee. R On Fri, Apr 17, 2009 at 9:15 AM, Tofu Linden wrote: > Jan Ciger wrote: > > BTW, can we get a better joystick support? > > Yes - lots of fixes in 1.23, mostly thanks to Aimee Triscothick. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org ----- The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge- Stephen Hawking and many others who found light through the cracks of knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090417/f861c7a2/attachment.htm From jan.ciger at gmail.com Fri Apr 17 09:32:36 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 17 Apr 2009 18:32:36 +0200 Subject: [sldev] Writing a FindNDOF.cmake In-Reply-To: <49E89CFF.1080406@lindenlab.com> References: <49E78199.1050709@lindenlab.com> <49E84030.6000405@gmail.com> <49E8555F.4000109@gmail.com> <49E89CFF.1080406@lindenlab.com> Message-ID: <49E8AF24.3030009@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tofu Linden wrote: > Jan Ciger wrote: >> BTW, can we get a better joystick support? > > Yes - lots of fixes in 1.23, mostly thanks to Aimee Triscothick. Thanks a bunch! That will save quite a bit of work for me. Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJ6K8in11XseNj94gRAl0uAJ9s6z16Q/jtAlU9nHgSGOVbYlHnqgCffU13 NtFe4SPxubpMLybJ+jVWy20= =G/KD -----END PGP SIGNATURE----- From robla at lindenlab.com Fri Apr 17 14:43:49 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 17 Apr 2009 14:43:49 -0700 Subject: [sldev] Checkin process into http-texture branch Message-ID: <49E8F815.5000009@lindenlab.com> Hi folks, There's a lot of moving parts for releasing the first viewer off of the http-texture branch (not the least of which being a name...stay tuned for that). One thing we're pretty certain of: we want to have our first release by the end of this quarter (June 30), and preferably well in advance of that. So, it'll be important to get through the release cycle for this release as quickly as possible. However, we want to make sure you all are part of the process and have an opportunity to get what you (as a developer willing to shepherd a feature through the review process) think is important included, and that you know what you're signing up for. We want to move toward time-based releases, and keep the duration of each release cycle something best measured in weeks. It's probably premature to get into more detail than that without getting the first release under our belt, but if people have opinions about this subject, it can't hurt to share them. Here's the rough contour of what the release cycle will look like: * Phase I : Merge window - we'll provide the general guidelines for the release (e.g. stating what improvements we'd like to focus on). More on the merge window in a bit. * Phase II: Stabilization phase - bugfix phase. No new features, no big disruptive changes. Only fixes necessary to get the already completed features into shipable state * Phase III: RC cycle - very short cycle at the end of the stabilization phase. Only fixes for showstoppers, and only shallow bugfixes (no gutting/replacing subsystems...just the least disruptive change that fixes the problem, saving the "real" fix for the next cycle) For the merge window: Specific feature/patch proposals should be discussed on sldev@ (let at least one full business day pass without comment before considering silence assent). All checkins should have a corresponding JIRA task with the proposed patch, either attached in JIRA, or a pointer to a specific patchset in a public source repository somewhere (e.g. Bitbucket). The comments on the JIRA task should have a comment from another committer (not necessarily a Linden) who has thoroughly reviewed the patch, and is willing to stake their credibility as a committer that the patch should be safe for checkin. You'll need to take responsibility for the code you commit, especially if you commit a build breaker. Failure to do so may lead to you losing commit access, depending on the degree of carelessness exhibited. Reviewers will also be subject to scrutiny. More on what this means for this first release cycle in a separate mail. Rob From robla at lindenlab.com Fri Apr 17 15:38:33 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 17 Apr 2009 15:38:33 -0700 Subject: [sldev] Merge window for our first release Message-ID: <49E904E9.8010009@lindenlab.com> Hi all, Per my previous email, we want to get something out absolutely no later than June 30, so we'll want to close the merge window (Phase I in my previous mail) much sooner than that. The marquee feature for this first release is the new map tile work, with HTTP textures. Other enhancements should be minor, and should have mainstream appeal. Since we've already got the features that we want, perhaps the only reason why the merge window isn't closed yet is because we're only now talking about the merge window as a concept. Given our constraints, we'd like to shoot for May 1 as the end of the merge window for this cycle. So, are there other patches in JIRA that seem worthy of making it in before the first merge window, and are there volunteers to shepherd those patches through? Aimee and I have been talking about VWR-12748 (Minimap zoom level) over on irc.efnet.org #opensl, which is a possibility. Given some of the VFS rework that's gone on in the 1.26 server (which is shared by the viewer), there's a little bit of mumbling about possibly pulling that in (seems like a big stability improvement on the simulator side from our initial observations). I imagine we'll need to get some of the 1.23 changes in. It's hard to say yet whether easybuild will make it in. Are there others that we should get in there now? Rob From robin.cornelius at gmail.com Sat Apr 18 08:01:44 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat, 18 Apr 2009 16:01:44 +0100 Subject: [sldev] [http-texture PATCH] VWR-12479 Message-ID: <49E9EB58.4070300@gmail.com> Hey everyone, As i would very much like to see all build busting, including 64 bit busting, patched out of http-texture, looking for the nod to commit the one liner as commented by soft, in VWR-12479, to http-texture. Or else can some one merge across from the internal branch with it fixed. TIA Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090418/cb3dd10d/attachment.pgp From soft at lindenlab.com Sat Apr 18 08:06:55 2009 From: soft at lindenlab.com (Soft) Date: Sat, 18 Apr 2009 10:06:55 -0500 Subject: [sldev] [http-texture PATCH] VWR-12479 In-Reply-To: <49E9EB58.4070300@gmail.com> References: <49E9EB58.4070300@gmail.com> Message-ID: On Sat, Apr 18, 2009 at 10:01 AM, Robin Cornelius wrote: > Hey everyone, > > As i would very much like to see all build busting, including 64 bit > busting, patched out of http-texture, looking for the nod to commit the > one liner as commented by soft, in VWR-12479, to http-texture. Or else > can some one merge across from the internal branch with it fixed. Saw the discussion on the JIRA - already done. From soft at lindenlab.com Sat Apr 18 08:09:36 2009 From: soft at lindenlab.com (Soft) Date: Sat, 18 Apr 2009 10:09:36 -0500 Subject: [sldev] 64-bit & stand-alone Linux users all in http-texture? Message-ID: Are the 64-bit Linux users all using http-texture? To date, I've been pushing 64-bit and stand-alone build fixes to maint-viewer. If everyone's on board with the http-texture (and future similar) branches, we should make that the home for these. From robin.cornelius at gmail.com Sat Apr 18 08:28:39 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat, 18 Apr 2009 16:28:39 +0100 Subject: [sldev] 64-bit & stand-alone Linux users all in http-texture? In-Reply-To: References: Message-ID: <49E9F1A7.7020208@gmail.com> Soft wrote: > Are the 64-bit Linux users all using http-texture? To date, I've been > pushing 64-bit and stand-alone build fixes to maint-viewer. If > everyone's on board with the http-texture (and future similar) > branches, we should make that the home for these. > _______________________________________________ +1 The people most likely to be helping out on these branches are also many of the ones who want standalone and building on 64 boxes to build out of the box. As this is the first of the open source branches then this makes a lot of sense, and when anyone is testing features and fixes from other branches, they will always know where to check for a build failure fix, and its likely that more community contributions will directly come if there are any 64bit build busters as there are a good few of us testing with 64bit systems (and we tend to be the noisy ones too ;-p ) As I started on the discussion of the easybuild branch, i'm quite keen for Robs idea there to merge that in ASAP to http-texture and to get other build fixes esp the windows ones in there to make building easier for everyone and lower the bar for first time compiling. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090418/e58a9b1e/attachment.pgp From feilen1000 at gmail.com Sat Apr 18 10:42:22 2009 From: feilen1000 at gmail.com (Feilen) Date: Sat, 18 Apr 2009 12:42:22 -0500 Subject: [sldev] libpurple implementation? Message-ID: <49EA10FE.3020200@gmail.com> I've never actually used this system before, but I had an idea- Wouldn't it be possible to implement libpurple, a lib for instant-messenger clients, into the SL im system to allow for ingame IMing? It would make it more convenient than constantly switching out whenever you're messaged. From me at signpostmarv.name Sat Apr 18 22:47:45 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Sun, 19 Apr 2009 06:47:45 +0100 Subject: [sldev] libpurple implementation? In-Reply-To: <49EA10FE.3020200@gmail.com> References: <49EA10FE.3020200@gmail.com> Message-ID: <49EABB01.4050609@signpostmarv.name> When this topic has been brought up on the OpenSim mailing list/IRC, the basic gist of the replies was "looks useful, but has licensing issues". Don't know if the same licensing issues apply to LL's usage as OpenSim usage. ~ Marv. Feilen wrote: > I've never actually used this system before, but I had an idea- > > Wouldn't it be possible to implement libpurple, a lib for > instant-messenger clients, into the SL im system to allow for ingame IMing? > It would make it more convenient than constantly switching out whenever > you're messaged. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090419/3176e07a/attachment.bin From tigrospottystripes at gmail.com Sun Apr 19 00:49:31 2009 From: tigrospottystripes at gmail.com (Tigro Spottystripes) Date: Sun, 19 Apr 2009 04:49:31 -0300 Subject: [sldev] back to the lab again? Message-ID: <49EAD78B.4020701@Gmail.com> Reading somthing on the forum inspired write this message, what are your opinions (both LL employees and community developers) about starting over avoiding mistakes made with the first attempt of making SL , many that got discovered only too late and now piled up and got to be mantained, and go more carefully this time, taking input from users from the start so there is less chances that feature suggestions conflict with intended behavior and "undocumented features", already from the start only using code that won't have licensing concerns regarding opensource etc, not putting any effort in making this new SL/compatible with anything in the first incarnation, no content to be broken 'cause there is no content made yet, no bug exploits that gotta be supported as if they were features etc. Basicly, what are your opinions regarding getting a clean slate and this time doing things with much more planning, community input and testing etc? ps:this is about both the client and server side of things pps:From all the people in this list I'm probably one of the ones that can contribute the least regarding actual coding, technichal info etc, but I felt this was somthing that could be good to be discussed among the people who fit better the intended target audience of this list From schlenk at uni-oldenburg.de Sun Apr 19 03:26:18 2009 From: schlenk at uni-oldenburg.de (Michael Schlenker) Date: Sun, 19 Apr 2009 12:26:18 +0200 Subject: [sldev] back to the lab again? In-Reply-To: <49EAD78B.4020701@Gmail.com> References: <49EAD78B.4020701@Gmail.com> Message-ID: <49EAFC4A.8020503@uni-oldenburg.de> Tigro Spottystripes schrieb: > Reading somthing on the forum inspired write this message, what are your > opinions (both LL employees and community developers) about starting > over avoiding mistakes made with the first attempt of making SL , many > that got discovered only too late and now piled up and got to be > mantained, and go more carefully this time, taking input from users from > the start so there is less chances that feature suggestions conflict > with intended behavior and "undocumented features", already from the > start only using code that won't have licensing concerns regarding > opensource etc, not putting any effort in making this new SL/compatible > with anything in the first incarnation, no content to be broken 'cause > there is no content made yet, Here it breaks down. If you kill off all or even most of the current content you could just start a totally different thing. Technically nice, but commercial suicide. > no bug exploits that gotta be supported as > if they were features etc. Basicly, what are your opinions regarding > getting a clean slate and this time doing things with much more > planning, community input and testing etc? Its the same wishful thinking you always find if you have a messy state and need to clean up. Its well discussed, one classic piece about it is for example, http://www.joelonsoftware.com/articles/fog0000000069.html there are others advocating a rewrite, but most people tell you its a not so great idea as it sounds usually. There are a lot of issues, sure, but you nearly always fare better if you improve things step by step instead of doing a full rewrite, especially if you have a big system. Getting a good test harness is usually a big win in such cases as you know you don't break too much stuff while refactoring and improving. You can deal with all the issues incrementally, for example if you see a bug gets feature status either develop it into a full feature and deprecate the old behaviour over the next few versions. Similar things happen all the time, see http-texture branch, internal reorg of servers and queries, etc. etc. Michael From aimee.trescothick at gmail.com Sun Apr 19 04:17:46 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Sun, 19 Apr 2009 12:17:46 +0100 Subject: [sldev] Merge window for our first release References: Message-ID: On 17 Apr 2009, at 23:38, Rob Lanphier wrote: > So, are there other patches in JIRA that seem worthy of making it in > before the first merge window, and are there volunteers to shepherd > those patches through? Aimee and I have been talking about VWR-12748 > (Minimap zoom level) over on irc.efnet.org #opensl, which is a > possibility. Speaking of http://jira.secondlife.com/browse/VWR-12748 I just posted an updated patch (and artwork) to that issue, so it could do with someone re-reviewing it please? The updated patch is just a little tidying up, and makes the picking for hover tips relative to the scaled symbol size. http://jira.secondlife.com/browse/VWR-12696 is a pretty straightforward fix a couple of bugs in the minimap, and may be worth sneaking in at the same time? Aimee. From mike.dickson at hp.com Sun Apr 19 06:32:13 2009 From: mike.dickson at hp.com (Mike Dickson) Date: Sun, 19 Apr 2009 08:32:13 -0500 Subject: [sldev] libpurple implementation? In-Reply-To: <49EABB01.4050609@signpostmarv.name> References: <49EA10FE.3020200@gmail.com> <49EABB01.4050609@signpostmarv.name> Message-ID: <1240147933.2346.2.camel@mdickson-laptop> OpenSIm is BSD licensed while libpurple is GPLv2. Thats likely the reason for the concern. Putting it in the viewer shouldn't be an issue re: licensing though perhaps a Linden should ultimately weigh in on that. Mike On Sun, 2009-04-19 at 05:47 +0000, SignpostMarv Martin wrote: > When this topic has been brought up on the OpenSim mailing list/IRC, the > basic gist of the replies was "looks useful, but has licensing issues". > > Don't know if the same licensing issues apply to LL's usage as OpenSim > usage. > > > ~ Marv. > > Feilen wrote: > > I've never actually used this system before, but I had an idea- > > > > Wouldn't it be possible to implement libpurple, a lib for > > instant-messenger clients, into the SL im system to allow for ingame IMing? > > It would make it more convenient than constantly switching out whenever > > you're messaged. > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting privileges > > > > -- Mike Dickson BladeSystem infrastructure R&D From moriz.gupte at gmail.com Sun Apr 19 07:19:49 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Sun, 19 Apr 2009 08:19:49 -0600 Subject: [sldev] back to the lab again? In-Reply-To: <49EAFC4A.8020503@uni-oldenburg.de> References: <49EAD78B.4020701@Gmail.com> <49EAFC4A.8020503@uni-oldenburg.de> Message-ID: Full rewrite is an arrogant stance that assumes that the space is now clearly understood and specified (all requirements captured, all use cases visited etc...) and now we can build, it is as extreme a view as building on top of known flawed subsystems causing the whole platform to be unscaleable, resistant to evolution and so on. Experienced developers are well aware of this issue. They can only play a balancing act. It's an art. On Sun, Apr 19, 2009 at 4:26 AM, Michael Schlenker wrote: > Tigro Spottystripes schrieb: > > Reading somthing on the forum inspired write this message, what are your > > opinions (both LL employees and community developers) about starting > > over avoiding mistakes made with the first attempt of making SL , many > > that got discovered only too late and now piled up and got to be > > mantained, and go more carefully this time, taking input from users from > > the start so there is less chances that feature suggestions conflict > > with intended behavior and "undocumented features", already from the > > start only using code that won't have licensing concerns regarding > > opensource etc, not putting any effort in making this new SL/compatible > > with anything in the first incarnation, no content to be broken 'cause > > there is no content made yet, > Here it breaks down. If you kill off all or even most of the current > content you could just start a totally different thing. Technically > nice, but commercial suicide. > > > no bug exploits that gotta be supported as > > if they were features etc. Basicly, what are your opinions regarding > > getting a clean slate and this time doing things with much more > > planning, community input and testing etc? > Its the same wishful thinking you always find if you have a messy state > and need to clean up. Its well discussed, one classic piece about it is > for example, > http://www.joelonsoftware.com/articles/fog0000000069.html > there are others advocating a rewrite, but most people tell you its a > not so great idea as it sounds usually. > > There are a lot of issues, sure, but you nearly always fare better if > you improve things step by step instead of doing a full rewrite, > especially if you have a big system. Getting a good test harness is > usually a big win in such cases as you know you don't break too much > stuff while refactoring and improving. > > You can deal with all the issues incrementally, for example if you see a > bug gets feature status either develop it into a full feature and > deprecate the old behaviour over the next few versions. Similar things > happen all the time, see http-texture branch, internal reorg of servers > and queries, etc. etc. > > Michael > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org ----- The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge- Stephen Hawking and many others who found light through the cracks of knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090419/367c7164/attachment.htm From monkowsk at watson.ibm.com Mon Apr 20 08:24:29 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 20 Apr 2009 11:24:29 -0400 Subject: [sldev] Merge window for our first release In-Reply-To: <49E904E9.8010009@lindenlab.com> References: <49E904E9.8010009@lindenlab.com> Message-ID: <49EC93AD.7060408@watson.ibm.com> I'd like to see http://jira.secondlife.com/browse/VWR-10311 implemented. It's a trivial change. If it requires any shepherding, I'll do it. I think it would be appropriate for an "open source" viewer. Mike Mm Alder Rob Lanphier wrote: > So, are there other patches in JIRA that seem worthy of making it in > before the first merge window, and are there volunteers to shepherd > those patches through? From moriz.gupte at gmail.com Mon Apr 20 08:40:47 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Mon, 20 Apr 2009 09:40:47 -0600 Subject: [sldev] Merge window for our first release In-Reply-To: <49EC93AD.7060408@watson.ibm.com> References: <49E904E9.8010009@lindenlab.com> <49EC93AD.7060408@watson.ibm.com> Message-ID: I also vote for taking lipsynch out of beta. I use it all the time but have to waste some time telling new users how to enable it. extremely low client side CPU footprint + does what it is supposed to, no reason not to move it out of beta IMHO. R On Mon, Apr 20, 2009 at 9:24 AM, Mike Monkowski wrote: > I'd like to see http://jira.secondlife.com/browse/VWR-10311 implemented. > It's a trivial change. If it requires any shepherding, I'll do it. I > think it would be appropriate for an "open source" viewer. > > Mike > Mm Alder > > Rob Lanphier wrote: > > So, are there other patches in JIRA that seem worthy of making it in > > before the first merge window, and are there volunteers to shepherd > > those patches through? > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org ----- The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge- Stephen Hawking and many others who found light through the cracks of knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090420/deda21ca/attachment.htm From kakurady at gmail.com Mon Apr 20 09:01:23 2009 From: kakurady at gmail.com (Kakurady Drakenar) Date: Mon, 20 Apr 2009 12:01:23 -0400 Subject: [sldev] Merge window for our first release In-Reply-To: References: <49E904E9.8010009@lindenlab.com> <49EC93AD.7060408@watson.ibm.com> Message-ID: <21b2f1350904200901t18a4cc2bpfaaae650e995e183@mail.gmail.com> It doesn't do what it's supposed to do, that is accurate lip-synching for all avatars. All it does is babbling for your own avatar, and all other avatars at the same time when even only one of them talks, because of the limitations of Vivox's voice architecture. Now, if there's a way to have user aware of that caveat, I have nothing else to worry on this issue. GCat/Kakur (To Moriz: Sorry for the duplicate, I forgot to choose "reply to all".) On Mon, Apr 20, 2009 at 11:40 AM, Moriz Gupte wrote: > I also vote for taking lipsynch out of beta. I use it all the time but have > to waste some time telling new users how to enable it. extremely low client > side CPU footprint + does what it is supposed to, no reason not to move it > out of beta IMHO. > R > > > On Mon, Apr 20, 2009 at 9:24 AM, Mike Monkowski wrote: > >> I'd like to see http://jira.secondlife.com/browse/VWR-10311 implemented. >> It's a trivial change. If it requires any shepherding, I'll do it. I >> think it would be appropriate for an "open source" viewer. >> >> Mike >> Mm Alder >> >> Rob Lanphier wrote: >> > So, are there other patches in JIRA that seem worthy of making it in >> > before the first merge window, and are there volunteers to shepherd >> > those patches through? >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > > -- > Rameshsharma Ramloll PhD Research Assistant Professor Idaho State > University, PocatelloTel: 208-282-5333 > Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2, Blog: > http://snipurl.com/3p5op , Play2Train: http://www.play2train.org > ----- > The greatest enemy of knowledge is not ignorance, it is the illusion of > knowledge- Stephen Hawking and many others who found light through the > cracks of knowledge. > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090420/70e336e3/attachment.htm From soft at lindenlab.com Mon Apr 20 09:38:57 2009 From: soft at lindenlab.com (Soft) Date: Mon, 20 Apr 2009 11:38:57 -0500 Subject: [sldev] VWR-10311 Enabling lip sync by default Message-ID: Edited subject. There's enough information to display green waves of appropriate intensity above each speaking avatar. That same information can't be used to control which avatars move their mouths? On Mon, Apr 20, 2009 at 11:01 AM, Kakurady Drakenar wrote: > It doesn't do what it's supposed to do, that is accurate lip-synching for > all avatars. All it does is babbling for your own avatar, and all other > avatars at the same time when even only one of them talks, because of the > limitations of Vivox's voice architecture. > > Now, if there's a way to have user aware of that caveat, I have nothing else > to worry on this issue. > > GCat/Kakur > > (To Moriz: Sorry for the duplicate, I forgot to choose "reply to all".) > > On Mon, Apr 20, 2009 at 11:40 AM, Moriz Gupte wrote: >> >> I also vote for taking lipsynch out of beta. I use it all the time but >> have to waste some time telling new users how to enable it. extremely low >> client side CPU footprint + does what it is supposed to, no reason not to >> move it out of beta IMHO. >> R >> >> On Mon, Apr 20, 2009 at 9:24 AM, Mike Monkowski >> wrote: >>> >>> I'd like to see http://jira.secondlife.com/browse/VWR-10311 implemented. >>> ?It's a trivial change. If it requires any shepherding, I'll do it. ?I >>> think it would be appropriate for an "open source" viewer. >>> >>> Mike >>> Mm Alder >>> >>> Rob Lanphier wrote: >>> > So, are there other patches in JIRA that seem worthy of making it in >>> > before the first merge window, and are there volunteers to shepherd >>> > those patches through? >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting >>> privileges >> >> >> >> -- >> Rameshsharma Ramloll PhD Research Assistant Professor Idaho State >> University, PocatelloTel: 208-282-5333 >> Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 >> , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org >> ----- >> The greatest enemy of knowledge is not ignorance, it is the illusion of >> knowledge- Stephen Hawking and many others who found light through the >> cracks of knowledge. >> >> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From moriz.gupte at gmail.com Mon Apr 20 09:48:53 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Mon, 20 Apr 2009 10:48:53 -0600 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: Message-ID: A few points to note here (1) the argument about fidelity is misplaced given the cartoonish fidelity of SL anyways (2) background noise often trigger the lips movements, of course, no surprise here...but mess up testing and gives wrong impression of cross talk triggered lip animations (3) I have seen with my own eyes that when I speak my lips move and the person infront of me not moving, even in a crowd situation. all parties involved are in full duplex mode (3) using push to talk kills any background sound and lips stay stuck...not moving. Hence, lip sync does INDEED DO what it is supposed to do. Lipsync is a great in mediating turn taking in our setting...and newbies don't like the green indicator that much even though they get used to it. I understand that there is a furry market that will be hit but I think this fear is misplaced. On Mon, Apr 20, 2009 at 10:38 AM, Soft wrote: > Edited subject. > > There's enough information to display green waves of appropriate > intensity above each speaking avatar. That same information can't be > used to control which avatars move their mouths? > > On Mon, Apr 20, 2009 at 11:01 AM, Kakurady Drakenar > wrote: > > It doesn't do what it's supposed to do, that is accurate lip-synching for > > all avatars. All it does is babbling for your own avatar, and all other > > avatars at the same time when even only one of them talks, because of the > > limitations of Vivox's voice architecture. > > > > Now, if there's a way to have user aware of that caveat, I have nothing > else > > to worry on this issue. > > > > GCat/Kakur > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090420/71a40fd8/attachment.htm From monkowsk at watson.ibm.com Mon Apr 20 09:58:35 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Mon, 20 Apr 2009 12:58:35 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: Message-ID: <49ECA9BB.9090502@watson.ibm.com> That same information *is* used. Kakurady's statement is *not* true. Try it for yourself. Mike Soft wrote: > Edited subject. > > There's enough information to display green waves of appropriate > intensity above each speaking avatar. That same information can't be > used to control which avatars move their mouths? > > On Mon, Apr 20, 2009 at 11:01 AM, Kakurady Drakenar wrote: > >>It doesn't do what it's supposed to do, that is accurate lip-synching for >>all avatars. All it does is babbling for your own avatar, and all other >>avatars at the same time when even only one of them talks, because of the >>limitations of Vivox's voice architecture. From dmahalko at gmail.com Mon Apr 20 10:12:12 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon, 20 Apr 2009 12:12:12 -0500 Subject: [sldev] Source directory housekeeping / organizing? Message-ID: The wiki is supposed to help with understanding the viewer source, but certain pages are "stale" and don't reflect the current state of the client anymore. One page that has gotten really stale is this one, which is current as of 1.17.2 on 6/2007... https://wiki.secondlife.com/wiki/Viewer_Source_Files However, a second problem is that the viewer source seems to be in need of some housekeeping and reorganizing, before the wiki page can be reorganized. After the client changed to the new viewer waaaaaaaay back going from \appviewer to \newview it seems that \newview has become a catchall for a lot of new/changed stuff that seems like it should be in folders outside of \newview. For example, in the latest public release ZIP I see in \newview.. 146 files named llfloater*.cpp 88 files named llpanel*.cpp 40 files named lltool*.cpp Um, shouldn't all that be located in \llui ? All the dialog boxes aka floaters and panels and tools are apparently part of the "user interface".... Of course this could go in the reverse direction. Does the source really need subdirectores which contain only a few source files? \llimage is extremely sparse, for example... \llimage\llimage*.cpp -> \newview\. \llimage\llpngwrapper.cpp -> \newview\llimage-llpngwrapper.cpp \llimage\llpngwrapper.h -> \newview\llimage-llpngwrapper.h Some people may like the flat-file view of things, without any folders, since it eliminates digging through a chest of drawers to find a few lonely socks in each one.. It would be nice if one organization method or the other would win, rather than a mashup of some stuff in separate directories, and some stuff all thrown together into \newview, as it is now. Would moving files around from \newview into separate directories screw up the SVN versioning? Do the files just have to stay where they were created for SVN consistency, even if it is not ideal for documentation and comprehension? -- Dale Mahalko / Scalar Tardis From sardonyx at lindenlab.com Mon Apr 20 10:22:45 2009 From: sardonyx at lindenlab.com (Sardonyx Linden) Date: Mon, 20 Apr 2009 10:22:45 -0700 Subject: [sldev] Source directory housekeeping / organizing? In-Reply-To: References: Message-ID: On Mon, Apr 20, 2009 at 10:12 AM, Dale Mahalko wrote: > Would moving files around from \newview into separate directories > screw up the SVN versioning? It screws up merging, because SVN 1.4 and earlier (which we still use) silently drop modifications if a file gets renamed across a merge boundary. 1.5 or 1.6 might have sort of fixed this, but I have little faith in the implementation . -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090420/43722755/attachment.htm From robin.cornelius at gmail.com Mon Apr 20 10:23:39 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 20 Apr 2009 18:23:39 +0100 Subject: [sldev] Source directory housekeeping / organizing? In-Reply-To: References: Message-ID: <49ECAF9B.7080104@gmail.com> Dale Mahalko wrote: > For example, in the latest public release ZIP I see in \newview.. > > 146 files named llfloater*.cpp > 88 files named llpanel*.cpp > 40 files named lltool*.cpp > > Um, shouldn't all that be located in \llui ? All the dialog boxes aka > floaters and panels and tools are apparently part of the "user > interface".... Personally no, llui is the component controls of the UI interface, such as textboxes, list boxes etc, thats a nice self contained group as it is. In theory with a little bit more clean-up that becomes a self contained GL UI widget set. The various implementations of floaters and panels could potentially go in a sub folder, but when there is low level network and packet handling code in the implementation of some of the floaters its very difficult to draw the line to divide up. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090420/6463ffab/attachment.pgp From robla at lindenlab.com Mon Apr 20 10:30:46 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Mon, 20 Apr 2009 10:30:46 -0700 Subject: [sldev] Source directory housekeeping / organizing? In-Reply-To: References: Message-ID: <49ECB146.2030905@lindenlab.com> On 04/20/2009 10:12 AM, Dale Mahalko wrote: > Some people may like the flat-file view of things, without any > folders, since it eliminates digging through a chest of drawers to > find a few lonely socks in each one.. > > It would be nice if one organization method or the other would win, > rather than a mashup of some stuff in separate directories, and some > stuff all thrown together into \newview, as it is now. > > Would moving files around from \newview into separate directories > screw up the SVN versioning? Do the files just have to stay where they > were created for SVN consistency, even if it is not ideal for > documentation and comprehension? > Sadly, it not only screws up SVN versioning, but makes merges next to impossible. One of the big reasons we want to move to Mercurial is to make it feasible to do some directory reshuffling. Until we bite the bullet and fully move over to Mercurial, we can't do this. Rob From dmahalko at gmail.com Mon Apr 20 10:36:33 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Mon, 20 Apr 2009 12:36:33 -0500 Subject: [sldev] Source directory housekeeping / organizing? In-Reply-To: <49ECAF9B.7080104@gmail.com> References: <49ECAF9B.7080104@gmail.com> Message-ID: Ah, okay, so all the panels and floaters and tools should be in \\llui and all the stuff currently in there should be moved to \lluiwidgets. :-) But due to the SVN issues, nevermind. - Dale Mahalko / Scalar Tardis On Mon, Apr 20, 2009 at 12:23 PM, Robin Cornelius wrote: > Personally no, llui is the component controls of the UI interface, such > as textboxes, list boxes etc, thats a nice self contained group as it > is. In theory with a little bit more clean-up that becomes a self > contained GL UI widget set. From blackhat at blackhatdesign.com Mon Apr 20 10:54:23 2009 From: blackhat at blackhatdesign.com (Black Hat Design) Date: Mon, 20 Apr 2009 12:54:23 -0500 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: Message-ID: <061501c9c1e1$0a96ff00$1fc4fd00$@com> I agree that Lip Sync be moved out of Beta. It does a fairly decent job when voice actually works. Unfortunately residents are suffering many voice issues now (http://jira.secondlife.com/browse/VWR-12487) and these are no longer triaged as they appear to be third party issues. I have not had much luck in getting answers from Vivox on the issues currently plaguing SL residents. I am led to believe that the issue is arising out of a conflict with the new SDK which was introduced in RC9 of the current release running alongside the old SDK which many residents are still running since there is no mandatory update to the viewer at this time. Currently, if you want stable voice, you can run the old client and suffer through many of the bugs that are fixed in the current version, or you can run the new client and go back to using Skype and a stream for inworld conferences. Being that Vivox has not been responsive to inquiries, I am curious as to whether there has been some deterioration in the relationship between Linden Lab and Vivox. Dirk Talamasca dirk at dirktalamasca.com Skype: Dirk Talamasca Yahoo: blackhat AIM: Black Hat Design Google: dirktalamasca at gmail.com Edited subject. There's enough information to display green waves of appropriate intensity above each speaking avatar. That same information can't be used to control which avatars move their mouths? On Mon, Apr 20, 2009 at 11:01 AM, Kakurady Drakenar wrote: > It doesn't do what it's supposed to do, that is accurate lip-synching for > all avatars. All it does is babbling for your own avatar, and all other > avatars at the same time when even only one of them talks, because of the > limitations of Vivox's voice architecture. > > Now, if there's a way to have user aware of that caveat, I have nothing else > to worry on this issue. > > GCat/Kakur > > (To Moriz: Sorry for the duplicate, I forgot to choose "reply to all".) > > On Mon, Apr 20, 2009 at 11:40 AM, Moriz Gupte wrote: >> >> I also vote for taking lipsynch out of beta. I use it all the time but >> have to waste some time telling new users how to enable it. extremely low >> client side CPU footprint + does what it is supposed to, no reason not to >> move it out of beta IMHO. >> R >> >> On Mon, Apr 20, 2009 at 9:24 AM, Mike Monkowski >> wrote: >>> >>> I'd like to see http://jira.secondlife.com/browse/VWR-10311 implemented. >>> ?It's a trivial change. If it requires any shepherding, I'll do it. ?I >>> think it would be appropriate for an "open source" viewer. >>> >>> Mike >>> Mm Alder >>> >>> Rob Lanphier wrote: >>> > So, are there other patches in JIRA that seem worthy of making it in >>> > before the first merge window, and are there volunteers to shepherd >>> > those patches through? >>> _______________________________________________ From brad.king at kitware.com Mon Apr 20 11:46:27 2009 From: brad.king at kitware.com (Brad King) Date: Mon, 20 Apr 2009 14:46:27 -0400 Subject: [sldev] easybuild branch In-Reply-To: References: Message-ID: <49ECC303.8080607@kitware.com> Hi Robin, I've been the developer committing changes on the easybuild branch. So far most of the changes have been for delaying download of prebuilt binaries to build time. There are also changes that remove dependence on cygwin (building without flex/bison). Robin Cornelius wrote: > As Rob mentioned yesterday at his office hour, merging easybuild into > http-texture ASAP is probably a good idea so it gets exposure and we > can chase out any bug/ issues that have appeared with the changes to > the build, I agree if its left in its current branch it will get next > to no testing and when it does get merged some of us may then be upset > as its caused build breakage to our way of doing things. > > I've started some testing and hit a few snags already. Thanks for looking. > Firstly i was under the impression that develop.py was going/being > replaced and/or that the build would be started by invoking cmake > directly? Yes. One goal is that CMake will be the only prerequisite. Once the user runs it it will report what other things are missing (like python) along with a link to the wiki with instructions. > I'm personally against invoking cmake directly for people > who *just* want to build as although the number of parameters passed > to cmake have been reduced by various autodetection its still a messy > process. [snip] > mkdir build ; cd build ; cmake -DSTANDALONE:BOOL=true .. If CMake is not easy enough to use without a develop.py front-end, then it will be improved. We've already planned enhancements to CMake's command-line usability for a later phase of this effort. This includes project-specific command-line options like --standalone. Manual creation of the build tree has always been the "cmake way" because we support multiple arbitrarily-located build trees sharing one pristine source tree which is never touched. I think Second Life needs some changes to work with an arbitrarily-located build tree, but I'm sure it's possible if that is a goal. One idea to auto-create a build tree is to have some kind of file in the source tree that tells CMake where to put the build tree if a user tries an in-source build. > 2) There is a subtle change to the develop.py on that branch, it > passes the standalone parameter to cmake for both the build and > configure stages (but with the approprate ON/OFF flag set). What this > means in practice (which i panicked over) is that > > /develop.py --standalone > /develop.py build > > will no longer work, the build stage will start to download prebuilt > packages., because the build call to develop.py has an implicit > STANDALONE:BOOL=FALSE, What this needs to be is now :- > > /develop.py --standalone > /develop.py --standalone build I've made no changes to develop.py, and it looks identical to that on trunk and http-texture. Can you provide more detail, please? > Testing on windows today has failed with missing cursors ( Cannot find > source file "arrow.cur".) at the configure stage. Now i'm not sure at > this point if this is a work in progress and may be today some more > commits will finish this off, but i was under the impression that > artwork-common would now be downloaded and installed by the process. > But i also now notice that artwork-common is not in the install.xml in > easybuild, so i guess this is something gone ahead in trunk and not > ported to the branch that needs it most. The artwork-common change was made after the easybuild branch spawned from trunk and it has not been merged. Automatic artwork and libs downloading is a work-in-progress. > 4) Compiler detection and generators > > Running the default develop.py on my system from a command prompt (no > generator specified) with the path/lib/include set up to point at a > visual studio 2008 install (eg a Visual studio 2008 command prompt) > resulted in the cmake stage finding and testing cl and friends from VC > 2008, then generating a project for Visual studio 2003. > > Basically the "Check for working CXX compiler" will first test the Actually this is just checking that the already-selected compiler works. The search is complete by the time this check runs. Currently CMake does not take the environment into account when selecting a default generator. FYI, you do not actually need to be at a VS prompt if you select a VS IDE generator. Only Make-based generators require one to start CMake from the proper environment. In fact, you can even run cmake-gui from the start menu and not use a command line at all. > 5) VSTool.exe and develop.py and express > > The combination still fails in a big heap, we know that VSTool.exe > itself is of no use to express builders but the current develop.py > still does not have the express edition patches so will not detect an > express and fails in an ungraceful and confusing manor to a builder, > please see http://jira.secondlife.com/browse/VWR-11138 for a solution Again, CMake will be improved so that develop.py can be dropped. -Brad From kerdezixe at gmail.com Mon Apr 20 12:04:15 2009 From: kerdezixe at gmail.com (Laurent Laborde) Date: Mon, 20 Apr 2009 21:04:15 +0200 Subject: [sldev] Proposition of cache improvment Message-ID: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> Friendly greetings ! I'm still worried about cache performance, and come with an idea \o/ I'm still using this lovely I-Ram for my Secondlife cache. (it's a pci-e card with ram slot, and act as a sata hdd, *GOOD* performance) But... from time to time i have this annoying "greyness" in recently visited sim that are supposed to be in cache. I don't believe that is because of a slow disk (it's an i-ram) I think that : - the client request the prims "map" of the sim. - then the client request each texture uuid for each prims. - it check if it's in cache, if not, it request the texture from LL server. I got the idea of declaring a "static object" feature (this prims never change and you can cache the texure uuid in a "prims cache"). But it's not so good. I found that a lot of crowded sim rarely change, and we could save *a lot* of server ressource AND increase user experience. THE(!) Idea : 1) when you log into a sim, the sim send it's "state_uuid". 2a) if the client have this "state" in cache, it can load (almost?) everything from it's own cache. 2b) if not, it use the normal procedure (but still using the good(?) old(!) texture cache of course) 3) everytime something change in the sim, a new state uuid is generated and sim cache is discarded. if( isInCache(state_uuid) ) { LoadSimFromCache(); } else { LoadSimFromServer(); } that's the basic idea. it probably need a lot of tunning. Eg : - apply that to set of prims instead of whole sim ? - don't cache any scripted object ? (because it may contain texture change function (e.g : vendor) - add some estate option for tuning/controling the cache behaviour on this sim ? - add a "static" property to unscripted rezed object ? My sim is very static and see 500~1500 unique visitor/day (up to 45000+ traffic in very good day). It's a shame to use a lot of ressource on something that could be efficiently cached (Sysadmin Inside (tm) ) *hugs* -- Kerunix Flan Laurent Laborde Sysadmin of http://www.over-blog.com/ (1st french blog plateform) From philip at lindenlab.com Mon Apr 20 12:45:54 2009 From: philip at lindenlab.com (Philip Rosedale) Date: Mon, 20 Apr 2009 12:45:54 -0700 Subject: [sldev] Proposition of cache improvment In-Reply-To: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> Message-ID: <49ECD0F2.2090706@lindenlab.com> Hi Laurent. Yes, this is definitely a direction LL intends to go - blocking together large groups of objects into blocks of data for sending/caching. At present we basically handle prims in an atomic fashion relative to culling, interest lists, transmission and caching. By grouping them together we can speed the system up. Challenge (as you point out) is that there are lots of considerations and the optimal block size is larger than a single prim but smaller than a sim of prims. But yes I agree this is the right direction. Laurent Laborde wrote: > Friendly greetings ! > > I'm still worried about cache performance, and come with an idea \o/ > I'm still using this lovely I-Ram for my Secondlife cache. (it's a > pci-e card with ram slot, and act as a sata hdd, *GOOD* performance) > > But... from time to time i have this annoying "greyness" in recently > visited sim that are supposed to be in cache. > I don't believe that is because of a slow disk (it's an i-ram) > I think that : > - the client request the prims "map" of the sim. > - then the client request each texture uuid for each prims. > - it check if it's in cache, if not, it request the texture from LL server. > > I got the idea of declaring a "static object" feature (this prims > never change and you can cache the texure uuid in a "prims cache"). > But it's not so good. > > I found that a lot of crowded sim rarely change, and we could save *a > lot* of server ressource AND increase user experience. > > THE(!) Idea : > 1) when you log into a sim, the sim send it's "state_uuid". > 2a) if the client have this "state" in cache, it can load (almost?) > everything from it's own cache. > 2b) if not, it use the normal procedure (but still using the good(?) > old(!) texture cache of course) > 3) everytime something change in the sim, a new state uuid is > generated and sim cache is discarded. > > if( isInCache(state_uuid) ) { > LoadSimFromCache(); > } else { > LoadSimFromServer(); > } > > that's the basic idea. it probably need a lot of tunning. Eg : > - apply that to set of prims instead of whole sim ? > - don't cache any scripted object ? (because it may contain texture > change function (e.g : vendor) > - add some estate option for tuning/controling the cache behaviour on this sim ? > - add a "static" property to unscripted rezed object ? > > My sim is very static and see 500~1500 unique visitor/day (up to > 45000+ traffic in very good day). > It's a shame to use a lot of ressource on something that could be > efficiently cached (Sysadmin Inside (tm) ) > > *hugs* > > From robin.cornelius at gmail.com Mon Apr 20 15:13:23 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 20 Apr 2009 23:13:23 +0100 Subject: [sldev] easybuild branch In-Reply-To: <49ECC303.8080607@kitware.com> References: <49ECC303.8080607@kitware.com> Message-ID: <49ECF383.1010107@gmail.com> Brad King wrote: > Hi Robin, Hi Brad, Thanks for the reply, > > I've been the developer committing changes on the easybuild branch. > So far most of the changes have been for delaying download of prebuilt > binaries to build time. There are also changes that remove dependence > on cygwin (building without flex/bison). Yes seen those and tested them. Also seen you have the FindNDOF.cmake implemented, but please have a look at http://jira.secondlife.com/browse/VWR-10579 i've added some extra comments (and patch) as the patch applied is still broken and not enabling NDOF in standalone mode. >> Firstly i was under the impression that develop.py was going/being >> replaced and/or that the build would be started by invoking cmake >> directly? > > Yes. One goal is that CMake will be the only prerequisite. Once the > user runs it it will report what other things are missing (like python) > along with a link to the wiki with instructions. Ok that clears things up. Currently it was just rumours floating around about how this was going to work. > >> I'm personally against invoking cmake directly for people >> who *just* want to build as although the number of parameters passed >> to cmake have been reduced by various autodetection its still a messy >> process. > [snip] >> mkdir build ; cd build ; cmake -DSTANDALONE:BOOL=true .. > > If CMake is not easy enough to use without a develop.py front-end, then > it will be improved. We've already planned enhancements to CMake's > command-line usability for a later phase of this effort. This includes > project-specific command-line options like --standalone. I'm all for cmake improvements if they simply the build process, I assume you mean a general project-specific command line option that any user of cmake (not just secondlife) could utilise by crafting there CMakeList.txt correct with new commands etc. An important goal of what i do is building the viewer using only standard distro supplied utilities and libraries on common linux distributions so if custom versions of built tools were required this would be very bad, but again i assume you mean a general cmake change. > > Manual creation of the build tree has always been the "cmake way" > because we support multiple arbitrarily-located build trees sharing > one pristine source tree which is never touched. I think Second Life > needs some changes to work with an arbitrarily-located build tree, but > I'm sure it's possible if that is a goal. > > One idea to auto-create a build tree is to have some kind of file in the > source tree that tells CMake where to put the build tree if a user tries > an in-source build. > This sounds interesting, I think it would be very useful to allow the build location to be set via CMakeList.txt or the command line. So the current way still works but a new system of allowing some function like set_build_directory("build") so this could replace or provide an alternative to the :- mkdir build ; cd build ; cmake $some_options .. which i think would be used my many. Also would allow thinks like set_build_directory("viewer-${ARCH}") to replace what the current develop.py does now. >> 2) There is a subtle change to the develop.py on that branch, it > I've made no changes to develop.py, and it looks identical to that on > trunk and http-texture. Can you provide more detail, please? This may have happened some time previous to the branch off, but its more informational than important and if you plan to kill develop.py anyway it really does not matter. > >> Testing on windows today has failed with missing cursors ( Cannot find >> source file "arrow.cur".) at the configure stage. Now i'm not sure at >> this point if this is a work in progress and may be today some more >> commits will finish this off, but i was under the impression that >> artwork-common would now be downloaded and installed by the process. >> But i also now notice that artwork-common is not in the install.xml in >> easybuild, so i guess this is something gone ahead in trunk and not >> ported to the branch that needs it most. > > The artwork-common change was made after the easybuild branch spawned > from trunk and it has not been merged. Automatic artwork and libs > downloading is a work-in-progress. Ok great. Something that has been brought up with LL a few times recently is how to handle the artwork-common package for standalone builds. There are two ways that probably need to be considered. One where the artwork is automaticly downloaded for the standalone builder, so they still use system supplied libs but they don't need to manually grab the artwork. the second is where the artwork may not be in the build tree at all and will only appear in the final location when the binaries are installed on the target system (eg what happens now on debian packages of the viewer and artwork). So what i would like to see is as follows 1) Standard build automaticly grabs everything 2) Full standalone, no artwork in source tree 3) standalone with automatic artwork fetch > >> 4) Compiler detection and generators > Actually this is just checking that the already-selected compiler works. > The search is complete by the time this check runs. Currently CMake > does not take the environment into account when selecting a default > generator. > > FYI, you do not actually need to be at a VS prompt if you select a VS > IDE generator. Only Make-based generators require one to start CMake > from the proper environment. In fact, you can even run cmake-gui from > the start menu and not use a command line at all. My only concern here was that the compiler used to test the compiler functioned was not the same as was used for the actual build. Some of this may have been confused by the develop.py stage. So hopefully by the time that is removed it will all just work correctly. > >> 5) VSTool.exe and develop.py and express >> >> The combination still fails in a big heap, we know that VSTool.exe >> itself is of no use to express builders but the current develop.py >> still does not have the express edition patches so will not detect an >> express and fails in an ungraceful and confusing manor to a builder, >> please see http://jira.secondlife.com/browse/VWR-11138 for a solution > > Again, CMake will be improved so that develop.py can be dropped. I can see how the existing functionality of vstool could be integrated into cmake. But please remember this does not and cannot work for express editions of visual studio as they do not support the API's necessary for automated editing of the solution, needed for setting the project user options file that contains the default working directory, the start up project and the build type, to name a few options. Something that has not been discussed is the install target. Currently there is a cmake install target provided for standalone and this does indeed work (with one minor patch that is imported to some internal LL branch). This is still very much required by some of us as again we want fine grained control over the naming of the binary and the exact locations of the main binary and the data files. What is there now does work so please keep that intact. Not all of us want to produce tarballs of the viewer the way LL currently do by default. Thanks for your time Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090420/8a1c2b53/attachment.pgp From aimee.trescothick at gmail.com Mon Apr 20 16:02:25 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Tue, 21 Apr 2009 00:02:25 +0100 Subject: [sldev] Merge window for our first release In-Reply-To: <21b2f1350904200901t18a4cc2bpfaaae650e995e183@mail.gmail.com> References: <49E904E9.8010009@lindenlab.com> <49EC93AD.7060408@watson.ibm.com> <21b2f1350904200901t18a4cc2bpfaaae650e995e183@mail.gmail.com> Message-ID: <3F19DCD0-91C4-43DA-9CC6-C88D45DC5B83@gmail.com> On 20 Apr 2009, at 17:01, Kakurady Drakenar wrote: > It doesn't do what it's supposed to do, that is accurate lip- > synching for all avatars. All it does is babbling for your own > avatar, and all other avatars at the same time when even only one of > them talks, because of the limitations of Vivox's voice architecture. If that's what you're seeing it's not normal. It usually only babbles the person talking. Works well for me, the only time I see someone else's lips moving when they shouldn't, is when that person has a problem with their audio setup causing feedback echo. Aimee. From I_really_needed_a_new_mailbox at gmx.de Mon Apr 20 16:33:24 2009 From: I_really_needed_a_new_mailbox at gmx.de (Zai Lynch) Date: Tue, 21 Apr 2009 01:33:24 +0200 Subject: [sldev] To all Wikipedia (and Wikia) contributors Message-ID: This is copy/paste of a statement I just wrote at the Editing Discussionof our SL Wiki: Just a short heads-up that the Wikimedia foundation is currently having a vote amongst all registered users with more than 25 edits before mid March 2009, which is aimed to double license all Wikimedia content under GFDL and CC-BY-SA 3.0. This means we might soon be able to incorporate content from Wikipedia into this Wiki (e.g. templates, icons, ...). In case you got an account at any WikiMedia wiki which is allowed to vote, please consider to do so. Voting will end on May 3rd 2009. All infos about the update can be found at http://meta.wikimedia.org/wiki/Licensing_update. To vote, just log in with your account. The link is displayed for any logged in user at the top of any page (e.g. English Wikipedia: http://en.wikipedia.org/wiki/Special:SecurePoll/vote/1 ). On a similar note: - Please consider voting at WEB-910 [c] for free use of KBcontent in the wiki. - Please consider to double license your SL wiki contributions (e.g. with Template:Re-license_contributions). *Libre knowledge! * Greetz, *Lynch * (talk |contribs ) 23:18, 20 April 2009 (UTC) P.S.: In case Wikimedia succeedes with this, it might be worth trying to ask http://secondlife.wikia.com contributors to do the same. It's also GFDL content and therefor has the same loop hole. Would be especially great for History of Second Life related articles. -- *Lynch * (talk |contribs ) 23:27, 20 April 2009 (UTC) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090421/9864f2ed/attachment.htm From carlo at alinoe.com Mon Apr 20 18:30:54 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 21 Apr 2009 03:30:54 +0200 Subject: [sldev] Proposition of cache improvment In-Reply-To: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> Message-ID: <20090421013054.GA23465@alinoe.com> One could use an arbitrary cache "file tree" to represent a (frequently visited) sim, and sync it again with the servers view of that sim using rsync. http://en.wikipedia.org/wiki/Rsync Rsync is a well established, stable and robust tool with an extremely efficient way of syncing slowly changing arbitrary data. On Mon, Apr 20, 2009 at 09:04:15PM +0200, Laurent Laborde wrote: > Friendly greetings ! > > I'm still worried about cache performance, and come with an idea \o/ > I'm still using this lovely I-Ram for my Secondlife cache. (it's a > pci-e card with ram slot, and act as a sata hdd, *GOOD* performance) > > But... from time to time i have this annoying "greyness" in recently > visited sim that are supposed to be in cache. > I don't believe that is because of a slow disk (it's an i-ram) > I think that : > - the client request the prims "map" of the sim. > - then the client request each texture uuid for each prims. > - it check if it's in cache, if not, it request the texture from LL server. > > I got the idea of declaring a "static object" feature (this prims > never change and you can cache the texure uuid in a "prims cache"). > But it's not so good. > > I found that a lot of crowded sim rarely change, and we could save *a > lot* of server ressource AND increase user experience. > > THE(!) Idea : > 1) when you log into a sim, the sim send it's "state_uuid". > 2a) if the client have this "state" in cache, it can load (almost?) > everything from it's own cache. > 2b) if not, it use the normal procedure (but still using the good(?) > old(!) texture cache of course) > 3) everytime something change in the sim, a new state uuid is > generated and sim cache is discarded. > > if( isInCache(state_uuid) ) { > LoadSimFromCache(); > } else { > LoadSimFromServer(); > } > > that's the basic idea. it probably need a lot of tunning. Eg : > - apply that to set of prims instead of whole sim ? > - don't cache any scripted object ? (because it may contain texture > change function (e.g : vendor) > - add some estate option for tuning/controling the cache behaviour on this sim ? > - add a "static" property to unscripted rezed object ? > > My sim is very static and see 500~1500 unique visitor/day (up to > 45000+ traffic in very good day). > It's a shame to use a lot of ressource on something that could be > efficiently cached (Sysadmin Inside (tm) ) > > *hugs* *hugs back* :) -- Carlo Wood From kerdezixe at gmail.com Mon Apr 20 19:06:14 2009 From: kerdezixe at gmail.com (Laurent Laborde) Date: Tue, 21 Apr 2009 04:06:14 +0200 Subject: [sldev] Proposition of cache improvment In-Reply-To: <20090421013054.GA23465@alinoe.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> <20090421013054.GA23465@alinoe.com> Message-ID: <8a1bfe660904201906v464aa77cod55b83085e9dd013@mail.gmail.com> On Tue, Apr 21, 2009 at 3:30 AM, Carlo Wood wrote: > One could use an arbitrary cache "file tree" to represent > a (frequently visited) sim, and sync it again with the servers > view of that sim using rsync. > > http://en.wikipedia.org/wiki/Rsync > > Rsync is a well established, stable and robust tool with > an extremely efficient way of syncing slowly changing > arbitrary data. As far as i know (and it make sense), eveything but textures files, sound, animation are in database (probably mysql). You can't rsync that ^^ Also, rsync is very good to save bandwith (copy only the modified/new file), but the initial check (comparaison of distant vs local file) is very slow and ressource intensive. (an overkill for a usage in SL (it check too many things that make no sense to check in SL) It's much faster to copy everything when you know that something changed. (that's what we're doing at work) And sooner or later, everything will be http(s) based, which is a very good idea ! Proxy, reverse proxy, CDN, huuuuge webserver cloud/farm (amazon, google, sun, ibm, microsoft, ...) Extremly wide and very well supported set of sotfware for everything you can dream about any usage of http. I'm waiting since years(!) to be able to plug a proxy (like Squid) between the SL Viewer and LL's servers. Because : - I have 100Mbps fiber optic at home, with good ping in france (<10ms). But the ping to USA is over 100ms. (and when you have to request thousands of textures, it's important) - LL server can be slow - my desktop computer is not made for that - i'll be happy to dedicate an old/cheap linux server just for that. With as many TB of disk i may need (a few GB will probably be enough, and could fit in ram disk cache of a dedicated server :D ) -- F4FQM Kerunix Flan Laurent Laborde From GordonWendt at gmail.com Mon Apr 20 20:44:04 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Mon, 20 Apr 2009 23:44:04 -0400 Subject: [sldev] To all Wikipedia (and Wikia) contributors In-Reply-To: References: Message-ID: <493033a70904202044l386767cdxeb6f9011dfb6322c@mail.gmail.com> Cool, I haven't been an active contributor to Wikipedia in years but some of the templates would be amazingly useful on the SL Wiki. That being said I don't think this is less of a deal for moving code over and more for content, I'm not sure templates could ever really be considered protected by the copyright as the article content was, that's arguable but it'll be nice for it to be clearly allowed soon. The general assumption and one that I've made is that this will pass by a supermajority (in WP parlence that's 85%-90% if I remember correctly). -G.W. On Mon, Apr 20, 2009 at 7:33 PM, Zai Lynch < I_really_needed_a_new_mailbox at gmx.de> wrote: > This is copy/paste of a statement I just wrote at the Editing Discussionof our SL Wiki: > > Just a short heads-up that the Wikimedia foundation is currently having a > vote amongst all registered users with more than 25 edits before mid March > 2009, which is aimed to double license all Wikimedia content under GFDL and > CC-BY-SA 3.0. > > This means we might soon be able to incorporate content from Wikipedia into > this Wiki (e.g. templates, icons, ...). In case you got an account at any > WikiMedia wiki which is allowed to vote, please consider to do so. Voting > will end on May 3rd 2009. All infos about the update can be found at > http://meta.wikimedia.org/wiki/Licensing_update. To vote, just log in with > your account. The link is displayed for any logged in user at the top of any > page (e.g. English Wikipedia: > http://en.wikipedia.org/wiki/Special:SecurePoll/vote/1 ). > > On a similar note: > > - Please consider voting at WEB-910 > [c] for free use of KBcontent in the wiki. > - Please consider to double license your SL wiki contributions (e.g. > with Template:Re-license_contributions). > > > *Libre knowledge! * > > Greetz, *Lynch > * (talk |contribs > ) 23:18, 20 April 2009 (UTC) > > P.S.: In case Wikimedia succeedes with this, it might be worth trying to > ask http://secondlife.wikia.com contributors to do the same. It's also > GFDL content and therefor has the same loop hole. Would be especially great > for History of Second Liferelated articles. -- > *Lynch * (talk > |contribs > ) 23:27, 20 April 2009 (UTC) > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090420/f377a492/attachment.htm From kelly at lindenlab.com Mon Apr 20 21:09:47 2009 From: kelly at lindenlab.com (kelly at lindenlab.com) Date: Mon, 20 Apr 2009 21:09:47 -0700 (PDT) Subject: [sldev] DB vs. Asset vs Simulation In-Reply-To: <8a1bfe660904201906v464aa77cod55b83085e9dd013@mail.gmail.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> <20090421013054.GA23465@alinoe.com> <8a1bfe660904201906v464aa77cod55b83085e9dd013@mail.gmail.com> Message-ID: <1522.75.33.197.92.1240286987.squirrel@mail.lindenlab.com> > As far as i know (and it make sense), eveything but textures files, > sound, animation are in database (probably mysql). > You can't rsync that ^^ This is incorrect. :) My overview is at the top of the inventory page: http://wiki.secondlife.com/wiki/Inventory_OS Pertaining to this discussion: Items that you see in world are being simulated and are not in the DB or the asset system but live in memory in the simulator process. Everything that is a thing (can be rezed or viewed) lives in the asset server, not the DB. We actually save (serialize) the state of each simulator once an hour to a file and save that file in the asset system. File type operations on 'simstate' conceptually make some sense. - Kelly From merov at lindenlab.com Tue Apr 21 00:05:59 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Tue, 21 Apr 2009 00:05:59 -0700 Subject: [sldev] Fix for VWR-12827 ( LLVertexBuffer::setupVertexBuffer crash) Message-ID: Hi there, We discussed this issue with devs today and I put together a patch that can be applied against the projects/http-texture code. It's attached to the PJIRA: https://jira.secondlife.com/browse/VWR-12827 Definitely fixed my repro cases. Anyone to apply and test to see if that solves the various repro cases people have been signaling? Cheers, - Merov From carlo at alinoe.com Tue Apr 21 05:56:30 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 21 Apr 2009 14:56:30 +0200 Subject: [sldev] Proposition of cache improvment In-Reply-To: <8a1bfe660904201906v464aa77cod55b83085e9dd013@mail.gmail.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> <20090421013054.GA23465@alinoe.com> <8a1bfe660904201906v464aa77cod55b83085e9dd013@mail.gmail.com> Message-ID: <20090421125630.GA20624@alinoe.com> On Tue, Apr 21, 2009 at 04:06:14AM +0200, Laurent Laborde wrote: > It's much faster to copy everything when you know that something > changed. (that's what we're doing at work) rsync might not be usable, but copying everything as soon as anything changed is not a good algorithm imho. On a sim with 15,000 prims I'm pretty sure there are constantly minor changes - an elevator, a door, an ad somewhere - the pet of someone - or the land is group owned and people can rez/move things. It is extremely likely that -say- 0.1% of the prims changed position or (dis)appeared. No need to re-download the other 99.9% too then :/ -- Carlo Wood From brad.king at kitware.com Tue Apr 21 06:58:24 2009 From: brad.king at kitware.com (Brad King) Date: Tue, 21 Apr 2009 09:58:24 -0400 Subject: [sldev] easybuild branch In-Reply-To: <49ECF383.1010107@gmail.com> References: <49ECC303.8080607@kitware.com> <49ECF383.1010107@gmail.com> Message-ID: <49EDD100.9010405@kitware.com> Robin Cornelius wrote: > please have a look at > http://jira.secondlife.com/browse/VWR-10579 i've added some extra > comments (and patch) as the patch applied is still broken and not > enabling NDOF in standalone mode. Thanks. I've updated the issue further. > I'm all for cmake improvements if they simply the build process [snip] > i assume you mean a general cmake change. Yes, of course. The idea is that improvements that go to CMake help everyone while develop.py is only for Second Life. >> One idea to auto-create a build tree is to have some kind of file in the >> source tree that tells CMake where to put the build tree if a user tries >> an in-source build. > > This sounds interesting, I think it would be very useful to allow the > build location to be set via CMakeList.txt or the command line. So the > current way still works but a new system of allowing some function like [snip] > set_build_directory("viewer-${ARCH}") By the time CMake processes a CMakeLists.txt file it needs to already know where the build tree goes. My proposal is to have an extra file called something like "InSource.cmake" which can be put at the top of the source tree. If someone tries to do an in-source build, this file will be loaded first and it can choose a different build tree. All this will happen before CMakeLists.txt code runs though, and I'm not sure what information we'll be able to make available to the startup script. > So what i would like to see is as follows > > 1) Standard build automaticly grabs everything > 2) Full standalone, no artwork in source tree > 3) standalone with automatic artwork fetch I'm sure something like this is possible. > I can see how the existing functionality of vstool could be integrated > into cmake. But please remember this does not and cannot work for > express editions of visual studio as they do not support the API's > necessary for automated editing of the solution, needed for setting the > project user options file that contains the default working directory, > the start up project and the build type, to name a few options. IIRC the information is not actually in the .sln file but in a user file (.suo or something) next to it. We might be able to directly generate that file if it does not exist, but it need investigation. > Something that has not been discussed is the install target. [snip] > What is there now does work so please keep that intact. Sure. -Brad From josh at lindenlab.com Tue Apr 21 09:42:19 2009 From: josh at lindenlab.com (Joshua Bell) Date: Tue, 21 Apr 2009 09:42:19 -0700 Subject: [sldev] Proposition of cache improvment In-Reply-To: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> Message-ID: <49EDF76B.8010007@lindenlab.com> Laurent Laborde wrote: > 3) everytime something change in the sim, a new state uuid is > generated and sim cache is discarded. Here's another crazy idea that intrepid coders could play with - a two level cache, with per-region bucketing and reference counting. Assume the resident visits a limited number of regions very frequently, and assume that region contents change infrequently on the whole. Implement a cache bucket per region. Have items age out of the cache within buckets as infrequently as possible (and reference counted, so assets used in two regions are only purged if it ages out of both). Limit the number of region cache buckets - and possibly make that user-selectable (advanced option) - and weight those by time-spent-in-region. In theory, the (say) 5 regions you hang out in frequently would "rez" instantly on teleport, and the (say) 5 sims you visit infrequently and irregularly wouldn't have that much of a different experience than you do today. Your least-frequently-visited region would need to stream down all content, but when you teleport back "home" everything looks ducky. This would require no protocol or server-side changes (yay!). From robla at lindenlab.com Tue Apr 21 10:21:54 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Tue, 21 Apr 2009 10:21:54 -0700 Subject: [sldev] Proposition of cache improvment In-Reply-To: <49EDF76B.8010007@lindenlab.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> <49EDF76B.8010007@lindenlab.com> Message-ID: <49EE00B2.7080400@lindenlab.com> On 04/21/2009 09:42 AM, Joshua Bell wrote: > Here's another crazy idea that intrepid coders could play with - a two > level cache, with per-region bucketing and reference counting. Assume > the resident visits a limited number of regions very frequently, and > assume that region contents change infrequently on the whole. Implement > a cache bucket per region. Have items age out of the cache within > buckets as infrequently as possible (and reference counted, so assets > used in two regions are only purged if it ages out of both). Limit the > number of region cache buckets - and possibly make that user-selectable > (advanced option) - and weight those by time-spent-in-region. > That looks like a variation of 2Q caching: https://wiki.secondlife.com/wiki/Texture_cache#Analysis I'm going to guess this would be a fine improvement. I'd be hesitant to implement a more complicated algorithm than 2Q just given the fact that this area gets so much research, and complicated algorithms rarely perform as well as you might think they would. I suppose that in the case of the viewer, texture cache accounting overhead is pretty trivial (as compared to say, a database with thousands of transactions per second), so there's more wiggle room to get fancier, but I'll bet the cost of development + QA + ongoing maintenance of a clever solution can't be justified by the improvement. Rob From GordonWendt at gmail.com Tue Apr 21 10:54:01 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue, 21 Apr 2009 13:54:01 -0400 Subject: [sldev] [bsi] Public Nightly Build is Available: 1.23.0.117724 In-Reply-To: <49ED613D.1020401@lindenlab.com> References: <49ED613D.1020401@lindenlab.com> Message-ID: <493033a70904211054v710a8b6aw295a5170fd7b2029@mail.gmail.com> Dessie, any chance of getting some regions on Aditi to test the new adult content features as I don't think there's any live regions on Agni that make use of them yet? If I'm wrong and there are some is there a list somewhere of regions using the new AO measures that we can test in? -Gordon Wendt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090421/3cc2b4c8/attachment.htm From GordonWendt at gmail.com Tue Apr 21 10:54:56 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Tue, 21 Apr 2009 13:54:56 -0400 Subject: [sldev] [bsi] Public Nightly Build is Available: 1.23.0.117724 In-Reply-To: <493033a70904211054v710a8b6aw295a5170fd7b2029@mail.gmail.com> References: <49ED613D.1020401@lindenlab.com> <493033a70904211054v710a8b6aw295a5170fd7b2029@mail.gmail.com> Message-ID: <493033a70904211054u7a3a51bblb6929d8db73fdecb@mail.gmail.com> Please ignore, mis-sent this to the wrong list. -G.W. On Tue, Apr 21, 2009 at 1:54 PM, Gordon Wendt wrote: > Dessie, any chance of getting some regions on Aditi to test the new adult > content features as I don't think there's any live regions on Agni that make > use of them yet? If I'm wrong and there are some is there a list somewhere > of regions using the new AO measures that we can test in? > > -Gordon Wendt > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090421/0e3a2f3b/attachment.htm From dmahalko at gmail.com Tue Apr 21 11:45:08 2009 From: dmahalko at gmail.com (Dale Mahalko) Date: Tue, 21 Apr 2009 13:45:08 -0500 Subject: [sldev] Proposition of cache improvment In-Reply-To: <49EE00B2.7080400@lindenlab.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> <49EDF76B.8010007@lindenlab.com> <49EE00B2.7080400@lindenlab.com> Message-ID: I recall these discussions years ago on the SL forums back when nobody who could actually foment change read them, so this seems old news to me. SL tries to be completely stateless. In an ideal world the client would never cache anything and the whole world would be streamed constantly from central command. Actually this sounds like the new "play any 3D video games from a streaming server" idea I hear being thrown around. It's very bandwidth intensive, and SL seems to be holding out for a future when everyone has 100 megabit to the home. If you want a world you can load up from a cache and then only get updates for changes, the stateless design principle is going to have to change to something more transactional. This might be too fundamental of a change for the current design to deal with. Per-prim transaction tracking is probably way too intensive. But break the sim up into 8x8 meter chunks (no height limit), and timestamp any prim changes within each chunk, and now you've got a fast, practical cache method that doesn't get overly granular. Client says: I have these cached chunks of the current sim, and I have these timestamps for each chunk. Sim says: Here is a list of chunks have changed since your last vist. All others are unchanged. Client loads the unchanged cached chunks from disk. Sim only sends prim data for the changed chunks. The lurking problem that is not going to go away and can not be solved is the intellectual property issues. A cache of the world can be ripped. But hey, a stream of the world using the existing methods can be ripped too. So might as well make caching fast and reliable regardless of the fact that it is rippable, because the current stateless stream method offers no better content protection anyway. Not improving caching for the sake of trying to prevent content ripping is basically an invalid premise. - Dale Mahalko / Scalar Tardis From gbrandon at gmail.com Tue Apr 21 12:11:09 2009 From: gbrandon at gmail.com (Brandon Lockaby) Date: Tue, 21 Apr 2009 15:11:09 -0400 Subject: [sldev] Proposition of cache improvment In-Reply-To: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> Message-ID: That does sound plausible if you can differentiate which content is cached that way... You say "static objects"... perhaps, if an object hasn't been changed in 2 days it could be placed in that category, something like that? On Mon, Apr 20, 2009 at 3:04 PM, Laurent Laborde wrote: > Friendly greetings ! > > I'm still worried about cache performance, and come with an idea \o/ > I'm still using this lovely I-Ram for my Secondlife cache. (it's a > pci-e card with ram slot, and act as a sata hdd, *GOOD* performance) > > But... from time to time i have this annoying "greyness" in recently > visited sim that are supposed to be in cache. > I don't believe that is because of a slow disk (it's an i-ram) > I think that : > - the client request the prims "map" of the sim. > - then the client request each texture uuid for each prims. > - it check if it's in cache, if not, it request the texture from LL server. > > I got the idea of declaring a "static object" feature (this prims > never change and you can cache the texure uuid in a "prims cache"). > But it's not so good. > > I found that a lot of crowded sim rarely change, and we could save *a > lot* of server ressource AND increase user experience. > > THE(!) Idea : > 1) when you log into a sim, the sim send it's "state_uuid". > 2a) if the client have this "state" in cache, it can load (almost?) > everything from it's own cache. > 2b) if not, it use the normal procedure (but still using the good(?) > old(!) texture cache of course) > 3) everytime something change in the sim, a new state uuid is > generated and sim cache is discarded. > > if( isInCache(state_uuid) ) { > LoadSimFromCache(); > } else { > LoadSimFromServer(); > } > > that's the basic idea. it probably need a lot of tunning. Eg : > - apply that to set of prims instead of whole sim ? > - don't cache any scripted object ? (because it may contain texture > change function (e.g : vendor) > - add some estate option for tuning/controling the cache behaviour on this > sim ? > - add a "static" property to unscripted rezed object ? > > My sim is very static and see 500~1500 unique visitor/day (up to > 45000+ traffic in very good day). > It's a shame to use a lot of ressource on something that could be > efficiently cached (Sysadmin Inside (tm) ) > > *hugs* > > -- > Kerunix Flan > Laurent Laborde > Sysadmin of http://www.over-blog.com/ (1st french blog plateform) > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090421/0200ef6a/attachment.htm From me at signpostmarv.name Tue Apr 21 13:31:04 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Tue, 21 Apr 2009 21:31:04 +0100 Subject: [sldev] Proposition of cache improvment In-Reply-To: References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> Message-ID: <49EE2D08.6090709@signpostmarv.name> Kelly said that the sim state is serialized once an hour, so if an object hasn't changed between states, wouldn't it be considered static ? ~ Marv. Brandon Lockaby wrote: > That does sound plausible if you can differentiate which content is > cached that way... > You say "static objects"... perhaps, if an object hasn't been changed > in 2 days it could be placed in that category, something like that? > > On Mon, Apr 20, 2009 at 3:04 PM, Laurent Laborde > wrote: > > Friendly greetings ! > > I'm still worried about cache performance, and come with an idea \o/ > I'm still using this lovely I-Ram for my Secondlife cache. (it's a > pci-e card with ram slot, and act as a sata hdd, *GOOD* performance) > > But... from time to time i have this annoying "greyness" in recently > visited sim that are supposed to be in cache. > I don't believe that is because of a slow disk (it's an i-ram) > I think that : > - the client request the prims "map" of the sim. > - then the client request each texture uuid for each prims. > - it check if it's in cache, if not, it request the texture from > LL server. > > I got the idea of declaring a "static object" feature (this prims > never change and you can cache the texure uuid in a "prims cache"). > But it's not so good. > > I found that a lot of crowded sim rarely change, and we could save *a > lot* of server ressource AND increase user experience. > > THE(!) Idea : > 1) when you log into a sim, the sim send it's "state_uuid". > 2a) if the client have this "state" in cache, it can load (almost?) > everything from it's own cache. > 2b) if not, it use the normal procedure (but still using the good(?) > old(!) texture cache of course) > 3) everytime something change in the sim, a new state uuid is > generated and sim cache is discarded. > > if( isInCache(state_uuid) ) { > LoadSimFromCache(); > } else { > LoadSimFromServer(); > } > > that's the basic idea. it probably need a lot of tunning. Eg : > - apply that to set of prims instead of whole sim ? > - don't cache any scripted object ? (because it may contain texture > change function (e.g : vendor) > - add some estate option for tuning/controling the cache behaviour > on this sim ? > - add a "static" property to unscripted rezed object ? > > My sim is very static and see 500~1500 unique visitor/day (up to > 45000+ traffic in very good day). > It's a shame to use a lot of ressource on something that could be > efficiently cached (Sysadmin Inside (tm) ) > > *hugs* > > -- > Kerunix Flan > Laurent Laborde > Sysadmin of http://www.over-blog.com/ (1st french blog plateform) > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090421/a1240248/attachment.bin From open at autistici.org Wed Apr 22 05:06:49 2009 From: open at autistici.org (Opensource Obscure) Date: Wed, 22 Apr 2009 12:06:49 +0000 Subject: [sldev] [Blogs] WEB-1038: too much email notifications Message-ID: <6990c60fdfe0d74f14730cad00982dea@localhost> I just updated http://jira.secondlife.com/browse/WEB-1038 where I report two problems I'm seeing in the way official blogs manage email notifications right now. Hopefully I didn't create a duplicate - if you're aware of other similar tickets please tell me. Basically, I think that by default notifications - should NOT get sent when an existing post is simply updated - should NOT get sent when a post is commented by someone I'm not subscribed to I'm pretty sure I'm receiving both these kinds of notifications right now, and they're way too much emails. Could someone please test this, and comment/vote on http://jira.secondlife.com/browse/WEB-1038 ? Opensource Obscure From soft at lindenlab.com Wed Apr 22 09:02:30 2009 From: soft at lindenlab.com (Soft) Date: Wed, 22 Apr 2009 11:02:30 -0500 Subject: [sldev] Open Source Meeting Thu 2pm Message-ID: Our Thursday open source meetings take place at 2pm. If there is anything you would like on the agenda... have at it! http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda There will not be pie. From danteferret at gmail.com Wed Apr 22 10:13:43 2009 From: danteferret at gmail.com (Dante Tucker) Date: Wed, 22 Apr 2009 13:13:43 -0400 Subject: [sldev] [Blogs] WEB-1038: too much email notifications In-Reply-To: <6990c60fdfe0d74f14730cad00982dea@localhost> References: <6990c60fdfe0d74f14730cad00982dea@localhost> Message-ID: <4d211a610904221013x1520df33k20dc472c4236ddb2@mail.gmail.com> Blue's first comment on WEB-983 should help people getting flooded at the moment. ".....In the meantime, you can go to the individual post you've commented to and click Stop Email Notification in the Action bar on the left." On Wed, Apr 22, 2009 at 8:06 AM, Opensource Obscure wrote: > > I just updated http://jira.secondlife.com/browse/WEB-1038 > where I report two problems I'm seeing in the way > official blogs manage email notifications right now. > > Hopefully I didn't create a duplicate - if you're > aware of other similar tickets please tell me. > > Basically, I think that by default notifications > - should NOT get sent when an existing post is simply updated > - should NOT get sent when a post is commented by someone > I'm not subscribed to > > I'm pretty sure I'm receiving both these kinds of > notifications right now, and they're way too much emails. > > > Could someone please test this, and comment/vote on > http://jira.secondlife.com/browse/WEB-1038 ? > > Opensource Obscure > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090422/949fe314/attachment.htm From robla at lindenlab.com Wed Apr 22 11:40:47 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 22 Apr 2009 11:40:47 -0700 Subject: [sldev] Community QA process Message-ID: <49EF64AF.6070601@lindenlab.com> Hi folks, I've filed the following issue in JIRA: "Write up QA process for new http-texture branch viewer" https://jira.secondlife.com/browse/VWR-12931 ...which is on my plate to write up. However, I'm looking for community input on this. One thing we're not currently planning on doing is submitting this branch of the viewer through our standard QA process. Instead, we've got nightly builds, and a community of people who will want to use this version of the viewer since it'll include several bits of functionality not yet available in the main Second Life viewer. How will we know when we're "done"? Will we need to have a daily triage discussion during the last leg of development? Will there be anyone willing to run through formal test plans? What is realistic? Rob From robla at lindenlab.com Wed Apr 22 15:37:12 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Wed, 22 Apr 2009 15:37:12 -0700 Subject: [sldev] easybuild-2 plan In-Reply-To: <49EDD100.9010405@kitware.com> References: <49ECC303.8080607@kitware.com> <49ECF383.1010107@gmail.com> <49EDD100.9010405@kitware.com> Message-ID: <49EF9C18.7040303@lindenlab.com> Hi folks, I've had a few conversations with folks in addition to the discussion here about easybuild, and here's what I'm thinking: 1. Let's wait until the dust settles on the 1.23 merge that Merov is working on right now 2. When that's done, let's rebase easybuild on the http-texture branch, creating an easybuild-2 branch 3. Then, let's get a few of the suggested changes into easybuild-2 That's assuming that we don't want to make this a guinea pig for the improved merge tracking features in Subversion 1.5, which we don't have a ton of experience with here at Linden Lab (thus our pathological urge to create numbered branches every time we rebase). It's not clear if the easybuild-2 stuff would make it in our first viewer release off of this branch, but I think that's ok. Thoughts? Rob From GordonWendt at gmail.com Wed Apr 22 17:25:50 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed, 22 Apr 2009 20:25:50 -0400 Subject: [sldev] Community QA process In-Reply-To: <49EF64AF.6070601@lindenlab.com> References: <49EF64AF.6070601@lindenlab.com> Message-ID: <493033a70904221725q2efb4197l7bf43831bc7de56e@mail.gmail.com> Rob, When PN's become available for this branch will notices be posted to the BSI and/or sldev lists so that we can easily keep up with them? Thanks. -G.W. On Wed, Apr 22, 2009 at 2:40 PM, Rob Lanphier wrote: > Hi folks, > > I've filed the following issue in JIRA: > > "Write up QA process for new http-texture branch viewer" > https://jira.secondlife.com/browse/VWR-12931 > > ...which is on my plate to write up. However, I'm looking for community > input on this. > > One thing we're not currently planning on doing is submitting this > branch of the viewer through our standard QA process. Instead, we've > got nightly builds, and a community of people who will want to use this > version of the viewer since it'll include several bits of functionality > not yet available in the main Second Life viewer. > > How will we know when we're "done"? Will we need to have a daily triage > discussion during the last leg of development? Will there be anyone > willing to run through formal test plans? What is realistic? > > Rob > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090422/59866e17/attachment.htm From joe at lindenlab.com Wed Apr 22 19:00:32 2009 From: joe at lindenlab.com (Joe Miller) Date: Wed, 22 Apr 2009 19:00:32 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <061501c9c1e1$0a96ff00$1fc4fd00$@com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> Message-ID: <49EFCBC0.6030908@lindenlab.com> An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090422/8219246d/attachment.htm From TammyNowotny at mac.com Wed Apr 22 19:29:54 2009 From: TammyNowotny at mac.com (Tammy Nowotny) Date: Wed, 22 Apr 2009 22:29:54 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49EFCBC0.6030908@lindenlab.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> Message-ID: <49EFD2A2.5020808@mac.com> I have been having trouble with voice not firing up with 1.23. My friends list is pretty long but it is less than 800, by a factor of 10. (But that may not include avatars who have left the game and been away for years, but whose calling card is still in my inventory and/or who I never purged from my list.) I have an old pre-intel Mac Mini with only 1 GB of memory. --Tammy Nowotny Joe Miller wrote: > Dirk, > > Quite the contrary, the Linden Lab / Vivox relationship is very > healthy and we have some interesting new features ready to roll > shortly. There were a few issues in the SDK shipped with the 1.22 > viewer that have caused problems for some folks. One in particular > was triggered by very large Friends Lists (800+ calling cards in > inventory) so it would likely affect long-term residents like > yourself. That problem (and others mentioned in the Jira you > referenced below) should be fixed now in the 1.23RC nightly, soon to > be RC0. If you have questions around functionality or problems with > voice in SL, you'll have better luck seeking answers here or at Linden > than expecting Vivox to respond. Please feel free to hit me with an > IM or email if you have specific issues or questions you're having > trouble getting answers to. I'll get you the answers. > > -- Joe > > Black Hat Design wrote: >> I agree that Lip Sync be moved out of Beta. It does a fairly decent job when >> voice actually works. Unfortunately residents are suffering many voice >> issues now (http://jira.secondlife.com/browse/VWR-12487) and these are no >> longer triaged as they appear to be third party issues. I have not had much >> luck in getting answers from Vivox on the issues currently plaguing SL >> residents. I am led to believe that the issue is arising out of a conflict >> with the new SDK which was introduced in RC9 of the current release running >> alongside the old SDK which many residents are still running since there is >> no mandatory update to the viewer at this time. >> >> Currently, if you want stable voice, you can run the old client and suffer >> through many of the bugs that are fixed in the current version, or you can >> run the new client and go back to using Skype and a stream for inworld >> conferences. >> >> Being that Vivox has not been responsive to inquiries, I am curious as to >> whether there has been some deterioration in the relationship between Linden >> Lab and Vivox. >> >> Dirk Talamasca >> dirk at dirktalamasca.com >> >> Skype: Dirk Talamasca >> Yahoo: blackhat >> AIM: Black Hat Design >> Google: dirktalamasca at gmail.com >> >> Edited subject. >> >> There's enough information to display green waves of appropriate >> intensity above each speaking avatar. That same information can't be >> used to control which avatars move their mouths? >> >> On Mon, Apr 20, 2009 at 11:01 AM, Kakurady Drakenar >> wrote: >> >>> It doesn't do what it's supposed to do, that is accurate lip-synching for >>> all avatars. All it does is babbling for your own avatar, and all other >>> avatars at the same time when even only one of them talks, because of the >>> limitations of Vivox's voice architecture. >>> >>> Now, if there's a way to have user aware of that caveat, I have nothing >>> >> else >> >>> to worry on this issue. >>> >>> GCat/Kakur >>> >>> (To Moriz: Sorry for the duplicate, I forgot to choose "reply to all".) >>> >>> On Mon, Apr 20, 2009 at 11:40 AM, Moriz Gupte >>> >> wrote: >> >>>> I also vote for taking lipsynch out of beta. I use it all the time but >>>> have to waste some time telling new users how to enable it. extremely low >>>> client side CPU footprint + does what it is supposed to, no reason not to >>>> move it out of beta IMHO. >>>> R >>>> >>>> On Mon, Apr 20, 2009 at 9:24 AM, Mike Monkowski >>>> wrote: >>>> >>>>> I'd like to see http://jira.secondlife.com/browse/VWR-10311 implemented. >>>>> It's a trivial change. If it requires any shepherding, I'll do it. I >>>>> think it would be appropriate for an "open source" viewer. >>>>> >>>>> Mike >>>>> Mm Alder >>>>> >>>>> Rob Lanphier wrote: >>>>> >>>>>> So, are there other patches in JIRA that seem worthy of making it in >>>>>> before the first merge window, and are there volunteers to shepherd >>>>>> those patches through? >>>>>> >>>>> _______________________________________________ >>>>> >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090422/510a2af7/attachment.htm From merov at lindenlab.com Wed Apr 22 22:00:23 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 22 Apr 2009 22:00:23 -0700 Subject: [sldev] easybuild-2 plan In-Reply-To: <49EF9C18.7040303@lindenlab.com> References: <49ECC303.8080607@kitware.com><49ECF383.1010107@gmail.com> <49EDD100.9010405@kitware.com> <49EF9C18.7040303@lindenlab.com> Message-ID: <770075B3-2F04-4929-9BF1-0B28FB0168FD@lindenlab.com> Hi Rob, On Apr 22, 2009, at 3:37 PM, Rob Lanphier wrote: > 1. Let's wait until the dust settles on the 1.23 merge that Merov is > working on right now I'm done with the merge on an internal svn branch. I'll export that tomorrow (with CG's help) and work on merging this with the commits we did on the projects branch (relatively few actually so it shouldn't be too bad). IOW, the dust is settling pretty fast on that one :) > 2. When that's done, let's rebase easybuild on the http-texture > branch, > creating an easybuild-2 branch I suppose here you are talking about branches/2009/http-texture right? (i.e. the newly merged 1.23 + http-texture exported here above). > 3. Then, let's get a few of the suggested changes into easybuild-2 Seems good to me. That way, both projects/2009/easybuild-2 and projects/2009/http-texture will start from the same base. That makes me think that we should create a projects/2009/http- texture-2 branch though, for a reason I can't remember now, CG was not open to that this afternoon. Cheers, - Merov From merov at lindenlab.com Wed Apr 22 22:14:00 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 22 Apr 2009 22:14:00 -0700 Subject: [sldev] Community QA process In-Reply-To: <49EF64AF.6070601@lindenlab.com> References: <49EF64AF.6070601@lindenlab.com> Message-ID: <48C4E81B-9BED-4707-B939-E57472F7A352@lindenlab.com> Hi guys, On Apr 22, 2009, at 11:40 AM, Rob Lanphier wrote: > How will we know when we're "done"? I'm tempted to answer "define 'done'" though that's not very constructive :) Since we have nightly builds, that notion of a done viewer only applies to "the OS viewer", the one that gets stamped as "for anyone's usage" and not just devs. If we have a community QA, I think the best is to agree on a "level of bugs" criteria (say: no show stopper for instance). We can decide what constitute a show stopper on this list and during the weekly IW triage meeting with the community. > Will we need to have a daily triage discussion during the last leg > of development? I propose "limited to the identified set of show stoppers". Otherwise it'll be endless. > Will there be anyone willing to run through formal test plans? What > is realistic? That doesn't seem very realistic to me... unless someone volunteers of course! :) Having lots of community eyes on the product though should ensure a rather good test coverage IMHO. Then of course, we need more unit tests and auto tests (crash rate in particular). That could also give us a release criteria. Cheers, - Merov From open at autistici.org Thu Apr 23 02:59:32 2009 From: open at autistici.org (Opensource Obscure) Date: Thu, 23 Apr 2009 09:59:32 +0000 Subject: [sldev] [Blogs] WEB-1038: too much email notifications In-Reply-To: <4d211a610904221013x1520df33k20dc472c4236ddb2@mail.gmail.com> References: <6990c60fdfe0d74f14730cad00982dea@localhost> <4d211a610904221013x1520df33k20dc472c4236ddb2@mail.gmail.com> Message-ID: Thanks for the tip - I'm going to comment and link WEB-983. However I'm not subscribed to any individual post, thread or discussion. I'm only subscribed to individual users (about 70 users, both Linden and normal users). I'm getting a notification even when their articles get a comment from users I'm not subscribed to. I don't think this is the expected behaviour. I'm getting notifications also when they update their articles, and maybe this is the expected behaviour, BUT - I think this should be optional: new blog posts and new comments are supposed to be more interesting than an update to existing content; if the existing content is heavily updated, the author could add a comment. In this scenario, there is no need to notify users every time the article is updated. -- opensource obscure On Wed, 22 Apr 2009 13:13:43 -0400, Dante Tucker wrote: > Blue's first comment on WEB-983 should help people getting flooded at the > moment. > ".....In the meantime, you can go to the individual post you've commented > to > and click Stop Email Notification in the Action bar on the left." > > On Wed, Apr 22, 2009 at 8:06 AM, Opensource Obscure > wrote: > >> >> I just updated http://jira.secondlife.com/browse/WEB-1038 >> where I report two problems I'm seeing in the way >> official blogs manage email notifications right now. >> >> Hopefully I didn't create a duplicate - if you're >> aware of other similar tickets please tell me. >> >> Basically, I think that by default notifications >> - should NOT get sent when an existing post is simply updated >> - should NOT get sent when a post is commented by someone >> I'm not subscribed to >> >> I'm pretty sure I'm receiving both these kinds of >> notifications right now, and they're way too much emails. >> >> >> Could someone please test this, and comment/vote on >> http://jira.secondlife.com/browse/WEB-1038 ? >> >> Opensource Obscure >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> From carlo at alinoe.com Thu Apr 23 05:52:38 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 23 Apr 2009 14:52:38 +0200 Subject: [sldev] easybuild-2 plan In-Reply-To: <770075B3-2F04-4929-9BF1-0B28FB0168FD@lindenlab.com> References: <49EDD100.9010405@kitware.com> <49EF9C18.7040303@lindenlab.com> <770075B3-2F04-4929-9BF1-0B28FB0168FD@lindenlab.com> Message-ID: <20090423125238.GA892@alinoe.com> On Wed, Apr 22, 2009 at 10:00:23PM -0700, Philippe Bossut (Merov Linden) wrote: > > creating an easybuild-2 branch > > I suppose here you are talking about branches/2009/http-texture right? > (i.e. the newly merged 1.23 + http-texture exported here above). I lost track of how many branches exist where. Is there an overview of the available open repositories / branches somewhere, what they are/mean and how to download them? -- Carlo Wood From robin.cornelius at gmail.com Thu Apr 23 08:30:46 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 23 Apr 2009 16:30:46 +0100 Subject: [sldev] Easy build/Artwork tarball distribution Message-ID: Hey guys, Do LL plan to keep distributing the source code (for point releases) and artwork in the way it currently is, as found at :- http://wiki.secondlife.com/wiki/Source_archive eg separate source/artwork etc. I'm assuming the libs packages will stop being exported due to the install.xml work that is happening.? and with the artwork-common packages are we also going to see the demise of the artwork from that page too? What my issue is (today ;-p), is that with the new SVN checkins today to easybuild is that although its now possible to build the viewer code with an out of build tree artwork location using some new cmake options, I still need to patch the cmake build rules in order to build with *no* artwork in tree at all, this is the standard way i build for Debian/Ubuntu packages but only because the artwork and viewer source are distributed as separate tarballs/zips. If the point releases are going to happen WITH artwork in tree as well then this is not a problem, but i'm guessing as everything is gearing up for artwork-common then the point release page will end up just source. The way the source *almost* use to build was a warning was printed for no in tree artwork (although this seemed to be often broken and i did need a patch applied to make it work) and the build would continue. For linux builds this is certainly not a problem as there is no resource compiler so non of the artwork is embedded into anything. So some of the way i will go depends on LL's plan for the point release source page. My two roads are :- 1) artwork is always a seperate package either on install page or via install.xml 2) artwork for point releases is merged in the source zip/tar.gz (seems unlikely this will happen to me) I can quite easily add a cmake option to not error out when the artwork is not present, which i will do anyway and attach to a JIRA. Regards Robin From robin.cornelius at gmail.com Thu Apr 23 08:40:09 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 23 Apr 2009 16:40:09 +0100 Subject: [sldev] easybuild-2 plan In-Reply-To: <49EF9C18.7040303@lindenlab.com> References: <49ECC303.8080607@kitware.com> <49ECF383.1010107@gmail.com> <49EDD100.9010405@kitware.com> <49EF9C18.7040303@lindenlab.com> Message-ID: On Wed, Apr 22, 2009 at 11:37 PM, Rob Lanphier wrote: > Hi folks, > > I've had a few conversations with folks in addition to the discussion > here about easybuild, and here's what I'm thinking: > > 1. Let's wait until the dust settles on the 1.23 merge that Merov is > working on right now > 2. When that's done, let's rebase easybuild on the http-texture branch, > creating an easybuild-2 branch > 3. Then, let's get a few of the suggested changes into easybuild-2 > > That's assuming that we don't want to make this a guinea pig for the > improved merge tracking features in Subversion 1.5, which we don't have > a ton of experience with here at Linden Lab (thus our pathological urge > to create numbered branches every time we rebase). > Thoughts? Yes lets get easybuild and http-texture merged, then we can work out of a single branch as the easybuild work greatly effects my packaging building and is only of benefit to builders of the viewer from source code it makes lots of sense to get this in the open-source branch . The easybuild stuff *should* be pretty isolated from any code changes within the viewer as its only affecting build rules/scripts so the conflict potential should be minimal there. something we need to be careful of here is some of the planed changes are being done to cmake itsself so this would bump the minimum cmake version and we probably don't want to all have to suddenly upgraded that on this cycle. This would make sense for the easybuild-2 or greater branch. But nothing that has gone in to easybuild so far has required such a cmake version bump. Robin From robin.cornelius at gmail.com Thu Apr 23 08:53:58 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 23 Apr 2009 16:53:58 +0100 Subject: [sldev] Community QA process In-Reply-To: <48C4E81B-9BED-4707-B939-E57472F7A352@lindenlab.com> References: <49EF64AF.6070601@lindenlab.com> <48C4E81B-9BED-4707-B939-E57472F7A352@lindenlab.com> Message-ID: On Thu, Apr 23, 2009 at 6:14 AM, Philippe Bossut (Merov Linden) wrote: > Hi guys, > > On Apr 22, 2009, at 11:40 AM, Rob Lanphier wrote: >> How will we know when we're "done"? > > I'm tempted to answer "define 'done'" though that's not very > constructive :) > I think we have a pretty well defined set of features that we want to implement on this cycle. Certainly having them all "acceptably" finished and "acceptably" bug free is an important goal here. I think also we need to monitor the crash rate and the bug reports coming in. In theory once all bugs of a certain severity or greater are tackled and the crash rate has reached an appropriate lull we can declare "good enough". Really incomming crash reports should be opening new pJIRAs so as we don't have data from this side of the firewall, would be good to have someone from LL open them with the stack traces and some indication of volume so this can be used to judge severity. This should cause a feedback loop that the output of can be used to flip the go switch. > Since we have nightly builds, that notion of a done viewer only > applies to "the OS viewer", the one that gets stamped as "for anyone's > usage" and not just devs. If we have a community QA, I think the best > is to agree on a "level of bugs" criteria (say: no show stopper for > instance). We can decide what constitute a show stopper on this list > and during the weekly IW triage meeting with the community. > >> Will we need to have a daily triage discussion during the last leg >> of development? > > I propose "limited to the identified set of show stoppers". Otherwise > it'll be endless. Yes there does need to be a bit of restriction placed on this or as you say it will get out of hand. Also daily triage is going to be difficult for many of us and it would be very very useful to have some asyncronous ways of handling this as well. Probably via the mailing list is the best as i can ponder things during my lunch time at work whist most of you are still in bed in the early hours of the morning. The other thing to be careful of for me at least is, 1) i'm not paid for any of this and do need to make a living doing my paid job, and also i do need to have a life other than secondlife development, although it may not seem like it to some ;-p. But seriously there is only so much time a week i can spend on opensource projects and I am sure many others are the same. so daily real time triage discussion may prove an issue. > >> Will there be anyone willing to run through formal test plans? ?What >> is realistic? > > That doesn't seem very realistic to me... unless someone volunteers of > course! :) Having lots of community eyes on the product though should > ensure a rather good test coverage IMHO. +1, but out of curiosity what constitutes a formal test plan internally currently? What scope does it have and how is it constructed? This info could be useful and may be ideas can be used as appropriate for a test plan this side of the firewall. > > Then of course, we need more unit tests and auto tests (crash rate in > particular). That could also give us a release criteria. Sure, but also crash rate from crashlogger on test builds should be used for a release criteria as mentioned previously. Robin From brad.king at kitware.com Thu Apr 23 09:36:55 2009 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Apr 2009 12:36:55 -0400 Subject: [sldev] Easy build/Artwork tarball distribution In-Reply-To: References: Message-ID: <49F09927.60607@kitware.com> Robin Cornelius wrote: > I still need to patch the cmake build rules in order to build > with *no* artwork in tree at all I was not aware of this goal when I made the changes. > but i'm guessing as everything is gearing up for > artwork-common then the point release page will end up just source. It seems that artwork-common has only a subset of the artwork. Now one needs *both* artwork-common and the artwork zip file. Does anyone know why? > The way the source *almost* use to build was a warning was printed for > no in tree artwork (although this seemed to be often broken and i did > need a patch applied to make it work) and the build would continue. > For linux builds this is certainly not a problem as there is no > resource compiler so non of the artwork is embedded into anything. This is why I thought the artwork was required. It is on windows. > I can quite easily add a cmake option to not error out when the > artwork is not present, which i will do anyway and attach to a JIRA. I already have some changes along these lines underway. Currently it can be an option only on Linux and Mac. Windows requires art to build. -Brad From robin.cornelius at gmail.com Thu Apr 23 09:58:35 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 23 Apr 2009 17:58:35 +0100 Subject: [sldev] Easy build/Artwork tarball distribution In-Reply-To: <49F09927.60607@kitware.com> References: <49F09927.60607@kitware.com> Message-ID: On Thu, Apr 23, 2009 at 5:36 PM, Brad King wrote: > > I was not aware of this goal when I made the changes. Its probably not an official goal, just something that is very handy. > This is why I thought the artwork was required. ?It is on windows. > >> I can quite easily add a cmake option to not error out when the >> artwork is not present, which i will do anyway and attach to a JIRA. > > I already have some changes along these lines underway. ?Currently it > can be an option only on Linux and Mac. ?Windows requires art to build. Ah ok cool. that would be great. The old way use to print a warning that the artwork was not available, but I wonder if this should be a specific flag passed to cmake as its a specialized requirement and probably not something most people would want to do Thanks Robin From brad.king at kitware.com Thu Apr 23 10:29:08 2009 From: brad.king at kitware.com (Brad King) Date: Thu, 23 Apr 2009 13:29:08 -0400 Subject: [sldev] Easy build/Artwork tarball distribution In-Reply-To: References: <49F09927.60607@kitware.com> Message-ID: <49F0A564.5060507@kitware.com> Robin Cornelius wrote: > On Thu, Apr 23, 2009 at 5:36 PM, Brad King wrote: >> I already have some changes along these lines underway. Currently it >> can be an option only on Linux and Mac. Windows requires art to build. > > Ah ok cool. that would be great. The old way use to print a warning > that the artwork was not available, but I wonder if this should be a > specific flag passed to cmake as its a specialized requirement and > probably not something most people would want to do I created an ARTWORK_REQUIRED option that appears when artwork is missing but it is possible to build without it: Optionally build without artwork if possible http://svn.secondlife.com/trac/linden/changeset/2155/projects/2009/easybuild You can set it to OFF to build without artwork. -Brad From robla at lindenlab.com Thu Apr 23 16:23:27 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 23 Apr 2009 16:23:27 -0700 Subject: [sldev] 1.23 source publishing snafu Message-ID: <49F0F86F.6010905@lindenlab.com> Hi folks, We thought 1.23 viewer source was being published, but after investigation, it appears we misconfigured the build machine (that handles the source pushes). Since it wasn't configured to push, we weren't getting errors, and those of you poor souls thinking that you were working with 1.23 source code were getting something else. We're really sorry. Due to the timing figuring this out, it may be tomorrow before the source push happens, but I'm guessing we'll get it sometime tomorrow. With any luck, the merged http-texture/1.23 code will go out later today. Rob From carlo at alinoe.com Thu Apr 23 16:41:45 2009 From: carlo at alinoe.com (Carlo Wood) Date: Fri, 24 Apr 2009 01:41:45 +0200 Subject: [sldev] openjpeg bug on 64bit In-Reply-To: <20090406175534.GA7852@alinoe.com> References: <20090406175534.GA7852@alinoe.com> Message-ID: <20090423234145.GA24850@alinoe.com> Heya Callum, I never saw a reply to this - neither, here in my Inbox or on the openjpeg website. I assumed you were on a holiday or something, but it has been almost 3 weeks now. On Mon, Apr 06, 2009 at 07:55:34PM +0200, Carlo Wood wrote: > Hey Callum, > > can you have a look at this bug and write a patch for it? > http://groups.google.com/group/openjpeg/browse_thread/thread/4683bba9660c2779 -- Carlo Wood From robla at lindenlab.com Thu Apr 23 16:58:12 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Thu, 23 Apr 2009 16:58:12 -0700 Subject: [sldev] Developers at SLCC? Message-ID: <49F10094.9060509@lindenlab.com> Hi folks, You might have seen the location of SLCC has been announced (San Francisco): http://www.slconvention.org/ Seems like we should hold a BOF or generally get the developer here together if there's going to be a lot of you there. Also, we're starting to plan for the the Hippo Awards this year. So, I'm particularly interested in hearing from you if you a) have contributed a patch to the viewer in the past, and/or b) were a nominee in past years and/or c) feel you'll generally qualify for an award in some other area (e.g. documentation). If that's the case, I'm also very interested in hearing if you are *not* planning on going to SLCC. Please reply to me privately on this one if you're just replying about your personal status. If someone wants to coordinate a BOF on the wiki or elsewhere, feel free to reply on list. Thanks Rob From gareth at garethnelson.com Fri Apr 24 02:13:12 2009 From: gareth at garethnelson.com (Gareth Nelson) Date: Fri, 24 Apr 2009 10:13:12 +0100 Subject: [sldev] 1.23 source publishing snafu In-Reply-To: <49F0F86F.6010905@lindenlab.com> References: <49F0F86F.6010905@lindenlab.com> Message-ID: <4ebfc1100904240213q46d49da0pdd5c4d87cf0c3f0d@mail.gmail.com> Will there ever be a chance of having direct access to the internal SVN server so we can see single changes? I know that you keep the server source in the same tree, so perhaps this could be done by moving llcommon/llmath/llprimitive etc into a seperate repo and using SVN externals - 5 minute job. On Fri, Apr 24, 2009 at 12:23 AM, Rob Lanphier wrote: > Hi folks, > > We thought 1.23 viewer source was being published, but after > investigation, it appears we misconfigured the build machine (that > handles the source pushes). ?Since it wasn't configured to push, we > weren't getting errors, and those of you poor souls thinking that you > were working with 1.23 source code were getting something else. > > We're really sorry. ?Due to the timing figuring this out, it may be > tomorrow before the source push happens, but I'm guessing we'll get it > sometime tomorrow. > > With any luck, the merged http-texture/1.23 code will go out later today. > > Rob > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > -- ?Lanie, I?m going to print more printers. Lots more printers. One for everyone. That?s worth going to jail for. That?s worth anything.? - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html From alissa_sabre at yahoo.co.jp Fri Apr 24 04:09:19 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sabre) Date: Fri, 24 Apr 2009 20:09:19 +0900 Subject: [sldev] easybuild branch In-Reply-To: <49ECC303.8080607@kitware.com> References: <49ECC303.8080607@kitware.com> Message-ID: <1du9dx46QYPQJ9G5ch7m4L.alissa_sabre@yahoo.co.jp> Hmm. Easy build sounded a good direction at its first place, but reading the message from Brad makes me worry ... > So far most of the changes have been for delaying download of prebuilt > binaries to build time. I'm not sure my environment is typical or unusual, but my main development machines are not online (i.e., disconnected from Internet) usually. I connect those machines only when necessary. In a past, my practice was something like: download necessary files with another machine and copy those files to main development machine locally. These days, however, I need to connect my main development machine to internet when running develop.py. I have a feeling you are making things worse, i.e., I would need to connect my main development machine whenever I build... What is the primary reason of this change? What advantage does the new scheme have over the current one? > (building without flex/bison). This sounds good, especially I'm still having a bison related issue on MacOS. I'm afraid, however, that this change makes it difficult to modify .y and/or .lex files. Hope your change actually means "flex/bison are not needed unless the builder changed .y/.flex files, and if she/he changed, flex/bison runs automatically to update generated .cpp/.hpp files." # Am I hoping too much? > We've already planned enhancements to CMake's > command-line usability for a later phase of this effort. This includes > project-specific command-line options like --standalone. So, you are changing CMake itself? Great! Following is a list of my own wishes on CMake improvement that I believe facilitte SL development: Proper handling of platform-specific file system features. E.g., on MacOS, a mount point for Windows (SMB/CIFS) file server has a semicolon (;) character embedded in it, but the current CMake can't handle such full-path name. Or, on Windows, file names are case insensitive but CMake seems file names case sensitive ways, causing trouble if the SL source files are placed in a lo0cation whose full-pathname contains upper-case letters. Moreover, in some non-US versions of Windows, users' home folers contain non-ASCII characters as default, and the fact makes CMake behave worse. Avoid coding full-paths and options on Linux. I have a feeling that CMake likes to embed full-paths to, e.g., compilers and other tools or fully expanded command line options to the build tools in the generated makefile's It is against the well-accepted conventions. Instead, the makefiles should refer to standard make variables, e.g., CXX, AR, CXXFLAGS, LDFLAGS, etc. One of the negative effect of this seems that we need to decide whether use or don't use distcc upon running develop.py, and if we change it after that, all source fikes are compiled again from the beginning. I hope it is not the case in the new easybuild. Fine build dependency. I also have a feeling, although not sure, that the CMake generated build files contain unnecessary build dependencies. A significant effect of this is tyhat, when any of the library subprojects failed to build, any source files in the newview directory are not compileed and the build process stops. Because those libraries are only needed upon linkage, steps before linkage should happen. Another observation is that when modifying a header file in a library subproject, a lot of source files that doesn't use the modified header file are re-compileed. It greately slows down development iteration on my poor development machine. > > 2) There is a subtle change to the develop.py on that branch, it > > passes the standalone parameter to cmake for both the build and > > configure stages (but with the approprate ON/OFF flag set). What this > > means in practice (which i panicked over) is that > > > > /develop.py --standalone > > /develop.py build > > > > will no longer work, the build stage will start to download prebuilt > > packages., because the build call to develop.py has an implicit > > STANDALONE:BOOL=FALSE, What this needs to be is now :- > > > > /develop.py --standalone > > /develop.py --standalone build > > I've made no changes to develop.py, and it looks identical to that on > trunk and http-texture. Can you provide more detail, please? I believe this happens on 1.22 and on trunk. So this issue should be unrelated to easybuild. A related _wish_ to easybuild is a co-existance of standalone and non-standalone build directory based on a single source tree. Currently, develop.py creates build directory of the same name regardless it is standalone or not, so I need to have two separate copies of source files to test both standealone and non-standalone builds on one Linux PC. Moreover, "develop.py --standalone configure" downloads prebuilt files into "library" directory just next to "indra" directory, and existance of prebuild header/libraries files there seems affects behaviour on standalone build files. It is problematic. Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From chaosstar at gmail.com Fri Apr 24 04:29:59 2009 From: chaosstar at gmail.com (Ambrosia) Date: Fri, 24 Apr 2009 13:29:59 +0200 Subject: [sldev] Vivox and Kakadu licensing issues. Message-ID: <9bb32d430904240429y50fc8e9av648f57898b310dc9@mail.gmail.com> Greetings! This hasn't let go of me all day, and I hope to find some enlightenment here about the issue. As often repeated, and stated on the wiki (by a third party), the lib Kakadu and the Vivox components of the SL viewer can not be freely distributed in 3rd party clients. Now, an issue with a 3rd party client has come up where this is being questioned I investigated some, and interestingly enough I can not find any licensing information specific to the Vivox components. The license file lists all the opensource libraries (including GPLd ones) that are used in the vivox SDK and tech, but I cannot find any info about the vivoxsdk.dll itself of the slvoice.exe licensing at all. Going purely by the licenses listed in the .txt file that comes with the viewer (and the vivox library download in the install.xml), the components are distributable..but as I said. It's a very confusing setup of licenses mostly referring to 3rd party tech used. Similiarly, somebody claims that according to the license at http://www.kakadusoftware.com/Downloads.html ('You are free to play around with these executables and even to re-distribute them, so long as such use or re-distribution is accompanied this copyright notice and is not for commercial gain.') the full kakadu library included in the download is free for distribution in non-commercial software, yet in my opinion this only applies to the actual exe files in the package. Does anybody have any insight into this? Maybe a Linden dev, by chance? It's causing alot of controversity about the client in question. From brad.king at kitware.com Fri Apr 24 06:33:06 2009 From: brad.king at kitware.com (Brad King) Date: Fri, 24 Apr 2009 09:33:06 -0400 Subject: [sldev] easybuild branch In-Reply-To: <1du9dx46QYPQJ9G5ch7m4L.alissa_sabre@yahoo.co.jp> References: <49ECC303.8080607@kitware.com> <1du9dx46QYPQJ9G5ch7m4L.alissa_sabre@yahoo.co.jp> Message-ID: <49F1BF92.9060909@kitware.com> Alissa Sabre wrote: >> So far most of the changes have been for delaying download of prebuilt >> binaries to build time. > > I'm not sure my environment is typical or unusual, but my main > development machines are not online (i.e., disconnected from Internet) > usually. I connect those machines only when necessary. In a past, my > practice was something like: download necessary files with another > machine and copy those files to main development machine locally. > These days, however, I need to connect my main development machine to > internet when running develop.py. I have a feeling you are making > things worse, i.e., I would need to connect my main development > machine whenever I build... If the files are up to date it should see them in your download cache and not actually touch the network. You only need to be connected for the initial build, and then only for building the 'prepare' target. > What is the primary reason of this change? What advantage does the new > scheme have over the current one? Previously the initial run of CMake took a long time before one could interactively change any options. Now it is really fast, and all the long stuff is delayed until build time which does not require further interaction. >> (building without flex/bison). > > This sounds good, especially I'm still having a bison related issue on > MacOS. I'm afraid, however, that this change makes it difficult to > modify .y and/or .lex files. Hope your change actually means > "flex/bison are not needed unless the builder changed .y/.flex files, > and if she/he changed, flex/bison runs automatically to update > generated .cpp/.hpp files." > > # Am I hoping too much? If you have flex and bison installed then it will use them and generate the files. This makes interactive development easy. Before committing, though, one needs to manually run flex and bison using the instructions in comments at the top of the sources. One must commit the input files and output files at the same time. Otherwise if a user builds without flex or bison he/she will get an out-of-date parser. This extra effort for the developer is traded for simplifying the build for users. Dropping cygwin as a dependency of windows builds is a win. >> We've already planned enhancements to CMake's >> command-line usability for a later phase of this effort. This includes >> project-specific command-line options like --standalone. > > So, you are changing CMake itself? Great! We plan to make a few tweaks to CMake's interface, mainly to ease command-line usage. The issues you raise below are out of the scope of this effort. I'll briefly comment on them, but this is not the place for full discussion of CMake-specific topics. > Following is a list of my own wishes on CMake improvement that I > believe facilitte SL development: > > Proper handling of platform-specific file system features. E.g., on > MacOS, a mount point for Windows (SMB/CIFS) file server has a > semicolon (;) character embedded in it, but the current CMake can't > handle such full-path name. The CMake language use ';' as a list separator. This cannot be addressed without major fundamental changes that are incompatible. > Or, on Windows, file names are case > insensitive but CMake seems file names case sensitive ways, causing > trouble if the SL source files are placed in a lo0cation whose > full-pathname contains upper-case letters. My Second Life sources are in ".../My Programs/SecondLife/linden" on windows and it works fine. > Avoid coding full-paths and options on Linux. I have a feeling that > CMake likes to embed full-paths to, e.g., compilers and other tools or > fully expanded command line options to the build tools in the > generated makefile's Changing compilers in an existing build tree is not a case we optimize. If one does change the compiler, everything needs to rebuild because CMake cannot be sure the new compiler provides an identical ABI. That's why we support out-of-source builds. Just create as many build trees as you have compilers, and you never need to change compilers in an existing build tree. > Fine build dependency. I also have a feeling, although not sure, that > the CMake generated build files contain unnecessary build > dependencies. A significant effect of this is tyhat, when any of the > library subprojects failed to build, any source files in the newview > directory are not compileed and the build process stops. Because > those libraries are only needed upon linkage, steps before linkage > should happen. CMake takes a conservative approach here. It is possible that one of the libraries to which an executable links contains a custom command to generate a header file that will be included by some of the executable's source files. If the library has not finished building before we start to compile the executable's sources then the header may be missing or out of date. I suggest running 'make -i' to ask make to keep going despite failures. > Another observation is that when modifying a header > file in a library subproject, a lot of source files that doesn't use > the modified header file are re-compiled. I'll be surprised if this is the case. Next time it happens, try preprocessing the object that you don't think should have rebuilt to see if it uses the modified header. You can also run "make -d" to see why it decides to rebuild something. > A related _wish_ to easybuild is a co-existance of standalone and > non-standalone build directory based on a single source tree. This is a develop.py limitation. CMake has full support for truly out-of-source builds. Just create your own build trees and run CMake directly. -Brad From lists.secondlife.com at trap.wereanimal.net Fri Apr 24 06:45:27 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Fri, 24 Apr 2009 09:45:27 -0400 Subject: [sldev] Community QA process In-Reply-To: References: <49EF64AF.6070601@lindenlab.com> <48C4E81B-9BED-4707-B939-E57472F7A352@lindenlab.com> Message-ID: <200904240945.28093.lists.secondlife.com@trap.wereanimal.net> On Thursday 23 April 2009 11:53:58 am Robin Cornelius wrote: > > I think also we need to monitor the crash rate and the bug reports > coming in. In theory once all bugs of a certain severity or greater > are tackled and the crash rate has reached an appropriate lull we can > declare "good enough". Really incomming crash reports should be > opening new pJIRAs so as we don't have data from this side of the > firewall, would be good to have someone from LL open them with the > stack traces and some indication of volume so this can be used to > judge severity. This should cause a feedback loop that the output of > can be used to flip the go switch. > How does on enter a crash report on the pjira? I've tried a while back to report one of thousand of random crashes everyone is complaining about and got chew out for reporting it. Is there a guide for posting gdb bt to the pjira? What gdb commands output would the programmers like to see? --Techwolf Lupindo From sllists at boroon.dasgupta.ch Fri Apr 24 08:49:00 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 24 Apr 2009 17:49:00 +0200 Subject: [sldev] Semicolons and CMake (was: easybuild branch) In-Reply-To: <49F1BF92.9060909@kitware.com> References: <49ECC303.8080607@kitware.com> <1du9dx46QYPQJ9G5ch7m4L.alissa_sabre@yahoo.co.jp> <49F1BF92.9060909@kitware.com> Message-ID: <49F1DF6C.1090800@boroon.dasgupta.ch> Brad King schrieb: > Alissa Sabre wrote: > > Following is a list of my own wishes on CMake improvement that I > > believe facilitte SL development: > >> Proper handling of platform-specific file system features. E.g., on >> MacOS, a mount point for Windows (SMB/CIFS) file server has a >> semicolon (;) character embedded in it, but the current CMake can't >> handle such full-path name. >> > > The CMake language use ';' as a list separator. This cannot be > addressed without major fundamental changes that are incompatible. Can't this be solved by quoting or escaping as explained at: http://www.cmake.org/Wiki/CMake/Language_Syntax#CMake_splits_arguments_unless_you_use_quotation_marks_or_escapes. ? cheers Boroondas From brad.king at kitware.com Fri Apr 24 08:55:22 2009 From: brad.king at kitware.com (Brad King) Date: Fri, 24 Apr 2009 11:55:22 -0400 Subject: [sldev] Semicolons and CMake In-Reply-To: <49F1DF6C.1090800@boroon.dasgupta.ch> References: <49ECC303.8080607@kitware.com> <1du9dx46QYPQJ9G5ch7m4L.alissa_sabre@yahoo.co.jp> <49F1BF92.9060909@kitware.com> <49F1DF6C.1090800@boroon.dasgupta.ch> Message-ID: <49F1E0EA.80004@kitware.com> Boroondas Gupte wrote: > Brad King schrieb: >> Alissa Sabre wrote: >> > Following is a list of my own wishes on CMake improvement that I >> > believe facilitte SL development: >> >>> Proper handling of platform-specific file system features. E.g., on >>> MacOS, a mount point for Windows (SMB/CIFS) file server has a >>> semicolon (;) character embedded in it, but the current CMake can't >>> handle such full-path name. >>> >> The CMake language use ';' as a list separator. This cannot be >> addressed without major fundamental changes that are incompatible. > Can't this be solved by quoting or escaping as explained at: > http://www.cmake.org/Wiki/CMake/Language_Syntax#CMake_splits_arguments_unless_you_use_quotation_marks_or_escapes. > ? Unfortunately that only works for one layer. Whenever CMake computes a list to store in a string it just slaps together the values with ';' and does not re-escape any semicolons in the values. This mistake was made very early and now there is a large base of code that depends on it. At the time it was made we didn't care about ';' in path names because Windows uses it as a separator too. -Brad From gigstaggart at gmail.com Fri Apr 24 09:17:10 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri, 24 Apr 2009 12:17:10 -0400 Subject: [sldev] Community QA process In-Reply-To: <200904240945.28093.lists.secondlife.com@trap.wereanimal.net> References: <49EF64AF.6070601@lindenlab.com> <48C4E81B-9BED-4707-B939-E57472F7A352@lindenlab.com> <200904240945.28093.lists.secondlife.com@trap.wereanimal.net> Message-ID: <49F1E606.7090903@gmail.com> GDB Backtrace on an *unstripped* binary, along with a little about what you were doing when it happened, is probably enough info to fix 80% of the bugs. What I do to make an unstripped binary is to change the strip command in the makefiles to a cp command. This way I know it's exactly the same build, just unstripped. Which bug did you get chewed out on? -Jason lists.secondlife.com at trap.wereanimal.net wrote: > How does on enter a crash report on the pjira? I've tried a while back to > report one of thousand of random crashes everyone is complaining about and got > chew out for reporting it. > > Is there a guide for posting gdb bt to the pjira? What gdb commands output > would the programmers like to see? > > --Techwolf Lupindo From gigstaggart at gmail.com Fri Apr 24 09:23:11 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Fri, 24 Apr 2009 12:23:11 -0400 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904240429y50fc8e9av648f57898b310dc9@mail.gmail.com> References: <9bb32d430904240429y50fc8e9av648f57898b310dc9@mail.gmail.com> Message-ID: <49F1E76F.40109@gmail.com> Ambrosia wrote: > Does anybody have any insight into this? Maybe a Linden dev, by > chance? It's causing alot of controversity about the client in > question. Yes. It doesn't really matter what the license for KDU is. The fact that it is closed source means that it is impossible to comply with the GPL while linking it, so therefore it is forbidden to distribute a client that includes KDU, unless you are Linden Lab, or have a license from Linden Lab other than the GPL. For Vivox, since it is not directly linked, it might be OK to distribute without violating the GPL, if Vivox were to allow it to be distributed. They haven't, though. -Jason From merov at lindenlab.com Fri Apr 24 14:34:56 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 24 Apr 2009 14:34:56 -0700 Subject: [sldev] http-texture branch Message-ID: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com> Hi guys, We've been working on a merge of our http-texture code with the 1.23 code base. We finally landed the whole thing in the "branches" repo (svn r2162 in branches/2009/http-texture) and I'm currently doing a merge on my "projects" working copy (i conflict to resolve). I should be making a commit to that projects branch tonight (projects/2009/http- texture). The objective of that merge is to bring some stability to the branch (1.23 is way more stable than trunk as it includes a bunch of fixes for crashers that are plaguing the version of the trunk http-texture is base upon). The PJIRA tracker for that task is: https://jira.secondlife.com/browse/VWR-12929 Howler if there's something with that operation you object to. Cheers, - Merov From lists.secondlife.com at trap.wereanimal.net Fri Apr 24 15:01:47 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Fri, 24 Apr 2009 18:01:47 -0400 Subject: [sldev] Community QA process In-Reply-To: <49F1E606.7090903@gmail.com> References: <49EF64AF.6070601@lindenlab.com> <200904240945.28093.lists.secondlife.com@trap.wereanimal.net> <49F1E606.7090903@gmail.com> Message-ID: <200904241801.47517.lists.secondlife.com@trap.wereanimal.net> On Friday 24 April 2009 12:17:10 pm Jason Giglio wrote: > GDB Backtrace on an *unstripped* binary, along with a little about what > you were doing when it happened, is probably enough info to fix 80% of > the bugs. > Due to a bug in the cmake build system, the strippped binary is not created, so I move the non-stripped binary over and rename it to stripped to fool viewer_manifest.py to finished its install and let portage do the split-debug install. My entire system is split-debug, so when I do a bt, it goes all the way back. I also use -ggdb in make.conf A small sample is at http://pastebin.com/mf69469b --Techwolf Lupindo From lists.secondlife.com at trap.wereanimal.net Fri Apr 24 15:05:26 2009 From: lists.secondlife.com at trap.wereanimal.net (lists.secondlife.com at trap.wereanimal.net) Date: Fri, 24 Apr 2009 18:05:26 -0400 Subject: [sldev] http-texture branch In-Reply-To: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com> References: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com> Message-ID: <200904241805.26410.lists.secondlife.com@trap.wereanimal.net> On Friday 24 April 2009 5:34:56 pm Philippe Bossut (Merov Linden) wrote: > Hi guys, > > We've been working on a merge of our http-texture code with the 1.23 > code base. We finally landed the whole thing in the "branches" repo > (svn r2162 in branches/2009/http-texture) and I'm currently doing a > merge on my "projects" working copy (i conflict to resolve). I should > be making a commit to that projects branch tonight (projects/2009/http- > texture). > Witch one should we be testing? branches or projects? And why two of the same project? --Techwolf Lupindo From merov at lindenlab.com Fri Apr 24 15:36:41 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 24 Apr 2009 15:36:41 -0700 Subject: [sldev] http-texture branch In-Reply-To: <200904241805.26410.lists.secondlife.com@trap.wereanimal.net> References: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com> <200904241805.26410.lists.secondlife.com@trap.wereanimal.net> Message-ID: <2A947AA4-63AE-4153-987E-EA13FD72163A@lindenlab.com> Hi Techwolf, On Apr 24, 2009, at 3:05 PM, lists.secondlife.com at trap.wereanimal.net wrote: > Witch one should we be testing? branches or projects? We should be testing projects and developing in projects. Always. Projects is what we do and test and breathe. > And why two of the same project? "branches" is the parking repository for the "vendor" version, the code that gets exported by LL into the OSS realm. That's where code lands when they throw it over the wall (I'm being facetious here with my use of vocabulary and, in that particular instance, that's me throwing code over the wall). We (as open source developers) are not supposed to modify branches ever. They are sacred and represent what comes from Lindens. We build it though to make sure it's not evil, that our changes don't get stomped by Linden updates and that we like it enough to merge it into our projects. Makes sense? Cheers, - Merov From merov at lindenlab.com Fri Apr 24 17:30:50 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Fri, 24 Apr 2009 17:30:50 -0700 Subject: [sldev] http-texture branch In-Reply-To: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com> References: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com> Message-ID: <6382D957-8E98-4B29-87E2-49D2BF1EFA06@lindenlab.com> Hi, OK, I went ahead with that and committed the code. It's building right now and it'll take a couple of hours before it clears the 3 platforms. So, what you need to know: - if you're building that baby (/branches/2009/http-texture) be aware that r2166 is that new svn revision - it's a merge of 1.23 and http-texture - it's more stable than previous http-texture builds: my next tasks will be to regress those crashers, mark fixed some that we suspect this merge will fix and finally fix the couple fetch related ones we have - the map is still as fast as the previous http-texture (w00t!) For more of what's the short term plan is on that release, check out: https://wiki.secondlife.com/wiki/HTTP_Texture_Development Cheers, - Merov On Apr 24, 2009, at 2:34 PM, Philippe Bossut (Merov Linden) wrote: > Hi guys, > > We've been working on a merge of our http-texture code with the 1.23 > code base. We finally landed the whole thing in the "branches" repo > (svn r2162 in branches/2009/http-texture) and I'm currently doing a > merge on my "projects" working copy (i conflict to resolve). I should > be making a commit to that projects branch tonight (projects/2009/ > http- > texture). > > The objective of that merge is to bring some stability to the branch > (1.23 is way more stable than trunk as it includes a bunch of fixes > for crashers that are plaguing the version of the trunk http-texture > is base upon). The PJIRA tracker for that task is: > https://jira.secondlife.com/browse/VWR-12929 > > Howler if there's something with that operation you object to. > > Cheers, > - Merov > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges From robla at lindenlab.com Fri Apr 24 18:06:33 2009 From: robla at lindenlab.com (Rob Lanphier) Date: Fri, 24 Apr 2009 18:06:33 -0700 Subject: [sldev] A brief history lesson on our branches (Re: http-texture branch) In-Reply-To: <2A947AA4-63AE-4153-987E-EA13FD72163A@lindenlab.com> References: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com><200904241805.26410.lists.secondlife.com@trap.wereanimal.net> <2A947AA4-63AE-4153-987E-EA13FD72163A@lindenlab.com> Message-ID: <49F26219.4070803@lindenlab.com> Hi folks, I'm not sure if this message is going to make it easier or harder to decipher what the difference between these branches are, but I'll give it a shot. I'd document this on the wiki, but I'm hoping this will be a temporary state of affairs, and we'll be able to set things up a little more clearly after we announce the name for the new project (more on that later...) Here's a condensed history of how things went down, with some simplifications to avoid making it too complicated. When we first set up the Subversion repository, there was only source pushes. My thought at the time was that mirroring our internal structure exactly would ease a transition from inside the firewall development to outside the firewall development. So, what you see is we have "trunk" and we've got "branches". We then realized that there was no safe place for external contributors to commit, because commits would get stomped by our export scripts. So we created the (now pretty much dormant) "sandbox" area as an experiment, that was cordoned off from being stomped on by the exporter. Later on, we wanted to have a more serious project that was more of a shared effort that we were conducting with an external vendor in the public repository, so we created the "projects" area. Like I said earlier, hopefully we'll be able to make things clearer once we have a project name we can emblazon all over everything (I'm guessing we'll at least create a new top level project that isn't "linden", for example, but that's just my wild Friday afternoon crazy talk). Some enterprising soul may want to update this page to reflect the new world order, since it's been a while since its seen an update: https://wiki.secondlife.com/wiki/Source_branches (bearing in mind that things may change again when we have a project name) Anyway, sorry for the confusion, and I hope this helps. Rob p.s. I'll be out on vacation next week, so while I'll be on email for some of it, probably not too responsive here. Have a great weekend...talk to you all when I'm back On 4/24/09 3:36 PM, Philippe Bossut (Merov Linden) wrote: > Hi Techwolf, > > On Apr 24, 2009, at 3:05 PM, lists.secondlife.com at trap.wereanimal.net > wrote: > >> Witch one should we be testing? branches or projects? >> > > We should be testing projects and developing in projects. Always. > Projects is what we do and test and breathe. > > >> And why two of the same project? >> > > "branches" is the parking repository for the "vendor" version, the > code that gets exported by LL into the OSS realm. That's where code > lands when they throw it over the wall (I'm being > facetious here with my use of vocabulary and, in that particular > instance, that's me throwing code over the wall). We (as > open source developers) are not supposed to modify branches ever. They > are sacred and represent what comes from Lindens. We build it though > to make sure it's not evil, that our changes don't get stomped by > Linden updates and that we like it enough to merge it into our projects. > > Makes sense? > > Cheers, > - Merov > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From boy.lane at yahoo.com Fri Apr 24 20:12:18 2009 From: boy.lane at yahoo.com (Boy Lane) Date: Sat, 25 Apr 2009 11:12:18 +0800 Subject: [sldev] Vivox and Kakadu licensing issues. References: Message-ID: <001501c9c553$a59172e0$6500a8c0@hp> Hi Gigs/Jason :) This doesn't really make sense as both are dynamically linked and not required to run the client. The issue in question was the following posting of the person claiming he has the right to distribute KDU/Vivox (I don't mention names but you probably know who it is ;)): "http://www.kakadusoftware.com/Downloads.html read :Copyright is owned by NewSouth Innovations Proprietary Ltd, commercial arm of the University of New South Wales, Sydney, Australia. You are free to play around with these executables and even to re-distribute them, so long as such use or re-distribution is accompanied this copyright notice and is not for commercial gain. Note: Binaries can only be used for non-commercial purposes. If in doubt please contact Dr. Taubman. and voice.... * The Vovida Software License, Version 1.0 * * Copyright (c) 2000 Vovida Networks, Inc. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in * the documentation and/or other materials provided with the * distribution." We would really need someone from LL to shed some light on this because either a) that "person" is distributing software components unlicensed or b) 3rd party builds may include those components legallay ok. Boy > Ambrosia wrote: >> Does anybody have any insight into this? Maybe a Linden dev, by >> chance? It's causing alot of controversity about the client in >> question. > > Yes. It doesn't really matter what the license for KDU is. > > The fact that it is closed source means that it is impossible to comply > with the GPL while linking it, so therefore it is forbidden to > distribute a client that includes KDU, unless you are Linden Lab, or > have a license from Linden Lab other than the GPL. > > For Vivox, since it is not directly linked, it might be OK to distribute > without violating the GPL, if Vivox were to allow it to be distributed. > They haven't, though. > > -Jason From teravus at gmail.com Fri Apr 24 21:50:16 2009 From: teravus at gmail.com (Teravus Ovares) Date: Sat, 25 Apr 2009 00:50:16 -0400 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <001501c9c553$a59172e0$6500a8c0@hp> References: <001501c9c553$a59172e0$6500a8c0@hp> Message-ID: <34cc66250904242150r145bad4aj2ce00cd926076a00@mail.gmail.com> As far as vivox, you might want to take a look at the open vivox initiative http://www.vivox.com/open/ (part of the open vivox faq) http://www.vivox.com/open/faq.php Can I distribute this to friends? No, currently Vivox software and service is offered for individual, non-commercial use only. Additionally, this seems more like a licensing debate then a technical one. We probably want to stay on the technical discussions. Regards Teravus On 4/24/09, Boy Lane wrote: > Hi Gigs/Jason :) > > This doesn't really make sense as both are dynamically linked and not > required to run the client. > > The issue in question was the following posting of the person claiming he > has the right to distribute KDU/Vivox (I don't mention names but you > probably know who it is ;)): > > "http://www.kakadusoftware.com/Downloads.html > > read :Copyright is owned by NewSouth Innovations Proprietary Ltd, commercial > arm of the University of New South Wales, Sydney, Australia. You are free to > play around with these executables and even to re-distribute them, so long > as such use or re-distribution is accompanied this copyright notice and is > not for commercial gain. Note: Binaries can only be used for non-commercial > purposes. If in doubt please contact Dr. Taubman. > > and voice.... > > * The Vovida Software License, Version 1.0 > * > * Copyright (c) 2000 Vovida Networks, Inc. All rights reserved. > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * > * 1. Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * > * 2. Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in > * the documentation and/or other materials provided with the > * distribution." > > We would really need someone from LL to shed some light on this because > either > a) that "person" is distributing software components unlicensed or > b) 3rd party builds may include those components legallay ok. > > Boy > > > > > Ambrosia wrote: > >> Does anybody have any insight into this? Maybe a Linden dev, by > >> chance? It's causing alot of controversity about the client in > >> question. > > > > Yes. It doesn't really matter what the license for KDU is. > > > > The fact that it is closed source means that it is impossible to comply > > with the GPL while linking it, so therefore it is forbidden to > > distribute a client that includes KDU, unless you are Linden Lab, or > > have a license from Linden Lab other than the GPL. > > > > For Vivox, since it is not directly linked, it might be OK to distribute > > without violating the GPL, if Vivox were to allow it to be distributed. > > They haven't, though. > > > > -Jason > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From robin.cornelius at gmail.com Sat Apr 25 01:50:12 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Sat, 25 Apr 2009 09:50:12 +0100 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <34cc66250904242150r145bad4aj2ce00cd926076a00@mail.gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <34cc66250904242150r145bad4aj2ce00cd926076a00@mail.gmail.com> Message-ID: <49F2CEC4.9010408@gmail.com> Teravus Ovares wrote: > As far as vivox, you might want to take a look at the open vivox initiative > http://www.vivox.com/open/ > > (part of the open vivox faq) http://www.vivox.com/open/faq.php > > Can I distribute this to friends? > No, currently Vivox software and service is offered for individual, > non-commercial use only. Can i ask that *anyone* interested in 1) redistributing the vivox binaries 2) wants to see vivox moving down the open source road contacts vivox via the vivox open links and mailing list and expresses some interest, esp viewer distributors/custom builders who want to ship the vivox binaries. I have been talking to vivox for a while about these subjects and although i have nothing to directly report, they are in dialogue. So if others expressed an interest in the 2 above points it will greatly help the cause. Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090425/8abc33d7/attachment-0001.pgp From carlo at alinoe.com Sat Apr 25 04:46:42 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 25 Apr 2009 13:46:42 +0200 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <49F2CEC4.9010408@gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <34cc66250904242150r145bad4aj2ce00cd926076a00@mail.gmail.com> <49F2CEC4.9010408@gmail.com> Message-ID: <20090425114642.GA8391@alinoe.com> I understood that vivox is making their money with a contract with Linden Lab which includes that they (vivox) run the voice servers. This might (even) mean that Linden people can't really comment on this (ie, revealing a loophole, or whatever). It also means that vivox can't care less who has their libraries as long as: 1) They get paid more or less per customer using their bandwidth 2) Their business isn't put in danger by opening up the source code used. It would be my guess that if they make the libraries distributable then they think they lose overview of how many people are actually using it - or they are afraid that, for example, people start using their voice servers that do not actually use SL (opensims, or any other grid) and hence are not paid for (by LL). However, if that is the case then they are using some very weak 'security by obscurity' model to regulate the number of people that use their servers. It seems unlikely (by then again, I don't know the protocol-- so I wouldn't know how easy it is to start using the vivox servers for some opensim grid). Point 2 seems more valid; once the protocol and source are open it's just a matter of time till someone implements the server side as well (see opensim) and start to use cheap(er) servers/bandwidth. Normally they would only agree to open the source code if by NOT doing so they will lose LL as client. In other words, we need to start looking for alternatives before they'll ever GPL it. HOWEVER -- since the vivox library isn't linked with the viewer, there is no GPL/whatever incompatibility and there is no NEED to make the vivox libraries open source. Hence, the only reason vivox can have imho is point 1. If they have a contract with LL for a fixed price (not directly related to the actual bandwidth being used), or if they get paid per copy of the library, then that is the reason they are not interested to make their code freely distributable. On Sat, Apr 25, 2009 at 09:50:12AM +0100, Robin Cornelius wrote: > Can i ask that *anyone* interested in > > 1) redistributing the vivox binaries > 2) wants to see vivox moving down the open source road > > contacts vivox via the vivox open links and mailing list and expresses > some interest, esp viewer distributors/custom builders who want to ship > the vivox binaries. > > I have been talking to vivox for a while about these subjects and > although i have nothing to directly report, they are in dialogue. So if > others expressed an interest in the 2 above points it will greatly help > the cause. > > Robin > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges -- Carlo Wood From carlo at alinoe.com Sat Apr 25 05:08:56 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 25 Apr 2009 14:08:56 +0200 Subject: [sldev] Community QA process In-Reply-To: <49F1E606.7090903@gmail.com> References: <49EF64AF.6070601@lindenlab.com> <48C4E81B-9BED-4707-B939-E57472F7A352@lindenlab.com> <200904240945.28093.lists.secondlife.com@trap.wereanimal.net> <49F1E606.7090903@gmail.com> Message-ID: <20090425120856.GB8391@alinoe.com> On Fri, Apr 24, 2009 at 12:17:10PM -0400, Jason Giglio wrote: > GDB Backtrace on an *unstripped* binary, along with a little about what > you were doing when it happened, is probably enough info to fix 80% of > the bugs. I disagree. Most crashes happen in third party libraries. The crashes that last (that aren't already fixed) never happen in the location where the problem is. Problems might involve memory corruption (using freed objects, overflows), hardware specific or hard to reproduce external environment involvement (ie, someone using a bad internet connection; or a specific type of videocard), race conditions or other threading related issues, etc. None of those will be easy to fix with a backtrace. I've been collecting backtraces from my own crashes just to see if they happen in the same place (and in fact, most of my current crashes happen clearly at the moment that a media url is changed). So here isn't example (not reported, by me, before): When the media url is changed as a result of a teleport, entering a parcel or maybe by a script (didn't run into it yet when I did it manually), the viewer crashes with a backtrace like the following: #0 0x0000000000000000 in ?? () #1 0x00007f1a83962941 in g_object_notify () from /usr/lib/libgobject-2.0.so.0 #2 0x00007f1a605b9538 in ?? () from /usr/lib/gstreamer-0.10/libgstplaybin.so #3 0x00007f1a7f5edc98 in gst_marshal_BOOLEAN__POINTER (closure=0x57d7bf0, return_value=0x46a4abe0, n_param_values=, param_values=0x46a4ac50, invocation_hint=, marshal_data=0x7f1a605b9370) at gstmarshal.c:584 #4 0x00007f1a8395c11d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #5 0x00007f1a8396fd0d in ?? () from /usr/lib/libgobject-2.0.so.0 #6 0x00007f1a7f5b1628 in gst_pad_emit_have_data_signal (pad=, obj=0x4945f00) at gstpad.c:3830 #7 0x00007f1a7f5b1ee5 in gst_pad_push_event (pad=0x57b5da0, event=0x4945f00) at gstpad.c:4476 #8 0x00007f1a7f5b1a18 in gst_pad_send_event (pad=0x49f3d30, event=0x4945f00) at gstpad.c:4634 #9 0x00007f1a7f5b2038 in gst_pad_push_event (pad=0x590acf0, event=0x4945f00) at gstpad.c:4490 #10 0x00007f1a52cdc316 in ?? () from /usr/lib/gstreamer-0.10/libgstffmpeg.so #11 0x00007f1a7f5b1a18 in gst_pad_send_event (pad=0x590ab80, event=0x4945f00) at gstpad.c:4634 #12 0x00007f1a7f5b2038 in gst_pad_push_event (pad=0x590aa10, event=0x4945f00) at gstpad.c:4490 #13 0x00007f1a60179b79 in gst_queue_loop (pad=) at gstqueue.c:1093 #14 0x00007f1a7f5d56d6 in gst_task_func (task=0x5738030, tclass=) at gsttask.c:192 #15 0x00007f1a836ef387 in ?? () from /usr/lib/libglib-2.0.so.0 #16 0x00007f1a836eddf4 in ?? () from /usr/lib/libglib-2.0.so.0 #17 0x00007f1a824c8fc7 in start_thread () from /lib/libpthread.so.0 #18 0x00007f1a7d7845ad in clone () from /lib/libc.so.6 Now, if you think the 0x0000000000000000 at the top is significant, here is another: #0 0x00007f2623ae2513 in ?? () from /usr/lib/libgobject-2.0.so.0 #1 0x00007f2623ae4045 in g_object_set_valist () from /usr/lib/libgobject-2.0.so.0 #2 0x00007f2623ae4324 in g_object_set () from /usr/lib/libgobject-2.0.so.0 #3 0x00007f2600748090 in ?? () from /usr/lib/gstreamer-0.10/libgstplaybin.so #4 0x00007f2600748469 in ?? () from /usr/lib/gstreamer-0.10/libgstplaybin.so #5 0x00007f2600749a20 in ?? () from /usr/lib/gstreamer-0.10/libgstplaybin.so #6 0x00007f2623adf11d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #7 0x00007f2623af2d0d in ?? () from /usr/lib/libgobject-2.0.so.0 #8 0x00007f2623af41d8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #9 0x00007f2623af46d3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #10 0x00007f2623adf11d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 #12 0x00007f2623af41d8 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 #13 0x00007f2623af46d3 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 #14 0x00007f25f584f7e3 in ?? () from /usr/lib/gstreamer-0.10/libgstqtdemux.so #15 0x00007f25f5850fbf in ?? () from /usr/lib/gstreamer-0.10/libgstqtdemux.so #16 0x00007f261f7378e6 in gst_pad_chain_unchecked (pad=0x12b468a0, buffer=0x7f25cd58e6c0) at gstpad.c:3890 #17 0x00007f261f738bc3 in gst_pad_push (pad=0xd99a730, buffer=0x7f25cd58e6c0) at gstpad.c:4057 #18 0x00007f25fbdf10ff in gst_type_find_element_chain (pad=0xd99acf0, buffer=0x7f25cd58e6c0) at gsttypefindelement.c:623 #19 0x00007f261f7378e6 in gst_pad_chain_unchecked (pad=0xd99acf0, buffer=0x7f25cd58e6c0) at gstpad.c:3890 #20 0x00007f261f738bc3 in gst_pad_push (pad=0x12b763e0, buffer=0x7f25cd58e6c0) at gstpad.c:4057 #21 0x00007f261f7378e6 in gst_pad_chain_unchecked (pad=0x10ebdd80, buffer=0x7f25cd58e6c0) at gstpad.c:3890 #22 0x00007f261f738bc3 in gst_pad_push (pad=0x12b46170, buffer=0x7f25cd58e6c0) at gstpad.c:4057 #23 0x00007f2600f88431 in gst_base_src_loop (pad=0x12b46170) at gstbasesrc.c:2275 #24 0x00007f261f7586d6 in gst_task_func (task=0xbb38960, tclass=) at gsttask.c:192 #25 0x00007f2623872387 in ?? () from /usr/lib/libglib-2.0.so.0 #26 0x00007f2623870df4 in ?? () from /usr/lib/libglib-2.0.so.0 #27 0x00007f262264bfc7 in start_thread () from /lib/libpthread.so.0 #28 0x00007f261d9075ad in clone () from /lib/libc.so.6 Now you might think this is easy to fix if you look at the source code of the lines mentioned.. but I doubt that because this only happens sometimes - not every time. Although I'm running the viewer always in gdb, I didn't yet get to it to install *all* libraries involved in a debugable way :p I'm pretty sure 99.999% of the users will have libraries installed that give equal or less information. -- Carlo Wood From carlo at alinoe.com Sat Apr 25 05:10:53 2009 From: carlo at alinoe.com (Carlo Wood) Date: Sat, 25 Apr 2009 14:10:53 +0200 Subject: [sldev] Community QA process In-Reply-To: <200904241801.47517.lists.secondlife.com@trap.wereanimal.net> References: <49EF64AF.6070601@lindenlab.com> <200904240945.28093.lists.secondlife.com@trap.wereanimal.net> <49F1E606.7090903@gmail.com> <200904241801.47517.lists.secondlife.com@trap.wereanimal.net> Message-ID: <20090425121053.GC8391@alinoe.com> On Fri, Apr 24, 2009 at 06:01:47PM -0400, lists.secondlife.com at trap.wereanimal.net wrote: > install. My entire system is split-debug, so when I do a bt, it goes all the > way back. I also use -ggdb in make.conf Wow :p Make that 99.9% in my previous post - lol. I'm amazed! -- Carlo Wood From sllists at boroon.dasgupta.ch Sat Apr 25 07:00:24 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Sat, 25 Apr 2009 16:00:24 +0200 Subject: [sldev] A brief history lesson on our branches (Re: http-texture branch) In-Reply-To: <49F26219.4070803@lindenlab.com> References: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com><200904241805.26410.lists.secondlife.com@trap.wereanimal.net> <2A947AA4-63AE-4153-987E-EA13FD72163A@lindenlab.com> <49F26219.4070803@lindenlab.com> Message-ID: <49F31778.4040202@boroon.dasgupta.ch> Rob Lanphier schrieb: > Some enterprising soul may want to update this page to reflect the new > world order, since it's been a while since its seen an update: > https://wiki.secondlife.com/wiki/Source_branches OK, I've done that: https://wiki.secondlife.com/wiki/Source_branches#Current_repository_structure Please correct any misconceptions I might have included. (Bonus points if someone cleans up the old stuff still there) What is still missing but would be nice to have documented: Is there any rule about what branches will go directly to linden/branches/ (e.g. http://svn.secondlife.com/svn/linden/branches/render-pipeline/) and what to linden/braches// (e.g. http://svn.secondlife.com/svn/linden/branches/2009/http-texture/)? cheers Boroondas From boy.lane at yahoo.com Sat Apr 25 20:11:37 2009 From: boy.lane at yahoo.com (Boy Lane) Date: Sun, 26 Apr 2009 11:11:37 +0800 Subject: [sldev] Vivox and Kakadu licensing issues. Message-ID: <008601c9c61c$b82f95c0$6500a8c0@hp> I had a look at the mentioned KDU license that allows certain executables to be distributed and used for non-commercial projects. However this license seems to be for a complete different software package that is not identical with the one used in the SL client. So I assume here we can almost certainly say the KDU library used in the viewer is not redistributable and packaging it with a client is not legal (if done by someone else than LL). Correct me if I am wrong :). "http://www.kakadusoftware.com/Downloads.html read :Copyright is owned by NewSouth Innovations Proprietary Ltd, commercial arm of the University of New South Wales, Sydney, Australia. You are free to play around with these executables and even to re-distribute them, so long as such use or re-distribution is accompanied this copyright notice and is not for commercial gain. Note: Binaries can only be used for non-commercial purposes. If in doubt please contact Dr. Taubman." List of files (Win32): 11/28/2008 18:45 94,208 kdu_buffered_compress.exe 11/28/2008 18:45 94,208 kdu_buffered_expand.exe 11/28/2008 18:45 233,472 kdu_compress.exe 11/28/2008 18:45 192,512 kdu_expand.exe 11/28/2008 18:46 81,920 kdu_maketlm.exe 11/28/2008 18:46 237,568 kdu_merge.exe 11/28/2008 18:46 262,144 kdu_render.exe 11/28/2008 18:46 204,800 kdu_server.exe 11/28/2008 18:46 188,416 kdu_server_admin.exe 11/28/2008 18:47 520,192 kdu_show.exe 11/28/2008 18:47 90,112 kdu_transcode.exe 11/28/2008 18:43 565,248 kdu_v61R.dll 11/28/2008 18:47 110,592 kdu_v_compress.exe 11/28/2008 18:47 122,880 kdu_v_expand.exe 04/26/2009 11:09 0 test.txt 11/25/2008 10:58 96,745 Usage_Examples.txt ----- Original Message ----- From: "Boy Lane" To: "Teravus Ovares" Sent: Saturday, April 25, 2009 1:32 PM Subject: Re: [sldev] Vivox and Kakadu licensing issues. > Thanks Teravus, > > Certainly it's a licensing issue but one with a heavy technical impact > that affects all 3rd part viewers. > > We need someone from LL to answer that question here, it's no big deal. > Just a yes or no if > a) KDU can be distributed or not > b) Vivox can be distributed or not > > Boy > From alissa_sabre at yahoo.co.jp Sat Apr 25 07:01:04 2009 From: alissa_sabre at yahoo.co.jp (Alissa Sanbre) Date: Sat, 25 Apr 2009 23:01:04 +0900 Subject: [sldev] Question involving the rendering of interface windows In-Reply-To: <49E3684D.3000702@lindenlab.com> References: <49E3684D.3000702@lindenlab.com> Message-ID: <9uds4ds8dY4eaYeY96oYtm.alissa_sabre@yahoo.co.jp> > the current code > re-renders everything every frame, traditional notions of region > invalidation* just don't exist in the codebase and would need to be > shoehorned in. That's work that would be necessary either for > efficiently rendering all UI to one texture, or individual window to > separate textures. Moreover, because the current code assumes everything is redrawn every frame, a UI window must _poll_ the information to be shown on it, in many case. I guess we need to introduce a set of interface to "subscribe state changes" or "notify events to receivers", if we go to that direction. but, I believe the biggest problem is the amount of texture memory. With just a small glyph caching, pango based text drawing runs in an acceptable performance on modern CPU. Those who can't stand the extra overhead will have some older hardware, that has smaller main memory and graphics memory. I'm afraid that per-window texture buffer may make things worse. Alissa Sabre -------------------------------------- Power up the Internet with Yahoo! Toolbar. http://pr.mail.yahoo.co.jp/toolbar/ From khyota at redhyena.net Sun Apr 26 01:52:41 2009 From: khyota at redhyena.net (Khyota) Date: Sun, 26 Apr 2009 04:52:41 -0400 Subject: [sldev] compiling qtwebkit in the viewer In-Reply-To: <49F09150.8020108@gmail.com> References: <200901192044.20181.khyota@redhyena.net> <49F09150.8020108@gmail.com> Message-ID: <200904260452.42044.khyota@redhyena.net> On Thursday 23 April 2009 12:03:28 you wrote: > Hey, Khyota - did you ever solve this issue? I don't think I saw a > useful response on sl-dev and I'm sortof following in your footsteps, > currently trying to compile in the render-pipeline branch. > > Cheers, > Vex > > Khyota wrote: > > Hey guys im trying to test out SL with webkit, ive compiled it and > > replaced llmozlib2.h and libllmozlib2.a. It still seems to be trying to > > link the stuff from the old llmozlib and xulrunner. > > > > I got error messages > > > > ld: cannot find -lmozjs and such, creating symlinks to these in > > xulrunner-1.9/ to /usr/local/lib64 fixed that for this, and -lxpcom, > > -lxul.but now im stumped with -lprofdirserviceprovider_s. google reveals > > it is part of the old llmozlib, but it doesnt seem to be needed at all. > > How can i get rid of them? Hey sorry for delay i diddnt see this email, i did solve it but dont remeber how. I *think* it was by simply using webkit from Robins Repo http://omvviewer.byteme.org.uk/mozlib-webkit.shtml and her omvviewer but i stoped using it because it was cutting my overall fps in half. Maybe thats fixed now, i should try it again. Good luck Vex Khyota From secret.argent at gmail.com Sun Apr 26 12:22:22 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Sun, 26 Apr 2009 14:22:22 -0500 Subject: [sldev] DB vs. Asset vs Simulation In-Reply-To: <1522.75.33.197.92.1240286987.squirrel@mail.lindenlab.com> References: <8a1bfe660904201204g3690cc6eu2e54e831bb84da4c@mail.gmail.com> <20090421013054.GA23465@alinoe.com> <8a1bfe660904201906v464aa77cod55b83085e9dd013@mail.gmail.com> <1522.75.33.197.92.1240286987.squirrel@mail.lindenlab.com> Message-ID: I still believe that simplifying the cache at the client side to a Squid-style simple directory tree based on UUID would do more to resolve cache problems any any complex algorithm. From brad.king at kitware.com Mon Apr 27 07:47:59 2009 From: brad.king at kitware.com (Brad King) Date: Mon, 27 Apr 2009 10:47:59 -0400 Subject: [sldev] http-texture branch In-Reply-To: <6382D957-8E98-4B29-87E2-49D2BF1EFA06@lindenlab.com> References: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com> <6382D957-8E98-4B29-87E2-49D2BF1EFA06@lindenlab.com> Message-ID: <49F5C59F.4020601@kitware.com> Philippe Bossut (Merov Linden) wrote: > OK, I went ahead with that and committed the code. [snip] > For more of what's the short term plan is on that release, check out: > https://wiki.secondlife.com/wiki/HTTP_Texture_Development Is it now safe for me to rebase easybuild on projects/2009/http-texture as Linden folks requested? Thanks, -Brad From merov at lindenlab.com Mon Apr 27 10:34:13 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Mon, 27 Apr 2009 10:34:13 -0700 Subject: [sldev] http-texture branch In-Reply-To: <49F5C59F.4020601@kitware.com> References: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com> <6382D957-8E98-4B29-87E2-49D2BF1EFA06@lindenlab.com> <49F5C59F.4020601@kitware.com> Message-ID: <292FF4E6-6318-4267-91F5-A2E71825DE51@lindenlab.com> Hi Brad, On Apr 27, 2009, at 7:47 AM, Brad King wrote: > Is it now safe for me to rebase easybuild on projects/2009/http- > texture > as Linden folks requested? It is, as safe as the previous base you've been using. It builds on the 3 platforms fine which is the most important thing from your standpoint I think. I haven't been following the easybuild project super closely though so may be someone else with more stake than me in that project should chime in (Soft?). Cheers, - Merov From merov at lindenlab.com Mon Apr 27 10:39:03 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Mon, 27 Apr 2009 10:39:03 -0700 Subject: [sldev] http-texture branch In-Reply-To: <6382D957-8E98-4B29-87E2-49D2BF1EFA06@lindenlab.com> References: <12120960-2BAB-4C82-A87A-F9EBC2B320E7@lindenlab.com> <6382D957-8E98-4B29-87E2-49D2BF1EFA06@lindenlab.com> Message-ID: <63D0C121-D4D4-47EF-B024-1BA201C5FE67@lindenlab.com> Hi, The builds were successful and my personal smoke tests were pretty good so far. This build is *not* the answer to all crashers we had but it's significantly more stable. I update the relevant download links to point to these new builds: https://wiki.secondlife.com/wiki/Open_Source_Portal I'll keep an eye on the crash logger every day so please download test and let those crash logs coming so we get an idea of how stable this build is. Thanks all for your help :) Cheers, - Merov On Apr 24, 2009, at 5:30 PM, Philippe Bossut (Merov Linden) wrote: > Hi, > > OK, I went ahead with that and committed the code. It's building right > now and it'll take a couple of hours before it clears the 3 platforms. > > So, what you need to know: > - if you're building that baby (/branches/2009/http-texture) be aware > that r2166 is that new svn revision > - it's a merge of 1.23 and http-texture > - it's more stable than previous http-texture builds: my next tasks > will be to regress those crashers, mark fixed some that we suspect > this merge will fix and finally fix the couple fetch related ones we > have > - the map is still as fast as the previous http-texture (w00t!) > > For more of what's the short term plan is on that release, check out: > https://wiki.secondlife.com/wiki/HTTP_Texture_Development > > Cheers, > - Merov From robin.cornelius at gmail.com Mon Apr 27 12:22:23 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Mon, 27 Apr 2009 20:22:23 +0100 Subject: [sldev] 2 patches for http-texture Message-ID: <49F605EF.4050800@gmail.com> Hey guys Two more simple patches for http-texture, 1) http://jira.secondlife.com/browse/VWR-12989 test failing to build because lltut.h uses memcmp but does not include string.h 2) http://jira.secondlife.com/browse/VWR-12995 Another 64 bit printf issue with a %d for a size_t, fix same as last time change to %ld and cast up to long. If i see no objections i'll commit these in Thanks Robin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090427/d20a7023/attachment.pgp From ron at involve3d.com Mon Apr 27 14:00:49 2009 From: ron at involve3d.com (Ron Blechner) Date: Mon, 27 Apr 2009 17:00:49 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49EFD2A2.5020808@mac.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> <49EFD2A2.5020808@mac.com> Message-ID: Voted for VWR-10311. I've been pounding the drums for this for years, of course. Lip-sync is never perfect in any game or platform I've used with it. So what? Bottom line is that the experience with Lip-sync is more immersive and more interesting than without. Let's do it. -Ron -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com On Wed, Apr 22, 2009 at 10:29 PM, Tammy Nowotny wrote: > I have been having trouble with voice not firing up with 1.23.? My friends > list is pretty long but it is less than 800, by a factor of 10.? (But that > may not include avatars who have left the game and been away for years, but > whose calling card is still in my inventory and/or who I never purged from > my list.) > > I have an old pre-intel Mac Mini with only 1 GB of memory. > > --Tammy Nowotny > > > Joe Miller wrote: > > Dirk, > > Quite the contrary, the Linden Lab / Vivox relationship is very healthy and > we have some interesting new features ready to roll shortly.? There were a > few issues in the SDK shipped with the 1.22 viewer that have caused problems > for some folks.? One in particular was triggered by very large Friends Lists > (800+ calling cards in inventory) so it would likely affect long-term > residents like yourself.? That problem (and others mentioned in the Jira you > referenced below) should be fixed now in the 1.23RC nightly, soon to be > RC0.? If you have questions around functionality or problems with voice in > SL, you'll have better luck seeking answers here or at Linden than expecting > Vivox to respond.? Please feel free to hit me with an IM or email if you > have specific issues or questions you're having trouble getting answers to. > I'll get you the answers. > > -- Joe > > Black Hat Design wrote: > > I agree that Lip Sync be moved out of Beta. It does a fairly decent job when > voice actually works. Unfortunately residents are suffering many voice > issues now (http://jira.secondlife.com/browse/VWR-12487) and these are no > longer triaged as they appear to be third party issues. I have not had much > luck in getting answers from Vivox on the issues currently plaguing SL > residents. I am led to believe that the issue is arising out of a conflict > with the new SDK which was introduced in RC9 of the current release running > alongside the old SDK which many residents are still running since there is > no mandatory update to the viewer at this time. > > Currently, if you want stable voice, you can run the old client and suffer > through many of the bugs that are fixed in the current version, or you can > run the new client and go back to using Skype and a stream for inworld > conferences. > > Being that Vivox has not been responsive to inquiries, I am curious as to > whether there has been some deterioration in the relationship between Linden > Lab and Vivox. > > Dirk Talamasca > dirk at dirktalamasca.com > > Skype: Dirk Talamasca > Yahoo: blackhat > AIM: Black Hat Design > Google: dirktalamasca at gmail.com > > Edited subject. > > There's enough information to display green waves of appropriate > intensity above each speaking avatar. That same information can't be > used to control which avatars move their mouths? > > On Mon, Apr 20, 2009 at 11:01 AM, Kakurady Drakenar > wrote: > > > It doesn't do what it's supposed to do, that is accurate lip-synching for > all avatars. All it does is babbling for your own avatar, and all other > avatars at the same time when even only one of them talks, because of the > limitations of Vivox's voice architecture. > > Now, if there's a way to have user aware of that caveat, I have nothing > > > else > > > to worry on this issue. > > GCat/Kakur > > (To Moriz: Sorry for the duplicate, I forgot to choose "reply to all".) > > On Mon, Apr 20, 2009 at 11:40 AM, Moriz Gupte > > > wrote: > > > I also vote for taking lipsynch out of beta. I use it all the time but > have to waste some time telling new users how to enable it. extremely low > client side CPU footprint + does what it is supposed to, no reason not to > move it out of beta IMHO. > R > > On Mon, Apr 20, 2009 at 9:24 AM, Mike Monkowski > wrote: > > > I'd like to see http://jira.secondlife.com/browse/VWR-10311 implemented. > ?It's a trivial change. If it requires any shepherding, I'll do it. ?I > think it would be appropriate for an "open source" viewer. > > Mike > Mm Alder > > Rob Lanphier wrote: > > > So, are there other patches in JIRA that seem worthy of making it in > before the first merge window, and are there volunteers to shepherd > those patches through? > > > _______________________________________________ > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > ________________________________ > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > From gigstaggart at gmail.com Mon Apr 27 17:50:55 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Mon, 27 Apr 2009 20:50:55 -0400 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <001501c9c553$a59172e0$6500a8c0@hp> References: <001501c9c553$a59172e0$6500a8c0@hp> Message-ID: <49F652EF.8070909@gmail.com> Boy Lane wrote: > Hi Gigs/Jason :) > > This doesn't really make sense as both are dynamically linked and not > required to run the client. Dynamically linking a closed source library isn't a pass for violating the GPL. Regarding that copyright notice you posted, Vivox itself uses a bunch of open source software... The Vivox client is in large part just BSD licensed code that has been closed. -Jason From carlo at alinoe.com Mon Apr 27 19:21:12 2009 From: carlo at alinoe.com (Carlo Wood) Date: Tue, 28 Apr 2009 04:21:12 +0200 Subject: [sldev] 2 patches for http-texture In-Reply-To: <49F605EF.4050800@gmail.com> References: <49F605EF.4050800@gmail.com> Message-ID: <20090428022112.GA28785@alinoe.com> On Mon, Apr 27, 2009 at 08:22:23PM +0100, Robin Cornelius wrote: > 1) http://jira.secondlife.com/browse/VWR-12989 > > test failing to build because lltut.h uses memcmp but does not include > string.h Surely you mean > 2) http://jira.secondlife.com/browse/VWR-12995 > > Another 64 bit printf issue with a %d for a size_t, fix same as last > time change to %ld and cast up to long. Sorry, but a size_t is unsigned. You have to use %lu > If i see no objections i'll commit these in I object! :p > Thanks > > Robin -- Carlo Wood From boy.lane at yahoo.com Mon Apr 27 20:16:32 2009 From: boy.lane at yahoo.com (Boy Lane) Date: Tue, 28 Apr 2009 11:16:32 +0800 Subject: [sldev] Vivox and Kakadu licensing issues. References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> Message-ID: <002801c9c7af$bc792530$0700a8c0@hp> Hi Jason, Agreed. But the question was not directly linked to GPL and the status of the sources. Let me summarize it again. One person creates a 3rd party viewer and distributes KDU and Vivox components packaged with it. Claiming the earlier here mentioned license terms would allow that. However LL states that these components are not redistributable which seems to be contrary to what those quoted license passages say. So I'd ask again if someone from LL who are licensee of KDU and Vivox could clarify if it is legally possible to package these components with a custom built viewer or not. Boy ----- Original Message ----- From: "Jason Giglio" To: "Boy Lane" Cc: Sent: Tuesday, April 28, 2009 8:50 AM Subject: Re: [sldev] Vivox and Kakadu licensing issues. > Boy Lane wrote: >> Hi Gigs/Jason :) >> >> This doesn't really make sense as both are dynamically linked and not >> required to run the client. > > Dynamically linking a closed source library isn't a pass for violating > the GPL. > > Regarding that copyright notice you posted, Vivox itself uses a bunch of > open source software... The Vivox client is in large part just BSD > licensed code that has been closed. > > -Jason From tateru.nino at gmail.com Mon Apr 27 20:59:57 2009 From: tateru.nino at gmail.com (Tateru Nino) Date: Tue, 28 Apr 2009 13:59:57 +1000 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <002801c9c7af$bc792530$0700a8c0@hp> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> Message-ID: <49F67F3D.1010307@gmail.com> Also: distribution with Quicktime support, FMOD, the art assets, the fonts. (I believe I know the correct answer to the latter two - but we may as well get it all clarified in one go, right?) Have we missed any pieces? Boy Lane wrote: > Hi Jason, > > Agreed. But the question was not directly linked to GPL and the status of > the sources. > > Let me summarize it again. One person creates a 3rd party viewer and > distributes KDU and Vivox components packaged with it. Claiming the earlier > here mentioned license terms would allow that. > > However LL states that these components are not redistributable which seems > to be contrary to what those quoted license passages say. > > So I'd ask again if someone from LL who are licensee of KDU and Vivox could > clarify if it is legally possible to package these components with a custom > built viewer or not. > > Boy > > > ----- Original Message ----- > From: "Jason Giglio" > To: "Boy Lane" > Cc: > Sent: Tuesday, April 28, 2009 8:50 AM > Subject: Re: [sldev] Vivox and Kakadu licensing issues. > > > >> Boy Lane wrote: >> >>> Hi Gigs/Jason :) >>> >>> This doesn't really make sense as both are dynamically linked and not >>> required to run the client. >>> >> Dynamically linking a closed source library isn't a pass for violating >> the GPL. >> >> Regarding that copyright notice you posted, Vivox itself uses a bunch of >> open source software... The Vivox client is in large part just BSD >> licensed code that has been closed. >> >> -Jason >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -- Tateru Nino http://www.massively.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090428/7ffae89d/attachment.htm From monkowsk at watson.ibm.com Tue Apr 28 14:29:27 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Tue, 28 Apr 2009 17:29:27 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <061501c9c1e1$0a96ff00$1fc4fd00$@com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> Message-ID: <49F77537.8010609@watson.ibm.com> OK, so according to Rob's explanation: > For the merge window: Specific feature/patch proposals should be > discussed on sldev@ (let at least one full business day pass without > comment before considering silence assent). All checkins should have a > corresponding JIRA task with the proposed patch, either attached in > JIRA, or a pointer to a specific patchset in a public source repository > somewhere (e.g. Bitbucket). The comments on the JIRA task should have a > comment from another committer (not necessarily a Linden) who has > thoroughly reviewed the patch, and is willing to stake their credibility > as a committer that the patch should be safe for checkin. > > You'll need to take responsibility for the code you commit, especially > if you commit a build breaker. Failure to do so may lead to you losing > commit access, depending on the degree of carelessness exhibited. > Reviewers will also be subject to scrutiny. I think Tofu's comment on the Jira: > Tofu Linden added a comment - 28/Apr/09 11:36 AM > For the record - I'm for it. qualifies it for inclusion into http-texture (although Tofu didn't explicitly mention http-texture or staking anyone's credibility). So, since I am not a committer, and I don't know how to become a committer, and even if I were a committer, I wouldn't know how to commit, what happens next? Have I missed some documentation somewhere? Mike Mm Alder From gigstaggart at gmail.com Tue Apr 28 14:46:20 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Tue, 28 Apr 2009 17:46:20 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49EFCBC0.6030908@lindenlab.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> Message-ID: <49F7792C.3080504@gmail.com> Joe Miller wrote: > Dirk, > > Quite the contrary, the Linden Lab / Vivox relationship is very healthy > and we have some interesting new features ready to roll shortly. There > were a few issues in the SDK shipped with the 1.22 viewer that have > caused problems for some folks. One in particular was triggered by very > large Friends Lists (800+ calling cards in inventory) so it would likely What's the point in calling cards anymore? I deleted all of mine and didn't notice any loss of functionality. From colin.kern at gmail.com Tue Apr 28 17:02:18 2009 From: colin.kern at gmail.com (Colin Kern) Date: Tue, 28 Apr 2009 20:02:18 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49F7792C.3080504@gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> <49F7792C.3080504@gmail.com> Message-ID: <77c421f00904281702i3ad90e4cl7610c8eda511e623@mail.gmail.com> On Tue, Apr 28, 2009 at 5:46 PM, Jason Giglio wrote: > Joe Miller wrote: > > What's the point in calling cards anymore? > I think the idea is that you can give someone a calling card to provide them with an easy way to contact you without having to add them to your friends list. Technically, calling cards are still the only way to provide this feature, but I think very few people use them for this purpose. They probably just add them to their friends list anyway. Colin From mrfrans at gmail.com Tue Apr 28 19:48:14 2009 From: mrfrans at gmail.com (Frans) Date: Wed, 29 Apr 2009 04:48:14 +0200 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <77c421f00904281702i3ad90e4cl7610c8eda511e623@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> <49F7792C.3080504@gmail.com> <77c421f00904281702i3ad90e4cl7610c8eda511e623@mail.gmail.com> Message-ID: <7765f2c60904281948s3cf3a9f6pb8b29cebcee0dcd7@mail.gmail.com> As a asset they stay in your inventory even though the account itself might have disappeared, it serves it usefulness to track down names of old friends who have disappeared. But those uses are niche uses. On Wed, Apr 29, 2009 at 2:02 AM, Colin Kern wrote: > On Tue, Apr 28, 2009 at 5:46 PM, Jason Giglio > wrote: > > Joe Miller wrote: > > > > What's the point in calling cards anymore? > > > > I think the idea is that you can give someone a calling card to > provide them with an easy way to contact you without having to add > them to your friends list. Technically, calling cards are still the > only way to provide this feature, but I think very few people use them > for this purpose. They probably just add them to their friends list > anyway. > > Colin > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Jeroen Frans Executive Director TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/7bdbf771/attachment.htm From soft at lindenlab.com Tue Apr 28 20:10:17 2009 From: soft at lindenlab.com (Soft) Date: Tue, 28 Apr 2009 22:10:17 -0500 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <7765f2c60904281948s3cf3a9f6pb8b29cebcee0dcd7@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> <49F7792C.3080504@gmail.com> <77c421f00904281702i3ad90e4cl7610c8eda511e623@mail.gmail.com> <7765f2c60904281948s3cf3a9f6pb8b29cebcee0dcd7@mail.gmail.com> Message-ID: One can also create a folder of calling cards and right-click on it to start a group chat with that set of resis. I believe calling cards can also be dragged into an existing multi-user chat to invite more attendees. This is really functionality that should exist in the contact manager. I suspect it was done the current way for implementation expediency. On Tue, Apr 28, 2009 at 9:48 PM, Frans wrote: > As a asset they stay in your inventory even though the account itself might > have disappeared, it serves it usefulness to track down names of old friends > who have disappeared. But those uses are niche uses. > > On Wed, Apr 29, 2009 at 2:02 AM, Colin Kern wrote: >> >> On Tue, Apr 28, 2009 at 5:46 PM, Jason Giglio >> wrote: >> > Joe Miller wrote: >> > >> > What's the point in calling cards anymore? >> > >> >> I think the idea is that you can give someone a calling card to >> provide them with an easy way to contact you without having to add >> them to your friends list. ?Technically, calling cards are still the >> only way to provide this feature, but I think very few people use them >> for this purpose. ?They probably just add them to their friends list >> anyway. From aimee.trescothick at gmail.com Wed Apr 29 03:00:49 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Wed, 29 Apr 2009 11:00:49 +0100 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49F77537.8010609@watson.ibm.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> Message-ID: On 28 Apr 2009, at 22:29, Mike Monkowski wrote: > I think Tofu's comment on the Jira: >> Tofu Linden added a comment - 28/Apr/09 11:36 AM >> For the record - I'm for it. > > qualifies it for inclusion into http-texture (although Tofu didn't > explicitly mention http-texture or staking anyone's credibility). Although I'm not on the reviewers list at the moment, for want of free time, I have commit access and so am eligible to add myself to the list, I would be willing to act as reviewer for this simple change if needed. Aimee. From GordonWendt at gmail.com Wed Apr 29 05:03:38 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed, 29 Apr 2009 08:03:38 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> Message-ID: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> I have to object to this being commited by a non-Linden even to the http-texture branch considering that the process as far as I've read for non Linden commits seems to be meant for non controversial changes which per the comments on the JIRA and elsewhere this is not. If Tofu likes it enough to stake his L-rep on it then let him commit it otherwise it should be hashed out on JIRA until people can come to an agreement oin it. For the record I am against the change in general and don't think lipsync should be on by default. -Gordon On Wed, Apr 29, 2009 at 6:00 AM, Aimee Trescothick < aimee.trescothick at gmail.com> wrote: > On 28 Apr 2009, at 22:29, Mike Monkowski wrote: > > > I think Tofu's comment on the Jira: > >> Tofu Linden added a comment - 28/Apr/09 11:36 AM > >> For the record - I'm for it. > > > > qualifies it for inclusion into http-texture (although Tofu didn't > > explicitly mention http-texture or staking anyone's credibility). > > Although I'm not on the reviewers list at the moment, for want of free > time, I have commit access and so am eligible to add myself to the > list, I would be willing to act as reviewer for this simple change if > needed. > > Aimee. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/360d6c91/attachment.htm From moriz.gupte at gmail.com Wed Apr 29 07:35:36 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Wed, 29 Apr 2009 08:35:36 -0600 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> Message-ID: Dear Gordon, I am afraid 'for the record' is not enough. It is helpful if you support your vote with a reason unless it is weak. It has been interesting to me to watch the massive and sustained opposition to voice integration and hence a needless controversy. This turned out to the central most feature used by the most significant income generating sector for LL ie corporate/education users. Anyway, why visit those needless controversies. I don't think controversy should be the sole 'integration stopper'. Let's be a little more thoughful. Yes, lipsynch should be out of 'advanced' and yes it is not be on by default. Settingit on could accompany the dialog box for media player for eg. MG On Wed, Apr 29, 2009 at 6:03 AM, Gordon Wendt wrote: > I have to object to this being commited by a non-Linden even to the > http-texture branch considering that the process as far as I've read for non > Linden commits seems to be meant for non controversial changes which per the > comments on the JIRA and elsewhere this is not. If Tofu likes it enough to > stake his L-rep on it then let him commit it otherwise it should be hashed > out on JIRA until people can come to an agreement oin it. For the record I > am against the change in general and don't think lipsync should be on by > default. > > -Gordon > > > On Wed, Apr 29, 2009 at 6:00 AM, Aimee Trescothick < > aimee.trescothick at gmail.com> wrote: > >> On 28 Apr 2009, at 22:29, Mike Monkowski wrote: >> >> > I think Tofu's comment on the Jira: >> >> Tofu Linden added a comment - 28/Apr/09 11:36 AM >> >> For the record - I'm for it. >> > >> > qualifies it for inclusion into http-texture (although Tofu didn't >> > explicitly mention http-texture or staking anyone's credibility). >> >> Although I'm not on the reviewers list at the moment, for want of free >> time, I have commit access and so am eligible to add myself to the >> list, I would be willing to act as reviewer for this simple change if >> needed. >> >> Aimee. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Rameshsharma Ramloll PhD Research Assistant Professor Idaho State University, PocatelloTel: 208-282-5333 Bio: http://snipurl.com/3p5ap , LinkedIn profile: http://snipurl.com/3p5o2 , Blog: http://snipurl.com/3p5op , Play2Train: http://www.play2train.org ----- The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge- Stephen Hawking and many others who found light through the cracks of knowledge. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/3e443eff/attachment-0001.htm From monkowsk at watson.ibm.com Wed Apr 29 07:36:43 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 29 Apr 2009 10:36:43 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> Message-ID: <49F865FB.4080005@watson.ibm.com> I've addressed the concerns about lip sync in the JIRA issue http://jira.secondlife.com/browse/VWR-10311 As far as the "non controversial changes" comment: where did you read that? Is there a rule about unanimous approval? I'm having trouble finding any firm guidelines for this "open source viewer" aka "http-texture" project. I've seen http://wiki.secondlife.com/wiki/HTTP_Texture_Development but that is very thin on details. Mike Gordon Wendt wrote: > I have to object to this being commited by a non-Linden even to the > http-texture branch considering that the process as far as I've read for > non Linden commits seems to be meant for non controversial changes which > per the comments on the JIRA and elsewhere this is not. If Tofu likes > it enough to stake his L-rep on it then let him commit it otherwise it > should be hashed out on JIRA until people can come to an agreement oin > it. For the record I am against the change in general and don't think > lipsync should be on by default. From monkowsk at watson.ibm.com Wed Apr 29 07:44:49 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 29 Apr 2009 10:44:49 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> Message-ID: <49F867E1.6040805@watson.ibm.com> Moriz Gupte wrote: > Dear Gordon, > I am afraid 'for the record' is not enough. It is helpful if you support > your vote with a reason unless it is weak. ... > Yes, lipsynch should be out > of 'advanced' and yes it is not be on by default. Settingit on could > accompany the dialog box for media player for eg. > MG And *your* reason for saying that it should not be on by default is? Remember, that if voice chat is disabled, so is the lip sync, but if voice chat is enabled, you still have to use another setting to enable lip sync. How is that useful? Mike From GordonWendt at gmail.com Wed Apr 29 08:07:50 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed, 29 Apr 2009 11:07:50 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49F867E1.6040805@watson.ibm.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> Message-ID: <493033a70904290807p2a8aa05er4403e36d9da0678a@mail.gmail.com> Mike, I think I was reading too much into it. On the HTTP-Texture branch I don't really have any objections but the JIRA issue I believe is about getting it into the main viewer and my concern is that certain people are happy to try to use this as a backdoor way to get this implemented on the main viewer when there are serious objections to doing so. Once it is in it's much harder to justify removing it even if it was put in just as a testing feature. Moriz, First of all I don't aprpeciate the condescending attitude and secondly, I think I explained myself enough on the JIRA issue as to why I think that this is a nice feature to have but not useful enough to justify having on by default. Incidentally, speaking of backing up facts I challenge you to back up your statement about voice being, "central most feature used by the most significant income generating sector for LL ie corporate/education users". -Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/df632ba4/attachment.htm From monkowsk at watson.ibm.com Wed Apr 29 08:55:11 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 29 Apr 2009 11:55:11 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <493033a70904290807p2a8aa05er4403e36d9da0678a@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <493033a70904290807p2a8aa05er4403e36d9da0678a@mail.gmail.com> Message-ID: <49F8785F.9040504@watson.ibm.com> I wholeheartedly admit to being one of those "certain people." I *do* want to get this into the main viewer. I have heard objections that appear to be genuine, but do not understand their rationale. The Linden Open Source Contribution project has been seriously hurt by the difficulty in getting any contribution incorporated into the main viewer, especially during this extended period of concentrating on "viewer stability." This "backdoor" appears to be the only door "open." Any requirement of unanimous approval is sure to close this one as well. I'm also doing work with the morphs. Tofu Linden added a comment to that Jira issue, "I'm happy for people to keep working towards this, but I wanted to give a status update - I can't picture this issue getting looked at (even a little) internally for many months, given our current priorities; this is pretty much way down the list." With prospects like that, why would anyone work on an open source project? I think Philip realized this and created this "open source viewer" project to keep external developers from getting discouraged and abandoning SL for some project actually willing to accept contributions. If the developers themselves make it hard to get contributions accepted, then there's no reason to stay. Mike Gordon Wendt wrote: > Mike, I think I was reading too much into it. On the HTTP-Texture branch > I don't really have any objections but the JIRA issue I believe is about > getting it into the main viewer and my concern is that certain people > are happy to try to use this as a backdoor way to get this implemented > on the main viewer when there are serious objections to doing so. Once > it is in it's much harder to justify removing it even if it was put in > just as a testing feature. From moriz.gupte at gmail.com Wed Apr 29 09:47:20 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Wed, 29 Apr 2009 10:47:20 -0600 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49F867E1.6040805@watson.ibm.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> Message-ID: I agree Mike, the lipsync should not even have an additional control point to further load an already overloaded UI. I think what I was trying to say actually is that when somebody enables voices, it should come on automatically. I guess I was just trying to find a middle ground ... for those who did not want it On Wed, Apr 29, 2009 at 8:44 AM, Mike Monkowski wrote: > Moriz Gupte wrote: > >> Dear Gordon, >> I am afraid 'for the record' is not enough. It is helpful if you support >> your vote with a reason unless it is weak. >> > ... > >> Yes, lipsynch should be out of 'advanced' and yes it is not be on by >> default. Settingit on could accompany the dialog box for media player for >> eg. >> MG >> > > And *your* reason for saying that it should not be on by default is? > > Remember, that if voice chat is disabled, so is the lip sync, but if voice > chat is enabled, you still have to use another setting to enable lip sync. > How is that useful? > > Mike > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/6d276a6b/attachment.htm From ron at involve3d.com Wed Apr 29 10:30:37 2009 From: ron at involve3d.com (Ron Blechner) Date: Wed, 29 Apr 2009 13:30:37 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> Message-ID: Gordon: "try to use this as a backdoor way to get this implemented on the main viewer" As Moriz points out ... your statements presume that adding lipsync to the main viewer is a bad thing, which is precisely one of the topics of discussion. I provided my reasoning (increased immersion and being able to see who's speaking more clearly) - but I haven't seen you specifically state *why* you think lipsync is bad as default for voice. I'd love to hear contrary reasons, so that we can all consider the reasons and then work on ways to improve lipsync to offset / fix those issues. Right? Regards, Ron On Wed, Apr 29, 2009 at 12:47 PM, Moriz Gupte wrote: > I agree Mike, the lipsync should not even have an additional control point > to further load an already overloaded UI. I think what I was trying to say > actually is that when somebody enables voices, it should come on > automatically. I guess I was just trying to find a middle ground ... for > those who did not want it > > On Wed, Apr 29, 2009 at 8:44 AM, Mike Monkowski > wrote: >> >> Moriz Gupte wrote: >>> >>> Dear Gordon, >>> I am afraid 'for the record' is not enough. It is helpful if you support >>> your vote with a reason unless it is weak. >> >> ... >>> >>> Yes, lipsynch should be out of 'advanced' and yes it is not be on by >>> default. Settingit on could accompany the dialog box for media player for >>> eg. >>> MG >> >> And *your* reason for saying that it should not be on by default is? >> >> Remember, that if voice chat is disabled, so is the lip sync, but if voice >> chat is enabled, you still have to use another setting to enable lip sync. >> ?How is that useful? >> >> Mike > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com From missannotoole at yahoo.com Wed Apr 29 11:00:29 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Wed, 29 Apr 2009 11:00:29 -0700 (PDT) Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> Message-ID: <784490.3996.qm@web59104.mail.re1.yahoo.com> How ridiculous that anyone would consider forcing the default to enabled on anything that would increase CPU or Bandwidth. All defaults should be OFF on anything that compounds the problems related to system compatibility and ISP efforts to kill utilization. Such as voice. ________________________________ From: Moriz Gupte To: Second Life Developer Mailing List Sent: Wednesday, April 29, 2009 12:47:20 PM Subject: Re: [sldev] VWR-10311 Enabling lip sync by default I agree Mike, the lipsync should not even have an additional control point to further load an already overloaded UI. I think what I was trying to say actually is that when somebody enables voices, it should come on automatically. I guess I was just trying to find a middle ground ... for those who did not want it On Wed, Apr 29, 2009 at 8:44 AM, Mike Monkowski wrote: Moriz Gupte wrote: Dear Gordon, I am afraid 'for the record' is not enough. It is helpful if you support your vote with a reason unless it is weak. ... Yes, lipsynch should be out of 'advanced' and yes it is not be on by default. Settingit on could accompany the dialog box for media player for eg. MG And *your* reason for saying that it should not be on by default is? Remember, that if voice chat is disabled, so is the lip sync, but if voice chat is enabled, you still have to use another setting to enable lip sync. How is that useful? Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/9ab5daaf/attachment-0001.htm From ron at involve3d.com Wed Apr 29 11:09:54 2009 From: ron at involve3d.com (Ron Blechner) Date: Wed, 29 Apr 2009 14:09:54 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <784490.3996.qm@web59104.mail.re1.yahoo.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> Message-ID: Since you're labeling us as ridiculous, I'm forced to reply with a stifled laugh and a hyperlink: http://en.wikipedia.org/wiki/Moore%27s_law But, that said, by your logic, let's freeze all new features in SL as they may increase CPU. I'm sorry, but that's not a good reason. On Wed, Apr 29, 2009 at 2:00 PM, Ann Otoole wrote: > How ridiculous that anyone would consider forcing the default to enabled on > anything that would increase CPU or Bandwidth. > > All defaults should be OFF on anything that compounds the problems related > to system compatibility and ISP efforts to kill utilization. Such as voice. > > ________________________________ > From: Moriz Gupte > To: Second Life Developer Mailing List > Sent: Wednesday, April 29, 2009 12:47:20 PM > Subject: Re: [sldev] VWR-10311 Enabling lip sync by default > > I agree Mike, the lipsync should not even have an additional control point > to further load an already overloaded UI. I think what I was trying to say > actually is that when somebody enables voices, it should come on > automatically. I guess I was just trying to find a middle ground ... for > those who did not want it > > On Wed, Apr 29, 2009 at 8:44 AM, Mike Monkowski > wrote: >> >> Moriz Gupte wrote: >>> >>> Dear Gordon, >>> I am afraid 'for the record' is not enough. It is helpful if you support >>> your vote with a reason unless it is weak. >> >> ... >>> >>> Yes, lipsynch should be out of 'advanced' and yes it is not be on by >>> default. Settingit on could accompany the dialog box for media player for >>> eg. >>> MG >> >> And *your* reason for saying that it should not be on by default is? >> >> Remember, that if voice chat is disabled, so is the lip sync, but if voice >> chat is enabled, you still have to use another setting to enable lip sync. >> ?How is that useful? >> >> Mike > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com From kwerks.sl at gmail.com Wed Apr 29 12:45:42 2009 From: kwerks.sl at gmail.com (JB Kraft) Date: Wed, 29 Apr 2009 15:45:42 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> Message-ID: <7b61e3970904291245j53703dbcjb177dc234cb592d5@mail.gmail.com> Some folks actually prefer smaller, faster over "featureful" I think. I know I do anyway. I've spent more time trying to figure out how to tear code out of my client build then putting code in frankly. Just because hardware gets faster is just as illogical a reason to fill it back up with more stuff. The "more stuff" should stand on it's own usefulness, regardless of Moore and I, for one, appreciate being able to turn it off, and appreciate more, being able to rip it out altogether. If I could do that with WIndows, I might actually use it, for instance. Perhaps a more modular approach, plugin style, might be considered. From my own usage and perspective, voice and windlight would be the first two .so's to go. Just another view :) all the best JB On Wed, Apr 29, 2009 at 2:09 PM, Ron Blechner wrote: > Since you're labeling us as ridiculous, I'm forced to reply with a > stifled laugh and a hyperlink: > > http://en.wikipedia.org/wiki/Moore%27s_law > > But, that said, by your logic, let's freeze all new features in SL as > they may increase CPU. I'm sorry, but that's not a good reason. > > On Wed, Apr 29, 2009 at 2:00 PM, Ann Otoole > wrote: > > How ridiculous that anyone would consider forcing the default to enabled > on > > anything that would increase CPU or Bandwidth. > > > > All defaults should be OFF on anything that compounds the problems > related > > to system compatibility and ISP efforts to kill utilization. Such as > voice. > > > > ________________________________ > > From: Moriz Gupte > > To: Second Life Developer Mailing List > > Sent: Wednesday, April 29, 2009 12:47:20 PM > > Subject: Re: [sldev] VWR-10311 Enabling lip sync by default > > > > I agree Mike, the lipsync should not even have an additional control > point > > to further load an already overloaded UI. I think what I was trying to > say > > actually is that when somebody enables voices, it should come on > > automatically. I guess I was just trying to find a middle ground ... for > > those who did not want it > > > > On Wed, Apr 29, 2009 at 8:44 AM, Mike Monkowski > > > wrote: > >> > >> Moriz Gupte wrote: > >>> > >>> Dear Gordon, > >>> I am afraid 'for the record' is not enough. It is helpful if you > support > >>> your vote with a reason unless it is weak. > >> > >> ... > >>> > >>> Yes, lipsynch should be out of 'advanced' and yes it is not be on by > >>> default. Settingit on could accompany the dialog box for media player > for > >>> eg. > >>> MG > >> > >> And *your* reason for saying that it should not be on by default is? > >> > >> Remember, that if voice chat is disabled, so is the lip sync, but if > voice > >> chat is enabled, you still have to use another setting to enable lip > sync. > >> How is that useful? > >> > >> Mike > > > > > > > > _______________________________________________ > > Policies and (un)subscribe information available here: > > http://wiki.secondlife.com/wiki/SLDev > > Please read the policies before posting to keep unmoderated posting > > privileges > > > > > > -- > Ron Blechner > Chief Technology Officer > Involve, Inc > www.involve3d.com > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/12c8a30f/attachment.htm From ordinal.malaprop at fastmail.fm Wed Apr 29 12:48:17 2009 From: ordinal.malaprop at fastmail.fm (ordinal.malaprop at fastmail.fm) Date: Wed, 29 Apr 2009 20:48:17 +0100 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <7b61e3970904291245j53703dbcjb177dc234cb592d5@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <7b61e3970904291245j53703dbcjb177dc234cb592d5@mail.gmail.com> Message-ID: <4EBAB0C6-8B76-4F9E-9679-06FC0FC96E08@fastmail.fm> On 29 Apr 2009, at 20:45, JB Kraft wrote: > Perhaps a more modular approach, plugin style, might be considered. > From my own usage and perspective, voice and windlight would be the > first two .so's to go. A plugin architecture for the client would be incredibly useful, and I've promoted the idea in my own small way (rather than "hey, you want something different? Build and release your own client!") for a couple of years now. From monkowsk at watson.ibm.com Wed Apr 29 12:51:09 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Wed, 29 Apr 2009 15:51:09 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <784490.3996.qm@web59104.mail.re1.yahoo.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> Message-ID: <49F8AFAD.3040007@watson.ibm.com> Lip sync does not use any more CPU power than the blinking of the eyes does. It does not affect bandwidth at all. Perhaps you're confusing voice chat with lip sync. Mike Ann Otoole wrote: > How ridiculous that anyone would consider forcing the default to enabled > on anything that would increase CPU or Bandwidth. > > All defaults should be OFF on anything that compounds the problems > related to system compatibility and ISP efforts to kill utilization. > Such as voice. From soft at lindenlab.com Wed Apr 29 15:34:45 2009 From: soft at lindenlab.com (Soft) Date: Wed, 29 Apr 2009 17:34:45 -0500 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <784490.3996.qm@web59104.mail.re1.yahoo.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> Message-ID: There's certainly no bandwidth impact with this change. If it has a significant CPU impact, it could sit in the render options and default to disabled for the lower end system presets. Have you seen or measured a significant CPU impact? On Wed, Apr 29, 2009 at 1:00 PM, Ann Otoole wrote: > How ridiculous that anyone would consider forcing the default to enabled on > anything that would increase CPU or Bandwidth. > > All defaults should be OFF on anything that compounds the problems related > to system compatibility and ISP efforts to kill utilization. Such as voice. > > ________________________________ > From: Moriz Gupte > To: Second Life Developer Mailing List > Sent: Wednesday, April 29, 2009 12:47:20 PM > Subject: Re: [sldev] VWR-10311 Enabling lip sync by default > > I agree Mike, the lipsync should not even have an additional control point > to further load an already overloaded UI. I think what I was trying to say > actually is that when somebody enables voices, it should come on > automatically. I guess I was just trying to find a middle ground ... for > those who did not want it From moriz.gupte at gmail.com Wed Apr 29 15:42:58 2009 From: moriz.gupte at gmail.com (Moriz Gupte) Date: Wed, 29 Apr 2009 16:42:58 -0600 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49F8AFAD.3040007@watson.ibm.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> Message-ID: To summarize and to clarify: I feel these are the points important to state 1. We are not discussing voice 2. Voice has always been optional 3. lipsync has negligible footprint (as Mike has patiently and repeatedly mentioned inspite of various reflex reactions) In my own experience, enabling or disabling lipsync has no effect on our fps and all our machines share the exactly the same settings/I have 3 generations of hardware to work with and no impact experienced. 4. I have been challenged to provide financial info regarding financial impact of voice on income regarding corporate/education efforts (LL could perhaps design better survey forms to tease that info out, I can only tell about my own efforts which is skewed because of my audience: federal agencies. I would be using another platform if SL did not integrate voice because this is one of the primary requirements from RFPs or when you are putting in a competitive bid while facing other VR platforms such as Forterra which had lipsync for years and better web integration ) So it is not entirely mesmerizing why LL has ignored the voice controversy perhaps because corporations or feds don't pay in Lindens. 5. Enabling voice should trigger lipsync automatically (no need to overload UI) 6. On a related note, I found that there was a solution for the space navigator especially regarding vehicle controls in SL and the integration of that patch is supposed to be for the next main client [keeping fingers crossed, hope no controversy about this one [image: :)]]. Turns out my audience also prefer for some reason this device (I prefer the keyboard). 7. The plugin idea is great except that it will require deeper changes and we are still refactoring right? so while I would love to see it happen, I dont think those tiny incremental changes should be left out. There is therefore some understandable frustration regarding the time it takes for the patches to be integrated (If you find out when Aimee actually got a handle on this space navigator - vehicles problem, you will understand the frustration). It is clear that there are many items with high priority (HTML on a prim is a requirement...for e.g. and we it's coming any time [image: :)] but hey I think these little incremental improvements are worthwhile. And yes btw, Babbage Linden (Technical Director?) did mention Mike's work recently, as an example of user contribution, in one of his talks recently. So I think they might be more than a few people who like this stuff. MG On Wed, Apr 29, 2009 at 1:51 PM, Mike Monkowski wrote: > Lip sync does not use any more CPU power than the blinking of the eyes > does. It does not affect bandwidth at all. Perhaps you're confusing > voice chat with lip sync. > > Mike > > Ann Otoole wrote: > > How ridiculous that anyone would consider forcing the default to enabled > > on anything that would increase CPU or Bandwidth. > > > > All defaults should be OFF on anything that compounds the problems > > related to system compatibility and ISP efforts to kill utilization. > > Such as voice. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/48dde868/attachment.htm From merov at lindenlab.com Wed Apr 29 18:06:06 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 29 Apr 2009 18:06:06 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <49F8AFAD.3040007@watson.ibm.com> Message-ID: <1239A8D0-87D6-4895-AB66-B469BB123603@lindenlab.com> Hi, Thanks Moritz for the fair and clear summary of this issue. Putting in my L$0.02, I'll add that we think it's fine to have this "turned on by default" (which will only impact residents using voice chat as stated in that thread) and that our BDFL already said so (may be not in public though... Philip?). We already selected this VWR as one of the community voted feature that we'll get in "http-texture" (aka the "Second Life OSS" viewer). Since I'm at it, there is a wiki page that lists the bugs and features we (collective "we", not just Lindens...) are working on for the next and first release of this viewer. It is there: https://wiki.secondlife.com/wiki/ HTTP_Texture_Development#Pending_merge_queue_proposals I'll follow up on another thread on the state of that viewer so far in a little while. Cheers, - Merov On Apr 29, 2009, at 3:42 PM, Moriz Gupte wrote: > To summarize and to clarify: > I feel these are the points important to state > > 1. We are not discussing voice > 2. Voice has always been optional > 3. lipsync has negligible footprint (as Mike has patiently and > repeatedly mentioned inspite of various reflex reactions) In my own > experience, enabling or disabling lipsync has no effect on our fps > and all our machines share the exactly the same settings/I have 3 > generations of hardware to work with and no impact experienced. > 4. I have been challenged to provide financial info regarding > financial impact of voice on income regarding corporate/education > efforts (LL could perhaps design better survey forms to tease that > info out, I can only tell about my own efforts which is skewed > because of my audience: federal agencies. I would be using another > platform if SL did not integrate voice because this is one of the > primary requirements from RFPs or when you are putting in a > competitive bid while facing other VR platforms such as Forterra > which had lipsync for years and better web integration ) So it is > not entirely mesmerizing why LL has ignored the voice controversy > perhaps because corporations or feds don't pay in Lindens. > 5. Enabling voice should trigger lipsync automatically (no need to > overload UI) > 6. On a related note, I found that there was a solution for the > space navigator especially regarding vehicle controls in SL and the > integration of that patch is supposed to be for the next main client > [keeping fingers crossed, hope no controversy about this one ]. > Turns out my audience also prefer for some reason this device (I > prefer the keyboard). > 7. The plugin idea is great except that it will require deeper > changes and we are still refactoring right? so while I would love to > see it happen, I dont think those tiny incremental changes should be > left out. > > There is therefore some understandable frustration regarding the > time it takes for the patches to be integrated (If you find out when > Aimee actually got a handle on this space navigator - vehicles > problem, you will understand the frustration). It is clear that > there are many items with high priority (HTML on a prim is a > requirement...for e.g. and we it's coming any time but hey I think > these little incremental improvements are worthwhile. And yes btw, > Babbage Linden (Technical Director?) did mention Mike's work > recently, as an example of user contribution, in one of his talks > recently. So I think they might be more than a few people who like > this stuff. > > MG > > On Wed, Apr 29, 2009 at 1:51 PM, Mike Monkowski > wrote: > Lip sync does not use any more CPU power than the blinking of the eyes > does. It does not affect bandwidth at all. Perhaps you're confusing > voice chat with lip sync. > > Mike > > Ann Otoole wrote: > > How ridiculous that anyone would consider forcing the default to > enabled > > on anything that would increase CPU or Bandwidth. > > > > All defaults should be OFF on anything that compounds the problems > > related to system compatibility and ISP efforts to kill utilization. > > Such as voice. > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > > > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/03c3801b/attachment-0001.htm From gigstaggart at gmail.com Wed Apr 29 18:53:01 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 29 Apr 2009 21:53:01 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> <49F7792C.3080504@gmail.com> <77c421f00904281702i3ad90e4cl7610c8eda511e623@mail.gmail.com> <7765f2c60904281948s3cf3a9f6pb8b29cebcee0dcd7@mail.gmail.com> Message-ID: <49F9047D.8030809@gmail.com> Soft wrote: > One can also create a folder of calling cards and right-click on it to > start a group chat with that set of resis. I believe calling cards can > also be dragged into an existing multi-user chat to invite more > attendees. This is really functionality that should exist in the > contact manager. I suspect it was done the current way for > implementation expediency. > It's already in the contact manager too... IIRC you can ctrl-select multiple friends and initiate a friends chat that way. -Jason From GordonWendt at gmail.com Wed Apr 29 18:57:26 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Wed, 29 Apr 2009 21:57:26 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <784490.3996.qm@web59104.mail.re1.yahoo.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> Message-ID: <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> To answer the question as to why I hold my view, I think I answered it well enough on the JIRA issue. Incidentally I don't agree with many of the other opinions here but I just wanted to say that I do not agree with Anne and that my views are nowhere near that extreme, there are plenty of options that definitely should be on by default I just don't believe this is one of them and regardless of the motives in doing so I resent this being pushed through the back door. There are still legitimate ways to do this without sneaking in through a little heard of (outside of this list) branch of the viewer and trying to do this reflects very poorly on the ethics of both the people supporting this attempt and the Lindens who are supporting it. -Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090429/5b20d520/attachment.htm From gigstaggart at gmail.com Wed Apr 29 19:01:41 2009 From: gigstaggart at gmail.com (Jason Giglio) Date: Wed, 29 Apr 2009 22:01:41 -0400 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <002801c9c7af$bc792530$0700a8c0@hp> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> Message-ID: <49F90685.2090406@gmail.com> Boy Lane wrote: > Let me summarize it again. One person creates a 3rd party viewer and > distributes KDU and Vivox components packaged with it. Claiming the earlier > here mentioned license terms would allow that. Let me summarize my answer again: It doesn't matter. The GPL doesn't allow it even if the library's licenses do. Linking (even dynamically) a closed source library and distributing it as part of a GPLed work is a violation of the GPL. Even if the KDU license said: "Feel free to use this any way you want", you still couldn't use it with a GPLed work, since you can't satisfy the GPL requirements for source code availability of the closed library. > So I'd ask again if someone from LL who are licensee of KDU and Vivox could > clarify if it is legally possible to package these components with a custom > built viewer or not. The chance of you getting any even semi-official answer regarding licensing on this list from a Linden are pretty low. -Jason From mrfrans at gmail.com Wed Apr 29 20:36:12 2009 From: mrfrans at gmail.com (Frans) Date: Thu, 30 Apr 2009 05:36:12 +0200 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49F9047D.8030809@gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> <49F7792C.3080504@gmail.com> <77c421f00904281702i3ad90e4cl7610c8eda511e623@mail.gmail.com> <7765f2c60904281948s3cf3a9f6pb8b29cebcee0dcd7@mail.gmail.com> <49F9047D.8030809@gmail.com> Message-ID: <7765f2c60904292036q22f1a33cvf870ab05d50ef5d1@mail.gmail.com> I Believe it is only limited to 10 people via the contact manager. On Thu, Apr 30, 2009 at 3:53 AM, Jason Giglio wrote: > Soft wrote: > > One can also create a folder of calling cards and right-click on it to > > start a group chat with that set of resis. I believe calling cards can > > also be dragged into an existing multi-user chat to invite more > > attendees. This is really functionality that should exist in the > > contact manager. I suspect it was done the current way for > > implementation expediency. > > > > It's already in the contact manager too... IIRC you can ctrl-select > multiple friends and initiate a friends chat that way. > > -Jason > -- Jeroen Frans Executive Director TheVesuviusGroup.com SL: Frans Charming -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/29e32f29/attachment.htm From ron at involve3d.com Wed Apr 29 20:45:41 2009 From: ron at involve3d.com (Ron Blechner) Date: Wed, 29 Apr 2009 23:45:41 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> Message-ID: Reposting your reason here for everyone to see: "It is a nice feature but when it comes down to the essentials of being able to use SL it is unnecessary fluff and people shouldn't have to have it on by default and then have it be on them to have to figure out how to turn it off." So lipsync is "unnecessary fluff", eh? Why? I mean, plenty of people argue that all of Second Life is "unnecessary fluff". "What good is a virtual world?" people ask... most people hold the opinion that Second Life is a *game*. But it's not - we're here all as developers pushing Second Life as a platform for a variety of uses. Some of us make a living doing so. But let's look at the feature itself. Why is lipsync fluff or not fluff? To me, it seems ridiculous that we voice talk and what is shown indicates that our avatars are all telepathically communicating. That's lame, in my opinion. Lipsync is a standard used on a variety of online games, and as I've stated, they both add to the immersion and make it clearer who's currently speaking. Let's look at each of these one at a time. Making it clearer who's speaking: Second Life is NOT an easy platform to use. Studies from Linden Lab have shown that it takes up to 20 hours of using Second Life before you can guarantee a "permanent" resident. Anything that improves the ease of use is thus extremely valuable. When I use voice chat in a group, it's often disorienting who's talking. Yes, there are the volume indicators above peoples' heads, but this is not intuitive. We live real life where we see peoples' mouths move and that's an indication of speaking, and so having the same in Second Life is thus more intuitive. Immersion: Why bother doing anything in a virtual world? Immersion is the #1 thing that virtual worlds such as Second Life have and flat-web does not. The more things that make a user feel connected with their avatar by proxy, and make them suspend their disbelief to feel "present", the more that the immersion factor is felt. Lipsync is, in my professional assessment, *the single most important missing element for immersion*. Since Stephenson's Snow Crash inspired Rosedale and 90% of all the other devs in here poking around with virtual worlds, allow me to quote from the book when describing how under-appreciated faces are on avatars. The quote describes an employee of "Black Sun" where the character is the only person who cared at the time about faces. "She was the face department, because nobody thought that faces were all that important - they were just flesh-toned busts on top of the avatars. She was in the process of proving them all desperately wrong. But at this phase, the all-male society of bitheads that made up the power structure of Black Sun Systems said that the face problem was trivial and superficial." Face *is* immersion. When you look at machinima nowadays done with SL, it's all done with the lipsync client. If you look at contemporary animated movies and video games, all faces are animated. It's an absolute no-brainer. Lipsync is unnecessary about as much as a walk animation. We could, in theory, float around everywhere. But that's silly. And so is the lack of avatars moving their lips when they are talking. You know what's fluff? Reflections. Shiny. And these are WAY more CPU intensive than some *client-rendered* mesh-stretching, which is what your computer does 100% of the time anyway as the avatar moves around and figits. There's simply no good reason I've read so far that's been presented. Again, I'd love to hear one. I'd love to hear someone give a legit reason that we could address and use as constructive criticism to improve the lipsyncing features. But seeing none, let's get this feature out, not just in the branch viewer, but on the main one. If someone's going to use voice chat, they should have lipsync as well. -Ron On Wed, Apr 29, 2009 at 9:57 PM, Gordon Wendt wrote: > To answer the question as to why I hold my view, I think I answered it well > enough on the JIRA issue.? Incidentally I don't agree with many of the other > opinions here but I just wanted to say that I do not agree with Anne and > that my views are nowhere near that extreme, there are plenty of options > that definitely should be on by default I just don't believe this is one of > them and regardless of the motives in doing so I resent this being pushed > through the back door.? There are still legitimate ways to do this without > sneaking in through a little heard of (outside of this list) branch of the > viewer and trying to do this reflects very poorly on the ethics of both the > people supporting this attempt and the Lindens who are supporting it. > > -Gordon > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -- Ron Blechner Chief Technology Officer Involve, Inc www.involve3d.com From merov at lindenlab.com Wed Apr 29 23:23:43 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Wed, 29 Apr 2009 23:23:43 -0700 Subject: [sldev] Crash reports analysis [http-texture builds] Message-ID: <9E20290B-FB30-423B-A266-EF6ECF480E95@lindenlab.com> Hi, So I've been digging through the crash reports and tried to evaluate how we're doing. Here's some data, I'll give some conclusions at the end. Crashers since one week ----------------------------------- Looking into the crashers on the "Second Life OSS" builds since we're doing them, this is what I see: Total : 30 crashers - VWR-12775 : 12 - OpenJPEG : 3 - VWR-13065: 2 - VWR-13066 : 2 - VWR-12827: 2 - Unusable stacks: 9 Clearly, the notorious VWR-12775 (LLTextureFetchWorker::callbackDecoded crasher) is the one that's impeding reliability. If you're unlucky, you can crash repeatedly over and over as I noticed that you can meet that crash just reading the cache at launch... If I look from the beginning of the month, I get 32 such crashers out of 108. Looking into "CommunityDeveloper" channel shows 6 out of 17 crashers. That's a fairly consistent 30% of crashes due to this problem. VWR-12827 is the LLVertexBuffer one and was fixed with the merge of 1.23 Second Life OSS Build 1.23.0 2166 ------------------------------------------------ This is the most recent "1.23 + http-texture" merge build and is only a couple of days old. Total : 12 crashers - VWR-12775 : 1 - OpenJPEG : 2 - VWR-13065: 2 - VWR-13066 : 1 - Unusable stacks: 6 There's no obvious pattern except that VWR-12827 disappeared (as expected) but VWR-12065 emerged (badNetworkHandler exception). Still, not much data to see anything new. I have anecdotal data that VWR-12775 is still very prevalent and that most of those crashes are not reported. I sure can repro that one easily. Conclusion --------------- VWR-12775 LLTextureFetchWorker::callbackDecoded() is the bad guy. I've seen actually a couple of different stacks but they are all rooted down to the same problem. Several people on this list commented in the PJIRA and even proposed patches (thanks Robin!). Discussing this with the lead dev though, he thinks we better get to the deep down reason as to why we get the fetch worker into a state that is not supposed to even exist (in the intent of the code at least), rather than just writing it down to a race condition, detecting the weird state and avoiding the crash. Right now then, I'm tracing when this state happens (and it happens plenty, most of the time without getting into a crashing tangle) and writing unit tests to ensure the logic is sound and well understood. Writing unit tests for threaded code is a little tricky (actually, we don't have example of this in our still skimpy set of unit tests so, I'm blazing new trails here...) but is worthwhile. At the same time, I'm tasked with updating the doc (http://wiki.secondlife.com/wiki/HTTP_Texture ) as I go. That keeps me busy which explain (but doesn't excuse) I was not super responsive on the list today. Apologies for this. The OpenJPEG crashers are concerning. There are unfortunately little info in the stack trace and I haven't myself experienced that one. What's strange is that I looked into the other viewers crash logs (thousands of them) and it doesn't surface at all in their crashers. May be of note: our 2 crashers happen on Vista. Does this ring a bell to anyone? Keep testing and the logs (with symbols!) coming. This is extremely useful. Any idea on the here above reported crashes will be very much appreciated. Cheers, - Merov From chaosstar at gmail.com Wed Apr 29 23:34:38 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 30 Apr 2009 08:34:38 +0200 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <49F67F3D.1010307@gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> Message-ID: <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> On Tue, Apr 28, 2009 at 05:59, Tateru Nino wrote: > Also: distribution with Quicktime support, FMOD, the art assets, the fonts. > (I believe I know the correct answer to the latter two - but we may as well > get it all clarified in one go, right?) > > Have we missed any pieces? I think those, along with vivox and Kakadu are all pieces. Quicktime support is no problem, as it checks against an installed Quicktime on the system. The fonts can be easily exchanged by ones under a more open license like Creative Commons. This already has been done in some 3rd party viewers, and they look excellent. I personally suggest to push for that change in the official client as well..it will save some hassle overall. Distribution with FMOD...well. This is interesting. By its licence the fmod.dll can -not- be distributed with 3rd party viewers, else we get another GPL violation. OpenAL is no problem tho. Art assets..I don't know. Maybe, with the exception of the SL logo, a push to get those under the Creative Commons could be achieved. From robin.cornelius at gmail.com Thu Apr 30 00:42:35 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 30 Apr 2009 08:42:35 +0100 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> Message-ID: On Thu, Apr 30, 2009 at 7:34 AM, Ambrosia wrote: > > Quicktime support is no problem, as it checks against an installed > Quicktime on the system. Be a little careful of quicktime, on Macs its part of the operating system/standard distribution so linking against is fine under the GPL, on windows its certainly not part of the operating system so your in danger of GPL issues here right away on on mac platforms. > The fonts can be easily exchanged by ones under a more open license > like Creative Commons. This already has been done in some 3rd party > viewers, and they look excellent. I personally suggest to push for > that change in the official client as well..it will save some hassle > overall. > +1 Fonts can be easily solved this way, although LL has expressed in the past a desire to stick to the current fonts because of branding reasons, a common look at people are use to and expect. > > Art assets..I don't know. Maybe, with the exception of the SL logo, a > push to get those under the Creative Commons could be achieved. the artwork files are already under the CC-SA-3.0, they were under the CC-SA-2.5 which is not considered free by some people. But yea watch out for the images that also have a trademark. Probably at some point LL could stop exporting the trademarked images and use a replacement so ALL 3rd party builds will either use the new default free images or have to supply there own for their own skinning. I think this was breifly discussed for http-texure. Robin From chaosstar at gmail.com Thu Apr 30 02:05:39 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 30 Apr 2009 11:05:39 +0200 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> Message-ID: <9bb32d430904300205w35e4c29aq6f2ff08406acad4c@mail.gmail.com> > Be a little careful of quicktime, on Macs its part of the operating > system/standard distribution so linking against is fine under the GPL, > on windows its certainly not part of the operating system so your in > danger of GPL issues here right away on on mac platforms. > > Robin > Hmh. From what I'm reading on various sites...true, and probably a widely-overlooked thing. Basically it means any 3rd party client having the quicktime-support enabled in the build process isn't GPL compatible, That's what the LGPL is for, unless I'm mistaken..but the viewer isn't licensed under that :| Meh. From chaosstar at gmail.com Thu Apr 30 02:13:30 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 30 Apr 2009 11:13:30 +0200 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904300205w35e4c29aq6f2ff08406acad4c@mail.gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300205w35e4c29aq6f2ff08406acad4c@mail.gmail.com> Message-ID: <9bb32d430904300213t1bf04012o15009f7619dd82a9@mail.gmail.com> On Thu, Apr 30, 2009 at 11:05, Ambrosia wrote: > That's what the LGPL is for, unless I'm mistaken Note: Actually I am mistaken. LGPL allows a LGPL'd library to be linked to a proprietary app, not vice versa. From chaosstar at gmail.com Thu Apr 30 02:37:48 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 30 Apr 2009 11:37:48 +0200 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> Message-ID: <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> > Be a little careful of quicktime, on Macs its part of the operating > system/standard distribution so linking against is fine under the GPL, > on windows its certainly not part of the operating system so your in > danger of GPL issues here right away on on mac platforms. I just realized that we've been forgetting the FLOSS exception that LL added to the viewer license. So yes, a 3rd party viewer can have quicktime support, as well as FMOD. Duh. Big duh. The original question of the discussion wasn't quite referring to making a pure-GPL-compatible viewer. So basically this boils down to the same old spiel...can distribute the viewer, can not package it with llKDU, the vivox components, fonts. Am I correct in that analysis of it all? From robin.cornelius at gmail.com Thu Apr 30 03:00:50 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 30 Apr 2009 11:00:50 +0100 Subject: [sldev] Crash reports analysis [http-texture builds] In-Reply-To: <9E20290B-FB30-423B-A266-EF6ECF480E95@lindenlab.com> References: <9E20290B-FB30-423B-A266-EF6ECF480E95@lindenlab.com> Message-ID: On Thu, Apr 30, 2009 at 7:23 AM, Philippe Bossut (Merov Linden) wrote: > The OpenJPEG crashers are concerning. There are unfortunately little > info in the stack trace and I haven't myself experienced that one. > What's strange is that I looked into the other viewers crash logs > (thousands of them) and it doesn't surface at all in their crashers. > May be of note: our 2 crashers happen on Vista. Does this ring a bell > to anyone? > I surprised that that you have not had more reports on this. Certainly some of us have seen this fairly frequently who are building ourselves and it usually is triggers from the LLImageJ2COJ::getMetadata() during some where in opj_image_destroywhen a wild pointer is freed (possible also related to a bad image being fed to decode). This is fixed in openjpeg SVN and i think those of us on #opensl who are building http-texture already have this patched (or at least a good few do). Although its possible (I would need to confirm) that we see it because this was introduced in openjpeg 1.3 and LL are still on 1.2 internally and also this could explain why we don't see any other crashes here. Looking at http://www.openjpeg.org/websvn/filedetails.php?repname=OpenJpeg&path=%2Ftrunk%2Flibopenjpeg%2Fimage.c&rev=0&sc=0 the opj_free(image->comps); is the offending line, note in the SVN web view the structures are allocated with opj_calloc() where as the older code uses opj_malloc() which does not null the pointers. There may also need to be some viewer sanity checking here as well as various image-> members are used in LLImageJ2COJ::getMetadata() and although i've not see a crash directly because of their use after patching openjpeg its probably worth investigating to ensure no edge case is creeping in here. Robin From carlo at alinoe.com Thu Apr 30 03:24:49 2009 From: carlo at alinoe.com (Carlo Wood) Date: Thu, 30 Apr 2009 12:24:49 +0200 Subject: [sldev] Crash reports analysis [http-texture builds] In-Reply-To: <9E20290B-FB30-423B-A266-EF6ECF480E95@lindenlab.com> References: <9E20290B-FB30-423B-A266-EF6ECF480E95@lindenlab.com> Message-ID: <20090430102449.GA7141@alinoe.com> On Wed, Apr 29, 2009 at 11:23:43PM -0700, Philippe Bossut (Merov Linden) wrote: > The OpenJPEG crashers are concerning. There are unfortunately little > info in the stack trace and I haven't myself experienced that one. > What's strange is that I looked into the other viewers crash logs > (thousands of them) and it doesn't surface at all in their crashers. > May be of note: our 2 crashers happen on Vista. Does this ring a bell > to anyone? I reported an openjpeg crash bug here: http://groups.google.com/group/openjpeg/browse_thread/thread/91c951104e184488?hl=en Imho, this cannot be fixed in the viewer. Also, I think it only happens with a corrupt image. -- Carlo Wood From aimee.trescothick at gmail.com Thu Apr 30 03:32:43 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Thu, 30 Apr 2009 11:32:43 +0100 Subject: [sldev] Calling Cards (was Re: VWR-10311 Enabling lip sync by default) In-Reply-To: <49F9047D.8030809@gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> <49F7792C.3080504@gmail.com> <77c421f00904281702i3ad90e4cl7610c8eda511e623@mail.gmail.com> <7765f2c60904281948s3cf3a9f6pb8b29cebcee0dcd7@mail.gmail.com> <49F9047D.8030809@gmail.com> Message-ID: On 30 Apr 2009, at 02:53, Jason Giglio wrote: > Soft wrote: >> One can also create a folder of calling cards and right-click on it >> to >> start a group chat with that set of resis. I believe calling cards >> can >> also be dragged into an existing multi-user chat to invite more >> attendees. This is really functionality that should exist in the >> contact manager. I suspect it was done the current way for >> implementation expediency. >> > > It's already in the contact manager too... IIRC you can ctrl-select > multiple friends and initiate a friends chat that way. That's not really the same though, for example I have the calling cards of a small group of friends that regularly go exploring together in a folder, so I can quickly start an ad-hoc group chat with them without having to search for and select each name in my friends list every time. To do the same there would need to be way of grouping your own friends list, or tagging contacts. As far as I know there's no other way of adding people to an existing ad-hoc chat without dragging calling cards at present. Aimee. From stickman at gmail.com Thu Apr 30 03:35:17 2009 From: stickman at gmail.com (Stickman) Date: Thu, 30 Apr 2009 03:35:17 -0700 Subject: [sldev] Calling Cards (was Re: VWR-10311 Enabling lip sync by default) In-Reply-To: References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49EFCBC0.6030908@lindenlab.com> <49F7792C.3080504@gmail.com> <77c421f00904281702i3ad90e4cl7610c8eda511e623@mail.gmail.com> <7765f2c60904281948s3cf3a9f6pb8b29cebcee0dcd7@mail.gmail.com> <49F9047D.8030809@gmail.com> Message-ID: > To do the same there would need to be way of grouping your > own friends list, or tagging contacts. Looking forward to http://jira.secondlife.com/browse/VWR-890 that would allow this. Guess they'll have to get that one in first before they do away with calling cards. ;) Stickman From open at autistici.org Thu Apr 30 03:43:46 2009 From: open at autistici.org (Opensource Obscure) Date: Thu, 30 Apr 2009 10:43:46 +0000 Subject: [sldev] [WEB][IDEA] Blog comments need "Ignore this user" feature Message-ID: <6dfb8cda1c817372f3540feef1e53072@localhost> I just created http://jira.secondlife.com/browse/WEB-1074 that is - 'Blog comments need "Ignore this user" feature' Please comment and vote it, if you agree this option may be useful in some cases. Here are some details about it. A relevant number of people use / abuse the blog comments. Some examples: * slighlty offensive / provoking statements against other residents * bashing Linden Lab's work * going off-topic * asking help instead of using Support * complaining about bugs instead of using PJIRA I want to be able to 'mute' (on my side) those blog users that I think are consistently abusing the comments system, and / or using it to flame and start unuseful arguments. This is already working on the forum - I need a similar feature on the blog. As a non-english mother tongue reader, having to read many comments makes the blogs reading very hard to me. Every tool that helps me to avoid unuseful comments is good. This can't be accomplished with technichal features, but - I found on the SL forums that "Ignore this user" is a very helpful feature. After I read 3-4 comments by the same user and I find that all of them are stupid, offensive, or simply 100% unuseful, I start "ignoring" that user. This can be good or bad on a subjective/individual point of view. But it's a good OPTION. I like to be ABLE TO do it. I'd like if I could do the same on the blogs. If I could hide comments by notorious trolls and whiners, I'd have a much better blog experience. Otherwise, I will probably have to stop reading blog comments. Note that this is not about moderation. I'm not asking for a more strict moderation about Linden Lab. I'm not saying those users are infringing on any policy. I just want to make my SL experience _more predictable_ (on blogs too). ;-) Opensource Obscure From aimee.trescothick at gmail.com Thu Apr 30 03:47:07 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Thu, 30 Apr 2009 11:47:07 +0100 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> Message-ID: On 30 Apr 2009, at 02:57, Gordon Wendt wrote: > ... I resent this being pushed through the back door. There are > still legitimate ways to do this without sneaking in through a > little heard of (outside of this list) branch of the viewer and > trying to do this reflects very poorly on the ethics of both the > people supporting this attempt and the Lindens who are supporting it. Please lets not blow this out of proportions and insinuate there's anything underhand going on here, there isn't, no one is sneaking around or hiding anything. This branch is intended to be the front door, the main route for Open Source contributions in future, it's only little known right now as this will be the first cycle. Aimee. From me at signpostmarv.name Thu Apr 30 05:19:34 2009 From: me at signpostmarv.name (SignpostMarv Martin) Date: Thu, 30 Apr 2009 13:19:34 +0100 Subject: [sldev] [WEB][IDEA] Blog comments need "Ignore this user" feature In-Reply-To: <6dfb8cda1c817372f3540feef1e53072@localhost> References: <6dfb8cda1c817372f3540feef1e53072@localhost> Message-ID: <49F99756.9010102@signpostmarv.name> I could add this with Gears + Greasemonkey. :-P I would've already done this, but a convo with Gwyn on the topic of free speech changed my mind. I'll consider doing it if there's sufficient demand :-) ~ Marv. Opensource Obscure wrote: > I just created http://jira.secondlife.com/browse/WEB-1074 > that is - 'Blog comments need "Ignore this user" feature' > > Please comment and vote it, if you agree this option > may be useful in some cases. > Here are some details about it. > > A relevant number of people use / abuse the blog comments. > Some examples: > * slighlty offensive / provoking statements against other residents > * bashing Linden Lab's work > * going off-topic > * asking help instead of using Support > * complaining about bugs instead of using PJIRA > > I want to be able to 'mute' (on my side) those blog users > that I think are consistently abusing the comments system, > and / or using it to flame and start unuseful arguments. > > This is already working on the forum - I need a similar > feature on the blog. > > As a non-english mother tongue reader, having to read many > comments makes the blogs reading very hard to me. > > Every tool that helps me to avoid unuseful comments is good. > This can't be accomplished with technichal features, but - > I found on the SL forums that "Ignore this user" is a very > helpful feature. After I read 3-4 comments by the same user > and I find that all of them are stupid, offensive, or > simply 100% unuseful, I start "ignoring" that user. > > This can be good or bad on a subjective/individual point > of view. But it's a good OPTION. I like to be ABLE TO do it. > > I'd like if I could do the same on the blogs. > > If I could hide comments by notorious trolls and whiners, > I'd have a much better blog experience. Otherwise, I will > probably have to stop reading blog comments. > > Note that this is not about moderation. I'm not asking > for a more strict moderation about Linden Lab. I'm not > saying those users are infringing on any policy. > > I just want to make my SL experience _more predictable_ > (on blogs too). > > ;-) > > Opensource Obscure > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3244 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090430/d96deeed/attachment-0001.bin From secret.argent at gmail.com Thu Apr 30 05:23:17 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 30 Apr 2009 07:23:17 -0500 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> Message-ID: <0CC35484-2F37-4755-B40C-E8E3797C35B6@gmail.com> On 2009-04-30, at 01:34, Ambrosia wrote: > Quicktime support is no problem, as it checks against an installed > Quicktime on the system. That only helps with Mac OS X. Quicktime is not part of Microsoft's distribution so you can't distribute a GPLed Windows viewer linked against Quicktime. From secret.argent at gmail.com Thu Apr 30 05:24:36 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 30 Apr 2009 07:24:36 -0500 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904300213t1bf04012o15009f7619dd82a9@mail.gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300205w35e4c29aq6f2ff08406acad4c@mail.gmail.com> <9bb32d430904300213t1bf04012o15009f7619dd82a9@mail.gmail.com> Message-ID: <40DF4E98-EBC9-49BA-96F3-3916FACAFC49@gmail.com> On 2009-04-30, at 04:13, Ambrosia wrote: > Actually I am mistaken. LGPL allows a LGPL'd library to be linked to a > proprietary app, not vice versa. It works either way, since the app is also a library. From secret.argent at gmail.com Thu Apr 30 05:25:50 2009 From: secret.argent at gmail.com (Argent Stonecutter) Date: Thu, 30 Apr 2009 07:25:50 -0500 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> Message-ID: On 2009-04-30, at 04:37, Ambrosia wrote: > I just realized that we've been forgetting the FLOSS exception that LL > added to the viewer license. So yes, a 3rd party viewer can have > quicktime support, as well as FMOD. Duh. Big duh. Not so, Quicktime isn't F/L/OSS. From chaosstar at gmail.com Thu Apr 30 06:01:04 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 30 Apr 2009 15:01:04 +0200 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> Message-ID: <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> Quote: 'The viewer is licensed under the GPLv2 with an additional FLOSS exception. This FLOSS exception allows linking to GPL-incompatible libraries.' On Thu, Apr 30, 2009 at 14:25, Argent Stonecutter wrote: > > On 2009-04-30, at 04:37, Ambrosia wrote: >> I just realized that we've been forgetting the FLOSS exception that LL >> added to the viewer license. So yes, a 3rd party viewer can have >> quicktime support, as well as FMOD. Duh. Big duh. > > Not so, Quicktime isn't F/L/OSS. > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From open at autistici.org Thu Apr 30 05:37:01 2009 From: open at autistici.org (Opensource Obscure) Date: Thu, 30 Apr 2009 12:37:01 +0000 Subject: [sldev] [WEB][IDEA] Blog comments need "Ignore this user" feature In-Reply-To: <49F99756.9010102@signpostmarv.name> References: <6dfb8cda1c817372f3540feef1e53072@localhost> <49F99756.9010102@signpostmarv.name> Message-ID: <854115f0e396f2c0d4f77675778f6f83@localhost> I don't use Greasemonkey, and I think that most users don't use it or won't install it. But Marv's proposal could be a good alternative solution if Linden Lab couldn't implement this new feature in a reasonable time. Thanks for your offer! I think that the free-speech issue shouldn't be discussed on this list, as I think it's sort of off-topic. It's an important topic though. Both "ignore forum user" and "free speech" topics have been debated in this thread on the official forums: http://forums.secondlife.com/showthread.php?t=309660 Free speech has a *great* value to me. I wrote what I think about "ignore" feature and free speech in this reply: http://forums.secondlife.com/showpost.php?p=2340656&postcount=75 ciao, Opensource Obscure On Thu, 30 Apr 2009 13:19:34 +0100, SignpostMarv Martin wrote: > I could add this with Gears + Greasemonkey. :-P > > I would've already done this, but a convo with Gwyn on the topic of free > speech changed my mind. > > I'll consider doing it if there's sufficient demand :-) > > > ~ Marv. > > Opensource Obscure wrote: >> I just created http://jira.secondlife.com/browse/WEB-1074 >> that is - 'Blog comments need "Ignore this user" feature' >> >> Please comment and vote it, if you agree this option >> may be useful in some cases. >> Here are some details about it. >> >> A relevant number of people use / abuse the blog comments. >> Some examples: >> * slighlty offensive / provoking statements against other residents >> * bashing Linden Lab's work >> * going off-topic >> * asking help instead of using Support >> * complaining about bugs instead of using PJIRA >> >> I want to be able to 'mute' (on my side) those blog users >> that I think are consistently abusing the comments system, >> and / or using it to flame and start unuseful arguments. >> >> This is already working on the forum - I need a similar >> feature on the blog. >> >> As a non-english mother tongue reader, having to read many >> comments makes the blogs reading very hard to me. >> >> Every tool that helps me to avoid unuseful comments is good. >> This can't be accomplished with technichal features, but - >> I found on the SL forums that "Ignore this user" is a very >> helpful feature. After I read 3-4 comments by the same user >> and I find that all of them are stupid, offensive, or >> simply 100% unuseful, I start "ignoring" that user. >> >> This can be good or bad on a subjective/individual point >> of view. But it's a good OPTION. I like to be ABLE TO do it. >> >> I'd like if I could do the same on the blogs. >> >> If I could hide comments by notorious trolls and whiners, >> I'd have a much better blog experience. Otherwise, I will >> probably have to stop reading blog comments. >> >> Note that this is not about moderation. I'm not asking >> for a more strict moderation about Linden Lab. I'm not >> saying those users are infringing on any policy. >> >> I just want to make my SL experience _more predictable_ >> (on blogs too). >> >> ;-) >> >> Opensource Obscure >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> From tom at streamsense.net Thu Apr 30 06:03:58 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu, 30 Apr 2009 14:03:58 +0100 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> Message-ID: <49F9A1BE.7070902@streamsense.net> Ambrosia wrote: > Quote: > > 'The viewer is licensed under the GPLv2 with an additional FLOSS > exception. This FLOSS exception allows linking to GPL-incompatible > libraries.' > > It only applies to compatible licenses. http://www.alfresco.com/legal/licensing/floss_exception/ section 2, FLOSS license list. ~T From chaosstar at gmail.com Thu Apr 30 06:04:55 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 30 Apr 2009 15:04:55 +0200 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> Message-ID: <9bb32d430904300604i58b2d0f5l6eccfd1e4470210a@mail.gmail.com> Nevermind, I see what you mean. This is kind of bad news then, given that there is hardly a viable alternative for Windows builds right now. There is GStreamer, but...last I checked, GStreamer under Windows is kind of incomplete and/or rather old, Version-wise. On Thu, Apr 30, 2009 at 15:01, Ambrosia wrote: > Quote: > > 'The viewer is licensed under the GPLv2 with an additional FLOSS > exception. This FLOSS exception allows linking to GPL-incompatible > libraries.' > > On Thu, Apr 30, 2009 at 14:25, Argent Stonecutter > wrote: >> >> On 2009-04-30, at 04:37, Ambrosia wrote: >>> I just realized that we've been forgetting the FLOSS exception that LL >>> added to the viewer license. So yes, a 3rd party viewer can have >>> quicktime support, as well as FMOD. Duh. Big duh. >> >> Not so, Quicktime isn't F/L/OSS. >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/SLDev >> Please read the policies before posting to keep unmoderated posting privileges >> > From tom at streamsense.net Thu Apr 30 06:06:10 2009 From: tom at streamsense.net (Thomas Grimshaw) Date: Thu, 30 Apr 2009 14:06:10 +0100 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904300604i58b2d0f5l6eccfd1e4470210a@mail.gmail.com> References: <001501c9c553$a59172e0$6500a8c0@hp> <49F652EF.8070909@gmail.com> <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> <9bb32d430904300604i58b2d0f5l6eccfd1e4470210a@mail.gmail.com> Message-ID: <49F9A242.8040408@streamsense.net> Roll on VideoLAN. :) It's about time we integrated a player that didn't suck. ~T Ambrosia wrote: > Nevermind, I see what you mean. This is kind of bad news then, given > that there is hardly a viable alternative for Windows builds right > now. There is GStreamer, but...last I checked, GStreamer under Windows > is kind of incomplete and/or rather old, Version-wise. > > On Thu, Apr 30, 2009 at 15:01, Ambrosia wrote: > >> Quote: >> >> 'The viewer is licensed under the GPLv2 with an additional FLOSS >> exception. This FLOSS exception allows linking to GPL-incompatible >> libraries.' >> >> On Thu, Apr 30, 2009 at 14:25, Argent Stonecutter >> wrote: >> >>> On 2009-04-30, at 04:37, Ambrosia wrote: >>> >>>> I just realized that we've been forgetting the FLOSS exception that LL >>>> added to the viewer license. So yes, a 3rd party viewer can have >>>> quicktime support, as well as FMOD. Duh. Big duh. >>>> >>> Not so, Quicktime isn't F/L/OSS. >>> >>> _______________________________________________ >>> Policies and (un)subscribe information available here: >>> http://wiki.secondlife.com/wiki/SLDev >>> Please read the policies before posting to keep unmoderated posting privileges >>> >>> > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges > From chaosstar at gmail.com Thu Apr 30 06:12:55 2009 From: chaosstar at gmail.com (Ambrosia) Date: Thu, 30 Apr 2009 15:12:55 +0200 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <49F9A242.8040408@streamsense.net> References: <002801c9c7af$bc792530$0700a8c0@hp> <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> <9bb32d430904300604i58b2d0f5l6eccfd1e4470210a@mail.gmail.com> <49F9A242.8040408@streamsense.net> Message-ID: <9bb32d430904300612x1274bfa8y31a764f5c6009f53@mail.gmail.com> On Thu, Apr 30, 2009 at 15:06, Thomas Grimshaw wrote: > Roll on VideoLAN. :) It's about time we integrated a player that didn't > suck. > > ~T > Seriously. On a note, with the FLOSS exception not including the licenses for Quicktime, FMOD and Vivox..I sense a massive oversight on part of LL here. This quite frankly renders third party viewers useless for most residents. Those who don't care about any Backgrounds and want their voice and streaming videos. I can't check right now, but does anybody have insight about how much/if Vivox actually gets linked dynamically? If it's merely the seperate SLvoice.exe that gets started with parameters that uses the dlls, it still can be used by a GPL/FLOSS viewer, as that'd pretty much fall under the 'plug-in' exception in the GPL. From robin.cornelius at gmail.com Thu Apr 30 06:41:23 2009 From: robin.cornelius at gmail.com (Robin Cornelius) Date: Thu, 30 Apr 2009 14:41:23 +0100 Subject: [sldev] Vivox and Kakadu licensing issues. In-Reply-To: <9bb32d430904300612x1274bfa8y31a764f5c6009f53@mail.gmail.com> References: <49F67F3D.1010307@gmail.com> <9bb32d430904292334q4ab8b9j32d0656a5021fae6@mail.gmail.com> <9bb32d430904300237w5db5ce6apcc67ef0141d408@mail.gmail.com> <9bb32d430904300601g37b4a386rc74099cb4c42b746@mail.gmail.com> <9bb32d430904300604i58b2d0f5l6eccfd1e4470210a@mail.gmail.com> <49F9A242.8040408@streamsense.net> <9bb32d430904300612x1274bfa8y31a764f5c6009f53@mail.gmail.com> Message-ID: On Thu, Apr 30, 2009 at 2:12 PM, Ambrosia wrote: > > I can't check right now, but does anybody have insight about how > much/if Vivox actually gets linked dynamically? If it's merely the > seperate SLvoice.exe that gets started with parameters that uses the > dlls, it still can be used by a GPL/FLOSS viewer, as that'd pretty > much fall under the 'plug-in' exception in the GPL. Vivox is not linked in anyway to the viewer,it is a standalone application that communicates to the viewer via a local network socket. the vivox program itself opens the audio devices for sound and microphone. Robin From GordonWendt at gmail.com Thu Apr 30 07:43:28 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Thu, 30 Apr 2009 10:43:28 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: References: <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> Message-ID: <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> Aimee, maybe in the future but currently it's for a smaller branch that will eventually get merged in and go live. I suggest reading up btw, it's tough to assume good faith when people pushing this even admit that they're being sneaky and underhanded trying to get this in the back door. -Gordon On Thu, Apr 30, 2009 at 6:47 AM, Aimee Trescothick < aimee.trescothick at gmail.com> wrote: > > On 30 Apr 2009, at 02:57, Gordon Wendt wrote: > > > ... I resent this being pushed through the back door. There are > > still legitimate ways to do this without sneaking in through a > > little heard of (outside of this list) branch of the viewer and > > trying to do this reflects very poorly on the ethics of both the > > people supporting this attempt and the Lindens who are supporting it. > > Please lets not blow this out of proportions and insinuate there's > anything underhand going on here, there isn't, no one is sneaking > around or hiding anything. This branch is intended to be the front > door, the main route for Open Source contributions in future, it's > only little known right now as this will be the first cycle. > > Aimee. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/2926d742/attachment.htm From GordonWendt at gmail.com Thu Apr 30 07:45:02 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Thu, 30 Apr 2009 10:45:02 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> References: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> Message-ID: <493033a70904300745o201f886fnf2f553b9706cbe01@mail.gmail.com> Ron, I'm not ignoring your post btw, I read it last night and again today and I'm mulling it over. You do make some good points. -Gordon -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/cc40bb13/attachment.htm From monkowsk at watson.ibm.com Thu Apr 30 08:18:26 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu, 30 Apr 2009 11:18:26 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> References: <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> Message-ID: <49F9C142.7060904@watson.ibm.com> Gordon, I did admit that I am trying to get this in the main viewer. I never characterized it as "sneaky and underhanded" nor do I believe it is. I am under the impression that all of these open source viewer projects are intended to eventually get merged in and go live. The hppt-texture branch http://svn.secondlife.com/trac/linden/browser/branches/2009/http-texture became the http-texture project http://svn.secondlife.com/trac/linden/browser/projects/2009/http-texture Yeah, I'm confused too (but not sneaky or underhanded) :-). There needs to be a whole lot more documented on this new open source viewer concept. Mike Gordon Wendt wrote: > Aimee, maybe in the future but currently it's for a smaller branch that > will eventually get merged in and go live. I suggest reading up btw, > it's tough to assume good faith when people pushing this even admit that > they're being sneaky and underhanded trying to get this in the back door. From q at lindenlab.com Thu Apr 30 08:37:09 2009 From: q at lindenlab.com (Kent Quirk (Q Linden)) Date: Thu, 30 Apr 2009 11:37:09 -0400 Subject: [sldev] Open Source Meeting, 2PM PDT, Hippotropolis Message-ID: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com> Please add items to the agenda if you wish: http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda I'll be hosting today. Q From monkowsk at watson.ibm.com Thu Apr 30 08:58:18 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu, 30 Apr 2009 11:58:18 -0400 Subject: [sldev] Open Source Meeting, 2PM PDT, Hippotropolis In-Reply-To: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com> References: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com> Message-ID: <49F9CA9A.2000103@watson.ibm.com> I added: > # VWR-6198 Is anyone at Linden listening? Mm Alder 15:57, 30 April 2009 (UTC) > # Can we get better documentation on the open source viewer project (aka http-texture)? Is there anyone other than me who would be interested in open code reviews for this project? Mm Alder 15:57, 30 April 2009 (UTC) Kent Quirk (Q Linden) wrote: > Please add items to the agenda if you wish: > > http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > I'll be hosting today. > > Q > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From merov at lindenlab.com Thu Apr 30 09:45:42 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 30 Apr 2009 09:45:42 -0700 Subject: [sldev] About the http-texture project In-Reply-To: <49F9C142.7060904@watson.ibm.com> References: <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> <49F9C142.7060904@watson.ibm.com> Message-ID: <6DA98012-931B-4B4F-8BD7-5D3249FD073E@lindenlab.com> Hi Mike, I saw you have some questions about the branches, the projects and http-texture in your last 2 posts: On Apr 30, 2009, at 8:18 AM, Mike Monkowski wrote: > I am under the impression that all of these open source viewer > projects are intended to eventually get merged in and go live. The > hppt-texture branch > http://svn.secondlife.com/trac/linden/browser/branches/2009/http-texture > became the http-texture project > http://svn.secondlife.com/trac/linden/browser/projects/2009/http-texture OK, there is some confusion here: the project did not "become" something else. The purpose of the "branches" and "projects" svn nodes are mechanical svn conventions we use to make our merge work easier, *both* relate to the same project (called "http-texture" for the time being). I tried to explain that in a previous post: On Apr 24, 2009, at 3:36 PM, Philippe Bossut (Merov Linden) wrote: > "branches" is the parking repository for the "vendor" version, the > code that gets exported by LL into the OSS realm. That's where code > lands when they throw it over the wall (I'm being > facetious here with my use of vocabulary and, in that particular > instance, that's me throwing code over the wall). We (as > open source developers) are not supposed to modify branches ever. They > are sacred and represent what comes from Lindens. We build it though > to make sure it's not evil, that our changes don't get stomped by > Linden updates and that we like it enough to merge it into our > projects. Rob followed by a post of his own and updated the wiki describing the branches: http://wiki.secondlife.com/wiki/Source_branches I hope this clears the objective of the svn hierarchy. > Yeah, I'm confused too (but not sneaky or underhanded) :-). There > needs to be a whole lot more documented on this new open source viewer > concept. Not sure which missing documentation you're referring to but we have 3 at the moment: - https://wiki.secondlife.com/wiki/HTTP_Texture_Development : describes what we're trying to achieve in the next roll of this release - http://wiki.secondlife.com/wiki/HTTP_Texture : goes into gory details about the http-texture background work (clearly needs more work) - http://wiki.secondlife.com/wiki/S3_based_viewer_map : goes into the implementation of the new map UI, the only part of the project that pulls jpeg textures using http There are things we discussed but haven't documented yet, mostly: - gather perf data as part of the builds: we are thinking about just picking the launch time as a first goal on that road. I've been looking at attempt at this internally as several groups independently tried this already. Ideas from the group on this would be great! - crash rate reports: we're doing some reading manually but we need to extract some data and post them in a graph form somewhere automatically. Since this means accessing some DB not available publicly, this is clearly a task that's on Linden's laps. Hope this answer some of your questions. I saw you added this to the agenda for this afternoon's Hippo meeting so we'll discuss that subject there again. Cheers, - Merov From fire at b3dMultitech.com Thu Apr 30 10:01:27 2009 From: fire at b3dMultitech.com (Fire) Date: Thu, 30 Apr 2009 10:01:27 -0700 Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) Message-ID: <1dabc2a30904301001w24fe8d6dmfbccba2cfce2eaa5@mail.gmail.com> Hi everyone, The http-texture project sounds fascinating! If every texture in SL could actually be fed in via http - that would rock the SL world, especially for educators. Just wondering how far off the http-texture branch is to being fully functional. Please forgive me as I am not that familiar with the http-texture project as of yet... Thanks in advance! Cheers *Paul 'Fire' Preibisch* Educator, Content Creator, Virtual World Builder, Web 2.0 Consultant [image: Spreadfirefox Affiliate Button] [image: Spreadfirefox Affiliate Button] *Connect your Facebook Profile with your Second Life! http://apps.facebook.com/second-life/* *Need a Learning Management System for Second Life?Use Sloodle! * *Skype: Eslteacherlink.com* *Services: *Second Life Virtual World Construction, Machinima - Animation, Joomla Programming, Educational Website, LibsecondLife, Virtual Event Services Fire Centaur in Second Life On Thu, Apr 30, 2009 at 9:45 AM, Philippe Bossut (Merov Linden) < merov at lindenlab.com> wrote: > Hi Mike, > > I saw you have some questions about the branches, the projects and > http-texture in your last 2 posts: > > On Apr 30, 2009, at 8:18 AM, Mike Monkowski wrote: > > I am under the impression that all of these open source viewer > > projects are intended to eventually get merged in and go live. The > > hppt-texture branch > > http://svn.secondlife.com/trac/linden/browser/branches/2009/http-texture > > became the http-texture project > > http://svn.secondlife.com/trac/linden/browser/projects/2009/http-texture > > OK, there is some confusion here: the project did not "become" > something else. The purpose of the "branches" and "projects" svn nodes > are mechanical svn conventions we use to make our merge work easier, > *both* relate to the same project (called "http-texture" for the time > being). I tried to explain that in a previous post: > > On Apr 24, 2009, at 3:36 PM, Philippe Bossut (Merov Linden) wrote: > > "branches" is the parking repository for the "vendor" version, the > > code that gets exported by LL into the OSS realm. That's where code > > lands when they throw it over the wall (I'm being > > facetious here with my use of vocabulary and, in that particular > > instance, that's me throwing code over the wall). We (as > > open source developers) are not supposed to modify branches ever. They > > are sacred and represent what comes from Lindens. We build it though > > to make sure it's not evil, that our changes don't get stomped by > > Linden updates and that we like it enough to merge it into our > > projects. > > > Rob followed by a post of his own and updated the wiki describing the > branches: > http://wiki.secondlife.com/wiki/Source_branches > > I hope this clears the objective of the svn hierarchy. > > > Yeah, I'm confused too (but not sneaky or underhanded) :-). There > > needs to be a whole lot more documented on this new open source viewer > > concept. > > Not sure which missing documentation you're referring to but we have 3 > at the moment: > - https://wiki.secondlife.com/wiki/HTTP_Texture_Development : > describes what we're trying to achieve in the next roll of this release > - http://wiki.secondlife.com/wiki/HTTP_Texture : goes into gory > details about the http-texture background work (clearly needs more work) > - http://wiki.secondlife.com/wiki/S3_based_viewer_map : goes into the > implementation of the new map UI, the only part of the project that > pulls jpeg textures using http > > There are things we discussed but haven't documented yet, mostly: > - gather perf data as part of the builds: we are thinking about just > picking the launch time as a first goal on that road. I've been > looking at attempt at this internally as several groups independently > tried this already. Ideas from the group on this would be great! > - crash rate reports: we're doing some reading manually but we need to > extract some data and post them in a graph form somewhere > automatically. Since this means accessing some DB not available > publicly, this is clearly a task that's on Linden's laps. > > Hope this answer some of your questions. I saw you added this to the > agenda for this afternoon's Hippo meeting so we'll discuss that > subject there again. > > Cheers, > - Merov > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/b06a3412/attachment-0001.htm From merov at lindenlab.com Thu Apr 30 10:55:23 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 30 Apr 2009 10:55:23 -0700 Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) In-Reply-To: <1dabc2a30904301001w24fe8d6dmfbccba2cfce2eaa5@mail.gmail.com> References: <1dabc2a30904301001w24fe8d6dmfbccba2cfce2eaa5@mail.gmail.com> Message-ID: Hi Fire, On Apr 30, 2009, at 10:01 AM, Fire wrote: > The http-texture project sounds fascinating! If every texture in SL > could actually be fed in via http - that would rock the SL world, > especially for educators. That's definitely the idea but we have to get our act together wrt issues like security, privacy and right management before we push this willy-nilly. But yes, eventually, residents will be able to point to content outside the SL asset server. Can't tell you when though (because I don't know, not holding anything :) ) > Just wondering how far off the http-texture branch is to being fully > functional. Currently, http-texture is about making experiment with the technical aspects of this (caching, fetching, etc...). Right now, if you download one of the http-texture builds (get them at: http://wiki.secondlife.com/wiki/Open_Source_Portal) , you can experience the http texture niceties and speed (and crashers...) using the map: open the Map and browse around the grid. Note that you can now zoom out and in really far and see a map under a reasonable time. We think it's better that way but let us know what you think :) Cheers, - Merov From missannotoole at yahoo.com Thu Apr 30 10:59:47 2009 From: missannotoole at yahoo.com (Ann Otoole) Date: Thu, 30 Apr 2009 10:59:47 -0700 (PDT) Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) In-Reply-To: References: <1dabc2a30904301001w24fe8d6dmfbccba2cfce2eaa5@mail.gmail.com> Message-ID: <53435.26733.qm@web59103.mail.re1.yahoo.com> Are you going to give up on serving as a proxy to obfuscate resident IP address data? ________________________________ From: Philippe Bossut (Merov Linden) To: Second Life Developer Mailing List Sent: Thursday, April 30, 2009 1:55:23 PM Subject: Re: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) Hi Fire, On Apr 30, 2009, at 10:01 AM, Fire wrote: > The http-texture project sounds fascinating! If every texture in SL > could actually be fed in via http - that would rock the SL world, > especially for educators. That's definitely the idea but we have to get our act together wrt issues like security, privacy and right management before we push this willy-nilly. But yes, eventually, residents will be able to point to content outside the SL asset server. Can't tell you when though (because I don't know, not holding anything :) ) > Just wondering how far off the http-texture branch is to being fully > functional. Currently, http-texture is about making experiment with the technical aspects of this (caching, fetching, etc...). Right now, if you download one of the http-texture builds (get them at: http://wiki.secondlife.com/wiki/Open_Source_Portal) , you can experience the http texture niceties and speed (and crashers...) using the map: open the Map and browse around the grid. Note that you can now zoom out and in really far and see a map under a reasonable time. We think it's better that way but let us know what you think :) Cheers, - Merov _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/0055d6f7/attachment.htm From fire at b3dMultitech.com Thu Apr 30 11:03:10 2009 From: fire at b3dMultitech.com (Fire) Date: Thu, 30 Apr 2009 11:03:10 -0700 Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) In-Reply-To: References: <1dabc2a30904301001w24fe8d6dmfbccba2cfce2eaa5@mail.gmail.com> Message-ID: <1dabc2a30904301103o43d44e09u76ba2d3f04a7c92c@mail.gmail.com> Thanks for the answer Philippe... I hope LL gives you ALL the resources you need for this - cuz this would really increase the immersion and richness of SL... just wondering if input will also be possible via Flash or html forms that have been fed into SL? *Paul 'Fire' Preibisch* Educator, Content Creator, Virtual World Builder, Web 2.0 Consultant [image: Spreadfirefox Affiliate Button] [image: Spreadfirefox Affiliate Button] *Connect your Facebook Profile with your Second Life! http://apps.facebook.com/second-life/* *Need a Learning Management System for Second Life?Use Sloodle! * *Skype: Eslteacherlink.com* *Services: *Second Life Virtual World Construction, Machinima - Animation, Joomla Programming, Educational Website, LibsecondLife, Virtual Event Services Fire Centaur in Second Life On Thu, Apr 30, 2009 at 10:55 AM, Philippe Bossut (Merov Linden) < merov at lindenlab.com> wrote: > Hi Fire, > > On Apr 30, 2009, at 10:01 AM, Fire wrote: > > The http-texture project sounds fascinating! If every texture in SL > > could actually be fed in via http - that would rock the SL world, > > especially for educators. > > That's definitely the idea but we have to get our act together wrt > issues like security, privacy and right management before we push this > willy-nilly. But yes, eventually, residents will be able to point to > content outside the SL asset server. Can't tell you when though > (because I don't know, not holding anything :) ) > > > Just wondering how far off the http-texture branch is to being fully > > functional. > > Currently, http-texture is about making experiment with the technical > aspects of this (caching, fetching, etc...). Right now, if you > download one of the http-texture builds (get them at: > http://wiki.secondlife.com/wiki/Open_Source_Portal) > , you can experience the http texture niceties and speed (and > crashers...) using the map: open the Map and browse around the grid. > Note that you can now zoom out and in really far and see a map under a > reasonable time. We think it's better that way but let us know what > you think :) > > Cheers, > - Merov > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/ea4e266d/attachment.htm From GordonWendt at gmail.com Thu Apr 30 11:03:11 2009 From: GordonWendt at gmail.com (Gordon Wendt) Date: Thu, 30 Apr 2009 14:03:11 -0400 Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) In-Reply-To: <53435.26733.qm@web59103.mail.re1.yahoo.com> References: <1dabc2a30904301001w24fe8d6dmfbccba2cfce2eaa5@mail.gmail.com> <53435.26733.qm@web59103.mail.re1.yahoo.com> Message-ID: <493033a70904301103v51eb6411y7c03251f5f343514@mail.gmail.com> You beat me to it asking that Ann. This whole idea is a waste of time if LL doesn't have some plan to protect resident privacy with this since every resident with a lick of privacy sense won't use this without some sort of protection. -Gordon On Thu, Apr 30, 2009 at 1:59 PM, Ann Otoole wrote: > Are you going to give up on serving as a proxy to obfuscate resident IP > address data? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/400e2f75/attachment.htm From dahliatrimble at gmail.com Thu Apr 30 11:09:20 2009 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Thu, 30 Apr 2009 11:09:20 -0700 Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) In-Reply-To: <493033a70904301103v51eb6411y7c03251f5f343514@mail.gmail.com> References: <1dabc2a30904301001w24fe8d6dmfbccba2cfce2eaa5@mail.gmail.com> <53435.26733.qm@web59103.mail.re1.yahoo.com> <493033a70904301103v51eb6411y7c03251f5f343514@mail.gmail.com> Message-ID: I can see this as a useful feature for LL supplied images such as the map which can change frequently, but aside from the concerns about privacy, security, and content rights management, wouldn't having http texture sources lead to a lot of broken content as links go stale? I was under the impression that this was limited to map images, but if there are plans to extend it, how would the problem of stale links be addressed? On Thu, Apr 30, 2009 at 11:03 AM, Gordon Wendt wrote: > You beat me to it asking that Ann. This whole idea is a waste of time if LL > doesn't have some plan to protect resident privacy with this since every > resident with a lick of privacy sense won't use this without some sort of > protection. > > -Gordon > > > On Thu, Apr 30, 2009 at 1:59 PM, Ann Otoole wrote: > >> Are you going to give up on serving as a proxy to obfuscate resident IP >> address data? >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/66c6186c/attachment.htm From stickman at gmail.com Thu Apr 30 11:15:59 2009 From: stickman at gmail.com (Stickman) Date: Thu, 30 Apr 2009 11:15:59 -0700 Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) In-Reply-To: References: <1dabc2a30904301001w24fe8d6dmfbccba2cfce2eaa5@mail.gmail.com> <53435.26733.qm@web59103.mail.re1.yahoo.com> <493033a70904301103v51eb6411y7c03251f5f343514@mail.gmail.com> Message-ID: > extend it, how would the problem of stale links be addressed? I'm more concerned with hotlinking. It's prevalent enough on the internet as a whole, but you put it into something like Second Life where hundreds of people can pass by a spot every day and never look at an image but still end up loading it, and you can destroy someone's bandwidth who doesn't have hotlinking protection up. It can be a real unintentional grief machine. Having said that, I love the idea and would very much like to see it happen. I'm just concerned it gets implemented safely. I suppose the first step is to brainstorm a list of safety and privacy concerns, and then brainstorm how to solve them. Have we played that game yet? Is this the place for it? -Stickman From monkowsk at watson.ibm.com Thu Apr 30 11:43:01 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu, 30 Apr 2009 14:43:01 -0400 Subject: [sldev] About the http-texture project In-Reply-To: <6DA98012-931B-4B4F-8BD7-5D3249FD073E@lindenlab.com> References: <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> <49F9C142.7060904@watson.ibm.com> <6DA98012-931B-4B4F-8BD7-5D3249FD073E@lindenlab.com> Message-ID: <49F9F135.7070007@watson.ibm.com> Philippe Bossut (Merov Linden) wrote: > Not sure which missing documentation you're referring to but we have 3 > at the moment: OK, let's say Joe Sldev (I think the name is Serbian) has a great idea that he want's to get into the SL viewer. Is this new open source viewer (aka http-texture) his new open source portal or is it a sneaky underhanded backdoor to infiltrate the viewer codebase? He has a PJIRA entry with a patch file. How does that make its way to the SVN project? Does he have to worry about getting it into the SVN branch? Are there gatekeepers along the way? What if someone objects? Do we end up with SVN wars like Wiki wars? When the project gets merged to the branch, and the branch to the trunk, and the trunk to the RC, and the RC to the standard viewer, who does all that merging? Does anyone test it along the way? Does everything in the project get merged at once, or do selected patches get merged separately? Does anybody document what's going on? Does anyone even document the new or modified functionality? Where? At what point of the process? Enough for now. Mike From merov at lindenlab.com Thu Apr 30 11:58:22 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 30 Apr 2009 11:58:22 -0700 Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) In-Reply-To: References: <1dabc2a30904301001w24fe8d6dmfbccba2cfce2eaa5@mail.gmail.com> <53435.26733.qm@web59103.mail.re1.yahoo.com> <493033a70904301103v51eb6411y7c03251f5f343514@mail.gmail.com> Message-ID: <183E1020-2668-4F08-9F08-C7271354C92B@lindenlab.com> Hi, To answer the concerns expressed on this thread: yes, we take all those issues very very seriously (IP snooping, hot linking, griefing, phishing, etc...) and, as I said, that's why we won't push "URL on a prim" without careful examination of all the threats it presents and the possible mitigations. The good news is that web browsers have been down that road already and the threats and mitigating methods are known. The bad news is that web browsers don't have perfect solutions (it's a constant arm race with the griefers) *and* SL introduces new challenges of its own as you could get exposed to bad content just by walking by. Let's keep in mind though that, despite the issues, this technical possibility is very much desired by residents in some markets like education (exhibit A: Fire's email). On Apr 30, 2009, at 11:15 AM, Stickman wrote: > I suppose the first step is to brainstorm a list of safety and privacy > concerns, and then brainstorm how to solve them. Have we played that > game yet? Is this the place for it? There has been a couple of internal brainstorm meetings on "how to open without compromising security" internally. This is such a *huge* issue though and I'm wondering what's the best way to start the discussion without overwhelming the list. I'm thinking that a collaborative wiki page would be a better channel so that we could keep track of each potential threat/mitigation. What do you guys think? Cheers, - Merov From monkowsk at watson.ibm.com Thu Apr 30 11:59:35 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu, 30 Apr 2009 14:59:35 -0400 Subject: [sldev] About the http-texture project In-Reply-To: <6DA98012-931B-4B4F-8BD7-5D3249FD073E@lindenlab.com> References: <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> <49F9C142.7060904@watson.ibm.com> <6DA98012-931B-4B4F-8BD7-5D3249FD073E@lindenlab.com> Message-ID: <49F9F517.6010307@watson.ibm.com> Philippe Bossut (Merov Linden) wrote: > On Apr 24, 2009, at 3:36 PM, Philippe Bossut (Merov Linden) wrote: > >>"branches" is the parking repository for the "vendor" version, the >>code that gets exported by LL into the OSS realm. That's where code >>lands when they throw it over the wall (I'm being >>facetious here with my use of vocabulary and, in that particular >>instance, that's me throwing code over the wall). We (as >>open source developers) are not supposed to modify branches ever. They >>are sacred and represent what comes from Lindens. We build it though >>to make sure it's not evil, that our changes don't get stomped by >>Linden updates and that we like it enough to merge it into our >>projects. > > > > Rob followed by a post of his own and updated the wiki describing the > branches: > http://wiki.secondlife.com/wiki/Source_branches > > I hope this clears the objective of the svn hierarchy. So "Merov Linden" is "we" the open source developers? Not a Linden? The wiki page has a Note! and a Warning! that basically say don't believe anything you read there. Concerning "projects" all it says is > linden/projects/* Later on, Linden Lab wanted to have a more serious project that was more of a shared effort that they were conducting with an external vendor in the public repository, so they created the projects area. Am I seeing something different from what you're seeing? Mike From merov at lindenlab.com Thu Apr 30 12:57:03 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 30 Apr 2009 12:57:03 -0700 Subject: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) In-Reply-To: <20090430192152.557023DBC449@tammy.lindenlab.com> References: <20090430192152.557023DBC449@tammy.lindenlab.com> Message-ID: <0497D618-02C8-4726-8CC0-0399C684D5E7@lindenlab.com> Hi Malachi, On Apr 30, 2009, at 12:21 PM, malachi at tamzap.com wrote: > with the new map abilities when do you foresee if ever a map like > google earth? is this possible If what you have in mind is a "browsable map with smooth user interface and lots of geocoded content", yes it is possible but the point is rather: is it what we need? When I first demoed the new map to my daughter (9 years old), she immediately said: "why don't you zoom and zoom and zoom and then... bang! you're there!...". It's fitting: SL is a virtual world so the map *is* the territory. What Google Earth is trying to create is a representation of the real world that you could browse "as if" you were there but, with SL, you *are* there. So, what is the objective of a map? If we had infinite bandwidth and CPU, we wouldn't need a map at all: just fly high and look down, go where you want. From a realistic technical standpoint though, we can't really do this so the map is our way to reduce lots of content into a set of prerendered images that we can display and pin data on (land for sale, place of events, etc...). It's also a cool way to get a window on the SL world from outside the viewer as well (see he SLURL). Beyond that (adding 3D buildings to it for instance as in Google Earth) I'll start to feel like in a Jorge Borges novel (http://en.wikipedia.org/wiki/On_Exactitude_in_Science ). So my idea is that we should work making the SL IW experience better rather than stretching the map beyond the problems it's supposed to solve, namely, quick discoverability of content. Cheers, - Merov From aimee.trescothick at gmail.com Thu Apr 30 13:05:18 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Thu, 30 Apr 2009 21:05:18 +0100 Subject: [sldev] Open Source Meeting Agenda and RFC for VWR-12748 In-Reply-To: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com> References: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com> Message-ID: Just added an agenda item asking about procedure for getting the supporting artwork in for https://jira.secondlife.com/browse/VWR-12748 (Increase MiniMap zoom range, and magnify avatar markers at higher zoom levels) so that it can be committed. Once that's sorted out, does anyone have any comments/objections to that issue before it gets committed? Aimee. On 30 Apr 2009, at 16:37, Kent Quirk (Q Linden) wrote: > Please add items to the agenda if you wish: > > http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda > > I'll be hosting today. > > Q From sllists at boroon.dasgupta.ch Thu Apr 30 15:53:59 2009 From: sllists at boroon.dasgupta.ch (Boroondas Gupte) Date: Fri, 01 May 2009 00:53:59 +0200 Subject: [sldev] About the http-texture project In-Reply-To: <49F9F517.6010307@watson.ibm.com> References: <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> <49F9C142.7060904@watson.ibm.com> <6DA98012-931B-4B4F-8BD7-5D3249FD073E@lindenlab.com> <49F9F517.6010307@watson.ibm.com> Message-ID: <49FA2C07.6010803@boroon.dasgupta.ch> Mike Monkowski schrieb: > Philippe Bossut (Merov Linden) wrote: > >> On Apr 24, 2009, at 3:36 PM, Philippe Bossut (Merov Linden) wrote: >> Rob followed by a post of his own and updated the wiki describing the >> branches: >> http://wiki.secondlife.com/wiki/Source_branches >> >> I hope this clears the objective of the svn hierarchy. >> > > So "Merov Linden" is "we" the open source developers? Not a Linden? > > The wiki page has a Note! and a Warning! that basically say don't > believe anything you read there. Ah, that's because it was me who updated the wiki from Rob's post, not Rob himself. I don't have the whole picture, and I know that, that's why. Actually, the "Note!" is only for the future scenario when the current state isn't valid anymore (which might be soon, but surely not *this* soon), but the wiki page wasn't updated again until then. That's why I've put a date into it, so people can judge how likely that is at the specific time they're viewing the page. Once the repo structure has reached a more stable state and that has been documented, the "Note!" should be removed. The "Warning!" only applies for the stuff below it. Some part of that might still be accurate (except for the "release" to "trunk" rename), but I can't tell which part, so I've just left that stuff around and added the warning box. > Concerning "projects" all it says is > >> linden/projects/* Later on, Linden Lab wanted to have a more serious project that was more of a shared effort that they were conducting with an external vendor in the public repository, so they created the projects area. As a description of that area in the tree, that's still accurate, I think. It's what I condensed from Rob's mail at https://lists.secondlife.com/pipermail/sldev/2009-April/013510.html I'll add some sub-list-items describing the branches (or the corresponding projects) in that area. (Or feel free to do so yourself) cheers Boroondas From aimee.trescothick at gmail.com Thu Apr 30 15:59:00 2009 From: aimee.trescothick at gmail.com (Aimee Trescothick) Date: Thu, 30 Apr 2009 23:59:00 +0100 Subject: [sldev] [Patch] VWR-8008 Drop-down to select preset aspect ratios in texture preview floaters Message-ID: Per Q's comment on http://jira.secondlife.com/browse/VWR-8008 (Drop- down to select preset aspect ratios in texture preview floaters): "This seems like a perfect candidate for the http-texture open source branch. Aimee, any chance we could get you to apply it to that branch?" Anyone have any comments/objections first? Aimee. From merov at lindenlab.com Thu Apr 30 16:28:36 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 30 Apr 2009 16:28:36 -0700 Subject: [sldev] About the http-texture project In-Reply-To: <49F9F517.6010307@watson.ibm.com> References: <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> <49F9C142.7060904@watson.ibm.com> <6DA98012-931B-4B4F-8BD7-5D3249FD073E@lindenlab.com> <49F9F517.6010307@watson.ibm.com> Message-ID: Hi, On Apr 30, 2009, at 11:59 AM, Mike Monkowski wrote: > Philippe Bossut (Merov Linden) wrote: >> On Apr 24, 2009, at 3:36 PM, Philippe Bossut (Merov Linden) wrote: >>> "branches" is the parking repository for the "vendor" version, the >>> code that gets exported by LL into the OSS realm. That's where code >>> lands when they throw it over the wall (I'm being >>> facetious here with my use of vocabulary and, in that particular >>> instance, that's me throwing code over the wall). We >>> (as >>> open source developers) are not supposed to modify branches ever. >>> They >>> are sacred and represent what comes from Lindens. We build it though >>> to make sure it's not evil, that our changes don't get stomped by >>> Linden updates and that we like it enough to merge it into our >>> projects. >> Rob followed by a post of his own and updated the wiki describing >> the branches: >> http://wiki.secondlife.com/wiki/Source_branches >> I hope this clears the objective of the svn hierarchy. > > So "Merov Linden" is "we" the open source developers? Not a Linden? Yes, "We, the people", the concerned Open Source contributors to that project. That includes Lindens (like me) but not only. > The wiki page has a Note! and a Warning! that basically say don't > believe anything you read there. Concerning "projects" all it says is >> linden/projects/* Later on, Linden Lab wanted to have a more >> serious project that was more of a shared effort that they were >> conducting with an external vendor in the public repository, so >> they created the projects area. > > Am I seeing something different from what you're seeing? The note and warning is to say that the writing is a work in progress: - about the Note! clearly, we'll go with a better name than "http- texture" and Rob already mentioned that. This is a temporary name hence the writing under the Note! is temporary too. - about the Warning! it's just to say that we know this patch flow description is out of date but we haven't had time to correct it. It also mentions that anyone with understanding of the patch flow can fix the writing. This is where you should hook up to make your proposal on the subject. Cheers, - Merov From monkowsk at watson.ibm.com Thu Apr 30 16:51:38 2009 From: monkowsk at watson.ibm.com (Mike Monkowski) Date: Thu, 30 Apr 2009 19:51:38 -0400 Subject: [sldev] Open Source Meeting, 2PM PDT, Hippotropolis In-Reply-To: <49F9CA9A.2000103@watson.ibm.com> References: <3B7F46F8-2F96-49B9-B62F-879D3BBD3B34@lindenlab.com> <49F9CA9A.2000103@watson.ibm.com> Message-ID: <49FA398A.5090105@watson.ibm.com> As I warned :-) at the meeting today, I'm making up documentation for this new Open Source Viewer process. You can see the work in progress at http://wiki.secondlife.com/wiki/User:Mm_Alder/SLDev_Open_Source_Viewer Feel free to edit whatever you like. I'm only doing this because no one else would. :-) Mike Mike Monkowski wrote: > I added: > >># Can we get better documentation on the open source viewer project (aka http-texture)? Is there anyone other than me who would be interested in open code reviews for this project? Mm Alder 15:57, 30 April 2009 (UTC) > > > > Kent Quirk (Q Linden) wrote: > >>Please add items to the agenda if you wish: >> >>http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda >> >>I'll be hosting today. From jan.ciger at gmail.com Thu Apr 30 16:51:46 2009 From: jan.ciger at gmail.com (Jan Ciger) Date: Fri, 01 May 2009 01:51:46 +0200 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <4EBAB0C6-8B76-4F9E-9679-06FC0FC96E08@fastmail.fm> References: <061501c9c1e1$0a96ff00$1fc4fd00$@com> <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <7b61e3970904291245j53703dbcjb177dc234cb592d5@mail.gmail.com> <4EBAB0C6-8B76-4F9E-9679-06FC0FC96E08@fastmail.fm> Message-ID: <49FA3992.8020205@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ordinal.malaprop at fastmail.fm wrote: > On 29 Apr 2009, at 20:45, JB Kraft wrote: > >> Perhaps a more modular approach, plugin style, might be considered. >> From my own usage and perspective, voice and windlight would be the >> first two .so's to go. > > A plugin architecture for the client would be incredibly useful, and > I've promoted the idea in my own small way (rather than "hey, you want > something different? Build and release your own client!") for a couple > of years now. Um, folks - and how exactly do you want the renderer (Windlight) to be a removable plugin? Windlight (as technology) are basically just programmable shaders. If you remove that (turning off shaders in preferences does the same), you have more or less the old style 1.18 viewer, graphics-wise. What exactly would this as a plugin achieve? The shaders are not in the main memory - they run on the GPU, so you do not even save that by not loading them. Voice mentioned by JB Kraft is not even integrated in the viewer itself, it is an external application that you do not need to run if you do not want it and the viewer will work even if it is not present. So what plugin are we talking about? The few floaters for controlling it? Plugins make things needlessly complex and are not useful as a general design approach for core functionality. Furthermore, the viewer doesn't even use shared libraries yet (everything statically linked, with the exception of few a things loaded dynamically - FMOD, gstreamer, etc). *THAT* is what needs to be fixed, not jumping up and down about plugins as a panacea. I am trying to build a headless client based on the C++ sources for research right now, and thanks to rather poor modularization it is pretty difficult to do. I need to duplicate an re-implement quite a bit of functionality that is in the viewer already (e.g. LLAgent, LLWearable classes), because unless I want to pull in dependencies on XUL, the viewer UI and what not even for basic things like setting agent's appearance inworld I cannot use them. That is what needs to be fixed - once it is done, you can pretty much build whatever client you want and you do not need any "plugins". Regards, Jan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJ+jmPn11XseNj94gRAixIAJ42uqqUpOrC0iVotd65dSFMuy3/YwCgiiN9 RvgI55LUd/uRQBY6hF7JX8c= =hlIx -----END PGP SIGNATURE----- From kwerks.sl at gmail.com Thu Apr 30 17:16:40 2009 From: kwerks.sl at gmail.com (JB Kraft) Date: Thu, 30 Apr 2009 20:16:40 -0400 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <49FA3992.8020205@gmail.com> References: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <7b61e3970904291245j53703dbcjb177dc234cb592d5@mail.gmail.com> <4EBAB0C6-8B76-4F9E-9679-06FC0FC96E08@fastmail.fm> <49FA3992.8020205@gmail.com> Message-ID: <7b61e3970904301716i55274882nbdc112bd4e44cd8d@mail.gmail.com> Quite right. To explain myself, I think the viewer is getting too bloated for the "average" machine and offered plugins as a way to possibly mitigate that bloat as well as allow for expansion in other ways unforeseen. What I am really getting at is the very same thing you are speaking to here with the headless viewer for example. One way to do that would be to have a plugin for the GL renderer that does nothing. One could even make an ascii renderer a la ascii quake ;) The script editor is another excellent candidate for a plugin style framework, imho. Ultimately the goal is, I think, to move toward decoupling the various sub-systems and from the sounds of it, the Lab is trying to move toward that as well. How exactly that is done is another matter and given the current codebase, I appeciate somewhat the problems inherent. I threw plugins in as simply one possible direction to help manage the inevitable bloat that long lived code bases, driven by enthusiastic coders, accumulates. I picked on voice and windlight simply because for me, those are things I am personally not interested in. No offense intended, nor did I mean to speak directly to the technical issues involved in "plugifying" those particular things :) cheers! JB On Thu, Apr 30, 2009 at 7:51 PM, Jan Ciger wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ordinal.malaprop at fastmail.fm wrote: > > On 29 Apr 2009, at 20:45, JB Kraft wrote: > > > >> Perhaps a more modular approach, plugin style, might be considered. > >> From my own usage and perspective, voice and windlight would be the > >> first two .so's to go. > > > > A plugin architecture for the client would be incredibly useful, and > > I've promoted the idea in my own small way (rather than "hey, you want > > something different? Build and release your own client!") for a couple > > of years now. > > Um, folks - and how exactly do you want the renderer (Windlight) to be a > removable plugin? Windlight (as technology) are basically just > programmable shaders. If you remove that (turning off shaders in > preferences does the same), you have more or less the old style 1.18 > viewer, graphics-wise. What exactly would this as a plugin achieve? The > shaders are not in the main memory - they run on the GPU, so you do not > even save that by not loading them. > > Voice mentioned by JB Kraft is not even integrated in the viewer itself, > it is an external application that you do not need to run if you do not > want it and the viewer will work even if it is not present. So what > plugin are we talking about? The few floaters for controlling it? > > Plugins make things needlessly complex and are not useful as a general > design approach for core functionality. Furthermore, the viewer doesn't > even use shared libraries yet (everything statically linked, with the > exception of few a things loaded dynamically - FMOD, gstreamer, etc). > *THAT* is what needs to be fixed, not jumping up and down about plugins > as a panacea. > > I am trying to build a headless client based on the C++ sources for > research right now, and thanks to rather poor modularization it is > pretty difficult to do. I need to duplicate an re-implement quite a bit > of functionality that is in the viewer already (e.g. LLAgent, LLWearable > classes), because unless I want to pull in dependencies on XUL, the > viewer UI and what not even for basic things like setting agent's > appearance inworld I cannot use them. That is what needs to be fixed - > once it is done, you can pretty much build whatever client you want and > you do not need any "plugins". > > Regards, > > Jan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFJ+jmPn11XseNj94gRAixIAJ42uqqUpOrC0iVotd65dSFMuy3/YwCgiiN9 > RvgI55LUd/uRQBY6hF7JX8c= > =hlIx > -----END PGP SIGNATURE----- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting > privileges > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/75aeded8/attachment-0001.htm From melinda at superliminal.com Thu Apr 30 17:33:49 2009 From: melinda at superliminal.com (Melinda Green) Date: Thu, 30 Apr 2009 17:33:49 -0700 Subject: [sldev] VWR-10311 Enabling lip sync by default In-Reply-To: <7b61e3970904301716i55274882nbdc112bd4e44cd8d@mail.gmail.com> References: <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <7b61e3970904291245j53703dbcjb177dc234cb592d5@mail.gmail.com> <4EBAB0C6-8B76-4F9E-9679-06FC0FC96E08@fastmail.fm> <49FA3992.8020205@gmail.com> <7b61e3970904301716i55274882nbdc112bd4e44cd8d@mail.gmail.com> Message-ID: <49FA436D.2020309@superliminal.com> Clean, separable API's are themselves a type of plug-in. One of the best things about them is that when you cleanly "chop away baggage" (such as 3D rendering) from your viewer, you simultaneously allow other people to plug that piece into other things (such as a 3D ActiveX control) without the baggage of the viewer that it was previously wedded to. Both parts can and should then be wrapped in separate test harnesses so that their development can continue more efficiently on separate paths with the guarantees that they will stay compatible with each other and without interdependencies being reintroduced. The work to rip apart things like this is hard but the flexibility it buys is huge. -Melinda JB Kraft wrote: > Quite right. To explain myself, I think the viewer is getting too > bloated for the "average" machine and offered plugins as a way to > possibly mitigate that bloat as well as allow for expansion in other > ways unforeseen. What I am really getting at is the very same thing > you are speaking to here with the headless viewer for example. One way > to do that would be to have a plugin for the GL renderer that does > nothing. One could even make an ascii renderer a la ascii quake ;) The > script editor is another excellent candidate for a plugin style > framework, imho. > > Ultimately the goal is, I think, to move toward decoupling the various > sub-systems and from the sounds of it, the Lab is trying to move > toward that as well. How exactly that is done is another matter and > given the current codebase, I appeciate somewhat the problems > inherent. I threw plugins in as simply one possible direction to help > manage the inevitable bloat that long lived code bases, driven by > enthusiastic coders, accumulates. I picked on voice and windlight > simply because for me, those are things I am personally not interested > in. No offense intended, nor did I mean to speak directly to the > technical issues involved in "plugifying" those particular things :) > > cheers! > JB > > On Thu, Apr 30, 2009 at 7:51 PM, Jan Ciger > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > ordinal.malaprop at fastmail.fm > wrote: > > On 29 Apr 2009, at 20:45, JB Kraft wrote: > > > >> Perhaps a more modular approach, plugin style, might be considered. > >> From my own usage and perspective, voice and windlight would be the > >> first two .so's to go. > > > > A plugin architecture for the client would be incredibly useful, and > > I've promoted the idea in my own small way (rather than "hey, > you want > > something different? Build and release your own client!") for a > couple > > of years now. > > Um, folks - and how exactly do you want the renderer (Windlight) > to be a > removable plugin? Windlight (as technology) are basically just > programmable shaders. If you remove that (turning off shaders in > preferences does the same), you have more or less the old style 1.18 > viewer, graphics-wise. What exactly would this as a plugin > achieve? The > shaders are not in the main memory - they run on the GPU, so you > do not > even save that by not loading them. > > Voice mentioned by JB Kraft is not even integrated in the viewer > itself, > it is an external application that you do not need to run if you > do not > want it and the viewer will work even if it is not present. So what > plugin are we talking about? The few floaters for controlling it? > > Plugins make things needlessly complex and are not useful as a general > design approach for core functionality. Furthermore, the viewer > doesn't > even use shared libraries yet (everything statically linked, with the > exception of few a things loaded dynamically - FMOD, gstreamer, etc). > *THAT* is what needs to be fixed, not jumping up and down about > plugins > as a panacea. > > I am trying to build a headless client based on the C++ sources for > research right now, and thanks to rather poor modularization it is > pretty difficult to do. I need to duplicate an re-implement quite > a bit > of functionality that is in the viewer already (e.g. LLAgent, > LLWearable > classes), because unless I want to pull in dependencies on XUL, the > viewer UI and what not even for basic things like setting agent's > appearance inworld I cannot use them. That is what needs to be fixed - > once it is done, you can pretty much build whatever client you > want and > you do not need any "plugins". > > Regards, > > Jan > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iD8DBQFJ+jmPn11XseNj94gRAixIAJ42uqqUpOrC0iVotd65dSFMuy3/YwCgiiN9 > RvgI55LUd/uRQBY6hF7JX8c= > =hlIx > -----END PGP SIGNATURE----- > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated > posting privileges > > > ------------------------------------------------------------------------ > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/SLDev > Please read the policies before posting to keep unmoderated posting privileges From head_mt at yahoo.com Thu Apr 30 18:17:33 2009 From: head_mt at yahoo.com (Jeff) Date: Thu, 30 Apr 2009 18:17:33 -0700 (PDT) Subject: [sldev] remove In-Reply-To: References: Message-ID: <350616.17726.qm@web39102.mail.mud.yahoo.com> remove ________________________________ From: "sldev-request at lists.secondlife.com" To: sldev at lists.secondlife.com Sent: Thursday, April 30, 2009 12:00:05 PM Subject: SLDev Digest, Vol 28, Issue 57 Send SLDev mailing list submissions to sldev at lists.secondlife.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev or, via email, send a message with subject or body 'help' to sldev-request at lists.secondlife.com You can reach the person managing the list at sldev-owner at lists.secondlife.com When replying, please edit your Subject line so it is more specific than "Re: Contents of SLDev digest..." Today's Topics: 1. Re: About the http-texture project (Mike Monkowski) 2. Re: http-texture project - how far until complete? (this will totally Rawk SL!) (Philippe Bossut (Merov Linden)) 3. Re: About the http-texture project (Mike Monkowski) ---------------------------------------------------------------------- Message: 1 Date: Thu, 30 Apr 2009 14:43:01 -0400 From: Mike Monkowski Subject: Re: [sldev] About the http-texture project To: "Philippe Bossut (Merov Linden)" Cc: Second Life Developer Mailing List Message-ID: <49F9F135.7070007 at watson.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Philippe Bossut (Merov Linden) wrote: > Not sure which missing documentation you're referring to but we have 3 > at the moment: OK, let's say Joe Sldev (I think the name is Serbian) has a great idea that he want's to get into the SL viewer. Is this new open source viewer (aka http-texture) his new open source portal or is it a sneaky underhanded backdoor to infiltrate the viewer codebase? He has a PJIRA entry with a patch file. How does that make its way to the SVN project? Does he have to worry about getting it into the SVN branch? Are there gatekeepers along the way? What if someone objects? Do we end up with SVN wars like Wiki wars? When the project gets merged to the branch, and the branch to the trunk, and the trunk to the RC, and the RC to the standard viewer, who does all that merging? Does anyone test it along the way? Does everything in the project get merged at once, or do selected patches get merged separately? Does anybody document what's going on? Does anyone even document the new or modified functionality? Where? At what point of the process? Enough for now. Mike ------------------------------ Message: 2 Date: Thu, 30 Apr 2009 11:58:22 -0700 From: "Philippe Bossut (Merov Linden)" Subject: Re: [sldev] http-texture project - how far until complete? (this will totally Rawk SL!) To: Second Life Developer Mailing List Message-ID: <183E1020-2668-4F08-9F08-C7271354C92B at lindenlab.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Hi, To answer the concerns expressed on this thread: yes, we take all those issues very very seriously (IP snooping, hot linking, griefing, phishing, etc...) and, as I said, that's why we won't push "URL on a prim" without careful examination of all the threats it presents and the possible mitigations. The good news is that web browsers have been down that road already and the threats and mitigating methods are known. The bad news is that web browsers don't have perfect solutions (it's a constant arm race with the griefers) *and* SL introduces new challenges of its own as you could get exposed to bad content just by walking by. Let's keep in mind though that, despite the issues, this technical possibility is very much desired by residents in some markets like education (exhibit A: Fire's email). On Apr 30, 2009, at 11:15 AM, Stickman wrote: > I suppose the first step is to brainstorm a list of safety and privacy > concerns, and then brainstorm how to solve them. Have we played that > game yet? Is this the place for it? There has been a couple of internal brainstorm meetings on "how to open without compromising security" internally. This is such a *huge* issue though and I'm wondering what's the best way to start the discussion without overwhelming the list. I'm thinking that a collaborative wiki page would be a better channel so that we could keep track of each potential threat/mitigation. What do you guys think? Cheers, - Merov ------------------------------ Message: 3 Date: Thu, 30 Apr 2009 14:59:35 -0400 From: Mike Monkowski Subject: Re: [sldev] About the http-texture project To: "Philippe Bossut (Merov Linden)" Cc: Second Life Developer Mailing List Message-ID: <49F9F517.6010307 at watson.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Philippe Bossut (Merov Linden) wrote: > On Apr 24, 2009, at 3:36 PM, Philippe Bossut (Merov Linden) wrote: > >>"branches" is the parking repository for the "vendor" version, the >>code that gets exported by LL into the OSS realm. That's where code >>lands when they throw it over the wall (I'm being >>facetious here with my use of vocabulary and, in that particular >>instance, that's me throwing code over the wall). We (as >>open source developers) are not supposed to modify branches ever. They >>are sacred and represent what comes from Lindens. We build it though >>to make sure it's not evil, that our changes don't get stomped by >>Linden updates and that we like it enough to merge it into our >>projects. > > > > Rob followed by a post of his own and updated the wiki describing the > branches: > http://wiki.secondlife.com/wiki/Source_branches > > I hope this clears the objective of the svn hierarchy. So "Merov Linden" is "we" the open source developers? Not a Linden? The wiki page has a Note! and a Warning! that basically say don't believe anything you read there. Concerning "projects" all it says is > linden/projects/* Later on, Linden Lab wanted to have a more serious project that was more of a shared effort that they were conducting with an external vendor in the public repository, so they created the projects area. Am I seeing something different from what you're seeing? Mike ------------------------------ _______________________________________________ SLDev mailing list SLDev at lists.secondlife.com https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev End of SLDev Digest, Vol 28, Issue 57 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090430/af371df5/attachment.htm From merov at lindenlab.com Thu Apr 30 18:18:10 2009 From: merov at lindenlab.com (Philippe Bossut (Merov Linden)) Date: Thu, 30 Apr 2009 18:18:10 -0700 Subject: [sldev] About the http-texture project In-Reply-To: <49F9F135.7070007@watson.ibm.com> References: <49F77537.8010609@watson.ibm.com> <493033a70904290503w59f49185w82e8a692aa7a2353@mail.gmail.com> <49F867E1.6040805@watson.ibm.com> <784490.3996.qm@web59104.mail.re1.yahoo.com> <493033a70904291857o4788d7bewdf50f75bcbbbde09@mail.gmail.com> <493033a70904300743m45c9e8bdg1dd8a37d7e8ea95f@mail.gmail.com> <49F9C142.7060904@watson.ibm.com> <6DA98012-931B-4B4F-8BD7-5D3249FD073E@lindenlab.com> <49F9F135.7070007@watson.ibm.com> Message-ID: Hi Mike, On Apr 30, 2009, at 11:43 AM, Mike Monkowski wrote: > Philippe Bossut (Merov Linden) wrote: >> Not sure which missing documentation you're referring to but we >> have 3 at the moment: > > OK, let's say Joe Sldev (I think the name is Serbian) has a great > idea that he want's to get into the SL viewer. > > Is this new open source viewer (aka http-texture) his new open > source portal or is it a sneaky underhanded backdoor to infiltrate > the viewer codebase? Our goal with the OSS viewer has been made clear by Philip (see https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts) . We do hope that most of the innovations battle tested here will eventually make it to the official viewer codebase but things that are clearly not mainstream enough or not very popular with this community won't simply make it there and that's ok. People will still be able to get those features in the "Second Life OSS" download though. So, for Joe Sldev, the "Second Life OSS" project is the right one to get his new feature in a fairly well distributed viewer, tested and amended by a knowledgeable community, you. > He has a PJIRA entry with a patch file. How does that make its way > to the SVN project? Does he have to worry about getting it into the > SVN branch? Are there gatekeepers along the way? What if someone > objects? Do we end up with SVN wars like Wiki wars? It's like almost any other FLOSS project: there is a group of *committers* that do have commit privileges to the svn tree. The big difference with the "old LL way of doing things" is that this group of committers has Lindens *and* non-Lindens. After submitting his contribution to the JIRA, Joe Sldev should engage folks on this mailing list to get support for his feature: are people interested by the feature, is this a worthy issue to fix. If there is community support and a good review of his code from committers, the patch will be taken in and committed by one of the committers. Eventually, if Joe Sldev does quite a bit of good contributions in line with the project, the committers will propose Joe to become a committer himself. The committers group grows by co-optation only. If someone objects (and if our community is alive, there *will* be someone to object...), we debate and try to reach a consensus on this list. If there's a really contentious decision to be made (split debate), Philip, our BDFL (Benevolent Dictator For Life), will weight in and make the decision. As for avoiding wars, we won't have SVN wars since the group of committers will be co-opted. Obviously, the committers will be careful co-opting only people who share their view and philosophy of development. If one committer will all of a sudden commit controversial patches with no respect for due debate or the general direction of the project (as decided by the BDFL), he or she'll see his/her commit rights revoked. The BDFL has full authority in that matter. > When the project gets merged to the branch, and the branch to the > trunk, and the trunk to the RC, and the RC to the standard viewer, > who does all that merging? Does anyone test it along the way? Does > everything in the project get merged at once, or do selected patches > get merged separately? That's a lot of question and each project (RC, maint, etc...) has its own way of ensuring quality and consistency of its project, mitigating agility vs prudence. As far as the merge back to the official viewer of "Second Life OSS" feature is concerned, that'll be up to the LL viewer team to cherry pick and merge patches/commits separately. I'll admit that this is not easy to do. Making this more manageable is one of the big reason for the push to hg (mercurial) which does make merges from various sources much more easier than svn. > Does anybody document what's going on? Does anyone even document > the new or modified functionality? Where? At what point of the > process? Every feature *must* have a JIRA attached with relevant doc and test plan. If too big for the JIRA, the JIRA record should point to a wiki doc. Contributors should expect to document their code, write test plans, etc... I'm not for writing a long list of enforced rules and regulations as we don't know yet how deep those patches will be. If I have to make a guess based on the ones I've seen from Robin Aimee and a couple of others, I'm not expecting this to become super process heavy. As a general philosophy, we should all strive for a high level of quality for contributions. Writing a patch and throwing it to JIRA hoping others will write the code documentation, test plan, build and test the code, etc... won't get Joe Sldev very far. Cheers, - Merov