Re: concepts v0.0.1
On 2016-12-16 21:51, Atila Neves wrote: Since my phobos PR for better static assertions was clearly never getting merged (https://github.com/dlang/phobos/pull/3677), I moved the code to dub instead: http://code.dlang.org/packages/concepts Basically, as long as you pair up your template constraints (e.g. isFoo) with a suitably named function that should compile (e.g. checkFoo, not a lambda), then you can write this: @models!(Foo, isFoo) struct Foo { //... } And in the case that isFoo is false, you'll get to know _why_ it didn't compile instead of an AssertError that leaves you confused. At least it used to and the unit tests pass so I'm assuming it still does :P It's not very well tested ;). When a check fails I get this error: Error: can only import from a module, not from package std.algorithm.searching.countUntil After fixing that to a proper selective import I get: Error: template instance moduleName!P template 'moduleName' is not defined Adding an import for std.traits will fix that. Then after fixing all that it seems to work properly :) Asserting that something does not compile is very risky because it does not tell you why it didn't compile. One should always first compile without __traits(compiles) to verify that the correct error is reported. -- /Jacob Carlborg
Re: unDE 0.1.0: original file manager, image and text viewer
On Thursday, 15 December 2016 at 20:16:10 UTC, unDEFER wrote: Hello, my dear friends! So many days you answers on many my questions. And today I glad to present my work: unDE 0.1.0. It is very original file manager, image and text viewer. More information: http://unde.sourceforge.net/en/ch24.html Video with English subtitles: https://youtu.be/29zuxU9eyXo Interesting, but requiring Cygwin on Windows is a no go. You're reducing your potential Windows userbase by 99%.
Re: unDE 0.1.0: original file manager, image and text viewer
On Saturday, 17 December 2016 at 16:12:10 UTC, thedeemon wrote: Interesting, but requiring Cygwin on Windows is a no go. You're reducing your potential Windows userbase by 99%. Really cygwin needed only for rsync and in the future for good commands base in bash. Maybe when I will write own version of rsync, I will make version without cygwin dependency.
Linker-hacking out the D runtime
As it stands, the -betterC flag is still immature and only removes a bit of the D runtime. I've been playing around a bit to see what could be possible. To do that, I've had to do some linker hacking to make code that's completely free of D runtime dependencies. I thought I'd write something up to help other people experiment with this stuff: https://theartofmachinery.com/2016/12/18/d_without_runtime.html Let's make a better -betterC :)
Re: Linker-hacking out the D runtime
On 18 December 2016 at 01:04, sarn via Digitalmars-d-announce wrote: > As it stands, the -betterC flag is still immature and only removes a bit of > the D runtime. -betterC removes module info and module helpers, not the D runtime. You will find it in gdc with the more appropriately named command line switch -fno-moduleinfo. ;-)
Re: Linker-hacking out the D runtime
On Sunday, 18 December 2016 at 00:04:54 UTC, sarn wrote: I thought I'd write something up to help other people experiment with this stuff: https://theartofmachinery.com/2016/12/18/d_without_runtime.html Thanks for this. I abandoned D sometime ago largely because of https://issues.dlang.org/show_bug.cgi?id=14758 (but there were other reasons), so your blog post is interesting to me. It is unfortunate that we have to resort to such hackery, but its nice to have such tools at our disposal regardless. I proposed another idea for giving users more control over D Runtime by moving runtime hook definitions to .di header files. If you're interested, you can read about it here: http://forum.dlang.org/post/psssnzurlzeqeneag...@forum.dlang.org. I'd much rather have something like that over a -betterC; you can read more about some disadvantages to expanding on -betterC (e.g. removing RTTI) here: http://forum.dlang.org/post/nevipjrkdqxivoerf...@forum.dlang.org. I've largely embraced Rust now for its "no runtime" and "no dependencies libcore" features (and a few other safety/robustness features), but I miss the modeling power and compile-time features of D greatly. Anyway, thanks for the post; it's given me a few ideas. Mike
Re: DirectX bindings
On Sunday, 3 November 2013 at 05:27:24 UTC, evilrat wrote: https://github.com/evilrat666/directx-d A long awaited update - v0.10.0 is out! Be wary there is still a lot of things untested, and one may encounter access violation or random crashes. It is great to see community expanding and the language growing up. Thanks everyone who contributed.