Re: D street cred: Just a thought

[Daniel Murphy via Digitalmars-d]

On 4/03/2017 7:10 PM, Patrick Schluter wrote:

The compiler front-end did just that. I can not comment on the quality
of the code but on the speed of compilation, wow, just wow.

Building v2.067 takes 1'38" on the server at work (westmere at 2.2 GHz,
gcc 6.2, dmd v2.073, single core build).
Building v2.073 takes 0'15" and most of that time is taken by building
the backend which is still in C++.
If that were rewritten in D, I suppose building the compiler would take
2 or 3 seconds max.


Yup.  And the same exact approach would be applicable to many other 
large C++ projects.  Most would be easier than converting the D 
compiler, because a huge part of the work was perfectly matching the C++ 
ABI so the glue layer/backend could still be in C++.


I did consider trying this with some other projects but there really 
aren't any large C++ projects I work with frequently enough for this to 
be worth the time.  LLVM would probably be a good project, but without 
someone to maintain the fork and zero chance of switching upstream to D, 
there isn't much point.


It's worth noting that maintaining an automatically converted fork is 
much much less work than maintaining a manually converted fork.

Re: Building bits of D [was Andrei's list of barriers to D adoption]

[Daniel Murphy via Digitalmars-d]

On 6/06/2016 8:40 PM, Russel Winder via Digitalmars-d wrote:


Building dmd with Microsoft C++ isn't an official build. Building it
with DMC++
is, works fine, and does not depend on Microsoft tools.


But standard C++ should be compilable with any standards compliant C++
compiler. So if it C++ and compiles with DMC++ then it should compile
with MS C++.




DMD is not written in C++ any more...

Re: C++ to D converter based on clang

[Daniel Murphy via Digitalmars-d-announce]

On 1/06/2016 9:40 PM, Jacob Carlborg wrote:

Yes I could. Like I could participate to VisualD/cpp2d or magicport2
projects.


Anything that is not using a real front end is a lost cause.



Haha that really depends on your goals.

Re: DMD producing huge binaries

[Daniel Murphy via Digitalmars-d]

On 20/05/2016 12:44 AM, Andrei Alexandrescu wrote:

On 05/19/2016 10:43 AM, Steven Schveighoffer wrote:

This may be crazy, but I solved this problem by simply moving the struct
outside the function. What about a lowering that does this for you?


That's also a possibility, but likely a more complicated one. -- Andrei


We don't actually need to lower it, just mangle it as if it was lowered.

Re: Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 19/05/2016 3:50 AM, Stefan Koch wrote:

I am currently designing an IR to feed into the CTFE Evaluator.
I am aware that this could potentially make it harder to get things
merged since DMD already has the glue-layer.



It's always more difficult to justify merging more complexity.  But if 
you can present a working and superior solution the specific 
implementation is less important.  It is still important that it matches 
the existing style of the compiler, especially with respect to adding 
dependencies.


Also be aware that even with agreement on the eventual goal, it is still 
very slow to get big changes approved.  eg ddmd took more than twice as 
long as it should have.  This is why I suggested looking for incremental 
improvements, so you can overlap getting earlier things merged and 
developing later parts.  I would be on the lookout for things that can 
be justified on their own (untangling AssignExp :) ) and try to push 
those through first.

Re: Why doesn't dlang-bot use the GitHub conventions?

[Daniel Murphy via Digitalmars-d]

On 19/05/2016 3:06 AM, Jacob Carlborg wrote:

On 2016-05-18 17:05, Daniel Murphy wrote:


No, because #99 is a github pull request reference.


GitHub uses the same syntax to refer to issues and pull requests. If the
syntax works for GitHub I don't see why it can't work for us. No point
in inventing a new syntax when a lot of developers are already familiar
with the GitHub syntax.



Yes, and the numbers overlap with the bugzilla issue numbers.

So if I say '#3' it will think I mean 
https://github.com/dlang/dmd/pull/3 instead of 
https://issues.dlang.org/show_bug.cgi?id=3

Re: Why doesn't dlang-bot use the GitHub conventions?

[Daniel Murphy via Digitalmars-d]

On 19/05/2016 12:27 AM, Jacob Carlborg wrote:

Apparently dlang-bot doesn't recognize the GitHub syntax/conventions [1]
to link and close issues from pull requests. Instead one have to use
"Fix issue ...". I don't see a point in inventing new conventions for this.

Can we please have dlang-bot recognize the GitHub syntax as well?

[1] https://help.github.com/articles/closing-issues-via-commit-messages/



No, because #99 is a github pull request reference.

Re: Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 18/05/2016 9:01 AM, Martin Nowak wrote:


Yes, this
https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/dinterpret.d#L3418
is really ugly and complex, but you won't get rid of this inherent
complexity. The e2ir code for AssingExp looks almost the same
https://github.com/dlang/dmd/blob/7d00095301c4780b41addcfeb50f4743a9a6c5d4/src/e2ir.c#L2466.




IMO this is a different problem, that AssignExp is stupidly complex and 
needs to be split up.



You might imagine that it's easier to work with syntax trees than to
start from scratch but I'm certain that's not true. I'm pretty sure that
the simplest approach is to use the simplest possible
machine-independent bytecode that you can come up with. I had got to the
point of starting that, but I just couldn't face doing it in C++.


All I'm saying is that interpreting the AST to generate bytecode is
going to be as complex as interpreting the AST directly, but then you
still a bytecode interpreter and later might still want a JIT.


The bytecode generator and bytecode interpreter can be debugged (and 
tested!) independently.  So the total amount of code will increase but 
the components themselves will be better isolated and easier to work with.


I don't think a possible future need for a JIT is a good reason to avoid 
an bytecode interpreter.  A large part of the work of adding a new (JIT) 
backend is pinning down the semantics, and adding a bytecode interpreter 
will certainly help to do that.




Using dedicated value types during interpretation instead of recycling
the AST for that will also make the transitions clearer and get rid of
some of the lifetime complexities in the current code.



Meh, sure.  But this feels just as difficult as switching to a simple 
bytecode, without all the benefits.

Re: Always false float comparisons

[Daniel Murphy via Digitalmars-d]

On 16/05/2016 10:37 PM, Walter Bright wrote:

Some counter points:

1. Go uses 256 bit soft float for constant folding.



Then we should use 257 bit soft float!

Re: Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 16/05/2016 9:20 PM, Martin Nowak wrote:

On Monday, 16 May 2016 at 10:01:47 UTC, Kagamin wrote:

Wasn't it possible to enable GC for entire compiler? There can be
hybrid approach: 1) first allocate from bump heap 2) when it reaches,
say, 200MB, switch to GC.


Well, I wouldn't use D's GC for that dedicated heap.
Allocation of CTFE values are completely independent and call be freed
once the evaluation is finished.


Maybe you wouldn't, but you certainly could...

Re: Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 15/05/2016 11:25 PM, Martin Nowak wrote:

On 05/15/2016 02:17 PM, Daniel Murphy wrote:


For simple types that's true.  For more complicated reference types...

Variable indexes are not enough, you also need heap memory, but slices
and pointers (and references) can refer to values either on the heap or
the stack, and you can have a slice of a member static array of a class
on the stack, etc.  Then there are closures...


So we do need a GC or RC for arrays, structs, classes (anything
heapish). Values for those could be allocated by a simple bump/region
allocator or a dedicated allocator that support individual freeing (via
RC or GC).

In any case struct Pointer { int index; /* 2B positive values for stack,
2B negative for heap*/ } wouldn't be much more complicated than a raw
pointer (and a bit simpler to garbage collect).



The problem is, if index refers to a single variable on the stack, then 
it's insufficient to refer to a variable inside an aggregate on the 
stack.  Then you need to start building constructs for member of struct 
in array of struct pointers and it gets fairly messy...  It's all 
solvable, I'm not sure the simplicity would survive.



Neither e2ir or s2ir are actually that complex.  A lot of the mess there
comes from the backend IR interface being rather difficult to work with.


Think of a simple switch statement where you even need to introduce
relocations (or keep a list of fixup addresses) b/c you don't know the
jump addresses in advance.


This is not exactly difficult to do.


In a visitor you simply test the cases and execute the first case body.

