On 10/30/2016 11:19 PM, Stefan Koch wrote:
> Oh shoot!
> I did not enable the new call system :(
> This computed by the old interpreter.
>
> The new engine fails :(
Stefan, would you mind creating a dedicated topic in main D newsgroup to
report your development progress? Bumping the thread in ann
On Sunday, 30 October 2016 at 21:09:19 UTC, Stefan Koch wrote:
On Sunday, 30 October 2016 at 03:07:13 UTC, Stefan Koch wrote:
I just made progress on another fundamental feature,
function call support.
It's does not [fully] work yet, but it shows promise.
The following just compiled :
int fn(
On Sunday, 30 October 2016 at 03:07:13 UTC, Stefan Koch wrote:
I just made progress on another fundamental feature,
function call support.
It's does not [fully] work yet, but it shows promise.
The following just compiled :
int fn(int a)
{
return a + fn2(2);
}
int fn2(int a)
{
return
On Friday, 28 October 2016 at 16:52:46 UTC, Stefan Koch wrote:
Another update on CTFE.
I have found a few errors in my handling of switch-statments.
An efficient solution for this is still pending,
Futhermore I have begun to work on ctfe handling refernces.
These are a little bit harder to do i
Another update on CTFE.
I have found a few errors in my handling of switch-statments.
An efficient solution for this is still pending,
Futhermore I have begun to work on ctfe handling refernces.
These are a little bit harder to do in bytecode and do pessimise
performance if overused.
I hope t
On Wednesday, 26 October 2016 at 16:24:49 UTC, MakersF wrote:
On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch
wrote:
Who can guess what this code does ?
char[] obfuscatedFn(string a, string b, uint aLength = 0, uint
bLength = 0, uint cLength = 0, uint pos = 0, uint bPos = 0,
char[
On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote:
Who can guess what this code does ?
char[] obfuscatedFn(string a, string b, uint aLength = 0, uint
bLength = 0, uint cLength = 0, uint pos = 0, uint bPos = 0,
char[] result = [])
{
aLength = cast(uint)a.length;
bLength
On Wednesday, 26 October 2016 at 15:38:30 UTC, Kagamin wrote:
On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch
wrote:
bLength = cast(uint)a.length;
Reads past the end of b if b is shorter than a.
you are right.
Thanks for spotting it :)
On Wednesday, 26 October 2016 at 15:02:28 UTC, Stefam Koch wrote:
bLength = cast(uint)a.length;
Reads past the end of b if b is shorter than a.
Who can guess what this code does ?
char[] obfuscatedFn(string a, string b, uint aLength = 0, uint
bLength = 0, uint cLength = 0, uint pos = 0, uint bPos = 0,
char[] result = [])
{
aLength = cast(uint)a.length;
bLength = cast(uint)a.length;
cLength = aLength + bLength;
result.
On Wednesday, 26 October 2016 at 08:19:46 UTC, Andrea Fontana
wrote:
On Wednesday, 26 October 2016 at 03:58:05 UTC, Stefam Koch
wrote:
On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg
wrote:
Very impressive :)
Thanks.
I just got the following code to compile and execute correctly
On Wednesday, 26 October 2016 at 03:58:05 UTC, Stefam Koch wrote:
On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg
wrote:
Very impressive :)
Thanks.
I just got the following code to compile and execute correctly.
bool strEq(string a, string b)
{
if (a.length != b.length)
On Tuesday, 25 October 2016 at 17:19:26 UTC, Jacob Carlborg wrote:
Very impressive :)
Thanks.
I just got the following code to compile and execute correctly.
bool strEq(string a, string b)
{
if (a.length != b.length)
{
return false;
}
uint length = cast(uint) a.length
On 2016-10-25 14:36, Stefam Koch wrote:
First perf data is in
The is measured with time src/dmd -c -ctfe-bc
old interpreter (without -ctfe-bc) :
real0m6.839s
user0m6.423s
sys0m0.407s
new interpreter (-ctfe-bc)
real0m0.549s
user0m0.547s
sys0m0.000s
LLVM Backend (-ctf
On Tuesday, 25 October 2016 at 15:57:33 UTC, Wyatt wrote:
On Tuesday, 25 October 2016 at 12:36:56 UTC, Stefam Koch wrote:
LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :
real0m0.039s
user0m0.027s
sys 0m0.010s
I think 20,000% is a pretty good speedup! ;) Great stuff.
Now that J
On Tuesday, 25 October 2016 at 12:36:56 UTC, Stefam Koch wrote:
LLVM Backend (-ctfe-bc -version=UseLLVMBackend) :
real0m0.039s
user0m0.027s
sys 0m0.010s
I think 20,000% is a pretty good speedup! ;) Great stuff.
Now that JIT works, are you returning to focusing on feature
coverag
On Tuesday, 25 October 2016 at 09:36:12 UTC, Stefam Koch wrote:
On Monday, 24 October 2016 at 06:37:12 UTC, Rory McGuire wrote:
Cool, thanks for the feedback.
I have take care of the blocker for now.
I turns out my tests contained wrong code that reused a
register for multiple purposes.
LLV
On Monday, 24 October 2016 at 06:37:12 UTC, Rory McGuire wrote:
Cool, thanks for the feedback.
I have take care of the blocker for now.
I turns out my tests contained wrong code that reused a register
for multiple purposes.
LLVM does not like that.
So it assumed the wrong things while optimi
On Mon, Oct 24, 2016 at 8:17 AM, Stefam Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Monday, 24 October 2016 at 05:57:42 UTC, Stefam Koch wrote:
>
>> On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote:
>>
>>>
>>> Little update here:
>>> The LLVM b
On Monday, 24 October 2016 at 05:57:42 UTC, Stefam Koch wrote:
On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote:
Little update here:
The LLVM backend is almost on feature parity.
Meaning that that soon the new CTFE engine is a real jit.
In the process I discoverd quite a few horri
On Sunday, 16 October 2016 at 00:27:50 UTC, Uplink_Coder wrote:
Little update here:
The LLVM backend is almost on feature parity.
Meaning that that soon the new CTFE engine is a real jit.
In the process I discoverd quite a few horrible bugs and
inconsistency in the API.
I am quite astonished t
On 19 Oct 2016 17:46, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote:
>>
>> On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote:
>>>
>>> If all goes well there will be a separate ni
On Wednesday, 19 October 2016 at 07:11:24 UTC, Nordlöw wrote:
On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote:
If all goes well there will be a separate nightly release
build from the newCTFE branch, sometime in October.
I hope to get alpha bug reports that way.
Have you ben
On Sunday, 25 September 2016 at 20:47:41 UTC, Stefan Koch wrote:
If all goes well there will be a separate nightly release build
from the newCTFE branch, sometime in October.
I hope to get alpha bug reports that way.
Have you benchmarked CTFE-heavy projects like Pegged?
On Monday, 17 October 2016 at 15:50:37 UTC, Uplink_Coder wrote:
The time llvm takes to build it's IR and execute the JITed code
is absolutely too much! multiple milliseconds!
I will write a very simple x86 codegenerator tomorrow.
Great work.
On Monday, 17 October 2016 at 00:56:01 UTC, Uplink_Coder wrote:
If anyone want to take a look the lastest llvm_backend
development is happening here :
https://github.com/UplinkCoder/dmd/blob/_ctfe/src/bc_llvm_backend.d
The time llvm takes to build it's IR and execute the JITed code
is absol
On Sunday, 16 October 2016 at 13:51:55 UTC, Uplink_Coder wrote:
On Sunday, 16 October 2016 at 10:58:57 UTC, Dmitry Olshansky
wrote:
That LLVM thing is surely nice to have but I highly doubt it
will be allowed as dependency for DMD.
---
Dmitry Olshansky
LLVM is purely optional.
A pure D int
On 10/16/16 2:27 AM, Uplink_Coder wrote:
On Wednesday, 5 October 2016 at 08:34:06 UTC, Rory McGuire wrote:
No worries, I've been watching this space for over a decade. I really
believe you are working on one of the most important parts of IT for
the next decade. I am planning/making a library t
On Wednesday, 5 October 2016 at 08:34:06 UTC, Rory McGuire wrote:
No worries, I've been watching this space for over a decade. I
really believe you are working on one of the most important
parts of IT for the next decade. I am planning/making a library
that uses CTFE extensively and feel much
On Sunday, 16 October 2016 at 10:58:57 UTC, Dmitry Olshansky
wrote:
That LLVM thing is surely nice to have but I highly doubt it
will be allowed as dependency for DMD.
---
Dmitry Olshansky
LLVM is purely optional.
A pure D interpreter exists.
LLVM optimises most ctfe btw and returns consta
On Sun, Sep 25, 2016 at 10:47 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Sunday, 25 September 2016 at 18:21:27 UTC, Rory McGuire wrote:
>
>>
>> :D congrats!
>>
>
> I appreciate it.
> If all goes well there will be a separate nightly release build
On Sunday, 25 September 2016 at 18:21:27 UTC, Rory McGuire wrote:
:D congrats!
I appreciate it.
If all goes well there will be a separate nightly release build
from the newCTFE branch, sometime in October.
I hope to get alpha bug reports that way.
Also I am now starting experimentation wi
On Sun, Sep 25, 2016 at 4:47 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Tuesday, 20 September 2016 at 05:06:57 UTC, Nordlöw wrote:
>
>> On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote:
>>
>>> Compiling all of phobos does not crash
On Tuesday, 20 September 2016 at 05:06:57 UTC, Nordlöw wrote:
On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote:
Compiling all of phobos does not crash my engine anymore!
Great work! Keep up still!
I am proud to announce,
(and slightly embarssed because it took to long)
that t
On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote:
Compiling all of phobos does not crash my engine anymore!
Great work! Keep up still!
On Monday, 19 September 2016 at 18:05:34 UTC, Lurker wrote:
Good news anyway! Do you have any preliminary results or goals
and expectations that you are going to achieve with your
rework? Is it mostly perf/memory improvements, are there any
new features that this rework will unlock?
Thanks
On Monday, 19 September 2016 at 10:07:06 UTC, Stefan Koch wrote:
Compiling all of phobos does not crash my engine anymore!
However running the unittests does show incorrect results :(
This is concerning since I am mostly bailing out.
I think this too seems to be related to closures produced in
On Thursday, 8 September 2016 at 18:54:52 UTC, Stefan Koch wrote:
On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch
wrote:
On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch
wrote:
compiling parts of phobos does no longer crash the new engine.
However it still produces incorrec
On Thursday, 8 September 2016 at 13:11:23 UTC, Stefan Koch wrote:
On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch
wrote:
compiling parts of phobos does no longer crash the new engine.
However it still produces incorrect byte-code :)
I think I have taken care of the incorrect bytecod
On Thursday, 8 September 2016 at 14:48:25 UTC, Rory McGuire wrote:
On Thu, Sep 8, 2016 at 3:11 PM, Stefan Koch via
Digitalmars-d-announce < digitalmars-d-announce@puremagic.com>
wrote:
On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch
wrote:
compiling parts of phobos does no longer
On Thu, Sep 8, 2016 at 3:11 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote:
>
>> compiling parts of phobos does no longer crash the new engine.
>> However it still produces incorrect byte-
On Thursday, 8 September 2016 at 10:44:55 UTC, Stefan Koch wrote:
compiling parts of phobos does no longer crash the new engine.
However it still produces incorrect byte-code :)
I think I have taken care of the incorrect bytecode.
It was not an issue with the engine itself but rather with the
compiling parts of phobos does no longer crash the new engine.
However it still produces incorrect byte-code :)
On Monday, 5 September 2016 at 13:13:03 UTC, Rory McGuire wrote:
Great news! Any chance you post the commit link in your
announcements? Would be really interested in being able to do a
quick scan of what changed.
At the moment writing a change-log would be tedious busywork
since everything ch
On Mon, Sep 5, 2016 at 1:39 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> FunctionCall support is done. (with a lot of room for improvement)
> you can already return strings.
> now I just have to finish string-comparison and string-concat support to
>
FunctionCall support is done. (with a lot of room for improvement)
you can already return strings.
now I just have to finish string-comparison and string-concat
support to make it usable.
And of course the correct translation of logical-expressions...
On 09/01/2016 11:51 PM, Rory McGuire via Digitalmars-d-announce wrote:
Yeah, I'm using an enum to force the evaluation during CT,
I had missed that detail. Still, the error seems to be independent of
any CTFE that's going on.
[...]
Here is another example:
void main() {
enum ret = ctfefunc
On Thursday, 1 September 2016 at 21:48:41 UTC, Rory McGuire wrote:
I was hoping that the error was coming from the CTFE engine as
it ran the code, but it comes up before ctfe execution I guess.
As a general comment, there is no such thing as a CTFE phase. It
is performed in-line with other sem
On Thu, Sep 01, 2016 at 08:43:16PM +, David Nadlinger via
Digitalmars-d-announce wrote:
> On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote:
> > I have something that will help with that a little bit.
> > https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln when you apply
> > t
On Thu, Sep 1, 2016 at 11:26 PM, ag0aep6g via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On 09/01/2016 11:01 PM, Rory McGuire via Digitalmars-d-announce wrote:
>
>> I'm actually asking why we can't catch the ctfe error.
>>
>
> There is no CTFE error in your example. It
On Thu, Sep 1, 2016 at 11:05 PM, David Nadlinger via Digitalmars-d-announce
wrote:
> On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote:
>
>> I'm actually asking why we can't catch the ctfe error.
>>
>
> You can, by using __traits(compiles, …).
>
> Surely the ctfe engine could be c
On 09/01/2016 11:01 PM, Rory McGuire via Digitalmars-d-announce wrote:
I'm actually asking why we can't catch the ctfe error.
There is no CTFE error in your example. It doesn't compile in the first
place, even without attempting any CTFE.
[...]
Surely the ctfe engine could be changed to cat
On Thursday, 1 September 2016 at 20:43:16 UTC, David Nadlinger
wrote:
See also: https://github.com/dlang/dmd/pull/692 – it's about
time we finally got __ctfeWrite() merged.
— David
Oh yeah.
Let me get this into PR shape.
On Thursday, 1 September 2016 at 21:01:46 UTC, Rory McGuire wrote:
I'm actually asking why we can't catch the ctfe error.
You can, by using __traits(compiles, …).
Surely the ctfe engine could be changed to catch unsupported
code errors. (Not invalid, just unsupported at CT).
It already does
On 01 Sep 2016 21:36, "David Nadlinger via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
>>
>> So why can't we even catch the Error during CTFE, that would at least
help somewhat.
>
>
> You are mixing up
On Thursday, 1 September 2016 at 19:38:13 UTC, Stefan Koch wrote:
I have something that will help with that a little bit.
https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln
when you apply this patch __ctfeWriteln() will output every
compiletime avilable string to the console.
More crucially
On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
At the moment I just have a verbose logging mode with
pragma(msg) for my
CTFE stuff.
I have something that will help with that a little bit.
https://github.com/UplinkCoder/dmd/tree/__ctfeWriteln
when you apply this patch __c
On Thursday, 1 September 2016 at 19:27:17 UTC, Rory McGuire wrote:
So why can't we even catch the Error during CTFE, that would at
least help somewhat.
You are mixing up runtime exceptions ("throw …") with compiler
errors (missing a semicolon). dm.D.learn should be able to help
clear that up.
On Thu, Sep 1, 2016 at 9:09 PM, David Nadlinger via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote:
>
>> is that in one of the "semantic" passes the compiler has?
>>
>
> For reference, I've laid out the reas
On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote:
void main() {
ctfefunc();
}
string ctfefunc() {
static if (assertCTFE!true) {
throw new Exception("asdf");
}
return `import std.stdio; writeln("ctfe generated this");`;
}
template assertCTFE(bool b) {
enum assertCTFE = __traits
On Thursday, 1 September 2016 at 16:43:53 UTC, Rory McGuire wrote:
is that in one of the "semantic" passes the compiler has?
For reference, I've laid out the reasons why this proposal
couldn't work to Stefan here:
https://github.com/dlang/dmd/pull/6098#issuecomment-243375543
The real reason
On Thu, Sep 1, 2016 at 6:29 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote:
>
>> the _checkCTFE() function is just a function that does something we're not
>> allowed to do at CTFE, but c
On Thursday, 1 September 2016 at 13:18:18 UTC, Rory McGuire wrote:
the _checkCTFE() function is just a function that does
something we're not
allowed to do at CTFE, but current implementation does not
respect
__traits(compiles, );
As far as I can tell that is a bug. Thoughts?
It is not
On Wed, Aug 31, 2016 at 10:43 PM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote:
>
>> On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:
>>
>>> I just came up with a nifty little patch
On Tuesday, 30 August 2016 at 22:01:45 UTC, tsbockman wrote:
On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:
I just came up with a nifty little patch that makes it
possible to ensure that a function is _only_ used at ctfe.
Or the opposite.
static assert(__ctfe, "This function is
On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:
I just came up with a nifty little patch that makes it possible
to ensure that a function is _only_ used at ctfe.
Or the opposite.
static assert(__ctfe, "This function is not supposed to be
called outside of ctfe");
and static asser
On Tuesday, 30 August 2016 at 17:29:19 UTC, deadalnix wrote:
worth trying to get it into master ?
I would say maybe, but let's keep separate things separate.
This is a language change. I would not include it in the same
series of patch that change CTFE behavior.
Yes. It would be confusing. A
On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote:
On Monday, 29 August 2016 at 08:05:10 UTC, Rory McGuire wrote:
On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via
The work you are doing is just awesome!
Many thanks.
+1 your work is key for our success as a community.
Am Tue, 30 Aug 2016 12:42:35 +0200
schrieb Johannes Pfau :
> @nogc is only meaningful at runtime. So this could work:
>
> module foo;
> @nogc:
> [...]
>
> string ctfeOnly(string name)
> {
> static assert(!__ctfe);
This should be
static assert(__ctfe);
of course.
Am Tue, 30 Aug 2016 08:35:20 +
schrieb Stefan Koch :
> I do not see how this could affect @nogc.
@nogc is only meaningful at runtime. So this could work:
module foo;
@nogc:
[...]
string ctfeOnly(string name)
{
static assert(!__ctfe);
// error: cannot use operator ~ in @nogc function
On Tue, Aug 30, 2016 at 10:35 AM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> [snip]
> But yes you can circumvent the code-generation and pulling in the druntime
> dependency using a static if.
>
That will be awesome!
On Tuesday, 30 August 2016 at 08:18:47 UTC, Johannes Pfau wrote:
There are some nice use cases for this:
* Do not enforce @nogc for CTFE only functions, so you can mark
a
complete module nogc: and CTFE only functions will get ignored
* Do not emit code for CTFE only functions. This is useful
Am Tue, 30 Aug 2016 08:57:25 +0200
schrieb Jacob Carlborg :
> On 2016-08-29 10:39, Stefan Koch wrote:
>
> > Thanks guys.
> >
> > I just came up with a nifty little patch that makes it possible to
> > ensure that a function is _only_ used at ctfe.
> > Or the opposite.
> >
> > static assert(__ctfe,
On 2016-08-29 10:39, Stefan Koch wrote:
Thanks guys.
I just came up with a nifty little patch that makes it possible to
ensure that a function is _only_ used at ctfe.
Or the opposite.
static assert(__ctfe, "This function is not supposed to be called
outside of ctfe");
and static assert(!__ctfe
On Monday, 29 August 2016 at 00:24:01 UTC, Stefan Koch wrote:
I feel that this can have a positive
I am happy for all comments or suggestions.
Incredible work! Keep up!
On Monday, 29 August 2016 at 08:05:10 UTC, Rory McGuire wrote:
On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via
The work you are doing is just awesome!
Many thanks.
+1 your work is key for our success as a community.
R
Thanks guys.
I just came up with a nifty little patch th
On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via
Digitalmars-d-announce wrote:
> On Monday, 29 August 2016 at 00:24:01 UTC, Stefan Koch wrote:
>
>> I feel that this can have a positive impact on the whole of dmd, since
>> that will allow better frontend-optimisations.
>>
>> I am happ
On Monday, 29 August 2016 at 00:24:01 UTC, Stefan Koch wrote:
I feel that this can have a positive impact on the whole of
dmd, since that will allow better frontend-optimisations.
I am happy for all comments or suggestions.
The work you are doing is just awesome!
Many thanks.
Hi Guys,
First of all,
parsers will not make it before September.
I am sorry about that.
Currently I am fixing issues with the design, that for example
prevent slices of slices to work.
Also I am writing analysis and debugging code to (such as
generating a call-graph and primitive DFA) that w
On Wednesday, 17 August 2016 at 18:24:37 UTC, Rory McGuire wrote:
On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce"
< digitalmars-d-announce@puremagic.com> wrote:
Just a small update today.
if(__ctfe) and if(!__ctfe)
now get special treatment.
Also working on getting compiletime-pa
On 17 Aug 2016 18:50, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> Just a small update today.
> if(__ctfe) and if(!__ctfe)
> now get special treatment.
> Also working on getting compiletime-parsers to run.
>
Nice tease with the "compile time parsers t
Just a small update today.
if(__ctfe) and if(!__ctfe)
now get special treatment.
Also working on getting compiletime-parsers to run.
On Sun, Aug 14, 2016 at 5:21 AM, Stefan Koch via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> Hi,
>
> I took a break from work on string operations and focused instead of
> improving the robustness of the engine.
> I.E. for it not to halt the compiler on unsupported expr
Hi,
I took a break from work on string operations and focused instead
of improving the robustness of the engine.
I.E. for it not to halt the compiler on unsupported expressions.
right now,
I can compile druntime without failures.
Phobos should be working by the end of next week.
Have a nice S
I have just committed the changes necessary for (ascii) string
indexing and (ascii) string-foreach.
Currently working on UTF8 => UTF32 auto-re-encoding and
StringConcat and Slice-Support.
Completion of Slice support will also fix the interplay between
structs and arrays.
Cheers,
Stefan
On Tuesday, 9 August 2016 at 12:30:18 UTC, Kagamin wrote:
1. You said CTFE engine can be ctfeable itself? But it uses
unions in BCValue - it's not going to work in CTFE, is it? Just
wondering myself what's the way to have polymorphism at compile
time.
2. The byte code generator interface has no
1. You said CTFE engine can be ctfeable itself? But it uses
unions in BCValue - it's not going to work in CTFE, is it? Just
wondering myself what's the way to have polymorphism at compile
time.
2. The byte code generator interface has no mean to declare
functions? In case of LLVM jit one would
On Monday, 8 August 2016 at 09:51:03 UTC, Johan Engelen wrote:
On Sunday, 7 August 2016 at 16:52:28 UTC, Stefan Koch wrote:
On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote:
No, not now, but very soon. I want to have _basic_ utf8
support before I am comfortable with enabling string
On Sunday, 7 August 2016 at 16:52:28 UTC, Stefan Koch wrote:
On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote:
No, not now, but very soon. I want to have _basic_ utf8
support before I am comfortable with enabling string
operations.
Tomorrow this is going to work.
Hi Stefan,
Ho
On Saturday, 6 August 2016 at 14:26:00 UTC, Stefan Koch wrote:
I added a switch to my version of dmd which allows to toggle
the ctfe engine.
So now I can compare apples to apples when posting perf data.
That's indeed very useful, also for testing purposes.
On Saturday, 6 August 2016 at 23:04:48 UTC, Stefan Koch wrote:
On Saturday, 6 August 2016 at 19:07:10 UTC, Rory McGuire wrote:
Hi Stefan,
Are you saying we can play around with ascii string
slicing/appending already?
No, not now, but very soon. I want to have _basic_ utf8 support
before I
On Saturday, 6 August 2016 at 19:07:10 UTC, Rory McGuire wrote:
Hi Stefan,
Are you saying we can play around with ascii string
slicing/appending already?
No, not now, but very soon. I want to have _basic_ utf8 support
before I am comfortable with enabling string operations.
The gist with
On 06 Aug 2016 16:30, "Stefan Koch via Digitalmars-d-announce" <
digitalmars-d-announce@puremagic.com> wrote:
>
> Time for an update.
> (ASCII)-Strings work reasonably well.
>
> I am now working on supporting general Sliceing and Appending.
> The effort on function calls is also still ongoing.
>
>
Time for an update.
(ASCII)-Strings work reasonably well.
I am now working on supporting general Sliceing and Appending.
The effort on function calls is also still ongoing.
I added a switch to my version of dmd which allows to toggle the
ctfe engine.
So now I can compare apples to apples when
I am very happy to announce that calls are almost working now.
And the code-gen-interface[1] is near finalization.
It should be very easy to provide different back-ends such as
LLVM or libJIT now.
The missing pieces well be added during next week.
I invite everyone to comment on the interface
On Friday, 29 July 2016 at 14:28:03 UTC, Stefan Koch wrote:
if ((a && b) || (a && c)) {//bla}
This is now solved although quite naively at the cost of
inserting twice the number of instructions for thoose cases.
Then agian we are still much faster then the old interpreter.
And I can still op
On Friday, 29 July 2016 at 12:47:55 UTC, Robert burner Schadek
wrote:
On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:
please share your thoughts.
When is this moving into dmd master?
As soon as it passes the test-suite.
And can execute diet-ng on the fast-path.
Currently I have
On Friday, 29 July 2016 at 13:07:12 UTC, Edwin van Leeuwen wrote:
On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:
I have fresh performance statistics:
Is there any improvement in memory usage?
Yes!
There memory usage is the same as run-time execution.
plus about 16k for the inter
On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:
I have fresh performance statistics:
Is there any improvement in memory usage?
On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:
please share your thoughts.
When is this moving into dmd master?
1 - 100 of 212 matches
Mail list logo