Re: [opensource-dev] Script Memory Limits UI

Change requires work. Unnecessary, unwanted, and uncalled for in this instance. We have to adapt to handle a part of the task that LL was supposed to do themselves. Oh of course this is a hard job, allocating memory dynamically in an environment like this. Perhaps it is impossible. I have y

Re: [opensource-dev] Script Memory Limits UI

On Mon, Mar 8, 2010 at 8:40 PM, Lear Cale wrote: > It would be nice if everything were free, too... > Until now, script memory has seemed to be a free lunch.  Well, the > free lunch is over, and we'll have to deal with it. I wouldn't mind "dealing with" lunch not being free if a crappy bloated sc

Re: [opensource-dev] Script Memory Limits UI

On 2010-03-08, at 19:41, Lear Cale wrote: > Babbage has already said that LSO code will be "charged" 64K even > though it only uses 16K. Perhaps he's changed that decision -- is > that the case? I'd like some clarification there too, because I read that they'd backed down on that idea (which is

Re: [opensource-dev] Potential inventory problem?

That certainly sounds like the symptoms I'm seeing. One of my two CPUs is pegged, memory allocation for the Snowglobe process is all over the place (jumping up and down by 10s or 100s of MB at a time), and the hang seems to be indefinite. I haven't left it for more than three minutes, but by that t

Re: [opensource-dev] Script Memory Limits UI

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What if the memory allocation worked kinda like those bouncing bars on top of those audiofrquency/spectrum/VUmeter readouts on some stereos and many computer audio players, where it's fast to go up, but then it falls slowly back till it hits the curren

Re: [opensource-dev] Script Memory Management Algorithm

Please tell me how to register for this list. I was registered for sldev, but don't remember how. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep un

Re: [opensource-dev] Script Memory Management Algorithm

huh? Can you point to existing technology for this analyzer? Seems to me like it would require an oracle. On Mon, Mar 8, 2010 at 2:03 PM, Michael Schlenker wrote: > > Am 08.03.2010 um 18:46 schrieb Kelly Linden: > >> We are not out to write a new malloc for mono.  What we have is a system >>

Re: [opensource-dev] Question regarding llSetLinkPimitiveParamsFast() function in 1.38.0

It's generally a bad idea to change behavior dramatically, and much safer to add a new function. Dramatic changes in behavior cause new bugs, or cause old but insignificant bugs to become significant. New functions don't. On Sun, Mar 7, 2010 at 9:39 AM, Obsidian Kindragon wrote: > Hi all, > >

Re: [opensource-dev] Script Memory Limits UI

It used to be that simple, with original LSO. With mono, it's more complicated, because two instances of the *exact* same script can share the code segments. I wonder whether this sharing ability will be taken into account. Ideally yes, because it's best when the metrics used to measure somethin

Re: [opensource-dev] Script Memory Limits UI

Babbage has already said that LSO code will be "charged" 64K even though it only uses 16K. Perhaps he's changed that decision -- is that the case? Regards Jeff On Sat, Mar 6, 2010 at 9:02 PM, Frans wrote: > In response to the OP. I agree the UI will have to present that information > differentl

Re: [opensource-dev] Script Memory Limits UI

It would be nice if everything were free, too. The issue is memory *allocation*. If a script only uses 16K but is allocated 64K, that 64K counts against the server's actual memory allocation limit. So, cool, wouldn't it be nice to only allocate what is actually requested? Well that implies rewr

Re: [opensource-dev] Potential inventory problem?

Ah, the comment by Qarl Linden in the JIRA issue nails the issue for that specific freeze bug: "i'm not sure how our external svn is configured - but i can explain the root of the problem. it's with our memory allocator (malloc/new/etc.) we switched back at 1.21, and the behavior of the inventory s

Re: [opensource-dev] Potential inventory problem?

Ah, the comment by Qarl Linden in the JIRA issue nails the issue for that specific freeze bug: "i'm not sure how our external svn is configured - but i can explain the root of the problem. it's with our memory allocator (malloc/new/etc.) we switched back at 1.21, and the behavior of the inventory s

Re: [opensource-dev] Potential inventory problem?

It does happen on the SL grid. At least it did for a long while, I have admit I use the texture picker not that often these days, but it has burned me pretty badly. How bad is the freeze? How long is it? Edit: Found this JIRA, might be relevant to the problem I think, the freeze bug used to exist

Re: [opensource-dev] Snowglobe as an mixed reality platform

I would wish everything to be as honest and open as you've described it, Merov. The problem is that the open source / TPV community has been battered around the head too much recently (by factors outside of your control, I'm sure), and when the answer to everything seems to be "No" except when it

Re: [opensource-dev] Snowglobe as an mixed reality platform

Hey, Been waiting on this a while. Has there been any progress been made Tuomas? As Merov already mentioned we're willing to give help. If you need a place to host documentation and/or code; - You can use the wiki to create a page for documentation over @ https://wiki.secondlife.com/wiki/Open_Sou

[opensource-dev] SnowGlobe/viewer 2 streaming media issue with new prim textures

https://jira.secondlife.com/browse/SNOW-566 This is a reference to: https://jira.secondlife.com/browse/VWR-17151 There are 14 votes for VWR-17151 in pJIRA, but I can't find a reference/link to it in any SnowGlobe jira and the issue shows up in my hand-built SnowGlobe 2 viewer, AND to some exte

Re: [opensource-dev] Potential inventory problem?

Hahaha, I remember back when Open Grid Services was written in PHP; I still have it on my webserver somewhere. I think I submitted a patch to you guys several years ago (regarding a SQL injection exploit) where I accidentally left in a bunch of cursing and racial slurs. If I contribute again, I