Not to mention that we can reuse existing solutions from the current
interpreter (e.g. for gotos see
https://github.com/dlang/dmd/blob/0757504342e48e272372b7ac52cda5a333b2a2bc/src/dinterpret.d#L1014
and
https://github.com/dlang/dmd/blob/0757504342e48e272372b7ac52cda5a333b2a2bc/src/dinterpret.d#L1094).



Flow control is really not where the complexity lies IMO.  The weird 
ways in which different types of reference types can combine leads to 
either very complicated or very low level descriptions of memory.

Re: Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 15/05/2016 9:57 PM, Martin Nowak wrote:

On 05/15/2016 01:58 PM, Daniel Murphy wrote:

The biggest advantage of bytecode is not the interpreter speed, it's
that by lowering you can substitute VarExps etc with actual references
to memory without modifying the AST.

By working with something lower level than the AST, you should end up
with something much less complex and with fewer special cases.


Which is a bad assessment, you can stick variable indexes into
VarDeclaration (we already do that) and thereby access them in O(1).
Converting control flow and references into byte code is far from
trivial, we're talking about another s2ir and e2ir here.

-Martin



We really should have discussed this last week!

Re: Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 15/05/2016 9:57 PM, Martin Nowak wrote:

On 05/15/2016 01:58 PM, Daniel Murphy wrote:

The biggest advantage of bytecode is not the interpreter speed, it's
that by lowering you can substitute VarExps etc with actual references
to memory without modifying the AST.

By working with something lower level than the AST, you should end up
with something much less complex and with fewer special cases.


Which is a bad assessment, you can stick variable indexes into
VarDeclaration (we already do that) and thereby access them in O(1).
Converting control flow and references into byte code is far from
trivial, we're talking about another s2ir and e2ir here.

-Martin



For simple types that's true.  For more complicated reference types...

Variable indexes are not enough, you also need heap memory, but slices 
and pointers (and references) can refer to values either on the heap or 
the stack, and you can have a slice of a member static array of a class 
on the stack, etc.  Then there are closures...


Neither e2ir or s2ir are actually that complex.  A lot of the mess there 
comes from the backend IR interface being rather difficult to work with. 
 We can already save a big chunk of complexity by not having to 
translate the frontend types.  E.g.  implementing the logic in the 
interpreter to correctly unwind through destructors is unlikely to be 
simpler than lowering to an IR.

Re: Battle-plan for CTFE

[Daniel Murphy via Digitalmars-d-announce]

On 15/05/2016 8:29 PM, Martin Nowak wrote:


No need for a byte-code interpreter, it mostly just adds overhead and
complexity over an AST interpreter. If you want to go really fast you
need some sort of JIT anyhow, but a proper interpreter will be orders of
mangnitude faster than the current implementation.



The biggest advantage of bytecode is not the interpreter speed, it's 
that by lowering you can substitute VarExps etc with actual references 
to memory without modifying the AST.


By working with something lower level than the AST, you should end up 
with something much less complex and with fewer special cases.


The current goal is not a full JIT, just something that manages memory 
in a less insane way.

Re: Why are tests restarting in Github?

[Daniel Murphy via Digitalmars-d]

On 25/04/2016 5:44 AM, ag0aep6g wrote:

On 24.04.2016 21:26, tcak wrote:

There are 10 test. Some of them gets completed. And then, I look at it
again, tests have restarted, and less number of tests are passed at that
point.

1. What is the reason of restarts?


Something else has been pulled. That changes the code that's being
tested, so all tests need to restarted.


2. What is reason of long waiting time? Sometimes number of passed tests
stay there 2-3 days.


The pull request is probably not a priority for the auto-tester. Pull
requests that have been marked for auto-merging have priority over
others. I'm not sure, but the auto-tester may also prioritize requests
with recent activity over older ones.


Yes, if you rebase and force-push your pull will be put at the top of 
the list.

Re: [PRs] How to update on Github

[Daniel Murphy via Digitalmars-d]

On 19/04/2016 11:05 PM, tcak wrote:

On Thursday, 21 May 2015 at 10:39:46 UTC, ZombineDev wrote:

Basically you need clone your fork to your computer, add a "upstream"
remote to github.com/D-Programming-Language/[repo name, eg. phobos],
pull from upstream the new changes and optionally update github by
pushing to origin (origin normally is github).
It may sound complicated doing this from the command-line, but after a
few times you'll get used to it.


Please put this information somewhere. Due to the fear of being told to
squash commits, I do not want to do any commits anymore.


It's in the wiki.

Re: I want this so badly, please implement

[Daniel Murphy via Digitalmars-d]

On 8/04/2016 1:59 AM, Adam D. Ruppe wrote:


(I thought this would be easy but I keep hitting dmd assert failures.
However, that's probably because I'm a n00b, it probably is easy if you
know the e2ir style.)


If you have a patch I can probably point out the error.  You're right 
that it should be fairly straightforward, although you'll need to copy 
elems to temps when they're used multiple times to avoid the 
multiple-references asserts/ICEs.

Re: How my little brother try D

[Daniel Murphy via Digitalmars-d]

On 3/04/2016 9:35 PM, cym13 wrote:


To be fair I've always thought that mv is a bad name because moving
really is just renaming, there are no two separate operations. That said
I too would have searched for "move" first exactly because as misleading
as the name can be it corresponds to what the user wants to do.


Except that's not true!  Renaming doesn't (typically) work across devices.

Re: Can we check the arguments to format() at compile time?

[Daniel Murphy via Digitalmars-d]

On 2/04/2016 8:25 AM, Yuxuan Shui wrote:

Clang has this nice feature that it will warn you when you passed wrong
arguments to printf:

#include 
int main(){
 long long u = 10;
 printf("%c", u);
}

clang something.c:
something.c:4:15: warning: format specifies type 'int' but the argument
has type 'long long' [-Wformat]

With the CTFE power of D, we should be able to do the same thing when
the format string is available at compile time. Instead of throwing
exceptions at run time.


That's something I want to do with this eventually: 
https://github.com/D-Programming-Language/dmd/pull/3799


When arguments (or anything about the arguments) is known at compile 
time, some subsets of in-contracts can be checked.


Currently only stuff like this is supported:
auto iota(int low, int high) in { assert(low <= high); } body { ... }

iota(23, 7); // Error

But it's not impossible that
assert(checkFormatArgs(format, args));
could work one day.

Re: "Squash and merge" on GitHub

[Daniel Murphy via Digitalmars-d]

On 2/04/2016 7:28 AM, Vladimir Panteleev wrote:


4. We should use the autotester's auto-merge feature anyway.



Can we disable both and force everyone to use the autotester?

Re: Could we reserve void[T] for builtin set of T ?

[Daniel Murphy via Digitalmars-d]

On 1/04/2016 6:24 AM, deadalnix wrote:

Pretty much as per title. I has that in the back of my mind for a while.
Would that work ?


Don't forget that builtin AAs have been an epic disaster, and this would 
require an appalling amount of effort to implement in the compiler 
types, ctfe, druntime, new traits etc.


Phobos seems like a better place - and while not quite as concise, the 
syntax should still be pretty intuitive.

Re: DDMD: functions defined in both C++ and D

[Daniel Murphy via Digitalmars-d]

On 8/03/2016 8:42 PM, Johan Engelen wrote:

On Monday, 7 March 2016 at 22:19:46 UTC, Daniel Murphy wrote:

On 8/03/2016 7:12 AM, Johan Engelen wrote:

 or perhaps a remnant of
semi-automated C++->D conversion?


That.


:)
Out with it, then?


If it still links.  Vtbl emission can be tricky.

Re: DDMD: functions defined in both C++ and D

[Daniel Murphy via Digitalmars-d]

On 8/03/2016 7:12 AM, Johan Engelen wrote:

 or perhaps a remnant of
semi-automated C++->D conversion?


That.

Re: State of the Compiler

[Daniel Murphy via Digitalmars-d]

On 1/03/2016 7:18 AM, Jack Stouffer wrote:

On Monday, 29 February 2016 at 00:10:33 UTC, Walter Bright wrote:

5. convert back end to D.


What's the status of this? When the ddmd switch happened, Daniel Murphy
was saying that a similar transition in the back end would take about
six to eight months.



The actual conversion process is pretty straightforward.  The big issue 
is that converting would mean losing the dmc test suite which is our 
best way to test the backend.


The plan is to dump the test suite to IR, then set up a way to run the 
IR through the backend and check the output hasn't changed.  Then we can 
start actually converting to D.  I have a PR for some of this open.

Re: Running DMD tests on Windows / build requirements

[Daniel Murphy via Digitalmars-d]

On 22/02/2016 5:42 AM, Vladimir Panteleev wrote:

On Saturday, 20 February 2016 at 13:41:36 UTC, Martin Krejcirik wrote:

Dne 20. 2. 2016 v 13:40 kinke napsal(a):

You may want to have a look at
http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC#Running_the_dmd-testsuite_tests
for some tools prerequisites.


I have gnu make, but it doesn't work:

D:\prac4\dmd\test>make -f Makefile
Creating output directory: test_results
! was unexpected at this time.
make: *** [test_results/.created] Error 255


I believe you need to run the tests from a POSIX environment, e.g.
Cygwin or MSYS.

The error message indicates that it attempted to execute a command with
POSIX shell syntax using the Windows command interpreter.



I've been using my own test runner for years.  I probably should try and 
push some of this upstream at some point...


test.bat (in dmd/src)
@echo off
start runtest %*

runtest.bat (in dmd/src)
@echo off
cd ..\test
copy ..\src\dmd.exe .\
copy ..\..\phobos\phobos.lib .\
dir *.d /s/b > alltests.txt
dmd d_do_test2
d_do_test2 %*
pause
exit

