On 2/11/15 4:55 AM, ANtlord wrote:
> On Monday, 17 February 2014 at 15:49:27 UTC, Andrei Alexandrescu wrote:
>> On 2/17/14, 5:55 AM, Dicebot wrote:
>>> Andrei, what is current state of std.allocator? I am asking this in
>>> context of recent Walter Phobos proposal (ScopeBuffer) to evaluate how
>>> feasible is to define any relations between two at current stage.
>>
>> Progress on std.allocator is slow but I do have a plan. I don't think
>> we should pull ScopeBuffer yet.
>>
>> Andrei
>
> Mr. Alexandrescu. What about std allocator? Is feature valuable? I've
> took a look in Wish List in wiki and Allocator still there.
> If this feature is valuable. What is left in currently implementation of
> your project? Can you tell about state, maybe show To Do list?
>
> Sorry, if my english is not clear. Thank you.

Interface with garbage collector is to be done. The rest is usable right now. -- Andrei

On Wednesday, 11 February 2015 at 15:56:07 UTC, Andrei Alexandrescu wrote:
> On 2/11/15 4:55 AM, ANtlord wrote:
>> On Monday, 17 February 2014 at 15:49:27 UTC, Andrei Alexandrescu wrote:
>>> On 2/17/14, 5:55 AM, Dicebot wrote:
>>>> Andrei, what is current state of std.allocator? I am asking this in
>>>> context of recent Walter Phobos proposal (ScopeBuffer) to evaluate how
>>>> feasible is to define any relations between two at current stage.
>>>
>>> Progress on std.allocator is slow but I do have a plan. I don't think
>>> we should pull ScopeBuffer yet.
>>>
>>> Andrei
>>
>> Mr. Alexandrescu. What about std allocator? Is feature valuable? I've
>> took a look in Wish List in wiki and Allocator still there.
>> If this feature is valuable. What is left in currently implementation of
>> your project? Can you tell about state, maybe show To Do list?
>>
>> Sorry, if my english is not clear. Thank you.
>
> Interface with garbage collector is to be done. The rest is usable right now. -- Andrei

Should it be in std.experimental? Or at least on code.dlang.org?

On Wednesday, 11 February 2015 at 15:57:26 UTC, John Colvin wrote:
> Should it be in std.experimental? Or at least on code.dlang.org?

Yeah, dub package would be really nice!

On Wednesday, 11 February 2015 at 15:56:07 UTC, Andrei Alexandrescu wrote:
> On 2/11/15 4:55 AM, ANtlord wrote:
>> On Monday, 17 February 2014 at 15:49:27 UTC, Andrei Alexandrescu wrote:
>>> On 2/17/14, 5:55 AM, Dicebot wrote:
>>>> Andrei, what is current state of std.allocator? I am asking this in
>>>> context of recent Walter Phobos proposal (ScopeBuffer) to evaluate how
>>>> feasible is to define any relations between two at current stage.
>>>
>>> Progress on std.allocator is slow but I do have a plan. I don't think
>>> we should pull ScopeBuffer yet.
>>>
>>> Andrei
>>
>> Mr. Alexandrescu. What about std allocator? Is feature valuable? I've
>> took a look in Wish List in wiki and Allocator still there.
>> If this feature is valuable. What is left in currently implementation of
>> your project? Can you tell about state, maybe show To Do list?
>>
>> Sorry, if my english is not clear. Thank you.
>
> Interface with garbage collector is to be done. The rest is usable right now. -- Andrei

I thought, that general purpose of allocator it is memory management without garbage collector. Because allocator will be used in containers, and they must work without garbage collector. If no, what is difference between containers and arrays in current implementation of D? I assumed, that containers are need for increased performance within saving safety code. But a using GC will not increase performance.

Or Am I dead wrong?

On Thursday, 12 February 2015 at 08:56:53 UTC, ANtlord wrote:
> On Wednesday, 11 February 2015 at 15:56:07 UTC, Andrei Alexandrescu wrote:
>> On 2/11/15 4:55 AM, ANtlord wrote:
>>> On Monday, 17 February 2014 at 15:49:27 UTC, Andrei Alexandrescu wrote:
>>>> On 2/17/14, 5:55 AM, Dicebot wrote:
>>>>> Andrei, what is current state of std.allocator? I am asking this in
>>>>> context of recent Walter Phobos proposal (ScopeBuffer) to evaluate how
>>>>> feasible is to define any relations between two at current stage.
>>>>
>>>> Progress on std.allocator is slow but I do have a plan. I don't think
>>>> we should pull ScopeBuffer yet.
>>>>
>>>> Andrei
>>>
>>> Mr. Alexandrescu. What about std allocator? Is feature valuable? I've
>>> took a look in Wish List in wiki and Allocator still there.
>>> If this feature is valuable. What is left in currently implementation of
>>> your project? Can you tell about state, maybe show To Do list?
>>>
>>> Sorry, if my english is not clear. Thank you.
>>
>> Interface with garbage collector is to be done. The rest is usable right now. -- Andrei
>
> I thought, that general purpose of allocator it is memory management without garbage collector. Because allocator will be used in containers, and they must work without garbage collector. If no, what is difference between containers and arrays in current implementation of D? I assumed, that containers are need for increased performance within saving safety code. But a using GC will not increase performance.
>
> Or Am I dead wrong?

