It's been bitrotting for a while, I've rebased and it has passed tests
now. Who will do the honors?
https://github.com/D-Programming-Language/phobos/pull/3405
There are three pull requests open against my fork, I invite the authors
to rebase them or retarget them against the phobos mainline af
On Friday, 2 October 2015 at 13:12:47 UTC, Andrei Alexandrescu
wrote:
It's been bitrotting for a while, I've rebased and it has
passed tests now. Who will do the honors?
Done.
- Jonathan M Davis
On Friday, 2 October 2015 at 13:12:47 UTC, Andrei Alexandrescu
wrote:
It's been bitrotting for a while, I've rebased and it has
passed tests now. Who will do the honors?
[...]
Andrei
Just curious, why not just merge it yourself?
On Friday, 2 October 2015 at 21:55:56 UTC, bitwise wrote:
On Friday, 2 October 2015 at 13:12:47 UTC, Andrei Alexandrescu
wrote:
It's been bitrotting for a while, I've rebased and it has
passed tests now. Who will do the honors?
[...]
Andrei
Just curious, why not just merge it yourself?
The
On Friday, 2 October 2015 at 21:59:27 UTC, Brad Anderson wrote:
On Friday, 2 October 2015 at 21:55:56 UTC, bitwise wrote:
On Friday, 2 October 2015 at 13:12:47 UTC, Andrei Alexandrescu
wrote:
It's been bitrotting for a while, I've rebased and it has
passed tests now. Who will do the honors?
[.
On 10/02/2015 05:55 PM, bitwise wrote:
On Friday, 2 October 2015 at 13:12:47 UTC, Andrei Alexandrescu wrote:
It's been bitrotting for a while, I've rebased and it has passed tests
now. Who will do the honors?
[...]
Andrei
Just curious, why not just merge it yourself?
Sticking to procedure,
On 03/10/15 2:12 AM, Andrei Alexandrescu wrote:
It's been bitrotting for a while, I've rebased and it has passed tests
now. Who will do the honors?
https://github.com/D-Programming-Language/phobos/pull/3405
There are three pull requests open against my fork, I invite the authors
to rebase them
On Saturday, 3 October 2015 at 00:05:45 UTC, Andrei Alexandrescu
wrote:
Sticking to procedure, nothing more. Thanks Jonathan -
allocator is now in. Enjoy! -- Andrei
Superb! I'll spread the word, as usual 😉
On Friday, 2 October 2015 at 13:12:47 UTC, Andrei Alexandrescu
wrote:
It's been bitrotting for a while, I've rebased and it has
passed tests now. Who will do the honors?
https://github.com/D-Programming-Language/phobos/pull/3405
There are three pull requests open against my fork, I invite
the
On 10/03/2015 12:31 PM, John Colvin wrote:
On Friday, 2 October 2015 at 13:12:47 UTC, Andrei Alexandrescu wrote:
It's been bitrotting for a while, I've rebased and it has passed tests
now. Who will do the honors?
https://github.com/D-Programming-Language/phobos/pull/3405
There are three pull r
On 10/03/2015 12:31 PM, John Colvin wrote:
On Friday, 2 October 2015 at 13:12:47 UTC, Andrei Alexandrescu wrote:
It's been bitrotting for a while, I've rebased and it has passed tests
now. Who will do the honors?
https://github.com/D-Programming-Language/phobos/pull/3405
There are three pull r
It seems to me, that std.experimental.allocator should work with @nogc
annotated functions if none of the allocators being used are the
gcallocator, though it's not at all clear to me how this would work.
Are there plans for this?
Hi all,
tl;dr: I would like to start having GC-free methods and data
structures in Phobos, which depends on std.allocator being stable
(i.e not in experimental).
Q1: So I would like to know what's missing/blocking this? Is it
just time?
(FYI: std.experimental.allocator has been merg
On 09/05/2016 4:50 PM, Danni Coy via Digitalmars-d wrote:
It seems to me, that std.experimental.allocator should work with @nogc
annotated functions if none of the allocators being used are the
gcallocator, though it's not at all clear to me how this would work.
Are there plans for this?
On Monday, 9 May 2016 at 04:50:59 UTC, Danni Coy wrote:
It seems to me, that std.experimental.allocator should work
with @nogc annotated functions if none of the allocators being
used are the gcallocator, though it's not at all clear to me
how this would work.
Are there plans for this?
On Monday, 9 May 2016 at 05:00:31 UTC, rikki cattermole wrote:
On 09/05/2016 4:50 PM, Danni Coy via Digitalmars-d wrote:
It seems to me, that std.experimental.allocator should work
with @nogc
annotated functions if none of the allocators being used are
the
gcallocator, though it's not a
On 09/05/2016 5:16 PM, Hildigard Sandyman wrote:
On Monday, 9 May 2016 at 05:00:31 UTC, rikki cattermole wrote:
On 09/05/2016 4:50 PM, Danni Coy via Digitalmars-d wrote:
It seems to me, that std.experimental.allocator should work with @nogc
annotated functions if none of the allocators being
On Monday, 9 May 2016 at 05:27:24 UTC, rikki cattermole wrote:
On 09/05/2016 5:16 PM, Hildigard Sandyman wrote:
On Monday, 9 May 2016 at 05:00:31 UTC, rikki cattermole wrote:
On 09/05/2016 4:50 PM, Danni Coy via Digitalmars-d wrote:
It seems to me, that std.experimental.allocator should work
On 09/05/2016 6:22 PM, Hildigard Sandyman wrote:
It's true but... why do you bother with IAllocator ? Everything can be
set a compile time with a template parameter. As long as the param is a
struct with allocate/deallocate/reallocate it's OK. you can use already
a good part of the package conten
On Mon, May 9, 2016 at 3:10 PM, Hildigard Sandyman via Digitalmars-d
wrote:
> On Monday, 9 May 2016 at 04:50:59 UTC, Danni Coy wrote:
> It already mostly works in @nogc block:
> - Mallocator and AlignedMallocator are @nogc.
I was trying to use BitmappedBlock, AllocatorList and MmapAllocator
with
> It's true but... why do you bother with IAllocator ? Everything can be set a
> compile time with a template parameter. As long as the param is a struct
> with allocate/deallocate/reallocate it's OK. you can use already a good part
> of the package content in a @nogc fashion.
>
> Do you have an ex
clearly orientates the
answer:
It seems to me, that std.experimental.allocator should work
with @nogc
It should == It doesn't yet
Are there plans for this ?
Question is based on the previous wrong assumption, but since the
most important part of the message is the Q itself, it makes
peopl
On Monday, 9 May 2016 at 06:35:36 UTC, rikki cattermole wrote:
On 09/05/2016 6:22 PM, Hildigard Sandyman wrote:
It's true but... why do you bother with IAllocator ?
Everything can be
set a compile time with a template parameter. As long as the
param is a
struct with allocate/deallocate/realloca
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated out from usage,
you really do. Which is a major part of my requirements.
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated out
from usage, you really do. Which is a major part of my
requirements.
Well, in my ex
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation nicely separated out from
usage, you really do. Which is a major
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP.
But if you want to keep implementation n
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole wrote:
I've done windowing and image libraries before.
You are correct, you do not need OOP
On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, rikki cattermole
wrote:
I've done windowing
On 10/05/2016 12:33 AM, ZombineDev wrote:
On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole wrote:
On 09/05/2016 11:12 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 10:33:27 UTC, ri
On Monday, 9 May 2016 at 12:37:24 UTC, rikki cattermole wrote:
On 10/05/2016 12:33 AM, ZombineDev wrote:
On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rikki cattermole
wrote:
On 09/05/2016 11:12
On 10/05/2016 1:05 AM, ZombineDev wrote:
On Monday, 9 May 2016 at 12:37:24 UTC, rikki cattermole wrote:
On 10/05/2016 12:33 AM, ZombineDev wrote:
On Monday, 9 May 2016 at 12:02:19 UTC, rikki cattermole wrote:
On 09/05/2016 11:56 PM, ZombineDev wrote:
On Monday, 9 May 2016 at 11:20:00 UTC, rik
Currently the API's don't support const(void)[], e.g.
import std.experimental.allocator : makeArray, theAllocator,
dispose;
import std.experimental.allocator.mallocator : Mallocator;
void main()
{
const a = theAllocator.makeArray!ubyte(100);
theAllocator.dispose(a);
//
Q4: Current allocator API requires DRuntime to be linked. So,
they are not compatible with BetterC mode. Can this be fixed
before std.experimental.allocator -> std.allocator migration?
--Ilya
On 2016-12-10 05:18, Seb wrote:
Hi all,
tl;dr: I would like to start having GC-free methods and data structures
in Phobos, which depends on std.allocator being stable (i.e not in
experimental).
Q1: So I would like to know what's missing/blocking this?
I think it needs to be CTFE compatible. I
I am newbie to D learning it for sometime using Ali's book. I
came across std.experimental.allocator and read through
http://dlang.org/library/std/experimental/allocator/building_blocks.html . Can someone explain me the actual benefits of using this and if so any benchmarks explainin
When std.experimental.allocator was created, I was under the
impression it was meant to be used to make containers. But since
allocate() returns void[], casts are required before using that
memory, which is unsafe.
Is my only option to wrap the casts in an @trusted helper
function? or am I
Hi,
When I attempt to run the Phobos tests on my machine, I get the
following:
core.exception.AssertError@std\experimental\allocator\building_blocks\allocator_list.d(198):
Assertion failure
0x010AECF7 in _d_assert
0x00EBF05A in
D3std12experimental9allocator15building_blocks1
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
On Sunday, 15 July 2018 at 13:06:16 UTC, John Colvin wrote:
Currently the API's don't support const(void)[], e.g.
import std.experimental.allocator : makeArray, theAllocator,
dispose;
import std.experimental.allocator.mallocator : Mallocator;
void main()
{
On 7/15/18 9:06 AM, John Colvin wrote:
Currently the API's don't support const(void)[], e.g.
import std.experimental.allocator : makeArray, theAllocator, dispose;
import std.experimental.allocator.mallocator : Mallocator;
void main()
{
const a = theAllocator.makeArray
On Thursday, 5 January 2017 at 11:09:01 UTC, xtreak wrote:
Can someone explain me the actual benefits of using this and if
so any benchmarks explaining the advantage.
Benefits compared to what? Compared to using the GC?
On Thursday, 5 January 2017 at 11:09:01 UTC, xtreak wrote:
I am newbie to D learning it for sometime using Ali's book. I
came across std.experimental.allocator and read through
http://dlang.org/library/std/experimental/allocator/building_blocks.html . Can someone explain me the actual ben
On Thursday, 5 January 2017 at 13:16:44 UTC, Edwin van Leeuwen
wrote:
On Thursday, 5 January 2017 at 11:09:01 UTC, xtreak wrote:
Can someone explain me the actual benefits of using this and
if so any benchmarks explaining the advantage.
Benefits compared to what? Compared to using the GC?
Ye
nient when you are dealing with a task that allocates its own memory
and then finishes without sharing that memory anywhere else.
Or you could use malloc, which is better for minimizing memory use and
amortizes the cost of memory management better than a GC.
If you write your code to use std.expe
On Friday, 6 January 2017 at 03:28:43 UTC, Chris Wright wrote:
There are some other interesting things you can do with this,
though, regarding tracking how you use memory. Or you could use
it to better benchmark malloc vs GC for your application.
I did this just to see what the difference w
On Friday, 6 January 2017 at 23:39:09 UTC, Ryan wrote:
On Friday, 6 January 2017 at 03:28:43 UTC, Chris Wright wrote:
There are some other interesting things you can do with this,
though, regarding tracking how you use memory. Or you could
use it to better benchmark malloc vs GC for your app
On Saturday, 21 January 2017 at 02:47:49 UTC, bitwise wrote:
[...]
I can see that 'TypedAllocator' exists, but with a different
interface than the rest of the allocators. Why wouldn't all
allocators just have a common interface? Why wouldn't Mallocator
take a template parameter allowing usag
On Saturday, 21 January 2017 at 02:47:49 UTC, bitwise wrote:
When std.experimental.allocator was created, I was under the
impression it was meant to be used to make containers. But
since allocate() returns void[], casts are required before
using that memory, which is unsafe.
Is my only
On Saturday, 21 January 2017 at 05:06:07 UTC, Eugene Wissner
wrote:
Alligned allocator isn't present in the
std.experimental.allocator because IAllocator has a method
alignedAllocate()
I hadn't noticed this, but I immediately see two problems:
1) there is no alignedDeallocate(
On Sat, 21 Jan 2017 05:52:49 +, bitwise wrote:
> On Saturday, 21 January 2017 at 05:06:07 UTC, Eugene Wissner wrote:
>> Alligned allocator isn't present in the std.experimental.allocator
>> because IAllocator has a method alignedAllocate()
>
> I hadn't noticed
On Saturday, 21 January 2017 at 05:52:49 UTC, bitwise wrote:
I hadn't noticed this, but I immediately see two problems:
1) there is no alignedDeallocate() which is needed because
aligned allocators usually prepend metadata containing a
pointer to the actual start of the memory to be passed to
On Saturday, 21 January 2017 at 02:47:49 UTC, bitwise wrote:
When std.experimental.allocator was created, I was under the
impression it was meant to be used to make containers. But
since allocate() returns void[], casts are required before
using that memory, which is unsafe.
Is my only
On Saturday, 21 January 2017 at 09:56:29 UTC, ZombineDev wrote:
On Saturday, 21 January 2017 at 02:47:49 UTC, bitwise wrote:
When std.experimental.allocator was created, I was under the
impression it was meant to be used to make containers. But
since allocate() returns void[], casts are
On Sat, 21 Jan 2017 04:01:06 +, bitwise wrote:
> On Saturday, 21 January 2017 at 02:47:49 UTC, bitwise wrote:
>> [...]
>
> I can see that 'TypedAllocator' exists, but with a different interface
> than the rest of the allocators. Why wouldn't all allocators just have a
> common interface?
Typ
On 01/21/2017 01:06 AM, Eugene Wissner wrote:
On Saturday, 21 January 2017 at 05:52:49 UTC, bitwise wrote:
I hadn't noticed this, but I immediately see two problems:
1) there is no alignedDeallocate() which is needed because aligned
allocators usually prepend metadata containing a pointer to th
On Saturday, 21 January 2017 at 10:15:46 UTC, ZombineDev wrote:
On Saturday, 21 January 2017 at 09:56:29 UTC, ZombineDev wrote:
On Saturday, 21 January 2017 at 02:47:49 UTC, bitwise wrote:
When std.experimental.allocator was created, I was under the
impression it was meant to be used to make
On Saturday, 21 January 2017 at 16:28:16 UTC, Andrei Alexandrescu
wrote:
alignedAllocate provides access to OS/clib-provided primitives
for aligned allocation. Those don't require a special
deallocation function, see e.g.
http://en.cppreference.com/w/c/memory/aligned_alloc. -- Andrei
This mak
On 01/21/2017 12:14 PM, bitwise wrote:
On Saturday, 21 January 2017 at 16:28:16 UTC, Andrei Alexandrescu wrote:
alignedAllocate provides access to OS/clib-provided primitives for
aligned allocation. Those don't require a special deallocation
function, see e.g.
http://en.cppreference.com/w/c/memo
On Saturday, 21 January 2017 at 17:26:35 UTC, Andrei Alexandrescu
wrote:
On 01/21/2017 12:14 PM, bitwise wrote:
On Saturday, 21 January 2017 at 16:28:16 UTC, Andrei
Alexandrescu wrote:
alignedAllocate provides access to OS/clib-provided
primitives for
aligned allocation. Those don't require a
On 1/21/17 5:44 PM, bitwise wrote:
About alignedMalloc:
In C++ for example, I may want to use a vector full some SIMD type:
class alignas(16) Vec4 {
union {
struct { float x, y, z, w; };
__m128 m;
};
};
std::vector points = { ... };
In C++ however, 'new' does not respe
On Sat, 21 Jan 2017 22:44:49 +, bitwise wrote:
> So I use a custom aligned allocator:
>
> template
> class AlignedAllocator {
> T* allocate(size_type n) {
> return (T*)_aligned_malloc(ALIGN, n * sizeof(T));
> }
> };
>
> SIMD operations(aligned load and store) can now safel
On Sunday, 22 January 2017 at 00:13:10 UTC, Chris Wright wrote:
On Sat, 21 Jan 2017 22:44:49 +, bitwise wrote:
So I use a custom aligned allocator:
template
class AlignedAllocator {
T* allocate(size_type n) {
return (T*)_aligned_malloc(ALIGN, n * sizeof(T));
}
};
SIMD o
On Sun, 22 Jan 2017 00:53:45 +, bitwise wrote:
> I understand this, but I've given a solid example which supports the
> former, and haven't seen a counter example which supports the latter.
Because examples that are easy to generate are small and small examples
don't have coarse-grained anyth
On Saturday, 21 January 2017 at 23:24:52 UTC, Andrei Alexandrescu
wrote:
On 1/21/17 5:44 PM, bitwise wrote:
About alignedMalloc:
In C++ for example, I may want to use a vector full some SIMD
type:
class alignas(16) Vec4 {
union {
struct { float x, y, z, w; };
__m128 m;
On Sunday, 22 January 2017 at 01:02:09 UTC, Chris Wright wrote:
On Sun, 22 Jan 2017 00:53:45 +, bitwise wrote:
I understand this, but I've given a solid example which
supports the former, and haven't seen a counter example which
supports the latter.
Because examples that are easy to gener
On Saturday, 21 January 2017 at 23:24:52 UTC, Andrei Alexandrescu
wrote:
Andrei
Anyways, design opinions aside, I would be satisfied if an
aligned allocator were included in std.allocators that provided
aligned heap memory using allocate()/deallocate(). The rest is
just details with no pract
On 1/21/17 10:07 PM, bitwise wrote:
On Saturday, 21 January 2017 at 23:24:52 UTC, Andrei Alexandrescu wrote:
Andrei
Anyways, design opinions aside, I would be satisfied if an aligned
allocator were included in std.allocators that provided aligned heap
memory using allocate()/deallocate(). The
On Sunday, 22 January 2017 at 13:21:41 UTC, Andrei Alexandrescu
wrote:
On 1/21/17 10:07 PM, bitwise wrote:
On Saturday, 21 January 2017 at 23:24:52 UTC, Andrei
Alexandrescu wrote:
Andrei
Anyways, design opinions aside, I would be satisfied if an
aligned
allocator were included in std.allocat
On Tuesday, 24 January 2017 at 19:38:31 UTC, bitwise wrote:
I would, but I'm not sure I can use these allocators.
Ran into this:
http://forum.dlang.org/post/akohcwiotlcrodemh...@forum.dlang.org
As stated in that thread, I can mark the member instance of the
allocator in the container as 'shar
On Sunday, 22 January 2017 at 13:21:41 UTC, Andrei Alexandrescu
wrote:
-- Andrei
After exploring this idea(@safe containers), then looking at
std.Array again, it's actually pretty smart. I had concerns about
efficiency, but RefCounted seems to force allocation like
make_shared<>, eliminating
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 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
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
Hi.
I have the following code:
/++
A queue like buffer that's first filled up with insertBack, then
depopulated using removeFront() until it's empty.
+/
struct TransducerBuffer (T, Allocator)
{
private Allocator _allocator;
private T[] _array;
void insertBack(auto ref T newElem) {
/
On Wednesday, 20 April 2016 at 13:43:59 UTC, Vladimir Panteleev
wrote:
Hi,
When I attempt to run the Phobos tests on my machine, I get the
following:
[...]
Should anyone run into this, these disappeared after updating
snn.lib.
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
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.
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
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
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
lease/std_experimental_allocator.html
and
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_building_blocks.html
while using
http://erdani.com/d/phobos-prerelease/std_experimental_allocator_showcase.html
as reference for "highlight" examples.
A few more words on that:
Think of std.experimental.alloc
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 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 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 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 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 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
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/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
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 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 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
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 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 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
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:
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
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
1 - 100 of 176 matches
Mail list logo
