Re: It makes me sick!

[Ali Çehreli via Digitalmars-d-learn]

On 07/26/2017 09:20 PM, FoxyBrown wrote:

>> Somebody else had the same problem which they solved by removing
>> "entire dmd":
>>
>>   http://forum.dlang.org/thread/ejybuwermnentslcy...@forum.dlang.org
>>
>> Ali
>
> Thanks, that was it. So I guess I have to delete the original dmd2 dir
> before I install each time... didn't use to have to do that.

Normally, it shouldn't be necessary. The splitting of the datetime 
package[1] had this effect but I'm not sure why the installation process 
can't take care of it.


Ali

[1] http://dlang.org/changelog/2.075.0.html#split-std-datetime

Re: It makes me sick!

[FoxyBrown via Digitalmars-d-learn]

On Thursday, 27 July 2017 at 03:41:06 UTC, Ali Çehreli wrote:

On 07/26/2017 08:34 PM, FoxyBrown wrote:
Knowing that every time I upgrade to the latest "official" D 
compiler I

run in to trouble:



Win32\Debug DMD\test.obj(test)
 Error 42: Symbol Undefined 
_D3std8datetime7SysTime8toStringMxFNbNfZAya

(const(nothrow @safe immutable(char)[] function())
std.datetime.SysTime.toString)
Win32\Debug DMD\test.obj(test)


Somebody else had the same problem which they solved by 
removing "entire dmd":


  
http://forum.dlang.org/thread/ejybuwermnentslcy...@forum.dlang.org


Ali


Thanks, that was it. So I guess I have to delete the original 
dmd2 dir before I install each time... didn't use to have to do 
that.

Re: It makes me sick!

[Ali Çehreli via Digitalmars-d-learn]

On 07/26/2017 08:34 PM, FoxyBrown wrote:

Knowing that every time I upgrade to the latest "official" D compiler I
run in to trouble:



Win32\Debug DMD\test.obj(test)
 Error 42: Symbol Undefined _D3std8datetime7SysTime8toStringMxFNbNfZAya
(const(nothrow @safe immutable(char)[] function())
std.datetime.SysTime.toString)
Win32\Debug DMD\test.obj(test)


Somebody else had the same problem which they solved by removing "entire 
dmd":


  http://forum.dlang.org/thread/ejybuwermnentslcy...@forum.dlang.org

Ali

Re: It makes me sick!

[FoxyBrown via Digitalmars-d-learn]

And yes, I'm using the correct phobos(the one that came with 
dmd2).

It makes me sick!

[FoxyBrown via Digitalmars-d-learn]

Knowing that every time I upgrade to the latest "official" D 
compiler I run in to trouble:




Win32\Debug DMD\test.obj(test)
 Error 42: Symbol Undefined 
_D3std8datetime7SysTime8toStringMxFNbNfZAya (const(nothrow @safe 
immutable(char)[] function()) std.datetime.SysTime.toString)

Win32\Debug DMD\test.obj(test)
 Error 42: Symbol Undefined 
_D3std8datetime7SysTime6toHashMxFNaNbNiNfZk (const(pure nothrow 
@nogc @safe uint function()) std.datetime.SysTime.toHash)

Win32\Debug DMD\test.obj(test)
 Error 42: Symbol Undefined 
_D3std8datetime7SysTime8opEqualsMxFNaNbNfKxS3std8datetime7SysTimeZb (const(pure nothrow @safe bool function(ref const(std.datetime.SysTime))) std.datetime.SysTime.opEquals)

Win32\Debug DMD\test.obj(test)
 Error 42: Symbol Undefined 
_D3std8datetime7SysTime8__xopCmpFKxS3std8datetime7SysTimeKxS3std8datetime7SysTimeZi (int std.datetime.SysTime.__xopCmp(ref const(std.datetime.SysTime), ref const(std.datetime.SysTime)))

Win32\Debug DMD\test.obj(test)
 Error 42: Symbol Undefined _D3gtk3All12__ModuleInfoZ 
(gtk.All.__ModuleInfo)

\GtkD\x86\gtkd.lib(AboutDialog)
 Error 42: Symbol Undefined 
_D3std6format64__T14formatIntegralTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatIntegralFNaNbNfS3std5array17__T8AppenderTAyaZ8AppenderxmKxS3std6format18__T10FormatSpecTaZ10FormatSpeckmZv (pure nothrow @safe void std.format.formatIntegral!(std.array.Appender!(immutable(char)[]).Appender, ulong, char).formatIntegral(std.array.Appender!(immutable(char)[]).Appender, const(ulong), ref const(std.format.FormatSpec!(char).FormatSpec), uint, ulong))

\GtkD\x86\gtkd.lib(AboutDialog)
 Error 42: Symbol Undefined _D3std5stdio6stderrS3std5stdio4File 
(std.stdio.File std.stdio.stderr)

\GtkD\x86\gtkd.lib(Implement)
 Error 42: Symbol Undefined 
_D3std6format64__T14formatUnsignedTS3std5array17__T8AppenderTAyaZ8AppenderTmTaZ14formatUnsignedFNaNbNfS3std5array17__T8AppenderTAyaZ8AppendermKxS3std6format18__T10FormatSpecTaZ10FormatSpeckbZv (pure nothrow @safe void std.format.formatUnsigned!(std.array.Appender!(immutable(char)[]).Appender, ulong, char).formatUnsigned(std.array.Appender!(immutable(char)[]).Appender, ulong, ref const(std.format.FormatSpec!(char).FormatSpec), uint, bool))

Error: linker exited with status 8
Building Win32\Debug DMD\test.exe failed!


I recompiled gtkD with the new compiler, same result.  My code 
was working before the upgrade just fine and I did not change 
anything.

Re: Silent error when using hashmap

[FoxyBrown via Digitalmars-d]

On Thursday, 27 July 2017 at 02:30:17 UTC, FatalCatharsis wrote:
On Thursday, 27 July 2017 at 01:21:40 UTC, Steven Schveighoffer 
wrote:

[...]


This appears to be it. When an error is thrown, stdout does not 
flush. When I put stdout.flush() immediately after the 
writeln("start") at the beginning it is printed correctly. 
However, when I try to catch the error and then do 
stdout.flush() in main, it does not print.


Do you know of a way to make D always flush the output buffer 
when an error is thrown?


On Thursday, 27 July 2017 at 01:05:28 UTC, ketmar wrote:

[...]


Yes, I understand this. This is not my question. My question is 
why all previous output to the console does not occur before 
the error is thrown. As Steve said, this is because the output 
buffer is not flushed when an error occurs.


I just noticed this without an exception. I changed my writeln's 
to write and printed a "\n" but it did not flush. Had to flush it 
manually. Not sure if that is by design or what.

DDox and filters.

[Danni Coy via Digitalmars-d-learn]

I am trying to build my projects documentation via the ddox system via dub.
It seems that my modules are being documented and then filtered out.

Ironically for a documentation system there isn't a lot of documentation.
What is the minimum I need in order for documentation to show up?
how do I control the filter options.

Re: Silent error when using hashmap

[FatalCatharsis via Digitalmars-d]

On Thursday, 27 July 2017 at 01:21:40 UTC, Steven Schveighoffer 
wrote:
the writeln("start"); and writeln("end"); in main. This is 
what I meant by printing. These do not appear in the output. 
The programs starts and immediately ends without printing 
"start" and "end".


try flushing the output. In some cases the output streams do 
not flush on newlines.


I did not put an output in the exception handler of the 
WndProc because writeln can throw and the function is marked 
nothrow. All I as trying to do there was get it to recover.


Just surround writeln with try/catch(Exception), should work.

You could also just use good old printf.

-Steve


This appears to be it. When an error is thrown, stdout does not 
flush. When I put stdout.flush() immediately after the 
writeln("start") at the beginning it is printed correctly. 
However, when I try to catch the error and then do stdout.flush() 
in main, it does not print.


Do you know of a way to make D always flush the output buffer 
when an error is thrown?


On Thursday, 27 July 2017 at 01:05:28 UTC, ketmar wrote:
'cause, as i said, RangeError is not an exception. i thought 
that you already know it, as this is "general", not "learning" 
NG.


Yes, I understand this. This is not my question. My question is 
why all previous output to the console does not occur before the 
error is thrown. As Steve said, this is because the output buffer 
is not flushed when an error occurs.

Re: Silent error when using hashmap

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 8:51 PM, FatalCatharsis wrote:

On Thursday, 27 July 2017 at 00:48:48 UTC, ketmar wrote:

FatalCatharsis wrote:


On Thursday, 27 July 2017 at 00:34:28 UTC, ketmar wrote:
wrap the whole event handler function in `try/catch` block, and 
print it there. after all, this is what Dmain does, and so can you. 
having *full* stack trace has no sense there anyway, as you know for 
sure that event handler is called by windows, not by you (and 
usually from your event loop anyway, so detailed stack trace has 
little useful info).


I tried that like so:

https://gist.github.com/FatalCatharsis/39c5f35ae78ecd5399eebe0fb2491004

I put exception blocks both around main and around the invocation of 
the hash lookup and still get no printouts anywhere, including at the 
beginning and end of main.


'cause you never printed anything.


the writeln("start"); and writeln("end"); in main. This is what I meant 
by printing. These do not appear in the output. The programs starts and 
immediately ends without printing "start" and "end".


try flushing the output. In some cases the output streams do not flush 
on newlines.


I did not put an 
output in the exception handler of the WndProc because writeln can throw 
and the function is marked nothrow. All I as trying to do there was get 
it to recover.


Just surround writeln with try/catch(Exception), should work.

You could also just use good old printf.

-Steve

Re: Destructors vs. Finalizers

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 8:20 PM, Moritz Maxeiner wrote:

On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer wrote:

On 7/26/17 7:28 PM, Moritz Maxeiner wrote:

On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote:

On 7/26/17 2:33 PM, Moritz Maxeiner wrote:


A finalizer may freely work on non-pointer members and pointer 
members that target objects outside the GC pool which the programmer 
knows to be valid at finalization (e.g. they are manually managed).
Whether or not it makes sense for the finalizer to call the 
destructor is something the programmer has to decide on a per use 
case basis.


No, because a destructor can safely assume it can look at GC members' 
data. So a finalizer can never call it.


No, whether a finalizer can safely call a destructor depends on the 
destructor's body.
If the destructor doesn't access GC members and doesn't allocate using 
the GC, the finalizer can safely call it. That's why it's the 
programmer's job to determine this on a use case basis.




I suppose this is true, but in practice, you wouldn't in a destructor 
that which is available for a finalizer. In other words, you simply 
wouldn't implement such a destructor.


It's also very fragile as the maintainer of the destructor is working 
under different assumptions from the finalizer. If you call the 
destructor from the finalizer, then the rules of the finalizer infect 
the destructor.


-Steve

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 8:09 PM, Timon Gehr wrote:

On 27.07.2017 01:56, Andrei Alexandrescu wrote:

On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations 
exist that intentionally cause UB when stream is NULL (as in Timon's 
example).


My argument was not that we need to fear implementations that take 
explicit measures to screw you, but UB is UB. Compilers can in principle 
turn segfaults into any other behaviour they want, and this behaviour 
can change between releases. I'd just rather not codify guarantees that 
do not exist into the type system, as it is not really feasible to check 
them, even if in practice you will in the overwhelming majority get the 
expected behaviour.


