Re: Battle-plan for CTFE

2016-05-09 Thread Andrei Alexandrescu via Digitalmars-d-announce 

On 5/9/16 7:57 PM, Stefan Koch wrote:

Hi Guys,

I have been looking into the DMD now to see what I can do about CTFE.
Unfortunately It is a pretty big mess to untangle.
Code responsible for CTFE is in at least 3 files.
[dinterpret.d, ctfeexpr.d, constfold.d]
I was shocked to discover that the PowExpression actually depends on
phobos! (depending on the exact codePath it may or may not compile...)
which let to me prematurely stating that it worked at ctfe
[http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org]

My Plan is as follows.

Add a new file for my ctfe-interpreter and update it gradually to take
more and more of the cases the code in the files mentioned above was
used for.

Do Dataflow analysis on the code that is to be ctfe'd so we can tell
beforehand if we need to store state in the ctfe stack or not.

Or baring proper data-flow analysis: RefCouting the variables on the
ctfe-stack could also be a solution.

I will post more details as soon as I dive deeper into the code.


Thanks Stefan, that's a good start! (This is probably better for the 
general forum.) -- Andrei

Re: Battle-plan for CTFE

2016-05-09 Thread Walter Bright via Digitalmars-d-announce 

On 5/9/2016 2:32 PM, Andrej Mitrovic via Digitalmars-d-announce wrote:

On 5/9/16, Stefan Koch via Digitalmars-d-announce
 wrote:

I was shocked to discover that the PowExpression actually depends
on phobos!


I seem to remember having to implement diagnostics in DMD asking for
the user to import std.math. I'm fairly confident it had something to
do with power expressions.

Yah, it's a mess. :)



The pow stuff should just be done in dmd without reference to the library.

Re: Battle-plan for CTFE

2016-05-09 Thread Jonathan M Davis via Digitalmars-d-announce 
On Monday, May 09, 2016 13:24:56 Walter Bright via Digitalmars-d-announce 
wrote:
> On 5/9/2016 9:57 AM, Stefan Koch wrote:
> >[...]
>
> The memory consumption problem, at least, can be resolved by using stack
> temporaries instead of allocating new nodes. This was already done in
> constfold.d, but not in the rest of the interpreter.
>
> Doing that will (I predict) also double its speed right there.

Previously, Don stated that he thought that simply making it so that CTFE
didn't allocate a new integer every time it mutated it would be a _huge_
speed-up by itself (which presumably is what you're talking about with
regards to allocating new nodes). Unfortunately, he got too busy to actually
do that work and no one else stepped in to do. But if Stefan is going to
step up and improve CTFE, that's fantastic. It's one of D's best features,
but it's also one of its most problematic. Fixng that would be huge.

- Jonathan M Davis

Re: Battle-plan for CTFE

2016-05-09 Thread Stefan Koch via Digitalmars-d-announce 

On Monday, 9 May 2016 at 20:24:56 UTC, Walter Bright wrote:

On 5/9/2016 9:57 AM, Stefan Koch wrote:

[...]


The memory consumption problem, at least, can be resolved by 
using stack temporaries instead of allocating new nodes. This 
was already done in constfold.d, but not in the rest of the 
interpreter.


Doing that will (I predict) also double its speed right there.


Thanks, your advice is most helpful and a good first stop-gap.

Still the current state of CTFE is almost not maintainable
 and I would really prefer a clean-slate approach.

SDC benefits extremely from the extra level of indirection, 
however I do understand that SDC and DMD have diffrent goals 
regarding compile-speed.


Also I feel that good code has found it's most beautiful shape 
when it's simplicity makes it inevitable, at least the 
Ctfe-Mechanism has not reached this point yet, imo.

Re: Battle-plan for CTFE

2016-05-09 Thread Andrej Mitrovic via Digitalmars-d-announce 
On 5/9/16, Stefan Koch via Digitalmars-d-announce
 wrote:
> I was shocked to discover that the PowExpression actually depends
> on phobos!