And d_do_test2.d (in dmd/test) (attached)

Run like
test
or
test fast

from dmd/src

It works, mostly
module d_do_test;

import std.algorithm;
import std.array;
import std.conv;
import std.exception;
import std.file;
import std.format;
import std.process;
import std.random;
import std.regex;
import std.stdio;
import std.string;
import core.sys.posix.sys.wait;

void usage()
{
write("d_do_test   \n"
  "\n"
  "   input_dir: one of: compilable, fail_compilation, runnable\n"
  "   test_name: basename of test case to run\n"
  "   test_extension: one of: d, html, or sh\n"
  "\n"
  "   example: d_do_test runnable pi d\n"
  "\n"
  "   relevant environment variables:\n"
  "  ARGS:  set to execute all combinations of\n"
  "  REQUIRED_ARGS: arguments always passed to the compiler\n"
  "  DMD:   compiler to use, ex: ../src/dmd\n"
  "  CC:C++ compiler to use, ex: dmc, g++\n"
  "  OS:win32, win64, linux, freebsd, osx\n"
  "  RESULTS_DIR:   base directory for test results\n"
  "   windows vs non-windows portability env vars:\n"
  "  DSEP:   or /\n"
  "  SEP:   \\ or /\n"
  "  OBJ:  .obj or .o\n"
  "  EXE:  .exe or \n");
}

enum TestMode
{
COMPILE,
FAIL_COMPILE,
RUN
}

struct TestArgs
{
TestMode mode;

bool compileSeparately;
string   executeArgs;
string[] sources;
string[] cppSources;
string[] objcSources;
string   permuteArgs;
string   compileOutput;
string   gdbScript;
string   gdbMatch;
string   postScript;
string   requiredArgs;
string   requiredArgsForLink;
// reason for disabling the test (if empty, the test is not disabled)
string[] disabledPlatforms;
bool disabled;
}

struct EnvData
{
string all_args;
string dmd;
string results_dir;
string sep;
string dsep;
string obj;
string exe;
string os;
string compiler;
string ccompiler;
string model;
string required_args;
bool dobjc;
}

bool findTestParameter(string file, string token, ref string result)
{
auto tokenStart = std.string.indexOf(file, token);
if (tokenStart == -1) return false;

auto lineEndR = std.string.indexOf(file[tokenStart .. $], "\r");
auto lineEndN = std.string.indexOf(file[tokenStart .. $], "\n");
auto lineEnd  = lineEndR == -1 ?
(lineEndN == -1 ? file.length : lineEndN) :
(lineEndN == -1 ? lineEndR: min(lineEndR, lineEndN));

//writeln("found ", token, " in line: ", file.length, ", ", tokenStart, ", 
", tokenStart+lineEnd);
//writeln("found ", token, " in line: '", file[tokenStart .. 
tokenStart+lineEnd], "'");

result = strip(file[tokenStart+token.length .. tokenStart+lineEnd]);
// skips the :, if present
if (result.length > 0 && result[0] == ':')
result = strip(result[1 .. $]);

//writeln("arg: '", result, "'");

string result2;
if (findTestParameter(file[tokenStart+lineEnd..$], token, result2))
result ~= " " ~ result2;

return true;
}