I can't see how compilers can take advantage of this one. However, we 
can take advantage that this UB is almost universally implemented as a 
hardware segfault that ends the process.


-Steve

Re: Silent error when using hashmap

[ketmar via Digitalmars-d]

FatalCatharsis wrote:


On Thursday, 27 July 2017 at 00:48:48 UTC, ketmar wrote:

FatalCatharsis wrote:


On Thursday, 27 July 2017 at 00:34:28 UTC, ketmar wrote:
wrap the whole event handler function in `try/catch` block, and print 
it there. after all, this is what Dmain does, and so can you. having 
*full* stack trace has no sense there anyway, as you know for sure 
that event handler is called by windows, not by you (and usually from 
your event loop anyway, so detailed stack trace has little useful 
info).


I tried that like so:

https://gist.github.com/FatalCatharsis/39c5f35ae78ecd5399eebe0fb2491004

I put exception blocks both around main and around the invocation of 
the hash lookup and still get no printouts anywhere, including at the 
beginning and end of main.


'cause you never printed anything.


the writeln("start"); and writeln("end"); in main. This is what I meant 
by printing. These do not appear in the output. The programs starts and 
immediately ends without printing "start" and "end". I did not put an 
output in the exception handler of the WndProc because writeln can throw 
and the function is marked nothrow. All I as trying to do there was get 
it to recover.


'cause, as i said, RangeError is not an exception. i thought that you 
already know it, as this is "general", not "learning" NG.

Re: I feel the dynamic array .sizeof property is kind of a bait and switch

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 16:27:57 UTC, WhatMeWorry wrote:

On Wednesday, 26 July 2017 at 02:31:33 UTC, Mike Parker wrote:

With static arrays, the memory for the elements if part of the 
array itself, so it is counted in the size. For dynamic 
arrays, it is not. For .sizeof to report the size of the 
allocated memory would be incorrect.


OK, Then I assume the critical thing is that dynamic arrays 
memory is

not part of the array itself.  But is this a deal breaker?


A deal breaker for what? For making sizeof return the amount of 
memory allocated? Yes. It's the same behavior in C and C++:


float verts[3];
assert(sizeof(verts) == (sizeof(float) * 3));

float *verts = malloc(sizeof(float)*3);
assert(sizeof(verts) == sizeof(void*));

Re: Silent error when using hashmap

[FatalCatharsis via Digitalmars-d]

On Thursday, 27 July 2017 at 00:48:48 UTC, ketmar wrote:

FatalCatharsis wrote:


On Thursday, 27 July 2017 at 00:34:28 UTC, ketmar wrote:
wrap the whole event handler function in `try/catch` block, 
and print it there. after all, this is what Dmain does, and 
so can you. having *full* stack trace has no sense there 
anyway, as you know for sure that event handler is called by 
windows, not by you (and usually from your event loop anyway, 
so detailed stack trace has little useful info).


I tried that like so:

https://gist.github.com/FatalCatharsis/39c5f35ae78ecd5399eebe0fb2491004

I put exception blocks both around main and around the 
invocation of the hash lookup and still get no printouts 
anywhere, including at the beginning and end of main.


'cause you never printed anything.


the writeln("start"); and writeln("end"); in main. This is what I 
meant by printing. These do not appear in the output. The 
programs starts and immediately ends without printing "start" and 
"end". I did not put an output in the exception handler of the 
WndProc because writeln can throw and the function is marked 
nothrow. All I as trying to do there was get it to recover.

Re: Silent error when using hashmap

[ketmar via Digitalmars-d]

FatalCatharsis wrote:


On Thursday, 27 July 2017 at 00:34:28 UTC, ketmar wrote:
wrap the whole event handler function in `try/catch` block, and print it 
there. after all, this is what Dmain does, and so can you. having *full* 
stack trace has no sense there anyway, as you know for sure that event 
handler is called by windows, not by you (and usually from your event 
loop anyway, so detailed stack trace has little useful info).


I tried that like so:

https://gist.github.com/FatalCatharsis/39c5f35ae78ecd5399eebe0fb2491004

I put exception blocks both around main and around the invocation of the 
hash lookup and still get no printouts anywhere, including at the 
beginning and end of main.


besides, RangeError is not Exception.

Re: Silent error when using hashmap

[ketmar via Digitalmars-d]

FatalCatharsis wrote:


On Thursday, 27 July 2017 at 00:34:28 UTC, ketmar wrote:
wrap the whole event handler function in `try/catch` block, and print it 
there. after all, this is what Dmain does, and so can you. having *full* 
stack trace has no sense there anyway, as you know for sure that event 
handler is called by windows, not by you (and usually from your event 
loop anyway, so detailed stack trace has little useful info).


I tried that like so:

https://gist.github.com/FatalCatharsis/39c5f35ae78ecd5399eebe0fb2491004

I put exception blocks both around main and around the invocation of the 
hash lookup and still get no printouts anywhere, including at the 
beginning and end of main.


'cause you never printed anything.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[MysticZach via Digitalmars-d]

On Tuesday, 25 July 2017 at 07:48:39 UTC, Andrea Fontana wrote:
I don't like it so much but also something like this could be 
considered:


out!(x => x>0)
or maybe:
out!x(x > 0)

that can't collide with current syntax

Andrea


It's another viable option, but it doesn't seem to stand out much 
from the crowd. Most people, including me, seem to think `out(x; 
x > 0)` and `out(; y > 0)` are the "least imperfect" option. I 
suspect they would win if put to a vote. Maybe the leadership can 
come up with something better. People will get used to whatever 
is selected. I just like the foreach version because it's simple 
and concise. I also don't think the ambiguous `out(x > 0)` syntax 
is that bad for non-return variables. But I can also see why 
that's suboptimal from a design point of view.

Re: Silent error when using hashmap

[FatalCatharsis via Digitalmars-d]

On Thursday, 27 July 2017 at 00:34:28 UTC, ketmar wrote:
wrap the whole event handler function in `try/catch` block, and 
print it there. after all, this is what Dmain does, and so can 
you. having *full* stack trace has no sense there anyway, as 
you know for sure that event handler is called by windows, not 
by you (and usually from your event loop anyway, so detailed 
stack trace has little useful info).


I tried that like so:

https://gist.github.com/FatalCatharsis/39c5f35ae78ecd5399eebe0fb2491004

I put exception blocks both around main and around the invocation 
of the hash lookup and still get no printouts anywhere, including 
at the beginning and end of main.

Re: Silent error when using hashmap

[ketmar via Digitalmars-d]

FatalCatharsis wrote:


On Thursday, 27 July 2017 at 00:12:20 UTC, ketmar wrote:
'cause windows' event handler called from darkes depths of windows code, 
and D just can't make sense of the stack to unwind it properly and to 
show you error message and stack trace. never ever rely on getting 
proper stack traces for exceptions thrown in windows callbacks: it *may* 
work sometimes, but it is not guaranteed.


Is there a way to get it to not fail so hard so that prints that occur 
before and after the failure aren't lost? The "begin" and "end" in the 
main don't even get output when the failure happens.


wrap the whole event handler function in `try/catch` block, and print it 
there. after all, this is what Dmain does, and so can you. having *full* 
stack trace has no sense there anyway, as you know for sure that event 
handler is called by windows, not by you (and usually from your event loop 
anyway, so detailed stack trace has little useful info).

Re: Silent error when using hashmap

[FatalCatharsis via Digitalmars-d]

On Thursday, 27 July 2017 at 00:12:20 UTC, ketmar wrote:
'cause windows' event handler called from darkes depths of 
windows code, and D just can't make sense of the stack to 
unwind it properly and to show you error message and stack 
trace. never ever rely on getting proper stack traces for 
exceptions thrown in windows callbacks: it *may* work 
sometimes, but it is not guaranteed.


Is there a way to get it to not fail so hard so that prints that 
occur before and after the failure aren't lost? The "begin" and 
"end" in the main don't even get output when the failure happens.

Re: Destructors vs. Finalizers

[Moritz Maxeiner via Digitalmars-d]

On Thursday, 27 July 2017 at 00:00:08 UTC, Steven Schveighoffer 
wrote:

On 7/26/17 7:28 PM, Moritz Maxeiner wrote:
On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven 
Schveighoffer wrote:

On 7/26/17 2:33 PM, Moritz Maxeiner wrote:


A finalizer may freely work on non-pointer members and pointer 
members that target objects outside the GC pool which the 
programmer knows to be valid at finalization (e.g. they are 
manually managed).
Whether or not it makes sense for the finalizer to call the 
destructor is something the programmer has to decide on a per 
use case basis.


No, because a destructor can safely assume it can look at GC 
members' data. So a finalizer can never call it.


No, whether a finalizer can safely call a destructor depends on 
the destructor's body.
If the destructor doesn't access GC members and doesn't allocate 
using the GC, the finalizer can safely call it. That's why it's 
the programmer's job to determine this on a use case basis.






The destructor is ensured that the entire structure is 
intact, so it can do whatever it wants.


The point is that I saw (and see) no reason for a destructor 
to ever call a finalizer.


An example:

class File
{
   int fd;
   ubyte[] buffer;

   // avoiding bikeshed issues by using clear names
   destructor() { finalizer(); delete buffer; }
   finalizer() { close(fd); }
}

No reason to repeat the finalizer code in the destructor.


I concede the point.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 2 Begins

[MysticZach via Digitalmars-d]

On Wednesday, 26 July 2017 at 08:12:39 UTC, Olivier FAURE wrote:
I... think you misunderstood me? I shouldn't have used the word 
'proposals', I should have said 'suggestions'.


What I meant was "I think it would be better for the current 
version of DIP 1009 to include a 'Rejected alternative 
syntaxes' that would include a summary of the previously 
discussed suggestions for improving contract readability."


MysticZach argues that such a section would be pointless since 
the language authors read the previous version of DIP 1009, but 
I still think adding it would be a good idea (for posterity and 
to streamline discussions in this thread).


I don't know. DIPs have both a forward-looking and a 
backward-looking aspect. The forward is to convince the language 
authors of the need/value of a specific language change. The 
backward is to record a history of discussions so that people can 
learn why things are the way they are. They are both valuable in 
their own way, but I think the forward-looking aspect is more 
valuable. I'd like some guidance from the leadership as to the 
important of the backward-looking aspect of DIPs. For example, 
DIP1003 was actually rewritten to excise the alternatives and 
keep only the one adopted. The motive given was that people 
looking for the history could examine prior versions of the DIP. 
I guess the motive is that too much history can end up cluttering 
the important information.


That said, I think that making good decisions for the language 
far outweighs any concerns about DIPs themselves. So we should 
really be focusing on that.

Re: Silent error when using hashmap

[ketmar via Digitalmars-d]

FatalCatharsis wrote:


On Wednesday, 26 July 2017 at 16:39:15 UTC, ketmar wrote:>
'cause `WM_CREATE` is not the first message window receiving. check if 
hwnd is in hash with `in` first.


I figured this was the case. WM_NCCREATE is probably sent first and the 
lookup fails. I'm more concerned with why there was no exceptions/debug 
output of any kind.


