Re: std.csv Performance Review
On Sunday, 4 June 2017 at 06:54:46 UTC, Patrick Schluter wrote: On Sunday, 4 June 2017 at 06:15:24 UTC, H. S. Teoh wrote: On Sun, Jun 04, 2017 at 05:41:10AM +, Jesse Phillips via (Note that this is much less of a limitation than it seems; for example you could use std.mmfile to memory-map the file into your address space so that it doesn't actually have to fit into memory, and you can still take slices of it. The OS will manage the paging from/to disk for you. Of course, it will be slower when something has to be paged from disk, but IME this is often much faster than if you read the data into memory yourself. If the file is in the file cache of the kernel, memory mapping does not need to reload the file as it is already in memory. In fact, calling mmap() changes only the sharing of the pages in general. That's where most of the performance win from memory mapping comes from. To be precise, it's the copying of data that is spared by mmap. If the file is in the file cache, the open/read/write/close syscalls will also be fed from the memory mapped cache entry, but this requires that the data is copied from the kernel memory space to the processes buffer space. So each call to read will have to do this copying. So the gain from mmap comes for avoiding the copy of memory and avoiding the syscalls read/write/seek. The loading in memory of the physical file is the same in both cases. This stackoverflow [1] discussion links to a realworldtech discussion with Linus Torvalds explaining it in detail. On windows and Solaris the mechanism is the same. [1] https://stackoverflow.com/questions/5902629/mmap-msync-and-linux-process-termination/6219962#6219962
Re: std.csv Performance Review
On Saturday, 3 June 2017 at 04:25:27 UTC, Jesse Phillips wrote: Even though the issue can be ignored, the overhead of parsing to identify issues still remains. I haven't attempted write the algorithm assuming proper data structure so I don't know what the performance would look like, but I suspect it isn't negligible. There is also likely some overhead for providing the tokens through range interfaces. Immediate idea is to have the cake and eat it too with parseXML!(Yes.validate)(...), but more work.
Re: C++17 cannot beat D surely
On Saturday, June 03, 2017 22:38:24 H. S. Teoh via Digitalmars-d wrote: > On Sat, Jun 03, 2017 at 03:00:56PM -0700, Ali Çehreli via Digitalmars-d wrote: > > On 06/03/2017 12:12 PM, Steven Schveighoffer wrote: > > > I'd say this deserves a blog post but it would be too short. > > > > I made many good friends at C++Now. Some of them know Atila from > > CppCon and other C++ conferences. (Beer involved. :) ) They told me > > Atila would routinely tell them during C++ presentations "This > > wouldn't be a talk at a DConf; it's a language feature in D." :) > > [...] > > In this case, I'd say "this wouldn't be an article about D; it's a > language feature." :-D > > Though I'd say we *could* add meat to the article by explaining what > exactly CTFE is, how it works, and why you could just call the standard > library sort at compile-time and have it Just Work(tm) without having to > jump through hoops. > > And perhaps demonstrate how easy it is to do this not just with sort, > but with far more complex things. In fact, significant chunks of Phobos > are now available at CTFE. For example, you can call std.format at > compile-time to perform some pretty hairy string formatting and have the > result baked into your executable so that you incur none of the cost of > computing it at runtime. > > The best part of all this is, as long as you have already written > runtime code that's CTFE-compatible, you don't have to do anything else > to make it work at compile-time. No messing around with constexpr, no > awkward special syntax, no need to jump through hoops, invoke arcane > black magic, etc.. Just call the code with normal runtime syntax from an > expression whose value needs to be known at compile-time, and the > compiler does the rest of you. > > And if you need a particular functionality both at compile-time and > during runtime, there's no need to write it twice in two different > sublanguages. You just write one function once, and call it from both > CTFE and at runtime. It Just Works(tm). > > Then we could add the icing on the cake by showing off one of > Andrei's(?) little gems in std.random: a RNG generator that checks *at > compile-time* whether a particular set of RNG parameters would produce a > poor-quality RNG, and abort with a compile-error if so. Meaning that if > the thing compiles at all, you have a minimum quality guarantee. (This > particular gem is described in detail in TDPL, btw, and is one of the > things about D that blew me away when I first read it.) Be careful, or Mike will start hounding you to write the actual article. ;) - Jonathan M Davis
Sorting in D Blog Post Review Request
As a result of the ongoing thread, 'C++17 cannot beat D surely' [1], I've slapped together a blog post about it all. A post about CTFE sort in D by itself would be rather short. So I also wrote about two points of the confusion (one of which was my own) that arose in the thread. I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors. Thanks in advance. [1] http://forum.dlang.org/post/bhdehyzrlfklfkxic...@forum.dlang.org [2] https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3
Re: C++17 cannot beat D surely
On Sunday, 4 June 2017 at 07:49:36 UTC, Jonathan M Davis wrote: Be careful, or Mike will start hounding you to write the actual article. ;) - Jonathan M Davis It's already written! And I'm looking for reviewers [1] so I can get it in shape in time to publish Monday. [1] http://forum.dlang.org/post/mosjryaaatmhqcpim...@forum.dlang.org
Re: Sorting in D Blog Post Review Request
On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote: I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors. https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3 Added a couple of comments.
Re: Sorting in D Blog Post Review Request
On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote: As a result of the ongoing thread, 'C++17 cannot beat D surely' [1], I've slapped together a blog post about it all. A post about CTFE sort in D by itself would be rather short. So I also wrote about two points of the confusion (one of which was my own) that arose in the thread. I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors. Thanks in advance. [1] http://forum.dlang.org/post/bhdehyzrlfklfkxic...@forum.dlang.org [2] https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3 I don't think this is a good response to the original post, diving into a bunch of arcana about initialization and allocation rather than showing how simple D's compile-time sort is. It'd be better to just have a nuts and bolts post showing how the _same_ code can be done much easier in D, including actually showing D's quicksort and maybe mentioning __ctfe, then show how easy it is to do something much more advanced in D, like Teoh said. This post goes off on a couple tangents, maybe it could be a follow-up blog post after one addressing the original C++ post.
Re: A Few thoughts on C, C++, and D
On Thursday, 1 June 2017 at 12:04:40 UTC, Jacob Carlborg wrote: So DStep works, just that will generate platform specific bindings. That is good enough if it is integrated with the compiler then.
Re: C++17 cannot beat D surely
On Sat, 2017-06-03 at 19:12 +, Steven Schveighoffer via
Digitalmars-d wrote:
> On Saturday, 3 June 2017 at 17:32:41 UTC, Andrei Alexandrescu
> wrote:
> > On 06/03/2017 01:03 PM, Russel Winder via Digitalmars-d wrote:
> > > Björn Fahller has done compile time sort in C++17 here
> > > http://playfulpr
> > > ogramming.blogspot.co.uk/2017/06/constexpr-quicksort-in-c17.html
> > >
> > > Surely D can do better?
> >
> > There is nothing to do really. Just use standard library sort.
> >
> > void main() {
> > import std.algorithm, std.stdio;
> > enum a = [ 3, 1, 2, 4, 0 ];
> > static auto b = sort(a);
> > writeln(b);
> > }
>
> I'd say this deserves a blog post but it would be too short.
>
> -Steve
a. that was my point in making the original post; and
b. no it isn't, it is the right length.
It would make a great article for Overload.
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
Re: Question to GC experts: NO_SCAN for a part of the block
On 06/04/2017 03:08 AM, Stanislav Blinov wrote:
---
import core.memory : GC;
import std.stdio;
import std.typecons;
class C {
int i;
this(int i) {
this.i = i;
}
~this() {
writeln("C(", i, ") dtor");
}
}
[...]
auto selective(int numCs, int numBytes) {
[...]
auto memory = GC.malloc(numCs*C.sizeof + numBytes*byte.sizeof,
GC.BlkAttr.NO_SCAN);
auto cs = (cast(C*)memory)[0..numCs];
cs[] = C.init;
// add scanning range for references
GC.addRange(cs.ptr, cs.length*C.sizeof, typeid(C));
auto bytes = (cast(byte*)(memory + numCs*C.sizeof))[0..numBytes];
bytes[] = byte.init;
return tuple!("Cs", "bytes")(cs, bytes);
}
void main() {
int numCs = 4; // comes at runtime from elsewhere
int numBytes = 32; // comes at runtime from elsewhere
[...]
int counter;
[...]
auto arrays3 = selective(numCs, numBytes);
foreach (ref e; arrays3.Cs)
e = new C(counter++); // dtors will not be called
}
---
Should this work, and if not, why?
As far as I can tell, the `addRange` call works correctly, but maybe too
well in a sense. It keeps the `new`ed `C`s alive as long as `arrays3.Cs`
has pointers to them. And `arrays3.Cs` has those pointers until the very
end.
If you add `GC.removeRange(arrays3.Cs.ptr);` at the of `main`, the dtors
show up. Overwriting `arrays3.Cs`'s elements with `null`s also works. My
guess is that the `removeRange` call isn't done automatically before the
final run of the GC. Maybe it should be?
But I have a vague memory that the GC isn't required to call destructors
on everything in the final run. Or maybe it's not guaranteed that there
is a final run when the program ends? Anyway, that would mean
everything's working as intended, and you just can't rely on destructors
like that.
Re: Question to GC experts: NO_SCAN for a part of the block
On Sunday, 4 June 2017 at 09:38:45 UTC, ag0aep6g wrote: Should this work, and if not, why? As far as I can tell, the `addRange` call works correctly, but maybe too well in a sense. It keeps the `new`ed `C`s alive as long as `arrays3.Cs` has pointers to them. And `arrays3.Cs` has those pointers until the very end. Yeah, after playing around with the code a bit, shuffling the calls, making new allocations, etc., I saw those dtors indeed being run. I was just expecting the behavior to be the same as for normal 'new'ed arrays, but I guess there are nuances. If you add `GC.removeRange(arrays3.Cs.ptr);` at the of `main`, the dtors show up. Yeah, well, calling it manually sort of defeats the purpose :) Overwriting `arrays3.Cs`'s elements with `null`s also works. My guess is that the `removeRange` call isn't done automatically before the final run of the GC. Maybe it should be? If at all possible, I think that'd be good, if only for consistency. But I have a vague memory that the GC isn't required to call destructors on everything in the final run. Or maybe it's not guaranteed that there is a final run when the program ends? That's what puzzled me, seeing as dtors from the other two arrays ran at the end. I understand how particular dtors may not be run due to circular or self-references, but there are none in this case. Anyway, that would mean everything's working as intended, and you just can't rely on destructors like that. Seems it is, and that is great. Now all that's left is some benchmarking to see if saving on allocations actually yields any fruit. Thanks!
Re: C++17 cannot beat D surely
Could someone clarify why the generated assembly for
void main() @nogc {
import std.algorithm;
enum a = [3, 1, 2, 0]; // inferred to be int[]
enum b = sort(a);
static assert(b[0] == 0);
}
is 1380 lines with ldc 1.3.0 (-O3 -release -betterC -flto=full)?
You can see the result on godbolt here:
https://godbolt.org/g/BNRnO9
It's kind of surprising compared to C++'s 2 lines:
https://godbolt.org/g/vXrxaY
Re: C++17 cannot beat D surely
On 04/06/2017 11:06 AM, Vittorio Romeo wrote:
Could someone clarify why the generated assembly for
void main() @nogc {
import std.algorithm;
enum a = [3, 1, 2, 0]; // inferred to be int[]
enum b = sort(a);
static assert(b[0] == 0);
}
is 1380 lines with ldc 1.3.0 (-O3 -release -betterC -flto=full)?
You can see the result on godbolt here:
https://godbolt.org/g/BNRnO9
It's kind of surprising compared to C++'s 2 lines:
https://godbolt.org/g/vXrxaY
_Dmain is exactly 2 instructions, so nope equivalent :)
The linker isn't stripping out unused symbols however (from what I can
tell).
Re: C++17 cannot beat D surely
On Sunday, 4 June 2017 at 10:21:16 UTC, rikki cattermole wrote:
On 04/06/2017 11:06 AM, Vittorio Romeo wrote:
Could someone clarify why the generated assembly for
void main() @nogc {
import std.algorithm;
enum a = [3, 1, 2, 0]; // inferred to be int[]
enum b = sort(a);
static assert(b[0] == 0);
}
is 1380 lines with ldc 1.3.0 (-O3 -release -betterC
-flto=full)?
You can see the result on godbolt here:
https://godbolt.org/g/BNRnO9
It's kind of surprising compared to C++'s 2 lines:
https://godbolt.org/g/vXrxaY
_Dmain is exactly 2 instructions, so nope equivalent :)
The linker isn't stripping out unused symbols however (from
what I can tell).
I see. Is there any argument that can be passed to ldc in order
to strip the unused symbols?
Re: C++17 cannot beat D surely
On 04/06/2017 11:27 AM, Vittorio Romeo wrote:
On Sunday, 4 June 2017 at 10:21:16 UTC, rikki cattermole wrote:
On 04/06/2017 11:06 AM, Vittorio Romeo wrote:
Could someone clarify why the generated assembly for
void main() @nogc {
import std.algorithm;
enum a = [3, 1, 2, 0]; // inferred to be int[]
enum b = sort(a);
static assert(b[0] == 0);
}
is 1380 lines with ldc 1.3.0 (-O3 -release -betterC -flto=full)?
You can see the result on godbolt here:
https://godbolt.org/g/BNRnO9
It's kind of surprising compared to C++'s 2 lines:
https://godbolt.org/g/vXrxaY
_Dmain is exactly 2 instructions, so nope equivalent :)
The linker isn't stripping out unused symbols however (from what I can
tell).
I see. Is there any argument that can be passed to ldc in order to strip
the unused symbols?
Should be a way, since you can pass arg directly via ldc to ld. But I
would expect it to have done it by default anyway.
Re: C++17 cannot beat D surely
On Sunday, 4 June 2017 at 10:27:14 UTC, Vittorio Romeo wrote: I see. Is there any argument that can be passed to ldc in order to strip the unused symbols? Doesn't the strip command work?
Re: C++17 cannot beat D surely
On Sunday, 4 June 2017 at 14:13:24 UTC, Ola Fosheim Grøstad wrote: On Sunday, 4 June 2017 at 10:27:14 UTC, Vittorio Romeo wrote: I see. Is there any argument that can be passed to ldc in order to strip the unused symbols? Doesn't the strip command work? Oh wait, you didn't mean symbols, you meant code. LLVM has passes for that: https://blog.quarkslab.com/global-dead-code-elimination-for-llvm-revisited.html
Re: std.csv Performance Review
On Sunday, 4 June 2017 at 06:15:24 UTC, H. S. Teoh wrote: On Sun, Jun 04, 2017 at 05:41:10AM +, Jesse Phillips via Digitalmars-d wrote: On Saturday, 3 June 2017 at 23:18:26 UTC, bachmeier wrote: > Do you know what happened with fastcsv [0], original thread > [1]. > > [0] https://github.com/quickfur/fastcsv > [1] > http://forum.dlang.org/post/mailman.3952.1453600915.22025.digitalmars-d-le...@puremagic.com I do not. Rereading that in light of this new article I'm a little sceptical of the 51 times faster, since I'm seeing only 10x against these other implications. [...] You don't have to be skeptical, neither do you have to believe what I claimed. I posted the entire code I used in the original thread, as well as the URLs of the exact data files I used for testing. You can just run it yourself and see the results for yourself. Ok, I took you up on that, I'm still skeptical: LDC2 -O3 -release -enable-cross-module-inlining std.csv: 12487 msecs fastcsv (no gc): 1376 msecs csvslicing: 3039 msecs That looks like about 10 times faster to me. Using the slicing version failed because of \r\n line endings (guess multi-part separators is broken) I changed the data file so I could get the execution time. Anyway, I'm not trying to claim fastcsv isn't good at what it does, all I'm trying to point out is std.csv is doing more work than these faster csv parsers. And I don't even want to claim that std.csv is better because of that work, it actually appears that it was a mistake to do validation.
Re: DMD VS2017 Support
On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: On 01.05.2017 10:03, Igor wrote: On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote: [...] That was it. It didn't occur to me that this was the problem because I payed closed attention during VisualD installation and saw it properly recognized where DMD was installed but for some reason the path wasn't set in Options. Once I did set it, compile and build worked. Thanks evilrat! So in conclusion it seems the problem is in VisualD installation which doesn't set the path properly even though it recognizes where DMD is installed. Hope the author takes a look at this problem so beginners wanting to try D don't give up on a problem like this. VS 2017 uses a "private" registry that the Visual D installer doesn't have access to. I'll change the registry location in the next release. Please note that the next dmd installer will also detect VS2017 and setup directories correctly in sc.ini: https://github.com/dlang/installer/pull/227 Today I saw that a new DMD version had been released. So I downloaded it (dmd-2.074.1.exe). Unfortunately, the installer does *not* detect VS2017, instead it asks me to install VS2013 for x64 support.
Re: Sorting in D Blog Post Review Request
On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote: I've slapped together a blog post about it all. So I took the feedback I've gotten so far, stepped away and thought about it for a bit, and agreed that I was taking the wrong approach. So I've given it a rewrite. The original gist is still there, but the new one is here: https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453 I'm open to any changes or additions anyone would like to make. That includes rewriting large portions of it (or all of it, if anyone is up for it). Destroy!
Re: Value closures (no GC allocation)
On Sunday, 21 May 2017 at 00:33:30 UTC, Vittorio Romeo wrote: Hello everyone, I recently started learning D (I come from a Modern C++ background) and I was curious about closures that require GC allocation. I wrote this simple example: [...] I started to do some changes to the compiler. https://github.com/MakersF/dmd/tree/valuelambda It's my first time messing with DMD, it's mostly to familiarize myself with the compiler, so I don't expect to do everything the right way. Let me know if you have inputs.
Re: Sorting in D Blog Post Review Request
On Sunday, 4 June 2017 at 16:07:35 UTC, Mike Parker wrote: On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote: I've slapped together a blog post about it all. So I took the feedback I've gotten so far, stepped away and thought about it for a bit, and agreed that I was taking the wrong approach. So I've given it a rewrite. The original gist is still there, but the new one is here: https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453 I'm open to any changes or additions anyone would like to make. That includes rewriting large portions of it (or all of it, if anyone is up for it). Destroy! Much better, a standard overview of CTFE, but that's better for a general audience. I'd leave out the bit about allocation altogether, a technical detail that depends on the compiler and could just be fixed someday. Stick that in your GC blog post later on, and refer back to this post then.
Re: Sorting in D Blog Post Review Request
On Sunday, 4 June 2017 at 16:48:11 UTC, Joakim wrote: On Sunday, 4 June 2017 at 16:07:35 UTC, Mike Parker wrote: [...] Much better, a standard overview of CTFE, but that's better for a general audience. I'd leave out the bit about allocation altogether, a technical detail that depends on the compiler and could just be fixed someday. Stick that in your GC blog post later on, and refer back to this post then. Oh, I'd actually show the source for our quicksort too, to emphasize how different it is from theirs.
Re: Sorting in D Blog Post Review Request
On 06/04/2017 06:07 PM, Mike Parker wrote: https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453 From there: "What it boils down to is this: if a function *can* be executed at compile time, it *will* be." I think that gives the wrong impression. We regularly have newcomers in D.learn who expect CTFE to happen where it doesn't. They have a function call with all compile-time constants, and they expect it to be handled by CTFE. They think that the call *can* be evaluated at compile time, so it *will* be. But that's not how it works. CTFE only kicks in when the destination *requires* a compile-time constant.
Re: C++17 cannot beat D surely
On Sunday, 4 June 2017 at 10:39:09 UTC, rikki cattermole wrote: Should be a way, since you can pass arg directly via ldc to ld. But I would expect it to have done it by default anyway. It is indeed done by default on Windows and Linux. If you dump the object code before it gets to the linker, it will still show the unused symbols, though. — David
Re: Bad array indexing is considered deadly
On Friday, 2 June 2017 at 15:19:29 UTC, Andrei Alexandrescu wrote: Array bound accesses should be easy to intercept and have them just kill the current thread. Ideally, fiber, as well. Probably the real ideal for this sort of problem is to be able to be as close as possible to Erlang, where errors bring down the particular task in progress, but not the application that spawned the task. Incidentally, I wouldn't limit the area of concern here to array bound access issues. This is more about the ability of _any_ error to propagate in applications of this nature, where you have many independent tasks being spawned in separate threads or (more often) fibers, and where you absolutely do not want an error in one task preventing you from being able to continue with others.
Re: C++17 cannot beat D surely
On 2017-06-04 08:18, H. S. Teoh via Digitalmars-d wrote: Ah, but if you want your function to work both at CTFE and runtime, then why write `if (__ctfe)` in the first place? :-D Unless, of course, you're optimizing for runtime with something that's incompatible with CTFE, like inline assembly or something. Then you're on your own. :-D Or using malloc/free at runtime but the GC at compile time. -- /Jacob Carlborg
Re: Bad array indexing is considered deadly
On 2017-06-04 20:15, Joseph Rushton Wakeling wrote: On Friday, 2 June 2017 at 15:19:29 UTC, Andrei Alexandrescu wrote: Array bound accesses should be easy to intercept and have them just kill the current thread. Ideally, fiber, as well. Probably the real ideal for this sort of problem is to be able to be as close as possible to Erlang, where errors bring down the particular task in progress, but not the application that spawned the task. Erlang has the philosophy of share nothing between processes (green processes), or task as you call it here. All allocations are process local, that makes it easier to know that a failing process doesn't affect any other process. -- /Jacob Carlborg
Re: Bad array indexing is considered deadly
On Sunday, 4 June 2017 at 19:12:42 UTC, Jacob Carlborg wrote: On 2017-06-04 20:15, Joseph Rushton Wakeling wrote: On Friday, 2 June 2017 at 15:19:29 UTC, Andrei Alexandrescu wrote: Array bound accesses should be easy to intercept and have them just kill the current thread. Ideally, fiber, as well. Probably the real ideal for this sort of problem is to be able to be as close as possible to Erlang, where errors bring down the particular task in progress, but not the application that spawned the task. Erlang has the philosophy of share nothing between processes (green processes), or task as you call it here. All allocations are process local, that makes it easier to know that a failing process doesn't affect any other process. If I'm not wrong, it also uses a VM, also if there's the availability of a native code compiler... If a VM is involved, it's another game... /Paolo
Re: The design of the hooks in std.experimental.checkedint
On 2017-06-03 23:45, Andrei Alexandrescu wrote: One question - current logic decides whether to call e.g. hookOpBinary vs. perform the default operation followed by onOverflow. How would that work if both hookOpBinary and onOverflow are defined? I'm not sure I fully understand without a code example but I would say that the default hook would implement hookOpBinary to perform the default operation and then call onOverflow. I'm unclear whether this is a step in the right direction. Why have user code work more to provide less information to the framework? I don't see how it would provide less information to the framework. Let user code define what it can, and the framework takes care of the rest. Well, the default hook is part of the framework. A look at how std.experimental.allocator would work if all primitives were required would also be useful. Yes. I haven't looked that carefully on how DbI is used in the allocators yet. A look at an alternative design would definitely be interesting. Note that it doesn't need to be an either or case. Some of hooks can be required while other are optional. This suggestion is perfect when the logic is: if there's a hook, call that, otherwise perform a default operation. It's less ideal when there are multiple conditional branches. -- /Jacob Carlborg
Re: Bad array indexing is considered deadly
On Sunday, 4 June 2017 at 19:12:42 UTC, Jacob Carlborg wrote: Erlang has the philosophy of share nothing between processes (green processes), or task as you call it here. All allocations are process local, that makes it easier to know that a failing process doesn't affect any other process. Indeed. (I used 'task' here in a deliberately vague sense, in order to not be too Erlang- or D-specific.) The obvious differences in how D handles things seem to make it rather hard to get the same ease of error handling, but it would be interesting to consider what might get us closer.
Re: Bad array indexing is considered deadly
On 2017-06-04 21:24, Paolo Invernizzi wrote: If I'm not wrong, it also uses a VM, also if there's the availability of a native code compiler... If a VM is involved, it's another game... Yes, it's running on a VM, the Beam. -- /Jacob Carlborg
Re: The design of the hooks in std.experimental.checkedint
On 06/04/2017 03:25 PM, Jacob Carlborg wrote: On 2017-06-03 23:45, Andrei Alexandrescu wrote: One question - current logic decides whether to call e.g. hookOpBinary vs. perform the default operation followed by onOverflow. How would that work if both hookOpBinary and onOverflow are defined? I'm not sure I fully understand without a code example but I would say that the default hook would implement hookOpBinary to perform the default operation and then call onOverflow. What would be the advantage of moving the default into a hook? I'm unclear whether this is a step in the right direction. Why have user code work more to provide less information to the framework? I don't see how it would provide less information to the framework. Hook function is defined: "I want to hook this entire operation." Hook function is not defined: "I am not interested in hooking this operation." If hook is always defined, the shell cannot identify what a particular hook has an interest in. Andrei
Re: Bad array indexing is considered deadly
On Sunday, 4 June 2017 at 19:24:27 UTC, Paolo Invernizzi wrote: If I'm not wrong, it also uses a VM, also if there's the availability of a native code compiler... If a VM is involved, it's another game... Not sure if I follow that. If you only use safe code then there should be no difference between using a VM or not. And what is a VM these days anyway? (e.g. hypervisors and micro code caches in CPUs etc) Now, you might argue that some IRs are too complicated, and that a simple IR is easier to get right. Or that some concurrency models are more volatile than others. That is true, but it doesn't have much to do with using a VM. So the only special thing about using a VM in this case is that it could allow an actor to migrate to another server while running. Which is another game...
Re: std.csv Performance Review
On Sunday, 4 June 2017 at 15:59:03 UTC, Jesse Phillips wrote: On Sunday, 4 June 2017 at 06:15:24 UTC, H. S. Teoh wrote: [...] Ok, I took you up on that, I'm still skeptical: LDC2 -O3 -release -enable-cross-module-inlining std.csv: 12487 msecs fastcsv (no gc): 1376 msecs csvslicing: 3039 msecs That looks like about 10 times faster to me. Using the slicing version failed because of \r\n line endings (guess multi-part separators is broken) I changed the data file so I could get the execution time. Anyway, I'm not trying to claim fastcsv isn't good at what it does, all I'm trying to point out is std.csv is doing more work than these faster csv parsers. And I don't even want to claim that std.csv is better because of that work, it actually appears that it was a mistake to do validation. In case you have time, it would be very interesting to compare it with other state of the art tools like paratext: http://www.wise.io/tech/paratext
Re: Sorting in D Blog Post Review Request
On Sunday, June 04, 2017 19:16:09 ag0aep6g via Digitalmars-d wrote: > On 06/04/2017 06:07 PM, Mike Parker wrote: > > https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453 > > From there: "What it boils down to is this: if a function *can* be > executed at compile time, it *will* be." > > I think that gives the wrong impression. We regularly have newcomers in > D.learn who expect CTFE to happen where it doesn't. They have a function > call with all compile-time constants, and they expect it to be handled > by CTFE. They think that the call *can* be evaluated at compile time, so > it *will* be. But that's not how it works. CTFE only kicks in when the > destination *requires* a compile-time constant. Yeah, the compiler doesn't care at all about whether a function can be called during CTFE until it actually attempts it, and it's only going to attempt it in a context where the result _must_ be known at compile-time, whereas that line implies that the compiler calls functions at compile-time whenever it can, which would have a _very_ different effect. - Jonathan M Davis
Re: DMD VS2017 Support
On Sunday, June 04, 2017 16:03:46 Jolly James via Digitalmars-d wrote: > On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: > > On 01.05.2017 10:03, Igor wrote: > >> On Monday, 1 May 2017 at 01:54:30 UTC, evilrat wrote: > >>> [...] > >> > >> That was it. It didn't occur to me that this was the problem > >> because I > >> payed closed attention during VisualD installation and saw it > >> properly > >> recognized where DMD was installed but for some reason the > >> path wasn't > >> set in Options. Once I did set it, compile and build worked. > >> Thanks > >> evilrat! > >> > >> So in conclusion it seems the problem is in VisualD > >> installation which > >> doesn't set the path properly even though it recognizes where > >> DMD is > >> installed. Hope the author takes a look at this problem so > >> beginners > >> wanting to try D don't give up on a problem like this. > > > > VS 2017 uses a "private" registry that the Visual D installer > > doesn't have access to. I'll change the registry location in > > the next release. > > > > Please note that the next dmd installer will also detect VS2017 > > and setup directories correctly in sc.ini: > > https://github.com/dlang/installer/pull/227 > > Today I saw that a new DMD version had been released. So I > downloaded it (dmd-2.074.1.exe). > > Unfortunately, the installer does *not* detect VS2017, instead it > asks me to install VS2013 for x64 support. That PR was merged into the master branch, not the stable branch, so the updates to the installer will be in 2.075.0. Presumably, they either thought that it was too large a change for a release that only has bugfixes, or they just merged it into master, because that's the default, and they didn't think about it. - Jonathan M Davis
Re: DMD VS2017 Support
On Sunday, 4 June 2017 at 23:45:34 UTC, Jonathan M Davis wrote: On Sunday, June 04, 2017 16:03:46 Jolly James via Digitalmars-d wrote: On Monday, 1 May 2017 at 18:30:53 UTC, Rainer Schuetze wrote: > [...] Today I saw that a new DMD version had been released. So I downloaded it (dmd-2.074.1.exe). Unfortunately, the installer does *not* detect VS2017, instead it asks me to install VS2013 for x64 support. That PR was merged into the master branch, not the stable branch, so the updates to the installer will be in 2.075.0. Presumably, they either thought that it was too large a change for a release that only has bugfixes, or they just merged it into master, because that's the default, and they didn't think about it. - Jonathan M Davis I strongly assume that it's the latter. It has simply been forgotten. However, it's not difficult to cherry-pick it for `stable`: https://github.com/dlang/installer/pull/228
Re: DIP66 - Multiple alias this
On Friday, 10 October 2014 at 17:09:08 UTC, IgorStepanov wrote: I've created DIP for my pull request. DIP: http://wiki.dlang.org/DIP66 PR: https://github.com/D-Programming-Language/dmd/pull/3998 Please, comment it. Well, nearly 3 years later and nothing!
Re: Sorting in D Blog Post Review Request
On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote: As a result of the ongoing thread, 'C++17 cannot beat D surely' [1], I've slapped together a blog post about it all. A post about CTFE sort in D by itself would be rather short. So I also wrote about two points of the confusion (one of which was my own) that arose in the thread. I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors. Thanks in advance. [1] http://forum.dlang.org/post/bhdehyzrlfklfkxic...@forum.dlang.org [2] https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3 Just a minor typo: writeln(b); should be // [1, 2, 3] enum int[] a = [ 3, 1, 2 ]; static b = sort(a); writeln(b); // [0, 1, 2, 3, 4]
Re: Anyone tried to emscripten a D/SDL game?
On Wednesday, 24 May 2017 at 17:08:06 UTC, Nick Sabalausky "Abscissa" wrote: On Wednesday, 24 May 2017 at 17:06:55 UTC, Guillaume Piolat wrote: http://code.alaiwan.org/wp/?p=103 Awesome, thanks! Author here ; the blogpost is indeed interesting but it's outdated. It's a lot more simpler now that the "LDC + emscripten-fastcomp" combination works (no need for intermediate C lowering anymore) The whole simplified toolchain and example project live here: https://github.com/Ace17/dscripten If you have questions about how this work, I'd be glad to answer them!
Re: Anyone tried to emscripten a D/SDL game?
On Wednesday, 24 May 2017 at 17:47:42 UTC, Suliman wrote: It's it's possible to [compile to WASM] with D? It should be. LLVM has a working WebAssembly backend ; LDC might need some slight modifications to become aware of this new target. Everything that don't rely on the D runtime should work (except for bugs, e.g https://github.com/kripken/emscripten-fastcomp/issues/187 ). Then, I think the following blog post could be easily adapted for the D langage: https://medium.com/@mbebenita/lets-write-pong-in-webassembly-ac3a8e7c4591 However, please keep in mind that the target instruction set is only the tip of the iceberg ; you have to provide a target environment (like SDL bindings or a simplified D runtime), so the generated code can do anything usefull (like I/O).
