Re: newCTFE Status March 2018
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!
Re: newCTFE Status March 2018
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.
Re: newCTFE Status March 2018
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.
Re: newCTFE Status March 2018
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.
Re: newCTFE Status March 2018
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
Re: newCTFE Status March 2018
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
Re: newCTFE Status March 2018
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
Re: newCTFE Status March 2018
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.
Re: newCTFE Status March 2018
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 :-)
Re: newCTFE Status March 2018
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.
Re: newCTFE Status March 2018
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.
Re: newCTFE Status March 2018
On Friday, 30 March 2018 at 19:48:02 UTC, Stefan Koch wrote: Have a nice easter. Stefan Great, then there's hope.
Re: newCTFE Status March 2018
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?
newCTFE Status March 2018
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
