On Saturday, 5 November 2016 at 20:57:06 UTC, Andrei Alexandrescu
wrote:
On 11/4/16 9:21 PM, Stefan Koch wrote:
I thought about it some more, and decided that I will replace
the old
interpreter completely in the long run.
However in order to get something release before 2017, I have
to rely on
On Saturday, 5 November 2016 at 03:01:48 UTC, ketmar wrote:
On Friday, 4 November 2016 at 10:59:25 UTC, Marc Schütz wrote:
In this case better make sure to remove the resulting dead
code from the old interpreter, otherwise it will become and
unmaintainable mess in the long run.
interpreter is
On Friday, 4 November 2016 at 10:59:25 UTC, Marc Schütz wrote:
In this case better make sure to remove the resulting dead code
from the old interpreter, otherwise it will become and
unmaintainable mess in the long run.
If you ask me the old interpreter is already an unmaintainble
mess.
It w
On Thursday, 3 November 2016 at 22:29:34 UTC, Jerry wrote:
So I was thinking of a way of extending if statements that have
declarations. The following being as example of the current use
of if statements with declarations:
[...]
Just Introduce another block
{
int i = someFunc();
if (i
On Thursday, 3 November 2016 at 15:44:20 UTC, Marc Schütz wrote:
On Tuesday, 1 November 2016 at 17:41:35 UTC, Stefan Koch wrote:
I intend to keep the current implemntation around as a
fallback.
For things that are used rarely.
like floating point and others :)
Is that a good idea? It means th
On Wednesday, 2 November 2016 at 23:48:46 UTC, Nordlöw wrote:
On Wednesday, 2 November 2016 at 11:01:55 UTC, Stefan Koch
wrote:
I am now passing phobos unittests!
I can't wait to see this in action!
Keep on going and I'll keep praying... 😊
No need for prayer.
I am trying my best to be doin
On Tuesday, 1 November 2016 at 21:12:06 UTC, Nordlöw wrote:
On Tuesday, 1 November 2016 at 19:28:03 UTC, Stefan Koch wrote:
Now a phobos unittest miscompiles :(
Again passing the unittests does not mean too much.
I just means I bail out before I generate invalid code :)
Keep up!
I am now pa
On Tuesday, 1 November 2016 at 15:50:06 UTC, Stefan Koch wrote:
Very recent news:
NEW CTFE PASSES THE DRUNTIME UNITESTS
Now a phobos unittest miscompiles :(
Again passing the unittests does not mean too much.
I just means I bail out before I generate invalid code :)
On Tuesday, 1 November 2016 at 16:44:14 UTC, Nordlöw wrote:
On Monday, 31 October 2016 at 13:29:01 UTC, Stefan Koch wrote:
These are the constructs that will work.
- foreach on static arrays strings and range-foreach (those
kinds (0 .. 64)).
- switches (even deeply nested ones)
- for and whi
On Monday, 31 October 2016 at 20:49:58 UTC, Steven Schveighoffer
wrote:
On 10/31/16 9:29 AM, 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
On Monday, 31 October 2016 at 20:23:13 UTC, Jacob Carlborg wrote:
One of the big features of D and a feature that is show cased
is CTFE. The regex module and the PEG parser generator are
projects that are often mentioned when talking about what CTFE
can do.
One of the, or _the_, major goal no
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 can do arithmetic on is int.
Altough you can compare longs sinc
On Thursday, 27 October 2016 at 23:49:49 UTC, deadalnix wrote:
On Thursday, 27 October 2016 at 05:25:49 UTC, Stefan Koch wrote:
https://github.com/dlang/dmd/pull/6215
PR is open.
Pending review and merge.
Although if you ask me this is a no-brainer.
It's now merged, thanks Stefan.
No probl
On Thursday, 27 October 2016 at 19:59:09 UTC, Steven
Schveighoffer wrote:
On 10/27/16 3:49 PM, Ali Çehreli wrote:
http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html
Some entries for reference:
C
- You shoot yourself in the foot.
- You shoot yourself in the foot and then no
On Thursday, 27 October 2016 at 05:15:26 UTC, deadalnix wrote:
On Thursday, 27 October 2016 at 04:41:38 UTC, Stefan Koch wrote:
On Thursday, 27 October 2016 at 04:39:03 UTC, mogu wrote:
On Thursday, 27 October 2016 at 04:33:30 UTC, Stefan Koch
wrote:
On Thursday, 27 October 2016 at 02:36:13 UTC
On Thursday, 27 October 2016 at 04:39:03 UTC, mogu wrote:
On Thursday, 27 October 2016 at 04:33:30 UTC, Stefan Koch wrote:
On Thursday, 27 October 2016 at 02:36:13 UTC, Stefam Koch
wrote:
Trivial.
Fix is comeing.
Okay it was less trivial then it should have been.
Great job gcc.
-Wno-narro
On Thursday, 27 October 2016 at 02:36:13 UTC, Stefam Koch wrote:
Trivial.
Fix is comeing.
Okay it was less trivial then it should have been.
Great job gcc.
On Friday, 21 October 2016 at 13:42:49 UTC, Adam D. Ruppe wrote:
On Friday, 21 October 2016 at 13:33:26 UTC, Stefan Koch wrote:
It does create a lambda?
Hmm that should not happen.
I think deprecating `{ lambda }` is really the way to go. It'd
fix this as well at that other FAQ at pretty low
On Friday, 21 October 2016 at 13:18:19 UTC, RazvanN wrote:
On Friday, 21 October 2016 at 12:34:58 UTC, Andrei Alexandrescu
wrote:
[...]
I am the one who raised the question. I am n00b when it comes
to D language (I just started reading about it a couple of days
ago) and I tried the above men
On Friday, 21 October 2016 at 12:34:58 UTC, Andrei Alexandrescu
wrote:
I got a question about what happens with this code:
int j;
for({j=2; int d = 3; } j+d<7; {j++; d++;}) {
}
[...]
We could restrict the initialze part to assignments only. But I
am unsure of the implications.
How did you fin
On Friday, 21 October 2016 at 02:16:44 UTC, Chris M. wrote:
So I know you can do some pattern matching with templates in D,
but has there been any discussion about implementing it as a
language feature, maybe something similar to Rust's match
keyword (https://doc.rust-lang.org/stable/book/patte
On Saturday, 15 October 2016 at 19:42:03 UTC, Uplink_Coder wrote:
On Saturday, 15 October 2016 at 19:07:50 UTC, Patrick Schluter
wrote:
At least with that lookup table below, you can detect isolated
continuation bytes (192 and 193) and invalid codes (above 244).
__gshared static immutable ubyt
On Friday, 14 October 2016 at 20:47:39 UTC, Stefan Koch wrote:
On Thursday, 13 October 2016 at 21:49:22 UTC, safety0ff wrote:
Bad benchmark! Bad! -- Andrei
Also, I suspect a benchmark with a larger loop body might not
benefit as significantly from branch hints as this one.
I disagree in lon
On Thursday, 13 October 2016 at 21:49:22 UTC, safety0ff wrote:
Bad benchmark! Bad! -- Andrei
Also, I suspect a benchmark with a larger loop body might not
benefit as significantly from branch hints as this one.
I disagree in longer loops code compactness is as important as in
small ones.
On Friday, 14 October 2016 at 18:02:24 UTC, Andrei Alexandrescu
wrote:
On 10/14/16 12:38 PM, Stefan Koch wrote:
On Friday, 14 October 2016 at 13:13:16 UTC, Andrei
Alexandrescu wrote:
https://issues.dlang.org/show_bug.cgi?id=5051 -- Andrei
I have been working on this.
What this amounts to is a
On Friday, 14 October 2016 at 13:13:16 UTC, Andrei Alexandrescu
wrote:
https://issues.dlang.org/show_bug.cgi?id=5051 -- Andrei
I have been working on this.
What this amounts to is an AST-writeout using the HdrGen.
This will affect the code in so far as it will be lowerd my the
dmd frontend.
On Friday, 14 October 2016 at 04:44:46 UTC, Patrick Schluter
wrote:
core.hints
short and simple
core.hints ?
That sounds to weak.
If I tell the compiler to group function a and function b
together and position them as close as possible to each other it
damn well better do it.
Because If I w
On Friday, 14 October 2016 at 04:21:28 UTC, Stefan Koch wrote:
On Wednesday, 12 October 2016 at 17:59:51 UTC, Andrei
Alexandrescu wrote:
On 10/12/2016 01:05 PM, safety0ff wrote:
On Wednesday, 12 October 2016 at 16:48:36 UTC, safety0ff
wrote:
[Snip]
Didn't see the LUT implementation, nvm!
Y
On Wednesday, 12 October 2016 at 17:59:51 UTC, Andrei
Alexandrescu wrote:
On 10/12/2016 01:05 PM, safety0ff wrote:
On Wednesday, 12 October 2016 at 16:48:36 UTC, safety0ff wrote:
[Snip]
Didn't see the LUT implementation, nvm!
Yah, that's pretty clever. Better yet, I suspect we can reuse
th
On Thursday, 13 October 2016 at 22:44:13 UTC, Dominikus Dittes
Scherkl wrote:
On Thursday, 13 October 2016 at 19:52:57 UTC, Stefan Koch wrote:
On Thursday, 13 October 2016 at 19:49:42 UTC, Johan Engelen
wrote:
On Thursday, 13 October 2016 at 19:35:08 UTC, Stefan Koch
wrote:
Please share your
On Thursday, 13 October 2016 at 21:52:22 UTC, Johan Engelen wrote:
On Thursday, 13 October 2016 at 19:52:57 UTC, Stefan Koch wrote:
also do you happen to know where llvm_expect is implemented in
ldc ? I cannot seem to find it.
It's at the bottom of druntime/src/ldc/intrinsics.di (note the
On Thursday, 13 October 2016 at 19:49:42 UTC, Johan Engelen wrote:
On Thursday, 13 October 2016 at 19:35:08 UTC, Stefan Koch wrote:
Please share your thoughts and tell me what other intrinsic
functions could/should be added.
I think the name should be different from "intrinsics", so that
it
Hi,
while working on a faster auto-decoding it became oblivous that
branch-prediction primitives such as the llvm_expect or
builtin_expect are quite useful and should be avilable in a
cross-platform compatible way.
I propose to add a new module to to druntime called
core.intrinsics that wou
On Thursday, 13 October 2016 at 01:27:35 UTC, Andrei Alexandrescu
wrote:
On 10/12/2016 08:41 PM, safety0ff wrote:
On Thursday, 13 October 2016 at 00:32:36 UTC, safety0ff wrote:
It made little difference: LDC compiled into AVX2 vectorized
addition
(vpmovzxbq & vpaddq.)
Measurements without
On Thursday, 13 October 2016 at 01:26:17 UTC, Andrei Alexandrescu
wrote:
On 10/12/2016 08:11 PM, Stefan Koch wrote:
We should probably introduce a new module for stuff like this.
object.d is already filled with too much unrelated things.
Yah, shouldn't go in object.d as it's fairly niche. On t
On Wednesday, 12 October 2016 at 23:59:15 UTC, Stefan Koch wrote:
On Wednesday, 12 October 2016 at 23:47:45 UTC, Andrei
Alexandrescu wrote:
I think we should define two aliases "likely" and "unlikely"
with default implementations:
bool likely(bool b) { return b; }
bool unlikely(bool b) { ret
On Wednesday, 12 October 2016 at 23:47:45 UTC, Andrei
Alexandrescu wrote:
I think we should define two aliases "likely" and "unlikely"
with default implementations:
bool likely(bool b) { return b; }
bool unlikely(bool b) { return b; }
They'd go in druntime. Then implementers can hook them in
On Wednesday, 12 October 2016 at 22:16:38 UTC, tsbockman wrote:
On Wednesday, 12 October 2016 at 16:36:32 UTC, Andrei
Alexandrescu wrote:
On 10/12/2016 12:31 PM, Stefan Koch wrote:
I can take a look at 259.
14835 is nothing trivial though.
My understanding is Thomas has an attack on 259 once
On Wednesday, 12 October 2016 at 20:02:16 UTC, safety0ff wrote:
On Wednesday, 12 October 2016 at 16:24:19 UTC, Andrei
Alexandrescu wrote:
Remember the ASCII part is the bothersome one. There's only
two comparisons, all with 100% predictability. We should be
able to arrange matters so the loss
On Wednesday, 12 October 2016 at 16:27:05 UTC, Andrei
Alexandrescu wrote:
So it would be great to get the super annoying
https://issues.dlang.org/show_bug.cgi?id=259 to a conclusion,
and it seems the similarly annoying
https://issues.dlang.org/show_bug.cgi?id=14835 is in the way.
If anyone wo
On Wednesday, 12 October 2016 at 14:46:32 UTC, Andrei
Alexandrescu wrote:
No need. 1% for dmd is negligible. 25% would raise an eyebrow.
-- Andrei
Alright then
PR: https://github.com/dlang/phobos/pull/4849
On Wednesday, 12 October 2016 at 13:53:03 UTC, Andrei
Alexandrescu wrote:
So we've had a good run with making popFront smaller. In ASCII
microbenchmarks with ldc, the speed is indistinguishable from s
= s[1 .. $]. Smaller functions make sure that the impact on
instruction cache in larger applic
On Wednesday, 12 October 2016 at 14:12:30 UTC, Andrei
Alexandrescu wrote:
On 10/12/2016 09:39 AM, Stefan Koch wrote:
Thanks! I'd say make sure there is exactly 0% loss on
performance compared to the popFront in the ASCII case, and if
so make a PR with the table version. -- Andrei
I measur
On Wednesday, 12 October 2016 at 12:46:50 UTC, Andrei
Alexandrescu wrote:
On 10/12/2016 06:56 AM, Stefan Koch wrote:
I just confirmed that branching version is faster then
table-lookup.
please test it our for yourself
http://paste.ofcode.org/3CpieAhkrTYEcSncbPKbrj
The table-lookup does produc
On Wednesday, 12 October 2016 at 13:32:45 UTC, Stefan Koch wrote:
On Wednesday, 12 October 2016 at 12:46:50 UTC, Andrei
Alexandrescu wrote:
In the second case, the compiler generates an inc for bumping
the pointer and a dec for decreasing the length (small
instructions). If the variable char_
I just confirmed that branching version is faster then
table-lookup.
please test it our for yourself
http://paste.ofcode.org/3CpieAhkrTYEcSncbPKbrj
The table-lookup does produce the smallest code though.
On Wednesday, 12 October 2016 at 10:15:17 UTC, Matthias Bentrup
wrote:
On Wednesday, 12 October 2016 at 09:23:53 UTC, Stefan Koch
wrote:
On Wednesday, 12 October 2016 at 08:56:59 UTC, Matthias
Bentrup wrote:
[...]
All three are slower than baseline, for my test-case.
What did you test it agai
On Wednesday, 12 October 2016 at 08:56:59 UTC, Matthias Bentrup
wrote:
Here are three branch-less variants that use the sign instead
of the carry bit.
The last one is the fastest on my machine, although it mixes
the rare error case and the common 1-byte case into one branch.
void popFront1
On Tuesday, 11 October 2016 at 16:13:45 UTC, Andrei Alexandrescu
wrote:
On 10/11/16 11:15 AM, Stefan Koch wrote:
I will now run this problem through STOKE.
Let's see what it comes up with :)
http://stoke.stanford.edu you mean? That would be cool. Keep us
posted! -- Andrei
Yep I mean that on
On Tuesday, 11 October 2016 at 15:08:34 UTC, Andrei Alexandrescu
wrote:
On 10/10/2016 11:00 PM, Stefan Koch wrote:
[...]
Looked at this, still seems to generate a jump forward with
ldc. Also, why do you leave a fallthrough path? Progress needs
to be made on all paths, otherwise we have infi
On Tuesday, 11 October 2016 at 14:49:28 UTC, Matthias Bentrup
wrote:
This is the result I'd like to get, but I can't find a way to
write it without inline assembly :(
void popFrontAsmIntel(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
if (c < 0x80) {
s = s[1 .. $];
} els
On Tuesday, 11 October 2016 at 14:24:56 UTC, Andrei Alexandrescu
wrote:
On 10/11/2016 03:30 AM, Matthias Bentrup wrote:
A branch-free version:
void popFront4(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
s = s.ptr[ch
On Tuesday, 11 October 2016 at 14:16:54 UTC, Andrei Alexandrescu
wrote:
On 10/11/2016 04:57 AM, Stefan Koch wrote:
Yours runs with 790 us best time.
bsr is a real timetaker :)
What inputs did you test it on?
https://github.com/minimaxir/big-list-of-naughty-strings/blob/master/blns.txt
Here
On Tuesday, 11 October 2016 at 09:45:11 UTC, Temtaime wrote:
Sorry this was also a type in the code.
void popFront7(ref char[] s) @trusted pure nothrow
{
import core.bitop;
auto v = 7 - bsr(~s[0] | 1);
s = s[v > 6 ? 1 : (v ? (v > s.length ? s.length : v) : 1)..$];
}
Please check this.
On Tuesday, 11 October 2016 at 08:57:46 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 08:44:04 UTC, Temtaime wrote:
void popFront1(ref char[] s) @trusted pure nothrow
{
import core.bitop, std.algorithm;
auto v = bsr(~s[0] | 1);
s = s[clamp(v, 1, v > 6 ? 1 : $)..$];
}
Seems to be
On Tuesday, 11 October 2016 at 08:44:04 UTC, Temtaime wrote:
void popFront1(ref char[] s) @trusted pure nothrow
{
import core.bitop, std.algorithm;
auto v = bsr(~s[0] | 1);
s = s[clamp(v, 1, v > 6 ? 1 : $)..$];
}
Seems to be less if i'm not wrong.
Yours runs with 790 us best time.
bsr
On Tuesday, 11 October 2016 at 08:17:52 UTC, Stefan Koch wrote:
Also the code produces conditional set instructions which have
a higher latency.
And worse throughput.
On my arguably a bit dated laptop:
popFront3 performs 109 us best time
and popFront4 performs with 265 us best time
Testcode
On Tuesday, 11 October 2016 at 08:03:40 UTC, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 07:30:26 UTC, Matthias Bentrup
wrote:
A branch-free version:
void popFront4(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
On Tuesday, 11 October 2016 at 07:30:26 UTC, Matthias Bentrup
wrote:
A branch-free version:
void popFront4(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
uint char_length = 1 + (c >= 192) + (c >= 240) + (c >= 248);
s = s.ptr[char_length .. s.length];
}
Theoretically the char_l
On Tuesday, 11 October 2016 at 03:58:59 UTC, Andrei Alexandrescu
wrote:
On 10/10/16 11:00 PM, Stefan Koch wrote:
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei
Alexandrescu wrote:
That looks good. I'm just worried about the jump forward -
ideally the
case c < 127 would simply entail a quic
On Tuesday, 11 October 2016 at 03:18:24 UTC, Lurker wrote:
Pardon me asking, but why all these gotos instead of else ifs:
if (c < 192)
{
char_length = 2;
}
else if (c < 240)
{
char_length = 3;
} else if (...) {
}
Does it have any effect on generated code (I don't think it
On Tuesday, 11 October 2016 at 03:05:12 UTC, Nicholas Wilson
wrote:
Splitting this from the colour
thread(https://forum.dlang.org/thread/mailman.961.1475765646.2994.digitalmar...@puremagic.com?page=1).
[...]
This will bloat like hell.
The best way would be to provide special Range-Definitions
On Tuesday, 11 October 2016 at 02:48:22 UTC, Andrei Alexandrescu
wrote:
That looks good. I'm just worried about the jump forward -
ideally the case c < 127 would simply entail a quick return. I
tried a fix, but it didn't do what I wanted in ldc. We
shouldn't assert(0) if wrong - just skip one b
This version has 24 instructions but these have a smaller
encoding then and are generally inexpensive
With inline asm and conditional moves it would be possible to
reduce this even further
to ~20 instructions.
void popFront1(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
size_t c
On Monday, 10 October 2016 at 15:17:05 UTC, Stefan Koch wrote:
On Monday, 10 October 2016 at 03:55:17 UTC, Andrei Alexandrescu
wrote:
Oh, forgot to mention: the initial/short path should only
check for ASCII, i.e. c < 0x80. -- Andrei
Since in this case stability of min is concern, you can sh
On Monday, 10 October 2016 at 15:37:09 UTC, Stefan Koch wrote:
Since in this case stability of min is concern, you can shave
of another 2 instructions by writing the comparison by hand
In this case the stability of min is +NO+ concern.
On Monday, 10 October 2016 at 03:55:17 UTC, Andrei Alexandrescu
wrote:
Oh, forgot to mention: the initial/short path should only check
for ASCII, i.e. c < 0x80. -- Andrei
void popFront1(ref char[] s) @trusted pure nothrow {
immutable c = s[0];
size_t char_length = 1;
if (!(c & 0x80)) {
On Sunday, 9 October 2016 at 22:11:50 UTC, Andrei Alexandrescu
wrote:
Had a bit of a good time with popFront for UTF, got to this:
https://github.com/dlang/phobos/pull/4848. I suspect there are
cleverer things that can be done. Can anyone make it tighter?
Take a look at the disassembly referred
On Sunday, 9 October 2016 at 13:40:14 UTC, Jacob Carlborg wrote:
How about we just implement AST macros and be done with it :)
Walter would rather die. Then see ast-macros in D.
I must say they would probably be worse then templates, in
regards of compile-time bloating.
On Sunday, 9 October 2016 at 04:12:48 UTC, Nicholas Wilson wrote:
On Sunday, 9 October 2016 at 03:05:22 UTC, Stefan Koch wrote:
So far it can be visualized as
struct __Symbol
{
string name;
__Symbol parent;
/* MaybeLater:
__SymbolType type;
__Symbol[] members;
*/
}
Infinite r
Hi Guys,
You might remember my critique regarding the
fullyQulifiedName-template in phobos.
Basically it is dramatically slowed down by the cost of template
instanciation.
I tried to remedy the situation by using by introducing another
__trait.
While this succeeded in reducing the compile-tim
On Friday, 7 October 2016 at 12:04:09 UTC, Mark wrote:
I'm going over the Object class methods and I have a few
concerns about the opEquals method.
First, what should be the default implementation of opEquals?
The specification (see
https://dlang.org/spec/operatoroverloading.html#eqcmp) reads
On Tuesday, 4 October 2016 at 01:59:11 UTC, Stefan Koch wrote:
On Tuesday, 4 October 2016 at 01:20:01 UTC, Manu wrote:
On 4 October 2016 at 04:21, Stefan Koch via Digitalmars-d
wrote:
On Monday, 3 October 2016 at 15:23:40 UTC, Jonathan Marler
wrote:
Yes, having the mixins expanded without
On Tuesday, 4 October 2016 at 01:20:01 UTC, Manu wrote:
On 4 October 2016 at 04:21, Stefan Koch via Digitalmars-d
wrote:
On Monday, 3 October 2016 at 15:23:40 UTC, Jonathan Marler
wrote:
Yes, having the mixins expanded without the surrounding code
would make it difficult to debug in some
On Monday, 3 October 2016 at 22:28:46 UTC, Andrei Alexandrescu
wrote:
Consider:
template SomethingCool(alias X) { alias Y = X!int; }
struct MyStruct(T) {
alias A = SomethingCool!MyStruct;
}
Inside MyStruct though, a mention of the symbol MyStruct alone
is actually the current instantiatio
On Monday, 3 October 2016 at 15:23:40 UTC, Jonathan Marler wrote:
Yes, having the mixins expanded without the surrounding code
would make it difficult to debug in some cases. Maybe
generating the entire source with the expanded mixins is
another option?
mycode.d
obj/mycode_processed.d
Th
On Sunday, 2 October 2016 at 12:27:23 UTC, Andrei Alexandrescu
wrote:
Yes, Stefan it would be terrific if you could keep an eye on it
while working on the engine. A file with properly handed
dependencies could serve as instantiation cache and save a ton
of re-instantiation waste. Thanks! -- A
On Sunday, 2 October 2016 at 03:36:31 UTC, Manu wrote:
This comes up a lot.
As far as I know, it's not solved. What shall we do?
I feel like a simple solution would be to have the compiler
emit a _mixin.d file populated with all the mixin
expansions beside the .obj files, and have the debuginf
On Saturday, 1 October 2016 at 19:54:13 UTC, Dicebot wrote:
On Saturday, 1 October 2016 at 15:06:44 UTC, Stefan Koch wrote:
The problem is the default template parameter Flag!"unsafe",
because fqn makes it into "cast(Flag)".
Getting this right is a bit tricky.
Isn't it a problem with library i
On Saturday, 1 October 2016 at 16:05:25 UTC, Andrei Alexandrescu
wrote:
https://issues.dlang.org/show_bug.cgi?id=16568
TIA! -- Andrei
Please post some code/instructions to reproduce the issue.
The fix for this will be quite simple create a directory with the
DDMMYY timestamp as directory nam
On Saturday, 1 October 2016 at 10:19:21 UTC, Dicebot wrote:
On 09/29/2016 07:02 PM, David Nadlinger wrote:
[...]
What are the issues with fullyQualifiedName in that context? I
mean other than Voldemort types of course. I'd expect `static
import` + `fullyQualifiedName` combo to be reasonably
On Friday, 30 September 2016 at 17:29:41 UTC, Dmitry Olshansky
wrote:
I know it's not unusual to rant about open bugs and such but
it's been 4 months and I'm helpless.
I had some nice breakthrough in std.regex performance back in
May but failed to deliver it to the mainline because of a bug:
On Thursday, 29 September 2016 at 18:37:36 UTC, Ilya Yaroshenko
wrote:
On Thursday, 29 September 2016 at 17:56:59 UTC, Stefan Koch
wrote:
Solution
T[] can be added to a template variadic name.
```
void foo(size_t[] Index...)(Indexes index)
{
...
}
```
This description does not tell me an
On Thursday, 29 September 2016 at 17:24:55 UTC, Ilya Yaroshenko
wrote:
Problem
Most ndslice API accepts variadic list of integers.
The following code example shows how `slice` and `[a, b, c]`
can generate 64 identical functions each.
```
// (1, 1U, 1UL, 1L) x
// (2, 2U, 2UL, 2L) x
// (3, 3U, 3U
On Thursday, 29 September 2016 at 16:30:56 UTC, Eugene Wissner
wrote:
The problem is you can never know all the use cases of some
feature. It is just pointless to try to predict where a user
will need a feature. I had a use case where I could be sure
that everything needed is imported and whe
On Thursday, 29 September 2016 at 13:58:44 UTC, Eugene Wissner
wrote:
On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch
wrote:
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch
wrote:
I would like to see users of fullyQualifiedName because apart
from binderoo code which
On Tuesday, 27 September 2016 at 01:17:16 UTC, Andrei
Alexandrescu wrote:
I'm not going to argue this much further. Essentially Mir is
touted as a highly generic and portable library. Having it only
work on one language implementation works against that
statement, the credibility of Mir, and th
On Monday, 26 September 2016 at 18:07:44 UTC, Jonathan Marler
wrote:
My dmd compiler gets an Access Violation when compiling this
code:
public template TemplateWrapper(T)
{
alias ToAlias = T;
}
public class Bar : Foo
{
TemplateWrapper!(Bar) something;
}
On Friday, 23 September 2016 at 15:30:20 UTC, Andrei Alexandrescu
wrote:
Work is blocked by
https://issues.dlang.org/show_bug.cgi?id=16528, which is quite
a head-scratcher. Any ideas for a workaround? Thanks! -- Andrei
annotate the templates.
On Friday, 23 September 2016 at 08:50:56 UTC, Timon Gehr wrote:
FQN disables UFCS. Nothing specific to operators here.
There is no reason why there should be any difference between a
+ b and a.opBinary!"+"(b). In fact, 2.opBinary!"+"(3) should
work too.
Currently this is tricky to implement
On Wednesday, 21 September 2016 at 18:34:13 UTC, Michael Coulombe
wrote:
On Wednesday, 21 September 2016 at 17:14:34 UTC, Stefan Koch
wrote:
That can and is being fixed.
Templates can only be fixed partially and I am not even sure
of that.
I am not suggesting to remove templates.
I just want
On Wednesday, 21 September 2016 at 16:11:04 UTC, WebFreak001
wrote:
Interesting talk. Templates are indeed slow but the reason why
I use them over CTFE functions (or why i leave out ctfe in
general and just use functions) is that they don't require 20
GB of RAM for some medium-simple tasks (l
Hi,
I just recorded a draft for a talk about templates and why they
are slow.
I'd be interested in questions and improvement suggestions.
I have uploaded it here :
http://www96.zippyshare.com/v/dlNhyACZ/file.html
On Monday, 19 September 2016 at 22:17:34 UTC, Mathias Lang wrote:
No you can't. The example is wrong, but Stefan is right.
Try it.
It got fixed a few versions ago.
Maybe it's broken again ?
I remember it working with 2.068
Hi,
The previous thread "[WORK] std.file.update function"
http://forum.dlang.org/thread/nrmb6b$2lc9$1...@digitalmars.com
quickly turned out to be a misnomer after a few posts about
object-file-formats and codegen.
Therefore I am opening this one.
Of course I do have something to say about th
On Monday, 19 September 2016 at 21:09:37 UTC, Jonathan Marler
wrote:
I don't know if I would call this a "destabalizing" language
change though. It should be backwards compatible with the
existing semantics. It adds an extra step to type deduction,
but this would be the very last step of ty
On Monday, 19 September 2016 at 20:21:30 UTC, Jonathan Marler
wrote:
Yes that's why the template cannot deduce the parameters. The
question is, when the parameters cannot be deduced, and they
are all optional, would it be reasonable for the compiler to
infer that the user intended to use the
On Monday, 19 September 2016 at 14:04:03 UTC, Andrei Alexandrescu
wrote:
Interesting. What happens e.g. if one makes a change to a
function whose generated code is somewhere in the middle of the
object file? If it doesn't alter the call graph, doesn't the
new .o file share a common prefix wit
On Monday, 19 September 2016 at 05:16:37 UTC, Walter Bright wrote:
I'd love to design our own high speed formats, but then they'd
be incompatible with everybody else's.
I'd like that as well.
I recently had a look at the ELF and the COFF file formats both
are definitely in need of rework an
On Sunday, 18 September 2016 at 15:17:31 UTC, Andrei Alexandrescu
wrote:
There are quite a few situations in rdmd and dmd generally when
we compute a dependency structure over sets of files. Based on
that, we write new files that overwrite old, obsoleted files.
Those changes in turn trigger oth
701 - 800 of 990 matches
Mail list logo