bool findOutputParameter(string file, string token, out string result, string 
sep)
{
bool found = false;

while (true)
{
auto istart = std.string.indexOf(file, token);
if (istart == -1)
break;
found = true;

// skips the :, if present
if (file[istart] == ':') ++istart;

enum embed_sep = "---";
auto n = std.string.indexOf(file[istart .. $], embed_sep);

enforce(n != -1, "invalid "~token~" format");
istart += n + embed_sep.length;
while (file[istart] == '-') ++istart;
if (file[istart] == '\r') ++istart;
if (file[istart] == '\n') ++istart;

auto 

Re: Head Const

[Daniel Murphy via Digitalmars-d]

On 16/02/2016 8:29 PM, Ola Fosheim Grøstad wrote:


I agree with the principle, but not as a library function, because:

1. you want virtual functions to work out ok


virtual functions don't even need mangling.  But even if they did it 
would work just fine anyway.




2. making D more reliant on macroish string processing is not good



It's not macroish string processing, it's embedding a subset of C++ 
declarations like a DSL.  The difference is that the C++ can be fully 
type-checked and semantically analysed, errors will not leak into the 
generated source.




You would need something along the lines of:

1. «extern "C++"» the essence of the class definition in plain C++ syntax

2. add to this syntax a translation for each parameter what it means in D.


E.g.

extern "C++" {

class X {
   mutable int rc;
   virtual func1(const A* ptr); @reinterpret(ptr, head_const_ptr!A)
   virtual func2(const A* ptr); @reinterpret(ptr, const A*)
   virtual func3(A* ptr);
   virtual func4(const A* ptr); @reinterpret(ptr, const_rc!A*)
};

}



We don't 'need' compiler support beyond what we have, for any of this.

Re: Head Const

[Daniel Murphy via Digitalmars-d]

On 16/02/2016 12:04 PM, Walter Bright wrote:


It's currently difficult to interface with C++, and always will be, but
smoothing out what we can can be a big opportunity for D.



I'm starting to think we should give up on implementing C++ support in 
the language and move it to the library.


eg

mixin(cppFunctionBinding("unsigned long long NameSpace::myFunc(char * 
const && x, long double y)");


expands to some combination of pragma(mangle) and extern(C++)

With the limitation that only declarations can be parsed, it's not that 
bad to implement a ctfe C++ parser, and we can stop the creep of C++ 
features and hack into D.


As a bonus, it could generate wrappers when we really can't match the 
semantics well enough.

Re: Head Const

[Daniel Murphy via Digitalmars-d]

On 16/02/2016 9:48 AM, Walter Bright wrote:

rears its head again :-)

Head Const is what C++ has for const, i.e. it is not transitive, applies
to one level only. D has transitive const.

What head const will do for us:

1. make it easy to interface to C++ code that uses const, as currently
it is not very practical to do so, you have to resort to pragma(mangle)



I'd much rather improve pragma(mangle) than add more C++ features to D.


2. supports single assignment style of programming, even if the data is
otherwise mutable


Like 'final'?  We did get rid of that...

Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library

[Daniel Murphy via Digitalmars-d-announce]

On 9/02/2016 12:23 AM, Atila Neves wrote:

What's new:

Built-in unittest blocks can now have a name with just a string UDA:


@("test that does stuff") unittest {... }



I feel obliged to point out that this is going to be a disaster as soon 
as any other library decides that means something else.

Re: Wannabe contributor frustrations

[Daniel Murphy via Digitalmars-d]

On 12/02/2016 4:10 AM, Jonathan M Davis wrote:


IIRC, it uses 2.067 and will continue to do so until GDC and LDC have
switched to using the D version of the frontend instead of the older,
C++ version.



Most likely we will stick with 2.067 until GDC and LDC both have 2.068 
releases.  There are a couple bugs in 2.067 that affect building DMD, 
but using it as a host compiler has been fairly painless so far and I 
don't think there's any huge motivation to bump it up.

Re: Wannabe contributor frustrations

[Daniel Murphy via Digitalmars-d]

On 11/02/2016 3:37 PM, Jonathan M Davis wrote:


It's also a pain to edit. It's been suggested several times that we
change the build system (e.g. to use
https://github.com/atilaneves/reggae), but IIRC, Walter and Andrei have
generally been opposed to the idea of changing it. It's one of those
things that frequent contributors have more or less sorted out and don't
usually worry about much anymore (aside perhaps from the rare occasions
when they need to edit the makefiles), whereas it definitely tends to
bite folks who aren't familiar with it. And building the documentation
is that much worse.

Personally, I'd love to see it changed to something more maintainable,
but we'd  have to be sure that what we were switching to really was
better. As it is, I wrote a program that I use to update the source and
do builds on my machine so that building is semi-sane, and I suspect
that other contributors have done similar.



There is a non-zero possibility that we'll switch to dub eventually.

Re: Type safety could prevent nuclear war

[Daniel Murphy via Digitalmars-d]

On 5/02/2016 11:03 AM, tsbockman wrote:


The compiler cannot (in the general case) verify that `extern(C)`
declarations are *correct*. What it could do, though, is verify that
they are *consistent*.

If the same `extern(C)` symbol is declared multiple places in the D
source code for a program, the compiler should issue at least a warning
if the D signatures don't agree with each other.


Currently D allows overloading extern(C) declarations, see
https://issues.dlang.org/show_bug.cgi?id=15217

Checking for invalid overloads with non-D linkage is covered here:
https://issues.dlang.org/show_bug.cgi?id=2789

But neither of these cover overloads that aren't simultaneously visible.
15217 shows us that this lack of checking, when combined with D's 
abundant binary-compatible-but-distinct types, is somewhat useful.


Apart from some scary ABI hacks there is nothing really stopping us from 
enforcing that all non-D function in all modules included in a single 
compilation have distinct symbol names or (at least binary-compatible) 
matching D parameters.

Re: Deprecation policy

[Daniel Murphy via Digitalmars-d]

On 4/02/2016 6:25 AM, Jonathan M Davis wrote:


With regards to language features, we really don't have a policy. Some
stuff has been in the state of "we're definitely going to deprecate it"
for ages (e.g. delete and using scope on local variables) but never
actually gets deprecated, and other stuff gets deprecated but doesn't
get removed for ages. And I think that it mostly comes down to when a
compiler dev feels like making the change (and they usually don't -
probably because they have much more interesting and pressing things to
worry about).



There are other things holding up deprecated features other than lack of 
time/energy.


- Walter/Andrei have declared features deprecated for ideological 
reasons, yet they're still useful and don't have good alternatives.
- Walter/Andrei have refused or extended reasonable deprecation paths 
because they will break code


So implementing a deprecation typically means five minutes of writing a 
compiler patch, an hour of removing ancient uses from obscure druntime 
code, 12 months of waiting for review and 3 weeks of arguing with Walter 
and/or Andrei and/or anyone else who can't be bothered updating their code.


See https://issues.dlang.org/show_bug.cgi?id=4733 for why I don't bother 
any more.

Re: Type safety could prevent nuclear war

[Daniel Murphy via Digitalmars-d]

On 5/02/2016 10:07 PM, tsbockman wrote:


I think it makes sense (when actually linking to C) to allow stuff like
druntime's creative use of overloads. The signatures of the two
bsd_signal() overloads are compatible (from C's perspective), so why not?

However, multiple `extern(C)` overloads that differ in the number or
size of arguments should trigger a warning. Signed versus unsigned or
even int versus floating point is more of a gray area.



That's what I meant by binary compatible.


Overloads with conflicting pointer types should definitely be allowed,
but ideally the compiler would force them to be marked @system or
@trusted, since there is an implied unsafe cast in there somewhere.


Safety on C functions is always going to need to be hand verified, the 
presence of overloads doesn't change that.  Conflicting pointer types 
are pretty much the same as a function taking void* - all the unsafe 
stuff is on the other side and invisible to the D compiler.

Re: Vision for the first semester of 2016

[Daniel Murphy via Digitalmars-d-announce]

On 1/02/2016 8:46 AM, Iain Buclaw via Digitalmars-d-announce wrote:


I know, I've been hitting bug after bug in 2.067, and the answer has always
been to backport from 2.068.  I already have backported druntime's object.d
from 2.068 because 2.067's object module has drifted so far out of sync
with it's hidden implementation, I couldn't build anything!  So I might as
well backport the rest of the druntime library.  Nothing much has changed
as it was a "bugfix" release.



The process will be complete when you've backported the entirety of 2.068.

Re: extern(C++) multiple inheritence

[Daniel Murphy via Digitalmars-d]

On 26/01/2016 5:29 PM, Manu via Digitalmars-d wrote:


I tried to build DMD myself, doesn't build with vs2015:
https://issues.dlang.org/show_bug.cgi?id=15611

*sigh* .. everything's always so hard! It's exhausting.



Get with the times, vs2015 is so last year.

Re: Last revision of phobos and druntime that actually compile with cdmd

[Daniel Murphy via Digitalmars-d]

On 25/01/2016 2:55 AM, Benjamin Thaut wrote:

I tried using a commit which was
the same date as the cdmd -> ddmd switch but that didn't work.


That's the only way I know to do it, it should work.

Re: extern(C++, ns)

[Daniel Murphy via Digitalmars-d]

On 21/01/2016 9:15 AM, Walter Bright wrote:

On 1/20/2016 8:38 AM, Marc Schütz wrote:

IMO his description was already quite clear, but here you are:


What's missing is why this is a *serious* problem. All you've got to do
is add a qualifier.



The *serious* problem is that the added scope does not appear to add 
practical value, yet has a non-zero cost.  And yes I've seen your 
example with two same-named symbols in the same module, but I really 
don't understand why *that* is a serious problem that the namespace 
scope is worth introducing to solve.


And I am not personally arguing for D modules mapping to C++ namespaces 
- the alternative feature I have in mind is extern(C++, "namespace") 
affecting mangling and *nothing else*.

Re: extern(C++) multiple inheritence

[Daniel Murphy via Digitalmars-d]

On 19/01/2016 4:10 PM, Manu via Digitalmars-d wrote:

I'm repeating this here from the depths of my prior whinge thread,
since this is kind of a new topic.

D's multiple inheritance solution is single-inheritance + interfaces.
Rightly so, it's a great solution, and this matches what all the C++
programmers I've ever worked with do anyway. Trouble is, it doesn't
seem to work with extern(C++) at the moment.



Yeah, it never has.  No attempt has ever been made to make it work.

If you want to take a look, it's probably not much more complicated than 
fixing the layout.  The code should mostly be somewhere in todt.c (when 
ClassDeclaration::cpp is non-zero).

Re: extern(C++, ns)

[Daniel Murphy via Digitalmars-d]

On 18/01/2016 6:47 AM, Walter Bright wrote:
> On 1/17/2016 3:55 AM, Daniel Murphy wrote:
>> So now we have two public symbols called 'mylib', and because they
>> conflict they
>> can't be used to disambiguate eg 'someotherlib.funca' with
>> 'library.a.funca'.
>
> Consider these two C++ files:
>
> --file 1-
> namespace (X) { int fooa() { ... }
> --file 2-
> namespace (X) { int fooa() { ... }
> -
>
> You'll get a multiply defined symbol error for X.fooa() from the linker.
> When using namespaces in D, the "one definition rule" needs to be
> followed just as in C++ for the same reason.
>
> However, in D, you CAN do the following:
>
> -module M---
> extern (C++,X) { int fooa(); }
> -module N---
> extern  (C++,X) { int fooa(); }
> 
>
> and yes, M.X.fooa() will wind up referring to the same externally
> defined symbol X::fooa() as N.X.fooa().
>
> Because, as I said multiple times, namespaces in D affect the name
> mangling in a C++ way while doing symbol lookup in the D way.
>
> Note that
>
> extern(C) { ... }
>
> in D works EXACTLY the same way.

So Why make extern(C++, namespace) introduce a new symbol? Why not 
just let it change ONLY mangling and use modules to organize symbols and 
resolve conflicts?

Re: extern(C++, ns)

[Daniel Murphy via Digitalmars-d]

On 18/01/2016 12:19 PM, Chris Wright wrote:

On Sun, 17 Jan 2016 22:55:23 +1100, Daniel Murphy wrote:


So now we have two public symbols called 'mylib', and because they
conflict they can't be used to disambiguate eg 'someotherlib.funca' with
'library.a.funca'.


Users want to disambiguate between a use of C++ namespace members and
other values from other modules. The natural way to do this is to provide
a fully qualified D name. For instance, if I wrapped C++ type
Urho3D::Core::Context in D module urho3d.core, I'd normally refer to it
as urho3d.core.Context.

That works today. It's got no problems.

However, in your scenario, users don't want to use the D module names to
disambiguate. They want to use C++ namespaces. Why?



IMO the only reason to use C++ namespaces in D is to match mangling of a 
C++ library you want to link to.  If they just changed mangling and 
nothing else, then they would do their job just fine.

Re: extern(C++, ns)

[Daniel Murphy via Digitalmars-d]

On 19/01/2016 7:54 PM, Walter Bright wrote:

On 1/19/2016 12:42 AM, Daniel Murphy wrote:

So Why make extern(C++, namespace) introduce a new symbol? Why not
just let
it change ONLY mangling and use modules to organize symbols and
resolve conflicts?


1. Because a namespace is a scope, and is expected to act like one.



But I don't want a namespace scope, I want to bind to a symbol in a C++ 
namespace.



2. So names in different namespaces will not conflict.



They won't conflict if they're put in different modules.


3. So names in namespaces can be referenced as:

 std.exception

as one would expect.


I think the alternative of just referring to it as stdcpp.exception is 
just fine.  Or better.




As the length of this thread testifies, this has been discussed at
length already.


My summation of this thread is that very few agree with your design.  I 
recall the same thing of the thread we had before it was introduced. 
I'll admit that it's probably possible to bind to C++ libraries using 
the current feature, clumsy as it is.

Re: extern(C++) multiple inheritence

[Daniel Murphy via Digitalmars-d]

On 19/01/2016 8:04 PM, Walter Bright wrote:

On 1/19/2016 12:34 AM, Daniel Murphy wrote:

Yeah, it never has.  No attempt has ever been made to make it work.


Actually, as I recall it was made to match what DMC++ generates for Win32.



Wasn't that from before we had extern(C++) classes?  I did the 
extern(C++) single inheritance class layout but didn't touch interfaces.

Re: extern(C++, ns)

[Daniel Murphy via Digitalmars-d]

On 17/01/2016 6:09 AM, Walter Bright wrote:

On 1/16/2016 6:26 AM, Daniel Murphy wrote:

Nobody
wants conflicting symbols in a module, and nobody wants to cram all of
their C++
namespace bindings inside a single D source file to avoid getting
namespace
symbol conflicts.


D's namespace system does not suffer from those faults.


Sure it does.  Here's the situation:

I have two C++ headers in a library:

library\a.h:

namespace "mylib"
{
void funca() { ... }
}

library\b.h:

namespace "mylib"
{
void funcb() { ... }
}

I want to create D bindings and keep a similar import layout.  So I make:

module library.a;

extern(C++, mylib) void funca();

and

module library.b;

extern(C++, mylib) void funcb();

And now I have two library namespace symbols I never wanted.  I just 
wanted to mangle the same as the C++ symbols. D's module system already 
takes care of resolving conflicts.


So now we have two public symbols called 'mylib', and because they 
conflict they can't be used to disambiguate eg 'someotherlib.funca' with 
'library.a.funca'.


The only advantage of the current system I've seen presented is that you 
can now have multiple conflicting symbols in the same module.  I can see 
how that's useful in C++, but I don't think it helps _binding_ to C++ at 
all.  Or how it's worth the mess the extra symbols cause.

Re: extern(C++, ns)

[Daniel Murphy via Digitalmars-d]

On 13/01/2016 5:51 PM, Walter Bright wrote:


If you like:

 extern (C++) {
 int a;
 extern (C++,ns) {
 int a;
 }
 }

The whole point of scoped names is to be able to do this.



The whole point is meant to be linking to C++ symbols inside namespaces. 
 Nobody wants conflicting symbols in a module, and nobody wants to cram 
all of their C++ namespace bindings inside a single D source file to 
avoid getting namespace symbol conflicts.

Re: So... let's document dmd

[Daniel Murphy via Digitalmars-d]

On 17/01/2016 2:29 AM, Joakim wrote:


While this would all be nice in principle, the reality is that dmd is
mostly worked on by two people these days
(https://github.com/D-Programming-Language/dmd/graphs/contributors) and
they're unlikely to refactor ddmd to put forth a libdmd.  It will depend
on someone caring enough to take it up, as Daniel did with the port of
the frontend to D.  As tsbockman said, I don't think we're at the stage
where anybody will put in that much effort into this.


I've already spent a huge amount of time on refactoring the frontend, 
there's just so much more to do.  More important than allowing new 
third-party uses of the frontend, is that well defined interfaces will 
make maintaining GDC and LDC less tricky.  Having to maintain a stable 
API would probably hurt more than it helps at this point.

Re: Reset all Members of a Aggregate Instance

[Daniel Murphy via Digitalmars-d-learn]

On 4/12/2015 8:38 AM, Chris Wright wrote:

An object reference is just a pointer, but we can't directly cast it. So
we make a pointer to it and cast that; the type system allows it. Now we
can access the data that the object reference refers to directly.


Casting is fine too: cast(void*)classRef

Re: Can someone check this on win32 ?

[Daniel Murphy via Digitalmars-d-learn]

On 21/11/2015 10:46 PM, BBaz wrote:

Seems to be fixed:

__
import std.math;
void main() {real function(real) c = }
__


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

At least it works on linux x86_64.




It works because of 
https://github.com/D-Programming-Language/phobos/pull/3599


But it only works for the std.math intrinsics, there are plenty of 
others without real bodies.

Re: Something about Chinese Disorder Code

[Daniel Murphy via Digitalmars-d-learn]

On 25/11/2015 2:16 PM, Rikki Cattermole wrote:

On 25/11/15 1:47 AM, Meta wrote:

I'm pretty sure you can just do:

wstring text = "my string";

Or

auto text = "my string"w;


The second one is correct yes.
I'm just assuming that it isn't compiled into the executable.


Either is fine.  Non-suffixed string literals have a default type of 
string, but implicitly convert to wstring/dstring at compile time.

Re: extern(C++, NS)

[Daniel Murphy via Digitalmars-d]

On 30/11/2015 10:42 PM, Manu via Digitalmars-d wrote:
>

Exactly, the D module system would still be in place. Assuming they
were in defferent modules, then the D module system would keep them
out of conflict naturally, with rules identical to the normal D rules.
I imagined this; C++ namespace is for mangling, D module is for
scoping. That's not how it seems to be, so my intuition was dead
wrong, but my weekend's experience has convinced me it would be better
how I initially intuited. Thing is, we're presenting a C++ API to D,
so we want to present it in D's terms, that is, the API is distributed
among D modules in a way that makes sense to a D user. I don't want to
present the API in C++ terms, and it's not even practical; stuffing
the entire C++ API into a single D module is crazy. In the cases I'm
interested in, the C++ API is possibly larger than the entire D
codebase that's attached to it.



You're not the only one who thought it should be that way.

Re: I hate new DUB config format

[Daniel Murphy via Digitalmars-d]

On 26/11/2015 6:45 PM, Jacob Carlborg wrote:

On 2015-11-25 20:02, Walter Bright wrote:


Note 2: I intend to migrate the dmd.conf file format to json.


What's the gain here compared to the breakage it will cause?



We get to delete the non-boost INI parser from the frontend!

Re: I hate new DUB config format

[Daniel Murphy via Digitalmars-d]

On 27/11/2015 1:37 AM, Jacob Carlborg wrote:

On 2015-11-26 12:47, Daniel Murphy wrote:


We get to delete the non-boost INI parser from the frontend!


How much trouble is that causing?



None, it just annoys me.

Re: C++ to add import, module and export

[Daniel Murphy via Digitalmars-d]

On 25/11/2015 11:53 AM, deadalnix wrote:

On Tuesday, 24 November 2015 at 23:14:28 UTC, deadalnix wrote:

According to this:
https://www.youtube.com/watch?v=RwdQA0pGWa4

There are plan to add these keyword in C++'s module system.


Also, this module representation may be an opportunity for us to compile
D to something a C++ compiler can digest (maybe ?).



For what purpose?

Re: New __traits

[Daniel Murphy via Digitalmars-d]

On 25/11/2015 12:06 PM, BLM768 wrote:

For a project I've been working on, I found that it would be helpful to
have a way to determine whether a symbol represents a module or package.
Since I couldn't find an easy way to do it, I forked DMD and made some
tweaks. ;)

Anyway, I uncovered an interesting issue. According to my test program
(https://gist.github.com/blm768/42f40aa5a0c49bb8bd16), these are the
"types" of various packages/modules in Phobos:
std:
std.stdio: package, module
std.algorithm: package
std.digest: package

In other words, "std" isn't a package _or_ module, and std.stdio is both
(even though it's just a single D source file). This doesn't seem quite
right.

There could be an error in my patch to DMD, but I don't see where it
could be because it's so simple. The code is at
https://github.com/blm768/dmd/tree/new_traits if anyone wants to look
over it.

If anyone can help me figure out what's going on, I'd greatly appreciate
it.


What you're seeing is just an artifact of how dmd's internals work. 
'std' is an 'import' (call Dsymbol.kind() for the category of symbol) 
and you'll have to resolve it to work out which module/package is being 
imported.  It's possible that this is a bug in the symbol resolution, 
and that it should have already been resolved to a package.


Keep in mind also that isPackage and isModule are RTTI functions, and 
since Module inherits from Package all modules will appear to be 
packages if that's all you check.

Re: New __traits

[Daniel Murphy via Digitalmars-d]

On 26/11/2015 9:33 AM, BLM768 wrote:

On Wednesday, 25 November 2015 at 15:39:17 UTC, Daniel Murphy wrote:

What you're seeing is just an artifact of how dmd's internals work.
'std' is an 'import' (call Dsymbol.kind() for the category of symbol)
and you'll have to resolve it to work out which module/package is
being imported.  It's possible that this is a bug in the symbol
resolution, and that it should have already been resolved to a package.


It seems that I can resolve the import by using "theImport.pkg", but I'm
not sure if it's the "correct" way. It works in my tests, though. Is
that the right way to do it, or is there a better method?




Unfortunately I have no idea.  You'll have to have a look at what other 
code that resolves packages is doing.


If you can't find it it might be worth emailing Kenji Hara, since he 
knows everything.

Re: I have this game engine...

[Daniel Murphy via Digitalmars-d]

On 4/11/2015 7:09 PM, Iain Buclaw via Digitalmars-d wrote:


I'm aware of this, not because I take an interest, but because I was cc'd
into discussion when they discovered a C++ regression that was seen by
comparing the md5sum of (D frontend) interpret.c sources between 2nd and
3rd generation bootstrapped builds.  ;-)



That's awesome!

Re: why to (not) support "older" compiler versions

[Daniel Murphy via Digitalmars-d]

On 4/11/2015 3:12 AM, Johannes Pfau wrote:


A crazy idea:
Once gdc supports the latest frontend version we could theoretically
adjust the dmd pull request testing to also merge dmd pull requests
into the gdc frontend and test gdc with these frontend-only requests. We
would then only merge dmd pull requests that build for gdc as well. Then
we would need some hooks to also automatically pull these into gdc. Or
we could setup the frontend as a submodule.




It's not a crazy idea at all.  The problem is that we will need to get 
the compilers in sync first, and I'm not sure that's getting any closer 
to being reality.


I think the number of pull requests touching the glue layer is low 
enough that it would work, once the CI system is set up to enforce it.

Re: Our template emission strategy is broken

[Daniel Murphy via Digitalmars-d]

On 13/11/2015 8:26 PM, Robert burner Schadek wrote:

On Friday, 13 November 2015 at 02:50:07 UTC, Daniel Murphy wrote:

You also need to modify root/rmem.d to actually use the GC as the
allocator.


I should have known that it couldn't be that simple. Anyway, after doing
so. Building druntime and phobos die with a segfault, but all dmd tests
pass, except runnable/arrayop.d

Furthermore, I had to create a function called:

 extern (C) void* allocmemory(size_t m_size) {
 return GC.malloc(m_size);
 }




Yep, that sounds about right.  It's probably just some malloced memory 
being used to store GC pointers, somewhere in there.

Re: Our template emission strategy is broken

[Daniel Murphy via Digitalmars-d]

On 12/11/2015 10:44 AM, Robert burner Schadek wrote:


I just run make -f posix.mak unittest -j10 on phobos after removing
GC.disable() from ddmd. It worked just fine. Everything build everything
passed the tests.

(the time program told 1:41.25 for nogc and 1:49.80 with gc. This is
with running all the tests.)

Shouldn't we at least add a command line switch to dmd to activate the GC.


You also need to modify root/rmem.d to actually use the GC as the allocator.

Re: Release D 2.069.0

[Daniel Murphy via Digitalmars-d-announce]

On 9/11/2015 10:25 AM, Jack Stouffer wrote:


Is there any reason why this isn't currently used in the front end?


Lack of testing, focus on matching c-dmd performance, it used to be 
blocked and nobody realized it wasn't any more etc.

Re: Release D 2.069.0

[Daniel Murphy via Digitalmars-d-announce]

On 8/11/2015 1:41 AM, Dmitry Olshansky wrote:


IMHO enabling D's GC in the frontend is better way to fix leaking in the
CTFE, but there are some issues with that (it segfaults if we enable GC).



Actually I think it's fixed now, just disabled.

It used to have problems with lib*/scan*, but those are in D now, and 
most of the allocations from the glue layer are being forwarded to the 
GC through rmem.


If anyone wants to try it they just need to add -version=GC to the DMD 
build flags and insert this function in root/rmem.d's version(GC) block.



extern (C) void* allocmemory(size_t m_size)
{
return GC.malloc(m_size);
}

Re: Is D so powerfull ??

[Daniel Murphy via Digitalmars-d]

On 9/11/2015 4:26 PM, Jeremy DeHaan wrote:


What is the correct way to use C++ class instances in D? Can you by
chance give an example?


extern (C++) class X
{
...
}

extern (C++) void func(X x);

void main(string[] args)
{
func(new X());
}

etc

Re: Is D so powerfull ??

[Daniel Murphy via Digitalmars-d]

On 9/11/2015 5:54 PM, Jeremy DeHaan wrote:



Didn't you say constructors and destructors are missing? What should
one do in those cases?


Constructors and destructors do not match the C++ ABI, but they are 
still generated, so they can only be called from the language they were 
written in.  So if you write your classes in D you must new and delete 
(or GC) them from D.  You can still create them from C++ (or create 
C++-written classes from D) if you use a forwarding function:


X makeX() { return new X(); }



Additionally, should we use new in this case? Wouldn't new create a
pointer to a C++ class? Or does it work differently for extern(c++)
classes?


New in D will allocate a class instance on the GC heap and return a 
reference to it, just like when it's used with D classes.


These two functions have the same ABI:

// D

extern(C++) class X {}

extern(C++) void func(X x);

// C++

class X {}

void func(X *x);


You can find several examples of C++ interop in dmd's test\runnable\cppa.d

Re: Is D so powerfull ??

[Daniel Murphy via Digitalmars-d]

On 9/11/2015 4:05 PM, Jeremy DeHaan wrote:



Because that's what this page says:
http://dlang.org/cpp_interface.html



That page is out of date.  Virtual and non-virtual member functions, 
static member functions, and free functions all work since ~2.066.


The biggest missing thing is special member functions, ie 
ctor/dtor/operators.


> Declaring it as a struct in D code is freaking genius. I wonder if
> that works across the board with other compilers and OS's though.

Mixing struct/class will only work properly with ABIs that mangle them 
the same way, so it's not portable.

Re: why to (not) support "older" compiler versions

[Daniel Murphy via Digitalmars-d]

On 3/11/2015 7:52 PM, drug wrote:

On 03.11.2015 11:22, Johannes Pfau wrote:


I guess it's to be compatible with the latest DMD, LDC and GDC. GDC
currently only provides the 2.066.1 frontend.


A bit offtopic - will the situation change with ddmd accepted? I mean
the situation with different frontend version in different compilers.


While DDMD does not have any direct effect on our ability to keep the 
three compilers synced, some of the cleanup work that has been done does 
help.

Re: #ifdef hell

[Daniel Murphy via Digitalmars-d]

On 31/10/2015 12:01 AM, Jacob Carlborg wrote:

On 2015-10-30 03:01, Walter Bright wrote:


I might add that over time, I'd been removing #if's and #ifdef's from
the dmd front end source code. The results were very satisfactory - the
code was easier to read, understand and maintain. It also made running
magicport on the code practical.


The DMD source code contained #ifdef's inside expressions, which is
quite a difference compared to "or" and "and" in "static if".



Yes, this was the major problem with converting the #ifdefs, not 
conditions ||ed together.  If D allowed oring versions together then 
version would have been a lot more useful in DDMD.

Re: Fixing spurious "statement is not reachable" in template code

[Daniel Murphy via Digitalmars-d]

On 28/10/2015 4:29 PM, tsbockman wrote:


I would say none, since *the template* contains no unreachable code, and
the compiler can easily trim unreachable code from any *instantiation*
which needs it, without bothering me about it.


If it's unreachable or not depends on what the template is instantiated 
with, there is no clear concept of unreachable code without knowing the 
template parameters.


bool func(T)(T value) if (isUnsigned!T)
{
if (value < 0)
return true;
return false;
}

Here the first return is definitely dead code for any instantiation, but 
to know this the compiler would have to reverse-engineer properties from 
the template constraints, which is not generally possible.




I would only be interested in a warning if the compiler wasn't able to
trim the dead code, but as far as I can tell the only case in which the
compiler doesn't trim it, is the case where it doesn't realize it's
unreachable - in which case it can't warn me, either.


Well of course...


It's not intended as a simplification for people who can't handle the
true complexity of templates - the difference is philosophical. It's a
recognition of the fundamental unity of run-time and compile-time
computation, the same idea which motivates CTFE.


IIRC it's intended to avoid scaring people off reading TDPL by avoiding 
the work 'template'.



If most people actually *want* these warnings, then great - there's no bug.
But, if most find the warnings conflict with how they want to use
templates, as I do - why not just change it?


I don't want these warnings, so I don't generally build with warnings 
enabled.



The "reality" of D templates is whatever the D community chooses to make
it, subject to technical feasibility.


As one of the core compiler devs, I'm saying it sounds infeasible.  I 
don't think either of your suggested solutions are implementable. 
Templates just do not work that way.


> 1. Defer "not reachable" warnings until compilation has been
> completed, and only issue the warning if *all* instantiations of the
> statement were unreachable.

The exact set of instantiations depends on the current module being 
compiled, so module A can still get an unreachable code warning even if 
in an instantiation from module B the code is reachable.


> 2. For semantic analysis purposes, first instantiate each template
> using dummy parameters with the widest possible VRP ranges. Only
> statements found to be "not reachable" in this dummy run should
> actually generate warnings.

Will not work with compile-time introspection.

In some trivial cases code can be found to be unreachable without doing 
semantic analysis, and therefore can be done before template 
instantiation.  Being limited, I doubt this is of much value.

Re: Fixing spurious "statement is not reachable" in template code

[Daniel Murphy via Digitalmars-d]

On 28/10/2015 4:02 PM, tsbockman wrote:

(But not all control flow statements have static equivalents, so this
solution can only be applied to some code. Even if we had `static
switch`, `static foreach`, `static goto`, etc., I doubt that forcing the
user to segregate all compile-time logic from the run-time logic in that
way is desirable.)


Nobody is forcing anyone to do this.  Warnings are opt-in.


Whether the logic is explicitly `static` (compile time) or not, the
warning should be issued if and only if the flagged code is unreachable
with all possible input combinations - including both compile-time and
run-time.


In D's compilation model it is not possible to know all possible 
instantiations at compilation time.

Re: Fixing spurious "statement is not reachable" in template code

[Daniel Murphy via Digitalmars-d]

On 25/10/2015 4:25 AM, tsbockman wrote:

///
module main;

import std.stdio;

void reachIf(bool x)()
{
 if(!x)
 return;
 writeln("reached"); // Warning: statement is not reachable
}

void main(string[] args) {
 reachIf!true();  // prints "reached"
 reachIf!false(); // triggers warning
}
///






Thoughts?


Easy to fix:

void reachIf(bool x)()
{
 static if(!x)
 return;
 else
 writeln("reached");
}

The warning is correct, and incredibly annoying.

Re: Fixing spurious "statement is not reachable" in template code

[Daniel Murphy via Digitalmars-d]

On 28/10/2015 8:29 AM, tsbockman wrote:

On Tuesday, 27 October 2015 at 21:14:26 UTC, Timon Gehr wrote:

On 10/27/2015 09:18 PM, tsbockman wrote:

I don't think any dead code is being generated,


This seems to be a misunderstanding. I mean generated using mixins or
template instantiation. Sure, it will usually be removed, but why
generate and semantically analyze it in the first place.


Forcing me to add `static if`s with redundant and potentially complex
predicates just to make my code do the exact same thing it would have
done anyway is a violation of "Don't Repeat Yourself", with all of the
usual consequences:

* The more places the same logic is expressed, the more chances I have
to get it wrong and cause a bug.

* Even if I get it right the first time, a redundant predicate could get
out of sync with the rest of the code later, causing a bug.

* It's a waste of my time, which is more valuable than my computer's time.

* It clutters up the code with statements which add little (useful)
information.



I personally like the style of that code, and agree that it allows less 
repetition.  But it does this at the cost of intentionally introducing 
dead code in some instantiations.  If you enable the compiler warnings 
about dead code, they have to trigger here because it doesn't know if 
you introduced dead code intentionally or not.  As is often the case 
with warnings, if you want your code to compile with them you sometimes 
need to avoid otherwise completely valid constructs.


Here's a similar example:

bool func(T, T val)()
{
if (val < 0)
return true;
return false;
}

func!(uint, 7);
func!(int, 7);

When instantiated with uint, the first return is unreachable because 
unsigned numbers cannot be negative.  When val == 7, it's also 
unreachable because 7 is not less than 0.  Which instantiations should 
give the warning?


> Another perspective, though, which I picked up from someone (Andrei
> Alexandrescu, I think?) in the D community, is to consider template
> parameters simply as additional function arguments, which happen to
> be evaluated at compile time. In many cases, the timing of their
> evaluation is just an implementation detail - a performance
> optimization (or de-optimization, as the case may be).

This is a great way to learn how to use templates, but there are limits 
to how well this simplification corresponds to reality and this is one 
of them.  Parameters inhibit optimizations and analysis in ways that 
compile-time constants do not.

Re: Purity of std.conv.to!string

[Daniel Murphy via Digitalmars-d-learn]

On 27/09/2015 3:14 AM, cym13 wrote:

On Saturday, 26 September 2015 at 17:08:00 UTC, Nordlöw wrote:

Why is the following code not pure:

float x = 3.14;
import std.conv : to;
auto y = x.to!string;


???

Is there a reason for it not being pure? If not, this is a serious
problem as this is such a fundamental function.


Probably because it uses C's float formatting functions, and they 
probably set errno and therefore aren't pure.




Maybe because of floating point numbers uncertainty that would cause the
resulting string to be different for two equivalent inputs? I can't seem
to put an example together though.


No, it doesn't work like that.

Re: Magicport - where it is ?

[Daniel Murphy via Digitalmars-d]

On 14/09/2015 7:24 PM, Temtaime wrote:

Hi !
I wonder if there's a repo with magicport that was used to convert dmd.
I have a big library written in C++ and wanna try convert it to D.
Or is magicport closed and there's no chance to get it ?

Thanks for a reply.


The latest version of magicport is in the dmd repo history, right before 
it was deleted.


https://github.com/D-Programming-Language/dmd/tree/last-cdmd

Good luck with your conversion!

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

On 8/09/2015 1:54 AM, "Luís Marques   wrote:

On Friday, 4 September 2015 at 12:38:41 UTC, Daniel Murphy wrote:

It's not that phobos is bad, it's that we're following the same
development pattern we had with C++.  We're using a conservative
subset of D features and libraries, and slowly expanding what's
acceptable. For example, DMD now uses foreach and delegates in a few
places, and I expect we'll see a lot of use of D strings in the near
future.


Is there any place where this is documented? For instance, what D
constructs are currently allowed, whether/which phobos imports have
started to be accepted, and so on?


No.

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

On 6/09/2015 2:47 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
 wrote:


But you are going to do high level refactoring too, right? Not just
local conversions into foreachs and the like?



Of course.  Some of this was been started before the conversion.

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

On 2/09/2015 11:23 PM, Rory McGuire via Digitalmars-d-announce wrote:

Surely if the dog food is so bad no one should be eating?


It's not that phobos is bad, it's that we're following the same 
development pattern we had with C++.  We're using a conservative subset 
of D features and libraries, and slowly expanding what's acceptable. 
For example, DMD now uses foreach and delegates in a few places, and I 
expect we'll see a lot of use of D strings in the near future.

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

On 1/09/2015 11:57 PM, Rory McGuire via Digitalmars-d-announce wrote:

Surely this is a code coverage issue then?
Are there any unit tests  in ddmd?


There is an enormous test suite, but there are also plenty of parts with 
zero coverage.

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Iain Buclaw via Digitalmars-d-announce 
digitalmars-d-announce@puremagic.com wrote in message 
news:mailman.640.1440835567.13986.digitalmars-d-annou...@puremagic.com...


 I'm planning to generate the C++ headers from the D source rather than 
 maintain them by hand.


You could use UDAs for that!


How?

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Iain Buclaw via Digitalmars-d-announce 
digitalmars-d-announce@puremagic.com wrote in message 
news:mailman.647.1440844869.13986.digitalmars-d-annou...@puremagic.com...


Just an idea to selectively @tag any classes or functions you want to 
export to C++, then let the
conversion tool do the rest.  This is as opposed to going back to some 
sort of magicport.json format

maintained outside the normal sources.


I'm just planning to implement this in dmd and have it dump out all 
extern(C++) declarations. (and structs and constants) 

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Jacob Carlborg  wrote in message news:mrsigg$1574$1...@digitalmars.com...

I'm pretty sure we already have a tool that generates C/C++ headers for D 
modules.


Adam started one, I don't think it got to the point where it would work for 
this, and I don't agree that the json output is a good way to do it. 

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Johannes Pfau  wrote in message news:mrp3m1$184s$1...@digitalmars.com...


Current GDC master can compile DDMD, although it uses the 2.066.1
frontend. Iain backported the relevant C++ mangle changes:

https://github.com/D-Programming-Language/dmd/pull/4957


Yeah, I guess the more accurate statement is that DDMD relies on some fixes 
that are not in DMD 2.066.  At some point we will probably start relying on 
bug fixes or features that aren't available before 2.067 in any compiler. 

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Iain Buclaw via Digitalmars-d-announce 
digitalmars-d-announce@puremagic.com wrote in message 
news:mailman.598.1440753894.13986.digitalmars-d-annou...@puremagic.com...


Best to start using GDC in the CI development of DMD now though so we 
catch them when it

happens!


I've played the 'upgrade the autotester' game before, and I'm not in a hurry 
to go again.


But yes I absolutely agree that should happen. 

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Luís Marques  wrote in message 
news:fnhnundiapulkyqmi...@forum.dlang.org...


Probably not all of them, though, no? For instance, utf.h is not needed by 
the GDC / LDC glue code, is it?


We don't have a policy on this yet.  It won't matter so much if we can 
auto-generate the headers. 

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Luís Marques  wrote in message 
news:ckyiqzpchfahzfjmm...@forum.dlang.org...


What is the relation between the .h files that were left intact, and the 
backend, GDC, and LDC? When the backend is converted to D, will the DMD 
source drop the C++ header files, or will (some?) of those be left behind 
because GDC and LDC will always use some C++ interfaces in their glue 
code?


The frontend header files will need to stay intact, and GDC/LDC will 
continue to use them.  All the backend header files can be deleted once the 
backend has been converted.


I'm planning to generate the C++ headers from the D source rather than 
maintain them by hand. 

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Bruno Medeiros  wrote in message news:mrn30f$26ff$2...@digitalmars.com...


Cool stuff!


Yeah!

What's the plan going forward, for those not so much up to date with 
what's going on? Is the next major release of DMD gonna be D-DMD based 
then? Which compiler is going to be used to compile D-DMD?


The next major release (2.069) will use the D-based frontend.  We're 
planning to use GDC and/or LDC releases based on the 2.067 frontend to 
compile DMD on most platforms. 

Re: DMD git HEAD now self-hosting

[Daniel Murphy via Digitalmars-d]

H. S. Teoh via Digitalmars-d  wrote in message 
news:mailman.579.1440708229.13986.digitalmar...@puremagic.com...



I'm surprised nobody has mentioned this on the forum yet, but as of 23
Aug, dmd git HEAD has switched over to ddmd with the landmark commit
88ec9d8.  Since that time, the remaining C++ files have been slowly but
surely phased out one by one, replaced with their D equivalents.

This is awesome news I think a celebration is in order. ;-)


We've been celebrating without you on the announce list!



As of today, there are still about 28 or so C++ files left (84 source
files are now in D). PRs converting C++ sources to D continue to trickle
in.

Way to go, D!


Unfortunately it's going to slow down for a little while.  The files I've 
done post-switch were only left in C++ because they used a small part of the 
backend headers and were easier to do by hand instead of converting 
automatically.  The rest of the glue layer/backend (~90 c++ files) is going 
to need a conversion project of the same scale as the frontend one, preceded 
by a refactoring project 10 times the size of the frontend one.


Walter's recent backend cleanup PRs are working on this, and I'm working on 
a backend test suite to make refactoring safer.


We could see DMD be 100% D within six months, depending on how much free 
time I have and how picky Walter is about my refactoring PRs. 

Re: dmd codegen improvements

[Daniel Murphy via Digitalmars-d]

John Colvin  wrote in message news:qlbnpjnizwpslrdpk...@forum.dlang.org...

I think he's saying that the argument: Don't work on DMD because it's 
already far behind could have been applied to working on LLVM when it was 
far behind GCC.  I don't agree, but I think that's what he means.


It helps that LLVM has a superior license. 

Re: DMD git HEAD now self-hosting

[Daniel Murphy via Digitalmars-d]

bitwise  wrote in message news:ydbofgjkddszxedpw...@forum.dlang.org...


So.. looking through the source, I see lots of this:

extern (C++) class { ... }

Wasn't extern(C++) only supposed to work on interfaces?
Are the docs outdated?


Yup.  extern(C++) works with almost everything except special member 
functions. 

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

BBasile  wrote in message news:rljvemqjfvnnqqnnc...@forum.dlang.org...

Excellent. I guess it's also time to clean the wiki page that explained 
how to build under win32 with DMC. It's obsolete now.


Nope!  The glue layer and backend are still in C++, and still need to be 
built with DMC.

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Mike  wrote in message news:hkyvytmqbstkelkum...@forum.dlang.org...

There are still a number of .h files in the front end.  What will happen 
with those?  Do they need to be maintained?


For now they must be maintained by hand, if there is any possibility of the 
glue layers or backends needing them.  In the future we will hopefully 
auto-generate them. 

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Joakim  wrote in message news:sfhycfhmabpfxxuxn...@forum.dlang.org...

Great work, thanks to Daniel and others who helped out, can't wait to use 
ddmd and see all the changes that come with it in the next couple 
releases.


I can't wait to use foreach internally!  No more manual for loops!

Can we look forward to a complete ddmd, ie backend and everything ported 
to D too, anytime soon?


I've started on the glue layer, and most of that should be done soon, but 
the backend brings a bunch of complications:

- The code style is nothing like the frontend
- It makes heavy use of the preprocessor
- We don't have a good way of testing it, which makes refactoring risky

My current plan is to create a nice text form of the backend's IR, then 
convert DMC's test suite to this format, with before and after snapshots.  I 
can then feed these tests through DMD's backend (no need for a C++ frontend 
any more) to check for regressions, letting me start modernizing the code 
and converting it to D.


This is going to take a while. 

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

BBasile  wrote in message news:fmoabuqgvlztgmqyj...@forum.dlang.org...

By the way, currently under win32 it's not possible to build DDMD unless 
the line


---
#HOST_DC=dmd
---

is uncommented. Because there is a bunch of commands using dmd compile and 
run (-run) in win32.mak. Is it a bug ? Maybe I miss out a step to 
bootstrap ?


The missing step is to set HOST_DC in the environment.

My current HOST_DC is
c:\d\dmd2.067beta\windows\bin\dmd.exe -conf=c:\d\dmd2.067beta\windows\bin\sc.ini

Re: D-Day for DMD is today!

[Daniel Murphy via Digitalmars-d-announce]

Dicebot  wrote in message news:jdgpeyxvdltshldnf...@forum.dlang.org... 


Great!

Daniel, does that mean that I can remove DDMD testing job from my 
CI? :)


Yes, thanks!

Re: extern opaque struct

[Daniel Murphy via Digitalmars-d]

John Colvin  wrote in message news:uhpgjffttsuqeswyj...@forum.dlang.org...


Let's say I have some C headers that have code like this in:

extern struct UndeclaredStruct blah;
Undeclared *p = blah;

which would naïvely translate to D as:

struct UndeclaredStruct;
extern UndeclaredStruct blah;
auto p = blah;

which doesn't compile. Why not? Neither the size nor any default 
initialiser is needed.


It should work, please file in bugzilla. 

Re: force inline/not-inline

[Daniel Murphy via Digitalmars-d]

Steven Schveighoffer  wrote in message 
news:mp86be$8f2$1...@digitalmars.com...


the only thing I can thing of is that true/false are (or have the 
potential to be in this context) expressions, which means one could use 
compile-time logic to specify inlining. The same wouldn't be true of 
arbitrary identifiers.


That's why the proposal was for strings, not arbitrary identifiers. 

Re: force inline/not-inline

[Daniel Murphy via Digitalmars-d]

tcak  wrote in message news:psflpqqpsukpfgpzh...@forum.dlang.org... 


Why not like pragma(inline, [try | force | no]) ?


Walter liked the boolean version, which is certainly better than nothing.

Re: version: multiple conditions

[Daniel Murphy via Digitalmars-d]

Walter Bright  wrote in message news:mloslo$1o7v$1...@digitalmars.com...

I have yet to see a single case of needing boolean versions that could 
not be refactored into something much more readable and maintainable that 
did not use such.


Over time, I've gotten rid of most of that stuff from the dmd source code, 
and the result has been quite pleasing.


Walter, how about a compromise?

If we allow setting versions to boolean expression then it becomes much 
easier to use it the way you suggest, while still requiring a (hopefully) 
sensible name and discouraging making a mess.


eg

version(A)
{
  version(B)
  {
  }
  else
  {
 version=NeedsSomeCode;
  }
}

becomes

version NeedsSomeCode = A  !B

An example from real code would be

version valistIsCharPointer = (Linux  LP32) || Windows;

This pattern does appear frequently in your compiler code, are you for or 
against seeing it in D? 

Re: version: multiple conditions

[Daniel Murphy via Digitalmars-d]

Walter Bright  wrote in message news:mloslo$1o7v$1...@digitalmars.com...

I have yet to see a single case of needing boolean versions that could 
not be refactored into something much more readable and maintainable that 
did not use such.


Over time, I've gotten rid of most of that stuff from the dmd source code, 
and the result has been quite pleasing.


The numerous remaining cases in dmd are why ddmd uses static if instead of 
version.  It's almost always easier to just use the more powerful 'static 
if' than to refactor the code to use D's crippled 'version'.  Keeping this 
feature simple and limited just pushes the complexity into user code. 

Re: version: multiple conditions

[Daniel Murphy via Digitalmars-d]

Walter Bright  wrote in message news:mlorvv$1nb6$1...@digitalmars.com...


On 6/14/2015 9:53 AM, bitwise wrote:
 What if I need AndroidOrWP8, and I
 also need Win32OrWin64? This can quickly become a much larger pita.

If you need those, the design is wrong. It is better to think about what 
the code is trying to do with Android or WP8, and label *that* a version.


This works well until the code that needs to be versioned is split over many 
source files, and now each one needs to duplicate the version setting code. 

Re: Allow deprecated to accept more than string literals while parsing

[Daniel Murphy via Digitalmars-d]

Dicebot  wrote in message news:odfsgqcftykjkztsg...@forum.dlang.org...

Is there any reason to not allow argument to be any expression and reject 
non-string ones at semantic phase?


The original reason is that trying to reference manifest constants etc from 
that context resulted in forward reference errors, so allowing only string 
literals was easier.  I'm guessing those problems have since been fixed, so 
allowing any ct expression that resolves to a string should be fine now. 

Re: Evaluation order of index expressions

[Daniel Murphy via Digitalmars-d]

Andrei Alexandrescu  wrote in message news:mjvlv5$vch$1...@digitalmars.com...


 which one is correct?

GDC. -- Andrei


I don't think it matters too much if we pick strict LTR, or keep dmd's 
existing exception for assign expressions.  IIRC Walter is in favour of 
keeping the exception[1].


Could you and Walter please come to an agreement and confirm here?  It 
should be fairly straightforward to get this fixed once it's clear which way 
it should go.


[1] 
https://github.com/D-Programming-Language/dmd/pull/4035#issuecomment-58861231