'cause windows' event handler called from darkes depths of windows code, 
and D just can't make sense of the stack to unwind it properly and to show 
you error message and stack trace. never ever rely on getting proper stack 
traces for exceptions thrown in windows callbacks: it *may* work sometimes, 
but it is not guaranteed.

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 7:56 PM, Andrei Alexandrescu wrote:

On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations 
exist that intentionally cause UB when stream is NULL (as in Timon's 
example). Either they check for null, and handle gracefully, or don't 
check and segfault.


No need to worry about that at all. If worse comes to worst - i.e. we do 
port to such an implementation - we can always provide a thin wrapper 
that checks for NULL then calls the native function. No need to change 
the signatures. -- Andrei


Hm.. so you mean:

pragma(mangle, "fgetc")
private extern(C) int real_fgetc(FILE * stream)

extern(D) int fgetc(FILE *stream) @trusted
{
  if(stream == null) assert(0);
  return real_fgetc(stream);
}

Yeah, that should work well actually. Nice!

-Steve

Re: all OS functions should be "nothrow @trusted @nogc"

[Timon Gehr via Digitalmars-d]

On 27.07.2017 01:56, Andrei Alexandrescu wrote:

On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations 
exist that intentionally cause UB when stream is NULL (as in Timon's 
example).


My argument was not that we need to fear implementations that take 
explicit measures to screw you, but UB is UB. Compilers can in principle 
turn segfaults into any other behaviour they want, and this behaviour 
can change between releases. I'd just rather not codify guarantees that 
do not exist into the type system, as it is not really feasible to check 
them, even if in practice you will in the overwhelming majority get the 
expected behaviour.


Either they check for null, and handle gracefully, or don't 

check and segfault.


No need to worry about that at all. If worse comes to worst - i.e. we do 
port to such an implementation


How do you notice?

- we can always provide a thin wrapper 
that checks for NULL then calls the native function. No need to change 
the signatures. -- Andrei


I don't see how that works, as you'd end up with two different 
implementations of the same C function. (I.e. you get a name clash in 
the object file.)

Re: Silent error when using hashmap

[FatalCatharsis via Digitalmars-d]

On Wednesday, 26 July 2017 at 16:39:15 UTC, ketmar wrote:>
'cause `WM_CREATE` is not the first message window receiving. 
check if hwnd is in hash with `in` first.


I figured this was the case. WM_NCCREATE is probably sent first 
and the lookup fails. I'm more concerned with why there was no 
exceptions/debug output of any kind.


On Wednesday, 26 July 2017 at 22:08:45 UTC, Steven Schveighoffer 
wrote:
Note that in D when a thread crashes besides the main thread, 
you may not get a stack trace printout. You may get nothing.


-Steve


This example doesn't create any threads explicitly. Are there 
other threads that dlang generates? How do I obtain debug output 
and proper exception handling from these threads?

Re: Destructors vs. Finalizers

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 7:28 PM, Moritz Maxeiner wrote:

On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer wrote:

On 7/26/17 2:33 PM, Moritz Maxeiner wrote:

On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in use 
anymore. The order in which this is currently happening is not 
specified. So, how are the destructors supposed to be called in the 
right order? Manually? ARC?


After the split:
Destructors are only for deterministic end of object lifetime, so 
yes, they are to be called by any scheme (such as manual management 
via destroy and reference counting - which is likely also implemented 
as calling destroy) that is deterministic.

Finalizers are for nondeterministic schemes such as the GC.
The GC *never* calls destructors directly, only finalizers.
A finalizer might manually call a destructor, but a destructor may 
never call a finalizer.


Actually, it's the opposite.


It's a matter of definition and this is the behaviour I would define, 
because


A finalizer can never call anything on its members because it doesn't 
know if it's being destroyed by the GC.


This falsely assumes that all members point into the GC pool.


Yes, I should have qualified GC members.

A 
finalizer may freely work on non-pointer members and pointer members 
that target objects outside the GC pool which the programmer knows to be 
valid at finalization (e.g. they are manually managed).
Whether or not it makes sense for the finalizer to call the destructor 
is something the programmer has to decide on a per use case basis.


No, because a destructor can safely assume it can look at GC members' 
data. So a finalizer can never call it.




The destructor is ensured that the entire structure is intact, so it 
can do whatever it wants.


The point is that I saw (and see) no reason for a destructor to ever 
call a finalizer.


An example:

class File
{
   int fd;
   ubyte[] buffer;

   // avoiding bikeshed issues by using clear names
   destructor() { finalizer(); delete buffer; }
   finalizer() { close(fd); }
}

No reason to repeat the finalizer code in the destructor.

-Steve

Re: all OS functions should be "nothrow @trusted @nogc"

[Andrei Alexandrescu via Digitalmars-d]

