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
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
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
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
*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
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
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
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
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"
> 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
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
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
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
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
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
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 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
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: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
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
> 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
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
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'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
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
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
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
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
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 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
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
> 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
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
33 matches
Mail list logo
