Re: GC memory fragmentation
On Tuesday, 13 April 2021 at 12:30:13 UTC, tchaloupka wrote: Some kind of GC memory dump and analyzer tool as mentioned `Diamond` would be of tremendous help to diagnose this.. I've used bpftrace to do some of that stuff: https://theartofmachinery.com/2019/04/26/bpftrace_d_gc.html
Djinn: a new templating language and code generator
I was using Jinja2 to generate some files and I wished I had D ranges. So I made a toy proof-of-concept of a D answer to Jinja2. Then a COVID-19 outbreak here triggered a lockdown, and I polished it up a bit more: https://theartofmachinery.com/2021/01/01/djinn.html Hope someone else finds it useful, too.
Re: My hobby game running on the web using Emscripten
On Friday, 11 December 2020 at 14:59:47 UTC, Ferhat Kurtulmuş wrote: I saw a post[1] about d running on the browser using emscripten a while ago. I decided to modify my SDL-OpenGL hobby game[2] to run with emscripten. It is still WIP. But, nice to see it running on the browser :-D https://aferust.github.io/drawee-wasm/ source: https://github.com/aferust/drawee-wasm Controls: arrow keys and SPACE. [1] https://theartofmachinery.com/2018/12/20/emscripten_d.html [2] https://github.com/aferust/drawee Cool, nice to see someone doing something with that post.
Re: sumtype 1.0.0
On Wednesday, 25 November 2020 at 00:20:54 UTC, Paul Backus wrote: The exact memory layout and ABI of SumType is deliberately left unspecified. It's an implementation detail that client code isn't supposed to rely on. If you want to pass a SumType's value to a C function, you will first have to extract it using pattern matching. Is that also true of the version being merged into Phobos? Specifically talking about the Phobos version and not the code.dlang.org version, what might change the ABI? An example of where someone would care would be D code with a plugin system, or even a shared library with functions that take SumType instances as parameters.
Re: canFind all elements in a array.
On Tuesday, 10 November 2020 at 08:19:15 UTC, Vino wrote:
foreach(i; data2[]) {
if(data1[].canFind(i[0])) {
writeln(i[1]);
}
}
This is iterating over all the elements in data2 and outputting
some of them, so the output will never be longer than data2.
It looks like you want to iterate over data1. Something like
this:
foreach(i; data1[]) {
auto result = data2[].find!((p, x) => p[0] == x)(i);
if (!result.empty) writeln(result.front[1]);
}
However, you could also use an associative array for data2:
string[string] data2 = [
"DEV Systems": "DEV Cluster",
"QAS Systems": "QAS Cluster",
];
foreach (i; data1[]) {
if (auto v = i in data2) writeln(*v);
}
The "in" operator returns a pointer to the value in data2 at
index "i", or else a null pointer.
See more info here:
https://ddili.org/ders/d.en/aa.html
https://dlang.org/spec/hash-map.html
Re: Druntime without pthreads?
On Tuesday, 20 October 2020 at 16:58:12 UTC, Severin Teona wrote: Hi guys. I have a curiosity, regarding [1] - I had encountered some "undefined reference" errors when trying to link the druntime (compiled for an embedded architecture) without some implementation of the POSIX thread calls (and other stuff too). My curiosity is what would change if I removed from the druntime everything that has to do with mutexes or threads. Would it be possible for the druntime to run and work properly on a microcontroller - where those concepts are not necessary? Could I just remove everything about synchronisation from the druntime, and classes or Garbage Collector to still work properly? [1]: https://forum.dlang.org/post/erwfgtigvcciohllv...@forum.dlang.org An alternative would be to link to a custom library that implements the pthreads ABI, but stubs everything out in a way that makes sense on a single-threaded microcontroller. I wanted to do that once for another project. I never got it to work for unrelated reasons, so I can't say how well the D runtime handles it, sorry. It's probably an easier approach than maintaining your own fork of the runtime, though.
Re: A security review of the D library Crypto
On Wednesday, 1 July 2020 at 11:54:54 UTC, Cym13 wrote: On Wednesday, 1 July 2020 at 10:59:13 UTC, Dukc wrote: It also illustrates what's the prolem with cryptography: it's like coding without ability to test. Who could even dream to get that right the first or even the second time? I think there a shortcoming in the "don't roll your own crypto" - advice: One could think it only applies to the algorithms, not the implementation. That's what I did when I first heard it. There's one more element missing here: the protocol. Cryptography isn't about encrypting stuff, it's about protecting secrets from start to finish and that includes the protocol used. To take an example, many people can think "Hey, I need encryption between my two servers, I'll use AES" and stop there. But use AES how? What mode (CBC,GCM,...)? Let's say CBC is used, what about message authentication? Can I just modify your stream? How is the key exchanged? How is the key generated? Etc. People tend to focus on encryption, be it algorithm or implementation, but once you've got bricks it's still a pain to put them together in a solid way. Things like TLS or SSH actually combine at least 3 completely different sets of bricks to establish the communication, authenticate it, secure it once established etc. So, in a way, "don't roll your own crypto" means "use TLS as much as possible" :) Some people don't want to hear all that because implementing crypto is exciting. So I like to recommend this problem set instead: https://cryptopals.com/ It scratches the "I wanna write crypto" itch, and it makes the "custom crypto is easier to break than you might think" point really well. (By the way, your article had really good depth. I'm subscribing to your RSS :)
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 17:23:51 UTC, Meta wrote: On Wednesday, 26 February 2020 at 17:11:18 UTC, bachmeier wrote: There needs to be a variant of "mansplaining" modified for Python users. Agreed, and there also needs to be a variant of prison, modified for people who post dumb comments on Hacker News. Whatever the language, I like the "show me the code/graphs/benchmarks/disassembly/data/something/anything" approach Atila used in his blog post. When I wrote a blog post about why C const is practically useless for optimisation, I lost count of how many people smugly pointed out that const "should" go on the other side of the *, as if that made all the difference. If they actually tried it they'd see it makes zero difference because "int * const x" is even less useful for optimisation.
Re: FeedSpot Recognizes the GtkDcoding Blog
On Friday, 7 February 2020 at 19:51:52 UTC, Andre Pany wrote: On Friday, 7 February 2020 at 18:16:37 UTC, Les De Ridder wrote: I'm not sure why LGPL is an issue. Does GtkD not allow dynamic linking? I am not an expert at all in the topic of licensing. This is my understanding: Gtk has the license lgpl. As long as you link dynamically to the shared object files, you can use it in commercial products. GtkD is a D wrapper for GTK. It is D source code which ease the access to the C api of Gtk. GtkD has also the license lgpl. To use GtkD in my application I have to statically link the D source code. Now it gets more complicated, GtkD has some additions to the lgpl rules. I cannot judge how high the risk is for companies to use this component, but as an employee I do anything to avoid any risk for the company I work for. Kind regards Andre I prefer MPLv2 for LGPL-style liberal copyleft in D code because it unambiguously draws the line based on files. No one has to speculate about whether, for example, LGPL's special exceptions for macro expansion also cover D's template system. https://www.mozilla.org/en-US/MPL/2.0/FAQ/
Re: wc in D: 712 Characters Without a Single Branch
On Tuesday, 28 January 2020 at 14:01:35 UTC, Mike Parker wrote: Robert Schadek was inspired by a post he saw on Hacker News a while back showing an implementation of wc in Haskell totaling 80 lines. I enjoyed the article overall, but I think this part lets it down a bit: Is the Haskell wc faster? For big files, absolutely, but then it is using threads. For small files, GNU’s coreutils still beats the competition. At this stage my version is very likely IO bound, and it’s fast enough anyway. Admit it, "my version is very likely IO bound" is hand-wavey. The top comment on HN right now is pointing out that it doesn't make sense. It would be a better tech article if it stuck to the facts by either cutting out the hand-wavey bit (and just saying "it's fast enough anyway") or doing a test. (Quick and dirty way: running the code on a large file and seeing if it maxes out a CPU using the "top" command. More elegant way: using tools like these https://github.com/sysstat/sysstat/) Remember: plenty of us on the forums are happy to help make a D article more interesting.
Re: code.dlang.org downtime
On Tuesday, 17 December 2019 at 17:34:07 UTC, H. S. Teoh wrote: On Tue, Dec 17, 2019 at 01:34:16AM +, bachmeier via Digitalmars-d-announce wrote: [...] Oh, I don't doubt that. My point was that it makes the D language project look like a small-scale open source project relying on volunteers (in this case Sonke) being generous with time and resources. What manager is going to trust a project like that with a major project? It seems unlikely that this would not be considered a major issue. This looks like something the D Foundation ought to fund. ... If a volunteer-driven opensource project like Debian can have worldwide multiple redundant FTP mirrors that almost guarantees 100% uptime, why can't we? I agree. I sent an email to the Foundation in October offering to help fund some proper infrastructure. Maybe the email got lost. The offer still stands.
Re: D for microservices: ldc, rdmd, dub now available on Alpine x86_64
On Tuesday, 5 November 2019 at 12:20:04 UTC, Jacob Carlborg wrote: On Tuesday, 5 November 2019 at 11:49:20 UTC, Daniel Kozak wrote: Generally no, because Apline use musl libc instead of glibc, so there are some issues with that The correct way is to use static linking and putting only the binary in a Docker image, i.e. "from scratch" [1] ;). But using Alpine and musl will help with building the binary. [1] https://hub.docker.com/_/scratch And the neat way to do that is with a multi-stage build: one Dockerfile, with an Alpine container building the binary, then copying to a FROM scratch container: https://docs.docker.com/develop/develop-images/multistage-build/ The musl build is practically necessary because glibc has effectively given up standalone static binary support. So, thanks BPF Korea :)
Re: remake of remake of Konami's Knightmare
On Saturday, 28 September 2019 at 02:59:20 UTC, Murilo wrote: On Thursday, 23 November 2017 at 12:18:38 UTC, ketmar wrote: recently i worked on remake of DOS remake of Konami's Knightmare game[0]. the game is playable now, it has music from original MSX Knightmare, and sfx/gfx/levels from DOS remake. it is written in D, of course, and it is FOSS. you can find the sources here[1]. Hi, I would like to see your source code please because I am making a game myself and I need to learn how to do it, I figured I could read your code and learn from it. The post you quoted links to the git repo. You can clone it with "git clone http://repo.or.cz/knightmare.git;, or view the code online at https://repo.or.cz/knightmare.git/tree (includes a link to download the tarball).
Re: Linking D Runtime
On Saturday, 24 August 2019 at 02:10:19 UTC, Jonathan Levi wrote: I would love a more portable solution though. This should work for now. How are you building the D code? It should be possible to build a library (with -lib and/or -shared) that statically includes the runtime and Phobos. If you want to dynamically link the standard libraries, then you shouldn't need to specify the full path (just "phobos2" and "druntime") as long as they're installed in one of the system's library search paths (see /etc/ld.so.conf on GNU/Linux).
Re: Snake game
On Wednesday, 24 July 2019 at 07:47:03 UTC, Alireza SN wrote: Hi, I'm new to D. Thought it would be fun to write a simple snake game for start. I hope it's not irrelevant to post it here. https://github.com/TheWeirdDev/SnakeD I posted it to the dlang subreddit: https://old.reddit.com/r/d_language/comments/ch63ht/simple_ncurses_terminal_snake_game/
Re: What are some ways to get more strict type-checking?
On Monday, 6 May 2019 at 02:02:52 UTC, Devin wrote: Recently, I poorly refactored some code, which introduced an obvious bug. But to my astonishment, the broken code compiled without any warnings or notifications. A minimum example is shown below: alias ID = uint; ... alias doesn't create a distinct type, but maybe Typedef from Phobos is what you want: https://dlang.org/library/std/typecons/typedef.html
Re: How does buffering actually work?
On Thursday, 28 February 2019 at 21:17:23 UTC, Cleverson Casarin
Uliana wrote:
It works almost perfectly, except that it doesn't wait for my
first Enter after printing "First name: value1". Rather, it
prints both "First name: value1" and "First name: value2"
together on the same line, then it starts to behave as
expected, e.g. printing one line at a time and waiting for me
to press Enter.
Perhaps that happened with some other variation of the code. The
code you wrote shouldn't work like that (it doesn't for me when I
tried, at least).
Ali has some good answers for fixing your code. (readf("\n")
also works, BTW.) Hopefully this helps with the "How does
buffering actually work?" question:
D uses the system's standard C library for IO, like most
programming languages do, so IO buffering isn't fundamentally
different (but some high-level functions might have different
behaviour).
The standard C library provides buffered IO for input and output.
By default terminal IO is line-buffered (not sure if that's all
systems), so you might see delays up until a newline, but
line-by-line IO won't notice the buffering.
What happens here?
write()
read()
write()
read()
The first write goes to the output buffer. If the buffer ever
gets full (or has a newline in the case of line buffering), the
data gets flushed to the real output.
At the read, it's possible there's still some data in the output
buffer that's not flushed. If needed, you can explicitly call
flush() to make sure there isn't. If there happens to already be
data in the read buffer, read() will take as much as it needs to.
If there isn't enough, then real input will happen, and the call
will block until data comes in. The real read will ask for a
chunk of data, which will often be more than the read() call
needs. The remainder gets put into the buffer (that's what it's
for). (The kernel and libc actually both have IO buffers.)
In any case, the second write won't happen until the read has
finished.
Rinse and repeat for the remaining lines.
Re: Should D file end with newline?
On Friday, 15 February 2019 at 13:14:47 UTC, Patrick Schluter wrote: A lots of fgets() based tools on Unix systems fail to read the last line if it doesn't contain a line feed character at the end. Afaicr glibc implementation does not have that problem but a lot of other standard C libs do. When we were still on Solaris we had to be very careful with that, as strange things could happen when using sed, awk, wc and a lot of other standard Unix commands. Now that we have switched to Linux we don't have the issue anymore. That makes sense. I guess I'm spoiled by GNU.
Re: Should D file end with newline?
On Tuesday, 12 February 2019 at 20:03:09 UTC, Jonathan M Davis wrote: So, I'd say that it's safe to say that dmd The whole thing just seems like a weird requirement that really shouldn't be there, Like I said in the first reply, FWIW, it's a POSIX requirement. Turns out most tools don't care (and dmd is apparently one of them). If you want an easy counterexample, try the wc command (it miscounts lines for non-compliant files). I've never seen that break an actual build system, which is why I said you could mostly get away with it. On the other hand, being POSIX-compliant always works. it matters even less if text editors are automatically appending newlines to files if they aren't there whether they show them or not, since if that's the case, you'd have to really work at it to have files not ending with newlines anyway. There are definitely broken text editors out there that won't add the newline (can't think of names). Like Jacob Carlborg said, Github flags the files they generate. hexdump shows a newline followed by a null character followed by a newline after the carriage return. hexdump is printing little-endian 16b by default, so I think that's just two newlines followed by a padding byte from hexdump. Try using the -c or -b flag and you probably won't see any null byte. Curiously, if I create a .cpp or .c file with vim and have it end with a curly brace, vim _does_ append a newline followed by a null character followed by a newline at the end of the file. So, I guess that vim looks at the extension and realizes that C/C++ has such a requirement and takes care of it for you, but it does not think that .d files need them and adds nothing extra for them. It doesn't add anything for a .txt file when I tried it either. Are you sure? vim is supposed to add the newline for all text files because that's POSIX. It does on my (GNU/Linux) machine.
Re: Should D file end with newline?
On Saturday, 9 February 2019 at 21:19:27 UTC, Victor Porton wrote: ISO C++ specifies that the C++ file must end with a newline. Should D file end with newline, too? I'm sure you could mostly get away without one, but POSIX says that all text files should end with a newline. There are some POSIX tools that don't work properly without the final newline.
Re: Vibe.d on Raspberry Pi
On Monday, 5 November 2018 at 16:06:38 UTC, Pander wrote: As reported in https://forum.dlang.org/thread/rgmbwuwfihauvngqm...@forum.dlang.org I've written a brief tutorial for the Pi board. I'm pretty new to D and the community so any suggestion is really highly appreciated. Bye, Andrea Nice! One suggestion: add the last step to the documentation that gets you a built and running server. It's a little thing, but it really helps people learning.
Re: Quick C bindings
On Friday, 28 September 2018 at 16:39:14 UTC, Márcio Martins wrote: What are you guys using these days to generate bindings? Writing them by hand is easy if the library doesn't use the preprocessor much. I often do that for simple jobs. dpp supports preprocessor directives (because it actually does a preprocessor pass).
Re: Updating D beyond Unicode 2.0
On Friday, 28 September 2018 at 11:37:10 UTC, Dukc wrote: It's easy to miss a part of a post sometimes. That's very true, and it's always good to give people the benefit of the doubt. But most people are able to post constructively here without * Abrasively and condescendingly declaring others' posts to be completely pointless * Doing that based on one single aspect of a post, without bothering to check the whole post or parent post * Doubling down even after getting a hint that the poster might not have posted 100% cluelessly * Doing all this more than once in a thread If Shachar starts posting constructively, I'll happily engage. I mean that. Otherwise I won't waste my time, and I'll tell others not to waste theirs, too.
Re: Updating D beyond Unicode 2.0
On Thursday, 27 September 2018 at 16:34:37 UTC, aliak wrote: On Thursday, 27 September 2018 at 13:59:48 UTC, Shachar Shemesh wrote: On 27/09/18 16:38, aliak wrote: The point was that being able to use non-English in code is demonstrably both helpful and useful to people. Norwegian happens to be easily anglicize-able. I've already linked to non ascii code versions in a previous post if you want that too. If you wish to make a point about something irrelevant to the discussion, that's fine. It is, however, irrelevant, mostly because it is uncontested. This thread is about the use of non-English in *identifiers*. This thread is not about comments. It is not about literals (i.e. - strings). Only about identifiers (function names, variable names etc.). If you have real world examples of those, that would be both interesting and relevant. Shachar English doesn't mean ascii. You can write non-English in ascii, which you would've noticed if you'd opened the link, which had identifiers in Norwegian (which is not English). And again, I've already posted a link that shows non-ascii identifiers. I'll paste it again here incase you don't want to read the thread: https://speakerdeck.com/codelynx/programming-swift-in-japanese Shachar seems to be aiming for an internet high score by shooting down threads without reading them. You have better things to do. http://www.paulgraham.com/vb.html
Re: Updating D beyond Unicode 2.0
On Sunday, 23 September 2018 at 06:53:21 UTC, Shachar Shemesh wrote: On 23/09/18 04:29, sarn wrote: You can find a lot more Japanese D code on this blogging platform: https://qiita.com/tags/dlang Here's the most recent post to save you a click: https://qiita.com/ShigekiKarita/items/9b3aa8f716848278ef62 Comments in Japanese. Identifiers in English. Not advancing your point, I think. Shachar Well, I knew that when I posted, so I honestly have no idea what point you assumed I was making.
Re: Updating D beyond Unicode 2.0
On Sunday, 23 September 2018 at 00:18:06 UTC, Adam D. Ruppe wrote: I have seen Japanese D code before on twitter, but cannot find it now (surely because the search engines also share this bias). You can find a lot more Japanese D code on this blogging platform: https://qiita.com/tags/dlang Here's the most recent post to save you a click: https://qiita.com/ShigekiKarita/items/9b3aa8f716848278ef62
Re: Updating D beyond Unicode 2.0
On Saturday, 22 September 2018 at 12:37:09 UTC, Steven Schveighoffer wrote: But aren't some (many?) Chinese/Japanese characters representing whole words? -Steve Kind of hair-splitting, but it's more accurate to say that some Chinese/Japanese words can be written with one character. Like how English speakers wouldn't normally say that "A" and "I" are characters representing whole words.
Re: std.experimental.collections.rcstring and its integration in Phobos
On Wednesday, 18 July 2018 at 12:03:02 UTC, Eugene Wissner wrote:
Therefore it shouldn't compile at all, but
rcstring("ä")[].split("|")
or
rcstring("ä").byCodePoint.split("|")
+1 to requiring an explicit byCodeUnit or whatever.
For every "obvious" way to interpret a string as a range, you can
find an application where the obvious code is surprisingly buggy.
(BTW, rcstring("ä").byCodePoint.split("|") is buggy for
characters made of multiple codepoints. Canonicalisation doesn't
fix it because many characters just don't have a single-codepoint
form.)
Re: D's Destructors are What Scott Meyers Warned Us About
On Monday, 9 July 2018 at 01:19:28 UTC, Mike Franklin wrote: In the context of your blog post at https://theartofmachinery.com/2018/05/27/cpp_classes_in_betterc.html, I'm wondering if the changes in 2.081 help matters at all: I'm wondering if any of the changes in 2.081 improves the situation here: e.g. https://dlang.org/changelog/2.081.0.html#cpp_destroy Mike I don't know yet, but, yeah, that work looks interesting and I definitely have to do some more testing. BTW, I'm still interested in writing DIPs. I've just been working a lot on another project lately.
Re: How can I point an array to existing data in memory while using Better C?
On Sunday, 8 July 2018 at 21:11:53 UTC, Stijn Herreman wrote: On Sunday, 8 July 2018 at 20:27:34 UTC, Stijn Herreman wrote: I should point out that I only have a vague idea of what I'm doing, I tried things until it compiled and worked (at first glance). If there are any docs that properly explain the casting of pointers, I'd appreciate the links. I found the following works as desired: environment.d public __gshared header* GPT_header; public __gshared partition_entry* GPT_entries; main.d GPT_header = cast(header*)0x7e00; GPT_entries = cast(partition_entry*)0x8000; That still lets me access GPT_entries with an index, e.g. GPT_entries[0]. Is this how it's supposed to be done, or is there a better way still? You can also easily make slices out of pointers. E.g.: // Some backing memory int[10] x; // Take a pointer int *xp = x.ptr; // Convert pointer to D slice int[] x2 = xp[0..10]; assert (x2.length == 10); (Of course, you don't need to break it into steps in real code, and it works fine in betterC.) There's still not a lot of info out there about doing betterC, but maybe you can find some examples in the following code. It works without any druntime at all, including TypeInfo. This is the entry point after a bootloader loads the D code and enters 32b protected mode: https://gitlab.com/sarneaud/xanthe/blob/master/src/os/drivers-bios.d#L198
Re: Compilation is taking a ton of memory
On Thursday, 28 June 2018 at 16:24:07 UTC, H. S. Teoh wrote: I continue to use SCons for my D projects. For dub dependencies, I just create a fake empty dub project with declared dependencies and run that separately for refreshing dependencies, but the actual compiling and linking is handled by SCons. Sounds like what I'm doing. I build the dependencies using dub on a dummy project, then use "dub describe" to find all the files I need and install them into my project directory. Then I can use whatever build system I want (currently tup).
Re: Compilation is taking a ton of memory
On Wednesday, 27 June 2018 at 16:00:37 UTC, Mario Silva wrote: Any tips on how to code in a way that minimizes both compilation times and memory consumption when compiling? Here are my tips. I'd love to hear more from others. * Try to reduce imports. E.g., say you use a lot of stuff from std.algorithm in your implementations, but not in your external interface. In that case, instead of doing "import std.algorithm;" at the module top, do things like "import std.algorithm.searching : canFind;" inside function bodies. If you think about this when designing your external interfaces, you can let user code import what it needs from your modules without recursively importing half the rest of the D ecosystem with it. * Templates are great, but not everything has to be one. Sometimes a simple delegate makes a perfectly generic interface. Templated code can be more expensive to compile, while non-templated code can be compiled once in a library and then reused. * CTFE is awesome but currently a memory hog. BTW, vibe.d isn't great with this stuff, TBH. Simple public API functions return types with "auto" that turn out to be several layers of templated wrappers all the way down, each wrapper coming from a different module. That's an example of what to avoid doing.
Re: D's Destructors are What Scott Meyers Warned Us About
On Monday, 28 May 2018 at 22:53:03 UTC, 12345swordy wrote: Interesting... You don't mind me asking your assistance on writing DIP on this? I have one set up already, and I needed help as 1.) This is my first time writing a DIP 2.) I don't know what main course of action to take regarding this issue. I want to write a draft of a DIP related to attribute inference next chance I get (possibly this weekend). It's related to this, so I'll post the draft here. You're very welcome to comment (or send PRs). BTW, I'll just be following these guidelines and using accepted DIPs as examples: https://github.com/dlang/DIPs/blob/master/GUIDELINES.md https://github.com/dlang/DIPs/tree/master/DIPs/accepted
Re: SecureD Futures (v2.0)
On Monday, 28 May 2018 at 07:52:43 UTC, Adam Wilson wrote: I understand that. Sorry, not for nothing, but you obviously don't. For starters, if you were familiar with the key derivation tools available 24hrs ago, you wouldn't have come up with PBKDF2 on PBKDF2. I suggest slowing down a little, and asking people on a crypto forum if you're still not sure. If you explain your problem from the start, they might even have some better ideas. When that RFC (correctly) recommends using a salt, it's talking about HKDF-Extract, which is a tool for taking a large amount of mostly-random data and turning it into an appropriate KDK. That's not the problem you have here. The problem you have is generating keys for different purposes from a KDK. That's a problem HKDF-Expand addresses, and it doesn't use a salt. Let me ask the question a different way. What is the reason NOT to use 2 different salts for the MAC and KEY generation steps? You might choose to not use extra salts for the same reason you've already chosen to not encrypt three times, or add extra HMACs for each individual block of ciphertext: it's not solving any problems.
Re: D's Destructors are What Scott Meyers Warned Us About
On Monday, 28 May 2018 at 20:13:47 UTC, 12345swordy wrote: How is __vdtor is going to be called, via destroy or via directly? Code using destroy() can still use destroy(). Otherwise, __vdtor would be callable in the same way that __dtor and __xdtor are. The plan is to have a better, safer, less problematic (with attributes) solution to what __dtor and __xdtor do with classes, so that longer term we can deprecate and remove the old way. The issue that I see that your going to create a "BaseObject" for every attribute or combination of said attributes. Which creates way too much code bloat. Even more so with the possibility of adding more attributes in the future. So, I won't say the problem doesn't exist, but it's nowhere near as bad as that. The idea isn't to have a BaseObject for every possible combination of attributes. The BaseObject UDA is just a solution to the problem destructors have with inheritance+attributes. Once you have a base class marked BaseObject, you can derive from it and add whatever combination of attributes you like. The BaseObject-marked class can have as much functionality as needed, except it can't have a non-trivial destructor. That's okay for the immediate problems of implementing ProtoObject and __vdtor, and making safe containers, and improving C++ interop and -betterC code. If needed in future, destructor support could be added in the existing language by exploiting attribute inference, but maybe by that time it would be better to make language changes and turn BaseObject into a no-op. It doesn't matter. I just think it's better to have a viable migration plan that doesn't start with "let's make all these language changes first".
Re: SecureD Futures (v2.0)
On Monday, 28 May 2018 at 06:22:02 UTC, Adam Wilson wrote: On 05/27/2018 08:52 PM, sarn wrote: On Monday, 28 May 2018 at 02:25:20 UTC, Adam Wilson wrote: I like it. But it does require more space. We need three salts and three lengths in the header. One for the PBKDF2 KDK, one for the MAC key, and one for the encryption key. HKDF-Expand doesn't need a salt. You just need one salt to make the KDK (whether you use PBKDF2 or HKDF-Extract for that) and no extra salts for deriving the encryption and MAC key. Strictly speaking, it's is Optional but Strongly Recommended per RFC5869-3.1 There's HKDF-Expand and there's HKDF-Extract. HKDF-Extract takes an optional salt and HKDF-Expand doesn't use a salt at all (take a closer look at that RFC). That OpenSSL routine is the combination of the two, so that's why it takes the salt.
Re: D's Destructors are What Scott Meyers Warned Us About
On Sunday, 27 May 2018 at 22:27:52 UTC, sarn wrote: I've been thinking this through a bit, and here's what I've got so far: Here's a tweak that should be implementable without any language changes: Instead of trying to detect an empty destructor, we use a UDA on the class --- call it BaseObject or something. A BaseObject-marked class is meant to be something like Andre's ProtoObject, or a custom alternative base. It must not define a destructor or include members with destructors (could relax this in future but works for now), and must only inherit from other BaseObject-marked classes. With that, __vdtor could be implemented using a template mixin. For a BaseObject class, that would generate an empty virtual __vdtor. For other classes, it would call __xdtor and then (non-virtually) call __vdtor for the superclass as long as it's not a BaseObject class. Can anyone see something I've missed? I think it works with the current type system, makes Andre's ProtoObject possible while supporting subclassing with @nogc or whatever, and gives us safe class destructors that could be compatible with C++.
Re: SecureD Futures (v2.0)
On Monday, 28 May 2018 at 02:25:20 UTC, Adam Wilson wrote: I like it. But it does require more space. We need three salts and three lengths in the header. One for the PBKDF2 KDK, one for the MAC key, and one for the encryption key. HKDF-Expand doesn't need a salt. You just need one salt to make the KDK (whether you use PBKDF2 or HKDF-Extract for that) and no extra salts for deriving the encryption and MAC key.
Re: using wkhtmltopdf with D
On Monday, 28 May 2018 at 01:28:10 UTC, Dr.No wrote: What's likely the reason of the crash? mismatch between D and C memory alignment? From an ABI point of view, the raw pointers won't care about the memory structure they point to. The function call is the only thing that depends on the binary interface. If you translate the code into C, does it work?
Re: SecureD Futures (v2.0)
On Sunday, 27 May 2018 at 10:27:45 UTC, Adam Wilson wrote:
struct cryptoHeader {
ubyte hdrVersion; // The version of the header
ubyte encAlg; // The encryption algorithm used
ubyte hashAlg; // The hash algorithm used
uint kdfIters; // The number of PBKDF2 iterations
ubyte authLen; // The length of the authentication value
ubyte saltLen; // The length of the PBKDF2 salt
ubyte ivLen;// The length of the IV
ulong encLen; // The length of the encrypted data
ulong adLen;// The length of the additional data
}
Should there be any kind of key identifier, or do you consider
that a separate issue?
- MacKey = PBKDF2 over EncKey once using same inputs as EncKey
How about this?
Use PBKDF2 to generate a key-derivation-key (KDK), then use
HKDF-Expand (https://tools.ietf.org/html/rfc5869) to derive the
encryption key and MAC key separately.
I think that's more standard. I don't know how much it matters
in practice, but a lot of cryptographers don't like generating
MAC/encryption keys from each other directly.
Also, it's probably safer to use HKDF-Extract instead of using
raw keys directly when not using PBKDF2.
Re: DIP 1012--Attributes--Preliminary Review Round 1
On Sunday, 27 May 2018 at 13:44:40 UTC, Mike Franklin wrote: I don't know what's happening with this DIP, but I've recently encountered a real-world problem for which there is no palatable workaround that this DIP would likely solve: https://github.com/dlang/druntime/pull/2184#pullrequestreview-120643123 My attempts to workaround the issue I posted at https://forum.dlang.org/post/uhgzgmowqcczczrdt...@forum.dlang.org That PR may be useful for motivating this DIP. Mike It looks like all you need is a way to toggle attributes with a flag, like pure(isPure) or something. IIRC, last time that came up, it turned into a bikeshedding fest about the syntax. (I don't think parentheses works with UDAs.) Anyway, yeah, we need the functionality. However, this DIP is *way* more complicated. I stand by what I said before: https://forum.dlang.org/post/dnmcqwkdfmommiiug...@forum.dlang.org Jonathan M Davis said it in long form: https://forum.dlang.org/post/mailman.5429.1501206646.31550.digitalmar...@puremagic.com
Re: D's Destructors are What Scott Meyers Warned Us About
On Sunday, 27 May 2018 at 09:55:56 UTC, Mike Franklin wrote:
TypeInfo has become my nemesis. I've been trying to replace
runtime hooks that depend on TypeInfo with templates that can
get their information at compile-time, but I'm running into all
sorts of problems. e.g. Did you know array.length can be set
in @safe nothrow pure code, but it lowers to runtime functions
that are neither @safe, nothrow, nor pure?
Ouch.
Anyway, I'm getting better at modifying the compiler/runtime
interface. If we can come up with a solution to this mess, and
I can understand it, I might be able to implement it.
I've been meaning to learn more about how the compiler/runtime
interface works myself but still haven't got around it. I'm
probably going to learn a lot by looking at your PRs.
I've been thinking this through a bit, and here's what I've got
so far:
At first I obviously wanted an all-round "just works" low-level
interface for destroying objects. But after looking at how
people are using __dtor/__xdtor in real code, and looking at the
PRs for destroy(), it's obvious that there's a lot of
disagreement about what that means. Let's leave that topic for
now.
If we just focus on fixing classes, we can add, say, __vdtor (I
really don't care much about the name, BTW). This needs to be a
normal virtual function in the vtable (preferably in a way that's
compatible with C++ ABIs) that runs the user-defined destructor
code, then recursively calls destructors for members and base
classes.
The generation of __vdtor also needs a special case to make
attributes work. Something like "an empty destructor has
attributes inferred like templated functions are, restricted by
any of its bases". For example, this needs to work:
extern(C++)
{
class Base
{
// Virtual
~this() @nogc
{
}
}
class Derived
{
// Not marked pure but is still @nogc
// (NB: explicitly marking @nogc isn't needed in current
language)
override ~this() @nogc
{
}
}
class Derived2 : Derived
{
override ~this() @nogc pure
{
// Marked pure, but still recurses to empty destructors
in Derived and Base
}
}
}
Right now __vdtor would need to be implemented with a thunk that
wraps around __xdtor (like I implemented here:
https://theartofmachinery.com/2018/05/27/cpp_classes_in_betterc.html). But if __vdtor is implemented, the D runtime code can be simplified to use __vdtor for classes, then hopefully we can deprecate and remove __dtor and __xdtor for classes, and then __vdtor can become the native destructor implementation.
Re: D's Destructors are What Scott Meyers Warned Us About
On Sunday, 27 May 2018 at 21:11:42 UTC, 12345swordy wrote: On Sunday, 27 May 2018 at 18:55:41 UTC, Mike Franklin wrote: And see this talk for a demonstration of the benefits https://www.youtube.com/watch?v=endKC3fDxqs Mike Can you actually reply to me instead of saying "read/watch this"? I'm not going to watch an hour, just to see how you going to achieve this. tl;dw: there's precedent. Historically typeinfo has been overused in the runtime library (I think it's because a lot of the code/architecture predates today's templates). For example, if you compared an int[] to an int[], the compiler would generate a function that looked up a comparator for int using RTTI, and would iterate over the arrays calling it on each element. That video is about replacing code like that with smarter templated code that's not only faster but results in *less* code bloat.
Re: Draft for DIP concerning destroy is up.
Just had a thought: attributes are inferred for templates, so maybe the ProtoObject could have a templated empty destructor. I don't think this would work with the existing destructor implementation, but it least it could be possible.
Re: Draft for DIP concerning destroy is up.
On Friday, 25 May 2018 at 21:01:16 UTC, Mike Franklin wrote: On Friday, 25 May 2018 at 20:08:23 UTC, 12345swordy wrote: https://github.com/dlang/DIPs/pull/120 Feedback would be very appreciated. I was under the impression that Andrei's ProtoObject was supposed to remedy that: https://forum.dlang.org/post/pa1lg6$1lud$1...@digitalmars.com Mike It's not enough for destructors because they work "both ways". If we have a universal base class with a @nogc destructor, then no subclass can have a non-@nogc destructor. In particular, it won't be compatible with today's Object. But if the universal base class has a destructor that's not @nogc, then classes can't ever be destroyed in @nogc code because destructors need to recurse to base class destructors. I think we have to either give up on having a sole universal base class, or special-case destructors in the language (or some combination of both).
Re: D's Destructors are What Scott Meyers Warned Us About
On Thursday, 24 May 2018 at 12:26:00 UTC, Steven Schveighoffer wrote: I added the bug report here: https://issues.dlang.org/show_bug.cgi?id=18903. I outline exactly how to fix it, if anyone wants an easy PR opportunity. -Steve Thanks for digging into that. On Wednesday, 23 May 2018 at 23:18:46 UTC, Manu wrote: On 23 May 2018 at 15:47, sarn via Digitalmars-d <digitalmars-d@puremagic.com> wrote: On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole wrote: I would consider the current state with classes a bug. So ticket please, it should not require a DIP to change (although Walter may disagree). Unfortunately, the way __dtor and __xdtor work for classes can't be changed without the risk of breaking code. (Even if the current behaviour is broken, users might be working around it.) In what way is the current behaviour *broken*? (as opposed to awkward, confusing, and poorly documented) If c is a class instance, then c.__xdtor compiles and runs but can only be guaranteed to run the right destructors in special controlled cases where there's most likely a better way. That std.signals code that Steven filed a bug report for is example of why we can't just fix the behaviour, though. If we just fixed __dtor/__xdtor, any code that used std.signals would start having ugly bugs at run time. I think that longer term we'll have to deprecate and remove these functions.
Re: D's Destructors are What Scott Meyers Warned Us About
On Wednesday, 23 May 2018 at 15:43:31 UTC, Steven Schveighoffer wrote: Coincidentally, this JUST changed due to a different reason: https://github.com/dlang/druntime/pull/2178 Please file an enhancement request. I still think it could be better, so I added a further issue: https://issues.dlang.org/show_bug.cgi?id=18899 -Steve This is really good news!
Re: D's Destructors are What Scott Meyers Warned Us About
On Wednesday, 23 May 2018 at 13:12:57 UTC, Steven Schveighoffer wrote: On 5/22/18 9:59 PM, sarn wrote: * Some code uses __dtor as a way to manually run cleanup code on an object that will be used again. Putting this cleanup code into a normal method will cause fewer headaches. Using __dtor is a very bad idea in almost all cases. Putting cleanup code into a normal function can have some of the same pitfalls, however (what if you forget to call the super version of the method?). The only *correct* way to destroy an object is to follow the runtime's example or call the function directly. The destructor also has the nice feature of being called when the struct goes out of scope. Best advice -- just use destroy on types to clean them up. Here's an example of what I'm talking about: https://github.com/dlang/phobos/blob/master/std/signals.d#L230 It's running __dtor manually just to run some code that happens to be in the destructor. It's obviously not meant to run any other destructors (at least, the documentation doesn't say "Use this mixin in your object and then calling disconnectAll() will destroy everything in your object."). It's a broken design pattern, but existing code is doing it. (As I said, I reviewed a lot of D packages, and I don't have time to file bug reports or PRs for each one.) But this is not necessarily the definition of POD. Generally this means it has no postblit, and some people may even be expecting such a thing to have no methods as well. So I'm not sure we want to add such a definition to the library. The common case is that some data types can be blitted around as raw memory without worrying about destructors, postblits, or whatever is added to the language in future. This is the thing that seems to matter. (Have you seen any code that needs to care if a struct has methods? It sounds like a very special case that can still be handled using current compile-time reflection anyway.) __traits(isPOD) seems to do the job, and is a lot better than the ad hoc implementations I've seen. We should encourage people to use it more often.
Re: D's Destructors are What Scott Meyers Warned Us About
On Wednesday, 23 May 2018 at 02:13:13 UTC, rikki cattermole wrote: I would consider the current state with classes a bug. So ticket please, it should not require a DIP to change (although Walter may disagree). Unfortunately, the way __dtor and __xdtor work for classes can't be changed without the risk of breaking code. (Even if the current behaviour is broken, users might be working around it.)
Re: D's Destructors are What Scott Meyers Warned Us About
On Wednesday, 23 May 2018 at 19:28:28 UTC, Paul Backus wrote: On Wednesday, 23 May 2018 at 01:59:50 UTC, sarn wrote: The one other usage of these low-level destructor facilities is checking if a type is a plain old data struct. This is an important special case for some code, but everyone seems to do the check a different way. Maybe a special isPod trait is needed. There's this: https://dlang.org/spec/traits.html#isPOD Damn, that's exactly what I wanted; I don't know how I missed it. I guess that's why it's good to bounce ideas off others.
D's Destructors are What Scott Meyers Warned Us About
(I'm referring to Scott's 2014 DConf talk:
https://www.youtube.com/watch?v=KAWA1DuvCnQ)
I was actually preparing a DIP about this when Manu posted to the
forums about his own related problems with C++ interop.
I traced a bug in some of my D code to my own misunderstanding of
how D's destructors actually work. So I did some research and
discovered a bunch of edge cases with using __dtor, __xdtor and
hasElaborateDestructor. I tried reviewing the packages on
code.dlang.org and some elsewhere (thankfully only about 1% of D
packages use these functions directly) and it turns out I'm not
the only one confused. I don't have time to file bug reports for
every package, so, if you're responsible for code that handles
destructors manually, please do a review. There's a *lot* of
buggy code out there.
I'm starting this thread to talk about ways to make things
better, but first the bad news. Let's use this idiomatic code as
an example of typical bugs:
void foo(T)(auto ref T t)
{
...
static if (hasElaborateDestructor!T)
{
t.__dtor();
}
...
}
Gotcha #1:
__dtor calls the destructor defined by T, but not the destructor
defined by any members of T (if T is a struct or class). I know,
some of you might be thinking, "Silly sarn, that's what __xdtor
is for, of course!" Turns out this isn't that widely known or
understood (__dtor is used in examples in the spec ---
https://dlang.org/spec/struct.html#assign-overload). A lot of
code is only __dtor-aware, and there's at least some code out
there that checks for both __dtor and __xdtor and mistakenly
prefers __dtor. __xdtor only solves the specific problem of also
destroying members.
Gotcha #2:
The destructor will never be run for classes because
hasElaborateDestructor is only ever true for structs. This is
actually per the documentation, but it's also not well known "on
the ground" (e.g., a lot of code has meaningless is(T == class)
or is(T == struct) around hasElaborateDestructor). The code
example is obviously a leak if t was emplace()d in non-GC memory,
but even for GCed classes, it's important for containers to be
explicit about whether or not they own reference types.
Gotcha #3:
Even if __dtor is run on a class instance, it generally won't run
the correct destructor because it's not virtual. (I.e., if T is
a base class, no destructors for derived classes will be called.)
The spec says that D destructors are virtual, but this is
emulated using runtime type information rather than by using the
normal virtual function implementation. __xdtor is the same.
Gotcha #4:
Even if the right derived class __dtor is run, it won't run the
destructors for any base classes. The spec says that destructors
automatically recurse to base classes, but, again, this is
handled manually by walking RTTI, not by making the destructor
function itself recurse.
Gotcha #5:
The idiom of checking if something needs destruction before
destroying it is often implemented incorrectly. As before,
hasElaborateDestructor works for structs, but doesn't always work
as expected for classes. hasMember!(T, "__dtor") seems to work
for classes, but doesn't work for a struct that doesn't define a
destructor, but requires destruction for its members (a case
that's easy to miss in testing).
It looks like most D programmers think that D destructors work
like they typically do in C++, just like I did.
Here are some recommendations:
* Really try to just use destroy(). Manually working with
__dtor/__xdtor is a minefield, and I haven't seen any code that
actually reimplements the RTTI walk that the runtime library
does. (Unfortunately destroy() currently isn't zero-overhead for
plain old data structs because it's based on RTTI, but at least
it works.)
* Avoid trying to figure out if something needs destruction.
Just destroy everything, or make it clear you don't own classes
at all, or be totally sure you're working with plain old data
structs.
* Some code uses __dtor as a way to manually run cleanup code on
an object that will be used again. Putting this cleanup code
into a normal method will cause fewer headaches.
The one other usage of these low-level destructor facilities is
checking if a type is a plain old data struct. This is an
important special case for some code, but everyone seems to do
the check a different way. Maybe a special isPod trait is needed.
Re: Using D without libphobos
On Saturday, 28 April 2018 at 10:36:03 UTC, A. Nicholi wrote: Right. So there isn’t anything in core.* that would be in libphobos, only D runtime? And std.* depends on both, that is correct? Just want to be sure there aren’t edge cases or exceptions, it would be a handy rule of thumb. That's right, and I think it's intended to stay that way. (I.e., you could file a bug report if you somehow found reverse dependencies from druntime to phobos2.) Things from std.* are in the https://github.com/dlang/phobos repo, which builds libphobos2, and things from core.* are in https://github.com/dlang/druntime, which builds libdruntime.
Re: Found on proggit: Krug, a new experimental programming language, compiler written in D
On Friday, 27 April 2018 at 04:06:52 UTC, Nick Sabalausky (Abscissa) wrote: One of the items on my bucket list is to write a "CS Theory for Programmers" book that actually fills in all this stuff, along with going easy on the math-theory syntax that you can't realistically expect programmers to be fluent in. The average CS book is the equivalent of marketing a "How to speak German book" in the US...but writing it in French. Sure, *some* Americans will be able to read it, but...) The first Haskell tutorial I read was written by someone who thought it would be cute to do mathsy typesetting of all the syntax. E.g., -> became some right arrow symbol, meaning that nothing the book taught could be put into an actual Haskell compiler and executed. The book never explained the real syntax. Thankfully there are more useful tutorials out there (like this one: http://learnyouahaskell.com/).
Re: Found on proggit: Krug, a new experimental programming language, compiler written in D
On Friday, 27 April 2018 at 00:03:34 UTC, H. S. Teoh wrote: Actually, Turing-complete *does* mean it can do anything... well, anything that can be done by a machine, that is. No, it means there's some *abstract mapping* between what a thing can do and what any Turing machine can do. That sounds pedantic, but it makes a difference. For example, early C++ template metaprogamming was Turing complete, but it couldn't do much of the code generation that's possible nowadays. Sure, there's a theoretical abstract function that maps the problem you're really trying to solve to a complex C++ type, and then template metaprogramming could convert that to a "solution" type that has a theoretical mapping to the solution you want, but there weren't any concrete implementations of these abstract functions you needed to get the actual code generation you wanted. Inputs and outputs are usually the killer of "but it's Turing complete" systems.
Re: Using D without libphobos
On Thursday, 26 April 2018 at 03:04:55 UTC, A. Nicholi wrote: I am not sure if this is possible though I think you've got the technical answer already (just don't link in phobos2) but I'll add my 2c that Phobosless programming isn't just possible but realistically doable. It's a shame to go without Phobos because it's got so much higher-level functionality, but if you're okay with writing things from the ground up in C-like code, it works. Most third-party D libraries depend on Phobos, though, so it's mostly DIY and using bindings to other languages. Have a look at the standard library here: https://dlang.org/phobos/index.html Basically, all the std.* is Phobos, and most of the core.* stuff needs linking with the D runtime library. However, there's a bunch of bindings to standard C stuff in core.stdc.* that only need the C runtime and standard library, and these come in really handy when you're not using Phobos. (There are more platform-specific C bindings in core.sys.* that aren't listed on that page.) Also, there are some other things in core.bitop and core.atomic (probably more) that don't need linking to druntime.
Re: Strange behavior using array of structures
On Wednesday, 4 April 2018 at 10:00:18 UTC, Orfeo wrote:
foreach (l; log) {
l.run;
}
Try making this "foreach (ref l; log) {".
Structs are value types in D, so by default they're copied when
you assign them to another variable (in this case l). That means
run() is modifying a copy that gets thrown away each time. "ref
l" makes l into a reference to the original struct instance.
Re: Invading^W The Sydney C++ Meetup
On Tuesday, 3 April 2018 at 01:10:45 UTC, finalpatch wrote: I will be presenting the second talk there, so should be even easier to spot. The one about template metaprogramming? Nice, I'm looking forward to that one.
Re: Vtable for virtual functions in D
On Tuesday, 3 April 2018 at 00:22:52 UTC, Mike Franklin wrote: I'm curious about this comment in the code: Unfortunately, "protected" doesn't work, so a lot of members end up being public. This seems to just be an oversight in the language, so maybe it will change in future versions of D. What specifically do you think should be changed in the language to support your idea? Thanks, Mike Sorry, I'll go into the details in my blog post, but what that comment is talking about is this: D has a "protected" specifier for classes, just like C++, but not one for structs - struct members can only be private or public. This is because D structs don't natively support inheritance.
Re: Invading^W The Sydney C++ Meetup
On Monday, 2 April 2018 at 07:46:08 UTC, Nicholas Wilson wrote: We could possibly do what the europeans were considering with a quarterly meet up (btw what happened to that?). I'd be up for an occasional event like that. Maybe it's easier to start with an online event (Google Hangouts or something). We could include everyone in East Asian timezones that way. If enough people show an interest, we could make it happen.
Invading^W The Sydney C++ Meetup
This feels like a long shot, but I figure it's worth a try. I'll be at the Sydney C++ Meetup this Thursday (and other Thursdays, no promises). If anyone lurking here is in Sydney and wants to talk about D with someone, come say hi. (I'm the guy with long brown hair and should be easy to spot.) We'll have an active Australian D community one day :)
Re: Vtable for virtual functions in D
On Thursday, 8 March 2018 at 22:07:24 UTC, sarn wrote: On Thursday, 8 March 2018 at 04:37:08 UTC, Mike Franklin wrote: Nice! I was thinking about something almost exactly like this recently since 2.079.0 has features to further decouple the language from the runtime. It would be nice to read a blog post about this technique. Mike I didn't realise there was any interest. Sure, I'll try to make it one of my next few posts. I decided to pull some basic background info about vtables, etc, into its own post. I'll write about taking advantage of alias this and template metaprogramming in a later post. https://theartofmachinery.com/2018/04/02/inheritance_and_polymorphism.html
Re: "Advent of D" article on Reddit
On Friday, 9 March 2018 at 05:34:31 UTC, bauss wrote: Lmao I love Reddit. The D hate has moved onto a new level. Instead of hating on D, it's now geared towards the amount of upvotes a D post on reddit gets. What an amusement. To be fair, some things get posted to /r/programming that really should stay on /r/d_language. Spamming doesn't create a good image.
Re: Vtable for virtual functions in D
On Thursday, 8 March 2018 at 22:56:27 UTC, Henrik wrote:
why do I have to put the @nogc on the constructor and
destructor separately?
You can make things slightly better by putting @nogc in the
struct itself:
struct S
{
@nogc:
void member1()
{
}
void member2()
{
}
}
But, yeah, this is a current pain point: attributes aren't
"deep". Maybe one day we'll have a syntax for applying
attributes recursively, but I think it's blocking on the lack of
a syntax for inverting an attribute. (I.e., a way to declare an
impure/gc/whatever thing inside a region that's declared
pure/nogc/whatever.)
Re: Vtable for virtual functions in D
On Thursday, 8 March 2018 at 04:37:08 UTC, Mike Franklin wrote: Nice! I was thinking about something almost exactly like this recently since 2.079.0 has features to further decouple the language from the runtime. It would be nice to read a blog post about this technique. Mike I didn't realise there was any interest. Sure, I'll try to make it one of my next few posts. And, yeah, the new 2.079 release has made some very significant improvements. I'm still experimenting to find out what's possible now.
Re: Vtable for virtual functions in D
On Wednesday, 7 March 2018 at 12:49:40 UTC, Guillaume Piolat wrote: If you know enough D maybe you can implement your own virtual functions on top of D structs. It seems no one has made it yet. When I wrote Xanthe a year ago, I rolled my own classes using alias this and explicit vtables: https://gitlab.com/sarneaud/xanthe/blob/master/src/game/rigid_body.d#L15 (I did this because normal D classes use the druntime library, and Xanthe was an experiment in not using the D runtime at all.) Henrik: you might be interested in this post I wrote about making that: https://theartofmachinery.com/2017/02/28/bare_metal_d.html NB: things are moving fast and some things have already improved since then.
Re: Vtable for virtual functions in D
On Tuesday, 6 March 2018 at 21:20:22 UTC, Henrik wrote: Does anyone know if D is using the vtable implementation for virtual functions just like most C++ compilers? If yes, can someone explain the advantages of this strategy? A function pointer in C is regarded as expensive because of missing inlining, but a double indirection through a vtable just looks insane - if there aren't really good reasons for such an implementation. Does it make class inheritance or class polymorphism much simpler to implement or what is the reason? I have worked with C in embedded systems for many years now, and for our modern Linux systems we are using a combination of C and Java today. Java for parts where memory safety is more important than speed/determinism, and C for the critical real time parts. There should exist a language between these worlds, where we can achieve memory safety at relatively small costs. C++ is not really an alternative, and D looks much more pleasant for us C programmers than for example Rust. D uses vtables. It's a tradeoff between having double indirection and bloating each instance with the function pointers. In cases where bloating isn't a problem, I just explicitly add normal function pointer members.
Re: Implementing tail-const in D
On Tuesday, 23 January 2018 at 09:36:03 UTC, Simen Kjærås wrote: Since tail-const (more correctly called head-mutable) was mentioned here lately (in the 'I closed a very old bug!'[1] thread), I've been racking my brain to figure out what needs doing to make a viable solution. Have you seen Rebindable in Phobos? I know it's not the same thing as what you're talking about, but it's relevant. https://dlang.org/library/std/typecons/rebindable.html
Re: OT: Indexing reordering in the eBay Search Engine
On Friday, 19 January 2018 at 23:55:00 UTC, Jon Degenhardt wrote: If anyone is interested in the type of work that goes on in my group at eBay, take a look at this blog post by one of my colleagues: https://www.ebayinc.com/stories/blogs/tech/making-e-commerce-search-faster/ It describes a 25% efficiency gain via a technique called index reordering. This is the engineering side of the work, I also work on recall and ranking. --Jon Those long-tail gains are really nice, and the real win IMO.
Re: Memory Dump in D
On Sunday, 7 January 2018 at 15:40:36 UTC, H3XT3CH wrote: I need it for windows and linux but primary for windows On *nix this is traditionally called a "core dump". A quick search will get you lots of tutorials. Most distros today disable core dumps with ulimit. Run "help ulimit" and check the -c flag.
Re: Alias Vs. Enum?
On Sunday, 7 January 2018 at 18:30:17 UTC, Simen Kjærås wrote: Instead of doing that silly dance, alias should simply take values as well. Also, using "enum" for manifest constants makes sense for people familiar with C idiom, but often confuses people coming from different languages.
Re: TickDuration deprecation
On Wednesday, 22 November 2017 at 22:17:05 UTC, Walter Bright wrote: On 11/22/2017 5:45 AM, Steven Schveighoffer wrote: 1. All OS calls with timing requirements use non-floating point to represent how long to sleep. After all a CPU uses discrete math, and the timing implementation is no different. Microsoft has numerous COM APIs for time functions. One of them I had to deal with used doubles to represent seconds. This had to be interfaced with other time functions that used integers. The trouble came from round trips - there were cases where double=>integer=>double did not produce the same result. Even worse, double=>integer=>double=>integer=>double ... produced a creeping shift in the value! It took much time to come up with a method of preventing such drift, and even that was unreliable. It's fixed point, not floating point, but this famous software disaster is a pretty dramatic example: http://www-users.math.umn.edu/~arnold/disasters/patriot.html +1 to using integer arithmetic for the low-level time APIs.
Re: Looking for a job in USA
On Monday, 20 November 2017 at 09:41:16 UTC, codephantom wrote: On Monday, 20 November 2017 at 09:15:15 UTC, Adam Wilson wrote: On 11/17/17 17:31, Indigo wrote: What is your reasoning for coming to the US? You might want to rethink this as America is collapsing. This is news to me, and I live in the US. Also, if the US is collapsing, that is very bad news for D, seeing as how I live about 45 minutes from Walter, and Andrei lives in the US as well. i was going to say.. ya'll can come to Australia if the u.s collapses. Ignoring the whole American Doom thing: Australia, the UK, Canada and New Zealand are all English-speaking countries with decent job prospects and good enough crime/corruption levels by world standards. Sydney's expensive, but there are very good tech opportunities if you can network. Melbourne is cheaper and I hear it has good tech jobs, too. Canberra also has tech work, but a lot of it requires security clearance and is hard for new migrants to get into.
Re: ESR on post-C landscape
On Tuesday, 14 November 2017 at 09:43:07 UTC, Ola Fosheim Grøstad wrote: ESR got famous for his cathedral vs bazaar piece, which IMO was basically just a not very insightful allegory over waterfall vs evolutionary development models, but since many software developers don't know the basics of software development he managed to become infamous for it… Everything ESR says is worth taking with a good dose of salt, but his "The Art of Unix Programming" isn't a bad read.
Re: ESR on post-C landscape
On Thursday, 16 November 2017 at 11:52:45 UTC, Ola Fosheim Grostad wrote: On Thursday, 16 November 2017 at 11:24:09 UTC, codephantom I would never say OO itself is a failure. But the idea that is should be the 'primary focus of program design' .. I think that is a failure...and I think that principle is generally accepted these days. Uhm, no? What do you mean by 'primary focus of program design' and in which context? In the 90s (and a bit into the 00s) there was a pretty extreme "everything must be an object; OO is the solution to everything" movement in the industry. Like most tech fads, it was associated with a lot of marketing and snake oil from people promising anything managers would pay money to hear (e.g., "use OO and your projects will be made up of reusable objects that you can simply drop into your next project!"). Look around most programming languages today and you'll see objects, so in that sense OOP never failed. What failed was the hype train. It's no different from most other tech fads (except XML has declined drastically since the hype passed).
Re: Proposal: Support for objects in switch statements
On Monday, 6 November 2017 at 10:10:29 UTC, Atila Neves wrote: Checking for types at runtime is a code smell in OOP. Sometimes necessary, especially if doing multiple dispatch, but never done gladly. There's already a way to dispatch on type: virtual functions. Atila More on that: https://www.tomdalling.com/blog/software-design/solid-class-design-the-liskov-substitution-principle/ It often happens when people try to model sum types using polymorphism.
Re: London senior DevOps job and two London [D-ish] developer roles
On Monday, 23 October 2017 at 05:26:17 UTC, Adil wrote: That email server is blocked. Other way round: SORBS is blocking your GMail server. They do stupid stuff like that sometimes :/ It might work if you try again later.
Re: Proposal: Object/?? Destruction
On Sunday, 15 October 2017 at 15:19:21 UTC, Q. Schroll wrote:
On Saturday, 14 October 2017 at 23:20:26 UTC, sarn wrote:
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll wrote:
Therefore, and because of brackets, you can distinguish f(1,
2) from f([1, 2]).
But in f([1, 2]), it's ambiguous (just by parsing) whether [1,
2] is a tuple literal or a dynamic array literal.
It would be a tuple if that's the best match, otherwise
conversion to int[] is tried.
...
You'd need to use a prefix or something to the bracket syntax.
[snip]
I just argued, you don't!
But have you thought through all the implications?
Take this code:
void main(string[] args)
{
import std.stdio : writeln;
writeln([1, 3.14]);
}
As you're probably 100% aware, this is totally valid D code
today. [1, 3.14] becomes a double[] because 1 gets converted to
a double. If this kind of behaviour changes, code will break, so
you'll need a bunch of exceptions to the "it would be a tuple if
that's the best match" rule. Also, for the same backwards
compatibility reasons, it would be impractical in most cases to
add any tuple overloads to most existing standard library
functions that currently accept slices or arrays, but presumably
new functions would be meant to take advantage of the new syntax
(else there wouldn't be much point creating a new syntax).
So, a literal like [1, 3.14] would basically be a tuple, but
would be converted to double[] in a bunch of special cases for
historical reasons.
If you're not sure if this is really a problem, take a look at
the confusion caused by the magic in {} syntax:
https://forum.dlang.org/thread/ecwfiderxbfqzjcyy...@forum.dlang.org
https://forum.dlang.org/thread/ihsmxiplprxwlqkgw...@forum.dlang.org
https://forum.dlang.org/thread/qsayoktyffczskrnm...@forum.dlang.org
To be totally honest, I still don't see what's wrong with just
creating a new bracket syntax, instead of adding more magic to []
(or () for that matter).
Re: Proposal: Object/?? Destruction
On Saturday, 14 October 2017 at 22:20:46 UTC, Q. Schroll wrote: Therefore, and because of brackets, you can distinguish f(1, 2) from f([1, 2]). But in f([1, 2]), it's ambiguous (just by parsing) whether [1, 2] is a tuple literal or a dynamic array literal. You'd need to use a prefix or something to the bracket syntax. E.g., $[1,2]. The dollar sign is just an example, but it might work because currently $ only seems to be used in slice syntax and in inline assembly. I don't think tuple literals are needed in inline assembly, and I think the slice syntax might be okay because (unlike C) D doesn't allow the borked 0[arr] style of indexing, so expressions like arr[0..$[x][y]] are unambiguous. (I.e., $[x][y] is the yth element of a tuple containing x, and not the yth element of the $th element of x as an array).
Re: Multiline string literal improvements
On Tuesday, 10 October 2017 at 21:38:41 UTC, captaindet wrote:
string a = |q{
firstLine();
if (cond) {
secondLine()
}
};
you could write your own string processing function according
to your needs
FWIW, that's the solution in Python:
https://docs.python.org/release/3.6.3/library/textwrap.html#textwrap.dedent
Works even better in D because it can run at compile time.
Re: Proposal: Object/?? Destruction
On Thursday, 5 October 2017 at 15:23:26 UTC, Seb wrote: I think I can state the opinion of many D users here: I don't mind whether it will be curly braces or round parentheses - the important thing is that we will be able to use it in the foreseeable future :) All my +1s. Let's leave syntax details to people who know the D grammar inside out.
Re: D's SwitchStatement accepts statements with ridiculous semantics
On Friday, 29 September 2017 at 09:56:17 UTC, Dukc wrote:
On Friday, 29 September 2017 at 09:12:54 UTC, Don Clugston
wrote:
Guess what this prints
My guess is it prints "1".
By "guess" I mean it, I did not test! Anyway reminds me a lot
of very badly used gotos.
Yeah, it's a lot like Duff's Device:
https://en.wikipedia.org/wiki/Duff's_device
For anyone who's wondering, it works because switch is just a
computed goto. The code's equivalent to this:
import std.stdio;
void main()
{
int i = 0;
// switch(i)
if (i == 7)
{
goto case_7;
}
else
{
goto case_default;
}
// for loop initialiser
i = 8;
// for loop test
while (i < 10)
{
case_7:
writeln(i);
return;
case_default:
// for loop update
++i;
}
}
Re: Hong Kong dlang Meetup
On Monday, 4 September 2017 at 19:25:59 UTC, Jonathan M Davis wrote: We haven't decided when exactly to meet up yet Any updates?
Re: Hong Kong dlang Meetup
On Monday, 4 September 2017 at 19:25:59 UTC, Jonathan M Davis wrote: Several of us from the D community will be in Hong Kong on a business trip next week (me, John Colvin, Atila Neves, and Ilya Yaroshenko), and our client, Symmetry Investments[1], has offered to sponsor a dlang meetup. We haven't decided when exactly to meet up yet, but we're looking to meet up sometime during the week of the 11th - 15th (probably on Thursday or Friday evening) and figured that we should see if anyone here was interested in showing up and would thus have some stake in when during the week it happened. The current plan is that the meetup will take place at Symmetry's main office in Chater House in Central Hong Kong. Sounds interesting. The 14th and 15th aren't good for me, otherwise the rest of the week is okay. Are you staying near the office?
Re: D as a Better C
On Wednesday, 23 August 2017 at 17:44:31 UTC, Jonathan M Davis wrote: I confess that I tend to think of betterC as a waste of time. The overwhelming majority of programmers don't need betterC. At all. But today we live in a world where practically everything just builds on top of C, and we keep seeing how that goes wrong. I think Rust and betterC D are the best candidates we've got for replacing C everywhere C is used.
Re: D as a Better C
On Wednesday, 23 August 2017 at 16:17:57 UTC, SrMordred wrote: No structs in -betterC ??? I haven't tried the latest iteration of betterC yet, but the longstanding problem is that the compiler generates TypeInfo instances for structs, and TypeInfos are classes, which inherit from Object, which are implemented in the D runtime. If you're using the current release of D, the workarounds are to include an implementation of Object so that classes work, or hack out the TypeInfo at link time.
Re: Need some vibe.d hosting advice
On Friday, 11 August 2017 at 13:06:54 UTC, aberba wrote: How would you do it if you were using vibe.d? Depends on who wants it built. I do consulting, so let me answer that way. "I don't want to think about ops and scalability and availability at all!" Then you'll have to pay a premium for someone else (like Heroku) to do that for you. It may or may not be worth it for you, but you can't have it both ways. "Okay, I've thought about it bit. I can use a shell, 100k non-asset requests per day sounds like a lot, and I guess a few minutes of downtime isn't so bad if it's occasional and I can schedule it to outside hours." Sounds like you can just host it on a VPS with all the important data on managed (backed-up) storage (like RDS or S3 in AWS) and possibly with a CDN in front. "I don't think either of those options fit my needs." Okay, let's talk about what your needs are. About S3, there's not a lot you'd need to do with S3, right? I'd just write the library or wrap the command line client.
Re: std.math module
On Sunday, 6 August 2017 at 23:33:26 UTC, greatsam4sure wrote: import std.math; import std.stdio; cos(90*PI/180) = -2.7e-20 instead of zero. I will appreciate any help. thanks in advance. tan(90*PI/180) = -3.689e+19 instead of infinity. What is the best way to use this module That's just floating point maths for you. You're not putting exactly pi/2 into cos, just a good floating point approximation. What you're getting out isn't exactly 0, either, just a good floating point approximation. (-2.7e-20 is really, really small.) Here's a good talk from DConf 2016: https://www.youtube.com/watch?v=97bxjeP3LzY If you need exact maths, you'll need a symbolic manipulation library (never used one in D, but there was a discussion recently https://forum.dlang.org/thread/ghihookwgzxculshi...@forum.dlang.org). You don't need this for most practical applications, though.
Re: DIP 1012--Attributes--Preliminary Review Round 1
On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md Like others in this thread have said, it needs more rationale. The rationale only mentions one actual problem: attributes can't be undone (which is a really important problem, by the way). But in the abstract it says [This DIP] does not (yet) propose any mechanism to disable compiler attributes directly (e.g. @!nogc). Instead of coming up with more problems to solve, it then dives into describing an entire framework for doing *things* with attributes. To be totally honest, as it stands it feels like architecture astronautics: https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/
Re: proposed @noreturn attribute
On Sunday, 9 July 2017 at 00:16:50 UTC, Walter Bright wrote: We have types that cannot be named (Voldemort types), types that have no type (void), I suppose that types that cannot exist will fill out the edge cases of the menagerie. I assume there is a standard jargon for this - does anyone know Type Theory? Are there any other interesting uses for a type that cannot exist? In pure functional languages, that's what "bottom" or Haskell's Void is. In Curry–Howard "programs are proofs" theory, a type is a proposition and an instance is a proof. A type with no instance is a proposition that can't be proved. https://codewords.recurse.com/issues/one/type-systems-and-logic I'm not sure how much impact this has on everyday D programming, but hey, it's a thing.
Re: Allocation trace
On Saturday, 24 June 2017 at 22:15:47 UTC, Andrei Alexandrescu wrote: Hello, does anyone have traces of allocations from real applications? Looking for the sequence of calls to malloc, realloc, and free, e.g.: 0 malloc 128 1 malloc 8192 2 malloc 32 3 free 1 ... Thanks, Andrei On *nix systems, you can use ltrace to generate this pretty easily.
Re: BetterC and TypeInfo Question
Currently a lot of language features generate dependencies on TypeInfo, arguably more than needed, but this is changing. Some examples are in this DConf 2017 talk: https://www.youtube.com/watch?v=endKC3fDxqs Also, the way the language is designed right now, all modules are responsible for containing TypeInfo instances for all their types, in case other modules *might* need them. So, if you define a plain old data struct, for example, you get TypeInfo and its runtime dependencies. This isn't a requirement, and Adam has just patched DMD to make -betterC leave out the TypeInfo. But, even in C++, RTTI is necessary for dynamic casting... so how is D going to address that? I think it is necessary, but can prolly be quite minimal. I will think about it more later. Does it matter? C++ programmers already accept that RTTI is needed for certain dynamic features.
Re: dmd -betterC
On Tuesday, 20 June 2017 at 17:30:43 UTC, Kagamin wrote: You can write a linker wrapper that will do the analysis you want, remove unneeded sections, stub symbols etc, see basic technique at https://theartofmachinery.com/2016/12/18/d_without_runtime.html I keep meaning to write an update to that post because there have been a lot of improvements to the ecosystem since then. (I've been kind of busy the past few months.)
Re: Immovable types
On Wednesday, 19 April 2017 at 02:53:18 UTC, Stanislav Blinov wrote: I'd very much like to hear your thoughts on this, good/bad, if it already was proposed, anything. If it's found feasible, I could start a DIP. Destroy, please. I don't have comments about the syntax, but I did want this feature when writing Xanthe (https://gitlab.com/sarneaud/xanthe). In normal D you can make a struct instance effectively immovable by dynamically allocating it, but I had to allocate stuff statically or on the stack.
Re: Of the use of unpredictableSeed
On Tuesday, 21 March 2017 at 10:27:27 UTC, Andrei Alexandrescu wrote: Thanks Yuxuan, sorry for missing this. Can we have this peer reviewed by 1-2 crypto experts? Thanks! -- Andrei By API, unpredictableSeed() only returns a 32b uint and will never meet crypto standards. Beware of anyone who offers to review it based on their "crypto expertise". unpredictableSeed() is just for things like making single-player games more interesting. It simply isn't for security, and that's pretty much what cym13's post was about.
Re: TLS
On Friday, 10 March 2017 at 19:24:29 UTC, bauss wrote: Mark your variables with __gshared. I would say shred, but it has some restrictions to it, where __gshared is the equivalent to global variables in C. immutable variables are also not put in TLS.
Re: Spotted on twitter: Rust user enthusiastically blogs about moving to D
PSA: please don't feed the trolls.
Re: Of the use of unpredictableSeed
On Monday, 6 March 2017 at 10:12:09 UTC, Shachar Shemesh wrote: Excuse me if I'm asking a trivial question. Why not just seed it from /dev/urandom? (or equivalent on non-Linux platforms. I know at least Windows has an equivalent). Shachar One reason is that /dev/urandom isn't always available, e.g., in a chroot. Sure, these are corner cases, but it's annoying when stuff like this doesn't "just work".
Re: Writing pattern matching macros in D.
On Monday, 6 March 2017 at 02:20:02 UTC, Deech wrote: Hi all, I've been reading up on D's metaprogramming features and was wondering if it was possible to use them to add pattern matching to the language as a macro. The template mixin feature seems to require putting the new syntax in strings. I was hoping there's an alternative. Thanks! -deech It isn't possible in the same way it is in, say, Rust. This has come up before and Walter has strong opinions against that kind of rewriting macro. This is what's currently implemented: https://dlang.org/phobos/std_variant.html#visit
Re: How to get dub to work when I have dlang installed in custom directory?
On Friday, 3 March 2017 at 20:35:04 UTC, Jamal wrote: I have no idea what is is wrong and or how to fix it. Any help? It would be the alias. When you're running dmd from your shell, you're using an alias that includes a bunch of flags to make dmd work. When dub runs, it'll run the dmd executable directly, not your alias, and lose the flags. You can get rid of the alias and use a dmd.conf instead. Just make a file called "dmd.conf" in the same directory as your dmd executable, and put something like this in it: [Environment32] DFLAGS=this> [Environment64] DFLAGS="dlang_compile">
Re: [NOTABLE PR] First step from traditional to generic runtime
On Thursday, 2 March 2017 at 19:32:23 UTC, Andrei Alexandrescu wrote: Worth a look: https://github.com/dlang/druntime/pull/1781. This moves comparison code away from tedious runtime-introspected routines to nice templates. -- Andrei Great news :)