On 07/26/2017 06:16 PM, Steven Schveighoffer wrote:
So I guess I should restate that we can assume no implementations exist 
that intentionally cause UB when stream is NULL (as in Timon's example). 
Either they check for null, and handle gracefully, or don't check and 
segfault.


No need to worry about that at all. If worse comes to worst - i.e. we do 
port to such an implementation - we can always provide a thin wrapper 
that checks for NULL then calls the native function. No need to change 
the signatures. -- Andrei

Re: Destructors vs. Finalizers

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 26 July 2017 at 23:28:38 UTC, Moritz Maxeiner wrote:


This falsely assumes that all members point into the GC pool. A 
finalizer may freely work on non-pointer members and pointer 
members that target objects outside the GC pool which the 
programmer knows to be valid at finalization (e.g. they are 
manually managed).


* freely with the exception of not allocating using the GC, of 
course.

Re: Destructors vs. Finalizers

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 26 July 2017 at 22:33:23 UTC, Steven Schveighoffer 
wrote:

On 7/26/17 2:33 PM, Moritz Maxeiner wrote:

On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in 
use anymore. The order in which this is currently happening 
is not specified. So, how are the destructors supposed to be 
called in the right order? Manually? ARC?


After the split:
Destructors are only for deterministic end of object lifetime, 
so yes, they are to be called by any scheme (such as manual 
management via destroy and reference counting - which is 
likely also implemented as calling destroy) that is 
deterministic.

Finalizers are for nondeterministic schemes such as the GC.
The GC *never* calls destructors directly, only finalizers.
A finalizer might manually call a destructor, but a destructor 
may never call a finalizer.


Actually, it's the opposite.


It's a matter of definition and this is the behaviour I would 
define, because


A finalizer can never call anything on its members because it 
doesn't know if it's being destroyed by the GC.


This falsely assumes that all members point into the GC pool. A 
finalizer may freely work on non-pointer members and pointer 
members that target objects outside the GC pool which the 
programmer knows to be valid at finalization (e.g. they are 
manually managed).
Whether or not it makes sense for the finalizer to call the 
destructor is something the programmer has to decide on a per use 
case basis.




The destructor is ensured that the entire structure is intact, 
so it can do whatever it wants.


The point is that I saw (and see) no reason for a destructor to 
ever call a finalizer.

[Issue 17697] Ddoc: get rid of `_` detection in URLs

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17697

Adam D. Ruppe  changed:

   What|Removed |Added

 CC||destructiona...@gmail.com

--- Comment #1 from Adam D. Ruppe  ---
The correct solution is to get rid of the utterly counterproductive identifier
highlighting entirely, then remove the useless _ suppression entirely.

--

[Issue 17697] Ddoc: get rid of `_` detection in URLs

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17697

Walter Bright  changed:

   What|Removed |Added

   Keywords||ddoc

--

[Issue 17697] New: Ddoc: get rid of `_` detection in URLs

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17697

  Issue ID: 17697
   Summary: Ddoc: get rid of `_` detection in URLs
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

For example,

  /* http://website.com/_abc */

  module abc;

The _ is needed to prevent Ddoc from highlighting the abc. But this makes the
URL unusable from a text editor.

The solution is to get rid of _ detection inside of URLs.

--

Re: Destructors vs. Finalizers

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 2:33 PM, Moritz Maxeiner wrote:

On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in use 
anymore. The order in which this is currently happening is not 
specified. So, how are the destructors supposed to be called in the 
right order? Manually? ARC?


After the split:
Destructors are only for deterministic end of object lifetime, so yes, 
they are to be called by any scheme (such as manual management via 
destroy and reference counting - which is likely also implemented as 
calling destroy) that is deterministic.

Finalizers are for nondeterministic schemes such as the GC.
The GC *never* calls destructors directly, only finalizers.
A finalizer might manually call a destructor, but a destructor may never 
call a finalizer.


Actually, it's the opposite. A finalizer can never call anything on its 
members because it doesn't know if it's being destroyed by the GC.


The destructor is ensured that the entire structure is intact, so it can 
do whatever it wants.


-Steve

Re: Why can't typeof() be used in member method?

[Temtaime via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 19:06:24 UTC, Andre Pany wrote:

On Wednesday, 26 July 2017 at 17:04:59 UTC, Adam D. Ruppe wrote:

On Wednesday, 26 July 2017 at 16:50:35 UTC, Andre Pany wrote:

[...]


FYI, you shouldn't use .stringof here. Just use `T` instead of 
`T.stringof`.


[...]


Thank you so much!

Kind regards
André


There's another method for such a check.

mixin(`static if (!is(typeof(T.`~p.name~`

Re: Destructors vs. Finalizers

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 12:01 PM, Guillaume Piolat wrote:

On Wednesday, 26 July 2017 at 15:15:03 UTC, Steven Schveighoffer wrote:

On 7/26/17 10:57 AM, Guillaume Piolat wrote:

I'll defend the view point that there is _nothing_ useful to do in a 
finalizer except to check if the destructor has already been called.


The thing to do in a finalizer that is useful is to release any non-GC 
resources.


Interesting case.

Do we assume the finalizer is always called after the destructor?


Yes, finalizer and destructor should be called on deterministic 
destruction (no need to repeat the finalizer code in the destructor).


- If yes, then releasing these non-GC resources could have been possible 
in the destructor too. The only lost generality would be if releasing 
such non-GC resources would be faster from the GC thread (could well be 
since pooled).


But the destructor can't be called from the GC. In cases where the GC is 
being used to clean up the object (whether on purpose or by accident), 
then if you didn't have a finalizer, the resource leaks.


- else, it's a case of the finalizer being calld by the GC and the 
destructor not being called. Is this considered a bug?


No.


|
|   - If yes, then point of releasing resources is moot since we have a 
bug.

|
|   - If not, it means we want to allow not calling destructors.


Of course, the idea is that a destructor does what the GC would have 
done (recursively call the finalizers of members, and optionally clean 
up memory if wholly owned).



|   |
|   |   => this implies we think finalizers will be called
|   |  I'll make claim this works for process-wide resources somehow 
(we stopped the last debate here), but not transient ones (eg: mutex) 
because of false pointers. The finalizer might be released late.


 From these premises I conclude that the instructions given to new D 
programmers would be:


   1. you should destroy resources deterministically

   2. however GC objects owning resources may release them in their 
finalizer

 * except if you can't release them from any thread
 * except if these resources should be released before the GC 
shutdown (and then you have to explain why finalizer might not be called 
right now).


Today, the finalizer is essentially a last-effort to clean up resources 
that would otherwise leak.


The reason deterministic destruction sucks today is because once you go 
2 levels deep, the only tool available (~this) cannot release any 
resources (because it's not legal to access GC-allocated members inside 
~this).


Adding a destructor concept would fix this issue, and make deterministic 
destruction more pleasant.


Look at any library that contains such non-memory resources. These 
things inevitably implement some sort of "close()" or "release()" 
function, which does the deterministic destruction. It's just a 
destructor with a different name.


-Steve

Re: D easily overlooked?

[kinke via Digitalmars-d]

On Wednesday, 26 July 2017 at 20:23:25 UTC, Ola Fosheim Grøstad 
wrote:
so it doesn't make a whole lot of sense telling people to 
"improve" on it if they haven't even adopted it (in production).


My point was improving vs. complaining. Both take some analysis 
to figure out an issue, but then some people step up and try to 
help improving things and some just let out their frustration, 
wondering why noone has been working on that particular 
oh-so-obvious thing, and possibly drop out, like all the 
like-minded guys before them.

Re: all OS functions should be "nothrow @trusted @nogc"

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 12:08 PM, Patrick Schluter wrote:

On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer wrote:

On 7/25/17 8:45 PM, Timon Gehr wrote:

On 26.07.2017 02:35, Steven Schveighoffer wrote:

On 7/25/17 5:23 PM, Moritz Maxeiner wrote:

On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven Schveighoffer wrote:

The behavior is defined. It will crash with a segfault.


In C land that behaviour is a platform (hardware/OS/libc) specific 
implementation detail (it's what you generally expect to happen, 
but AFAIK it isn't defined in official ISO/IEC C).


In cases where C does not crash when dereferencing null, then D 
would not crash when dereferencing null. D depends on the hardware 
doing this (Walter has said so many times), so if C doesn't do it, 
then D won't. So those systems would have to be treated specially, 
and you'd have to work out your own home-grown mechanism for memory 
safety.


What Moritz is saying is that the following implementation of fclose 
is correct according to the C standard:


int fclose(FILE *stream){
 if(stream == NULL){
 go_wild_and_corrupt_all_the_memory();
 }else{
 actually_close_the_file(stream);
 }
}


I think we can correctly assume no fclose implementations exist that 
do anything but access data pointed at by stream. Which means a 
segfault on every platform we support.


What a luck that Solaris/SPARC is not supported as on that platform 
fclose(NULL) and even close(-1) do not segfault. Had to learn it the 
hard way when we ported our project from Solaris/SPARC to Linux/x86_64. 
It was surprizing how often that (wrong) behavior happenned in our code 
base (100K line of C).


I'm guessing though that it's an implementation detail (like Walter's 
DMC example). A segfault is fine, and returning an error is fine. Both 
will properly be handled, and do not cause UB.


So I guess I should restate that we can assume no implementations exist 
that intentionally cause UB when stream is NULL (as in Timon's example). 
Either they check for null, and handle gracefully, or don't check and 
segfault.


What I was talking about is platforms that don't segfault on 
reading/writing from the zero page. Those we couldn't support with @safe 
D anyway.


-Steve

[Issue 17696] dlclose() not guaranteed to unload the library

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17696

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #1 from Iain Buclaw  ---
GCC internals note, there's flag_gnu_unique.  But actually it seems pretty
silly turning it off explicitly.

--

[Issue 17696] New: dlclose() not guaranteed to unload the library

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17696

  Issue ID: 17696
   Summary: dlclose() not guaranteed to unload the library
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: blocker
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

There's a broken test in druntime. Discovered after making a change in gdc to
put ClassInfo symbols in the comdat (yeah I know, but I am yet to receive any
duplicate symbol bug reports).

https://github.com/dlang/druntime/blob/master/test/shared/src/load.d#L136-L139


Old gdc behaviour:
---
$ readelf -Ws lib.o  | grep MyFinal
   113: 078a38 FUNCGLOBAL DEFAULT   16
_D3lib11MyFinalizer6__dtorMFZv
   117: 16 OBJECT  GLOBAL DEFAULT   28
_D3lib11MyFinalizer6__initZ
   118: 001040 OBJECT  GLOBAL DEFAULT   28
_D3lib11MyFinalizer6__vtblZ
   119:    152 OBJECT  GLOBAL DEFAULT   30
_D3lib11MyFinalizer7__ClassZ
   125: 0040  4112 OBJECT  GLOBAL DEFAULT   28
_D3lib14MyFinalizerBig6__initZ
   126: 105040 OBJECT  GLOBAL DEFAULT   28
_D3lib14MyFinalizerBig6__vtblZ
   127: 00a0   152 OBJECT  GLOBAL DEFAULT   30
_D3lib14MyFinalizerBig7__ClassZ
---

New gdc behaviour:
---
$ readelf -Ws lib.o  | grep MyFinal
   124: 078a38 FUNCGLOBAL DEFAULT   22
_D3lib11MyFinalizer6__dtorMFZv
   128: 16 OBJECT  WEAK   DEFAULT   34
_D3lib11MyFinalizer6__initZ
   129: 40 OBJECT  WEAK   DEFAULT   38
_D3lib11MyFinalizer6__vtblZ
   130:    152 OBJECT  UNIQUE DEFAULT   36
_D3lib11MyFinalizer7__ClassZ
   136:   4112 OBJECT  WEAK   DEFAULT   40
_D3lib14MyFinalizerBig6__initZ
   137: 40 OBJECT  WEAK   DEFAULT   44
_D3lib14MyFinalizerBig6__vtblZ
   138:    152 OBJECT  UNIQUE DEFAULT   42
_D3lib14MyFinalizerBig7__ClassZ
---

Current dmd behaviour:
---
$ readelf -Ws lib.o  | grep MyFinal
   105: 34 FUNCGLOBAL DEFAULT   70
_D3lib11MyFinalizer6__dtorMFZv
   106: 16 OBJECT  WEAK   DEFAULT   72
_D3lib11MyFinalizer6__initZ
   107:    168 OBJECT  WEAK   DEFAULT   73
_D3lib11MyFinalizer7__ClassZ
   108: 40 OBJECT  WEAK   DEFAULT   75
_D3lib11MyFinalizer6__vtblZ
   109:   4112 OBJECT  WEAK   DEFAULT   78
_D3lib14MyFinalizerBig6__initZ
   110:    176 OBJECT  WEAK   DEFAULT   79
_D3lib14MyFinalizerBig7__ClassZ
   111: 40 OBJECT  WEAK   DEFAULT   81
_D3lib14MyFinalizerBig6__vtblZ
---

Notice that dmd marks the __Class symbol as a weak @object, but gdc marks it as
a weak @gnu_unique_object.

This subtle difference means that when calling dlopen() on lib.so, it is marked
as DF_1_NODELETE - meaning "not unloadable", and will never be unloaded no
matter how many times you call dlclose().


Looking at the documentation:

http://pubs.opengroup.org/onlinepubs/007904975/functions/dlclose.html

===
Although a dlclose() operation is not required to remove structures from an
address space, neither is an implementation prohibited from doing so.
===

The druntime test should probably be fixed up, as it may not necessary always
be true.

In the meantime, I'll have a look at possibly a fix on my side, something that
errs towards --no-gnu-unique, however if its not an agnostic fix, then there's
no point in trying to do that.

https://cygwin.com/ml/binutils/2011-10/msg00276.html

--

Re: Silent error when using hashmap

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 12:09 PM, FatalCatharsis wrote:
I apologize, I'm not sure if this is expected behavior, a bug in the 
compiler, or a bug in the core windows libraries, so I'll post this here 
until pointed elsewhere.


I've done this trick with win32 for awhile in other languages where I 
pass a reference to a specific class of my own that represents an 
instance of window to the CreateWindowEx function, and then use a static 
router function to send messages to the specific instance. I've made the 
most minimal example I can in this gist.


https://gist.github.com/FatalCatharsis/d3cc6ec621f0600975806fe23610ae32

When I compile this and run this, nothing is printed and no window is 
created. I've tried putting try catches around everything (including the 
inside of the static constructor), but nothing is caught.


Note that in D when a thread crashes besides the main thread, you may 
not get a stack trace printout. You may get nothing.


-Steve

Re: Silent error when using hashmap

[Mike Parker via Digitalmars-d]

On Wednesday, 26 July 2017 at 16:09:30 UTC, FatalCatharsis wrote:



When I compile this and run this, nothing is printed and no 
window is created. I've tried putting try catches around 
everything (including the inside of the static constructor), 
but nothing is caught.


You're casting this to void*, which is correct, but then when you 
fetch it back you're casting to a WinThing*, which is not 
correct. this is a reference, not a pointer. Cast to WinThing 
instead of WinThing*.

Re: Destructors vs. Finalizers

[Dgame via Digitalmars-d]

On Wednesday, 26 July 2017 at 20:02:02 UTC, Moritz Maxeiner wrote:

On Wednesday, 26 July 2017 at 19:18:48 UTC, Dgame wrote:


Alright, thanks for the clarification. I've briefly hoped for 
some sort of miracle such as deterministic object lifetime 
without manual interaction. :)


I'm not sure what scheme you are trying to describe here, could 
you give a code example of what you hoped for?


Built-in Ownership/RC for objects.

[Issue 17695] [Reg 2.076] ICE with vector negation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17695

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/7ceb34a633518c75e61f858fde1fa3eb4d7c6300
fix Issue 17695 - [Reg 2.076] ICE with vector negation

https://github.com/dlang/dmd/commit/6dc8c01c246c3633077ed2e7bc9d17fb0a79d896
Merge pull request #7035 from WalterBright/fix17695

fix Issue 17695 - [Reg 2.076] ICE with vector negation
merged-on-behalf-of: Martin Nowak 

--

Re: D easily overlooked?

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 26 July 2017 at 19:56:01 UTC, Ali wrote:
And dont worry about D, its been around for 16-17 years now, it 
may never be as big as Python, Ruby or Go


But what is more important that it continues to be developed 
and improved and ... used


I don't think anyone that don't use D in production worry about 
it. I simply don't think that many programming languages have any 
intrinsic value so it doesn't make a whole lot of sense telling 
people to "improve" on it if they haven't even adopted it (in 
production).


For some simply understanding the landscape and nature of the 
evolution of open sourced programming languages (Rust, D etc) 
have more value than the languages themselves. So yeah, not 
sticking to any single language makes a lot of sense, they are 
just tools, means to an end, not goals in themselves and none of 
the current day languages are worthy of cultist behaviour…

Re: Destructors vs. Finalizers

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 26 July 2017 at 19:18:48 UTC, Dgame wrote:


Alright, thanks for the clarification. I've briefly hoped for 
some sort of miracle such as deterministic object lifetime 
without manual interaction. :)


I'm not sure what scheme you are trying to describe here, could 
you give a code example of what you hoped for?

Re: D easily overlooked?

[Ali via Digitalmars-d]

On Wednesday, 26 July 2017 at 19:56:01 UTC, Ali wrote:
.. honestly it should, now one language should be your only 
language,



DIP 9000, we need a real forum software,
the above is a typo it should read

"honestly it should not
no one language should be your only language"

Re: D easily overlooked?

[Ali via Digitalmars-d]

On Wednesday, 26 July 2017 at 19:27:06 UTC, Ola Fosheim Grøstad 
wrote:

On Wednesday, 26 July 2017 at 18:58:31 UTC, kinke wrote:
People need to eventually understand that all the energy 
wasted for complaining about D/the community/whatever would be 
so much more valuable if put into contributions.


Value is relative. So, if you don't use a tool in production 
why would you derive more value value from "improving" on the 
tool rather than analysing it to figure out 
why/why-not/how/how-not etc? Gaining insight might actually be 
more valuable…


Well, D now have a Improvement Proposal system (DIP), the actual 
visibility of this process can surely improve


I recommend looking at Tcl's TIP system, for inspiration

In my opinion an Improvement Proposal system is a lot better than 
a roadmap, because you can very clearly see, what the community 
is talking about, which improvements have implementations, which 
are just ideas, which are approved which are not, some IP entries 
takes years to implement


I think as the DIP system matures, it will help D a lot

And dont worry about D, its been around for 16-17 years now, it 
may never be as big as Python, Ruby or Go


But what is more important that it continues to be developed and 
improved and ... used


Many languages have small communities and will continue to .. 
such as Haskell, Idris, OCaml, F#, Clojure, Lisp , Elm  ..


As long as D have a solid, bug free implementation, you have 
nothing to worry about .. and it doesnt have to be your only 
language .. honestly it should, now one language should be your 
only language, I would argue any developer can master 3 to 5 
languages at any time ... try to pick ones that dont overlap much


Python, SQl, R, .. D, Dart

Re: D easily overlooked?

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 26 July 2017 at 18:58:31 UTC, kinke wrote:
People need to eventually understand that all the energy wasted 
for complaining about D/the community/whatever would be so much 
more valuable if put into contributions.


Value is relative. So, if you don't use a tool in production why 
would you derive more value value from "improving" on the tool 
rather than analysing it to figure out why/why-not/how/how-not 
etc? Gaining insight might actually be more valuable…

Re: Destructors vs. Finalizers

[Dgame via Digitalmars-d]

On Wednesday, 26 July 2017 at 18:33:58 UTC, Moritz Maxeiner wrote:

On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in 
use anymore. The order in which this is currently happening is 
not specified. So, how are the destructors supposed to be 
called in the right order? Manually? ARC?


After the split:
Destructors are only for deterministic end of object lifetime, 
so yes, they are to be called by any scheme (such as manual 
management via destroy and reference counting - which is likely 
also implemented as calling destroy) that is deterministic.

Finalizers are for nondeterministic schemes such as the GC.
The GC *never* calls destructors directly, only finalizers.
A finalizer might manually call a destructor, but a destructor 
may never call a finalizer.


Alright, thanks for the clarification. I've briefly hoped for 
some sort of miracle such as deterministic object lifetime 
without manual interaction. :)

Re: is the ubuntu sourceforge repository safe?

[Ali via Digitalmars-d]

On Monday, 24 July 2017 at 11:02:55 UTC, Russel Winder wrote:
On Sun, 2017-07-23 at 18:23 +, Michael via Digitalmars-d 
wrote:


I stopped using it. It kept causing error messages in my 
package manager and I couldn't update it properly so I've just 
stuck to downloading the updates on release.


If we are talking about D-Apt here  
http://d-apt.sourceforge.net/  it seems to be working fine for 
me on Debian Sid.  2.075 just installed this morning.


I think it would be better to have a PPA that is hosted on 
launchpad

Re: Why can't typeof() be used in member method?

[Andre Pany via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 17:04:59 UTC, Adam D. Ruppe wrote:

On Wednesday, 26 July 2017 at 16:50:35 UTC, Andre Pany wrote:

[...]


FYI, you shouldn't use .stringof here. Just use `T` instead of 
`T.stringof`.


[...]


Thank you so much!

Kind regards
André

Re: D easily overlooked?

[kinke via Digitalmars-d]

On Wednesday, 26 July 2017 at 15:55:14 UTC, Wulfklaue wrote:
But how about NOT always adding new feature and actually making 
things more easy for new people.


People need to eventually understand that all the energy wasted 
for complaining about D/the community/whatever would be so much 
more valuable if put into contributions. I'm tired of these 
negative vibes, 'somebody else gotta do this in his/her spare 
time, I need it so bad!' paradigm.


You for example reported a potential LDC issue you encountered 
(Visual Studio 2017 not autodetected), thanks for taking that 
time, but when I asked you to dig into it, you didn't even reply: 
https://github.com/ldc-developers/ldc/issues/2134. That's not the 
way issues are fixed and D can move forward, and neither is 
endlessly complaining about the (perceived) status quo.


[I ignored this thread for now but was curious why it's still 
active, so I only read the last 2 posts.]

Re: Why structs and classes instanciations are made differently ?

[Ali Çehreli via Digitalmars-d-learn]

On 07/26/2017 02:54 AM, Houdini wrote:

On Tuesday, 25 July 2017 at 17:16:00 UTC, Kagamin wrote:

On Tuesday, 25 July 2017 at 15:56:45 UTC, Houdini wrote:

Yes, but it isn't the default way in C++ to do dynamic instanciation.


https://github.com/isocpp/CppCoreGuidelines this? It's only 2 years
old. The new operator predates it by decades.


I meant :

When you need to instantiate a class, you usually do :

MyClass a;

and not :

MyClass* a = new MyClass();

You're in a value model.


That's my experience as well. However, stack class objects are rare and 
to repeat Steven, it comes with the problem of slicing. Only after 
learning D that I realized there were two kinds of C++ types in my code: 
value types and reference types, latter of which I've achieved with 
boost::shared_ptr. So, I think D's separation is the right choice.


However, classes are unnecessarily expensive due to that 'monitor' 
member and carry the mistakes of OOP models adopted by Java, C++, and 
others. I say this under the influence of open multi-methods[1] and 
anemic domain models[2].


Ali

[1] http://forum.dlang.org/thread/cigbfrgipbokyetsk...@forum.dlang.org

[2] https://www.meetup.com/D-Lang-Silicon-Valley/events/228027468/

Re: Destructors vs. Finalizers

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 26 July 2017 at 17:38:28 UTC, Dgame wrote:
I don't get it. The GC collects the objects which aren't in use 
anymore. The order in which this is currently happening is not 
specified. So, how are the destructors supposed to be called in 
the right order? Manually? ARC?


After the split:
Destructors are only for deterministic end of object lifetime, so 
yes, they are to be called by any scheme (such as manual 
management via destroy and reference counting - which is likely 
also implemented as calling destroy) that is deterministic.

Finalizers are for nondeterministic schemes such as the GC.
The GC *never* calls destructors directly, only finalizers.
A finalizer might manually call a destructor, but a destructor 
may never call a finalizer.

Re: D easily overlooked?

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 26 July 2017 at 15:55:14 UTC, Wulfklaue wrote:
The issue of D is not the pure language but this strange over 
focus on being the next C++ replacement that nobody is asking 
for! There are already a lot of other languages that can do C++ 
things, namely C++!


Once upon a time D claimed to be a cleaned up and more convenient 
C++ style language, but I don't think it moved in that direction 
after the onset. So I don't view it as a C++ replacement, but 
more like an enthusiast language that more people toy with than 
use in production. If D actually moved to take on C++ then that 
would be sensible strategy, but at this point there is just too 
much baggage and C++ is now much more of a moving target than it 
was 10 years ago. So, D cannot assume that goal, as C++ is moving 
faster than D at the moment...


There are just too much things where D is lacking but people 
there is simply a lack of flow.


Well, you have to match ambitions to the resources. I think Go 
made the right decision there, to scale the language to something 
they could get to relatively stable in a reasonable amount of 
time, then work on the runtime. Not sexy, but useful.


And the end result became, i gave up on D. Switch to the 
freaking old Pascal language and got more stuff done in a few 
days time, then the semi-months with D. How strange it may 
sound.


Why Pascal, and not one of the more contemporary languages?

Re: Is this related to D?

[angel via Digitalmars-d]

On Wednesday, 26 July 2017 at 18:09:23 UTC, Andrei Alexandrescu 
wrote:
I got this on a Google Alert for "dlang": 
https://launchpad.net/ubuntu/+source/language-pack-kn/1:17.10+20170724/+build/13147073. Is it connected to the D language? -- Andrei


No, this is related to Kannada language translation, which is a 
human language.

Re: Why structs and classes instanciations are made differently ?

[Patrick Schluter via Digitalmars-d-learn]

On Monday, 24 July 2017 at 17:42:30 UTC, Steven Schveighoffer 
wrote:

On 7/24/17 11:45 AM, Houdini wrote:
On Monday, 24 July 2017 at 15:41:33 UTC, Steven Schveighoffer 
wrote:


Because types with inheritance generally don't work right if 
you pass by value (i.e. the slicing problem).


structs don't support inheritance or virtual functions, so 
they can be safely passed by value.


But in C++, we pass them by reference also to avoid copies 
(const &).
The potential polymorphic usage is not the only point to 
consider.




In C++ class and struct are pretty much interchangeable, so 
technically, class is a wasted keyword for default visibility.


In D, I would use classes for any time I need polymorphism, and 
use structs otherwise.


-Steve


It has also the nice property that porting code from Java/C# is 
actually really easy when using classes as it has more or less 
the same semantic. When porting code from C and C++ it is often 
better to use structs.

Re: Anyone relying on signaling NaNs?

[kinke via Digitalmars-d]

On Saturday, 1 October 2016 at 19:10:47 UTC, Martin Nowak wrote:
Just tried to fix the float/double initialization w/ signaling 
NaNs [¹], but it seems we can't reliably do that for all 
backends/architectures. Any additional move of float might 
convert SNaNs to QNaNs (quiet NaNs). This has also been the 
finding of other people [²][³].


The biggest problem w/ the current situation is that float 
fields of a struct sometimes are initialized to QNaNs and fail 
`s.field is float.init`.


We thought about giving up on SNaNs as default float init 
values. Is anyone relying on them?


I just had the same 'fun' with LDC. Both LDC 1.3 and DMD 2.074.0 
produce special quiet NaNs for float.init and double.init on 
Win64 (both most significant mantissa bits set). I also tried to 
fix it, but it seems impossible when the x87 FPU (and not SSE) is 
used. This leads to a Win64 LDC build using signalling inits when 
cross-compiling via `-m32`, while the native Win32 LDC compiler 
uses quiet ones etc.


So I'm all in for consistent special quiet NaNs as init values 
for all 3 floating-point types (already implemented, 
https://github.com/ldc-developers/ldc/pull/2207). If someone 
relies on signalling NaNs and missed the original post, here's 
your chance to speak up.

Re: I feel the dynamic array .sizeof property is kind of a bait and switch

[WhatMeWorry via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 02:32:07 UTC, Adam D. Ruppe wrote:


I've hand rolled a function which is working for me currently, 
but with my coding ability, I'd feel much safer with something 
official :)


You could also do (cast(ubyte[]) array).length.



This was my (way over complicated) attempt at the same thing. 
I'll blame my verbosity because I was trying to teach myself 
about templates and constraints at the time :)


/+
There is a special type of array which acts as a wildcard that 
can hold arrays of any kind, declared as void[].  The .length of 
a void array is the length of the data in

bytes rather than the number of elements in its original type. "
+/

int arrayByteSize(T)(T someArray) if (isDynamicArray!(T))
{
ubyte[] arr = cast(ubyte[]) someArray;
return cast(int) arr.length;
}

It just seems like something this basic regarding dynamic 
arrays should just be built-in.


What are you using it for?


glBufferData(GL_ARRAY_BUFFER, vertices.arrayByteSize, 
vertices.ptr, GL_STATIC_DRAW);


I find that openGL uses array buffers all over the place.

I just keep going back to the idea that such low level 
functionality should be inherent in either the language or 
Phobos.  If that is even possible.

Is this related to D?

[Andrei Alexandrescu via Digitalmars-d]

I got this on a Google Alert for "dlang": 
https://launchpad.net/ubuntu/+source/language-pack-kn/1:17.10+20170724/+build/13147073. 
Is it connected to the D language? -- Andrei

Re: all OS functions should be "nothrow @trusted @nogc"

[Walter Bright via Digitalmars-d]

On 7/26/2017 6:29 AM, Kagamin wrote:

Should we still try to mark them safe at all?


Marking ones that are safe with @safe is fine. OS APIs pretty much never change.

Re: all OS functions should be "nothrow @trusted @nogc"

[Walter Bright via Digitalmars-d]

On 7/26/2017 3:14 AM, Timon Gehr wrote:

On 26.07.2017 05:02, Walter Bright wrote:

The implementation checks for fp being NULL and returns EOF if it is.


The C mindset is that this check is a waste of precious processing resources and 
morally wrong, as only a fool would pass NULL anyway, and fools deserve to get UB.


I wrote that code 30+ years ago, and no longer remember why I put the null check 
in. It might have been because other C compiler libraries did it.

Re: Destructors vs. Finalizers

[Dgame via Digitalmars-d]

I don't get it. The GC collects the objects which aren't in use 
anymore. The order in which this is currently happening is not 
specified. So, how are the destructors supposed to be called in 
the right order? Manually? ARC? As far as I understand it, the GC 
can't do it, otherwise we wouldn't have the "random" order in 
which the finalizer are called in the first place.

Re: How to make autocompletion for IDE?

[unDEFER via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 07:41:20 UTC, Andrea Fontana wrote:

Did you try with [1]?

[1] http://forum.dlang.org/post/okktlu$2bin$1...@digitalmars.com


Thank you, interesting. But I'm afraid it is not enough.

Re: [your code here] Pure RPN calculator

[Patrick Schluter via Digitalmars-d]

On Wednesday, 26 July 2017 at 17:12:00 UTC, Mike Wey wrote:

On 26-07-17 16:40, Iakh wrote:

On Wednesday, 26 July 2017 at 09:46:45 UTC, Timon Gehr wrote:

 readln.split.fold!((stack,op){
 switch(op){
 static foreach(c;"+-*/") case [c]:
 return stack[0..$-2]~mixin("stack[$-2] 
"~c~" stack[$-1]");

 default: return stack~op.to!real;
 }
 })((real[]).init).writeln;


What does "case [c]:" mean?



In the static foreach c is a `immutable char` by putting it 
between [ and ] you create an array of immutable characters 
(string).


That's why some comments in the code would go a long way in 
lifting such issues.

Re: GtkD on android?

[Mike Wey via Digitalmars-d-learn]

On 25-07-17 20:06, Joakim wrote:

On Saturday, 22 July 2017 at 18:59:44 UTC, FoxyBrown wrote:
With LDC's new ability to do android/arm, we are missing the ability 
to do GUI's? Can any of the current D solutions work such as GtkD or 
QtD? I'm looking for something somewhat lightweight, easy to use(I 
find GtkD a bit funky but it does seem to work and is relatively easy 
once one gets through the basics). I think having a GUI builder is 
crucial though as it makes it so much easier in the long run. Glade is 
a bit funky but functional and works.


Ideally I'd like to be able to make portable apps that just work 
across the board(mac, linux, windows, android) without much hassle.


Mike said maybe later, when I asked him in January:

http://forum.dlang.org/post/o4rq0i$dur$1...@digitalmars.com

In the meantime, you can try DlangUI, as Seb pointed out, but I get the 
impression it's not touch-optimized, just like Gtk.


And if you want something lightweight, the complete GTK stack is 
probably not what you are looking for.


--
Mike Wey

Re: Bug in File.byRecord ?

[Ali Çehreli via Digitalmars-d-learn]

On 07/26/2017 04:51 AM, closescreen wrote:
> I have a file with empty lines: 2,3 and 5,6
>
> filename.csv (with linenumbers for better view in this message)
> 1>Joe,Carpenter,30
> 2>
> 3>
> 4>Fred,Blacksmith,40
> 5>
> 6>
>
> Now, if I run:
> rdmd
> 
--eval='"filename.csv".File.byRecord!(string,string,int)("%s,%s,%d").writeln'

>
>
> It prints:
>
> [Tuple!(string, string, int)("Joe", "Carpenter", 30),
>  Tuple!(string, string, int)("Joe", "Carpenter", 30),
>  Tuple!(string, string, int)("Joe", "Carpenter", 30),
>  Tuple!(string, string, int)("Fred", "Blacksmith", 40),
>  Tuple!(string, string, int)("Fred", "Blacksmith", 40),
>  Tuple!(string, string, int)("Fred", "Blacksmith", 40)]
>
> It happens because code in
>
> https://github.com/dlang/phobos/blob/master/std/stdio.d#L297
>
> not checks return value after call formattedRead.
>
> Is this a bug?

Yes, I think it's a bug.

Ali

[Issue 17695] [Reg 2.076] ICE with vector negation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17695

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7035

--

Re: [your code here] Pure RPN calculator

[Mike Wey via Digitalmars-d]

On 26-07-17 16:40, Iakh wrote:

On Wednesday, 26 July 2017 at 09:46:45 UTC, Timon Gehr wrote:

 readln.split.fold!((stack,op){
 switch(op){
 static foreach(c;"+-*/") case [c]:
 return stack[0..$-2]~mixin("stack[$-2] "~c~" 
stack[$-1]");

 default: return stack~op.to!real;
 }
 })((real[]).init).writeln;


What does "case [c]:" mean?



In the static foreach c is a `immutable char` by putting it between [ 
and ] you create an array of immutable characters (string).


--
Mike Wey

Re: Why can't typeof() be used in member method?

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 16:50:35 UTC, Andre Pany wrote:
mixin(`static if (!__traits(compiles, 
typeof(`~T.stringof~`.`~p.name~`))) {

...
}


FYI, you shouldn't use .stringof here. Just use `T` instead of 
`T.stringof`.


Creating new class for checking whether the class has a 
specific member is not possible in my scenario, as a DLL call 
is involved and I need the result (member available) as 
condition for static if.


This doesn't *actually* create a new class, it just compiles as 
if you would to make sure it has a valid `this` for it in the 
type system.


You could also use `typeof(TBounds.init.Left)`, which is actually 
even better than `new` since it doesn't require the constructor 
arguments.


But in either case, that code isn't actually run, it just looks 
for the non-static member function.


Due you think typeof should work within member methods and I 
should file an issue?


I'm not sure... I could go either way on it since there is a 
reasonable answer here (int), but since it is non-static, trying 
to use it in an actual expression IS an error so it makes sense 
for typeof(error) to also be an error...

Re: Why can't typeof() be used in member method?

[Andre Pany via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 14:05:12 UTC, Adam D. Ruppe wrote:

On Wednesday, 26 July 2017 at 13:51:05 UTC, Andre Pany wrote:

How can I fix this issue?


I would just do

   typeof((new TBounds).Left) m;


so then it is clear that you want a non-static member.


In my productive scenario I try to check whether a class (TLabel) 
has a specific member ("Margins.Left", "TextSettings.Font.Size").


mixin(`static if (!__traits(compiles, 
typeof(`~T.stringof~`.`~p.name~`))) {

...
}

This coding is within a member method and due to the issue with 
typeof it is failing.
Creating new class for checking whether the class has a specific 
member is not possible in my scenario, as a DLL call is involved 
and I need the result (member available) as condition for static 
if.


Due you think typeof should work within member methods and I 
should file an issue?


Kind regards
André

Re: Silent error when using hashmap

[ketmar via Digitalmars-d]

FatalCatharsis wrote:

I apologize, I'm not sure if this is expected behavior, a bug in the 
compiler, or a bug in the core windows libraries, so I'll post this here 
until pointed elsewhere.


I've done this trick with win32 for awhile in other languages where I 
pass a reference to a specific class of my own that represents an 
instance of window to the CreateWindowEx function, and then use a static 
router function to send messages to the specific instance. I've made the 
most minimal example I can in this gist.


https://gist.github.com/FatalCatharsis/d3cc6ec621f0600975806fe23610ae32

When I compile this and run this, nothing is printed and no window is 
created. I've tried putting try catches around everything (including the 
inside of the static constructor), but nothing is caught.


However, when I comment out the hash lookup on line 54, the compiled 
program runs fine and creates a window, (but only for a moment since 
there is not a message handling loop). The expected printout of "start" 
and "end" occurs just fine.


What is happening here that causes the program not execute at all, with 
no output and no exceptions? Is this a bug with my code, a bug with the 
core.sys.windows.windows library, or a bug with the compiler? Any info 
about how to debug this further is greatly appreciated.


'cause `WM_CREATE` is not the first message window receiving. check if hwnd 
is in hash with `in` first.

Re: I feel the dynamic array .sizeof property is kind of a bait and switch

[WhatMeWorry via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 02:31:33 UTC, Mike Parker wrote:

On Wednesday, 26 July 2017 at 02:24:06 UTC, WhatMeForget wrote:

[...]


Because .sizeof has nothing to do with how many elements are in 
the array. It tells you how much space the array itself takes 
up.


Totally agree.  .length returns the the number of array elements.

With static arrays, the memory for the elements if part of the 
array itself, so it is counted in the size. For dynamic arrays, 
it is not. For .sizeof to report the size of the allocated 
memory would be incorrect.


OK, Then I assume the critical thing is that dynamic arrays 
memory is

not part of the array itself.  But is this a deal breaker?

Re: all OS functions should be "nothrow @trusted @nogc"

[Patrick Schluter via Digitalmars-d]

On Wednesday, 26 July 2017 at 03:16:44 UTC, Walter Bright wrote:

On 7/25/2017 6:09 PM, Steven Schveighoffer wrote:
Likewise, because D depends on hardware flagging of 
dereferencing null as a segfault, any platforms that *don't* 
have that for C also won't have it for D. And then @safe 
doesn't even work in D code either.


I spent 10 years programming on DOS with zero memory 
protection, and people have forgotten how awful that was. You 
couldn't simply instrument the code with null pointer checks, 
either, because then the program would be too big to fit.


The solution finally appeared with the 286 DOS Extenders, which 
ran in protected mode. I switched to doing all my development 
under them, and would port to DOS only after passing all the 
test suite.


D is definitely predicated on having hardware memory protection.

The C/C++ Standards are still hanging on to EBCDIC, 10 bit 
bytes, non-IEEE floating point, etc. It's time to let that crap 
go :-)


One C++ programmer told me that C++ could handle any character 
set. I asked him how RADIX50 was supported. Segfault! (I 
learned to program on RADIX50 systems.)


D made some fundamental decisions:

* Unicode
* 2's complement
* 8 bit bytes
* IEEE arithmetic
* memory protection
* fixed sizes for integral types
* single pointer type
* >= 32 bit processors

that relegated a lot of junk to the dustbin of history. (It's 
awful pretending to support that stuff. C and C++ pretend do, 
but just about zero programs will actually work on such 
systems, because there aren't any to try the code out on.)


And alone for that list of decision do I love you. I can not hear 
anymore all the crap about "undefined behaviour", "nasal demons" 
and optimizer that think that they are entitled to sabotage 
programs because he is an over zealous language lawyer in the C 
world practicing POOP (premature optimisation oriented 
programming).

Silent error when using hashmap

[FatalCatharsis via Digitalmars-d]

I apologize, I'm not sure if this is expected behavior, a bug in 
the compiler, or a bug in the core windows libraries, so I'll 
post this here until pointed elsewhere.


I've done this trick with win32 for awhile in other languages 
where I pass a reference to a specific class of my own that 
represents an instance of window to the CreateWindowEx function, 
and then use a static router function to send messages to the 
specific instance. I've made the most minimal example I can in 
this gist.


https://gist.github.com/FatalCatharsis/d3cc6ec621f0600975806fe23610ae32

When I compile this and run this, nothing is printed and no 
window is created. I've tried putting try catches around 
everything (including the inside of the static constructor), but 
nothing is caught.


However, when I comment out the hash lookup on line 54, the 
compiled program runs fine and creates a window, (but only for a 
moment since there is not a message handling loop). The expected 
printout of "start" and "end" occurs just fine.


What is happening here that causes the program not execute at 
all, with no output and no exceptions? Is this a bug with my 
code, a bug with the core.sys.windows.windows library, or a bug 
with the compiler? Any info about how to debug this further is 
greatly appreciated.

Re: all OS functions should be "nothrow @trusted @nogc"

[Patrick Schluter via Digitalmars-d]

On Wednesday, 26 July 2017 at 01:09:50 UTC, Steven Schveighoffer 
wrote:

On 7/25/17 8:45 PM, Timon Gehr wrote:

On 26.07.2017 02:35, Steven Schveighoffer wrote:

On 7/25/17 5:23 PM, Moritz Maxeiner wrote:
On Tuesday, 25 July 2017 at 20:16:41 UTC, Steven 
Schveighoffer wrote:

The behavior is defined. It will crash with a segfault.


In C land that behaviour is a platform (hardware/OS/libc) 
specific implementation detail (it's what you generally 
expect to happen, but AFAIK it isn't defined in official 
ISO/IEC C).


In cases where C does not crash when dereferencing null, then 
D would not crash when dereferencing null. D depends on the 
hardware doing this (Walter has said so many times), so if C 
doesn't do it, then D won't. So those systems would have to 
be treated specially, and you'd have to work out your own 
home-grown mechanism for memory safety.


What Moritz is saying is that the following implementation of 
fclose is correct according to the C standard:


int fclose(FILE *stream){
 if(stream == NULL){
 go_wild_and_corrupt_all_the_memory();
 }else{
 actually_close_the_file(stream);
 }
}


I think we can correctly assume no fclose implementations exist 
that do anything but access data pointed at by stream. Which 
means a segfault on every platform we support.


What a luck that Solaris/SPARC is not supported as on that 
platform fclose(NULL) and even close(-1) do not segfault. Had to 
learn it the hard way when we ported our project from 
Solaris/SPARC to Linux/x86_64. It was surprizing how often that 
(wrong) behavior happenned in our code base (100K line of C).




On platforms that may not segfault, you'd be on your own.

In other words, I think we can assume for any C functions that 
are passed pointers that dereference those pointers, passing 
null is safely going to segfault.
Dereferencing NULL pointer on Solaris/SPARC segfaults but 
fclose() does apparently not dereference blindly the passed 
pointer. I suspect that SUN intentionnally reduced the 
opportunities to segfault on a lot of system calls and libs. The 
port to Linux revealed several violations (stale pointer usage, 
double frees, buffer overflows) that never triggered on Solaris 
and the project is more than 20 year old.




Likewise, because D depends on hardware flagging of 
dereferencing null as a segfault, any platforms that *don't* 
have that for C also won't have it for D. And then @safe 
doesn't even work in D code either.


As we have good support for different prototypes for different 
platforms, we could potentially unmark those as @trusted in 
those cases.

Re: Destructors vs. Finalizers

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 26 July 2017 at 15:15:03 UTC, Steven Schveighoffer 
wrote:

On 7/26/17 10:57 AM, Guillaume Piolat wrote:

I'll defend the view point that there is _nothing_ useful to 
do in a finalizer except to check if the destructor has 
already been called.


The thing to do in a finalizer that is useful is to release any 
non-GC resources.


-Steve


Interesting case.

Do we assume the finalizer is always called after the destructor?

- If yes, then releasing these non-GC resources could have been 
possible in the destructor too. The only lost generality would be 
if releasing such non-GC resources would be faster from the GC 
thread (could well be since pooled).


- else, it's a case of the finalizer being calld by the GC and 
the destructor not being called. Is this considered a bug?

|
|   - If yes, then point of releasing resources is moot since we 
have a bug.

|
|   - If not, it means we want to allow not calling destructors.
|   |
|   |   => this implies we think finalizers will be called
|   |  I'll make claim this works for process-wide resources 
somehow (we stopped the last debate here), but not transient ones 
(eg: mutex) because of false pointers. The finalizer might be 
released late.


From these premises I conclude that the instructions given to new 
D programmers would be:


  1. you should destroy resources deterministically

  2. however GC objects owning resources may release them in 
their finalizer

* except if you can't release them from any thread
* except if these resources should be released before the GC 
shutdown (and then you have to explain why finalizer might not be 
called right now).

Re: D easily overlooked?

[Wulfklaue via Digitalmars-d]

On Wednesday, 26 July 2017 at 06:40:22 UTC, Bienlein wrote:
D is the most feature rich language I know of. Maybe only Scala 
comes close, but Scala can be at times an unreadable mess as 
the designers of the language valued mixing functional and OO 
higher than readability. D, on the contrary, has a very clean 
design througout.


But you are right. D is missing some unique selling point like 
ease of concurrency using Communicating Sequential Processes in 
Go or memory safety in Rust without a GC. This is because D 
does not have a business model, but seems to be seen as a 
playground for building the greatest language ever. I fear this 
will not change. Topics of people arguing that D needs a 
business case pop up regularly here and are every time mostly 
or also completely ignored. It does not look like this will 
change, because the main drivers of the language never drop a 
comment in those discussions.


I noticed the issues for me is going beyond just the language. 
Its also productivity.


Not going to hide that i switched to Pascal. There are some 
features that are needed in my case, where pascal has been 
kicking D's behind in my personal opinion.


One of those has been frankly community support. Lets say there 
is a issue in D and one posts about it here. If your lucky, in a 
few hours there is a response. Then the response can be 
categorized as:


* Friendly / Useful / Solve issue
* Useless off-topic responds that does not answer the question 
but focuses on a complaint and ignores the issue.
* Semi-aggressive answer that indeed solves the issue but one 
feels "intimidated"


I have for a long time have a love / hate relationship with D. 
And the negative feels have  always stemmed from the strange 
community.


Its not just the Pascal community where i feel better, even in 
the Rust / Go community people feel like the have more patience 
or are less judgmental.


Its this strange semi-aggressive that is her, that just feels so 
strange. I can not put my finger on it. All i can say is that i 
do not experience it in the same degree as with D.


Lets say i bring up the issue: Plugin/DLL linking is a bore and 
needs to be more easy. Go made it easier with simply 
"-buildmode=plugin". In Pascal it only takes one keyword 
"library"... I can bring up a lot of topics like this where 
things are more easy in other languages and in D it requires at 
times hours to get something going but lets use this example.


You will get people that agree but then at the same time point 
out:


* Stop complaining about it, we do not have the people to add 
this.

* Why don't you code it into the D source.
* Agree but it will never happen.
* We do not need this.
* Why do you not pay for this feature.

And every topic with a complained or suggestion comes down to 
this.


They recently added Static foreach ... yay ... and i do not care 
a god daim thing because it only adds more C++ upper language 
focus but does not make the language or the platform more easy. 
And boy are people going to be annoyed for me writing this. But 
how about NOT always adding new feature and actually making 
things more easy for new people.


The issue of D is not the pure language but this strange over 
focus on being the next C++ replacement that nobody is asking 
for! There are already a lot of other languages that can do C++ 
things, namely C++!


You want no memory management, you go Rust, Pascal, ... Easy web 
development, Go, Crystal, hell Ruby, PHP. System development: C, 
C++, Rust...


D is trying to win over a market with a mix of language feature 
that make it a master of none. And that shows...


There are just too much things where D is lacking but people 
there is simply a lack of flow.


Can not do X because of lack of money, people.
Can not get more money because we lack X and people.
Can not get more people because we lack X and money.

And the circle keep going while attention is put on language 
feature when the language is already great but the whole sea of 
other issues outside the language get a minimal of attention


I will not wast too much time on this because i can write on a 
piece of paper and know what the exact responses will be.


And the end result became, i gave up on D. Switch to the freaking 
old Pascal language and got more stuff done in a few days time, 
then the semi-months with D. How strange it may sound. And hell, 
trust me, Pascal there documentation sucks in its 1980s style but 
still its so much more easy to connect the dots. People know my 
opinion on the current D doc system :)  So its not just about 
modern styling and examples...

Re: Destructors vs. Finalizers

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 26 July 2017 at 15:42:45 UTC, jmh530 wrote:
On Wednesday, 26 July 2017 at 14:57:14 UTC, Guillaume Piolat 
wrote:


But then no transition path.



Does seem a bit like a nightmare...

It may facilitate a transition to add a destructor member 
function as well (C# has dispose as an interface, maybe that's 
better?). Then have a deprecation for ~this and tell people to 
use finalize or destructor, and then add back ~this with the 
property that the default ~this calls destructor if that's 
there.


Well I like this idea best.
To split C in A and B, deprecate C and tell what to do instead.

Re: Destructors vs. Finalizers

[jmh530 via Digitalmars-d]

On Wednesday, 26 July 2017 at 14:57:14 UTC, Guillaume Piolat 
wrote:


But then no transition path.



Does seem a bit like a nightmare...

It may facilitate a transition to add a destructor member 
function as well (C# has dispose as an interface, maybe that's 
better?). Then have a deprecation for ~this and tell people to 
use finalize or destructor, and then add back ~this with the 
property that the default ~this calls destructor if that's there.

[Issue 17680] Broken ddmd source links in documentation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17680

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dlang.org

https://github.com/dlang/dlang.org/commit/fc7a8aeadeaf3782ffd60e802d705bf7ac0f3e0d
Issue 17680 - fix DMDSRC

https://github.com/dlang/dlang.org/commit/f2ecd76842a28bfa15acf72460a77f93010bcfdd
Merge pull request #1843 from wilzbach/fix-17680

Issue 17680 - fix DMDSRC
merged-on-behalf-of: MetaLang 

--

Re: Destructors vs. Finalizers

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 10:57 AM, Guillaume Piolat wrote:

I'll defend the view point that there is _nothing_ useful to do in a 
finalizer except to check if the destructor has already been called.


For instance, a destructor could destroy recursively all members at that 
time.


A finalizer would not be able to.

The thing to do in a finalizer that is useful is to release any non-GC 
resources.


-Steve

Re: dub and hierarchies of packages

[Guillaume Piolat via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 14:05:09 UTC, Jean-Louis Leroy 
wrote:
I have a package hierarchy (here 
https://github.com/jll63/openmethods.d/blob/master/dub.sdl) and 
I would like to 'dub run' or 'dub test' everything. Is there a 
recursive mode that I've missed?


I don't think there is one. But would be useful!

Secondly, I have buildTypes that I would like to use in all the 
packages (like here 
https://github.com/jll63/openmethods.d/blob/master/tests/misc/dub.sdl#L9). I would like to avoid repeating it in every dub.sdl. I tried putting the buildTypes in the root dub.sdl and defining my subpackages there (in spite of the warning against doing that) in the hope that the buildTypes would be globally available, but no. Is there a way of making the subpackages inherit stuff from their parent? Or some sort of sdl #include or 'import'?


I think in DUB packages inherit flags from their dependencies 
when --combined is used. You could maybe use a fake dependency to 
insert the right "dflags" or "versions" for your particular build 
type.
Something that also changed in the past is adding the new build 
type to DUB in the case it's a generic enough need.

Re: Destructors vs. Finalizers

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 26 July 2017 at 14:10:19 UTC, Moritz Maxeiner wrote:
AFAICT that was mostly because it would have broken plenty of 
existing code.


The validity or purposefulness of such code is up to debate, a 
separate debate granted.

Let's assume there is working code that such a change will break.

Properly separating destruction and finalization from each 
other with the current syntax remaining as finalizers and the 
new one for destructors would allow this to be done without 
major code breakage.


Sure, in the event D would like to transition towards a state 
where the GC doesn't call finalizers, it seems useful.


From a marketing point of view having two destructors and 
keyword/syntax just for this would be hard to defend, and it 
would also need to explain the whole story.


Personally I'd be for:

~this() { /* deterministic one */ }
void finalize() { /* the one called by GC */ }

But then no transition path.

I'll defend the view point that there is _nothing_ useful to do 
in a finalizer except to check if the destructor has already been 
called.

[Issue 17695] New: [Reg 2.076] ICE with vector negation

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17695

  Issue ID: 17695
   Summary: [Reg 2.076] ICE with vector negation
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P3
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
void bug(__vector(ubyte[16]) a)
{
auto b = -a;
}
CODE
dmd -c -O bug.d

el:0x19531a0 cnt=0 const  TYunsigned char[16] 0LL+0LL 
Internal error: ddmd/backend/el.c 3034

Happens with
DMD64 D Compiler v2.075.0-master-234b414

Introduced by https://github.com/dlang/dmd/pull/7019.

--

Re: [your code here] Pure RPN calculator

[Iakh via Digitalmars-d]

On Wednesday, 26 July 2017 at 09:46:45 UTC, Timon Gehr wrote:

 readln.split.fold!((stack,op){
 switch(op){
 static foreach(c;"+-*/") case [c]:
 return stack[0..$-2]~mixin("stack[$-2] "~c~" 
stack[$-1]");

 default: return stack~op.to!real;
 }
 })((real[]).init).writeln;


What does "case [c]:" mean?

Re: Cast to subclass in the dmd compiler

[unDEFER via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 06:50:21 UTC, Jacob Carlborg wrote:
For Expression, there's a field called "op" that indicates what 
kind of expression it is, which can used in combination with a 
cast.


Thank you for hint!

Re: Destructors vs. Finalizers

[Daniel Kozak via Digitalmars-d]

@delete() {}
delete() {}

On Wed, Jul 26, 2017 at 3:08 PM, jmh530 via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> On Wednesday, 26 July 2017 at 12:55:17 UTC, Mike Parker wrote:
>
>> ---
>>> ~this() {}// Finalizer
>>> ~this() @nogc {}  // Finalizer
>>> ~this @deterministic {}   // Destructor
>>> ~this @nogc @deterministic {} // Destructor
>>> }
>>>
>>
>> Yeah, this brings with it more flexibility. I'd prefer to avoid adding a
>> new attribute for it, but this looks more interesting.
>>
>>
>>
> Some other options:
> ~~this() {}
> !this() {}
> !~this() {}
> this!(true) () {} //not really a big fan of this version
>

Re: Destructors vs. Finalizers

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 26 July 2017 at 13:54:15 UTC, Guillaume Piolat 
wrote:

On Wednesday, 26 July 2017 at 12:35:19 UTC, Mike Parker wrote:
On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat 
wrote:


I don't get the distinction between destructors and 
"finalizers" but imho the problem is very much that the GC is 
calling ~this.


Destructors are deterministic, finalizers are not. At least, 
that's how I understand the terms are commonly used.


Note that Andrei once proposed in 2014 that the GC wouldn't 
call destructors/finalizers at all:


[...]


AFAICT that was mostly because it would have broken plenty of 
existing code.
Properly separating destruction and finalization from each other 
with the current syntax remaining as finalizers and the new one 
for destructors would allow this to be done without major code 
breakage.

Re: Why can't typeof() be used in member method?

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 13:51:05 UTC, Andre Pany wrote:

How can I fix this issue?


I would just do

   typeof((new TBounds).Left) m;


so then it is clear that you want a non-static member.

dub and hierarchies of packages

[Jean-Louis Leroy via Digitalmars-d-learn]

Hi,

I am quite happy with dub, the little package manager that could 
:)


Now two questions or suggestions.

I have a package hierarchy (here 
https://github.com/jll63/openmethods.d/blob/master/dub.sdl) and I 
would like to 'dub run' or 'dub test' everything. Is there a 
recursive mode that I've missed?


Secondly, I have buildTypes that I would like to use in all the 
packages (like here 
https://github.com/jll63/openmethods.d/blob/master/tests/misc/dub.sdl#L9). I would like to avoid repeating it in every dub.sdl. I tried putting the buildTypes in the root dub.sdl and defining my subpackages there (in spite of the warning against doing that) in the hope that the buildTypes would be globally available, but no. Is there a way of making the subpackages inherit stuff from their parent? Or some sort of sdl #include or 'import'?

Re: Destructors vs. Finalizers

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 26 July 2017 at 12:35:19 UTC, Mike Parker wrote:
On Wednesday, 26 July 2017 at 12:19:15 UTC, Guillaume Piolat 
wrote:


I don't get the distinction between destructors and 
"finalizers" but imho the problem is very much that the GC is 
calling ~this.


Destructors are deterministic, finalizers are not. At least, 
that's how I understand the terms are commonly used.


Note that Andrei once proposed in 2014 that the GC wouldn't call 
destructors/finalizers at all:


http://forum.dlang.org/post/ljrm0d$28vf$1...@digitalmars.com

We're considering deprecating ~this() for classes in the future.


Instead the forum community pushed back and what has been done is 
extending the calls to GC-allocated structs.

Why can't typeof() be used in member method?

[Andre Pany via Digitalmars-d-learn]

Hi,

I try to track down why some complex logic is not working. I 
think the root issue is that typeof() is not working in member 
methods. I reduced it to following example:


app.d(16): Error: this for Left needs to be type TBounds not type 
app.A

Failed: ["dmd", "-v", "-o-", "app.d", "-I."]

class TBounds
{
@property float Left() {return 0.0;}
}

class A
{
static void test()
{
typeof(TBounds.Left) m;

}

void test2()
{
typeof(TBounds.Left) m;
}
}

void main() {}

How can I fix this issue?

Kind regards
André

Re: Get UDA of unit tests during Runtime.moduleUnitTester

[Matthew Remmel via Digitalmars-d-learn]

On Wednesday, 26 July 2017 at 06:47:20 UTC, Jacob Carlborg wrote:

On 2017-07-26 05:27, Matthew Remmel wrote:


[...]


Unless you want to go with the approach Seb suggested, using 
unit-threaded, you need to recursively iterate the module to 
get all aggregates using __traits(allMembers) then use 
__traits(getUnitTests) for each aggregate to get all unit tests.



[...]


That's not possible, the UDAs are lost after compile time. 
Also, all the unit tests block are combined into one function 
per module, which is what Runtime.moduleUnitTester is running. 
The separate unit test blocks are gone at runtime so there's 
nothing to connect the UDAs to.


Thanks for the info, I'll look into the threaded unit test 
library and see what they are doing, and how.


-Matt

Re: all OS functions should be "nothrow @trusted @nogc"

[Kagamin via Digitalmars-d]

On Wednesday, 26 July 2017 at 02:54:34 UTC, Walter Bright wrote:
* Operating system APIs grow like weeds. We'd set ourselves an 
impossible task.


It is worthwhile, however, to augment the APIs with the 
appropriate attributes like @nogc, scope, nothrow, @safe (for 
the ones that are), etc.


Given that C and OS api have no notion of memory safety, they 
don't support it and don't maintain it, so if it once was safe, 
it can be refactored later and become unsafe relying on proper 
usage of the api. Then if it was marked safe, the qualifier must 
be removed, which will be a breaking change for D code, but not 
for C code. Should we still try to mark them safe at all?

Re: all OS functions should be "nothrow @trusted @nogc"

[Kagamin via Digitalmars-d]

On Tuesday, 25 July 2017 at 18:36:35 UTC, Moritz Maxeiner wrote:

fgetc cannot be @trusted the same way fclose cannot be @trusted.
If you pass either of them `null` - which constitutes a legal 
@safe context - the behaviour is undefined, which contradicts 
@trusted definition:
exhibit any undefined behavior if called by a safe function.>


There's a less questionable problem with it.

Re: Destructors vs. Finalizers

[Steven Schveighoffer via Digitalmars-d]

On 7/26/17 8:57 AM, Mike Parker wrote:

On Wednesday, 26 July 2017 at 12:43:27 UTC, Steven Schveighoffer wrote:


Regarding the OP, I think we really should strive to have something to 
fix this issue.


A poor-mans distinction could be done by checking whether the GC is 
currently the one destroying (a flag is available, but isn't publicly 
accessible), though that could get expensive.


That's essentially what Guillaume's "GC-proof resource class" idiom does 
now.


https://p0nce.github.io/d-idioms/#GC-proof-resource-class



Yeah, I've seen that.

https://issues.dlang.org/show_bug.cgi?id=17563

-Steve

Re: Destructors vs. Finalizers

[jmh530 via Digitalmars-d]

On Wednesday, 26 July 2017 at 12:55:17 UTC, Mike Parker wrote:

---
~this() {}// Finalizer
~this() @nogc {}  // Finalizer
~this @deterministic {}   // Destructor
~this @nogc @deterministic {} // Destructor
}


Yeah, this brings with it more flexibility. I'd prefer to avoid 
adding a new attribute for it, but this looks more interesting.





Some other options:
~~this() {}
!this() {}
!~this() {}
this!(true) () {} //not really a big fan of this version

Re: Destructors vs. Finalizers

[Mike Parker via Digitalmars-d]

On Wednesday, 26 July 2017 at 12:43:27 UTC, Steven Schveighoffer 
wrote:


Regarding the OP, I think we really should strive to have 
something to fix this issue.


A poor-mans distinction could be done by checking whether the 
GC is currently the one destroying (a flag is available, but 
isn't publicly accessible), though that could get expensive.


That's essentially what Guillaume's "GC-proof resource class" 
idiom does now.


https://p0nce.github.io/d-idioms/#GC-proof-resource-class