Jardík via Digitalmars-d | 14 Feb 13:10 2016

Allocation failures

When I was interested in D some time ago, I believe GC was 
aborting the application on allocation failures. Is that still 
the case today? I am looking into using D for my new application, 
but I need some guarantees that I can at least save some critical 
data, when such thing happens, perhaps freeing some stuff that is 
not really needed for the saving part (e.g. I could destroy GUI, 
free all saved unmodified documents and after that proceed to 
save unsaved changes to temporary file of some kind (even 
unbuffered as i may not have enough memory for a buffer). This is 
essential for me, that I am able to do it, that there is a change 
to handle such situation. The application will run on a system 
with over-commit disabled, so that (C) malloc can correctly 
report failures. Is it currently possible? Will it be possible in 
a near future?

I could use malloc directly for such data and check its return 
values, but it won't save me when there would be enough memory 
and while after that GC will fail on something else and crash my 

I was also thinking about using rust for it, but for this very 
same reason I can't (rust aborts() almost everywhere on 
allocation failures).

Re: An important pull request: accessing shared affix for immutable data

On 02/13/2016 01:50 PM, Mathias Lang via Digitalmars-d wrote:
> 2016-02-12 20:12 GMT+01:00 Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d <at> puremagic.com <mailto:digitalmars-d <at> puremagic.com>>:
>     https://github.com/D-Programming-Language/phobos/pull/3991
>     The only difference between an approach based on an associative
>     array and AffixAllocator is that the latter is faster (the
>     association is fixed by layout).
> Could you point to your benchmark / paper about this ?

There's no need. I'll do the implementation with the prefix, and if you 
do it with a global hashtable within the same or better speed, my hat is 
off to you.

> The general idea sounds good, however I share deadalnix's concern over
> storing the metadata next to the user's data. I also fail to see how
> those are a "soup of generic considerations", given it only apply when
> using an affix.

It's really easy to throw hypotheticals out and speculate what's going 
to cause slowdown and what's not (and look awfully expert in the 
process). I'm very familiar with the concerns guarding storing metadata 
in jemalloc seeing I've worked in team with Jason Evans for months; most 
are quoted from rote and don't apply here.

But the entire matter of digging down into how efficient the layout is 
would be a massive missing of the point. AffixAllocator is one example, 
(Continue reading)

user001 via Digitalmars-d | 13 Feb 21:39 2016

DMD Issue with Asm Generation?

There seems to be some invalid code generation for std.format for 
type of "real". Relavant links:


movabs rbx,7FF0000000000000                | <-- problem, should 
be 0x7FFF
and rax,rbx                                |
cmp rax,rbx                                |
jne test.7FF6FF4762E4                      |
mov rdx,qword ptr ss:[rbp-230]             |
movabs rcx,FFFFFFFFFFFFF                   |
test rdx,rcx                               |
je test.7FF6FF4762E4                       |
lea rax,qword ptr ds:[7FF6FF4C5C02]        | ;7FF6FF4C5C02:"nan"
mov qword ptr ss:[rbp-2C8],rax             |
mov qword ptr ss:[rbp-2D0],3               |
jmp test.7FF6FF476335                      |
mov rsi,qword ptr ss:[rbp-230]             |
movabs rax,7FFFFFFFFFFFFFFF                |
and rsi,rax                                |
cmp rsi,rbx                                |
jne test.7FF6FF476335                      |
fld tword ptr ss:[rbp-228]                 |
fldz                                       |
fcompi st1                                 |
fstp st0                                   |
ja test.7FF6FF47631B                       |
jp test.7FF6FF47631B                       |
(Continue reading)

[Discussion] Usefulness of Algebraic?