Re: [opensource-dev] SLPlugin lagging my viewer like crazy, maybe it was a

On Mon, 8 Mar 2010 13:46:32 +0100 Lance Corrimal wrote: > Am Montag, 8. März 2010 13:15:59 schrieb Opensource Obscure: > > > sounds like killall -9 SLPlugin if u killall all plugins stop to work, keep first child active, it fork other child sometime for some strange reason one of plugin be

Re: [opensource-dev] Snowglobe as an mixed reality platform

Hi Morgaine, I'm surprised and disappointed you're reading so much into this. Personal (and irrelevant) feelings aside, my answer was motivated strictly by the following: - There is an already existing set of code with experimental results and it looks very nice indeed. - There's a chance all this

Re: [opensource-dev] Client Plugin System Design

On 2010-03-08, at 10:06, Morgaine wrote: > Unfortunately, as you know from your own work, Rob, there is a big > difference between using an embedded language inline with its host > application's main or single thread of execution, and turning the > language into a concurrent execution environ

Re: [opensource-dev] Client Plugin System Design

Indeed, Lawson. You may have seen it, but I provided a little more detail about accelerating plugin communications using Shared Memory segments in my answerto Tigro. In practice it's not easy to come up with an SM-accel

Re: [opensource-dev] Potential inventory problem?

Yes, I'm trying to push out the first release of a set of PHP grid services for OpenSim and the texture picker freeze bug is a showstopper. It obviously doesn't happen on SLGrid and it wasn't happening in the past with OpenSim. A packet trace didn't show anything interesting (doesn't appear to be t

Re: [opensource-dev] Script Memory Management Algorithm

Am 08.03.2010 um 18:46 schrieb Kelly Linden: > We are not out to write a new malloc for mono. What we have is a system that > throws an exception when the memory used by the script hits a certain > threshold (64k currently). This exception is caught so we can "crash" the > script. The futur

Re: [opensource-dev] Client Plugin System Design

Morgaine wrote: > > > PS. With regards to "Networking code in every plugin just to connect > to the client", networking is made available by the operating system > to every process through system calls or system subroutines, ie. the > thinnest interface possible. There is no bloat or overhead i

Re: [opensource-dev] Script Memory Management Algorithm

We are not out to write a new malloc for mono. What we have is a system that throws an exception when the memory used by the script hits a certain threshold (64k currently). This exception is caught so we can "crash" the script. The future small scripts and big scripts projects will add new func

Re: [opensource-dev] Potential inventory problem?

Happens just as well on any grid. I'm just as confused as anyone here what this error message means, but this was brought up before and I vaguely remember a linden saying that wasn't the source of the lag problems related to inventory. Are you trying to track down the texture picker freezing bug?

Re: [opensource-dev] Client Plugin System Design

Yes, there is a way, Tigro. In the Multi-Process Clientdesign that we started back when AWG was active, we loosely defined "Facility Optimization", which would be done mainly through communication * accelerators*. The general ide

Re: [opensource-dev] Client Plugin System Design

Lua provides a fine example of Direct Language Embedding. The language was designed expressly for being embedded in a host application as well as for being extended with calls to other languages. It's no surprise then that it is very clean and simple to use in this way. I like Lua a lot. Unfort

Re: [opensource-dev] SLPlugin lagging my viewer like crazy, maybe it was a

I've seen this behaviour as well in Viewer 2 on a Fedora 12 x64 system. Mike -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Lance Corrimal Sent: Monday, March 08, 2010 6:47 AM To: opensource-dev@lists

Re: [opensource-dev] Client Plugin System Design

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Would there be an approach that would allow both all the benefits you mention, plus letting the process based plugins have access to the bare metal performance? (somthing like a way to have the plugins instruct the client to add the desired processing

Re: [opensource-dev] SLPlugin lagging my viewer like crazy, maybe it was a

Am Montag, 8. März 2010 13:15:59 schrieb Opensource Obscure: sounds like killall -9 SLPlugin > I'm not competent enough to give you a better reply, > but this was already discussed here a few weeks ago, > there are 1 or 2 JIRA entries about it. > > I don't see this happening on Viewer 2, BTW, >

Re: [opensource-dev] SLPlugin lagging my viewer like crazy , maybe it was a bad idea from the start?

I got this too, but in my case, "system plugins" didn't get loaded. Quicker workaround for restoring performances: kill -9 the single processes, without need to relog. As said - workaround, not solution. I'm not competent enough to give you a better reply, but this was already discussed here a

Re: [opensource-dev] Client Plugin System Design

On Sun, 2010-03-07 at 18:19 -0800, Ricky wrote: > So far, barring any LL concepts, we have (as far as I know so far!) > two designs of plugin system: > 1: Socket-based plugins - as suggested by Morgaine. > 2: D-Bus or similar existing IPC tool. > 3: C++ Dynamically Shared Objects - my suggestion.

[opensource-dev] SLPlugin lagging my viewer like crazy, maybe it was a bad idea from the start?

Hey folks, I've been noticing the following behaviour (on linux): after some time logged i on snowglobe (latest svn checkout of 2009/trunk) I find that there are several copies of SLPlugin running in the background, and each of them loaded every single browser plugin installed on my system. I

Re: [opensource-dev] Client Plugin System Design

Ricky, I'm not sure even where to begin, because your proposed solution is simply direct embedding of one or more scripting language systems into the address space of the viewer. This ignores every single advantage of process-separated plugins and replaces them with a catalog of problems that coul