I'm naive here, I don't know the server side of it. But how can a sim
know when a script hits a threshold, and not be able to report the
actual memory used ? Since it can check it against a threshold...
On 8 mars 2010, at 18:46, Kelly Linden wrote:
We are not out to write a new malloc for
> So, cool, wouldn't it be nice to only allocate what is actually
> requested?
That -is- in the works, with the Small Scripts and Big Scripts
projects. it will allows you to reserve just as much memory as you
need for mono scripts, less than the 64k..or even more. But alas, yes,
time will have to
That's right. Computer programs are constantly managing two
contradictory resources, space and time. In theory we need control
over script time as much (no more no less) as we need control over
script memory. But let's not ask for even more additional workload
than we already have.
On 9
I believe that they're seeking better-informed legal counsel on GPL
compliance first, before redrafting the TPV. The first version conflated
users, viewers and developers so terribly that GPLv2 clause 6 was left in
tatters. Joe's phrasing is the only one that makes the necessary separation
so fa
It's not impossible... it's actually rather simple.
That being said, I wouldn't be surprised if LL feels it's too
difficult for them.
[ I suppose remarks like this (that it is simple) have usually not got
any weight, therefore I already added the fact that I wrote a malloc
library myself in the p
Carlo +1.
Explicit pre-allocation of memory by users has to be one of the silliest and
most regressive "improvements" appearing in SL for a long time. It's a
waste of memory, it takes us back decades, and it's a burden on users.
So why do it?
"Because we've decided to, full stop." -- seems to b
On 2010-03-09, at 07:26, Carlo Wood wrote:
> This is exactly the kind of reaction that drives me away from here.
>
> I propose a simple way get FOUR times the memory for all the
> scripts, at
> no other cost than adding some malloc code to your mono engine.
I don't think you have established tha
It has been 14 days since the initial draft of the 3PVP was published and we
were told it will be reworked to include comments, concerns and suggestions.
Two weeks have passed since and besides a FAQ that also says the policy is
being worked on there have been no news.
As this is a mission crit
This is exactly the kind of reaction that drives me away from here.
I propose a simple way get FOUR times the memory for all the scripts, at
no other cost than adding some malloc code to your mono engine.
And you simply say, "This is what we ARE doing, we're not going to change that".
Why this i
I'm inclined to agree. Not to mention addressed the cost of maintaining a
forked version of mono and the effort to forward port it into new releases.
I suppose it's possible that a change to malloc could make script memory
allocation problems much simpler but that seems highly unlikely. More l
So...
If the script hits a memory wall, there's no way to transparently increase
that wall and start reporting that the script is taking more RAM? Or has
the stack+heap collided with each other at that point and there's no way to
reform the memory space? Isn't this already something that scripts
I don't think that dynamic memory would be hard to implement, but
problem is that avatar/parcel have (or is going to have) limited memory
available.
1) It is not possible swap memory to server's hard drive - because that
would cause lag - and is actually reason behind why memory limits are
com
> It might be possible to add display of memory currently used
> as well, but what's the use case for it?
It would allow residents to independently review the imposed script limits.
Another use case would be because people *are* going to start banning
residents based on what the script limits UI
Many apologies if this has been discussed at length in a place that I've
missed...
I'm a bit baffled by the continuing strong focus on memory utilization of
scripts rather than CPU load on the host servers. If (maybe I'm missing an
important issue here) the issue is to avoid a resident or scripted
On Tue, 9 Mar 2010 14:47:35 +
Morgaine wrote:
> I believe that they're seeking better-informed legal counsel on GPL
> compliance first, before redrafting the TPV. The first version
> conflated users, viewers and developers so terribly that GPLv2 clause
> 6 was left in tatters. Joe's phrasi
On 2010-03-09, at 14:12, Tayra Dagostino wrote:
> I think yoiu've misreaded the TPV policy, no GPL violation, viewer
> code is GPL, you can take a copy from svn, manipulate it, patch or
> mood, rename it, all GPL let u do with it (and consequential charges
> for a developer who work on a GPL code)
On Tue, 9 Mar 2010 14:23:33 -0600
Argent Stonecutter wrote:
> On 2010-03-09, at 14:12, Tayra Dagostino wrote:
> > I think yoiu've misreaded the TPV policy, no GPL violation, viewer
> > code is GPL, you can take a copy from svn, manipulate it, patch or
> > mood, rename it, all GPL let u do with it
Read sections 4b,7a, 7c, 8c and 8d for a start - references to
distributing viewers and how you must not do so under certain
circumstances.
All of these restrictions contradict the rights granted by the GPL. LL
could argue that any releases after this policy constitute a release
under a new licens
On 2010-03-09, at 14:38, Tayra Dagostino wrote:
> On Tue, 9 Mar 2010 14:23:33 -0600
> Argent Stonecutter wrote:
>
>> On 2010-03-09, at 14:12, Tayra Dagostino wrote:
>>> I think yoiu've misreaded the TPV policy, no GPL violation, viewer
>>> code is GPL, you can take a copy from svn, manipulate it
Hi Joel.
This is an interesting issue. You would think CPU would be the big issue,
but really it isn't.
* We actually do a decent job of time slicing scripts. You add a lot of
scripts and in general just the scripts run slower, sim performance isn't
that impacted.
* WAIT! Before you yell at me
Many of the requirements are in fact unreasonable unless they are
rephrased to apply ONLY when connecting to LL's servers
On Tue, Mar 9, 2010 at 8:54 PM, Argent Stonecutter
wrote:
>
> On 2010-03-09, at 14:38, Tayra Dagostino wrote:
>
>> On Tue, 9 Mar 2010 14:23:33 -0600
>> Argent Stonecutter wro
Am 09.03.2010 um 02:54 schrieb Lear Cale:
> huh? Can you point to existing technology for this analyzer? Seems
> to me like it would require an oracle.
It might require an oracle to reach 100%, but if you go for the easy part, its
not that hard (assuming a sane GC). LSL is a pretty simple lan
Am 09.03.2010 um 23:57 schrieb Michael Schlenker:
>
> Am 09.03.2010 um 02:54 schrieb Lear Cale:
>
>> huh? Can you point to existing technology for this analyzer? Seems
>> to me like it would require an oracle.
For an example of such a technique for Java bytecodes:
http://citeseerx.ist.psu.ed
> I am simply pointing out that they are NOT compatible with the GPL.
GPL compatible or not - the sentence "The Snowglobe Viewer [...] this
viewer may be somewhat less stable than the official Second Life
viewer"( http://viewerdirectory.secondlife.com/ at 2010/03/10 00:06
GMT+1) is a slap into
It's the truth. Snowglobe is unstable.
~Tom
Armin Weatherwax wrote:
>> I am simply pointing out that they are NOT compatible with the GPL.
>>
> GPL compatible or not - the sentence "The Snowglobe Viewer [...] this
> viewer may be somewhat less stable than the official Second Life
> viewer"
At any given point in time, one viewer is more stable than another, and at
another point in time, it's the other way around. This is perfectly normal,
and blanket statements about superior stability make no sense ... especially
when they share common code! :-)
If anything, Snowglobe could well be
Don't new features get into snowglobe faster too? Thus more potential for bugs
On Wed, Mar 10, 2010 at 12:15 AM, Morgaine
wrote:
> At any given point in time, one viewer is more stable than another, and at
> another point in time, it's the other way around. This is perfectly normal,
> and blanke
On 10/03/2010 10:09 AM, Armin Weatherwax wrote:
>
>> I am simply pointing out that they are NOT compatible with the GPL.
>>
> GPL compatible or not - the sentence "The Snowglobe Viewer [...] this
> viewer may be somewhat less stable than the official Second Life
> viewer"( http://viewerd
*If only* new features got into Snowglobe faster. :-) The only things that
seem to get in fast are bug fixes. And of course IBM-sponsored code.
Admittedly, the rate is somewhat faster than into LL's main viewer ... but
then, it could hardly be slower! :-)
Talking about "LL's main viewer" ... w
Finally nailed this one down. If you have items in your inventory that have
completely empty permissions (basemask 0, everyonemask 0, currentmask 0,
etc) the viewer will freeze when you open the texture picker dialog. This
appears to affect all released versions of the viewer. The next obvious
ques
On 2010-03-09, at 19:06, John Hurliman wrote:
> Finally nailed this one down. If you have items in your inventory
> that have completely empty permissions (basemask 0, everyonemask 0,
> currentmask 0, etc) the viewer will freeze when you open the texture
> picker dialog. This appears to aff
Tayra, the GPL is about a lot more than merely providing modifiable sources.
GPL licenses specifically provide the freedom to modify and distribute GPL
sources *without "further restrictions"* being placed on developers beyond
the restrictions declared in the license itself. This is completely
di
Am Mittwoch 10 März 2010 schrieb Morgaine:
> *If only* new features got into Snowglobe faster. :-) The only
> things that seem to get in fast are bug fixes. And of course
> IBM-sponsored code.
>
> Admittedly, the rate is somewhat faster than into LL's main viewer
> ... but then, it could hardly
33 matches
Mail list logo
