Re: Blog post: What D got wrong
On Thursday, 13 December 2018 at 18:29:39 UTC, Adam D. Ruppe
wrote:
The attribute spam is almost longer than the function itself.
I often wished for something like
module foo.bar;
default(@safe, pure);
function foo() { } // is annotated with @safe & pure
@deny(pure) // or pure(false) as I suggested a long time ago
function bar() { } // is annotated only with @safe
That would IMO lighten the burden.
(Oh My) Gentool 0.0.3
(Oh My) Gentool - Yet another C/C++ binding generator. I'm glad to announce the new release - version 0.0.3 is now live. Though I have to release it earlier than I would like to, and there is some features I haven't finished, overall I'm ok with how it did. This release will be the last point zero release. The last 3 months I was working on this project, it helped me to trial and error various approaches and helped to understand possible issues and workarounds. For next release I plan to do partial re-write, which should also address performance - right now it is single-threaded, and running the tool for example on clang will take hours! (don't try this at home, it will crash) How to start - https://github.com/Superbelko/ohmygentool/wiki/QuickStart Code https://github.com/Superbelko/ohmygentool Binaries https://github.com/Superbelko/ohmygentool/releases/tag/v0.0.3
Re: Blog post: What D got wrong
On 12/13/2018 10:29 AM, Adam D. Ruppe wrote: The attribute spam is almost longer than the function itself. Attributes only start to matter when creating code that will be around for a long time (such as reusable libraries). It's a waste of effort for short term code.
Re: Blog post: What D got wrong
On Wednesday, 19 December 2018 at 19:58:53 UTC, Neia Neutuladh wrote: On Wed, 19 Dec 2018 17:28:01 +, Vijay Nayar wrote: Could you please elaborate a little bit more on this? In the linked program, I had expected that "ref" would return a reference to "a" that would behave similar to a pointer. They work like pointers that automatically dereference when assigning to the base type. Only three things in D can be ref: * A function parameter * A function return value * A foreach variable (since that's either going to be a function return value, a function parameter, or a pointer, depending on what you're iterating over) So when the compiler sees something like: ref int foo(); auto a = foo(); It sees that the type of 'a' has to be the same as the return type of 'foo'. Except that's not possible, so it uses the nearest equivalent type: int. And if you have: ref int foo(); int a = foo(); That obviously converts by copying the value. To be fair even in c++ this won't be a reference. int& foo(); auto a = foo(); // a == int auto& a = foo(); // a == int& So it shouldn't be that surprising.
Re: Blog post: What D got wrong
On Wed, 19 Dec 2018 17:28:01 +, Vijay Nayar wrote: > Could you please elaborate a little bit more on this? In the linked > program, I had expected that "ref" would return a reference to "a" that > would behave similar to a pointer. They work like pointers that automatically dereference when assigning to the base type. Only three things in D can be ref: * A function parameter * A function return value * A foreach variable (since that's either going to be a function return value, a function parameter, or a pointer, depending on what you're iterating over) So when the compiler sees something like: ref int foo(); auto a = foo(); It sees that the type of 'a' has to be the same as the return type of 'foo'. Except that's not possible, so it uses the nearest equivalent type: int. And if you have: ref int foo(); int a = foo(); That obviously converts by copying the value.
Re: Announcing Elembuf
On 12/19/18 12:54 PM, H. S. Teoh wrote: On Wed, Dec 19, 2018 at 11:56:44AM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: I had expected *some* improvement, I even wrote a "grep-like" example that tries to keep a lot of data in the buffer such that moving the data will be an expensive copy. I got no measurable difference. I would suspect due to that experience that any gains made in not copying would be dwarfed by the performance of network i/o vs. disk i/o. [...] Ahh, that makes sense. Did you test async I/O? Not that I expect any difference there either if you're I/O-bound; but reducing CPU load in that case frees it up for other tasks. I don't know how easy it would be to test this, but I'm curious about what results you might get if you had a compute-intensive background task that you run while waiting for async I/O, then measure how much of the computation went through while running the grep-like part of the code with either the circular buffer or the moving buffer when each async request comes back. Though that seems like a rather contrived example, since normally you'd just spawn a different thread and let the OS handle the async for you. The expectation in iopipe is that async i/o will be done a-la vibe.d style fiber-based i/o. But even then, the cost of copying doesn't go up -- if it's negligable in synchronous i/o, it's going to be negligible in async i/o. If anything, it's going to be even less noticeable. It was quite a disappointment to me, actually. -Steve
Re: Announcing Elembuf
On Wed, Dec 19, 2018 at 11:56:44AM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: > On 12/18/18 8:41 PM, H. S. Teoh wrote: > > On Tue, Dec 18, 2018 at 01:56:18PM -0500, Steven Schveighoffer via > > Digitalmars-d-announce wrote: [...] > > > Although I haven't tested with network sockets, the circular > > > buffer I implemented for iopipe > > > (http://schveiguy.github.io/iopipe/iopipe/buffer/RingBuffer.html) > > > didn't have any significant improvement over a buffer that moves > > > the data still in the buffer. > > [...] > > > > Interesting. I wonder why that is. Perhaps with today's CPU cache > > hierarchies and read prediction, a lot of the cost of moving the data is > > amortized away. > > I had expected *some* improvement, I even wrote a "grep-like" example > that tries to keep a lot of data in the buffer such that moving the > data will be an expensive copy. I got no measurable difference. > > I would suspect due to that experience that any gains made in not > copying would be dwarfed by the performance of network i/o vs. disk > i/o. [...] Ahh, that makes sense. Did you test async I/O? Not that I expect any difference there either if you're I/O-bound; but reducing CPU load in that case frees it up for other tasks. I don't know how easy it would be to test this, but I'm curious about what results you might get if you had a compute-intensive background task that you run while waiting for async I/O, then measure how much of the computation went through while running the grep-like part of the code with either the circular buffer or the moving buffer when each async request comes back. Though that seems like a rather contrived example, since normally you'd just spawn a different thread and let the OS handle the async for you. T -- Жил-был король когда-то, при нём блоха жила.
Re: Blog post: What D got wrong
On Wednesday, 12 December 2018 at 07:44:12 UTC, Walter Bright wrote: On 12/11/2018 4:51 AM, Nicholas Wilson wrote: > Returning a reference Wow, thats f*ck'n stupid! https://run.dlang.io/is/SAplYw It's quite deliberate. ref in C++ is a type constructor, but it's so special-cased to behave like a storage class, it might as well be one. In D it is. (For example, ref in C++ can only appear at the top level. There are no "pointers to refs".) refs exist so the lifetime of them can be controlled for memory safety. Treating them as flexibly as pointers would make that pretty difficult. refs are the primary way a memory safe container can expose pointers to its contents. Could you please elaborate a little bit more on this? In the linked program, I had expected that "ref" would return a reference to "a" that would behave similar to a pointer. But when that reference is assigned to "b", and "b" is modified, "a" appears to retain its original value, implying that "b" is a copy. When was the copy of "a" made? Was it during the assignment to "b"? I use ref regularly, especially when I have to port C++ code that does exactly that, exposing modifiable references to its members. And in my experience it works quite well, especially for array types and classes. So what is the best way to understand this program and know why a copy of "a" is made?
Re: Announcing Elembuf
On 12/18/18 8:41 PM, H. S. Teoh wrote: On Tue, Dec 18, 2018 at 01:56:18PM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: On 12/18/18 10:36 AM, H. S. Teoh wrote: On Tue, Dec 18, 2018 at 08:00:48AM +, Cyroxin via Digitalmars-d-announce wrote: [...] While the focus of this library is in socket receival, reading from a file doesn't seem to be bad either. [...] Ahh, I see. I thought the intent was to read from a file locally. If you're receiving data from a socket, having a circular buffer makes a lot more sense. Thanks for the clarification. Of course, a circular buffer works pretty well for reading local files too, though I'd consider its primary intent would be better suited for receiving data from the network. Although I haven't tested with network sockets, the circular buffer I implemented for iopipe (http://schveiguy.github.io/iopipe/iopipe/buffer/RingBuffer.html) didn't have any significant improvement over a buffer that moves the data still in the buffer. [...] Interesting. I wonder why that is. Perhaps with today's CPU cache hierarchies and read prediction, a lot of the cost of moving the data is amortized away. I had expected *some* improvement, I even wrote a "grep-like" example that tries to keep a lot of data in the buffer such that moving the data will be an expensive copy. I got no measurable difference. I would suspect due to that experience that any gains made in not copying would be dwarfed by the performance of network i/o vs. disk i/o. -Steve
Re: D is helping from porch pirates
On Wednesday, 19 December 2018 at 08:02:41 UTC, Piotrek wrote: On Monday, 17 December 2018 at 23:13:18 UTC, Daniel Kozák wrote: https://gma.abc/2zWvXCl D supports the bright side of life ;) That's a good spirit. Thanks for sharing. Cheers, Piotrek I found that approach more fun https://www.youtube.com/watch?v=xoxhDk-hwuo
Re: This Week in D is back
Here's a fun fact about the setup: the files are actually written
as D modules. The source code looks like
// just docs: title
/++
Article content
+/
module Blog.Posted_date;
Now, that might seem a little silly, but it provides some
interesting advantages (I should have wrote about this in the
first article!):
1) I can use adrdox's linking with the same pattern: I can link
with the shortcuts to the titles. Similarly, adrdox's navigation
can handle it automatically.
2) I can compile them!
It is #2 that is going to be fun. If I want to write some example
code in there, I can compile and run it without any copy/paste
action. But wait, how do you see the code in the article?
As a documented unittest, of course! And adrdox has two features
that extend it: an `// exclude from docs` comment to take boring
plumbing lines out of the publication
/++ I can compile and run this as a test, and display it in the
article as a complete program the user can copy/paste and run
themselves! +/
unittest {
import arsd.terminal;
void main() {
auto terminal =
Terminal(ConsoleOutputType.linear);
string line = terminal.getline();
terminal.writeln("You wrote: ", line);
}
main; // exclude from docs
}
And I can embed the unittest somewhere in the text (via a magic
`$(EMBED_UNITTEST id)`) instead of just listing them at the end
under examples, so make it flow better with the narrative.
It'll be fun to play with this in the future :)
Re: This Week in D is back
On Wednesday, 19 December 2018 at 14:17:53 UTC, bauss wrote: Thank you Adam for bringing it back. I enjoyed it back when it last ran. You might enjoy looking at the "home" page too: http://dpldocs.info/this-week-in-d/Blog.html links to the old ones, and to the Tip of the Week index from before to quickly skim!
Re: This Week in D is back
On Monday, 17 December 2018 at 22:01:07 UTC, Adam D. Ruppe wrote: Well, I am getting back into it: http://dpldocs.info/this-week-in-d/Blog.Posted_2018_12_17.html I have been waiting for this! Thank you Adam for bringing it back. I enjoyed it back when it last ran.
Re: LDC 1.13.0
On Sunday, 16 December 2018 at 15:57:25 UTC, kinke wrote: Glad to announce LDC 1.13: * Based on D 2.083.1. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. * Substantial debug info improvements. * New command-line option `-fvisibility=hidden` to hide functions/globals not marked as export, to reduce the size of shared libraries. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0 New Wiki page highlighting cross-compilation: https://wiki.dlang.org/Cross-compiling_with_LDC Thanks to all contributors! Native Android packages for the Termux app have been updated, including an Android/x64 package for the first time (with the std.variant issue from the last beta now fixed). While no Android device uses x64, many x64 and AArch64 Chromebooks support installing Android apps like Termux, so if you have a Chromebook, you can now start writing and compiling D code on there too: :) https://medium.com/@clumsycontraria/learning-to-code-on-a-bone-stock-chromebook-a7d0e75303bb An Alpine build of ldc for Docker containers and microservices is also up now.
Re: D is helping from porch pirates
On Monday, 17 December 2018 at 23:13:18 UTC, Daniel Kozák wrote: https://gma.abc/2zWvXCl D supports the bright side of life ;) That's a good spirit. Thanks for sharing. Cheers, Piotrek