I seem to remember having to implement diagnostics in DMD asking for
the user to import std.math. I'm fairly confident it had something to
do with power expressions.

Yah, it's a mess. :)

Re: Battle-plan for CTFE

2016-05-09 Thread Robert burner Schadek via Digitalmars-d-announce 

awesome news :-) thanks you

Re: Battle-plan for CTFE

2016-05-09 Thread David Nadlinger via Digitalmars-d-announce 

Hi Stefan,

On Monday, 9 May 2016 at 16:57:39 UTC, Stefan Koch wrote:

My Plan is as follows.


I think you guys talked about it at the conference, but be sure 
to coordinate with Timon Gehr. You'll want to steal all the best 
ideas from the various implementations anyway. ;)


Do Dataflow analysis on the code that is to be ctfe'd so we can 
tell beforehand if we need to store state in the ctfe stack or 
not.


Or baring proper data-flow analysis: RefCouting the variables 
on the ctfe-stack could also be a solution.


I presume by "store state" you mean persisting objects beyond the 
bounds of a single CTFE invocation? My first inclination here 
would simply be to make all allocations from a new arena each 
time CTFE is entered (can also re-use memory from prior runs for 
that), do a deep-copy of the result (converting it to full AST 
nodes, etc.), and then drop the entire arena. But probably you 
have thought of (and discarded) this already.


 — David

Re: LDC 1.0.0-beta1 has been released! Please help testing!

2016-05-09 Thread Kai Nacke via Digitalmars-d-announce 

On Monday, 9 May 2016 at 07:31:39 UTC, Guillaume Chatelet wrote:

On Monday, 25 April 2016 at 06:42:02 UTC, Kai Nacke wrote:

Hi everyone,

LDC 1.0.0-beta1, the LLVM-based D compiler, is available for 
download!
This BETA release is based on the 2.070.2 frontend and 
standard library and supports LLVM 3.5-3.8.


The 1.0 release will be a major milestone. Please help testing 
to make it the best release ever!
We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM 
(armv7hf). :-)


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

http://forum.dlang.org/post/bwrnvztwkzhhwhzsk...@forum.dlang.org

Regards,
Kai


Why does it requires libconfig.so.8? Could you static link it?


It's a bug. See https://github.com/ldc-developers/ldc/issues/1460.
(Hopefully fixed now.)

Regards,
Kai

Re: Battle-plan for CTFE

2016-05-09 Thread Rory McGuire via Digitalmars-d-announce 
On 09 May 2016 19:01, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> Hi Guys,
>
> I have been looking into the DMD now to see what I can do about CTFE.
> Unfortunately It is a pretty big mess to untangle.
> Code responsible for CTFE is in at least 3 files.
> [dinterpret.d, ctfeexpr.d, constfold.d]
> I was shocked to discover that the PowExpression actually depends on
phobos! (depending on the exact codePath it may or may not compile...)
> which let to me prematurely stating that it worked at ctfe [
http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org]
>
> My Plan is as follows.
>
> Add a new file for my ctfe-interpreter and update it gradually to take
more and more of the cases the code in the files mentioned above was used
for.
>
> Do Dataflow analysis on the code that is to be ctfe'd so we can tell
beforehand if we need to store state in the ctfe stack or not.
>
> Or baring proper data-flow analysis: RefCouting the variables on the
ctfe-stack could also be a solution.
>
> I will post more details as soon as I dive deeper into the code.
>
>

Will be awesome. Particularly if you document the workings of ctfe, might
make a great set of articles for a blog.

Battle-plan for CTFE

2016-05-09 Thread Stefan Koch via Digitalmars-d-announce 

Hi Guys,

I have been looking into the DMD now to see what I can do about 
CTFE.

