> > 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
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
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
ma...@lindenlab.com
Zero Linden
zero.lin...@secondli
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 ot
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 texture
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/ins
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, esp
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
> projec
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 t
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 down
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
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 ind
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 spa
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.
___
Poli
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.
>
>
> 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 polici
> 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
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
> 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.
19 matches
Mail list logo
