ARCs have their place, sure! But letting it leak isn't acceptable in my
case.
Instead, in my use case, no deletes until the whole heap is released
makes way more sense (heaps are small, grow a bit, and get released). Since
the lifetime of the object becomes == the lifetime of the heap, there's
On 04/11/13 20:09, Oren Ben-Kiki wrote:
ARCs have their place, sure! But letting it leak isn't acceptable in
my case.
Instead, in my use case, no deletes until the whole heap is
released makes way more sense (heaps are small, grow a bit, and get
released). Since the lifetime of the object
Is it possible to use stuff from libextra within libstd?
It seems to me that it would set up a circular dependency
Even if it was possible technically, probably not a good idea from a
maintenance perspective to have such dependencies.
On 4 November 2013 07:10, Martin DeMello
Essentially, yes.
On Mon, Nov 4, 2013 at 11:59 AM, Huon Wilson dbau...@gmail.com wrote:
On 04/11/13 20:09, Oren Ben-Kiki wrote:
ARCs have their place, sure! But letting it leak isn't acceptable in my
case.
Instead, in my use case, no deletes until the whole heap is released
makes way
This is not a complete answer to your question, but I have toyed with
the idea of an (unsafely implemented but with safe interface) message
allocation library that would partially address your use
case. Unfortunately I think that implementing it would require
higher-kinded types.
The basic would
On 11/03/2013 11:10 PM, Martin DeMello wrote:
I've been looking at https://github.com/mozilla/rust/issues/6085 which
seems like it should be fairly simple to fix, however, the proposed
solution involves EnumSet from libextra.
Is it possible to use stuff from libextra within libstd? It seems to
hello
I'm new in the rust dev list, so sorry if the question has already been
rised.
But what is the reason to have 2 libraries std/extra? why not gathering all
in a single std library?
Thanks
G.
-
Gaetan
2013/11/4 Brian Anderson bander...@mozilla.com
On 11/03/2013 11:10 PM, Martin
On 11/04/2013 11:00 AM, Gaetan wrote:
hello
I'm new in the rust dev list, so sorry if the question has already
been rised.
But what is the reason to have 2 libraries std/extra? why not
gathering all in a single std library?
There are a few reasons for the split between std and extra.
In
How does this work without getting into a dependency loop at build time?
martin
On Mon, Nov 4, 2013 at 10:55 AM, Brian Anderson bander...@mozilla.com wrote:
On 11/03/2013 11:10 PM, Martin DeMello wrote:
I've been looking at https://github.com/mozilla/rust/issues/6085 which
seems like it
ok I understand, it will be like python which I really like the
modularity. I'm beginning to play a little with std::os as my first rust
programming, trying to add missing methods, etc, and I think this should
quite strategic to move to libextra and then to be splitted appart, this
would solve
On 11/04/2013 02:39 PM, Martin DeMello wrote:
How does this work without getting into a dependency loop at build time?
The std under test is not *actually* the standard library as seen by
compiler and runtime; as far as the compiler is concerned it is just
some library compiled with --test,
On 11/04/2013 03:09 PM, Gaetan wrote:
ok I understand, it will be like python which I really like the
modularity. I'm beginning to play a little with std::os as my first
rust programming, trying to add missing methods, etc, and I think this
should quite strategic to move to libextra and then
okay, i figure niko might want to do this himself, but i've marked my
interest on the bug if he doesn't.
martin
On Mon, Nov 4, 2013 at 4:42 PM, Brian Anderson bander...@mozilla.com wrote:
On 11/04/2013 03:09 PM, Gaetan wrote:
ok I understand, it will be like python which I really like the
On 11/04/2013 04:59 PM, Martin DeMello wrote:
okay, i figure niko might want to do this himself, but i've marked my
interest on the bug if he doesn't.
Ask niko for advice about the design, but he will be *happy* to let you
do it, guaranteed.
___
Greetings you delightful Rustic people,
Sound the death knell for segmented stacks.
The new runtime does not implement segmented stacks and it never will.
This decision has been brewing for some time, and now I'd like to make
it official and lay out the reasoning for posterity.
To recap,
Bill, memory is cheap.
On Mon, Nov 4, 2013 at 9:50 PM, Bill Myers bill_my...@outlook.com wrote:
The advantage of segmented stacks is that blocked tasks only take up as
much memory as they actually need to store state, so that for instance a
network server can use a task for each connection,
Note that as memory becomes cheaper and larger there will be more pressure
on 64-bit OS-es to switch to large pages; the number of pages needed to map
several GBs of memory today is already getting out of hand, causing TLB
misses to become a performance issue in some cases - imagine a system with
Having memory is cheap, accessing it isn't.
On Monday, November 4, 2013, Thad Guidry wrote:
Bill, memory is cheap.
On Mon, Nov 4, 2013 at 9:50 PM, Bill Myers
bill_my...@outlook.comjavascript:_e({}, 'cvml', 'bill_my...@outlook.com');
wrote:
The advantage of segmented stacks is that
18 matches
Mail list logo
