On Thursday, 13 August 2015 at 21:05:28 UTC, rsw0x wrote:
On Thursday, 13 August 2015 at 20:56:36 UTC, Tofu Ninja wrote:
Something I thought about today, if a class or struct is
allocated by an allocator(say a malloc based allocator) and
one of its fields is populated with a reference to GCed
On Thursday, 13 August 2015 at 20:56:36 UTC, Tofu Ninja wrote:
Something I thought about today, if a class or struct is
allocated by an allocator(say a malloc based allocator) and one
of its fields is populated with a reference to GCed memory,
will the GC know to scan the allocator memory to ke
Something I thought about today, if a class or struct is
allocated by an allocator(say a malloc based allocator) and one
of its fields is populated with a reference to GCed memory, will
the GC know to scan the allocator memory to keep that GCed memory
alive?
On 7/14/15 7:35 AM, Jacob Carlborg wrote:
On 2015-07-13 20:52, Andrei Alexandrescu wrote:
That design would have been possible, e.g. have deallocate return false,
owns return Ternary.unknown, expand return false, alignedAllocate return
null etc.
Perhaps it's a simplified view, but for all exa
On 2015-07-13 20:52, Andrei Alexandrescu wrote:
That design would have been possible, e.g. have deallocate return false,
owns return Ternary.unknown, expand return false, alignedAllocate return
null etc.
Perhaps it's a simplified view, but for all examples in the talk it
seems it would work w
On 2015-07-12 18:10, Dmitry Olshansky wrote:
But then a Parent allocator would like to know if the child actually
doesn't support reallocate vs say failing to reallocate. In the former
case a lot of extra logic is simply removed at compile-time.
Perhaps this is a simplified view, but most case
On 7/12/15 11:08 AM, Jacob Carlborg wrote:
On 2015-06-12 13:06, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has arrived at
your doorsteps and kindly asks to let it into Phobos
http://wiki.dlang.org/Review/std.experimental.allocator
Docs:
http://erdani.com/d/phobos-pre
On 12-Jul-2015 18:08, Jacob Carlborg wrote:
On 2015-06-12 13:06, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has arrived at
your doorsteps and kindly asks to let it into Phobos
http://wiki.dlang.org/Review/std.experimental.allocator
Docs:
http://erdani.com/d/phobos-pr
On 2015-06-12 13:06, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has arrived at
your doorsteps and kindly asks to let it into Phobos
http://wiki.dlang.org/Review/std.experimental.allocator
Docs: http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
Code
On Friday, 12 June 2015 at 11:06:43 UTC, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has
arrived at your doorsteps and kindly asks to let it into Phobos
Sorry for being late, I wanted to restate an idea that could be
crucial for optimizations.
https://github.com/D-Pr
On Tuesday, 30 June 2015 at 06:07:14 UTC, Baz wrote:
On Friday, 26 June 2015 at 15:23:25 UTC, Alex Parrill wrote:
On Friday, 26 June 2015 at 14:56:21 UTC, Dmitry Olshansky
wrote:
[...]
Yea, VirtualAlloc seems like a better fit. (I don't actually
know the windows API that well)
[...]
Her
On Friday, 26 June 2015 at 15:23:25 UTC, Alex Parrill wrote:
On Friday, 26 June 2015 at 14:56:21 UTC, Dmitry Olshansky wrote:
[...]
Yea, VirtualAlloc seems like a better fit. (I don't actually
know the windows API that well)
[...]
Here's the paragraph I'm reading:
Mapped views of a file
On Friday, 26 June 2015 at 13:35:34 UTC, Dicebot wrote:
It is ok to use that time for any
additional comments :P
I would second the suggestion for improvement in the
documentation. The overview linked to in the original post is
written assuming advanced programming knowledge. My understanding
On Friday, 26 June 2015 at 14:56:21 UTC, Dmitry Olshansky wrote:
On 26-Jun-2015 17:51, Alex Parrill wrote:
The Windows MMap allocator only keeps one HANDLE around, and
creates a
new one on each `allocate`. Thus, `deallocate` closes the
latest handle,
regardless of what it was actually passed,
On 26-Jun-2015 17:51, Alex Parrill wrote:
The Windows MMap allocator only keeps one HANDLE around, and creates a
new one on each `allocate`. Thus, `deallocate` closes the latest handle,
regardless of what it was actually passed, so it leaks.
Actually I don't see why Windows couldnt' just use V
The Windows MMap allocator only keeps one HANDLE around, and
creates a new one on each `allocate`. Thus, `deallocate` closes
the latest handle, regardless of what it was actually passed, so
it leaks.
If I'm reading the docs for `CreateFileMapping` right, you should
be able to close the handle
On Thursday, 25 June 2015 at 13:36:31 UTC, Dicebot wrote:
1 day remaining
FYI: considering
http://forum.dlang.org/thread/mmhjqe$2mud$1...@digitalmars.com there
will be some delay between finishing the review period and
starting voting process. It is ok to use that time for any
additional co
1 day remaining
On Wednesday, 24 June 2015 at 04:00:11 UTC, Andrei Alexandrescu
wrote:
std.allocator.allocator.IAllocator
std.allocator.allocator.theAllocator;
Yep, "ridiculous" is the first thing that comes to mind.
I find it difficult to digest (ehm) the fact that the same
community that thinks "std.allo
On 6/23/15 6:11 PM, Mike wrote:
It seems there is already precedent with std.digest.digest
(http://dlang.org/phobos/std_digest_digest.html). I'm sorry I wasn't
aware of this at the time. std.allocator.porcelain couldn't stand, and
I suggested what seemed most natural to me. I've spend a number
On Tuesday, 23 June 2015 at 21:12:10 UTC, Dicebot wrote:
On Tuesday, 23 June 2015 at 19:17:21 UTC, Andrei Alexandrescu
The "import std.allocator" is already minimal - only contains
the high level stuff. -- Andrei
So you have chosen worst of both worlds - neither give power
users ability t
Ok, if you feel so strongly about it, let's not waste time in
arguing. You are not obliged to agree to any of reviewer comments
so as long as everyone is clear about their opinion, the eventual
voting will decide. I am simply pointing out things that catch my
attention.
On 6/23/15 6:18 PM, Andrei Alexandrescu wrote:
On 6/23/15 3:17 PM, Steven Schveighoffer wrote:
we need to redo
no
Yeah, so then it becomes import std.somepackage means import all the
modules in that package, except for std.allocator. But that's fine, if
we want that type of inconsistency,
On 6/23/15 6:07 PM, Andrei Alexandrescu wrote:
On 6/23/15 2:12 PM, Dicebot wrote:
So you have chosen worst of both worlds - neither give power users
ability to fine tune imports nor allow casual users always go with
`import std.allocator` and be happy? :)
There is functionality in std.allocato
On 6/23/15 3:17 PM, Steven Schveighoffer wrote:
we need to redo
no
On Tuesday, 23 June 2015 at 19:16:33 UTC, Andrei Alexandrescu
wrote:
The case with std.allocator is not everything is imported in
it, so no bloating no nothing. -- Andrei
My assumption with D libraries is that "import std.thing;"
imports everything in the the whole package.
Not that I've
On 6/23/15 2:29 PM, Dmitry Olshansky wrote:
I'm not sure if that's the case with std.allocator but importing package
IMHO should import _typical_ set of submodules.
Things that are more niche and rare (power user oriented) shouldn't
really be in package.d
Yah, that attitude describes std.alloc
On 6/23/15 2:12 PM, Dicebot wrote:
So you have chosen worst of both worlds - neither give power users
ability to fine tune imports nor allow casual users always go with
`import std.allocator` and be happy? :)
There is functionality in std.allocator to get anyone started who
doesn't want to sit
On 6/23/15 2:14 PM, Tofu Ninja wrote:
On Tuesday, 23 June 2015 at 21:12:10 UTC, Dicebot wrote:
So you have chosen worst of both worlds - neither give power users
ability to fine tune imports nor allow casual users always go with
`import std.allocator` and be happy? :)
If anything, that will be
On 24-Jun-2015 00:12, Dicebot wrote:
On Tuesday, 23 June 2015 at 19:17:21 UTC, Andrei Alexandrescu wrote:
On 6/23/15 10:16 AM, Dicebot wrote:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick con
On Tuesday, 23 June 2015 at 19:17:21 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 10:16 AM, Dicebot wrote:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't
think a
package.d shoul
On Tuesday, 23 June 2015 at 21:12:10 UTC, Dicebot wrote:
So you have chosen worst of both worlds - neither give power
users ability to fine tune imports nor allow casual users
always go with `import std.allocator` and be happy? :)
If anything, that will be the first package.d in Phobos (AFAIK)
On 6/23/15 10:16 AM, Dicebot wrote:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't think a
package.d should ever have anything except imports in it"
(see http://forum.dlang.org/
On 6/23/15 10:15 AM, Adam D. Ruppe wrote:
On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu wrote:
But that doesn't apply to packages that do NOT originate as big
modules, so they have no backward compatibility issue.
My thought isn't really about backward compatibility but about
m
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't
think a
package.d should ever have anything except imports in it"
(see
http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dla
On Tuesday, 23 June 2015 at 16:56:55 UTC, Andrei Alexandrescu
wrote:
But that doesn't apply to packages that do NOT originate as big
modules, so they have no backward compatibility issue.
My thought isn't really about backward compatibility but about
minimizing dependencies with sibling module
On 6/23/15 9:53 AM, extrawurst wrote:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't think a
package.d should ever have anything except imports in it"
(see http://forum.dlang.or
Am 23.06.2015 um 18:53 schrieb extrawurst:
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't think a
package.d should ever have anything except imports in it"
(see http://forum.dla
On Tuesday, 23 June 2015 at 16:49:45 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't
think a
package.d should ever have anything except imports in it"
(see
http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dla
On 6/23/15 9:48 AM, extrawurst wrote:
I agree with Adam on this: "Just a quick concern, I don't think a
package.d should ever have anything except imports in it"
(see http://forum.dlang.org/post/qwatonmpnoyjsvzjp...@forum.dlang.org)
What is the rationale? -- Andrei
On Tuesday, 23 June 2015 at 15:56:15 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 2:18 AM, Dicebot wrote:
On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu
wrote:
Perhaps I misunderstood the request - currently the imports in
allocator/package.d are:
public import std.experimental.all
On 6/23/15 8:56 AM, Andrei Alexandrescu wrote:
I see. Well this raises the question whether importing std.xyz
automatically means everything under std.xyz is transitorily imported.
s/transitorily/transitively/
On 6/23/15 2:18 AM, Dicebot wrote:
On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu wrote:
Perhaps I misunderstood the request - currently the imports in
allocator/package.d are:
public import std.experimental.allocator.common,
std.experimental.allocator.typed; import std.algorithm,
On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu
wrote:
Perhaps I misunderstood the request - currently the imports in
allocator/package.d are:
public import std.experimental.allocator.common,
std.experimental.allocator.typed;
import std.algorithm, std.conv, std.exception, std.r
On 6/21/15 4:47 AM, Dicebot wrote:
6. Usage of ternary is not always clear / justified. In `IAllocator` it
is explained and makes sense but there are things like
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_bitmapped_block.html
("Ternary empty() - Returns true iff no memory is
On 6/21/15 4:47 AM, Dicebot wrote:
5.
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_stats_collector.html
has no overview documentation at all
https://github.com/D-Programming-Language/phobos/commit/ef6de891197db6d497df11c9350781eef38df196
Andrei
On 6/22/15 2:40 PM, Dicebot wrote:
On Monday, 22 June 2015 at 19:51:50 UTC, Andrei Alexandrescu wrote:
2. `IAllocator` is defined inside `package.d` file. That means that it
is impossible to use interface without import ALL of allocator modules
Fixed, now interested users need to import
std.ex
On Monday, 22 June 2015 at 19:51:50 UTC, Andrei Alexandrescu
wrote:
2. `IAllocator` is defined inside `package.d` file. That means
that it
is impossible to use interface without import ALL of allocator
modules
Fixed, now interested users need to import
std.experimental.allocator.building_bloc
On 6/21/15 4:47 AM, Dicebot wrote:
4. There are no higher level usage examples and/or guidelines about how
this is supposed to fit in user applications. Intention behind the
library may be familiar to users coming from C++ but target D audience
is much more than that. Having std.allocator.showcas
On 6/21/15 4:47 AM, Dicebot wrote:
1. I have already mentioned that there is neither module structure
overview in `package.d` nor actual module structure. This is still the
case for
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
Improved:
http://erdani.com/d/phobos-prere
Can I use these allocators in @nogc code too ?
On 6/13/15 4:16 PM, ZombineDev wrote:
On Saturday, 13 June 2015 at 15:48:31 UTC, Andrei Alexandrescu wrote:
On 6/13/15 3:14 AM, Dicebot wrote:
Andrei, have you considered creating additional std.allocator.impl
package and moving actual allocators there? Or, probably, the other way
around with s
On 6/21/15 4:47 AM, Dicebot wrote:
1. I have already mentioned that there is neither module structure
overview in `package.d` nor actual module structure. This is still the
case for
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
2. `IAllocator` is defined inside `package.d`
Ok, as there has not been much attention here in last days, I
will put a short summary of my own.
In general, I believe this is extremely high quality proposal and
Andrei stands up to his reputation. The very design seems to fit
with D idiomatics and it may change completely how people think
On Tue, 16 Jun 2015 16:29:08 -0400, Andrei Alexandrescu
wrote:
On Saturday, 13 June 2015 at 19:08:26 UTC, Jacob Carlborg wrote:
On 2015-06-12 13:06, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has arrived at
your doorsteps and kindly asks to let it into Phobos
htt
Bringing back to first page.
On 2015-06-16 22:29, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/commit/319f3297418c515a6d2e52e6e52d0f3f5895f587
changes .it to .instance for all allocators. -- Andrei
Awesome, thanks.
--
/Jacob Carlborg
On Saturday, 13 June 2015 at 19:08:26 UTC, Jacob Carlborg wrote:
On 2015-06-12 13:06, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has
arrived at
your doorsteps and kindly asks to let it into Phobos
http://wiki.dlang.org/Review/std.experimental.allocator
Docs:
http:/
On Sunday, 14 June 2015 at 22:47:59 UTC, Brian Schott wrote:
Not yet, but while looking for one I found that this code
triggers an assertion in Region.expand()
Running the above code with "GCAllocator" substituted for
"NullAllocator" causes an InvalidMemoryOperationError after all
100 iterati
On Sunday, 14 June 2015 at 14:30:00 UTC, Andrei Alexandrescu
wrote:
Interesting. Do you have a repro for this? Thanks! -- Andrei
Not yet, but while looking for one I found that this code
triggers an assertion in Region.expand()
```
module test;
import std.experimental.allocator;
import std.s
On 6/13/15 11:49 PM, Dicebot wrote:
On Sunday, 14 June 2015 at 00:24:51 UTC, Andrei Alexandrescu wrote:
So we have:
* 1 request to change names;
* 3 requests to wank around the directory structure;
* 0 of everything else.
Sigh.
That is to be expected and intended for formal Phobos review.
Im
On 6/14/15 4:00 AM, Brian Schott wrote:
On Sunday, 14 June 2015 at 00:24:51 UTC, Andrei Alexandrescu wrote:
So we have:
* 1 request to change names;
* 3 requests to wank around the directory structure;
* 0 of everything else.
Sigh.
Andrei
How about this:
AllocatorList.allocate() calls All
On Sunday, 14 June 2015 at 00:24:51 UTC, Andrei Alexandrescu
wrote:
So we have:
* 1 request to change names;
* 3 requests to wank around the directory structure;
* 0 of everything else.
Sigh.
Andrei
How about this:
AllocatorList.allocate() calls AllocatorList.owns(), but only if
you don't
On 2015-06-14 02:24, Andrei Alexandrescu wrote:
* 1 request to change names;
* 3 requests to wank around the directory structure;
* 0 of everything else.
Sigh.
These are things that are easy to see right away, without looking deep
inside the code.
You can interpret this as:
1. Either your
On Sunday, 14 June 2015 at 00:24:51 UTC, Andrei Alexandrescu
wrote:
So we have:
* 1 request to change names;
* 3 requests to wank around the directory structure;
* 0 of everything else.
Sigh.
That is to be expected and intended for formal Phobos review.
Implementation is not of much interest
So we have:
* 1 request to change names;
* 3 requests to wank around the directory structure;
* 0 of everything else.
Sigh.
Andrei
Yesterday I have found an error in documentation and have left a
comment about it on github PR.
And I only start to read the documentation, so I think there
On Sunday, 14 June 2015 at 00:24:51 UTC, Andrei Alexandrescu
wrote:
On 6/13/15 4:16 PM, ZombineDev wrote:
On Saturday, 13 June 2015 at 15:48:31 UTC, Andrei Alexandrescu
wrote:
On 6/13/15 3:14 AM, Dicebot wrote:
Andrei, have you considered creating additional
std.allocator.impl
package and movi
On 6/13/15 4:16 PM, ZombineDev wrote:
On Saturday, 13 June 2015 at 15:48:31 UTC, Andrei Alexandrescu wrote:
On 6/13/15 3:14 AM, Dicebot wrote:
Andrei, have you considered creating additional std.allocator.impl
package and moving actual allocators there? Or, probably, the other way
around with s
On Saturday, 13 June 2015 at 15:48:31 UTC, Andrei Alexandrescu
wrote:
On 6/13/15 3:14 AM, Dicebot wrote:
Andrei, have you considered creating additional
std.allocator.impl
package and moving actual allocators there? Or, probably, the
other way
around with std.allocator.core
Existing flat hier
On Saturday, 13 June 2015 at 15:48:31 UTC, Andrei Alexandrescu
wrote:
On 6/13/15 3:14 AM, Dicebot wrote:
Andrei, have you considered creating additional
std.allocator.impl
package and moving actual allocators there? Or, probably, the
other way
around with std.allocator.core
Existing flat hier
On 2015-06-12 13:06, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has arrived at
your doorsteps and kindly asks to let it into Phobos
http://wiki.dlang.org/Review/std.experimental.allocator
Docs: http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
Code
On 6/13/15 10:24 AM, Dicebot wrote:
On Saturday, 13 June 2015 at 15:48:31 UTC, Andrei Alexandrescu wrote:
On 6/13/15 3:14 AM, Dicebot wrote:
Andrei, have you considered creating additional std.allocator.impl
package and moving actual allocators there? Or, probably, the other way
around with std
On Saturday, 13 June 2015 at 15:48:31 UTC, Andrei Alexandrescu
wrote:
On 6/13/15 3:14 AM, Dicebot wrote:
Andrei, have you considered creating additional
std.allocator.impl
package and moving actual allocators there? Or, probably, the
other way
around with std.allocator.core
Existing flat hier
On 6/13/15 3:14 AM, Dicebot wrote:
Andrei, have you considered creating additional std.allocator.impl
package and moving actual allocators there? Or, probably, the other way
around with std.allocator.core
Existing flat hierarchy does not hint about internal structure in any way.
It's good docu
Andrei, have you considered creating additional
std.allocator.impl package and moving actual allocators there?
Or, probably, the other way around with std.allocator.core
Existing flat hierarchy does not hint about internal structure in
any way.
On 6/12/15 4:07 PM, Tofu Ninja wrote:
Are there any plans to have new and delete call out to theAllocator or
processAllocator?
In the future we may rig things that way. -- Andrei
On Friday, 12 June 2015 at 15:54:27 UTC, Andrei Alexandrescu
wrote:
On 6/12/15 8:54 AM, Andrei Alexandrescu wrote:
* A dynamicaly-typed layer that allows the user to swap
allocators at
runtime. This is embodied in IAllocator, CAllocatorImpl,
theAllocator,
and processAllocator.
Forgot to ment
On Friday, 12 June 2015 at 19:19:55 UTC, Andrei Alexandrescu
wrote:
On 6/12/15 11:23 AM, Baz wrote:
On Friday, 12 June 2015 at 11:09:01 UTC, Dicebot wrote:
Small tip for reviewers: there are quite many modules in
proposed
package but majority is actual allocator implementation. I'd
suggest
to
On 6/12/15 11:23 AM, Baz wrote:
On Friday, 12 June 2015 at 11:09:01 UTC, Dicebot wrote:
Small tip for reviewers: there are quite many modules in proposed
package but majority is actual allocator implementation. I'd suggest
to start investigating sources/documentation starting from
http://erdani.
On Friday, 12 June 2015 at 11:09:01 UTC, Dicebot wrote:
Small tip for reviewers: there are quite many modules in
proposed package but majority is actual allocator
implementation. I'd suggest to start investigating
sources/documentation starting from
http://erdani.com/d/phobos-prerelease/std_ex
On 6/12/15 8:54 AM, Andrei Alexandrescu wrote:
* A dynamicaly-typed layer that allows the user to swap allocators at
runtime. This is embodied in IAllocator, CAllocatorImpl, theAllocator,
and processAllocator.
Forgot to mention - the entry point for this layer is also
http://erdani.com/d/phobo
On 6/12/15 4:08 AM, Dicebot wrote:
Small tip for reviewers: there are quite many modules in proposed
package but majority is actual allocator implementation. I'd suggest to
start investigating sources/documentation starting from
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.htm
On 6/12/15 7:31 AM, Jacob Carlborg wrote:
On 2015-06-12 13:06, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has arrived at
your doorsteps and kindly asks to let it into Phobos
http://wiki.dlang.org/Review/std.experimental.allocator
Docs:
http://erdani.com/d/phobos-prer
On 2015-06-12 13:06, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has arrived at
your doorsteps and kindly asks to let it into Phobos
http://wiki.dlang.org/Review/std.experimental.allocator
Docs: http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
Code
On Friday, 12 June 2015 at 11:06:43 UTC, Dicebot wrote:
The legendary allocator package by Andrei Alexandrescu has
arrived at your doorsteps and kindly asks to let it into Phobos
http://wiki.dlang.org/Review/std.experimental.allocator
Docs:
http://erdani.com/d/phobos-prerelease/std_experiment
Also wanted to apologize for authors of any other Phobos
proposals - I did intend to step down from review manager role
but this specific package is of huge personal interest to me,
thus the exception has been made.
Small tip for reviewers: there are quite many modules in proposed
package but majority is actual allocator implementation. I'd
suggest to start investigating sources/documentation starting
from
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
and
http://erdani.com/d/phobo
The legendary allocator package by Andrei Alexandrescu has
arrived at your doorsteps and kindly asks to let it into Phobos
http://wiki.dlang.org/Review/std.experimental.allocator
Docs:
http://erdani.com/d/phobos-prerelease/std_experimental_allocator.html
Code:
https://github.com/andralex/phob
88 matches
Mail list logo
