Re: [opensource-dev] Viewer UI mode merge
Dare I ask if there's been any thought during the FUI project about "tear off to separate rooted window" support? e.g. VWR-467 -Vex ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Not actually OT: How do I get/update gcc to 4.6 on debian squeeze?
Another useful option would be to build and maintain a VM image with the complete tool chain installed. It would be great to have as a reference and would let people who wanted to cross-compile do it much easier, at an obvious cost of VM overhead. Pity Windows and OSX compilers couldn't be VM-ized the same way. On 9/5/2014 7:25 AM, Lance Corrimal wrote: > Hmm.. maybe change that build environment to something that is actually > compatibel to something that users might have? as in, not using compiler > versions / library versions that aren't available from official > repositories for the distribution in question (prebuilt libs excluded)? > > Alternative: package the compiler toolchain as a prebuilt archive, d/l > and unpack into the source tree on build. preferrably as statically > linked stuff. > > > cheers > LC > > > Am 04.09.2014 um 20:14 schrieb Monty Brandenberg: >> On 9/4/2014 11:00 AM, Lance Corrimal wrote: >>> Hi, >>> >>> >>> I guess noone else builds on linux AND tries to actually have a build >>> environment that is exactly the same as the one Ll uses... Since it is NOT >>> DOCUMENTED. >> Nobody would *want* the exact same build environment that we use. >> But Oz is, I believe, running down the info on the tool chain >> components. We're large enough that that info is stuck in a silo >> somewhere and we have to blast it out. >> >> m >> > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy
Soft Linden wrote: On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson wrote: On 02/23/2010 02:16 PM, Gigs wrote: http://secondlife.com/corporate/tpv.php You all realize this is massively incompatible with the GPL, right? Not at all. They're not restricting access to the code. They're restricting access to their service. And defining the terms under which that service is provided. Mike's correct. If you see any wording that's ambiguous about that, let us know. Section 1c unambiguously imposes a GPL-incompatible download and/or installation requirement that is unrelated to the use of the software with the SL grid(s). IMHO, it would be more appropriate to handle this like new user dialogs and license changes already do - then it is clearly a use of service agreement, and the third-party viewer registry should already have all that information on hand on Linden Labs' servers. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Third party viewer policy
On 2/23/2010 6:05 PM, Lawson English wrote: Vex Streeter wrote: Soft Linden wrote: On Tue, Feb 23, 2010 at 2:21 PM, Mike Dickson wrote: On 02/23/2010 02:16 PM, Gigs wrote: http://secondlife.com/corporate/tpv.php You all realize this is massively incompatible with the GPL, right? Not at all. They're not restricting access to the code. They're restricting access to their service. And defining the terms under which that service is provided. Mike's correct. If you see any wording that's ambiguous about that, let us know. Section 1c unambiguously imposes a GPL-incompatible download and/or installation requirement that is unrelated to the use of the software with the SL grid(s). The preamble specifically states that the policy only applies to viewers meant to be used by SL. In essence, LL reserves the right to deny access to viewers that don meet their requirements. But that isn't what the policy says: 1. Required Functionality and Disclosures If you are a Developer of Third-Party Viewers, we require the following of all Third-Party Viewers: ... c. On your software download page or in another location that a user must visit before installing the Third-Party Viewer, you must disclose the following: [1.c.i - 1.c.v contents don't matter at all to the GPL] These are constraints which explicitly place new unconditional restrictions on the _delivery_of_software_ (derivative works of the SL viewer codebase) by third party developers to end-users and downstream developers, *not* constraints on connecting to LL's services. This is one of the mechanisms (if not the content) of constraint that FSF carefully designed GPL to discourage. MY concern is about prototyping viewers. I can certainly add a thing to timestamp a version string during login, but with smalltalk, I'm constantly tweaking the code *while* I'm connected to SL. Does this mean I have to log out every time I modify something in my squeak client just so I can change the version string? Even if I don't change the SL viewer code, but only something else in the Squeak image, its still part of the same application due to how Smalltalk works. So any time I'm connected to SL using smalltalk, and I play with the workspace to test a new one-liner, I'm effectively changing the viewer code, and must log out and back in with a new version string... Only partly joking here. Taking this policy to its extreme may sound silly, but people are correct: its poorly worded. heh - then client-side scripting (of whichever varieties) will be generally problematic, as will any users of the media api. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] "Resposibility" - Third party viewer policy
Lance Corrimal wrote: Am Dienstag, 23. Februar 2010 21:16:44 schrieb Gigs: http://secondlife.com/corporate/tpv.php You all realize this is massively incompatible with the GPL, right? Correct me if I'm wrong... The whole "you are responsible" stuff seems to mean that if X provides any open source viewer, X is also responsible for any misdeeds committed with other people's derivatives of X? GPL also specifically disclaims warranty and liability unless you choose to provide such for your code or distribution. Policy sections 1.c.i and 1.c.ii are redundant w/rt GPL but_requiring_ such statements of downstream distributors conflicts with GPL. Policy section 7.d is even worse as it directly contradicts GPL liability disclaimers. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Eclipse Guru's
Absolutely! You've described my preferred setup exactly. Any script longer than a few lines, and I do it with Eclipse, LSLPlus and Subversive. I also use PHP and C/C++ plugins for SLish work. Sadly, the last time I tried the C# plugin, things broke horribly, but perhaps it is time to try again. All assets for my projects go into svn, including textures, documentation, configuration information, etc for both in- and out-world components. W/rt team work - I wouldn't consider even attempting a cooperative project without a setup like this - just too many ways for things to break. For *big* projects, you can use eclipse system design plugins, requirements, bugtracking, etc. SVN hosting shouldn't be expensive - I use a combination of personal (LAN in my home), RL work (outside corporate firewall but still managed), and private hosted (ATM, I use dreamhost but there are lots of options). IMHO, Git and mercurial are the other SVN alternatives that come to mind - possibly better choices depending on your development model and teammates. Fire wrote: Hi everyone I have been using LSL Plus, and eclipse for the longest time to develop LSL code. I love it due to its auto-completion abilities, and the general user interface. What a great little dev environment!!! ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Snowglobe 2.0^H^H^H1.3 way forward?
Soft Linden wrote:
> Ha - I'm not the only one who does this? I'm forever leaving profiles
> open and minimized when checking out places in resis' picks. Half the
> time I find an interesting object during a visit, want to check out
> the creator's picks, and end up adding another window or two before
> I've exhausted the picks in the first.
>
Hah - I've assumed that everyone does this! I've always wondered why
profiles can't be converted to calling cards - it would be great to have
a folder full of interesting people to look up. Similarly, there seem
to be a number of places where you have the option of tping to a
location, but not {map, slurl, LM}ing it. If we're going to keep the
browser metaphor, it would be nice to have the equivalent of "bookmark
whatever I'm pointing to" as well as "bookmark here".
-Vex
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] oh give me a break
Excellent discussion, Thomas - I think I concur on every point. I'd add, however, that I think LL could tweak the economic model to discourage for-profit content theft. Perhaps requiring that account be verified in order to convert L$ to real world currency or even a monthly L$ transaction limit. No, I haven't thought about it very deeply, but since DRM is so often counterproductive, perhaps cracking down on the money laundering side of the equation would be a better (and much less intrusive) approach. Event so, such things do not (and cannot) address the problem of people who rip off content without profit motive. The basic truth is that some content requires more up front time and effort than a service-based economic model can support. I've never heard a cogent argument from the "everything digital should be gratis" crowd on how they thing such things ought to be funded. Speaking as someone whose RL work has been ripped off and is widely distributed for free, I *really* wish I had the same options that SL could offer in the real world. Cheers, Vex Thomas Grimshaw wrote: > This post is likely to incur some feelings of emotions in a lot of you; > I ask that you bear with me and be open minded towards these words. I > recognise that many of you won't agree with me; it is but an attempt to > try and shine a searchlight into the hysteria. > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] oh give me a break
Soft Linden wrote: > Any additional ideas on squashing fraud are always appreciated, via > mail to secur...@lindenlab.com. Please don't hold those discussions on > this list. > Understood - I know there is considerable effort in this area. Mainly I wanted to opine that such limits are much more effective than DRM at discouraging profit-motive copyright infringement. Cheers, Vex ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] This cannot be right...
Check out http://jira.secondlife.com/browse/VWR-22757 and http://jira.secondlife.com/browse/VWR-18427 I don't know why 209046 would be worse than prior releases, but it would be nice to know that OSX builds do or don't have the same issue. On 09/09/2010 01:07 PM, Ponzu wrote: When I start V2 Dev 209046, this show up in my system.log. It goes on producing more than 500 entries per second. ... Sep 9 12:49:43 iMac /Applications/Second Life Development.app/Contents/MacOS/Second Life[12501]: dnssd_clientstub deliver_request: socketpair failed 24 (Too many open files) Sep 9 12:49:43: --- last message repeated 499 times --- ... ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] User Story: Improved Cache
I think this is actually a crucial first step to cache improvement. The performance of this system would be an extremely useful baseline. For instance I'd love to be able to toggle between saving jp2 and raw w and w/out mipmap. There can be performance benefits to storing content compressed on disk, though it isn't clear to me that any of the SL assets would win here. I don't think it needs to be a real viewer at that level - It is pretty trivial to obfuscate assets at a similar level of protection as that currently used at a CPU cost that'll get lost in the noise (example: XOR asset UUID and post-header content with install-determined hash). Once the infrastructure is in place, a trivial obfuscater would make it TPV compliant, I'd think. On 09/16/2010 07:36 PM, Dale Mahalko wrote: > I just don't have the motivation for it myself, but I would really > like it if a 3rd party developer would gut out LL's texture cache and > eliminate the VFS, and replace them with a simple disk cache that > writes all assets in raw format, with files named by UUID on disk. > > * Decode all JPEG2000's once, to all levels of mipmap scale, and write > the raw RGB mipmaps to disk as individual files (UUID+mipscale.bmp), > discarding the source JP2's. > > * Decode all OGGs to WAV once, and write the raw WAV to disk, > discarding the OGGs. > > * Oh, and don't ever delete any assets until your dedicated 2 terabyte > cache drive is 99.99% full. > > * Let the local operating system deal with the file caching. If you > have 4+ gig of system memory, let the OS manage it for caching > frequently accessed world data. > > This cache would much simpler than the layered mess of caches > currently used, and it would give a speed boost over the constant JP2 > to RGB mipmap decoding and discarding that is in place now. Decode > once and don't ever do it again. > > , > > But I know it is just a dream. LL will never let it happen since it > will lay bare the data contents of every prim, texture, and object in > the virtual world, rather than obfuscating asset storage within the > current VFS / JP2 method. > > This viewer would get blacklisted before it ever got out the door. > > - Dale Mahalko / Scalar Tardis > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Externally controllable viewers?
Who's currently working on doing external control of viewer functions, especially avatar control? I know of a few people doing AR sorts of things that would qualify and some of the viewer-plugin and modularity work would certainly help. I'm going to be doing some viewer hacking to allow some additional input devices and would like to be as general as possible (and not reinvent the wheel). Many thanks Vex ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Externally controllable viewers?
No - avatar motion, gestures, animation from a non-viewer and non-SL source... probably chat, possibly lookat and touch. Heck, I'd love to get some of the old "avatar puppetry" stuff involved, but that'll be overkill for this use. If all I was interested in was control, I'd use libopenmetaverse, but there will be a real person watching their avatar interact with SL, just not using traditional controls. On 9/18/2010 7:23 PM, Altair Sythos Memo wrote: > On Sat, 18 Sep 2010 19:17:03 -0400 > Vex Streeter wrote: > >>Who's currently working on doing external control of viewer >> functions, especially avatar control? I know of a few people doing >> AR sorts of things that would qualify and some of the viewer-plugin >> and modularity work would certainly help. I'm going to be doing some >> viewer hacking to allow some additional input devices and would like >> to be as general as possible (and not reinvent the wheel). > sorry... do you mean sort of bot for group invite and similar when you > say "eexternal control"? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Question about the Too Many Open Files problem
HTTP textures seems to make an already bad situation worse. A very large number of the open files I see on Linux are fonts: I've seen up to 20 FDs pointing to the same font file - I typically run under linux with a ulimit of 2048 to avoid the issue. I see similar things on Windows (7) but it is neither quite as bad (fewer fonts maybe?) nor happens to hit whatever fd limit windows has. One of the problems with running out of FDs is that the viewer can fail in all sorts of bizarre ways and will often not be able to dump a useful log. On 9/19/2010 11:33 AM, leliel wrote: > I have exactly the same problem, except I'm using linux and my ulimit > is 1024. When I have http-textures enabled and I teleport the open > files hover around 850-950 with the viewer intermittently running out > of file descriptors. This causes about 1/3 of the http connections to > time out, presumably waiting for a free file descriptor, after this > happens for 30 seconds or so the cache system will get confused and > clear the whole cache, often 2 or 3 times per teleport. Eventually the > viewer will give up on the textures leaving 1/3 of the world gray. As > you might imagine, this makes http-textures completely unusable for > me. > > Occasionally the viewer will run out of file descriptors for too long > and crash, I had this happen to me once when some one IM'd me and the > viewer couldn't open the log file. > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Externally controllable viewers?
Awesome! This looks like very much like what I want! Cheers, Vex On 9/19/2010 6:19 PM, Dzonatas Sol wrote: > Hi, > > > Have a look at SNOW-375. It sounds like what you want. > > Also see Icesphere, which uses SNOW-375 to create detach windows and > chat. It also supports remote chat sessions to the viewer... for > multiple windows or multiple home computers. > > > > > Vex Streeter wrote: >> Who's currently working on doing external control of viewer >> functions, especially avatar control? I know of a few people doing >> AR sorts of things that would qualify and some of the viewer-plugin >> and modularity work would certainly help. I'm going to be doing some >> viewer hacking to allow some additional input devices and would like >> to be as general as possible (and not reinvent the wheel). >> >> Many thanks >> Vex >> ___ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Snowglobe 2 and strange sound issue
I'm having a strange problem on a home-built snowglobe 2 with sound... or rather lack thereof: scripted sounds don't result in any audible output. Environmental sounds work find (footsteps, wind, etc), streaming works (radio), and voice works... but if I click that bell, nothing happens. The thing that is really baffling me is that if I select a sound from inventory and "play locally" it plays fine, but "play in world" does nothing. Any hints or thoughts would be most welcome. I'm running a slightly modified variation of Snowglobe 2 on windowsxp (32bit), compiled with VS8/2005. Ring any bells? Thanks much, Vex ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