You still need to cooperate with the GC and let it know which memory should be hands off, for example.

Or just use it for the initial allocation and then ask it politely to release ownership of it.

--
Paulo

On Thursday, 12 February 2015 at 11:10:28 UTC, Paulo  Pinto wrote:
> On Thursday, 12 February 2015 at 08:56:53 UTC, ANtlord wrote:
>> On Wednesday, 11 February 2015 at 15:56:07 UTC, Andrei Alexandrescu wrote:
>>> On 2/11/15 4:55 AM, ANtlord wrote:
>>>> On Monday, 17 February 2014 at 15:49:27 UTC, Andrei Alexandrescu wrote:
>>>>> On 2/17/14, 5:55 AM, Dicebot wrote:
>>>>>> Andrei, what is current state of std.allocator? I am asking this in
>>>>>> context of recent Walter Phobos proposal (ScopeBuffer) to evaluate how
>>>>>> feasible is to define any relations between two at current stage.
>>>>>
>>>>> Progress on std.allocator is slow but I do have a plan. I don't think
>>>>> we should pull ScopeBuffer yet.
>>>>>
>>>>> Andrei
>>>>
>>>> Mr. Alexandrescu. What about std allocator? Is feature valuable? I've
>>>> took a look in Wish List in wiki and Allocator still there.
>>>> If this feature is valuable. What is left in currently implementation of
>>>> your project? Can you tell about state, maybe show To Do list?
>>>>
>>>> Sorry, if my english is not clear. Thank you.
>>>
>>> Interface with garbage collector is to be done. The rest is usable right now. -- Andrei
>>
>> I thought, that general purpose of allocator it is memory management without garbage collector. Because allocator will be used in containers, and they must work without garbage collector. If no, what is difference between containers and arrays in current implementation of D? I assumed, that containers are need for increased performance within saving safety code. But a using GC will not increase performance.
>>
>> Or Am I dead wrong?
>
> You still need to cooperate with the GC and let it know which memory should be hands off, for example.
>
> Or just use it for the initial allocation and then ask it politely to release ownership of it.
>
> --
> Paulo

Aaa, thank you for explanation. I've got it. If the rest is usable right now and interface with GC. Why is not this module in std? Is it in queue for review?

Hi,

Sorry for putting it here but I don't know where to file a bug report for the allocator project.

On 32-bit linux with the latest dmd beta I get errors for ulong -> uint (size_t) conversions.

dmd -main -unittest allocator.d

allocator.d(2015): Error: cannot implicitly convert expression (i * 4096LU) of type ulong to uint
allocator.d(2015): Error: cannot implicitly convert expression ((i + cast(ulong)blocks) * 4096LU) of type ulong to uint
allocator.d(1743): Error: template instance std.allocator.HeapBlock!(4096u, 4u) <cut the long line>
allocator.d(331):        instantiated from here: HeapBlock!(4096u, 4u)
allocator.d(334): Error: template instance Segregator! <cut the long line>
allocator.d(2015): Error: cannot implicitly convert expression (i * 128LU) of type ulong to uint
allocator.d(2015): Error: cannot implicitly convert expression ((i + cast(ulong)blocks) * 128LU) of type ulong to uint
allocator.d(1743): Error: template instance std.allocator.HeapBlock!(128u, 4u) <cut the long line>
 , __ctmp2303).this(m)) error instantiating
allocator.d(1342):        instantiated from here: HeapBlock!(128u, 4u)
allocator.d(1493): Error: cannot implicitly convert expression (x / 64LU) of type ulong to immutable(uint)
allocator.d(1495): Error: cannot implicitly convert expression (y / 64LU) of type ulong to immutable(uint)
allocator.d(1520): Error: cannot implicitly convert expression (x / 64LU) of type ulong to uint
allocator.d(1526): Error: cannot implicitly convert expression (i) of type ulong to uint
allocator.d(1527): Error: cannot implicitly convert expression (i) of type ulong to uint
allocator.d(1544): Error: cannot implicitly convert expression (w) of type ulong to uint
allocator.d(1553): Error: cannot implicitly convert expression (w) of type ulong to uint
allocator.d(1572): Error: cannot implicitly convert expression (w) of type ulong to uint
allocator.d(1582): Error: cannot implicitly convert expression (w) of type ulong to uint
allocator.d(1607): Error: cannot implicitly convert expression (i) of type ulong to uint
allocator.d(1615): Error: cannot implicitly convert expression (i) of type ulong to uint
allocator.d(1627): Error: cannot implicitly convert expression (i) of type ulong to uint
allocator.d(1633): Error: cannot implicitly convert expression (i) of type ulong to uint
allocator.d(4143): Error: function std.allocator.roundUpToMultipleOf (uint s, uint base) is not callable using argument types (ulong, uint)


