On Monday, 19 December 2016 at 10:11:18 UTC, Nordlöw wrote:
On Monday, 19 December 2016 at 08:26:00 UTC, Stefan Koch wrote:
Soon newCTFE will compile Phobos without any blacklisted
functions!
Which functions are still blacklisted?
Check here
https://github.com/UplinkCoder/dmd/blob/newCTFE/sr
On Monday, 19 December 2016 at 08:26:00 UTC, Stefan Koch wrote:
Soon newCTFE will compile Phobos without any blacklisted
functions!
Which functions are still blacklisted?
On Monday, 19 December 2016 at 08:26:00 UTC, Stefan Koch wrote:
Soon newCTFE will compile Phobos without any blacklisted
functions!
Awesome!
On Monday, 19 December 2016 at 08:26:00 UTC, Stefan Koch wrote:
On Saturday, 17 December 2016 at 09:39:02 UTC, Stefan Koch
wrote:
On Saturday, 17 December 2016 at 08:53:07 UTC, Stefan Koch
wrote:
Miscompiling phobos code is down to 4 functions.
std.range.primitives.{front, empty, back}
and std.
On Saturday, 17 December 2016 at 09:39:02 UTC, Stefan Koch wrote:
On Saturday, 17 December 2016 at 08:53:07 UTC, Stefan Koch
wrote:
Miscompiling phobos code is down to 4 functions.
std.range.primitives.{front, empty, back}
and std.traits.defaultParameters.
Note, StructLiterals are still regresse
On Saturday, 17 December 2016 at 08:53:07 UTC, Stefan Koch wrote:
Miscompiling phobos code is down to 4 functions.
std.range.primitives.{front, empty, back}
and std.traits.defaultParameters.
Note, StructLiterals are still regressed.
I am looking into it.
Fixed the regression.
It was an off-by-o
Miscompiling phobos code is down to 4 functions.
std.range.primitives.{front, empty, back}
and std.traits.defaultParameters.
Note, StructLiterals are still regressed.
I am looking into it.
On Saturday, 17 December 2016 at 04:14:29 UTC, Stefan Koch wrote:
I just fixed gotos again.
While researching unusually large performance drops, I found
the cause for a rather nasty bug. (It was an off-by-one error
again :))
It turned out that there were circumstances where some gotos
would
I just fixed gotos again.
While researching unusually large performance drops, I found the
cause for a rather nasty bug. (It was an off-by-one error again
:))
It turned out that there were circumstances where some gotos
would be dropped and the corresponding fixup jumps where never
emitted.
On Friday, 16 December 2016 at 10:33:32 UTC, Stefan Koch wrote:
On Friday, 16 December 2016 at 10:26:15 UTC, Stefan Koch wrote:
On Friday, 16 December 2016 at 09:32:13 UTC, Stefan Koch wrote:
Hey Guys bad news, Regressions.
The handling of default constructed Struct-Literals inside of
newCTFE
On Friday, 16 December 2016 at 10:26:15 UTC, Stefan Koch wrote:
On Friday, 16 December 2016 at 09:32:13 UTC, Stefan Koch wrote:
Hey Guys bad news, Regressions.
The handling of default constructed Struct-Literals inside of
newCTFE is broken.
I have no idea were this came from all of a sudden.
On Friday, 16 December 2016 at 09:32:13 UTC, Stefan Koch wrote:
Hey Guys bad news, Regressions.
The handling of default constructed Struct-Literals inside of
newCTFE is broken.
I have no idea were this came from all of a sudden.
I was in crunch-mode to get the phobos unittest to compile, I
do
Hey Guys bad news, Regressions.
The handling of default constructed Struct-Literals inside of
newCTFE is broken.
I have no idea were this came from all of a sudden.
I was in crunch-mode to get the phobos unittest to compile, I
don't remember the last 72 hours at all :)
So it might take a whil
On Thursday, 15 December 2016 at 23:37:50 UTC, Stefan Koch wrote:
On Thursday, 15 December 2016 at 23:05:55 UTC, Dmitry Olshansky
wrote:
Afaik string switches are implemented as a fairly slow hash
table. Optimal solutions like building a trie would be a nice
enhancement.
---
Dmitry Olshansk
On Thursday, 15 December 2016 at 23:05:55 UTC, Dmitry Olshansky
wrote:
Afaik string switches are implemented as a fairly slow hash
table. Optimal solutions like building a trie would be a nice
enhancement.
---
Dmitry Olshansky
Tries take up alot of memory for sparse tables.
I would like to
On 12/15/16 10:21 AM, Nordlöw wrote:
On Wednesday, 14 December 2016 at 08:40:34 UTC, Stefan Koch wrote:
String-Switches are supported now.
Cool, this is a crucial requirement for pattern matching in parser
generators, like Pegged and alikes. Is it worth giving newCTFE a try
with these things n
On Thursday, 15 December 2016 at 13:38:36 UTC, Nordlöw wrote:
On Thursday, 15 December 2016 at 12:06:46 UTC, Stefan Koch
wrote:
And now the phobos-compiletime tests pass!
How do you run the phobos compile-time tests?
make unittest does do it all right?
yes.
I run make -f posix.mak unittest.
On Thursday, 15 December 2016 at 12:06:46 UTC, Stefan Koch wrote:
And now the phobos-compiletime tests pass!
How do you run the phobos compile-time tests?
make unittest does do it all right?
On Thursday, 15 December 2016 at 12:06:46 UTC, Stefan Koch wrote:
I just fixed Assigning static arrays from ArrayLiterals.
And now the phobos-compiletime tests pass!
Wonderful! I just realized that fast string-switch is only
necessary for parse generators when the generated parse is
eva
On Thursday, 15 December 2016 at 06:04:12 UTC, deadalnix wrote:
On Tuesday, 13 December 2016 at 07:21:07 UTC, Stefan Koch wrote:
Do you use MCJIT or some special sauce made with Orc ?
Anyway, yes, LLVM's JIT is heavy duty, good for long running
code but probably not so much for CTFE which are
On Thursday, 15 December 2016 at 09:23:07 UTC, Nordlöw wrote:
On Thursday, 15 December 2016 at 09:21:10 UTC, Nordlöw wrote:
Cool, this is a crucial requirement for pattern matching in
parser generators, like Pegged and alikes. Is it worth giving
newCTFE a try with these things now?
BTW, does
On Thursday, 15 December 2016 at 09:21:10 UTC, Nordlöw wrote:
Cool, this is a crucial requirement for pattern matching in
parser generators, like Pegged and alikes. Is it worth giving
newCTFE a try with these things now?
BTW, does newCTFE string-switches use O(1) lookups?
On Wednesday, 14 December 2016 at 08:40:34 UTC, Stefan Koch wrote:
String-Switches are supported now.
Cool, this is a crucial requirement for pattern matching in
parser generators, like Pegged and alikes. Is it worth giving
newCTFE a try with these things now?
On Tuesday, 13 December 2016 at 07:21:07 UTC, Stefan Koch wrote:
Hi Guys, I just fixed the LLVM-Backend a little.
It's about 4000 times slower to start up then the interpreter.
And has 1000 microseconds overhead per evaluation.
If you don't want to run a raytracer at compiletime I doubt
that th
On Tuesday, 13 December 2016 at 12:04:31 UTC, Stefan Koch wrote:
I made good progress on function calls today.
By deferring them we get both better bytecode-generator
performance and simpler code.
Since the deferring step seems to work, you can expect calls to
work by the end of next week.
Wh
I made good progress on function calls today.
By deferring them we get both better bytecode-generator
performance and simpler code.
Since the deferring step seems to work, you can expect calls to
work by the end of next week.
When function-calls work, I will direct efforts towards correct
han
On Tuesday, 13 December 2016 at 07:53:56 UTC, Jacob Carlborg
wrote:
On 2016-12-13 08:21, Stefan Koch wrote:
Hi Guys, I just fixed the LLVM-Backend a little.
It's about 4000 times slower to start up then the interpreter.
And has 1000 microseconds overhead per evaluation.
If you don't want to run
On 2016-12-13 08:21, Stefan Koch wrote:
Hi Guys, I just fixed the LLVM-Backend a little.
It's about 4000 times slower to start up then the interpreter.
And has 1000 microseconds overhead per evaluation.
If you don't want to run a raytracer at compiletime I doubt that the
llvm backend is the righ
Hi Guys, I just fixed the LLVM-Backend a little.
It's about 4000 times slower to start up then the interpreter.
And has 1000 microseconds overhead per evaluation.
If you don't want to run a raytracer at compiletime I doubt that
the llvm backend is the right one for you.
That said, it's a great
On Sunday, 11 December 2016 at 09:13:41 UTC, Stefan Koch wrote:
On Sunday, 11 December 2016 at 09:05:26 UTC, Anonymouse wrote:
Would you say it has ended up being more or less (or roughly
equal) work than you initially expected?
And keep up the good work!
I did expect a lot of work.
But wi
On Sunday, 11 December 2016 at 09:13:41 UTC, Stefan Koch wrote:
Originally I planned for this to over in 3 months.
Now I am going finish the 6th month and it won't be done
completely.
I hear that.
As an anecdote, by Binderoo work has been functional for months;
but it's only now becoming usa
On Sunday, 11 December 2016 at 09:05:26 UTC, Anonymouse wrote:
Would you say it has ended up being more or less (or roughly
equal) work than you initially expected?
And keep up the good work!
I did expect a lot of work.
But with debugging it exceeded my expectations.
Originally I planned fo
On Sunday, 11 December 2016 at 08:37:28 UTC, Stefan Koch wrote:
Disregard That!
I wasn't paying attention
The lower numbers are produced by ldc!
The performance fixes did lower the overall overhead even more
though.
Which means bytecode generation will not even show up among the
top 50 function
On Sunday, 11 December 2016 at 08:33:49 UTC, Stefan Koch wrote:
On Monday, 31 October 2016 at 13:29:01 UTC, Stefan Koch wrote:
Hi Guys, since I got a few complaints about giving minor
status updates in the announce group, I am opening this thread.
I will start with giving an overview of what w
On Monday, 31 October 2016 at 13:29:01 UTC, Stefan Koch wrote:
Hi Guys, since I got a few complaints about giving minor status
updates in the announce group, I am opening this thread.
I will start with giving an overview of what works and what
does not work.
Currently the only basic type you
On Saturday, 10 December 2016 at 18:51:32 UTC, Stefan Koch wrote:
On Saturday, 10 December 2016 at 07:24:10 UTC, Stefan Koch
wrote:
FunctionPointers and plain function calls are currently in
progress!
Also I made further performance improvements to the
Bytecode-generator.
As of now it needs a
On Saturday, 10 December 2016 at 07:24:10 UTC, Stefan Koch wrote:
FunctionPointers and plain function calls are currently in
progress!
Also I made further performance improvements to the
Bytecode-generator.
As of now it needs around 50 nano-seconds per generated
instruction.
Generation + Inte
On Saturday, 10 December 2016 at 11:03:11 UTC, Stefan Koch wrote:
This was not found by the compilers testsuite!
Have you already thought to use fuzz testing ?
I'm sure it would find some weird failure cases. The other day
I've found that `enum a=null+null;` triggers a CTFE ICE. It's on
the
On Monday, 31 October 2016 at 13:29:01 UTC, Stefan Koch wrote:
Hi Guys, since I got a few complaints about giving minor status
updates in the announce group, I am opening this thread.
I will start with giving an overview of what works and what
does not work.
Currently the only basic type you
On Monday, 31 October 2016 at 13:29:01 UTC, Stefan Koch wrote:
Hi Guys, since I got a few complaints about giving minor status
updates in the announce group, I am opening this thread.
I will start with giving an overview of what works and what
does not work.
Currently the only basic type you
On Friday, 9 December 2016 at 03:06:49 UTC, Stefan Koch wrote:
On Friday, 9 December 2016 at 02:10:58 UTC, Andrei Alexandrescu
wrote:
That's pretty awesome. The new CTFE engine release will soon
rival Tesla Model 3 in terms of interest raised :o).
In addition to artificial corpora like the abo
On 2016-12-09 00:00, Stefan Koch wrote:
On Thursday, 8 December 2016 at 19:49:47 UTC, Faux Amis wrote:
Any reason for the infinite depth update posting style?
I would have loved to see each update to be a child of the root post
with its own discussions tree.
Currently, the posts are quite unread
On Friday, 9 December 2016 at 02:10:58 UTC, Andrei Alexandrescu
wrote:
On 12/08/2016 04:24 PM, Stefan Koch wrote:
Results are obtained running the following code
uint MakeInitAndSumArray(uint length)
{
uint result;
uint[] arr;
arr.length = length;
while(length--)
{
a
On 12/08/2016 04:24 PM, Stefan Koch wrote:
Results are obtained running the following code
uint MakeInitAndSumArray(uint length)
{
uint result;
uint[] arr;
arr.length = length;
while(length--)
{
arr[length] = length;
}
foreach(e;arr)
{
result += e;
On Thursday, 8 December 2016 at 19:49:47 UTC, Faux Amis wrote:
Any reason for the infinite depth update posting style?
I would have loved to see each update to be a child of the root
post with its own discussions tree.
Currently, the posts are quite unreadable in tree view
(thunderbird).
On
I just wanted to post another performance comparision that does
not test dmd's memory allocator more then anything else :)
[root@localhost dmd]# time src/dmd -c testSettingArrayLength.d
-bc-ctfe
2147385345u
536821761u
4294639619u
real0m0.114s
user0m0.110s
sys 0m0.003s
[root@local
On Thursday, 8 December 2016 at 19:13:23 UTC, Stefan Koch wrote:
I found the biggest performance bottleneck in newCTFE!
oldCtfe :
[root@localhost dmd]# time src/dmd -c ctfeTest.d testStringEq.d
testStringLength.d testStruct.d testMultipleArrayLiterals.d
real0m0.026s
user0m0.020s
sys
Any reason for the infinite depth update posting style?
I would have loved to see each update to be a child of the root post
with its own discussions tree.
Currently, the posts are quite unreadable in tree view (thunderbird).
On 2016-10-31 14:29, Stefan Koch wrote:
Hi Guys, since I got a few
I found the biggest performance bottleneck in newCTFE!
oldCtfe :
[root@localhost dmd]# time src/dmd -c ctfeTest.d testStringEq.d
testStringLength.d testStruct.d testMultipleArrayLiterals.d
real0m0.026s
user0m0.020s
sys 0m0.003s
[root@localhost dmd]# time src/dmd -c ctfeTest.d test
On Thursday, 8 December 2016 at 02:22:31 UTC, Stefan Koch wrote:
On Thursday, 8 December 2016 at 01:52:13 UTC, Stefan Koch wrote:
Array-literals with ctfe-known Variables in them are now
supported;
uint[] fn(uint n)
{
return [n, n, n];
}
static assert(fn(3).length == 3);
static assert(fn(3
On Thursday, 8 December 2016 at 01:52:13 UTC, Stefan Koch wrote:
Array-literals with ctfe-known Variables in them are now
supported;
uint[] fn(uint n)
{
return [n, n, n];
}
static assert(fn(3).length == 3);
static assert(fn(3)[0] == 3);
static assert(fn(3)[1] == 3);
static assert(fn(3)[2] =
On Wednesday, 7 December 2016 at 20:56:08 UTC, Stefan Koch wrote:
I did the change in continue and break handling.
Now ForStatements should be handled correctly for the most part.
I think there could still be a bug if you do labeled continue
on a for-statement.
I will do a change later that ta
I did the change in continue and break handling.
Now ForStatements should be handled correctly for the most part.
I think there could still be a bug if you do labeled continue on
a for-statement.
I will do a change later that takes that into account as well.
Then we should be all set to implem
On Wednesday, 7 December 2016 at 18:50:20 UTC, Stefan Koch wrote:
On Wednesday, 7 December 2016 at 18:00:40 UTC, Stefan Koch
wrote:
I have an update about ctfe performance.
I wondered for quite a while why newCTFE had a 5 millisecond
overhead, when compared the old interpreter.
Since on my cha
On Wednesday, 7 December 2016 at 18:00:40 UTC, Stefan Koch wrote:
I have an update about ctfe performance.
I wondered for quite a while why newCTFE had a 5 millisecond
overhead, when compared the old interpreter.
Since on my charts it had comparable or better stats.
I finally figured it out.
B
I have an update about ctfe performance.
I wondered for quite a while why newCTFE had a 5 millisecond
overhead, when compared the old interpreter.
Since on my charts it had comparable or better stats.
I finally figured it out.
Because the interpreter is supposed to be ctfe-able itself it
uses
On Wednesday, 7 December 2016 at 08:33:22 UTC, Andrea Fontana
wrote:
On Saturday, 3 December 2016 at 18:00:10 UTC, Stefan Koch wrote:
classes (unlikely to be added in the near future)
floating point math (unlikely to be added in the near future)
What's the problem with classes and floating poi
On Saturday, 3 December 2016 at 18:00:10 UTC, Stefan Koch wrote:
classes (unlikely to be added in the near future)
floating point math (unlikely to be added in the near future)
What's the problem with classes and floating point math?
Andrea
On Tuesday, 6 December 2016 at 23:55:06 UTC, Nordlöw wrote:
On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:
Yes there is.
Create a char[] give it the length of string a + string b;
copy string a into the char[]
then copy string b into the resulting array.
offsetting it by the len
On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:
Yes there is...
Thanks.
On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:
Yes there is.
Create a char[] give it the length of string a + string b;
copy string a into the char[]
then copy string b into the resulting array.
offsetting it by the length of string a.
Sounds like you have your concat implement
On Tuesday, 6 December 2016 at 23:16:16 UTC, Stefan Koch wrote:
On Tuesday, 6 December 2016 at 22:44:34 UTC, Nordlöw wrote:
On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:
Go ahead.
Many features should already be working correctly.
The missing important ones are slices and con
On Tuesday, 6 December 2016 at 22:44:34 UTC, Nordlöw wrote:
On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:
Go ahead.
Many features should already be working correctly.
The missing important ones are slices and concat.
Ok, great.
I was thinking about benchmarking parser gener
On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:
Go ahead.
Many features should already be working correctly.
The missing important ones are slices and concat.
Ok, great.
I was thinking about benchmarking parser generators such as
Pegged.
Is there another way of concatenatin
On Tuesday, 6 December 2016 at 22:21:59 UTC, Stefan Koch wrote:
Go ahead.
Many features should already be working correctly.
This https://github.com/UplinkCoder/dmd/commits/newCTFE I presume?
On Tuesday, 6 December 2016 at 21:40:47 UTC, Nordlöw wrote:
On Tuesday, 6 December 2016 at 16:27:38 UTC, Stefan Koch wrote:
I just implemented a bytecode cache, however the bytecode
generation is so fast now that we only safe a couple micro
seconds by using the cache.
It is not noticeable at a
On Tuesday, 6 December 2016 at 16:27:38 UTC, Stefan Koch wrote:
I just implemented a bytecode cache, however the bytecode
generation is so fast now that we only safe a couple micro
seconds by using the cache.
It is not noticeable at all :P.
I can't wait to try this out.
On 12/06/2016 11:27 AM, Stefan Koch wrote:
On Monday, 5 December 2016 at 18:47:13 UTC, Stefan Koch wrote:
On Monday, 5 December 2016 at 16:47:33 UTC, Andrei Alexandrescu wrote:
On 12/05/2016 11:28 AM, Stefan Koch wrote:
It looks like the performance wins brought by the new ctfe engine might
be
On Monday, 5 December 2016 at 18:47:13 UTC, Stefan Koch wrote:
On Monday, 5 December 2016 at 16:47:33 UTC, Andrei Alexandrescu
wrote:
On 12/05/2016 11:28 AM, Stefan Koch wrote:
It looks like the performance wins brought by the new ctfe
engine might
be higher then I predicted.
That's awesome!
On Monday, 5 December 2016 at 16:47:33 UTC, Andrei Alexandrescu
wrote:
On 12/05/2016 11:28 AM, Stefan Koch wrote:
It looks like the performance wins brought by the new ctfe
engine might
be higher then I predicted.
That's awesome!! -- Andrei
After discovering this performance bottleneck I ha
On 12/05/2016 11:28 AM, Stefan Koch wrote:
It looks like the performance wins brought by the new ctfe engine might
be higher then I predicted.
That's awesome!! -- Andrei
On Monday, 5 December 2016 at 07:48:31 UTC, Stefan Koch wrote:
I found an easily fixable performance problem inside the
byte-code generator.
Causing it to allocate 800K per discovery of a new type.
Reducing this will probably make IR generation 10 times faster
in the average case.
Clearing 8
On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote:
I just improved the handling of void initializations.
Now the code is less pessimistic and will allow them if they
are assigned to before use.
However using void variables at ctfe will not result in any
performance wins.
Oh it's b
On Monday, 5 December 2016 at 07:55:32 UTC, deadalnix wrote:
On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote:
I just improved the handling of void initializations.
Now the code is less pessimistic and will allow them if they
are assigned to before use.
However using void variables
On Monday, 5 December 2016 at 08:07:11 UTC, ketmar wrote:
On Monday, 5 December 2016 at 07:55:32 UTC, deadalnix wrote:
On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote:
I just improved the handling of void initializations.
Now the code is less pessimistic and will allow them if the
On Monday, 5 December 2016 at 07:55:32 UTC, deadalnix wrote:
On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote:
I just improved the handling of void initializations.
Now the code is less pessimistic and will allow them if they
are assigned to before use.
However using void variables
On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote:
I just improved the handling of void initializations.
Now the code is less pessimistic and will allow them if they
are assigned to before use.
However using void variables at ctfe will not result in any
performance wins.
Void init
On Monday, 5 December 2016 at 04:26:35 UTC, Stefan Koch wrote:
I just improved the handling of void initializations.
Now the code is less pessimistic and will allow them if they
are assigned to before use.
However using void variables at ctfe will not result in any
performance wins.
I found a
I just improved the handling of void initializations.
Now the code is less pessimistic and will allow them if they are
assigned to before use.
However using void variables at ctfe will not result in any
performance wins.
On Sunday, 4 December 2016 at 23:10:34 UTC, Stefan Koch wrote:
Also the fix for infinite loops has apparently cost us a lot of
performance.
I am not sure where this loss is coming from.
Maybe I am just reading my scales wrong ;)
it seemed to have t odo with the hardware being particularly busy
I just had a hunch about the continue statement within for-loops
being treated incorrectly.
let's see where it leads.
Also the fix for infinite loops has apparently cost us a lot of
performance.
I am not sure where this loss is coming from.
Maybe I am just reading my scales wrong ;)
While th
On Sunday, 4 December 2016 at 00:23:32 UTC, Stefan Koch wrote:
On Sunday, 4 December 2016 at 00:14:26 UTC, Stefan Koch wrote:
On Saturday, 3 December 2016 at 23:30:58 UTC, Stefan Koch
wrote:
[...]
I figured out part of the reason for this bug.
baically it's like this.
[...]
beginBlock:
On Sunday, 4 December 2016 at 00:14:26 UTC, Stefan Koch wrote:
On Saturday, 3 December 2016 at 23:30:58 UTC, Stefan Koch wrote:
Another bug in continue break handling has appeared.
uint fn() {
for (;;)
{
if (true) break;
return 0;
}
return 1;
}
static assert(fn());
The above c
On Saturday, 3 December 2016 at 23:30:58 UTC, Stefan Koch wrote:
Another bug in continue break handling has appeared.
uint fn() {
for (;;)
{
if (true) break;
return 0;
}
return 1;
}
static assert(fn());
The above code is enough to trigger it.
Apparently the fixup jump for the b
Another bug in continue break handling has appeared.
uint fn() {
for (;;)
{
if (true) break;
return 0;
}
return 1;
}
static assert(fn());
The above code is enough to trigger it.
Apparently the fixup jump for the break is never inserted.
I doubt that this is an off-by-one error a
On Saturday, 3 December 2016 at 19:28:52 UTC, Stefan Koch wrote:
On Saturday, 3 December 2016 at 18:16:21 UTC, Stefan Koch wrote:
[...]
StructLiteral regressions fixed.
That one was hard to find.
Basically the for Array arguments interfered with this one.
Arguments are technically the same exp
On Saturday, 3 December 2016 at 18:16:21 UTC, Stefan Koch wrote:
[...]
StructLiteral regressions fixed.
That one was hard to find.
Basically the for Array arguments interfered with this one.
Arguments are technically the same expression as everything else.
But in order to support targets that d
On Saturday, 3 December 2016 at 18:00:10 UTC, Stefan Koch wrote:
On Saturday, 3 December 2016 at 02:07:06 UTC, Stefan Koch wrote:
[...]
switch (...) { case ... , ... } (unreliable due to differences
in case-sorting :( )
for-each on strings and arrays.
if (...) { ... } else { ... } (if(__ctfe
On Saturday, 3 December 2016 at 02:07:06 UTC, Stefan Koch wrote:
Currently I am working on the ability of returning structs.
I will keep you updated,
This is coming along rather nicely.
StructLiterals as Arguments regressed.
But they did rather dubious stuff in the first place.
So supported t
Currently I am working on the ability of returning structs.
Although those are "merely" heterogeneous arrays.
This is a very important step towards having a usable
CTFE-reimplementation.
the regressed struct support.
seems to be restored. (Although I have no idea why)
Once this is done the more
On Thursday, 1 December 2016 at 17:52:02 UTC, Stefan Koch wrote:
I just fixed a bug cause the non-debug build to fail on a
expression that it should have bailed out on.
Currently I have troubles with this code :
int fn(int y)
{
int x = void;
++x;
return x+y;
}
Since x is uninitialized
I just fixed a bug cause the non-debug build to fail on a
expression that it should have bailed out on.
Currently I have troubles with this code :
int fn(int y)
{
int x = void;
++x;
return x+y;
}
Since x is uninitialized the ctfe interpreter should fail on it.
I will need to reserve a
On Wednesday, 30 November 2016 at 15:02:21 UTC, Andrea Fontana
wrote:
Every now and then it would be interesting to have a list of
things that work and a list of things still to do.
That list changes. On both ends. I constantly discover things
that I thought were dealt with are indeed sti
On Wednesday, 30 November 2016 at 13:49:01 UTC, Stefan Koch wrote:
I just added support for assert in newCTFE.
Cool.
Nontheless I get a solid 4x performance improvement over the
old evaluator when compiled with ldc.
Wow.
Furthermore struct support regressed.
It has to be rewritten anyway
On Wednesday, 30 November 2016 at 13:49:01 UTC, Stefan Koch wrote:
On Tuesday, 29 November 2016 at 23:09:08 UTC, Stefan Koch wrote:
On Tuesday, 29 November 2016 at 23:00:08 UTC, Stefan Koch
wrote:
I fixed a bug in continue break handling.
For the record it was an off by one error.
The value f
On Tuesday, 29 November 2016 at 23:09:08 UTC, Stefan Koch wrote:
On Tuesday, 29 November 2016 at 23:00:08 UTC, Stefan Koch wrote:
I fixed a bug in continue break handling.
For the record it was an off by one error.
The value for unresolvedGotos would add one referencing jump.
But the count of
On Tuesday, 29 November 2016 at 23:00:08 UTC, Stefan Koch wrote:
I fixed a bug in continue break handling.
For the record it was an off by one error.
The value for unresolvedGotos would add one referencing jump.
But the count of referencing would be initialized to zero instead
of one.
On Monday, 28 November 2016 at 17:02:37 UTC, Stefan Koch wrote:
On Friday, 25 November 2016 at 10:53:50 UTC, Stefan Koch wrote:
I discovered a nasty bug in goto handling.
I am working on fixed it;
This could take a while, since it likely requires structural
changes.
I fixed a bug in continue
On Friday, 25 November 2016 at 10:53:50 UTC, Stefan Koch wrote:
On Friday, 25 November 2016 at 09:14:16 UTC, Stefan Koch wrote:
On Thursday, 24 November 2016 at 17:16:33 UTC, Stefan Koch
wrote:
I have just discovered breakage of basic operations.
I will need regression tests, some time soon.
On Friday, 25 November 2016 at 09:14:16 UTC, Stefan Koch wrote:
On Thursday, 24 November 2016 at 17:16:33 UTC, Stefan Koch
wrote:
I have just discovered breakage of basic operations.
I will need regression tests, some time soon.
Hey Guys,
I fixed the regression.
(At the expense, of removing mo
301 - 400 of 495 matches
Mail list logo