Unfortunately It is a pretty big mess to untangle.
Code responsible for CTFE is in at least 3 files.
[dinterpret.d, ctfeexpr.d, constfold.d]
I was shocked to discover that the PowExpression actually depends 
on phobos! (depending on the exact codePath it may or may not 
compile...)
which let to me prematurely stating that it worked at ctfe 
[http://forum.dlang.org/thread/ukcoibejffinknrbz...@forum.dlang.org]


My Plan is as follows.

Add a new file for my ctfe-interpreter and update it gradually to 
take more and more of the cases the code in the files mentioned 
above was used for.


Do Dataflow analysis on the code that is to be ctfe'd so we can 
tell beforehand if we need to store state in the ctfe stack or 
not.


Or baring proper data-flow analysis: RefCouting the variables on 
the ctfe-stack could also be a solution.


I will post more details as soon as I dive deeper into the code.

Re: C#7 features

2016-05-09 Thread maik klein via Digitalmars-d-announce 

On Monday, 9 May 2016 at 13:09:24 UTC, Jacob Carlborg wrote:

On 2016-05-09 14:46, John wrote:

C# 7's tuples are something different though. They don't even 
map to

System.Tuple. The syntax is:

   (int x, int y) GetPoint() {
 return (500, 400);
   }

   var p = GetPoint();
   Console.WriteLine($"{p.x}, {p.y}");


Would be nice to have in D. Both with and without named fields.


I mean it is not much shorter than in D

alias Point = Tuple!(int, "x", int, "y");
Point getPoint(){
return Point(500, 400);
}

What would be nice though if tuples would be implicitly 
convertible to named tuples, if the types matches.


Tuple!(int, "x", int, "y") getPoint(){
return tuple(500, 400);
}

Re: C#7 features

2016-05-09 Thread Jacob Carlborg via Digitalmars-d-announce 

On 2016-05-09 14:46, John wrote:


C# 7's tuples are something different though. They don't even map to
System.Tuple. The syntax is:

   (int x, int y) GetPoint() {
 return (500, 400);
   }

   var p = GetPoint();
   Console.WriteLine($"{p.x}, {p.y}");


Would be nice to have in D. Both with and without named fields.

--
/Jacob Carlborg

Re: C#7 features

2016-05-09 Thread John via Digitalmars-d-announce 

On Monday, 9 May 2016 at 00:44:09 UTC, Peter Häggman wrote:

Their tuples seem to be a complete DIY:

https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.110).aspx


C# 7's tuples are something different though. They don't even map 
to System.Tuple. The syntax is:


  (int x, int y) GetPoint() {
return (500, 400);
  }

  var p = GetPoint();
  Console.WriteLine($"{p.x}, {p.y}");

Re: C#7 features

2016-05-09 Thread Kagamin via Digitalmars-d-announce 

On Monday, 9 May 2016 at 00:44:09 UTC, Peter Häggman wrote:
I wouldn't be surpised to see in the implementation an array of 
variant or something like that, explaining why it's limited to 
octuples [1].


You can also use anonymous types: http://ideone.com/WBRunL they 
are predated by tuples.

Re: C#7 features

2016-05-09 Thread Simen Kjaeraas via Digitalmars-d-announce 

On Monday, 9 May 2016 at 00:44:09 UTC, Peter Häggman wrote:


Their tuples seem to be a complete DIY:

https://msdn.microsoft.com/en-us/library/system.tuple(v=vs.110).aspx

I wouldn't be surpised to see in the implementation an array of 
variant or something like that, explaining why it's limited to 
octuples [1]. Sharp tuples look weak compared to D tuple-ish 
things: Tuple, TList, AliasSeq, variadics, ...


[1] Also I think that the param-"variadicity" is simply 
emulated via a set of overloaded constructor, explaining why 
they stop at 8.


C#'s tuples are actually 8 different templated classes - one for 
each arity. There's a lot of duplicated code to make that work. 
Wait, it's actually 9 classes - in addition to Tuple through 
Tuple there's the humble Tuple - a non-generic class 
that cannot be instantiated and only exists to be a namespace for 
the Tuple.Create function. The example code on gooroo seems to 
have eaten the template arguments for the constructor example - 
to instantiate a tuple you use one of these syntaxen:


  var t1 = new Tuple(1, "foo");
  var t2 = Tuple.Create(2, "bar");

