www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - newCTFE Status March 2018

reply Stefan Koch <uplink.coder googlemail.com> writes:
Hello Guys,

I took a few days off over easter and I have very good news for 
you.
The following code will now compile and execute correctly using 
newCTFE.

---
class C
{
   int i() {return 1;}
}

class D : C
{
   override int i() {return 2;}
   float f() { return 1.0f; }
}

class E : D
{
   override int i() {return 3;}
   override float f() { return 2.0f; }
}


int testClassStuff ()
{
   C c1, c2, c3;
   D c4;
   c1 = new C();
   c2 = new D();
   c3 = new E();

   D e = new E();
   assert(cast(int)e.f() == 2);

   return c1.i + c2.i + c3.i;
}
static assert(testClassStuff == 1 + 2 + 3);
---

In short this means that classes and virtual function calls work 
now.
albeit currently only if you don't define your own constructor, 
which would currently get treated as normal function and 
therefore not set the vtbl pointer correctly.

I'd also like to note that the vtbl handling is backend 
independent which means that you code your own backend for 
newCTFE without having to deal with the fact that vtbl and 
constructor stuff is going on.
To you It's just load store and call. :)

Have a nice easter.

Stefan
Mar 30 2018
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

 Hello Guys,

 I took a few days off over easter and I have very good news for 
 you.
 The following code will now compile and execute correctly using 
 newCTFE.

 ---
 class C
 {
   int i() {return 1;}
 }

 class D : C
 {
   override int i() {return 2;}
   float f() { return 1.0f; }
 }

 class E : D
 {
   override int i() {return 3;}
   override float f() { return 2.0f; }
 }


 int testClassStuff ()
 {
   C c1, c2, c3;
   D c4;
   c1 = new C();
   c2 = new D();
   c3 = new E();

   D e = new E();
   assert(cast(int)e.f() == 2);

   return c1.i + c2.i + c3.i;
 }
 static assert(testClassStuff == 1 + 2 + 3);
 ---

 In short this means that classes and virtual function calls 
 work now.
 albeit currently only if you don't define your own constructor, 
 which would currently get treated as normal function and 
 therefore not set the vtbl pointer correctly.

 I'd also like to note that the vtbl handling is backend 
 independent which means that you code your own backend for 
 newCTFE without having to deal with the fact that vtbl and 
 constructor stuff is going on.
 To you It's just load store and call. :)

 Have a nice easter.

 Stefan


How close are you to finish this?
Mar 30 2018
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote:

 On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

 [...]


 How close are you to finish this?


85 to 90% maybe.

I expect that there will many bugs which were hidden by newCTFE 
not supporting classes, which will now be out in the open and 
have to be dealt with.
Also the code is in need of cleanup before I would release it for 
upstream-inclusion.
Mar 30 2018
next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote:

 On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote:

 On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

 [...]


 How close are you to finish this?


 85 to 90% maybe.


Ok, so it will take 90% of the total to get to the remaining 10%. 
So it will be ready for 2028 :-)
Mar 31 2018
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter 
wrote:

 On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote:

 On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote:

 On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

 [...]


 How close are you to finish this?


 85 to 90% maybe.


 Ok, so it will take 90% of the total to get to the remaining 
 10%. So it will be ready for 2028 :-)


huh that's not quite right
The approx time I worked on it is 1.6 years.
If your proposition is correct it will take (0.9 * 1.6) years to 
finish
which would be 1.44 years.
meaning it should be ready 2019.
Mar 31 2018
next sibling parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Saturday, 31 March 2018 at 08:29:22 UTC, Stefan Koch wrote:

 On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter 
 wrote:

 Ok, so it will take 90% of the total to get to the remaining 
 10%. So it will be ready for 2028 :-)


 huh that's not quite right
 The approx time I worked on it is 1.6 years.
 If your proposition is correct it will take (0.9 * 1.6) years 
 to finish
 which would be 1.44 years.
 meaning it should be ready 2019.




 On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter 
 wrote

 it will take 90% of the total to get to the remaining 10%.


So 1.6 years is 10%, the total is 16 years, and there's 14.4 
years left. So 2032.

--
   So,em
Mar 31 2018
parent jmh530 <john.michael.hall gmail.com> writes:
On Saturday, 31 March 2018 at 10:38:53 UTC, Simen Kjærås wrote:

 [snip]

 So 1.6 years is 10%, the total is 16 years, and there's 14.4 
 years left. So 2032.

 --
   So,em


60% of the time, it works every time

