Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Thursday, 8 November 2018 at 23:50:18 UTC, TheFireFighter
wrote:
i.e. better encapsulation really is a good thing (although for
many, it a lesson that needs to be learned).
Public/private/protected are hacks anyway - and many
object-oriented languages don't have it. They only provide
extremely limited encapsulation ; the client still sees the
non-public part, and can depend on it in unexpected ways:
// my_module.d
struct MyStruct
{
private:
char[1024] data;
}
class MyClass
{
protected:
abstract void f();
};
// main.d
import my_module;
import std.traits;
import std.stdio;
int main()
{
// depends on the list of private
writefln("MyStruct.sizeof: %s", MyStruct.sizeof); members
// depends on wether 'f' is declared abstract or not.
writefln("isAbstractClass!MyClass: %s",
isAbstractClass!MyClass);
return 0;
}
If you want perfect encapsulation, use interfaces (as already
said in this thread), or PIMPL.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Wednesday, 31 October 2018 at 05:00:12 UTC, myCodeDontSmell
wrote:
in D, once your write your abstraction, say a class, with it's
public interface, all the code below it can do whatever it
likes to that class, making it a leaky abstraction.
I think there might be some confusion between "leaky abstraction"
and "insufficient encapsulation".
Here's the Wikipedia definition of leaky abstractions:
"In software development, a leaky abstraction is an abstraction
that *requires* knowledge of an underlying complexity* to be able
to know how to use it. This is an issue, as the whole point of an
abstraction is to be able to abstract away these details from the
user. "
Why would imply that: as long as the user of your class isn't
*required* to know about the underlying implementation specifics,
this isn't a "leaky abstraction".
My understanding is that:
"Leaky abstractions" are about the interface design, and how one
component is meant to be used. Those are unrelated to the
programming language (e.g translating the code to another
language doesn't make the leaky abstraction disappear).
For example, a shared directory can be a leaky abstraction, if
the network is unstable (because then, the client code, which
only sees file descriptors, now has to deal with disappearing
files).
"Encapsulation" is about implementation hiding and access control
("public/private"), and requires programming language support
(e.g most dynamic languages don't have it).
Re: D Language accepted for inclusion in GCC
On Thursday, 22 June 2017 at 16:13:51 UTC, Gary Willoughby wrote: D Language accepted for inclusion in GCC: https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html Well done Iain Buclaw! Reddit thread: https://www.reddit.com/r/programming/comments/6im1yo/david_edelsohn_d_language_accepted_for_inclusion/ http://forum.dlang.org/thread/rakdufnuyofyhsweg...@forum.dlang.org
Re: Testing in the D Standard Library
On Monday, 23 January 2017 at 01:52:29 UTC, Chris Wright wrote: On Sun, 22 Jan 2017 20:18:11 +, Mark wrote: Have you considered adding randomized tests to Phobos? Randomized testing is an interesting strategy to use alongside deterministic testing. It produces more coverage over time. However, any given test run only has a fraction of the coverage that you see over a large number of runs. In other words, if the randomized tests catch something, you don't know who dun it. This is generally considered a bad thing. Phobos does have some tests that use a PRNG. They all use a fixed seed. This is a shortcut to coming up with arbitrary test data; it's not a way to increase overall coverage. I think the right way to do it is to have a nightly randomized test build, but since I'm not willing to do the work, I don't have much say. This. So much this. Unit tests that loop over many randomly generated input test vectors are just a waste of everybody's CPU time. Don't get me wrong: fuzzing is also necessary. But it relies on an arbitrary time limit, which is hardly compatible with keeping a test suite fast. Which means it should be done in a another validation process than unit tests.
Re: Comparing compilation time of random code in C++, D, Go, Pascal and Rust
On Thursday, 27 October 2016 at 12:11:09 UTC, Johan Engelen wrote:
On Thursday, 27 October 2016 at 06:43:15 UTC, Sebastien Alaiwan
If code generation/optimization is the bottleneck, a
"ccache-for-D" ("dcache"?) tool might be very beneficial.
See
https://johanengelen.github.io/ldc/2016/09/17/LDC-object-file-caching.html
I also have a working dcache implementation in LDC but it still
needs some polishing.
Hashing the LLVM bitcode ... how come I didn't think about this
before!
Unless someone manages to do the same thing with gdc + GIMPLE,
this could very well be the "killer" feature of LDC ...
Having a the fastest compiler on earth still doesn't provide
scalability ; interestingly, when I build a full LLVM+LDC
toolchain, the longest step is the compilation of the dmd
frontend. It's the only part that is:
1) not cached: all the other source files from LLVM are ccache'd.
2) sequential: my CPU load drops to 12.5%, although it's near
100% for LLVM.
Re: Comparing compilation time of random code in C++, D, Go, Pascal and Rust
On Wednesday, 19 October 2016 at 17:05:18 UTC, Gary Willoughby
wrote:
This was posted on twitter a while ago:
Comparing compilation time of random code in C++, D, Go, Pascal
and Rust
http://imgur.com/a/jQUav
Very interesting, thanks for sharing!
From the article:
Surprise: C++ without optimizations is the fastest! A few other
surprises: Rust also seems quite competitive here. D starts out
comparatively slow."
These benchmarks seem to support the idea that it's not the
parsing which is slow, but the code generation phase. If code
generation/optimization is the bottleneck, a "ccache-for-D"
("dcache"?) tool might be very beneficial.
(However, then why do C++ standard committee members believe that
the replacement of text-based #includes with C++ modules
("import") will speed up the compilation by one order of
magnitude?)
Working simultaneously on equally sized C++ projects and D
projects, I believe that a "dcache" (using hashes of the AST?)
might be usefull. The average project build time in my company is
lower for C++ projects than for D projects (we're using "ccache
g++ -O3" and "gdc -O3").
Re: Running a D game in the browser
On Friday, 5 August 2016 at 13:18:38 UTC, Johan Engelen wrote: That patch doesn't look too bad. Could you introduce a CMake option for building with Emscripten-fastcomp? And a #define "LDC_LLVM_EMSCRIPTEN" or something like that, so that you can change `#if LDC_LLVM_VER >= 309 && 0` to `#if LDC_LLVM_VER >= 309 && !LDC_LLVM_EMSCRIPTEN`. Should be mergable into LDC master then! I could definitely formalize things a bit, but any patch of this kind would quickly be obsolete, as Emscripten catches up with LLVM versions. Moreover, I don't feel comfortable polluting LDC with the specificities of some obscure use case (as cool as this use case can be!). It might be preferable - though harder - to patch Emscripten so it aligns on LLVM official API versions.
Re: Running a D game in the browser
On Thursday, 4 August 2016 at 19:17:34 UTC, Sebastien Alaiwan wrote: at the moment, I have a patch to making the build work (only for the binary "ldc2", not other tools of the package). I created a dedicated github branch "fastcomp-ldc". The patch: https://github.com/Ace17/dscripten/blob/fastcomp-ldc/ldc2.patch
Re: Running a D game in the browser
On Wednesday, 3 August 2016 at 20:40:47 UTC, Kai Nacke wrote: That's awesome! Do you still know the modifications you made to compile LDC with emscripten-fastcomp? I would be interested to have a look into the "PNaCl legalization passes" problem. That would be great, and might simplify the toolchain a lot. First we must get the build to pass again ; I'm working on it at the moment, I have a patch to making the build work (only for the binary "ldc2", not other tools of the package). I can send it to you if you want.
Re: Running a D game in the browser
On Thursday, 4 August 2016 at 09:57:57 UTC, Mike Parker wrote: On Wednesday, 3 August 2016 at 20:26:23 UTC, Sebastien Alaiwan wrote: And a blogpost explaining the technique is available here: http://code.alaiwan.org/wp/?p=103 (Spoiler: at some point, it involves lowering the source code back to C) Reddit: https://www.reddit.com/r/programming/comments/4w3svq/running_a_d_game_in_the_browser/ HN: https://news.ycombinator.com/item?id=12225036
Re: Running a D game in the browser
On Thursday, 4 August 2016 at 05:03:17 UTC, Joel wrote: [snip] Though, it looks like the score isn't reset when you start a new game. Or, is it intended that way? Oh, I read it wrong, the score is reset. Dummy, me! It's just that you're becoming better at this silly game :-) Thanks for your replies! As Mark guessed, I didn't spend a lot of time on the game-design side (but I'm still interested in game-design related comments). It's more of a proof of concept, using D. Using C++, there already are impressive demos: https://kripken.github.io/BananaBread/wasm-demo/index.html
Running a D game in the browser
Hi, I finally managed to compile some D code to asm.js, using Emscripten. It had been done by one dude several years ago, but some changes in the inner workings of Emscripten (the introduction of fastcomp, also probably combined with changes in the way LDC generates LLVM bitcode) made it impossible to use the same technique. You can play a minimalistic demo: http://code.alaiwan.org/dscripten/full.html The source code + toolchain deployment scripts are available on github: https://github.com/Ace17/dscripten And a blogpost explaining the technique is available here: http://code.alaiwan.org/wp/?p=103 (Spoiler: at some point, it involves lowering the source code back to C) Please let me know what you think!