The 'templates' in C# are (much) more limited than old C++ 
templates, and have nothing on D's templates. That's not 
necessarily a bad thing, though - the language is different and 
fills a different niche. It does mean some things that are very 
elegant in D end up very inelegant in C#, though.

Re: Adventures in D Programming

2016-05-09 Thread qznc via Digitalmars-d-announce 

On Sunday, 8 May 2016 at 22:22:08 UTC, Peter Häggman wrote:

On Sunday, 8 May 2016 at 17:19:05 UTC, qznc wrote:

On Sunday, 8 May 2016 at 06:05:36 UTC, Iain Buclaw wrote:

http://blog.tenstral.net/2016/05/adventures-in-d-programming.html


Thanks, I missed that post until now.


"the documentation not matching the actual code is a bad 
experience for someone new to the language"


I would interpret that as a sign that we want multiple 
versions of documentation available on the website. For 
example, Python does that.


You've quoted the wrong part of the paragraph. The real problem 
he encountered was not the doc, it was the phobos bugs in the 
older version shipped with GDC/LDC:


"For GDC, which I used to compile my code due to LDC having 
bugs at that time, this means that it is shipping with a very 
outdated copy of Phobos"


The the doc thing is "just" a symptom. Older offline doc is 
always available in the release archive, it's easy to 
understand that so it's not the actual problem.


You are correct, but can this be solved? Newer Phobos versions 
fix bugs. GDC needs a newer Phobos? Well, this is translated into 
GDC needs more manpower. Everything does. Nothing new.

Re: Adventures in D Programming

2016-05-09 Thread Andrei Alexandrescu via Digitalmars-d-announce 

On 5/9/16 1:33 AM, H. S. Teoh via Digitalmars-d-announce wrote:

AFAICT, it shouldn't be super hard to do this. We're already building
Phobos docs in phobos-prerelease/, and IIRC the dlang.org repo already
downloads the last official release and installs it in phobos/. So it's
just a matter of extending this to install multiple doc builds in
phobos-x.y.z/.


That is correct. -- Andrei

Re: LDC 1.0.0-beta1 has been released! Please help testing!

2016-05-09 Thread Rory McGuire via Digitalmars-d-announce 
>From the github issue it appears it was just a issue with the build script.

On Mon, May 9, 2016 at 9:31 AM, Guillaume Chatelet via
Digitalmars-d-announce  wrote:
> On Monday, 25 April 2016 at 06:42:02 UTC, Kai Nacke wrote:
>>
>> Hi everyone,
>>
>> LDC 1.0.0-beta1, the LLVM-based D compiler, is available for download!
>> This BETA release is based on the 2.070.2 frontend and standard library
>> and supports LLVM 3.5-3.8.
>>
>> The 1.0 release will be a major milestone. Please help testing to make it
>> the best release ever!
>> We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM (armv7hf).
>> :-)
>>
>> As usual, you can find links to the changelog and the binary packages over
>> at digitalmars.D.ldc:
>> http://forum.dlang.org/post/bwrnvztwkzhhwhzsk...@forum.dlang.org
>>
>> Regards,
>> Kai
>
>
> Why does it requires libconfig.so.8? Could you static link it?

Re: LDC 1.0.0-beta1 has been released! Please help testing!

2016-05-09 Thread Guillaume Chatelet via Digitalmars-d-announce 

On Monday, 25 April 2016 at 06:42:02 UTC, Kai Nacke wrote:

Hi everyone,

LDC 1.0.0-beta1, the LLVM-based D compiler, is available for 
download!
This BETA release is based on the 2.070.2 frontend and standard 
library and supports LLVM 3.5-3.8.


The 1.0 release will be a major milestone. Please help testing 
to make it the best release ever!
We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM 
(armv7hf). :-)


As usual, you can find links to the changelog and the binary 
packages over at digitalmars.D.ldc:

http://forum.dlang.org/post/bwrnvztwkzhhwhzsk...@forum.dlang.org

Regards,
Kai


Why does it requires libconfig.so.8? Could you static link it?