https://www.youtube.com/watch?v=pjvQFtlNQ-M
Mar 31 2018
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 31 March 2018 at 08:29:22 UTC, Stefan Koch wrote:

 On Saturday, 31 March 2018 at 08:19:39 UTC, Patrick Schluter 
 wrote:

 On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote:

 On Friday, 30 March 2018 at 20:15:20 UTC, 12345swordy wrote:

 On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

 [...]


 How close are you to finish this?


 85 to 90% maybe.


 Ok, so it will take 90% of the total to get to the remaining 
 10%. So it will be ready for 2028 :-)


 huh that's not quite right
 The approx time I worked on it is 1.6 years.
 If your proposition is correct it will take (0.9 * 1.6) years 
 to finish
 which would be 1.44 years.
 meaning it should be ready 2019.


The thing is, the first 90% take 10% of the time, so it's 9 * 1.6 
in 14 years :-o

https://en.wikipedia.org/wiki/Ninety-ninety_rule
Mar 31 2018
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 30 March 2018 at 20:46:32 UTC, Stefan Koch wrote:

 85 to 90% maybe.

 I expect that there will many bugs which were hidden by newCTFE 
 not supporting classes, which will now be out in the open and 
 have to be dealt with.
 Also the code is in need of cleanup before I would release it 
 for upstream-inclusion.


I tried building your newCTFE_reboot branch but it fails as

expression.d(15724): Deprecation: Implicit string concatenation 
is deprecated, use "identity comparison of static arrays " ~ 
"implicitly coerces them to slices, " instead
expression.d(15725): Deprecation: Implicit string concatenation 
is deprecated, use "implicitly coerces them to slices, " ~ "which 
are compared by reference" instead
gluelayer.d(61): Deprecation: Symbol ddmd.backend.code_x86.code 
is not visible from module gluelayer because it is privately 
imported in module code
ctfe/ctfe_bc.d(4): Deprecation: Symbol ddmd.func.FuncDeclaration 
is not visible from module ctfe_bc because it is privately 
imported in module declaration
ctfe/ctfe_bc.d(4): Deprecation: Symbol ddmd.func.CtorDeclaration 
is not visible from module ctfe_bc because it is privately 
imported in module declaration
Sizeof BCValue: 56LU
ctfe/ctfe_bc.d(262): Error: module `bc_gccjit_backend` is in file 
'ddmd/ctfe/bc_gccjit_backend.d' which cannot be read
import path[0] = /usr/include/dmd/phobos
import path[1] = /usr/include/dmd/druntime/import
posix.mak:338: receptet för målet ”dmd” misslyckades
make[1]: *** [dmd] Fel 1
make[1]: Lämnar katalogen ”/home/per/Work/dmd/src”
posix.mak:8: receptet för målet ”all” misslyckades
make: *** [all] Fel 2

I'm on Ubuntu 17.10 and building with DMD 2.079.
Apr 01 2018
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote:

 [...]


Oh I was not aware people would try this :)
I have fixed the build please pull.
Apr 01 2018
parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Sunday, 1 April 2018 at 18:32:00 UTC, Stefan Koch wrote:

 On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote:

 [...]


 Oh I was not aware people would try this :)
 I have fixed the build please pull.


Thanks!
Apr 01 2018
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Sunday, 1 April 2018 at 16:48:32 UTC, Per Nordlöw wrote:

 [...]


What is going on here is that it tries to build the gccjit 
backend which is currently in a dysfunctional state.
I am currently getting trying to get libgccjit working such that 
I can make use of it's debug output, while I am trying to find 
out what is wrong with dynamic casts.
Apr 01 2018
prev sibling next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

 Have a nice easter.

 Stefan


Great, then there's hope.
Mar 30 2018
prev sibling parent Meta <jared771 gmail.com> writes:
On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote:

 Hello Guys,

 I took a few days off over easter and I have very good news for 
 you.
 The following code will now compile and execute correctly using 
 newCTFE.

 ---
 class C
 {
   int i() {return 1;}
 }

 class D : C
 {
   override int i() {return 2;}
   float f() { return 1.0f; }
 }

 class E : D
 {
   override int i() {return 3;}
   override float f() { return 2.0f; }
 }


 int testClassStuff ()
 {
   C c1, c2, c3;
   D c4;
   c1 = new C();
   c2 = new D();
   c3 = new E();

   D e = new E();
   assert(cast(int)e.f() == 2);

   return c1.i + c2.i + c3.i;
 }
 static assert(testClassStuff == 1 + 2 + 3);
 ---

 In short this means that classes and virtual function calls 
 work now.
 albeit currently only if you don't define your own constructor, 
 which would currently get treated as normal function and 
 therefore not set the vtbl pointer correctly.

 I'd also like to note that the vtbl handling is backend 
 independent which means that you code your own backend for 
 newCTFE without having to deal with the fact that vtbl and 
 constructor stuff is going on.
 To you It's just load store and call. :)

 Have a nice easter.

 Stefan


newCTFE is looking very cool. Glad to see you're still working at 
it.
Mar 30 2018