[Issue 19305] New: In symbol lookup, with statement becomes stronger than an inner scope import statement
https://issues.dlang.org/show_bug.cgi?id=19305
Issue ID: 19305
Summary: In symbol lookup, with statement becomes stronger than
an inner scope import statement
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: shigekikar...@gmail.com
I found a breaking change of symbol from DMD2.073.0. I think this change comes
from a conflict between statement spec 4.3.2 and module spec 11.19.1.
see 4.3.2 in https://docarchives.dlang.io/v2.081.0/spec/module.html
see 11.19.1 in
https://docarchives.dlang.io/v2.081.0/spec/statement.html#with-statement
running example
https://wandbox.org/permlink/5bDsMZeqKYh4runs
---
module a;
enum f = "a";
module b;
enum f = "b";
module main;
import std.stdio;
import a;
import b;
void main() {
with (a) {
// 11.19.1 Within the with body the referenced object is searched first
for identifier symbols
assert(f == "a");
// 4.3.2 When a symbol name is used unqualified, a two-phase lookup
will happen.
// First, the module scope will be searched, starting from the
innermost scope. ...
// Symbol lookup stops as soon as a symbol is found.
// If two symbols with the same name are found at the same lookup
phase,
// this ambiguity will result in a compilation error.
import b;
static if (__VERSION__ >= 2073) {
assert(f == "a");
} else {
assert(f == "b");
}
}
}
--
Re: Spasm - webassembly libary for single page applications
Nifty, I'll have to look into this. Any idea what it would take to get this doing some WebGL? (Or playing audio?) Or is this more for HTML-ish sorts of stuff? What are the main current limitations?
[Issue 19304] [Reg 2.081.0] Linker arguments order changed in issue 15574 hinders using --whole-archive linker directive
https://issues.dlang.org/show_bug.cgi?id=19304 Ludovit Lucenic changed: What|Removed |Added Keywords||link-failure --
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 23:32:34 UTC, Nicholas Wilson wrote: On Friday, 12 October 2018 at 20:12:26 UTC, Stanislav Blinov That's done first and foremost by stripping out unnecessary allocations, not by writing "new" every other line and closing your eyes. If you need perf in your _scripts_, a use LDC and b) pass -O3 which among many other improvements over baseline will promote unnecessary garbage collection to the stack. If you *need* perf, you write performant code. If you don't need perf, the least you can do is *not write* lazy-ass pessimized crap. I mean come on, it's 2018. We're writing code for multi-core and multi-processor systems with complex memory interaction. We might be sometimes. I suspect that is less likely for a script to fall in that category. Jesus guys. *All* code falls in that category. Because it is being executed by those machines. Yet we all oh so like to pretend that doesn't happen, for some bizarre reason. Precisely where in memory your data is, how it got there and how it's laid out should be bread and butter of any D programmer. It's true that it isn't critical for one-off scripts, but so is deallocation. Saying stuff like "do more with GC" is just outright harmful. That is certainly not an unqualified truth. Yes one shouldn't `new` stuff just for fun, but speed of executable is often not what one is trying to optimise when writing code, e.g. when writing a script one is probably trying to minimise development/debugging time. That's fine so long as it doesn't unnecessarily *pessimize* execution. Unfortunately, when you advertise GC for it's awesomeness in your experience with "throwaway" scripts, you're sending a very, *very* wrong message. Kids are reading, for crying out loud. Oi, you think thats bad? Try reading what some of the other Aussies post, *cough* e.g. a frustrated Manu *cough* :)
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 21:39:13 UTC, Atila Neves wrote: D isn't Java. If you can, put your data on the stack. If you can't, `new` away and don't think about it. Then five years later, try and hunt down that mysterious heap corruption. Caused by some destructor calling into buggy third-party code. Didn't want to think about that one either? The chances you'll have to optimise the code are not high. If you do, the chances that the GC allocations are the problem are also not high. If the profiler shows they are... then remove those allocations. I mean come on, it's 2018. We're writing code for multi-core and multi-processor systems with complex memory interaction. Sometimes we are. Other times it's a 50 line script. There is no "sometimes" here. You're writing programs for specific machines. All. The. Time. Precisely where in memory your data is, how it got there and how it's laid out should be bread and butter of any D programmer. Of any D programmer writing code that's performance sensitive. All code is performance sensitive. Whoever invented that distinction should be publicly humiliated. If it's not speed, it's power consumption. Or memory. Or I/O. "Not thinking" about any of that means you're treating your power champion horse as if it was a one-legged pony. Advocating the "not thinking" approach makes you an outright evil person.
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 20:12:26 UTC, Stanislav Blinov wrote: On Friday, 12 October 2018 at 19:55:02 UTC, Nicholas Wilson wrote: Freeing your mind and the codebase of having to deal with memory leaves it in an easier place to deal with the less common higher impact leaks: file descriptors, sockets, database handles ect. (this is like chopping down the forest so you can see the trees you care about ;) ). That's done first and foremost by stripping out unnecessary allocations, not by writing "new" every other line and closing your eyes. If you need perf in your _scripts_, a use LDC and b) pass -O3 which among many other improvements over baseline will promote unnecessary garbage collection to the stack. I mean come on, it's 2018. We're writing code for multi-core and multi-processor systems with complex memory interaction. We might be sometimes. I suspect that is less likely for a script to fall in that category. Precisely where in memory your data is, how it got there and how it's laid out should be bread and butter of any D programmer. It's true that it isn't critical for one-off scripts, but so is deallocation. Saying stuff like "do more with GC" is just outright harmful. That is certainly not an unqualified truth. Yes one shouldn't `new` stuff just for fun, but speed of executable is often not what one is trying to optimise when writing code, e.g. when writing a script one is probably trying to minimise development/debugging time. Kids are reading, for crying out loud. Oi, you think thats bad? Try reading what some of the other Aussies post, *cough* e.g. a frustrated Manu *cough*
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 21:34:35 UTC, Atila Neves wrote: --- When writing a throwaway script... ...there's absolutely no need for a GC. True. There's also absolutely no need for computer languages either, machine code is sufficient. Funny. Now for real, in a throwaway script, what is there to gain from a GC? Allocate away and forget about it. In fact, the GC runtime will only detract from performance. Demonstrably untrue. It puzzles me why this myth persists. Myth, is it now? Unless all you do is allocate memory, which isn't any kind of useful application, pretty much on each sweep run the GC's metadata is *cold*. What's worse, you don't control how much data there is and where it is. Need I say more? If you disagree, please do the demonstration then. There are trade-offs, and one should pick whatever is best for the situation at hand. Exactly. Which is *not at all* what the OP is encouraging to do. What this means is that whenever I have disregarded a block of information, say removed an index from an array, then that memory is automatically cleared and freed back up on the next sweep. While the process of collection and actually checking Which is just as easily achieved with just one additional line of code: free the memory. *Simply* achieved, not *easily*. Decades of bugs has shown emphatically that it's not easy. Alright, from one non-native English speaker to another, well done, I salute you. I also used the term "dangling pointer" previously, where I should've used "non-null". Strange you didn't catch that. To the point: *that* is a myth. The bugs you're referring to are not *solved* by the GC, they're swept under a rug. Because the bugs themselves are in the heads, stemming from that proverbial programmer laziness. It's like everyone is Scarlett O'Hara with a keyboard. For most applications, you *do* know how much memory you'll need, either exactly or an estimation. Garbage collection is useful for cases when you don't, or can't estimate, and even then a limited subset of that. Don't be a computer. Do more with GC. Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. There is: writing less code to achieve the same result. Well, I guess either of those do take more arguments than a "new", so yup, you do indeed write "less" code. Only that you have no clue how much more code is hiding behind that "new", how many indirections, DLL calls, syscalls with libc's wonderful poison that is errno... You don't want to think about that. Then two people start using your script. Then ten, a hundred, a thousand. Then it becomes a part of an OS distribution. And no one wants to "think about that". The "power" of GC is in the language support for non-trivial types, such as strings and associative arrays. Plain old arrays don't benefit from it in the slightest. For me, the power of tracing GC is that I don't need to think about ownership, lifetimes, or manual memory management. Yes you do, don't delude yourself. Pretty much the only way you don't is if you're writing purely functional code. But we're talking about D here. Reassigned a reference? You thought about that. If you didn't, you just wrote a nasty bug. How much more hypocrisy can we reach here? "Fun" fact: it's not @safe to "new" anything in D if your program uses any classes. Thing is, it does unconditionally thanks to DRuntime. I also don't have to please the borrow checker gods. Yeah, that's another extremum. I guess "rustacians" or whatever the hell they call themselves are pushing that one, don't they? "Let's not go for a GC, let's straight up cut out whole paradigms for safety's sake..." Yes, there are other resources to manage. RAII nearly always manages that, I don't need to think about that either. Yes you do. You do need to write those destructors or scoped finalizers, don't you? Or so help me use a third-party library that implements those? There's fundamentally *no* difference from memory management here. None, zero, zip. Sad thing is, you're not alone. Look at all the major OSs today. How long does it take to, I don't know, open a project in the Visual Studio on Windows? Or do a search in a huge file opened in 'less' on Unix? On an octacore 4GHz machine with 32Gb 3GHz memory? Should just instantly pop up on the screen, shouldn't it? Why doesn't it then? Because most programmers think the way you do: "oh it doesn't matter here, I don't need to think about that". And then proceed to advocate those "awesome" laid-back solutions that oh so help them save so much time coding. Of course they do, at everyone else's expense. Decades later, we're now trying to solve problems that shouldn't have existed in the first place. You'd think that joke was just that, a joke... But let's get back to D. Look at Phobos. Why does stdout.writefln need to allocate? How many times does
[Issue 15956] Incorrect value inside enum using simd vectors, weird tym errors, and weird if(true) {} partial solution.
https://issues.dlang.org/show_bug.cgi?id=15956
jo...@mail.de changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from jo...@mail.de ---
Tried it now, seems to work, too.
with the constructor:
this(in float4 arr) {
vec = arr;
}
the output is correct for both variables.
However the compile error with the float[4] accepting constructor is is still
there. Also it did not matter if the 'if anything' was present or not.
I suppose this is a different issue (or a feature?) and should therefore be
addressed in a different thread.
-> This can be closed?
--
[Issue 15956] Incorrect value inside enum using simd vectors, weird tym errors, and weird if(true) {} partial solution.
https://issues.dlang.org/show_bug.cgi?id=15956 jo...@mail.de changed: What|Removed |Added Severity|critical|normal --- Comment #3 from jo...@mail.de --- My example seems to be working now, could be that this has been fixed in 2.082.1. But I have not yet tested the original example. --
Re: You don't like GC? Do you?
On 10/11/18 11:20 PM, JN wrote: On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote: [snip] That is fine, if you want to position yourself as competition to languages like Go, Java or C#. D wants to be a viable competition to languages like C, C++ and Rust, as a result, there are usecases where GC might not be enough. Does it though? The way I see it is that people who want to do what C/C++ does are going to use ... C/C++. The same goes for Java/C#. People who want to do what Java/C# do are pretty much just going to use Java/C#. And nothing D does is going to convince them that D is truly better. For the C/C++ D's more involved involved semantics for non-GC code are ALWAYS going to be a turnoff. And for Java/C# people D's less evolved standard library (and library ecosystem) is ALWAYS going to be a turnoff. Where D shines is in it's balance between the two extremes. If want to attempt what C# can do with C++ i'm going to spend the next ten years writing code to replace what ships OOB in .NET. If I want to use C# as a systems language, I have to reinvent everything that C# relies on from the ground up, which will cost me about 10 years (see MSR's Singularity). IMHO D should focus on being the best possible D it can be. If we take care of D, the rest will attend to itself. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 21:15:04 UTC, welkam wrote: People in this thread mostly said that for some things GC is just awesome. When you need to get shit done fast and dirty GC saves time and mental capacity. Not all code deals with sockets, DB, bank transactions, multithreading, etc. Read the OP again then. What message does it send? What broad conclusion does it draw from a niche use case?
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 20:12:26 UTC, Stanislav Blinov wrote: On Friday, 12 October 2018 at 19:55:02 UTC, Nicholas Wilson wrote: Freeing your mind and the codebase of having to deal with memory leaves it in an easier place to deal with the less common higher impact leaks: file descriptors, sockets, database handles ect. (this is like chopping down the forest so you can see the trees you care about ;) ). That's done first and foremost by stripping out unnecessary allocations, not by writing "new" every other line and closing your eyes. D isn't Java. If you can, put your data on the stack. If you can't, `new` away and don't think about it. The chances you'll have to optimise the code are not high. If you do, the chances that the GC allocations are the problem are also not high. If the profiler shows they are... then remove those allocations. I mean come on, it's 2018. We're writing code for multi-core and multi-processor systems with complex memory interaction. Sometimes we are. Other times it's a 50 line script. Precisely where in memory your data is, how it got there and how it's laid out should be bread and butter of any D programmer. Of any D programmer writing code that's performance sensitive. It's true that it isn't critical for one-off scripts, but so is deallocation. We'll agree to disagree. Saying stuff like "do more with GC" is just outright harmful. Disagreement yet again.
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 16:26:49 UTC, Stanislav Blinov wrote: On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote: "It takes care of itself --- When writing a throwaway script... ...there's absolutely no need for a GC. True. There's also absolutely no need for computer languages either, machine code is sufficient. In fact, the GC runtime will only detract from performance. Demonstrably untrue. It puzzles me why this myth persists. There are trade-offs, and one should pick whatever is best for the situation at hand. What this means is that whenever I have disregarded a block of information, say removed an index from an array, then that memory is automatically cleared and freed back up on the next sweep. While the process of collection and actually checking Which is just as easily achieved with just one additional line of code: free the memory. *Simply* achieved, not *easily*. Decades of bugs has shown emphatically that it's not easy. Don't be a computer. Do more with GC. Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. There is: writing less code to achieve the same result. The "power" of GC is in the language support for non-trivial types, such as strings and associative arrays. Plain old arrays don't benefit from it in the slightest. For me, the power of tracing GC is that I don't need to think about ownership, lifetimes, or manual memory management. I also don't have to please the borrow checker gods. Yes, there are other resources to manage. RAII nearly always manages that, I don't need to think about that either.
Re: Spasm - webassembly libary for single page applications
On 10/12/18 3:43 PM, Sebastiaan Koppe wrote: I like to announce Spasm https://github.com/skoppe/spasm It is a webassembly library to develop single page applications and builds on my previous work (https://forum.dlang.org/post/eqneqstmwfzugymfe...@forum.dlang.org). It generates fast and small webassembly binaries. The example todo-mvc is only 5995 bytes (wasm) + 2199 bytes (html+js) when gzipped, and loads pretty fast (https://skoppe.github.io/spasm/examples/todo-mvc/) Spasm can be used with dub and only requires a recent version of ldc. See the readme on github how to get started. The library includes a webpack bootstrap project to build a production ready web page. Spasm is written in betterC. Next steps are: - more js host bindings (xhr, localstorage, etc.) - memory deallocation - gather an angry mob to make phobos more betterC compatible ;) OK, this is pretty cool. I need to start checking out webasm. -Steve
Re: custom sorting of lists ?
On 10/12/18 4:59 PM, Codifies wrote: On Friday, 12 October 2018 at 20:29:27 UTC, Steven Schveighoffer wrote: On 10/12/18 3:40 PM, Codifies wrote: [...] Unfortunately, I can't find a way to sort a doubly linked list in phobos, so comparisons are somewhat moot. However, if there *were* a sorting routine, generally the comparison function is done via whatever type you give it, or is given a custom comparison routine. In my ancient dcollections library linked-list sorting is supported via a `less` parameter: https://github.com/schveiguy/dcollections/blob/82118cfd4faf3f1ad77df078d279f1b964f274e7/dcollections/LinkList.d#L997 I think I'll look later and see if the links (in the dlist) are accessible, I could at least implement a bubble sort if I can swap two nodes I really should copy my mergesort implementation to Phobos. It's really simple, and there's no reason not to have sortable lists (both singly and doubly linked). -Steve
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 20:12:26 UTC, Stanislav Blinov wrote: Saying stuff like "do more with GC" is just outright harmful. Kids are reading, for crying out loud. People in this thread mostly said that for some things GC is just awesome. When you need to get shit done fast and dirty GC saves time and mental capacity. Not all code deals with sockets, DB, bank transactions, multithreading, etc.
Re: A Friendly Challenge for D
On Friday, 12 October 2018 at 20:05:29 UTC, welkam wrote: On Friday, 12 October 2018 at 16:19:59 UTC, Jabari Zakiya wrote: The real point of the challenge is too see what idiomatic code... There is no idiomatic D code. There is only better implementations. D doesnt tell you how to write your code. It gives you many tools and you choose which tools to use. That`s what people like about D. I await your implementation(s)! :-)
Re: custom sorting of lists ?
On Friday, 12 October 2018 at 20:29:27 UTC, Steven Schveighoffer wrote: On 10/12/18 3:40 PM, Codifies wrote: [...] Unfortunately, I can't find a way to sort a doubly linked list in phobos, so comparisons are somewhat moot. However, if there *were* a sorting routine, generally the comparison function is done via whatever type you give it, or is given a custom comparison routine. In my ancient dcollections library linked-list sorting is supported via a `less` parameter: https://github.com/schveiguy/dcollections/blob/82118cfd4faf3f1ad77df078d279f1b964f274e7/dcollections/LinkList.d#L997 -Steve I think I'll look later and see if the links (in the dlist) are accessible, I could at least implement a bubble sort if I can swap two nodes
Re: custom sorting of lists ?
On 10/12/18 3:40 PM, Codifies wrote:
a while ago I wrote a doubly linked list (in C), which has a compare
callback to allow custom sorting for example
int cmpNodes(cnode_t* n1, cnode_t* n2)
{
mapNode_t* rn1 = (mapNode_t*)(n1->data);
mapNode_t* rn2 = (mapNode_t*)(n2->data);
if (rn1->G + rn1->H > rn2->G + rn2->H) return 1;
return 0;
}
would be called by
clistSort(openList, cmpNodes);
The list would then be ordered by G + H fields (or any other algorithm
you code)
I notice there is a doubly linked list in the standard library, however
it doesn't seem to allow for a custom compare, I'd rather not port my
old C list code, can someone please give me some clues as to how I can
reorder a list with a custom comparison...?
Unfortunately, I can't find a way to sort a doubly linked list in
phobos, so comparisons are somewhat moot.
However, if there *were* a sorting routine, generally the comparison
function is done via whatever type you give it, or is given a custom
comparison routine.
In my ancient dcollections library linked-list sorting is supported via
a `less` parameter:
https://github.com/schveiguy/dcollections/blob/82118cfd4faf3f1ad77df078d279f1b964f274e7/dcollections/LinkList.d#L997
-Steve
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 19:55:02 UTC, Nicholas Wilson wrote: Freeing your mind and the codebase of having to deal with memory leaves it in an easier place to deal with the less common higher impact leaks: file descriptors, sockets, database handles ect. (this is like chopping down the forest so you can see the trees you care about ;) ). That's done first and foremost by stripping out unnecessary allocations, not by writing "new" every other line and closing your eyes. I mean come on, it's 2018. We're writing code for multi-core and multi-processor systems with complex memory interaction. Precisely where in memory your data is, how it got there and how it's laid out should be bread and butter of any D programmer. It's true that it isn't critical for one-off scripts, but so is deallocation. Saying stuff like "do more with GC" is just outright harmful. Kids are reading, for crying out loud.
Re: A Friendly Challenge for D
On Friday, 12 October 2018 at 16:19:59 UTC, Jabari Zakiya wrote: The real point of the challenge is too see what idiomatic code... There is no idiomatic D code. There is only better implementations. D doesnt tell you how to write your code. It gives you many tools and you choose which tools to use. That`s what people like about D.
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 19:43:02 UTC, Stanislav Blinov wrote: On Friday, 12 October 2018 at 18:50:26 UTC, Neia Neutuladh wrote: Over the lifetime of the script, it processed more memory than my computer had. That means I needed a memory management strategy other than "allocate everything". The GC made that quite easy. Now *that* is a good point. Then again, until you run out of address space you're still fine with just plain old allocate-and-forget. Not that it's a good thing for production code, but for one-off scripts? Sure. People demonstrably have trouble doing that. We can do it most of the time, but everyone occasionally forgets. The GC isn't a cure for forgetfulness. One can also forget to close a file or a socket, or I dunno, cancel a financial transaction. By lines of code, programs allocate memory much more often than they deal with files or sockets or financial transactions. So anything that requires less discipline when dealing with memory will reduce bugs a lot, compared with a similar system dealing with sockets or files. My point is it's irrelevant whether it's memory allocation or something else. If you allow yourself to slack on important problems, that habit *will* bite you in the butt in the future. Freeing your mind and the codebase of having to deal with memory leaves it in an easier place to deal with the less common higher impact leaks: file descriptors, sockets, database handles ect. (this is like chopping down the forest so you can see the trees you care about ;) ).
Re: A Friendly Challenge for D
On Friday, 12 October 2018 at 16:19:59 UTC, Jabari Zakiya wrote: Hmm,I don't think what you're saying about similar output|performance with other languages is empirically correct, but it's really not the point of the challenge. Thats why godbolt exists. c++ and Rust https://godbolt.org/z/FffXY2 C and D https://godbolt.org/z/YQvkXU Look at assembly output. Its all the same. Compilers are very good at recognizing simple arithmetic computations and can reason about it. What they struggle with is memory access. On Friday, 12 October 2018 at 16:19:59 UTC, Jabari Zakiya wrote: Finally, a really fast D implementation can be a marketing bananza to show people > in the numerical analysis, data|signal processing fields, et al, that D can be used by them to solve their problems and be more performant than C++, etc eBay`s tsv-utils is fastest in the world https://github.com/eBay/tsv-utils/blob/master/docs/comparative-benchmarks-2018.md#top-four-in-each-benchmark D`s JSON parsing is fastest in the world https://github.com/kostya/benchmarks#json Sambamba is BAM data processor and is fastest in the world https://www.basepairtech.com/blog/sorting-bam-files-samtools-vs-sambamba/ Mir GLAS is faster than OpenBLAS and Eigen http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-gemm-benchmark.html There are enough examples but they are not enough to change minds
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 19:06:36 UTC, Dejan Lekic wrote: What a bunch of nonsense! I used to talk like this some 20 years ago when all I saw in the computing world was C and C++... Sure garbage collection is not for every project, depends what industry you are in I guess... In my case (business applications/services) I have never had the need to turn off garbage collection! However, someone in the gaming industry, embedded or realtime systems would indeed need to turn off the GC... Who said anything about turning it off? I'm pointing out that using the GC for the sake of simplicity is precisely the wrong reason to do so, that's it. Bunch of nonsense, right. Have fun writing sloppy code then.
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 16:26:49 UTC, Stanislav Blinov wrote: On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote: "It takes care of itself --- When writing a throwaway script... ...there's absolutely no need for a GC. In fact, the GC runtime will only detract from performance. For me, at least, spending an extra two weeks optimizing a program to eliminate that last 0.1 seconds of running time is not a good decision.
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 18:50:26 UTC, Neia Neutuladh wrote: Over the lifetime of the script, it processed more memory than my computer had. That means I needed a memory management strategy other than "allocate everything". The GC made that quite easy. Now *that* is a good point. Then again, until you run out of address space you're still fine with just plain old allocate-and-forget. Not that it's a good thing for production code, but for one-off scripts? Sure. People demonstrably have trouble doing that. We can do it most of the time, but everyone occasionally forgets. The GC isn't a cure for forgetfulness. One can also forget to close a file or a socket, or I dunno, cancel a financial transaction. By lines of code, programs allocate memory much more often than they deal with files or sockets or financial transactions. So anything that requires less discipline when dealing with memory will reduce bugs a lot, compared with a similar system dealing with sockets or files. My point is it's irrelevant whether it's memory allocation or something else. If you allow yourself to slack on important problems, that habit *will* bite you in the butt in the future. But the other end of the spectrum is also harmful. That's how we get those "good" APIs such as XCB that fragment the hell out of your heap, force libc on you and make you collect their garbage. It's good enough for a lot of people most of the time without thinking about things much. That's precisely the line of thinking that gave us Java, C#, Python and other bastard languages that didn't want to concern themselves with the hardware all that much. 30 years of "progress" down the drain. It reduces the frequency of problems and it eliminates use-after-free Not in D it doesn't. Unless you only ever write @safe code, in which case you're not in the "without thinking about things much" camp. and double-free, which are sources of data corruption, which is hard to track down. Agreed. And in the context of a one-off script, I'm probably not going to worry about using the GC efficiently as long as I'm not running out of memory. Sure, *that's* the appropriate message. Not the "use the GC, it's not as bad as you think". If you "forget" who owns the data, you may as well "forget" who writes it and when. Would GC help then as well? You need to expend pretty much the same effort to track that. That's why we have the const system. Oh please, really? Const in D? And you're still talking about people that don't like to think about things much?
Spasm - webassembly libary for single page applications
I like to announce Spasm https://github.com/skoppe/spasm It is a webassembly library to develop single page applications and builds on my previous work (https://forum.dlang.org/post/eqneqstmwfzugymfe...@forum.dlang.org). It generates fast and small webassembly binaries. The example todo-mvc is only 5995 bytes (wasm) + 2199 bytes (html+js) when gzipped, and loads pretty fast (https://skoppe.github.io/spasm/examples/todo-mvc/) Spasm can be used with dub and only requires a recent version of ldc. See the readme on github how to get started. The library includes a webpack bootstrap project to build a production ready web page. Spasm is written in betterC. Next steps are: - more js host bindings (xhr, localstorage, etc.) - memory deallocation - gather an angry mob to make phobos more betterC compatible ;)
custom sorting of lists ?
a while ago I wrote a doubly linked list (in C), which has a
compare callback to allow custom sorting for example
int cmpNodes(cnode_t* n1, cnode_t* n2)
{
mapNode_t* rn1 = (mapNode_t*)(n1->data);
mapNode_t* rn2 = (mapNode_t*)(n2->data);
if (rn1->G + rn1->H > rn2->G + rn2->H) return 1;
return 0;
}
would be called by
clistSort(openList, cmpNodes);
The list would then be ordered by G + H fields (or any other
algorithm you code)
I notice there is a doubly linked list in the standard library,
however it doesn't seem to allow for a custom compare, I'd rather
not port my old C list code, can someone please give me some
clues as to how I can reorder a list with a custom comparison...?
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 16:26:49 UTC, Stanislav Blinov wrote: On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote: "It takes care of itself --- When writing a throwaway script... ...there's absolutely no need for a GC. In fact, the GC runtime will only detract from performance. What this means is that whenever I have disregarded a block of information, say removed an index from an array, then that memory is automatically cleared and freed back up on the next sweep. While the process of collection and actually checking Which is just as easily achieved with just one additional line of code: free the memory. Don't be a computer. Do more with GC. Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. The "power" of GC is in the language support for non-trivial types, such as strings and associative arrays. Plain old arrays don't benefit from it in the slightest. What a bunch of nonsense! I used to talk like this some 20 years ago when all I saw in the computing world was C and C++... Sure garbage collection is not for every project, depends what industry you are in I guess... In my case (business applications/services) I have never had the need to turn off garbage collection! However, someone in the gaming industry, embedded or realtime systems would indeed need to turn off the GC...
Re: You don't like GC? Do you?
On 10/12/2018 11:14 AM, Stanislav Blinov wrote: On Friday, 12 October 2018 at 17:31:30 UTC, Neia Neutuladh wrote: Throwaway scripts can allocate a lot of memory and have nontrivial running times. It's less common for scripts than for long-running processes, granted, but I've written scripts to go through gigabytes of data. Your point being?.. It's not like you need a GC to allocate gigabytes of storage. With D it's super easy to just allocate a huge hunk and simply (literally) slice through it. Over the lifetime of the script, it processed more memory than my computer had. That means I needed a memory management strategy other than "allocate everything". The GC made that quite easy. People demonstrably have trouble doing that. We can do it most of the time, but everyone occasionally forgets. The GC isn't a cure for forgetfulness. One can also forget to close a file or a socket, or I dunno, cancel a financial transaction. By lines of code, programs allocate memory much more often than they deal with files or sockets or financial transactions. So anything that requires less discipline when dealing with memory will reduce bugs a lot, compared with a similar system dealing with sockets or files. GC isn't magic. In fact, to use it correctly you need to pay *more* attention than when managing memory manually. Don't leave dangling pointers. Nurse uninitialized data. Massage it to not sweep in hot paths... People seem to forget that and advertise it as some sort of magic wand that does all you want without you having to think. It's good enough for a lot of people most of the time without thinking about things much. It reduces the frequency of problems and it eliminates use-after-free and double-free, which are sources of data corruption, which is hard to track down. And in the context of a one-off script, I'm probably not going to worry about using the GC efficiently as long as I'm not running out of memory. Beyond that, the concept you're failing to mention here is ownership. You need to use your own mental effort to figure out what memory is owned by what part of the code. The GC lets you ignore that. Nope, it doesn't. If you "forget" who owns the data, you may as well "forget" who writes it and when. Would GC help then as well? You need to expend pretty much the same effort to track that. That's why we have the const system.
Re: You don't like GC? Do you?
On Friday, 12 October 2018 at 17:31:30 UTC, Neia Neutuladh wrote: Throwaway scripts can allocate a lot of memory and have nontrivial running times. It's less common for scripts than for long-running processes, granted, but I've written scripts to go through gigabytes of data. Your point being?.. It's not like you need a GC to allocate gigabytes of storage. With D it's super easy to just allocate a huge hunk and simply (literally) slice through it. People demonstrably have trouble doing that. We can do it most of the time, but everyone occasionally forgets. The GC isn't a cure for forgetfulness. One can also forget to close a file or a socket, or I dunno, cancel a financial transaction. GC isn't magic. In fact, to use it correctly you need to pay *more* attention than when managing memory manually. Don't leave dangling pointers. Nurse uninitialized data. Massage it to not sweep in hot paths... People seem to forget that and advertise it as some sort of magic wand that does all you want without you having to think. Beyond that, the concept you're failing to mention here is ownership. You need to use your own mental effort to figure out what memory is owned by what part of the code. The GC lets you ignore that. Nope, it doesn't. If you "forget" who owns the data, you may as well "forget" who writes it and when. Would GC help then as well? You need to expend pretty much the same effort to track that. Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. The "power" of GC is in the language support for non-trivial types, such as strings and associative arrays. Plain old arrays don't benefit from it in the slightest. A string is a plain old array. An ASCII string, perhaps. Not a Unicode one. Count statically-typed compiled languages with native strings, please. and languages with manual memory management also support associative arrays. Of course they do. But again, are those built-in types?
Re: You don't like GC? Do you?
On 10/12/2018 09:26 AM, Stanislav Blinov wrote: On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote: "It takes care of itself --- When writing a throwaway script... ...there's absolutely no need for a GC. In fact, the GC runtime will only detract from performance. Throwaway scripts can allocate a lot of memory and have nontrivial running times. It's less common for scripts than for long-running processes, granted, but I've written scripts to go through gigabytes of data. What this means is that whenever I have disregarded a block of information, say removed an index from an array, then that memory is automatically cleared and freed back up on the next sweep. While the process of collection and actually checking Which is just as easily achieved with just one additional line of code: free the memory. People demonstrably have trouble doing that. We can do it most of the time, but everyone occasionally forgets. Beyond that, the concept you're failing to mention here is ownership. You need to use your own mental effort to figure out what memory is owned by what part of the code. The GC lets you ignore that. Don't be a computer. Do more with GC. Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. The "power" of GC is in the language support for non-trivial types, such as strings and associative arrays. Plain old arrays don't benefit from it in the slightest. A string is a plain old array, and languages with manual memory management also support associative arrays.
Re: You don't like GC? Do you?
On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote: "It takes care of itself --- When writing a throwaway script... ...there's absolutely no need for a GC. In fact, the GC runtime will only detract from performance. What this means is that whenever I have disregarded a block of information, say removed an index from an array, then that memory is automatically cleared and freed back up on the next sweep. While the process of collection and actually checking Which is just as easily achieved with just one additional line of code: free the memory. Don't be a computer. Do more with GC. Writing a throwaway script there's nothing stopping you from using mmap or VirtualAlloc. The "power" of GC is in the language support for non-trivial types, such as strings and associative arrays. Plain old arrays don't benefit from it in the slightest.
Re: A Friendly Challenge for D
On Friday, 12 October 2018 at 15:11:17 UTC, welkam wrote: On Wednesday, 10 October 2018 at 16:15:56 UTC, Jabari Zakiya wrote: What I am requesting here is for a person(s) who is an "expert" (very good) to create a very fast D version, using whatever tricks it has to maximize performance. I would like to include in my paper a good comparison of various implementations in different compiled languages (C/C++, D, Nim, etc) to show how it performs with each. I looked into your NIM code and from programmers point of view there is nothing interesting going on. Simple data structures and simple operations. If you wrote equivalent code in C, C++, D, NIM, Rust, Zig and compiled with same optimizing compiler (llvm or gcc) you should get the same machine code and almost the same performance (less than 1% difference due to runtime). If you got different machine code for equivalent implementation then you should file a bug report. The only way you will get different performance is by changing implementation details but then you would compare apples to oranges. Hmm,I don't think what you're saying about similar output|performance with other languages is empirically correct, but it's really not the point of the challenge. The real point of the challenge is too see what idiomatic code, written for performance, using the best resources that the language provides, will produce compared, to the Nim version. It's not to see what a line-by-line translation from Nim to D would look like. That may be a start to get something working, but shouldn't be the end goal. I'm using the Nim version here as the "reference implementation" so it can be used as the standard for comparison (accuracy of results and performance). The goal for D (et al) users is to use whatever resources it provides to maybe do better. Example. Nim currently doesn't provide standard bitarrays. Using bitarrays in place of byte arrays should perform faster because more data can fit in cache and operate faster. Also, to parallelize the algorithm maybe using OpenMP, CUDA, etc is the way to do it for D. I don't know what constructs D uses for parallel multiprocessing. And as noted before, this algorithms screams out to be done with GPUs. But you are correct that the Nim code uses very simple coding operations. That is one of its beauties! :) It is simple to understand and implement mathematically, short and simple to code, and architecturally adaptable to hardware. So to really do the challenge, the Nim code needs to be compiled and run (per instructions in code) to use as the "reference implementation", to see what correct outputs look like, and their times, and then other implementations can be compared to it. I would hope, after getting an output correct implementation done (to show you really know what you're doing) then alternative implementations can be done to wring out better performance. I think this is a good challenge for anyone wanting to learn D too, because it involves something substantially more than a "toy" algorithm, but short enough to do with minimal time and effort, that involves the need to know (learn about) D in enough detail to determine the "best" (alternative) way to do it. Finally, a really fast D implementation can be a marketing bananza to show people in the numerical analysis, data|signal processing fields, et al, that D can be used by them to solve their problems and be more performant than C++, etc. Again, people should feel free to email me if the want more direct answers to questions, or help.
Re: LDC2 -I option results in unresolved externals
On Friday, 12 October 2018 at 07:32:26 UTC, Mike Parker wrote: DMD has the -i option which tells the compiler to automatically compile all imported modules. I don't know if LDC has anything similar. It does, same option.
Re: Release D 2.082.1
On Thursday, 11 October 2018 at 23:02:19 UTC, Martin Nowak wrote: Glad to announce D 2.082.1. http://dlang.org/download.html This point release fixes a few issues over 2.082.1 Ummm... Anyway, thanks for the release!
Re: D Logic bug
On Friday, 12 October 2018 at 13:15:22 UTC, Steven Schveighoffer wrote: On 10/12/18 6:06 AM, Kagamin wrote: On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler wrote: [...] That's https://issues.dlang.org/show_bug.cgi?id=14186 Wow, interesting that C precedence is different from C++ here. It's C++ which the anormal one.
Re: D Logic bug
On Thursday, 11 October 2018 at 23:17:57 UTC, Jonathan M Davis wrote: On Thursday, October 11, 2018 8:35:34 AM MDT James Japherson via Digitalmars-d wrote: Certainly, major languages like C, C++, Java, and C# all do it the way that D does, and they all have the same kind of precedence for the ternary operator that D does. No, the off man out is C++. it's the only one with the priority of the ternary equal to assignments. All other languages do it like C, i.e. with a higher priority for ?: C++ is the annoying one (as always) here.
Re: What's going on with the DMD nightlies releases ?
On Wednesday, 19 September 2018 at 12:51:25 UTC, Basile B. wrote: The downloads of nightlies is broken since at least 2 weeks now. What's going on ? I've started using this script from today : https://github.com/BBasile/dmdm/blob/master/dmdm.sh Instead of downloading the nightly release it builds it directly during the CI.
Re: D Logic bug
On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler wrote: On Thursday, 11 October 2018 at 21:57:00 UTC, Jonathan M Davis wrote: On Thursday, October 11, 2018 1:09:14 PM MDT Jonathan Marler via Digitalmars-d wrote: On Thursday, 11 October 2018 at 14:35:34 UTC, James Japherson wrote: > [...] In c++ the ternary operator is the second most lowest precedence operator, just above the comma. You can see a table of each operator and their precendence here, I refer to it every so often: https://en.cppreference.com/w/cpp/language/operator_precedence Learning that the ternary operator has such a low precedence is one of those things that all programmers eventually run into...welcome to the club :) It looks like D has a similar table here (https://wiki.dlang.org/Operator_precedence). However, it doesn't appear to have the ternary operator in there. On that note, D would take it's precedence order from C/C++ unless there's a VERY good reason to change it. The operator precedence matches in D. Because in principle, C code should either be valid D code with the same semantics as it had in C, or it shouldn't compile as D code, changing operator precedence isn't something that D is going to do (though clearly, the ternary operator needs to be added to the table). It would be a disaster for porting code if we did. - Jonathan M Davis I had a look at the table again, looks like the ternary operator is on there, just called the "conditional operator". And to clarify, D's operator precedence is close to C/C++ but doesn't match exactly. Please do not conflate C and C++. It is specifically on order of precedence of the ternary that the 2 languages differ. It is C++ and only C++ which has the unconventionnal order of precedence where the ternary has the same priority as the assign operators. ALL other C derived languages have a higher priority for the ternary than the assignments.
Re: Has Anyone has this same Issue Please?
On Thursday, 11 October 2018 at 18:20:56 UTC, Ephrahim wrote:
Using this dub.json configuration
0.8.36\eventcore\source\eventcore\drivers\posix\driver.d(145,14):
Error: safe function
'eventcore.drivers.posix.driver.PosixEventDriverCore!(SelectEventLoop, LoopTimeoutTimerDriver, PosixEventDriverEvents!(SelectEventLoop, PosixEventDriverSockets!(SelectEventLoop))).PosixEventDriverCore.dispose' cannot call system function 'core.atomic.atomicStore!(cast(MemoryOrder)3, Mutex, typeof(null)).atomicStore'
..\..\..\..\AppData\Local\dub\packages\eventcore-0.8.36\eventcore\source\eventcore\drivers\posix\select.d(26,27):
Error: template instance
eventcore.drivers.posix.driver.PosixEventDriver!(SelectEventLoop) error
instantiating
..\..\..\..\AppData\Local\dub\packages\eventcore-0.8.36\eventcore\source\eventcore\drivers\posix\driver.d(210,22):
Error: safe function
'eventcore.drivers.posix.driver.PosixEventDriverCore!(SelectEventLoop,
LoopTimeoutTimerDriver, PosixEventDriverEvents!(SelectEventLoop,
PosixEventDriverSockets!(SelectEventLoop))).PosixEventDriverCore.runInOwnerThread'
cannot call system function 'core.atomic.atomicLoad!(cast(MemoryOrder)3,
Mutex).atomicLoad'
..\..\..\..\AppData\Local\dub\packages\eventcore-0.8.36\eventcore\source\eventcore\drivers\posix\driver.d(211,24):
Error: safe function 'eventcore.drivers.posix.driver.PosixEventDriverCore!(SelectEventLoop,
LoopTimeoutTimerDriver, PosixEventDriverEvents!(SelectEventLoop,
PosixEventDriverSockets!(SelectEventLoop))).PosixEventDriverCore.runInOwnerThread' cannot call
system function 'core.atomic.atomicLoad!(cast(MemoryOrder)3, Handle!("event",
Handle!("fd", uint, 4294967295u), Handle(4294967295u))).atomicLoad'
..\..\..\..\AppData\Local\dub\packages\eventcore-0.8.36\eventcore\source\eventcore\drivers\posix\driver.d(41,22):
Error: template instance
eventcore.drivers.posix.driver.PosixEventDriverCore!(SelectEventLoop,
LoopTimeoutTimerDriver, PosixEventDriverEvents!(SelectEventLoop,
PosixEventDriverSockets!(SelectEventLoop))) error instantiating
..\..\..\..\AppData\Local\dub\packages\eventcore-0.8.36\eventcore\source\eventcore\drivers\posix\select.d(26,27):
instantiated from here: PosixEventDriver!(SelectEventLoop)
..\..\..\..\AppData\Local\dub\packages\eventcore-0.8.36\eventcore\source\eventcore\drivers\winapi\core.d(112,22):
Error: safe function
'eventcore.drivers.winapi.core.WinAPIEventDriverCore.runInOwnerThread' cannot
call system function 'core.atomic.atomicLoad!(cast(MemoryOrder)3,
Mutex).atomicLoad'
..\..\..\..\AppData\Local\dub\packages\eventcore-0.8.36\eventcore\source\eventcore\drivers\winapi\sockets.d(256,18):
Error:
'eventcore.drivers.winapi.sockets.WinAPIEventDriverSockets.read.resetBuffers'
is not nothrow
..\..\..\..\AppData\Local\dub\packages\eventcore-0.8.36\eventcore\source\eventcore\drivers\winapi\sockets.d(261,17):
Error:
'eventcore.drivers.winapi.sockets.WinAPIEventDriverSockets.read.resetBuffers'
is not nothrow
..\..\..\..\AppData\Local\dub\packages\eventcore-0.8.36\eventcore\source\eventcore\drivers\winapi\sockets.d(238,16):
Error: function
'eventcore.drivers.winapi.sockets.WinAPIEventDriverSockets.read' is nothrow yet
may throw
C:\D\dmd2\windows\bin\dmd.exe failed with exit code 1.
C:\Users\user\Codes\DLang\Projects\app\dub.json has not been
successfully executed
error: DUB has returned the status 2 (undeterminated meaning)
Please Help!!! I will be very grateful for your help sirs/ma
That's a programming error in 'eventcore' at first glance. Some
attributes are not valid. Maybe the library is tested on x86_64
only and using it on x86 reveals issues. Also the error seem to
happen in a module that's for linux or OSX but i see that the
paths are windows-style. You should really report to the author.
The error is not on your side.
Re: A Friendly Challenge for D
On Wednesday, 10 October 2018 at 16:15:56 UTC, Jabari Zakiya wrote: What I am requesting here is for a person(s) who is an "expert" (very good) to create a very fast D version, using whatever tricks it has to maximize performance. I would like to include in my paper a good comparison of various implementations in different compiled languages (C/C++, D, Nim, etc) to show how it performs with each. I looked into your NIM code and from programmers point of view there is nothing interesting going on. Simple data structures and simple operations. If you wrote equivalent code in C, C++, D, NIM, Rust, Zig and compiled with same optimizing compiler (llvm or gcc) you should get the same machine code and almost the same performance (less than 1% difference due to runtime). If you got different machine code for equivalent implementation then you should file a bug report. The only way you will get different performance is by changing implementation details but then you would compare apples to oranges.
[Issue 19303] hasMember fails to recognize member (interaction with mixin template)
https://issues.dlang.org/show_bug.cgi?id=19303 Luís Marques changed: What|Removed |Added Hardware|x86 |All OS|Mac OS X|All Severity|enhancement |normal --
[Issue 19303] New: hasMember fails to recognize member (interaction with mixin template)
https://issues.dlang.org/show_bug.cgi?id=19303
Issue ID: 19303
Summary: hasMember fails to recognize member (interaction with
mixin template)
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: l...@luismarques.eu
In the code quoted below, there is an inconsistency between these two lines:
pragma(msg, P.ElementType);
static assert(hasMember!(P, "ElementType"));
The pragma correctly prints the P.ElementType, but the hasMember assert fails.
The interaction with the mixin template suggests this might be a compiler bug,
but for now I'm only marking this as a Phobos bug. A workaround would be
appreciated.
--
import std.traits;
void main()
{
alias V = Vec!Bool;
alias P = Port!(V);
pragma(msg, P.ElementType);
static assert(hasMember!(P, "ElementType"));
}
mixin template SignalOps()
{
static if(hasMember!(typeof(this), "ElementType")) { }
}
struct Bool {}
struct Port(SomeSignal)
{
mixin SignalOps;
static if(hasMember!(SomeSignal, "ElementType"))
alias ElementType = SomeSignal.ElementType;
}
struct Vec(SomeSignal)
{
alias ElementType = SomeSignal;
}
--
Re: std.regex is fat
On Friday, 12 October 2018 at 13:25:33 UTC, Chris Katko wrote: Like, insanely fat. All I wanted was a simple regex. The second include a regex function, my program would no longer compile "out of memory for fork". /usr/bin/time -v reports it went from 150MB of RAM for D, DAllegro, and Allegro5. To over 650MB of RAM, and from 1.5 seconds to >5.5 seconds to compile. Now I have to close all my Chrome tabs just to compile. Just for one line of regex. And I get it, it's the overhead of the library import, not the single line. But good gosh, more than 3X the RAM of the entire project for a single library import? Something doesn't add up! Hm... maybe, you run into this: https://forum.dlang.org/post/mailman.3091.1517866806.9493.digitalmar...@puremagic.com
std.regex is fat
Like, insanely fat. All I wanted was a simple regex. The second include a regex function, my program would no longer compile "out of memory for fork". /usr/bin/time -v reports it went from 150MB of RAM for D, DAllegro, and Allegro5. To over 650MB of RAM, and from 1.5 seconds to >5.5 seconds to compile. Now I have to close all my Chrome tabs just to compile. Just for one line of regex. And I get it, it's the overhead of the library import, not the single line. But good gosh, more than 3X the RAM of the entire project for a single library import? Something doesn't add up!
Re: Using . notation abstractly
On Friday, 12 October 2018 at 12:43:53 UTC, Paul Backus wrote:
On Wednesday, 10 October 2018 at 22:56:14 UTC, James Japherson
wrote:
The point of all this is because D does not allow nesting of
enums
which allows for nice use of . to separate hiearchies:
enum A
{
enum B
{
X,
}
}
A.B.X, rather than having to have one large flat enum and do
things like A_B_X.
You can use a mixin template to introduce a new namespace:
https://run.dlang.io/is/K0kJJl
True, but D has namespaces elsewhere, which don't require you to
clutter some other namespace with your enums:
struct A {
enum B {
X,
}
}
final abstract class C {
enum D {
Y,
}
}
This has the added benefits of 1) being more obvious, and 2) you
can put other stuff in there.
On Wednesday, 10 October 2018 at 22:56:14 UTC, James Japherson
wrote:
I know one can use structs but it is messy and not general
enough.
Please do elucidate - what do you mean not general enough? When
is a struct less general than an enum?
struct A
{
alias Dispatch this;
}
A.B.X
but it requires more machinery to setup.
Also:
alias A = Dispatch;
A.B.X;
Note that this results in Dispatcher!("B", "X"), so you'll have
to pass the "A" manually (the same problem exists in your code
above):
alias A = Dispatcher!"A";
A.B.X; // Dispatcher!("A", "B", "X")
--
Simen
Re: D Logic bug
On 10/12/18 6:06 AM, Kagamin wrote: On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler wrote: I had a look at the table again, looks like the ternary operator is on there, just called the "conditional operator". And to clarify, D's operator precedence is close to C/C++ but doesn't match exactly. This is likely a result of the grammar differences rather than an intention one. For example, the "Conditional operator" in D actually has a higher priority than an assignment, but in C++ it's the same and is evaluated right-to-left. So this expression would be different in C++ and D: a ? b : c = d In D it would be: (a ? b : c ) = d And in C++ would be: a ? b : (c = d) That's https://issues.dlang.org/show_bug.cgi?id=14186 Wow, interesting that C precedence is different from C++ here. -Steve
Re: Using . notation abstractly
On Wednesday, 10 October 2018 at 22:56:14 UTC, James Japherson
wrote:
The point of all this is because D does not allow nesting of
enums
which allows for nice use of . to separate hiearchies:
enum A
{
enum B
{
X,
}
}
A.B.X, rather than having to have one large flat enum and do
things like A_B_X.
You can use a mixin template to introduce a new namespace:
https://run.dlang.io/is/K0kJJl
[Issue 19302] New: statement not reachable in std.regex.internal.parser.Parser.parseAtom, only in -inline -profile builds
https://issues.dlang.org/show_bug.cgi?id=19302 Issue ID: 19302 Summary: statement not reachable in std.regex.internal.parser.Parser.parseAtom, only in -inline -profile builds Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: john.loughran.col...@gmail.com // test.d import std.regex; regex(); > dmd test.d -inline -profile -w phobos\std\regex\internal\parser.d(845): Warning: statement is not reachable It's trivial to fix this bug (just remove the offending "break" in std.regex.internal.parser.Parser.parseAtom), but I'm more interested in why on earth it only occurs with -inline -profile ?? --
Re: Interesting Observation from JAXLondon
On Friday, 12 October 2018 at 07:13:33 UTC, Russel Winder wrote: On Thu, 2018-10-11 at 13:00 +, bachmeier via Digitalmars-d wrote: […] Suggestions? My guess is that the reason they've heard of those languages is because their developers were writing small projects using Go and Rust, but not D. I fear it may already be too late. [...] I don't think it's ever too late. Python was stagnant for a long time but exploded in popularity in recent years due to Pandas, TensorFlow, SciPy etc. Similar things have happened in other languages, and it can happen for D. The technical differences between languages is mostly immaterial as well IMO. Plenty of awful languages have succeeded despite being really terrible for the domain they won. As long as there are libraries and integrations that help solve a problem, people will use them. PHP is the obvious example here. R is another. As long as D continues to be a nice language to work in for hobbyists, there will always be potential for a killer use case to come along. D just needs to make sure it doesn't piss off its fans. vibe.d happened because a single person was a fan of D. You don't need a lot of marketing for that to happen. Maybe vibe.d hasn't been the killer app for D, but the next thing might be, so you just need fans. I do believe in "Build it and they will come", but "it" needs to be something of value. At the moment, the "it" of D on its own just isn't valuable enough. Lots of marketing without a strong value proposition will just be a waste of effort.
Re: D Logic bug
On Thursday, 11 October 2018 at 23:17:15 UTC, Jonathan Marler wrote: I had a look at the table again, looks like the ternary operator is on there, just called the "conditional operator". And to clarify, D's operator precedence is close to C/C++ but doesn't match exactly. This is likely a result of the grammar differences rather than an intention one. For example, the "Conditional operator" in D actually has a higher priority than an assignment, but in C++ it's the same and is evaluated right-to-left. So this expression would be different in C++ and D: a ? b : c = d In D it would be: (a ? b : c ) = d And in C++ would be: a ? b : (c = d) That's https://issues.dlang.org/show_bug.cgi?id=14186
Re: gRPC for D is released.
On Thursday, 11 October 2018 at 16:19:07 UTC, April Nassi wrote: Hi! I'm the community manager for gRPC and this is awesome! Would love to add this to our ecosystem repo. Would also be great to have you talk about this on an upcoming community call! Thanks, e-mail: zoujiaq...@gmail.com
Re: Interesting Observation from JAXLondon
On Friday, 12 October 2018 at 07:13:33 UTC, Russel Winder wrote: On Thu, 2018-10-11 at 13:00 +, bachmeier via Digitalmars-d wrote: […] Suggestions? My guess is that the reason they've heard of those languages is because their developers were writing small projects using Go and Rust, but not D. I fear it may already be too late. Go, and now Rust, got marketing hype from an organisation putting considerable resources into the projects. This turned into effort from the community that increased rapidly, turning the hype into frameworks and libraries, and word of mouth marketing. It is the libraries and frameworks that make for traction. Now the hype is gone, Go and Rust, and their libraries and frameworks, are well positioned and with significant penetration into the minds of developers. Talk to Java developers and they have heard of Go and Rust, but not D. Go is more likely to them because of Docker and the context of The Web, for which Go has a strong pitch. They have heard of Rust but usually see it as not relevant to them, despite Firefox. Talk to Python developers and they know of Go, many of them of Rust, but almost never D. C and C++ are seen as the languages of performance extensions, though Rust increasingly has a play there. D has vibe.d, PyD, GtkD, and lots of other bits, but they've never quite had the resources of the equivalents in Go and Rust. Also the D community as a whole is effectively introvert, whereas Go and Rust communities have been quite extrovert. "Build it and they will come" just doesn't work, you have to be pushy and market stuff, often using guerilla marketing, to get mindshare. D has an excellent position against Python (for speed of development but without the performance hit) but no chance of penetrating the places where Python is strong due to lack of libraries and frameworks that people use – cf. Pandas, SciKit.Learn, etc. D has an excellent position against Go as a language except that Go has goroutines and channels. The single threaded event loop and callback approach is losing favour. Kotlin is introducing Kotlin Coroutines which is a step on from the observables system of Rx. Structured concurrency abstracting away from fibres and threadpools. Java may well get this via Project Loom which is Quasar being inserted into the JVM directly. Whatever D has it doesn't seem to be going to compete in this space. D without the GC has a sort of position against Rust, but I think that battle has been lost. Rust has won in the "the new C that isn't Go and doesn't have a garbage collector, and isn't C++, but does have all the nice monads stuff, oh and memory safety mostly". When it comes down to it D will carry on as a niche language loved by a few unknown to most. In my opinion, I don't think the game is over just yet. One of D's biggest strengths has been its ability to adapt and innovate. Despite being around since 2001, it is still forging ahead and many of the new features coming out in programming languages are coming to fruition in D before being back-ported to other languages. The D crowd is certainly very introverted and very technically minded, it really seems to be an amazing hub for innovators and compiler designers. But the D community has also been very receptive of changes to the language which allows it to evolve at a pace few other languages can match. My personal opinion is that languages that grow up too fast get stuck because they have too much legacy code and certain options that they may have originally wanted become unavailable. Go and Rust are gaining traction, especially among developers getting tired of very hard to work with languages. Java is very very slow to evolve and there's a huge amount of effort invested in learning other JVM languages like Scala, I think largely because people are looking for alternatives. Rust, while intriguing, is very alien in syntax and concept for many developers. Go gets wider adoption than other languages I've seen, but the race is still on in my book. One thing that does concern me, is the avenues in which people can discover D. For me personally, after a particularly nasty C++ project, I just googled for "alternatives to C++" and that's how I found D back in 2009 or so. But the same search today turns up nothing about D. I'm not sure sure how people are supposed to find D.
Re: Interesting Observation from JAXLondon
On Friday, 12 October 2018 at 07:13:33 UTC, Russel Winder wrote: On Thu, 2018-10-11 at 13:00 +, bachmeier via Digitalmars-d wrote: […] Suggestions? My guess is that the reason they've heard of those languages is because their developers were writing small projects using Go and Rust, but not D. I fear it may already be too late. Go, and now Rust, got marketing hype from an organisation putting considerable resources into the projects. This turned into effort from the community that increased rapidly, turning the hype into frameworks and libraries, and word of mouth marketing. It is the libraries and frameworks that make for traction. Now the hype is gone, Go and Rust, and their libraries and frameworks, are well positioned and with significant penetration into the minds of developers. Talk to Java developers and they have heard of Go and Rust, but not D. Go is more likely to them because of Docker and the context of The Web, for which Go has a strong pitch. They have heard of Rust but usually see it as not relevant to them, despite Firefox. Talk to Python developers and they know of Go, many of them of Rust, but almost never D. C and C++ are seen as the languages of performance extensions, though Rust increasingly has a play there. D has vibe.d, PyD, GtkD, and lots of other bits, but they've never quite had the resources of the equivalents in Go and Rust. Also the D community as a whole is effectively introvert, whereas Go and Rust communities have been quite extrovert. "Build it and they will come" just doesn't work, you have to be pushy and market stuff, often using guerilla marketing, to get mindshare. D has an excellent position against Python (for speed of development but without the performance hit) but no chance of penetrating the places where Python is strong due to lack of libraries and frameworks that people use – cf. Pandas, SciKit.Learn, etc. D has an excellent position against Go as a language except that Go has goroutines and channels. The single threaded event loop and callback approach is losing favour. Kotlin is introducing Kotlin Coroutines which is a step on from the observables system of Rx. Structured concurrency abstracting away from fibres and threadpools. Java may well get this via Project Loom which is Quasar being inserted into the JVM directly. Whatever D has it doesn't seem to be going to compete in this space. D without the GC has a sort of position against Rust, but I think that battle has been lost. Rust has won in the "the new C that isn't Go and doesn't have a garbage collector, and isn't C++, but does have all the nice monads stuff, oh and memory safety mostly". When it comes down to it D will carry on as a niche language loved by a few unknown to most. There is truth in much of what you say, but D has to pick its battles. Given the design of the language, I see two primary use-cases right now: 1. apps that need some level of performance, ie Tilix 2. Low-level tools that need a lot of performance, ie Weka or Sociomantic Going after some established tool like Pandas and its mix of Python and C is likely to fail right now, as D is never going to be as easy as Python, and presumably Pandas has already sped up whatever it needs to in C. Maybe you could create a better tool in D some day when the D ecosystem is larger, but I don't think it would be the best approach today. We need to think about what markets D would be best suited for and aim for those, while at the same time resisting the temptation to make D too specialized for those initial markets, which is a trap many other languages fall into.
Re: LDC2 -I option results in unresolved externals
On Friday, 12 October 2018 at 06:01:12 UTC, spikespaz wrote: I'm using the latest LDC2 beta, and when running the compiler with -I (Look for imports also in ) it fails with unresolved externals. These are my commands. = $ ldc2 "source\setup.d" -I "source" -J "build\vars" -of "build\bin\setup.exe" -m32 -g setup.obj : error LNK2019: unresolved external symbol __D6common17createErrorDialogFxC9ExceptionZv referenced in function __Dmain setup.obj : error LNK2019: unresolved external symbol __D6common14getConsoleArgsFxPuZAAya referenced in function __D5setup20getAvailableBrowsersFZ14__foreachbody1MFKC3std7windows8registry3KeyZi setup.obj : error LNK2001: unresolved external symbol __D6common12__ModuleInfoZ build\bin\setup.exe : fatal error LNK1120: 3 unresolved externals Error: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\link.exe failed with status: 1120 = But this next one works fine. = $ ldc2 "source\setup.d" "source/common.d" -J "build\vars" -of "build\bin\setup.exe" -m32 -g = I'm using LDC2 version 1.12.0-beta2, on DMD v2.082.0, on Windows with VS Build Tools 2017. Any solutions or corrections appreciated. -I does not tell the compiler to actually compile the modules it finds in the given directory. It's only for symbol lookup. DMD has the -i option which tells the compiler to automatically compile all imported modules. I don't know if LDC has anything similar, the wiki page listing its command line options hasn't been updated in a while.
Re: Visual D issues
On 11/10/2018 06:34, James Japherson wrote: > I've been having a lot of issues with visual D. I'm not sure if it's > just dysfunctional, has a few bugs, new bugs were introduced, or what > has happened. Some things have always been like then. I have a potential > solution though. > > I will invest quite a bit of time documenting the issues I have using > video, pictures and text, explaining why these problems are bad and even > give the source code so you can use it to help fix these problems. > > Most of these problems seem like bugs, some are inadequacies, some are > probably just incomplete features, some may be expected behavior for > some peoples workflow but doesn't work in mine. > > If I do this will you be willing to take a serious look in to these > problems and try to resolve them if we can come to an agreement that > they are problems? (and that might simply be that it is an issue on my > side if everything works as they are suppose to on yours) > > Why I'm asking is that I am extremely unproductive in D because of it's > arcane debugging problems that I seem to run in to quite often. I'm sure > if these problems could be fixed(or the major ones), I'd be far more > productive and enjoy the experience more too. > > But there is no point in me doing this if you won't or can't invest the > time(it's not a demand or insult, I just don't want to waste my time). > > I've already brought up many of these problems so you basically know > about them more or less. I realize it's hard to really know what's going > on much less fix them without really seeing the problem and knowing why > it is a problem(most of these problems have solutions but the > solutions/work-arounds are extremely time consuming compared to what the > debugger/ide can do). This is why I would invest the time to really show > these problems in detail and explain why the alternative is better(and > these things are not arcane issues I have, at least most of them). > > I realize some of these problems are not solvable in any satisfiable > sense but some are definitely needed for efficiency. Some of the harder > ones could be long term goals to work on a little at a time so they > eventually get fixed. > > Since I'm not proficient and already have too much on my plate, I can't > learn the inner workings of Visual D and try to fix these things myself, > hence why you'll have to do it if you choose to. Pedantically, Visual D has only very little influence on the debug experience, it is a combination of the compiler-generated debug information, the VS debugger and the mago debugger-plugin or mago debug-engine depending on what engine you select. > > Of course, you have none to lose to pretend that you'll invest your > time... but I hope you wouldn't do that to me. No big deal if you really > don't want to or can't. Life is more important, but if these fixes can > persist(not regress) then they should make programming in Visual D much > more friendly for most people that use it in the future. I'm interested in making the debug experience better, but I can't promise I can solve all issues. Visual D and mago are still more-or-less one-man-projects I do in my spare time. Videos are good if the issue is hard to demonstrate or not easily reproducible. Small reproducible test cases are often a lot easier to get started, though. Please post issues to https://issues.dlang.org, so they don't get lost in forum discussions.
Re: Interesting Observation from JAXLondon
On Thu, 2018-10-11 at 13:00 +, bachmeier via Digitalmars-d wrote: […] > Suggestions? > > My guess is that the reason they've heard of those languages is > because their developers were writing small projects using Go and > Rust, but not D. I fear it may already be too late. Go, and now Rust, got marketing hype from an organisation putting considerable resources into the projects. This turned into effort from the community that increased rapidly, turning the hype into frameworks and libraries, and word of mouth marketing. It is the libraries and frameworks that make for traction. Now the hype is gone, Go and Rust, and their libraries and frameworks, are well positioned and with significant penetration into the minds of developers. Talk to Java developers and they have heard of Go and Rust, but not D. Go is more likely to them because of Docker and the context of The Web, for which Go has a strong pitch. They have heard of Rust but usually see it as not relevant to them, despite Firefox. Talk to Python developers and they know of Go, many of them of Rust, but almost never D. C and C++ are seen as the languages of performance extensions, though Rust increasingly has a play there. D has vibe.d, PyD, GtkD, and lots of other bits, but they've never quite had the resources of the equivalents in Go and Rust. Also the D community as a whole is effectively introvert, whereas Go and Rust communities have been quite extrovert. "Build it and they will come" just doesn't work, you have to be pushy and market stuff, often using guerilla marketing, to get mindshare. D has an excellent position against Python (for speed of development but without the performance hit) but no chance of penetrating the places where Python is strong due to lack of libraries and frameworks that people use – cf. Pandas, SciKit.Learn, etc. D has an excellent position against Go as a language except that Go has goroutines and channels. The single threaded event loop and callback approach is losing favour. Kotlin is introducing Kotlin Coroutines which is a step on from the observables system of Rx. Structured concurrency abstracting away from fibres and threadpools. Java may well get this via Project Loom which is Quasar being inserted into the JVM directly. Whatever D has it doesn't seem to be going to compete in this space. D without the GC has a sort of position against Rust, but I think that battle has been lost. Rust has won in the "the new C that isn't Go and doesn't have a garbage collector, and isn't C++, but does have all the nice monads stuff, oh and memory safety mostly". When it comes down to it D will carry on as a niche language loved by a few unknown to most. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
[Issue 19301] [DIP1000] missing overload abilities
https://issues.dlang.org/show_bug.cgi?id=19301 Илья Ярошенко changed: What|Removed |Added Keywords||rejects-valid --
[Issue 19301] New: [DIP1000] missing overload abilities
https://issues.dlang.org/show_bug.cgi?id=19301
Issue ID: 19301
Summary: [DIP1000] missing overload abilities
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ilyayaroshe...@gmail.com
struct D
{
const(char)[] d;
this(scope const(char)[] d) @safe
{
this.d = "static_string";
}
this(string d) @safe
{
this.d = d;
}
}
D func(scope string s) @safe
{
return D(s);
}
-
Error: scope variable s assigned to non-scope parameter d calling
mir.exception.D.this
Expected behavior: pass using `this(scope const(char)[] d)`
--
Re: You don't like GC? Do you?
On Thursday, 11 October 2018 at 21:22:19 UTC, aberba wrote: When writing a throwaway script that I will only use a handful of times, optimising that code isn’t necessarily high on my priority list. The priority is to get it written, and get it running. That’s where the V8 (C++) engine that NodeJS is compiled into throws you a bone. That is fine, if you want to position yourself as competition to languages like Go, Java or C#. D wants to be a viable competition to languages like C, C++ and Rust, as a result, there are usecases where GC might not be enough. Also, the quoted part mentions throwaway scripts, which D can be used for, but most people would use Python or Node.JS like in the article instead.
LDC2 -I option results in unresolved externals
I'm using the latest LDC2 beta, and when running the compiler with -I (Look for imports also in ) it fails with unresolved externals. These are my commands. = $ ldc2 "source\setup.d" -I "source" -J "build\vars" -of "build\bin\setup.exe" -m32 -g setup.obj : error LNK2019: unresolved external symbol __D6common17createErrorDialogFxC9ExceptionZv referenced in function __Dmain setup.obj : error LNK2019: unresolved external symbol __D6common14getConsoleArgsFxPuZAAya referenced in function __D5setup20getAvailableBrowsersFZ14__foreachbody1MFKC3std7windows8registry3KeyZi setup.obj : error LNK2001: unresolved external symbol __D6common12__ModuleInfoZ build\bin\setup.exe : fatal error LNK1120: 3 unresolved externals Error: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\link.exe failed with status: 1120 = But this next one works fine. = $ ldc2 "source\setup.d" "source/common.d" -J "build\vars" -of "build\bin\setup.exe" -m32 -g = I'm using LDC2 version 1.12.0-beta2, on DMD v2.082.0, on Windows with VS Build Tools 2017. Any solutions or corrections appreciated.
