global immutable integer Arrays are now completely functional!
This makes the following code work:
uint echo (uint val)
{
return val;
}
const(uint) fastLog10(const uint val) pure nothrow @nogc {
return (val < 10) ? 0 :
(val < 100) ? 1 :
(val < 1000)
On Friday, 30 December 2016 at 22:29:18 UTC, Chris Wright wrote:
* Performance improvements, primarily when a module imports
another,
bulky module for optional functionality.
That is solved by selective imports.
* Making it easier to locate where things are defined when
reading code.
That
On Thursday, 29 December 2016 at 18:21:30 UTC, Stefan Koch wrote:
Hi Guys,
I just figured out why array constants did not work as function
arguments.
It's because the array-constant undergoes a cast when used as
slice, while an array literal can be taken as is.
The currently newCTFE does
On Friday, 30 December 2016 at 18:11:54 UTC, deadalnix wrote:
I think the performance gain we are looking at here is
marginal, and I don't expect people to change their code to get
a marginal benefit, so I suggest the performance aspect of the
change to be simply left aside.
Yes, imports
On Thursday, 29 December 2016 at 21:19:18 UTC, Alexandru Ermicioi
wrote:
On Thursday, 29 December 2016 at 21:07:00 UTC, Stefan Koch
wrote:
It's a delegate and not function.
Therefore it will get a frame-ptr regardless, without checking
if it is needed or not, or if there is a frame to point
On Thursday, 29 December 2016 at 20:55:43 UTC, Alexandru Ermicioi
wrote:
Given code below:
import std.stdio;
struct Annotation {
public int delegate(int) dg;
}
void main() {
import std.traits;
__traits(getAttributes, Cls)[0].dg(20).writeln;
}
@Annotation(delegate
On Thursday, 29 December 2016 at 20:27:21 UTC, David Zhang wrote:
Hi,
I've noticed recently, that whenever I unittest, it program
hangs either at the very end, or right before they start. When
using vanilla unit tests, the program appears to hang after the
"All unit tests have been
Hi Guys,
I just figured out why array constants did not work as function
arguments.
It's because the array-constant undergoes a cast when used as
slice, while an array literal can be taken as is.
The currently newCTFE does not really provide the capabilities to
handle casts.
This is another
On Tuesday, 27 December 2016 at 18:22:12 UTC, unDEFER wrote:
On Tuesday, 27 December 2016 at 18:01:36 UTC, Stefan Koch wrote:
Have you tried assigning it to a variable ?
Yes, I have tried, now backtrace of hanged process is:
(gdb) bt
#0 0x7f4e18260c6d in ?? ()
#1 0x in
On Tuesday, 27 December 2016 at 18:00:11 UTC, unDEFER wrote:
On Tuesday, 27 December 2016 at 17:50:14 UTC, Stefan Koch wrote:
The string is allocated on the gc-ed heap.
And since it's an R value it might get destroyed before execl
is finished.
Assign the result of toStringz to a char* variable
On Tuesday, 27 December 2016 at 17:50:15 UTC, Joseph Rushton
Wakeling wrote:
Hello all,
[ ... ]
Can anyone advise what could be going wrong here? This looks
like a nasty CTFE bug to me :-(
Thanks & best wishes,
-- Joe
I doubt that this is a CTFE bug since there should be little
On Tuesday, 27 December 2016 at 17:27:14 UTC, unDEFER wrote:
Hello I have very simple line with exec-command:
execl("/bin/bash".toStringz(), "/bin/bash".toStringz(),
"-c".toStringz(), command.toStringz(), null);
[...]
The string is allocated on the gc-ed heap.
And since it's an R value it
On Sunday, 25 December 2016 at 15:26:36 UTC, Stefan Koch wrote:
I reverted my ArrayLiteral fixes for now,
they broke the druntime build.
So far by attempts to fix this situation, proved fruitless.
However this getting global static variables to work correctly is
a high-priority goal, as it
On Sunday, 25 December 2016 at 19:16:03 UTC, Martin Nowak wrote:
Just a few infos on using perf and related tools for profiling
on linux.
https://code.dawg.eu/profiling-with-perf-and-friends.html
Nice article.
There is a nice gui tool for the same purpose,
On Sunday, 25 December 2016 at 19:22:10 UTC, aliak wrote:
Hey,
So, been using the programming language swift for a while now,
the optional types[1] they support makes working with
maybe-type (ala haskell) values extremely pleasant.
[...]
Well there is one easy way to do this.
pass a
On Sunday, 25 December 2016 at 12:21:42 UTC, Stefan Koch wrote:
On Sunday, 25 December 2016 at 11:27:07 UTC, Stefan Koch wrote:
static immutable alr = arrayLiteralReturn();
static assert(alr == [1,2,3]);
There were a few problems with that.
Namely some arrays-literals would not have a length.
On Sunday, 25 December 2016 at 11:27:07 UTC, Stefan Koch wrote:
static immutable alr = arrayLiteralReturn();
static assert(alr == [1,2,3]);
There were a few problems with that.
Namely some arrays-literals would not have a length.
This is because of literals coercing to slices.
This bug is now
static immutable alr = arrayLiteralReturn();
static assert(alr == [1,2,3]);
There were a few problems with that.
Namely some arrays-literals would not have a length.
This is because of literals coercing to slices.
This bug is now fixed, at the expense of registering more types
then is strictly
On Saturday, 24 December 2016 at 17:52:04 UTC, Chris Wright wrote:
The minimum isn't terribly useful because it gets to the point
of testing the process scheduler and IO more than the compiler.
If we want numbers that we can trust on the low end, we'll need
to put timing information into the
On Saturday, 24 December 2016 at 15:44:18 UTC, Andrei
Alexandrescu wrote:
On 12/24/16 9:20 AM, Stefan Koch wrote:
On Saturday, 24 December 2016 at 14:08:48 UTC, Andrei
Alexandrescu wrote:
On 12/24/2016 05:54 AM, Stefan Koch wrote:
If that were made more lazy, we could import half of the
world
On Saturday, 24 December 2016 at 16:10:04 UTC, Stefan Koch wrote:
Some progress on && has been made.
It can now be used within an if.
It is only enabled if debug = andnd is given.
This introduced a bug which is now fixed.
Furthermore returning of 64bit integral values has now been
enabled.
I
Some progress on && has been made.
It can now be used within an if.
It is only enabled if debug = andnd is given.
On Saturday, 24 December 2016 at 14:08:48 UTC, Andrei
Alexandrescu wrote:
On 12/24/2016 05:54 AM, Stefan Koch wrote:
If that were made more lazy, we could import half of the world
with
noticing impact.
That is what 1005 will bring. -- Andrei
A compiler enhancement can do this _without_ a
On Saturday, 24 December 2016 at 12:42:31 UTC, Andrew Edwards
wrote:
The authors of "The Art of Java" present, as a first coding
example, a recursive-descent parser to demonstrate Java's
ability to facilitate low level programming commonly performed
in C and C++.
I took the opportunity to
On Saturday, 24 December 2016 at 00:55:01 UTC, Yuxuan Shui wrote:
I tried this:
immutable int[char] xx = ['Q':0, 'B':1, 'N':2, 'R':3,
'P':4];
And got a "non-constant expression" error (with or without
'immutable').
What's the correct way?
You cannot initialize an AA at compile-time.
On Saturday, 24 December 2016 at 10:54:08 UTC, Stefan Koch wrote:
300 microseconds, which is not even 0.3% of the time spent.
Lexing them requires additionally also about 300 microseconds.
So Together that makes up 0.6% of the time spent.
Of course in the above 3% and 6% are the right numbers.
On Saturday, 24 December 2016 at 09:34:03 UTC, Andrei
Alexandrescu wrote:
(I confirm that importing std.traits, std.meta, and
std.range.primitives together takes 10ms.)
while compiling std.traits 6 files are opened and read into
memory,
taking roughly 300 microseconds, which is not even 0.3%
On Saturday, 24 December 2016 at 01:38:24 UTC, safety0ff wrote:
On Friday, 23 December 2016 at 22:11:31 UTC, Walter Bright
wrote:
For this D code:
enum SIZE = 1;
void foo(int* a, int* b) {
int* atop = a + 1000;
ptrdiff_t offset = b - a;
for (; a < atop; ++a)
*a &=
On Friday, 23 December 2016 at 18:33:52 UTC, Seb wrote:
On Friday, 23 December 2016 at 18:03:54 UTC, hardreset wrote:
I get..
456ms for unconditional
505ms for conditional
268ms for assembler
So the asm is about 40% faster than the best of the
alternatives. The point being that it's the
On Friday, 23 December 2016 at 11:31:14 UTC, Stefan Koch wrote:
On Friday, 23 December 2016 at 10:25:57 UTC, Stefan Koch wrote:
On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch
wrote:
I just fixed the "" case for StringLiterals.
This exposed bugs in the code-generator because now
On Friday, 23 December 2016 at 10:25:57 UTC, Stefan Koch wrote:
On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch
wrote:
I just fixed the "" case for StringLiterals.
This exposed bugs in the code-generator because now
phobos-unittests with "" are run.
(Which would previously be
On Thursday, 22 December 2016 at 20:34:50 UTC, Stefan Koch wrote:
I just fixed the "" case for StringLiterals.
This exposed bugs in the code-generator because now
phobos-unittests with "" are run.
(Which would previously be counted as uncompilable)
Apparently we run into a situation where
On Friday, 23 December 2016 at 06:53:25 UTC, Observer wrote:
[ ... ]
A pure function MUST NOT mutate any state except what is
reachable through it's arguments.
This includes ANY operating system state.
As for your debugger point.
You can break on a pure function as well as on any other.
And,
I just fixed the "" case for StringLiterals.
However the fix is quite hackish and needs to be revisited soon.
Furthermore I have made a few more preparations for function call
support.
The reason why I am a bit reculant to enable function calls is
the vast increase of bug-attack-surface.
On Thursday, 22 December 2016 at 18:04:51 UTC, Observer wrote:
(1) Serve as a convenient breakpoint handle in the debugger,
perhaps
as a kind of centralized this_cannot_ever_happen() function.
(2) conditionally_die(conditions);
(3) Sleep for some run-time-computable length of time.
(4)
On Thursday, 22 December 2016 at 15:21:08 UTC, Nordlöw wrote:
On Thursday, 22 December 2016 at 12:47:12 UTC, Stefan Koch
wrote:
Hey Guys,
Pointers support is coming!
Awesome!
Are there any D language features working in newCTFE that
doesn't work on current upstream master?
None at the
Hey Guys,
Pointers support is coming!
The following code compiles now:
uint* fn(uint v)
{
return new uint(v + 6);
}
static assert(*fn(5) == 11);
On Thursday, 22 December 2016 at 03:18:42 UTC, Jerry wrote:
Not using AliasSeq if that's what you mean. I don't know if the
"tupleof" for a struct would be considered the same as "T..."
but basically what I was doing:
foreach(ref field; myLargeStruct.tupleof)
{
}
Yes that is a
On Thursday, 22 December 2016 at 02:32:30 UTC, Jerry wrote:
On Thursday, 22 December 2016 at 01:57:55 UTC, safety0ff wrote:
On Thursday, 22 December 2016 at 01:30:44 UTC, Andrei
Alexandrescu wrote:
Must be a pathological case we should fix anyway. -- Andrei
Likely related bug has been open
On Wednesday, 21 December 2016 at 15:40:42 UTC, Andrei
Alexandrescu wrote:
On 12/20/2016 05:49 PM, Andrei Alexandrescu wrote:
https://github.com/dlang/dlang.org/pull/1528 -- Andrei
Dropped the void functions. On to the next scandal:
A function that accepts only parameters without mutable
On Tuesday, 20 December 2016 at 20:30:43 UTC, Nordlöw wrote:
On Tuesday, 20 December 2016 at 16:53:21 UTC, Stefan Koch wrote:
I hope that my reports give a little insight into what issues
I am facing, and why it is taking so long.
There's a left parenthesis too much on line 3320 in ctfe_bc.d
On Tuesday, 20 December 2016 at 17:15:53 UTC, Ilya Yaroshenko
wrote:
Are they already CTFEable? I have not seen an anounce, sorry
They have been for years now.
Of course only pointers from a CTFE context are valid at ctfe.
The new engine will support them as well, (as it will eventually
On Tuesday, 20 December 2016 at 16:57:34 UTC, Ilya Yaroshenko
wrote:
On Tuesday, 20 December 2016 at 16:34:04 UTC, Walter Bright
wrote:
On 12/20/2016 6:08 AM, Ilya Yaroshenko wrote:
No, tuples stores either value or pointer. If it stores
pointer then it is not
safe and it is not CTFE.
You
Hey Guys I wanted to give a quick update.
I recently fixed an interesting bug that happened de-referencing
null pointers to the heap.
That would cause arrays to be overwritten, when passed as
arguments.
That bug had me stuck for a few hours.
Getting Function-Calls right will be impossible,
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
On Monday, 19 December 2016 at 08:14:44 UTC, Basile B. wrote:
I know that there is other hot stuffs since a few days but this
is a really simple DIP, that has no effect on the grammar and
no effect on the semantic. It was drafted after the announce of
DIP 1003 last week. During a discussion
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
On Sunday, 18 December 2016 at 14:22:29 UTC, Joakim wrote:
I was looking at the most popular videos from CppCon and the
second-most popular from the last three years is the one on
data-oriented design:
https://youtube.com/watch?v=1OEu9C51K2A
The wikipedia page has a summary, basically
On Sunday, 18 December 2016 at 11:47:06 UTC, Jacob Carlborg wrote:
I think any module with more than 2000 lines of code is too big.
newCTFE has more than 2000 lines of code and is still growing,
There is no way it could be split up.
On Sunday, 18 December 2016 at 09:32:53 UTC, Caspar Kielwein
wrote:
On Thursday, 15 December 2016 at 18:48:22 UTC, Andrei
Alexandrescu wrote:
https://issues.dlang.org/show_bug.cgi?id=16975
I'd love if preconditions where available at the caller. This
would make it possible to use
On Sunday, 18 December 2016 at 04:46:34 UTC, Timothee Cour wrote:
Could we support something similar to nim's compilation option
pragmas [1]:
```
{.push checks: off.}
# compile this section without runtime checks as it is speed
critical
# ... some code ...
{.pop.} # restore old settings
```
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
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
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
On Friday, 16 December 2016 at 06:47:15 UTC, KaattuPoochi wrote:
On Tuesday, 13 December 2016 at 21:13:26 UTC, Ali wrote:
And extending Ali's solution you can actually get the data in
to a two dimentional array at compile time and have it in
static memory with a small adjustment:
static
On Thursday, 15 December 2016 at 19:30:08 UTC, Ali Çehreli wrote:
Yeah, I think the compiler is confused because the function is
called in a non-const context during the initialization of an
immutable object.
I would open an issue:
https://issues.dlang.org/enter_bug.cgi?product=D
Ali
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
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
On Thursday, 15 December 2016 at 05:53:42 UTC, Ilya Yaroshenko
wrote:
Please, no :-(
Mir needs betterC DMD FE
What for ?
Are you using the compiler frontend ?
And the frontend is not only using the betterC subset.
So you could not be using it right now.
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
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 Wednesday, 14 December 2016 at 06:00:08 UTC, Era Scarecrow
wrote:
Aside from just counting the results, is this going to
possibly affect compilation/code generation to get speed/size
optimization?
Well Yes.
That is the plan at least :)
CTFE could stream it's branch-counts directly into
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.
On Wednesday, 14 December 2016 at 05:07:17 UTC, Stefan Koch wrote:
Hi Guys,
Implementing and TESTING function-call support is boring so ...
I have just written a little piece of code that counts which
switch-cases are executed most frequently versus how often
their conditions are evaluated.
Hi Guys,
Implementing and TESTING function-call support is boring so ...
I have just written a little piece of code that counts which
switch-cases are executed most frequently versus how often their
conditions are evaluated.
This can essentially be the basis for pgo based on the
On Tuesday, 13 December 2016 at 22:15:13 UTC, Stefan Koch wrote:
I have noticed severe code-bloat at ctfe, and worse when
ctfe-codegen miscompiles those templates,
there in way to know why!
Was meant to say.
there is no way to know why.
On Tuesday, 13 December 2016 at 18:52:05 UTC, Andrei Alexandrescu
wrote:
* People have noticed that certain simple uses of D trigger
calls into druntime that are not quite justified. For example,
assigning an array of int to another array of int issues a call
into a function that uses dynamic
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
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
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
On Sunday, 11 December 2016 at 22:48:56 UTC, Chris Wright wrote:
On Sun, 11 Dec 2016 18:08:04 +, safety0ff wrote:
[...]
That's one option. Here's another:
Template instantiations are interned as they are constructed
(or at least should be). You must construct their arguments
before you
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
On Sunday, 11 December 2016 at 19:40:21 UTC, safety0ff wrote:
On Sunday, 11 December 2016 at 19:00:23 UTC, Stefan Koch wrote:
Just use this little program to simulate the process.
That's not really useful for understanding and making progress
on the issue.
I had a patch with improved hash
On Sunday, 11 December 2016 at 18:08:04 UTC, safety0ff wrote:
On Sunday, 11 December 2016 at 17:20:24 UTC, Stefan Koch wrote:
That means you have to compute the mangled name which is crazy
expensive.
And you can't cache the parent part of mangle because it all
freshly generated by the
On Sunday, 11 December 2016 at 17:04:24 UTC, safety0ff wrote:
On Sunday, 11 December 2016 at 16:26:29 UTC, Ethan Watson wrote:
At the very least, I now have an idea of which parts of the
compiler I'm taxing and can attempt to write around that. But
I'm also tempted to go in and optimise
On Sunday, 11 December 2016 at 16:26:29 UTC, Ethan Watson wrote:
But
I'm also tempted to go in and optimise those parts of the
compiler.
I already what I could to optimize those parts.
whatever you manage to squeeze out.
It's not going to do much good.
The templates you are using are by their
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
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
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
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
On Sunday, 11 December 2016 at 02:09:41 UTC, Orut wrote:
D nub here. I have a Python script that I'd like to implement
in D. For certain parts, the D equivalent was slower than
Python's. For example,
Python code:
#dummy code
s = ["abc", "fjkd", "L", "qwa", "r", "uw", "tiro", "bc", "sg",
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 +
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
On Saturday, 10 December 2016 at 08:41:56 UTC, Suliman wrote:
import std.stdio;
import std.concurrency;
void main()
{
void sp(int i)
{
receive((int i)
{
writeln("i: ", i);
});
}
auto r = new Generator!int(
{
foreach(i; 1
On Saturday, 10 December 2016 at 08:16:48 UTC, Is it possible to
store different generic types? wrote:
On Saturday, 10 December 2016 at 08:09:00 UTC, Is it possible
to store different generic types? wrote:
[...]
Okay the issue seem to be that D casts the left-hand argument
to the same type as
On Saturday, 10 December 2016 at 01:48:24 UTC, Ali Çehreli wrote:
On 12/09/2016 05:34 PM, Stefan Koch wrote:
On Friday, 9 December 2016 at 18:52:59 UTC, Ali Çehreli wrote:
I thought I needed something like staticIota in a unittest to
effect
static foreach over a number range and I found one in
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
On Friday, 9 December 2016 at 18:52:59 UTC, Ali Çehreli wrote:
I thought I needed something like staticIota in a unittest to
effect static foreach over a number range and I found one in
druntime's implementation:
https://github.com/dlang/druntime/blob/master/src/core/internal/traits.d#L106
On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote:
Hello,
we've just open sourced a small module ("accessors") that helps
to generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors
It takes advantage of the
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
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--)
{
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
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
801 - 900 of 1565 matches
Mail list logo
