https://issues.dlang.org/show_bug.cgi?id=16088
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #1 from
On Wednesday, 13 June 2018 at 09:40:05 UTC, Dukc wrote:
If I read your benchmark graphs right, they claimed that
allocating 16 kilobytes takes over 10^^6 usecs, with both
mallocs. Doesn't that mean over a second, 16 kilobytes? Can't
be! Are you confusing usecs with nsecs?
The benchmark
I've read up on Pony [1] and realized that it currently has a
superior implementation of the actor model when it comes to
combining safety, efficiency and memory management determinism
(thread-local reference-counting GC with consensus guarantees)
What libraries do we have at our disposal in
If this works:
template X(T)
{
static if(is(T t == S!n, int n))
{
static if(n == 0)
alias X = AliasSeq!();
else
alias X = S!0;
}
else
{
static assert(0);
}
}
class
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
I had a little fun today kicking the crap out of C's memcpy
with a D implementation.
If I read your benchmark graphs right, they claimed that
allocating 16 kilobytes takes over 10^^6 usecs, with both
mallocs. Doesn't that mean
On Wednesday, 13 June 2018 at 08:21:45 UTC, Martin Tschierschke
wrote:
Could D be an better choice for that purpose?
I would say yes. Especially if we're talking just replacing the C
code with D (using betterC.)
See:
https://dlang.org/blog/2018/06/11/dasbetterc-converting-make-c-to-d/
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
I had a little fun today kicking the crap out of C's memcpy
with a D implementation.
https://github.com/JinShil/memcpyD
Request for help: I don't have a Linux system running on real
hardware at this time, nor do I have a wide
Ubuntu 18.04 Linux 4.15.0-23-generic
AMD® Fx(tm)-8350 eight-core processor × 8
size memcpyC memcpyD
1 51089 36921
2 45896 35733
4 46079 36200
8 48443 37509
16 48669 24925
32 52917 27787
64 55631 44928
128 84282 47795
256 107350 66009
512 159310 126795
1024 247683 452560
2048 440687 673211
4096
https://issues.dlang.org/show_bug.cgi?id=12839
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
I had a little fun today kicking the crap out of C's memcpy
with a D implementation.
https://github.com/JinShil/memcpyD
Request for help: I don't have a Linux system running on real
hardware at this time, nor do I have a wide
The compilation is done by using the C compiler in the background.
https://www.ruby-lang.org/en/news/2018/05/31/ruby-2-6-0-preview2-released/
Could D be an better choice for that purpose?
Any comment?
https://issues.dlang.org/show_bug.cgi?id=18974
Simen Kjaeraas changed:
What|Removed |Added
Keywords||ice
CC|
Hello,
I'm having a hard time understanding whether this inconsistency
is a bug or intended behavior:
immutable class Foo {}
immutable struct Bar {}
void main()
{
import std.stdio : writeln;
Foo a;
Bar b;
writeln("typeof(a): ", typeof(a).stringof);
writeln("typeof(b): ",
On Tuesday, 12 June 2018 at 14:00:32 UTC, Steven Schveighoffer
wrote:
File.byLine is fast, but only because of the underlying
non-range tricks it uses to achieve performance. And iopipe
still is 2x faster.
I wish iopipe was around a little bit earlier so I could use it
in my small project.
On Wednesday, 13 June 2018 at 07:19:24 UTC, Gokhhy wrote:
Nevermind, it doesn't affect functions inside classes and
structs.
Yeah, that's kindof unfortunate isn't it. Just do the same thing
within the class/struct scope.
class C {
@nogc:
void nogcMethod1() {}
void nogcMehtod2()
On Wednesday, 13 June 2018 at 07:14:35 UTC, Gokhhy wrote:
On Wednesday, 13 June 2018 at 07:11:56 UTC, Mike Franklin wrote:
On Wednesday, 13 June 2018 at 06:45:27 UTC, Gokhhy wrote:
Is there a way to define an entire module as @nogc or
otherwise make it so I don't have to qualify every single
https://issues.dlang.org/show_bug.cgi?id=17712
--- Comment #13 from Basile B. ---
Other test case:
---
import std.datetime;
import std.typecons;
import std.variant;
Y a()
{
Y n = Y(Y[].init);
n.get!(X[]);
return n;
}
struct X
{
Y key;
}
struct Y
{
Algebraic!(Y[]) value_;
On Wednesday, 13 June 2018 at 06:45:27 UTC, Gokhhy wrote:
Is there a way to define an entire module as @nogc or otherwise
make it so I don't have to qualify every single function as
@nogc?
---
module module_wide-nogc;
@nogc:
/*
declarations or statements...
*/
---
But this is not
On Wednesday, 13 June 2018 at 06:45:27 UTC, Gokhhy wrote:
Is there a way to define an entire module as @nogc or otherwise
make it so I don't have to qualify every single function as
@nogc?
You can put attributes at the top of a module followed by a ":"
to have them apply to everything below
On Wednesday, 13 June 2018 at 07:11:56 UTC, Mike Franklin wrote:
On Wednesday, 13 June 2018 at 06:45:27 UTC, Gokhhy wrote:
Is there a way to define an entire module as @nogc or
otherwise make it so I don't have to qualify every single
function as @nogc?
You can put attributes at the top of a
I had a little fun today kicking the crap out of C's memcpy with
a D implementation.
https://github.com/JinShil/memcpyD
Request for help: I don't have a Linux system running on real
hardware at this time, nor do I have a wide range of platforms
and machines to test with. If you'd like to
Is there a way to define an entire module as @nogc or otherwise
make it so I don't have to qualify every single function as @nogc?
On Monday, 11 June 2018 at 19:05:21 UTC, Basile B. wrote:
On Monday, 11 June 2018 at 16:37:05 UTC, Basile B. wrote:
Russel Winder, "Shove" and finally myself, have encountered a
strange linker error with almost always the same symbols
related to a template instance...
See:
-
On Wednesday, 13 June 2018 at 06:10:26 UTC, Cym13 wrote:
That's very nice! Out of curiosity, what was the reason to
avoid a conventional stack? Or was it a consequence more than a
design decision? (If you've explained it before, feel free to
just throw the old post at me)
It was an initial
On Wednesday, 13 June 2018 at 05:57:31 UTC, Stefan Koch wrote:
Good day ladies and gentleman,
it is my distinct please to announce that a new feature just
landed in newCTFE.
!!! DELEGATES !!!
Nice!
On Wednesday, 13 June 2018 at 05:57:31 UTC, Stefan Koch wrote:
Good day ladies and gentleman,
it is my distinct please to announce that a new feature just
landed in newCTFE.
!!! DELEGATES !!!
this means the following code will now work:
int square_of_x_plus_x(int x) pure
{
int
Good day ladies and gentleman,
it is my distinct please to announce that a new feature just
landed in newCTFE.
!!! DELEGATES !!!
this means the following code will now work:
int square_of_x_plus_x(int x) pure
{
int passThrough(int y) pure
{
assert(x == y);
int y2 = x;
101 - 127 of 127 matches
Mail list logo