Is it a known issue? Or are there currently only 64-bit OSes supported by the allocator project?

Piotrek

On Thursday, 26 February 2015 at 21:01:27 UTC, Piotrek wrote:
> Hi,
>
> Sorry for putting it here but I don't know where to file a bug report for the allocator project.
>
> On 32-bit linux with the latest dmd beta I get errors for ulong -> uint (size_t) conversions.
>
> dmd -main -unittest allocator.d
>
> allocator.d(2015): Error: cannot implicitly convert expression (i * 4096LU) of type ulong to uint
> allocator.d(2015): Error: cannot implicitly convert expression ((i + cast(ulong)blocks) * 4096LU) of type ulong to uint
> allocator.d(1743): Error: template instance std.allocator.HeapBlock!(4096u, 4u) <cut the long line>
> allocator.d(331):        instantiated from here: HeapBlock!(4096u, 4u)
> allocator.d(334): Error: template instance Segregator! <cut the long line>
> allocator.d(2015): Error: cannot implicitly convert expression (i * 128LU) of type ulong to uint
> allocator.d(2015): Error: cannot implicitly convert expression ((i + cast(ulong)blocks) * 128LU) of type ulong to uint
> allocator.d(1743): Error: template instance std.allocator.HeapBlock!(128u, 4u) <cut the long line>
>  , __ctmp2303).this(m)) error instantiating
> allocator.d(1342):        instantiated from here: HeapBlock!(128u, 4u)
> allocator.d(1493): Error: cannot implicitly convert expression (x / 64LU) of type ulong to immutable(uint)
> allocator.d(1495): Error: cannot implicitly convert expression (y / 64LU) of type ulong to immutable(uint)
> allocator.d(1520): Error: cannot implicitly convert expression (x / 64LU) of type ulong to uint
> allocator.d(1526): Error: cannot implicitly convert expression (i) of type ulong to uint
> allocator.d(1527): Error: cannot implicitly convert expression (i) of type ulong to uint
> allocator.d(1544): Error: cannot implicitly convert expression (w) of type ulong to uint
> allocator.d(1553): Error: cannot implicitly convert expression (w) of type ulong to uint
> allocator.d(1572): Error: cannot implicitly convert expression (w) of type ulong to uint
> allocator.d(1582): Error: cannot implicitly convert expression (w) of type ulong to uint
> allocator.d(1607): Error: cannot implicitly convert expression (i) of type ulong to uint
> allocator.d(1615): Error: cannot implicitly convert expression (i) of type ulong to uint
> allocator.d(1627): Error: cannot implicitly convert expression (i) of type ulong to uint
> allocator.d(1633): Error: cannot implicitly convert expression (i) of type ulong to uint
> allocator.d(4143): Error: function std.allocator.roundUpToMultipleOf (uint s, uint base) is not callable using argument types (ulong, uint)
>
>
> Is it a known issue? Or are there currently only 64-bit OSes supported by the allocator project?
>
> Piotrek

I think, that if use this project https://github.com/andralex/std_allocator/, than you can post the issue to related issue tracker. And I see, that types in traceback are different from source https://github.com/andralex/std_allocator/blob/master/source/std/allocator.d#L857. Maybe you need to upgrade package.

Sorry, if my english isn't clear.

On Friday, 27 February 2015 at 08:18:53 UTC, ANtlord wrote:
> I think, that if use this project https://github.com/andralex/std_allocator/, than you can post the issue to related issue tracker.

Oh, I must be blind. I thought the issue tracker was disables on the repository in the same way as for Phobos. Thanks for checking. I submitted the issue.

> And I see, that types in traceback are different from source https://github.com/andralex/std_allocator/blob/master/source/std/allocator.d#L857. Maybe you need to upgrade package.

If you mean size_t and uint difference it's because size_t is an alias for uint on 32-bit os.

 roundUpToMultipleOf(size_t s, uint base)
becomes
 roundUpToMultipleOf (uint s, uint base)

Piotrek

On Friday, 1 November 2013 at 02:33:57 UTC, Andrei Alexandrescu wrote:
> Added SharedFreelist, a lock-free freelist.
>
> http://erdani.com/d/phobos-prerelease/std_allocator.html#.SharedFreelist
>
>
> Andrei

Hi Andrei,

Please check this bug fix for SharedFreelist https://github.com/andralex/phobos/pull/21 .

I have found that source code for bounded `maxNodes` version of SharedFreelist is commented out. I understand that `maxNodes` can be only approximate bound for _shared_ free list. However, approximate `maxNodes` bound is very useful too. Can I create PR for this feature?

Best Regards, --Ilya