dsimcha wrote:
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
dsimcha wrote:
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
dsimcha Wrote:
3. This one is an order of magnitude less likely than the other two to
actually get implemented, at least by me
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> dsimcha wrote:
> > == Quote from Sean Kelly (s...@invisibleduck.org)'s article
> >> dsimcha Wrote:
> >>> 3. This one is an order of magnitude less likely than the other two to
> >>> actually get implemented, at least by
dsimcha wrote:
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
dsimcha Wrote:
3. This one is an order of magnitude less likely than the other two to
actually get implemented, at least by me, but how about thread-local
allocators so you can call malloc() without taking a lock? I va
Hello dsimcha,
== Quote from BCS (n...@anon.com)'s article
Hello dsimcha,
3. This one is an order of magnitude less likely than the other two
to actually get implemented, at least by me, but how about
thread-local allocators so you can call malloc() without taking a
lock? I vaguely remembe
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
> dsimcha Wrote:
> > 3. This one is an order of magnitude less likely than the other two to
> > actually get implemented, at least by me, but how about thread-local
> > allocators so you can call malloc() without taking a lock? I vaguely
dsimcha Wrote:
> 3. This one is an order of magnitude less likely than the other two to
> actually get implemented, at least by me, but how about thread-local
> allocators so you can call malloc() without taking a lock? I vaguely remember
> Sean saying he was working on that a while back, but I
== Quote from BCS (n...@anon.com)'s article
> Hello dsimcha,
> > 3. This one is an order of magnitude less likely than the other two
> > to actually get implemented, at least by me, but how about
> > thread-local allocators so you can call malloc() without taking a
> > lock? I vaguely remember Se
Hello dsimcha,
3. This one is an order of magnitude less likely than the other two
to actually get implemented, at least by me, but how about
thread-local allocators so you can call malloc() without taking a
lock? I vaguely remember Sean saying he was working on that a while
back, but I never
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> dsimcha wrote:
>>> == Quote from downs (default_357-l...@yahoo.de)'s article
I submitted a patch a while back for constant-time removeRange. Can we
dredge
>>> that one up and/or implement something similar? It'
dsimcha wrote:
> == Quote from downs (default_357-l...@yahoo.de)'s article
>> I submitted a patch a while back for constant-time removeRange. Can we dredge
> that one up and/or implement something similar? It's rather useful for things
> like
> stackthreads that need to add and remove lots of rang
== Quote from downs (default_357-l...@yahoo.de)'s article
> dsimcha wrote:
> > == Quote from downs (default_357-l...@yahoo.de)'s article
> >> I submitted a patch a while back for constant-time removeRange. Can we
> >> dredge
> > that one up and/or implement something similar? It's rather useful fo
dsimcha Wrote:
> == Quote from Jason House (jason.james.ho...@gmail.com)'s article
> > Please add weak references! I can email you a druntime compatible
> > implementation.
>
> Probably be better to submit it as a patch to Bugzilla if it's reasonably
> well-tested and working already. On the ot
dsimcha, el 3 de noviembre a las 05:46 me escribiste:
> During my occasional forays into the dark side of Python and Java, I am often
> amazed at the extent to which memory management in these languages "just
> works". D should be like this for all but the most low-level programming
> tasks, and
== Quote from downs (default_357-l...@yahoo.de)'s article
> I submitted a patch a while back for constant-time removeRange. Can we dredge
that one up and/or implement something similar? It's rather useful for things
like
stackthreads that need to add and remove lots of ranges :)
> (Search the NG f
== Quote from Jason House (jason.james.ho...@gmail.com)'s article
> Please add weak references! I can email you a druntime compatible
> implementation.
Probably be better to submit it as a patch to Bugzilla if it's reasonably
well-tested and working already. On the other hand, I am curious to se
I submitted a patch a while back for constant-time removeRange. Can we dredge
that one up and/or implement something similar? It's rather useful for things
like stackthreads that need to add and remove lots of ranges :)
(Search the NG for "Feature req.+Patch: O(1) removeRange")
Please add weak references! I can email you a druntime compatible
implementation.
dsimcha Wrote:
> During my occasional forays into the dark side of Python and Java, I am often
> amazed at the extent to which memory management in these languages "just
> works". D should be like this for all but
During my occasional forays into the dark side of Python and Java, I am often
amazed at the extent to which memory management in these languages "just
works". D should be like this for all but the most low-level programming
tasks, and was intended to be. It seems like most of the other regulars h
18 matches
Mail list logo