struct Some(T){
     T value;
struct None{}

struct Option(T){
     alias OptionAdt(T) = Algebraic!(Some!T, None);
     OptionAdt!T value; //Should default to none
     //OptionAdt!T value = OptionAdt!T(None());
       Error: memcpy cannot be interpreted at compile time, 
because it has no
       available source code

It is a bit unfortunate that the default value of Option!T.init 
is neither Some!T nor None.

Also Algebraic probably has to be wrapped in a struct because D 
can not infer the type of T for the following code.

alias Option(T) = Algebraic!(Some!T, None);

bool test(T)(auto ref Option!T o){
     return true;

I really love ADT's but I think that they can not be used as a 
default value limits their usefulness.
(Continue reading)

Daniel N via Digitalmars-d | 13 Feb 11:27 2016

C++ UFCS update

This is the proposed wording for a unified call syntax based on 
the idea that f(x,y) can invoke a member function, x.f(y), if 
there are no f(x,y). The inverse transformation, from x.f(y) to 
f(x,y) is not proposed."

They were considering 6 alternatives and chose the worst...

Junfeng via Digitalmars-d | 12 Feb 21:13 2016

learn some d those days, can't understand the code here


Come here for help. what I doing is setup vim and use dcd for 
goto define, but sometimes dcd-server got crash, issue is here: 

Then I build the debug version, and an assert error comes out:


paste here:

     T[] ownArray(T)(T[] from)
         if (allocator is null)
             return from;
         if (from.length == 0)
             return null;
         T[] to = cast(T[]) allocator.allocate(T.sizeof * 
         assert (to.length == from.length, format("from.length = 
%d, to.length = %d", from.length, to.length));
         to[] = from[];
         return to;

For my limited d knowledge, T[] is an array has abi layout:

0: size
size_t: ptr
(Continue reading)

Re: Weird issue with std.range.iota.length

On 02/12/2016 02:10 PM, H. S. Teoh via Digitalmars-d wrote:
> The intestines are still visible in iota(), and anything that uses it in
> 32-bit.

Do we want them everywhere? -- Andrei

An important pull request: accessing shared affix for immutable data


A short while ago Dicebot discussed the notion of using the allocator to 
store the reference count of objects (and generally metadata). The 
allocator seems to be a good place because in a way it's a source of 
"ground truth" - no matter how data is qualified, it originated as 
untyped mutable bytes from the allocator.

So after thinking a bit I managed to convince myself that the affixes in 
an AffixAllocator can be accessed with removing immutable, but without 
actually breaking any guarantee made by the type system. (Affixes are 
extra bytes allocated before and after the actual allocation.) The logic 
goes as follows:

* If the buffer is mutable, then the allocator assumes it hasn't been 
shared across threads, so it returns a reference to a mutable affix.

* If the buffer is const, then the allocator must conservatively assume 
it might have been immutable and subsequently shared among threads. 
Therefore, several threads may request the affix of the same buffer 
simultaneously. So it returns a reference to a shared affix.

* If the buffer is shared, then the allocator assumes again several 
threads may access the affix so it returns a reference to a shared affix.

One simple way to look at this is: the allocator keeps an associative 
array mapping allocated buffers to metadata (e.g. reference counts). The 
allocated buffers may be immutable, which doesn't require the metadata 
to be immutable as well. The only difference between an approach based 
on an associative array and AffixAllocator is that the latter is faster 
(Continue reading)

Re: Weird issue with std.range.iota.length

On 02/12/2016 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
> IMO, fixing a specific type for length is a mistake.  Truly generic code
> should treat the length as an opaque type (possibly satisfying some
> constraints, like <-comparable, ==-comparable, and maybe supporting
> basic arithmetic operations), and should use generic templates like
> CommonType!(...) if it needs to work with multiple length types.

Tried that for a while, it quickly became a mess of entangled 
intestines. Not worth it. -- Andrei

opApply and opApplyReverse

One upon time, we decided that we can replace opNeg, opCom, etc. 
and opAdd, opSubtract, etc. by generic names opUnary and opBinary.

Why don't we have a single iteration operator? Can't we just 
provide the "Reverse" information by some bool argument (or 
string if you like maybe more functionality in the future) like 
the other operators?

I'd suppose to make opApply and opApplyReverse aliases to 
<newOp>!false / <newOp>!"Forward" and <newOp>!true / 
<newOp>!"Reverse" for compatibility.

The workaround I use:
static pure opApp(bool rev)()
   import std.format : format;
   immutable code =
     int opApply%s(scope int delegate(ref Idcs) dg)
       ... (with %s everywhere something Reverse-generic happens)
   return rev ? code.format("Reverse", ...)
              : code.format("",        ...);


(Continue reading)

anonymous via Digitalmars-d | 12 Feb 18:19 2016

[dlang.org] Getting the ddox pages out of limbo

We currently have two differently generated versions of the library 
documentation on dlang.org:

1) dlang.org/phobos/* (and dlang.org/phobos-prerelease/*) is generated 
by dmd's Ddoc functionality. These are the official docs, part of the 
"Documentation" section.

2) dlang.org/library/* (and dlang.org/library-prerelease/*) is generated 
by ddox (<https://github.com/rejectedsoftware/ddox>). Once upon a time, 
these docs were supposed to become official, replacing the other ones. 
Currently, they're in an unfortunate state of beta-forever.

ddox has a number of issues that make it currently not feasible to just 
switch over:

* Macro for "path to base of docs"?

* macros from parent scopes are not known in child scopes

* treating of underscore not consistent with dmd

There may be more.

Now, is the plan still to make the switch to ddox for the official 
documentation? Is anyone actually working towards that goal?

If not, maybe we should get rid of the ddox pages, at least for the time 
(Continue reading)