log for complex
Simple question: how do I get the log of a complex number? If I try the simple logtest = log(complex(1.0, 2.0)) I get the compiler error Error: function core.stdc.math.log(double x) is not callable using argument types (Complex!double) Some basic functions are described in https://dlang.org/phobos/std_complex.html, but not the log...
Re: Fetch and pre-build dub dependencies
On Wednesday, 7 March 2018 at 04:28:11 UTC, Seb wrote: For run.dlang.io, I fetch all dependencies and build them into the Docker image. That has the advantage that executions with dub packages are a lot faster. It's just dub fetch and dub build though. Take a look: https://github.com/dlang-tour/core-exec/blob/master/Dockerfile Thank you for showing your solution! Using dub --single is neat and works well for this!
Why not flag away the mistakes of the past?
So i've seen on the forum over the years arguments about auto-decoding (mostly) and some other things. Things that have been considered mistakes, and cannot be corrected because of the breaking changes it would create. And I always wonder why not make a solution to the tune of a flag that makes things work as they used too, and make the new behavior default. dmd --UseAutoDecoding That way the breaking change was easily fixable, and the mistakes of the past not forever. Is it just the cost of maintenance?
[Issue 14242] destruction of static arrays with elaborate destructor elements does not propagate attributes
https://issues.dlang.org/show_bug.cgi?id=14242 Mike Franklinchanged: What|Removed |Added Status|NEW |RESOLVED CC||slavo5...@yahoo.com Resolution|--- |WORKSFORME --- Comment #1 from Mike Franklin --- This appears to have been fixed in 2.068.2. I cannot reproduce it in the latest compiler (2.079.0) either. Resolving as WORKSFORME. --
[Issue 17961] std.uni does not compile with -unittest -dip1000
https://issues.dlang.org/show_bug.cgi?id=17961 --- Comment #11 from Carsten Blüggel--- (In reply to hsteoh from comment #10) > Link: https://github.com/dlang/phobos/pull/6041 Due to lack of acceptance I closed PR https://github.com/dlang/phobos/pull/6041. Maybe https://github.com/dlang/phobos/pull/6212 will come to the rescue. --
Re: Fetch and pre-build dub dependencies
On Tuesday, 6 March 2018 at 18:03:34 UTC, Tamas wrote: I have a Dockerfile to build a vibe.d project. Docker has a nice caching system so it continues building the docker image from the step where it's needed when something changes. This is typically at the step of adding my source files, then building the binary. The problem is that fetching and building vibe dependencies takes a lot of time every time some source files of mine changes. I can pre-fetch dub dependencies, although it's a bit cumbersome as fetch doesn't load dependencies of the given package. RUN dub fetch vibe-d --cache=system RUN dub fetch vibe-core --cache=system RUN dub fetch eventcore --cache=system But there's no easy way to build these dependencies before I add my project source files to the docker image. If I could do that the docker build process would be tremendously faster, as it would be simply skipped automatically by the Docker cache system. Currently 99% of the time spent on building the dependencies when i am creating a docker image. (I have to use ldc for ARM, which is slower.) Is there an easy way to fetch and prebuild a dub package dependencies? something like "dub fetch-and-build vibe-d --recursive --cache=system" For run.dlang.io, I fetch all dependencies and build them into the Docker image. That has the advantage that executions with dub packages are a lot faster. It's just dub fetch and dub build though. Take a look: https://github.com/dlang-tour/core-exec/blob/master/Dockerfile dub fetch also fetches the dependencies of the package. The docker images don't have internet access on run.dlang.io, so it works fine for me. Maybe all you need is to disable the registry lookup?
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 19:57:13 UTC, Steven Schveighoffer wrote: On 3/6/18 2:30 PM, Martin Nowak wrote: On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: But if needed, you could have your dub package depend on a prior version. http://code.dlang.org/packages/stdx-allocator ;) This is the answer, vibe.d should depend on stdx-allocator. -Steve Vibe.d (and a lot of other projects) do depend on this package, see e.g. https://github.com/vibe-d/vibe.d/pull/1983 Also many packages already depend on vibe.d-0.8.3, but it's in rc1 atm and not released as the latest stable tag yet, which is the reason for Atila's justified complaint.
Re: Release D 2.079.0
On 07/03/2018 2:54 PM, psychoticRabbit wrote: On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote: Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us? That's the day I stop using D. I do not, and will not, use dub. Full stop. Same goes for Rust ;-) Under such arrangement nobody is forcing you to use dub. We wouldn't break distribution or usage of dmd just because of changing a make file to dub. That's just silly.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote: Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us? That's the day I stop using D. I do not, and will not, use dub. Full stop. Same goes for Rust ;-)
Re: Advent of D
On Tuesday, 6 March 2018 at 21:09:06 UTC, Jordi Gutiérrez Hermoso wrote: Posting to Reddit is easier, but I don't have a recognisable account on Reddit to post it from. I'll post it. There are good times and bad times to post on /r/programming in terms of getting attention. A good time would be in about ~12 hours or so.
Re: can't build libuid examples
On Tuesday, 6 March 2018 at 19:19:05 UTC, greatsam4sure wrote: Try to build libuid examples get the following error. dub build, build successfully on the root folder. I will appreciate any help. Just try to build a gui app using dlang. OPTLINK (R) for Win32 Release 8.00.17 Those "Undefined Symbol" errors all mean you aren't linking with the libui library. Looking at the dub.json for libuid, it obviously *is* configured to link with libui to build the examples: https://github.com/mogud/libuid/blob/c36e994df238f03516abbb4a75ed054e44b602b5/dub.json#L21 However, if you read the project README, you'll see this: libuid is a binding of libui. So you have to build libui first. Did you do so? libuid provides the proper version of the libui source via a git submodule. If you did build it, you probably used Visual Studio. In which case, you also see this in the README: You can use --arch to specify architecture of you platform. Note in windows, use --arch=x86_mscoff to create 32bit binary. By default, DMD uses the OPTLINK linker, which expects object files in the OMF format and is incompatible with binaries produced by Visual Studio (which uses the COFF format). Passing --arch=x86_mscoff on your dub command line will cause DMD to use the MS linker instead of OPTLINK.
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: DIP 1006 - Preliminary Review Round 1
On 06.03.2018 19:49, Paolo Invernizzi wrote: I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. ... I have explained why. UB is non-modular and you don't (want to) control all the code that you use. Also, enforce cannot be disabled. And no, keeping the check or introducing UB are not the only sensible options.
Re: Release D 2.079.0
On Tue, Mar 06, 2018 at 08:50:37PM +, Jack Stouffer via Digitalmars-d-announce wrote: [...] > Also, if you'll allow me to have crazy ideas for a moment, one wonders > why we shouldn't just release Phobos itself through dub? Rust makes > people use their build tool, why not us? Please don't. I dread the day my daily dmd toolchain update script will have to depend on dub just to be able to build a working compiler. But personal preferences aside, one blocker to this is that dmd and phobos (as well as druntime) development often go in lockstep, and sometimes breaking transitions must be coordinated between them so that git master is always buildable. If dmd and phobos were separate repos, it would make this coordination much, much, more difficult. (Though, on second thoughts, that's not necessarily a bad thing, as it will force us to actually face these issues and make Phobos buildable with multiple compiler versions, which currently is not well supported, if it works at all, because of said interdependence. This would also force us to dogfood our release / deprecation processeses, which will allow us to notice problems early and to experience what end users would experience when transitioning between compiler versions. It *will* add more workload to an already thin Phobos dev team, though. So there's that.) T -- Why are you blatanly misspelling "blatant"? -- Branden Robinson
Re: DIP 1006 - Preliminary Review Round 1
On 06.03.2018 11:17, Walter Bright wrote: On 3/6/2018 1:58 AM, Jonathan M Davis wrote: [...] The entire point of making assert a core language feature was so that the compiler could take advantage of it to generate better code. It does not need to be a core language feature for that. It seems that you did the right thing for the wrong reasons. It's been like that for D since day 1. It has always been documented to do that. It has been discussed many times in this n.g. over the years with lng threads. I designed it that way so that D could potentially produce better code than other languages in ways they could not match. There is no other purpose to making it a core language feature. ... Yes. The (only!) purpose is standardization. asserts and contracts are a core language feature for similar reasons why unit tests are a core language feature. ... Or just don't turn off assert checking. Personally, I use asserts in a way that they add little overhead so they can remain active in the release build. ... Not everybody runs only their own code. It's entirely under your control. It is not. Could we please make it that way?
Re: DIP 1006 - Preliminary Review Round 1
On 06.03.2018 10:02, Walter Bright wrote: On 3/6/2018 12:45 AM, Timon Gehr wrote: Anyway, "do not use assert" is not the solution, as I have explained many times now. My interpretation is you want D assert to behave like C assert. This interpretation is wrong. I, as well as other people, want a compiler option to make the compiler ignore D asserts and contracts. Not more, not less. C assert and enforce are purely creatures of the library, with semantics defined by their library implementation, and have no effect on the core language. ... That's a meaningless proposition. The current D -release assert behavior can be implemented in a library (just trigger UB in the false branch). I recommend creating your own library assert, call it 'check' for example, and give it the semantics you wish. You can even have it expand to nothing for release builds. ... Well, awesome. Now I need to make everyone on the project as well as external libraries, such as Phobos, use my 'check' function, when the contract documentation tells them to use assert and does not even hint at the downsides. No, thanks. I'd rather fork the compiler. But I have explained this (and further reasons) already. I suspect you did not read my posts. A few others have. I'll try to keep this one shorter. Creating library asserts is why D has special support for __FILE__ and __LINE__ like C does, and for the same reasons. What I want is special support for sane built-in assert semantics using a compiler flag. That does not mean that there cannot _also_ be a flag to unleash the nasal demons upon unworthy programmers who were stupid enough to collaborate with someone who imported an external library that was written by somebody who had a bad day one time and left in a wrong assertion. Again: There is no reason why we need to force one behavior over the other. This should be configurable.
[Issue 18557] Types with 0 size should not be usable as aa key types
https://issues.dlang.org/show_bug.cgi?id=18557 Ketmar Darkchanged: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #3 from Ketmar Dark --- this patch breaks Variant: it is legal to use `This[This]` as a placeholder type in Variant, and with the patch applied that code doesn't compiles anymore ('cause `This` is defined as `struct This;`). adding real definition to `This` doesn't help too, 'cause then dmd errored with "recursive template expansion". --
[Issue 18564] core.demangle exception Range violation
https://issues.dlang.org/show_bug.cgi?id=18564 --- Comment #1 from Rainer Schuetze--- Did you try latest dmd master? There have been a couple of recent fixes that look similar, e.g. https://issues.dlang.org/show_bug.cgi?id=18300 and https://issues.dlang.org/show_bug.cgi?id=18208. --
[Issue 18542] DMD could generate better assembly for common range check idioms
https://issues.dlang.org/show_bug.cgi?id=18542 Ketmar Darkchanged: What|Removed |Added CC||ket...@ketmar.no-ip.org --
Re: Why does this not compile?
On 06.03.2018 17:19, Steven Schveighoffer wrote: unittest { int n = 0; struct S { int fun() const { return n; } } immutable S s; assert(s.fun == 0); n++; assert(s.fun == 1); // Not so immutable now, are you? } That's not a demonstration of breaking immutability. counter-proof: struct S { static int x; int fun() const { return x; } } immutable S s; assert(s.fun == 0); S.x++; assert(s.fun == 1); In other words, if the struct can access the data considered "outside it's instance", then it it can return it, change it even. Here's how to break immutability: void main(){ int i = 0; struct S{ const(int)* fun()const pure{ return } } immutable S s; static const(int)* foo(immutable(S) s)pure{ return s.fun(); } immutable(int) *pi=foo(s); import std.stdio; writeln(*pi); // 0 i+=1; writeln(*pi); // 1 } The reasoning "the reference is stored in the type yet not part of the type" does not work for pure functions, as then you cannot offer an alternative explanation in terms of an external data store. https://issues.dlang.org/show_bug.cgi?id=18567
[Issue 18567] New: immutability hole related to context pointers accessed through const pure methods
https://issues.dlang.org/show_bug.cgi?id=18567 Issue ID: 18567 Summary: immutability hole related to context pointers accessed through const pure methods Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: critical Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: timon.g...@gmx.ch DMD 2.079.0 void main(){ int i = 0; struct S{ const(int)* fun()const pure{ return } } immutable S s; static const(int)* foo(immutable(S) s)pure{ return s.fun(); } immutable(int) *pi=foo(s); import std.stdio; writeln(*pi); // 0 i+=1; writeln(*pi); // 1 } I.e. the data *pi is typed as immutable(int), yet changes. --
[Issue 18566] New: const on method of nested data type is not applied to variables in context
https://issues.dlang.org/show_bug.cgi?id=18566 Issue ID: 18566 Summary: const on method of nested data type is not applied to variables in context Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: timon.g...@gmx.ch void main(){ int i = 0; struct S{ int *fun()const pure{ return // compiles, but shouldn't } } } The type of i within "fun" should be "const(int)". --
[Issue 18563] context pointer inside structs constness problems
https://issues.dlang.org/show_bug.cgi?id=18563 Ketmar Darkchanged: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"
https://issues.dlang.org/show_bug.cgi?id=18541 --- Comment #9 from Ketmar Dark--- compiler transforms `==` for objects to virtual call, and dmd cannot devirtualize calls (yet? ;-). so yeah, no inlining. it is quite possible to rewrite the call into `e1 is e1 || .object.opEquals(e1, e2)`, tho. --- a/src/ddmd/opover.d +++ b/src/ddmd/opover.d @@ -30,6 +30,7 @@ import ddmd.globals; import ddmd.id; import ddmd.identifier; import ddmd.mtype; +import ddmd.sideeffect; import ddmd.statement; import ddmd.tokens; import ddmd.visitor; @@ -1162,7 +1163,7 @@ extern (C++) Expression op_overload(Expression e, Scope* sc) if (!(cd1.cpp || cd2.cpp)) { /* Rewrite as: - * .object.opEquals(e1, e2) + * e1 is e2 || .object.opEquals(e1, e2) */ Expression e1x = e.e1; Expression e2x = e.e2; @@ -1176,12 +1177,38 @@ extern (C++) Expression op_overload(Expression e, Scope* sc) if (cd2.isInterfaceDeclaration()) e2x = new CastExp(e.loc, e.e2, t2.isMutable() ? to : to.constOf()); +/* create temporaries, to avoid invalid rewriting of this: + *if (arr[i++] is obj || .object.opEquals(arr[i++], obj) + * rewrite to: + *tmp1 = e1x, tmp2 = e2x, then use temps + */ +// load e1x to temporary +auto tmp1 = copyToTemp(STCnodtor, "__opEqualsTmp1", e1x); +auto e1xtmp = new CommaExp(e.loc, new DeclarationExp(e.loc, tmp1), new VarExp(e.loc, tmp1)); + +// load e2x to temporary +auto tmp2 = copyToTemp(STCnodtor, "__opEqualsTmp2", e2x); +auto e2xtmp = new CommaExp(e.loc, new DeclarationExp(e.loc, tmp2), new VarExp(e.loc, tmp2)); + +// e1 is e2 +auto expis = new IdentityExp(TOKidentity, e.loc, e1xtmp, e2xtmp); + +// and use fresh varexps with temps (previous ones can be changed by semanticing) +e1x = new VarExp(e.loc, tmp1); +e2x = new VarExp(e.loc, tmp2); + +// .object.opEquals(e1, e2) result = new IdentifierExp(e.loc, Id.empty); result = new DotIdExp(e.loc, result, Id.object); result = new DotIdExp(e.loc, result, Id.eq); result = new CallExp(e.loc, result, e1x, e2x); + +// expis || result +result = new LogicalExp(e.loc, TOKoror, expis, result); + if (e.op == TOKnotequal) result = new NotExp(e.loc, result); + result = result.semantic(sc); return; } --
[Issue 18562] expression is not evaluated when accessing manifest constant
https://issues.dlang.org/show_bug.cgi?id=18562 Ketmar Darkchanged: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 18560] find on infinite ranges is broken
https://issues.dlang.org/show_bug.cgi?id=18560 Ketmar Darkchanged: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 18565] New: std.regex Captures opAssign returns void since v2.079.0
https://issues.dlang.org/show_bug.cgi?id=18565 Issue ID: 18565 Summary: std.regex Captures opAssign returns void since v2.079.0 Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: regression Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: d.b...@webfreak.org Before commit 59520969ef73eaf0691972ee00b389e5bbc4c8fb this code used to work: --- import std.regex; void main() { string str; Captures!string match; if (cast(bool)(match = str.matchFirst("a")) || cast(bool)(match = str.matchFirst("b"))) {} } --- and it performed the expected operations. However now the compilation fails with: --- a.d(7): Error: cannot cast expression match.opAssign(matchFirst(str, "a")) of type void to bool a.d(8): Error: cannot cast expression match.opAssign(matchFirst(str, "b")) of type void to bool --- --
Re: Advent of D
On Tuesday, 6 March 2018 at 21:09:06 UTC, Jordi Gutiérrez Hermoso wrote: I did post it to Lobsters, though: This is random but I have been thinking about asking for a lobsters invite... can you hook me up?
Vtable for virtual functions in D
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.
Re: Advent of D
On Tuesday, 6 March 2018 at 20:37:34 UTC, Steven Schveighoffer wrote: On 3/6/18 1:09 PM, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ I'm enjoying this. One thing jumped out at me: static does not mean execute at compile time (exactly), it really means allocate this data in thread-local storage. Thanks for the explanation. I forgot about using enum instead. I think I've only briefly encountered it before. I'm aware of the global storage of static in this context. I like that it's the same keyword for static foreach; that's kind of what I was thinking when I wrote that just adding a static can result in compile-time execution. BTW, that tour page needs updating, it has a few errors in it. You mean the Dlang tour? I've been meaning for a while to be able to generate a url to its Gems section but I've never managed to untangle its Vibe.d structure enough to do so.
Re: Advent of D
On Tuesday, 6 March 2018 at 21:03:47 UTC, JN wrote: On Tuesday, 6 March 2018 at 18:09:21 UTC, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ on Day 8, I think the original "verbose" code is better in the end. Mixin at least for me makes it a bit less clear on what exactly is going on. On the other hand the latter version is probably easier to maintain and more copy-paste-error-proof. Yeah, it's mostly the C that I wanted to get rid of. I do wish the static foreach had worked, though! It's odd that you can't have compile-time associative arrays.
Re: Advent of D
On Tuesday, 6 March 2018 at 20:09:58 UTC, Joakim wrote: Nice write-up, worth sharing on reddit/HN. Thanks. I tried posting it to HN, but it didn't pick up. If several of you try posting it too, it might pick up. Posting to Reddit is easier, but I don't have a recognisable account on Reddit to post it from. I did post it to Lobsters, though: https://lobste.rs/s/b4qki7/advent_d
Setting executable's information by resources
I'm trying to use this resource to set executable's information/metadata but it fail to set anything but the icon, without any error message. Could anyone point out if there's anything wrong with my approach? (if anyone use a different approach/toolset to set those data, your suggestion is very welcome) commands: C:\dm\bin\rcc.exe -32 -D__NT__ res.rc dmd app.d res.res resource file IDI_ICON1 ICONDISCARDABLE "ico.ico" #include "version.h" VS_VERSION_INFO VERSIONINFO FILEVERSION VER_FILEVERSION PRODUCTVERSION VER_PRODUCTVERSION BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904E4" BEGIN VALUE "CompanyName",VER_COMPANYNAME_STR VALUE "FileDescription",VER_FILEDESCRIPTION_STR VALUE "FileVersion",VER_FILEVERSION_STR VALUE "InternalName", VER_INTERNALNAME_STR VALUE "LegalCopyright", VER_LEGALCOPYRIGHT_STR VALUE "LegalTrademarks1", VER_LEGALTRADEMARKS1_STR VALUE "LegalTrademarks2", VER_LEGALTRADEMARKS2_STR VALUE "OriginalFilename", VER_ORIGINALFILENAME_STR VALUE "ProductName",VER_PRODUCTNAME_STR VALUE "ProductVersion", VER_PRODUCTVERSION_STR END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1252 END END
Re: Advent of D
On Tuesday, 6 March 2018 at 18:09:21 UTC, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ on Day 8, I think the original "verbose" code is better in the end. Mixin at least for me makes it a bit less clear on what exactly is going on. On the other hand the latter version is probably easier to maintain and more copy-paste-error-proof.
Re: Release D 2.079.0
On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote: I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila I don't think this is unusual even outside of D. At least Microsoft seems to be willing to break your build if it moves things forward. For example, there are projects that worked fine on MSVC 15.4 (VS2017), but broke if you installed the update to 15.5 (or auto-updated in Visual Studio). You can't test everything. A lot of the "regular" companies, that desire high stability, typically use very old compilers and just workaround the bugs they know. For a D example, I think Sociomantic was using D1 for a long time just because it was stable for them. And if you need stability, why would you update the compiler without local testing and reserving time to fix any issues?
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #30 from Andrei Alexandrescu--- Indeed it seems we are not supporting registration by address with ease for D value types. There are good reasons for that; by allowing value types to be moved around we avoid a swath of complications and difficulties that C++ encounters with their definition of rvalue references and move constructors. That C++ feature complicates all code considerably and still has a variety of safety, correctness, and efficiency issues (I am not exaggerating; all three problems are present) that make the bread and butter of advanced C++ instructors worldwide, including myself. I think we got the better deal there. The disadvantage is that indeed an object can be born and die at different addresses. So self-registering objects by address, or objects holding internal pointers, do not work with automatic allocation. Such is the nature of automatic allocation in D. (It should be noted that C++ has its own, distinct issues with self-registering objects, to which I dedicate several slides in http://erdani.com/index.php/training/mc1xd.) Allow me to make a few suggestions for workarounds: * Avoid automatic/stack allocation and also return by value. A struct may hold internal pointers and a constant address as long as the memory it's in is not automatic/stack. If you use raw memory in conjunction with functions such as emplace and destroy, you have good control. As a perk, you avoid the creation, copying, and destruction of spurious objects - which comes along with calls to register/unregister, which I assume has a significant cost. * Use a "cookie", not an address, in the registration. A classic registration pattern returns a cookie/handle, usually an integer, which the object stores. Then, the object passes that cookie back to the unregister function. In other words, if the address of an object isn't invariant, let's define something that is. * Use dynamic allocation in conjunction with reference counting. I know this has been mentioned and dismissed as too expensive, but I'm mentioning it for completeness. Also, it's one of those cases in which engineering can go a long way: use a high-performance allocator (for which we have a solid framework in the standard library), duplicate objects lazily, etc. If after exploring these and other solutions you come to the conclusion they are not satisfactory, I encourage you to create a DIP. Two possible lines of attack are: (1) Allow specifying that an object can't be moved (2) Allow a type to intercept its move by means of a nothrow hook Drawing from extensive experience with Phobos and its very generic code, I can tell you I foresee difficulties with (1). Anything that makes types "more special than others" is bound to cause a smorgasbord of special handling in the library. I think (2) would be a better angle because it encapsulates the handling with the type. Thanks! --
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository. This allows selection of the dependency on std.experimental separate from phobos. It still would be an "official" dlang package, and might even be included in the distribution (the latest version anyway), and docs included on the website. But if needed, you could have your dub package depend on a prior version. The entire concept needs a reexamination IMO. I just checked the git history, and not one module has graduated from std.experimental to mainline Phobos since the idea's inception in 2014. While it's possible that none of the modules are ready, logger has been there for four years now. I was against changing how experimental is handled in the past, but I recently have started to rethink how we promote modules. Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us?
[Issue 18541] comparison `==` of two typeid() should always be rewritten as a "is"
https://issues.dlang.org/show_bug.cgi?id=18541 Ketmar Darkchanged: What|Removed |Added CC||ket...@ketmar.no-ip.org --
Re: Advent of D
On 3/6/18 1:09 PM, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ I'm enjoying this. One thing jumped out at me: static does not mean execute at compile time (exactly), it really means allocate this data in thread-local storage. What triggers the compile-time execution is the fact that static *initializers* need to be decided at compile time. So while it is executing the regex building at compile time in your example, there are other ways to do it, and in this case, I'd prefer using an enum. You can also use ctRegex. The drawback of using static is that it keeps its value between function calls: int bar() { return 42; } void foo() { static x = bar(); x += 5; writeln(x); } void main() { foo(); // 47 foo(); // 52 } So it may not be what you are looking for. Whereas if you use: void foo() { enum x = bar(); writeln(x + 5); } it will always write the same answer (and not allocate global space for it). BTW, that tour page needs updating, it has a few errors in it. -Steve
Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it
On Tuesday, 6 March 2018 at 20:25:10 UTC, Johan Engelen wrote: On Tuesday, 6 March 2018 at 18:19:13 UTC, Luís Marques wrote: On my LLVM fork for RISC-V and MSP430 work it doesn't build (no llvm/Support/DJB.h) and on the latest stable, 5.0.1, cmake fails to configure (Unknown CMake command "add_llvm_install_targets"). LLDB and LLVM need to be version synchronized. Did you checkout LLVM and LLDB both from their respective same-named release branches? I'm pretty sure Timothee based his patch onto LLDB/LLVM trunk. -Johan
Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it
On Tuesday, 6 March 2018 at 18:19:13 UTC, Luís Marques wrote: On my LLVM fork for RISC-V and MSP430 work it doesn't build (no llvm/Support/DJB.h) and on the latest stable, 5.0.1, cmake fails to configure (Unknown CMake command "add_llvm_install_targets"). LLDB and LLVM need to be version synchronized. Did you checkout LLVM and LLDB both from their respective same-named release branches? -Johan
Re: Profiling after exit()
On Thursday, 27 July 2017 at 15:16:35 UTC, Eugene Wissner wrote: Are there profilers that work well with dmd? valgrind? OProfile? Yes, any sampling profiler works fine, e.g. perf on linux, Intel VTune/AMD CodeXL on Windows. Those directly monitor CPU performance counters and have a negligible performance overhead compared with dmd's instrumenting profiler, also they don't require rebuilding of binaries.
[Issue 18564] core.demangle exception Range violation
https://issues.dlang.org/show_bug.cgi?id=18564 johanenge...@weka.io changed: What|Removed |Added Keywords||mangling --
[Issue 18564] core.demangle exception Range violation
https://issues.dlang.org/show_bug.cgi?id=18564 johanenge...@weka.io changed: What|Removed |Added Keywords||industry CC||r.sagita...@gmx.de --
[Issue 18564] New: core.demangle exception Range violation
https://issues.dlang.org/show_bug.cgi?id=18564 Issue ID: 18564 Summary: core.demangle exception Range violation Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: johanenge...@weka.io Testcase: ``` import core.demangle; import std.stdio; void main() { enum str = "UVVUYUUY"; writeln(demangleType(str)); } ``` Instead of outputting the string, we get: `core.exception.RangeError@core/demangle.d(230): Range violation` (found by fuzz testing, but I get a range violation on the same line with a real world type mangle too) --
Re: Advent of D
On Tuesday, 6 March 2018 at 18:09:21 UTC, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ Really nice, thank you.
Re: How to use globals correctly?
On Tuesday, March 06, 2018 11:52:05 H. S. Teoh via Digitalmars-d-learn wrote: > On Tue, Mar 06, 2018 at 11:46:04AM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: > > On Tuesday, March 06, 2018 18:34:34 bauss via Digitalmars-d-learn wrote: > [...] > > > > Singletons are always smelly code tbh. > > > > > > Especially in D with thread-local storage. > > > > > > I can't think of a situation where you truly need singletons in D. > > > > I confess that I've never really understood why some folks dislike > > singletons so much, but then again, I've only rarely found cases where > > I thought that they made sense, and I gather that some folks out there > > use the singleton pattern way too much (I've heard it suggested that > > it's because it was one of the few design patterns from the design > > pattern book that was easy). > > [...] > > To me, a singleton is a symptom of excessive dogmatic adherence to the > OO religion where Everything Must Be A Class No Matter What. When there > can only be one of something, it's clearly no longer a *class*, but is > either a module, a global variable, or a (set of) global function(s). > > I'm curious to know what are the few cases where you think a singleton > made sense, where it wouldn't be more appropriately implemented as a > module, global variable, or global function(s). It makes sense whenever it doesn't make sense to have multiple instances of a particular class, and it makes sense to enforce that. As I explained, LocalTime and UTC from std.datetime do that for exactly that reason. Cases like that are rare, but they do exist. However, they also exist rarely enough that it's going to be hard to come up with more examples. I judge whether singletons makes sense on a case-by-case basis. Sometimes, they do make sense, so I wouldn't say that they're necessarily a code smell, but I also completely agree that they rarely make sense. So, I don't disagree that singletons should rarely be used. I just disagree with the idea that they should never be used. And for better or worse, singletons are one of those things that seems to me like it should usually be obvious whether they make sense in a particular case, but that doesn't seem to be true for everyone, otherwise there wouldn't be as much of a dislike of singletons as there seems to be, since they wouldn't come up very often. - Jonathan M Davis
Re: Advent of D
On Tuesday, 6 March 2018 at 18:09:21 UTC, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ What's with the mammoth D blog posts lately? Nice write-up, worth sharing on reddit/HN.
[Issue 18561] postblit should allow writing const/immutable members just like constructors
https://issues.dlang.org/show_bug.cgi?id=18561 --- Comment #5 from Steven Schveighoffer--- (In reply to anonymous4 from comment #3) > a.__ctor(1); This is another bug. One should only be able to call const __ctor on a struct once, before using it. --
Re: 5000 Merged Phobos Pull Requests
On Tue, Mar 06, 2018 at 07:21:10PM +, Jack Stouffer via Digitalmars-d wrote: > Nine days ago, Phobos hit 5000 merged pull requests: > > https://github.com/dlang/phobos/pulls?page=201=is%3Apr+is%3Amerged+sort%3Amerged-desc=✓ > > Thats an average of 1.93 merged PRs per day (first PR merged on Jan > 31, 2011). > > A huge thank you to everyone who made this happen. Very nice! One thing I would really like to see, though, is the reduction of the average size of the Phobos PR queue. Last month when I had a spot of free time I was diving into the deep end of the "cesspool", so to speak, of old Phobos PRs that have been languishing in the queue for far too long. With some effort, we managed to get the queue down to <100. I wanted to drive it down further, but then got busy with other things and haven't been able to work on Phobos PRs much since. Sadly, the queue has clogged back up to the 100+'s, with no end in sight. :-( It would be nice if somebody, or preferably a group of somebodies, would take on the task of digging into the deep end of the Phobos PR queue and either kick them back to life, revive them, or decide they're not worth the effort and close them. Having a PR sit in there forever with no sign of when / whether it will ever be merged is a big morale killer. You don't need commit privileges to contribute; there are plenty of other ways to help, like pinging the submitter if he's gone missing, or pinging Phobos devs if people seem to have forgotten about perfectly good work, or taking a look at the code and pointing out obvious / not so obvious issues. Or simply just pinging people (esp. @andralex :-D) and making yourself a nuisance if a PR seems stuck for no good reason. While understandably Andrei would hesitate handing out commit rights too easily, having a larger group of people help in these other ways would greatly help improve Phobos. (And if you get busy enough, Andrei might notice and give you commit rights. ;-) Which would help with our manpower problem.) T -- Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
Re: See docs compiler message
On 3/6/18 9:50 AM, ixid wrote: On Tuesday, 6 March 2018 at 14:37:27 UTC, Steven Schveighoffer wrote: Now, there aren't actually docs for Transposed, but you can find it if you look at std.range.transposed: https://dlang.org/phobos/std_range.html#transposed Thanks, I had found that but that is not an explanation unless you have a lot of prior technical understanding of what save is and why it's not working. I guess it's a general doc quality issue - unless you're already very knowledgeable it's pretty much useless to understand the problem you have. There are 2 problems. One is that Transposed offered .save as a member, when it shouldn't have (it's not a valid forward range). This is clear from trying to even use it as a forward range. Even when you call save, it destroys the original. The other problem is that I think algorithms are seeing that .save is there, and thinking it's a forward range, so using it that way. I transposed a range of ranges to pass to a function to get the distance between characters in strings. That works fine, as does printing the result. But it then complains if I try to do anything like fold with the result. I have no idea how save is called, but apparently it is somewhere in there. -Steve
[Issue 18561] postblit should allow writing const/immutable members just like constructors
https://issues.dlang.org/show_bug.cgi?id=18561 --- Comment #4 from ajiesk...@gmail.com --- (In reply to anonymous4 from comment #3) > This passes: > --- > struct A > { > int a; > this(int b) const { a=b; } > } > int main() > { > const A a; > assert(a.a==0,"0"); > a.__ctor(1); > assert(a.a==1,"1"); > return 0; > } > --- I believe it should not. Yes, constructor should be able to do that, but only when used as a constructor. But it is a separate issue from this one. --
Re: DIP 1006 - Preliminary Review Round 1
On Tuesday, March 06, 2018 18:49:42 Paolo Invernizzi via Digitalmars-d wrote: > I simply don't understand why enforce or a custom check can't be > used @safe code, if you want that behaviour. > > If the program must HALT on this or that, well, what is better > than an explicit piece of unremovable code that do that? Instead > of writing 'assert', one should write 'enforce'. 1. It's quite common for folks to want to add debugging checks that are compiled out in -release. That's exactly what assert is for in pretty much every lanugage that has it. It's what folks expect to use and what your average programmer will use without thinking about @safety issues at all. It's what everyone uses right now, and I'm pretty sure that almost everyone using it has no clue that Walter considers it okay for assertions to introduce optimizations which are not memory safe, and if/when he does do so, a lot of D code will suddenly have @safe code which is not memory safe. Such problems will hopefully be hit rarely, because hopefully, the code will have been well-tested, and the assertions will have found all of the related bugs, but there's every possibility that some bugs will manage to not be caught, thereby resulting in @safe code being unsafe. No one is going to be looking to use solutions other than assertions for what assertions are for unless we start telling everyone to avoid assertions, because they make @safe code unsafe. And honestly, if assertions make @safe code unsafe, I don't see a good argument for using them at all. If I didn't care about code being @safe, I wouldn't be using @safe. @safe is supposed to guarantee that the code is memory safe. 2. I think that it's fundamentally a terrible idea to allow built-in language features to violate @safe. Aside from issues related to @trusted being misused, @safe code should be guaranteed to be memory safe, and it should be considered a bug any time that it isn't. That's why @safe exists. No one should have to be looking at @safe code to track down memory safety problems. And if they do, then @safe is not doing it's job. Array bounds checks are left in @safe code for exactly these reasons. I'm all for introducing optimizations that do not violate @safe, but if we allow @safe code to be unsafe, then why do we even have it? - Jonathan M Davis
Re: Release D 2.079.0
On 3/6/18 2:30 PM, Martin Nowak wrote: On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: But if needed, you could have your dub package depend on a prior version. http://code.dlang.org/packages/stdx-allocator ;) This is the answer, vibe.d should depend on stdx-allocator. -Steve
Re: How to use globals correctly?
On Tue, Mar 06, 2018 at 11:46:04AM -0700, Jonathan M Davis via Digitalmars-d-learn wrote: > On Tuesday, March 06, 2018 18:34:34 bauss via Digitalmars-d-learn wrote: [...] > > Singletons are always smelly code tbh. > > > > Especially in D with thread-local storage. > > > > I can't think of a situation where you truly need singletons in D. > > I confess that I've never really understood why some folks dislike > singletons so much, but then again, I've only rarely found cases where > I thought that they made sense, and I gather that some folks out there > use the singleton pattern way too much (I've heard it suggested that > it's because it was one of the few design patterns from the design > pattern book that was easy). [...] To me, a singleton is a symptom of excessive dogmatic adherence to the OO religion where Everything Must Be A Class No Matter What. When there can only be one of something, it's clearly no longer a *class*, but is either a module, a global variable, or a (set of) global function(s). I'm curious to know what are the few cases where you think a singleton made sense, where it wouldn't be more appropriately implemented as a module, global variable, or global function(s). T -- Старый друг лучше новых двух.
[OT] Gaming Meetup
Hi, I was planning on going to what is basically a LAN Party in the Netherlands near Venlo and was wondering if anyone in this community also went or would want to go. It is themed after a certain computer game called osu! which probably not a lot of you play, but it might still be a nice opportunity to meet up and after all that's not all we will be playing there. Not sure how many gamers there are in this community but maybe someone will go too and we could meet. It's around end of July and you can go for up to 10 days (I will probably be there 9 days starting saturday), details can be found on https://cavoeboy.com/
Re: DIP 1006 - Preliminary Review Round 1
On Tuesday, 6 March 2018 at 18:49:42 UTC, Paolo Invernizzi wrote: I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. /Paolo Easy: the custom check itself could be wrong the custom check itself is right, but the implementation is wrong even though it may passed your unit tests.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote: Can somebody explain how [0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore. [0] is runtime bounds-checked array.ptr is unchecked and might return an out-of-bounds pointer (to the first element)
Re: Release D 2.079.0
On Monday, 5 March 2018 at 16:18:11 UTC, Chris M. wrote: Good stuff. Still bothers me that we had to special case "throw new Exception();" in order to make it nogc. I can't think of any better ways right now Implementing EH for values (instead of class references) would have been a lot more complex. but I wish it was more explicit. Initially people always want more explicitness for new, not yet too well known, features, while later opting for terser syntax for commonly used things. Exceptions are supposed to be rare and deleting them directly after being catched seemed like a reasonable enough default to go with the specialization. After all it solves a huge problem, error handling in @nogc code. Maybe we'll find a better/cleaner solution when more of the language has been transitioned to @safe @nogc.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 11:10:49 UTC, Atila Neves wrote: The problem with that is I was waiting for 2.079.0 since it fixes a bug that prevented me from upgrading to any of the 2.078.x releases on Windows. I think 2.078 would make an excellent starting point for a LTS because of the important fixes that only made it to 2.079. If anyone is interested to backport fixes and maintain such a source-branch, please contact me.
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 12:21:41 UTC, Steven Schveighoffer wrote: That being said, I'm wondering if it wouldn't be better to have std.experimental be in its own repository. Just showing that phobos is not the right place to develop modules/packages, also mir. IMO std.experimental provides little benefit over dub, but comes with many downsides. This allows selection of the dependency on std.experimental separate from phobos. You cannot link against diamond dependencies of different versions though, so we'd have to exclude it from libphobos and put it separately. It still would be an "official" dlang package, and might even be included in the distribution (the latest version anyway), and docs included on the website. Not sure why inclusion in distribution is often mentioned as such a thing. It's trivial and common to have separate libraries/dependencies in every language with a healthy ecosystem. But if needed, you could have your dub package depend on a prior version. http://code.dlang.org/packages/stdx-allocator ;)
Re: Speed of math function atan: comparison D and C++
On Tuesday, 6 March 2018 at 18:41:15 UTC, H. S. Teoh wrote: The fix itself may be straightforward, but how to do it without breaking tons of existing code and provoking user backlash is the tricky part. [snip] Ah, I see what you're saying. People may be depending on the extra accuracy for these functions. Would just require something like double sin(double x) @safe pure nothrow @nogc { version (FP_Math) { ///double sin implementation } else { return sin(cast(real) x); } }
5000 Merged Phobos Pull Requests
Nine days ago, Phobos hit 5000 merged pull requests: https://github.com/dlang/phobos/pulls?page=201=is%3Apr+is%3Amerged+sort%3Amerged-desc=✓ Thats an average of 1.93 merged PRs per day (first PR merged on Jan 31, 2011). A huge thank you to everyone who made this happen.
Re: Article: Why Const Sucks
On Monday, 5 March 2018 at 17:38:52 UTC, H. S. Teoh wrote: struct Container { auto opSlice() const { static struct Result { private Container impl; private int n; // internal mutable state @property bool empty() { ... } ... // rest of range API } return Result(this); } } That's definitely a know problem with ranges that hasn't yet been solved. The known workaround is to implement Range and ConstRange. This idiom could prolly be encapsulated in a safe and generic template type to avoid boilerplate. If we had some covariant mechansim to implement sth. similar to struct Range(T) if (is(T InoutT == inout)) { inout(InoutT) opIndex(size_t i) inout; } that would be ideal, but that isn't exactly trivial. I think we had a better issue for this topic, but here is one ticket asking for this feat. [9983 – inout type can not be used as a parameter for structure template](https://issues.dlang.org/show_bug.cgi?id=9983)
[Issue 9983] inout type can not be used as a parameter for structure template
https://issues.dlang.org/show_bug.cgi?id=9983 Martin Nowakchanged: What|Removed |Added CC||c...@dawg.eu Severity|normal |enhancement --
can't build libuid examples
Try to build libuid examples get the following error. dub build, build successfully on the root folder. I will appreciate any help. Just try to build a gui app using dlang. OPTLINK (R) for Win32 Release 8.00.17 Copyright (C) Digital Mars 1989-2013 All rights reserved. http://www.digitalmars.com/ctg/optlink.html ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(App) Error 42: Symbol Undefined _uiControlDestroy ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(App) Error 42: Symbol Undefined _uiMain ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowTitle ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetTitle ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowPosition ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetPosition ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowCenter ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowContentSize ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetContentSize ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowFullscreen ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetFullscreen ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowBorderless ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetBorderless ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetChild ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowMargined ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowSetMargined ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiOpenFile ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiSaveFile ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiMsgBox ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiMsgBoxError ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiNewWindow ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowOnPositionChanged ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowOnContentSizeChanged ..\..\AppData\Roaming\dub\packages\libuid-0.0.7\libuid\.dub\build\lib-debug-windows-x86-dmd_2079-7AA4D084E1AB1DF72ADCC536E95F2BDA\uid.lib(Window) Error 42: Symbol Undefined _uiWindowOnClosing
Re: Article: Why Const Sucks
On Tuesday, March 06, 2018 19:06:25 Martin Nowak via Digitalmars-d-announce wrote: > On Tuesday, 6 March 2018 at 18:17:58 UTC, Jonathan M Davis wrote: > > I'm not actually convinced that killing auto-decoding is really > > much better. > > I don't think the problem is auto-decoding in string range > adapters, but repeated validation. > https://issues.dlang.org/show_bug.cgi?id=14519#c32 > If you know that sth. works on code units just use > .representation. > > There is the related annoyance when the user of a function > presumably knows to only deal with ASCII strings but algorithms > fail, e.g. splitter.popBack or binary search. This one is tricky > because broken unicode support is often rooted in ignoring it's > existence. Yes, using stuff like representation or byCodeUnit helps to work around the auto-decoding, but as long as it's there, you have to constantly work around it if you care about efficiency with strings and/or want to be able to retain the original string type where possible. At this point, I think that it's pretty clear that we wouldn't have it if we could do stuff from scratch, but of course, we can't do stuff from scratch, because that would break everything. - Jonathan M Davis
[Issue 18134] BitArray >>= broken when length % (8 * size_t.sizeof) == 0
https://issues.dlang.org/show_bug.cgi?id=18134 github-bugzi...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 18134] BitArray >>= broken when length % (8 * size_t.sizeof) == 0
https://issues.dlang.org/show_bug.cgi?id=18134 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/b211347454b70fdb5a539f3fd8bc82fcec846e70 Fix issue 18134 - BitArray right shift broken if length is multiple of 8*size_t.sizeof https://github.com/dlang/phobos/commit/6264e40d8abbb411d4391b3cf8c4d2d4c69423e1 Merge pull request #6110 from byebye/issue_18134 Fix issue 18134 - BitArray right shift broken if length is multiple of 8*size_t.sizeof merged-on-behalf-of: Jack Stouffer--
Re: Article: Why Const Sucks
On Tuesday, 6 March 2018 at 18:17:58 UTC, Jonathan M Davis wrote: I'm not actually convinced that killing auto-decoding is really much better. I don't think the problem is auto-decoding in string range adapters, but repeated validation. https://issues.dlang.org/show_bug.cgi?id=14519#c32 If you know that sth. works on code units just use .representation. There is the related annoyance when the user of a function presumably knows to only deal with ASCII strings but algorithms fail, e.g. splitter.popBack or binary search. This one is tricky because broken unicode support is often rooted in ignoring it's existence.
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 Jonathan M Davischanged: What|Removed |Added CC||issues.dl...@jmdavisprog.co ||m --- Comment #29 from Jonathan M Davis --- (In reply to Tomer Filiba (weka) from comment #27) > I don't suppose this would help. It seems the & operator is just not allowed > in safe code: > > void main() @safe { > int x; > auto tmp = // Error: cannot take address of local x in @safe > function > } That code becomes @safe with -dip1000, because then it's inferred as scope, and the compiler verifies that it doesn't escape, whereas without DIP 1000 and its improvements to scope, the compiler doesn't have any way to ensure that the resulting pointer is used in an @safe manner. So, DIP 1000 should have a fairly large impact on how @safe certain operations are. (In reply to Tomer Filiba (weka) from comment #28) > My point is, @safe is so constrained that it's practically unusable, so I > don't consider it a viable solution for this problem. That would be highly dependent on what your code is doing and how willing you are to vet code and mark functions @trusted where appropriate or use @trusted lambdas to mark sections of code as @trusted (which isn't the most ideal solution for marking a section of code as @trusted, but it's the best we have right now). If you're constantly doing stuff like taking the address of a local variable, then yes, @safe is going to be a miserable mess (though DIP 1000 may fix that). But a lot of code can be @safe with no problem. It really depends on the type of stuff your code is doing. --
Re: mysql-native v2.1.0
On Tuesday, 6 March 2018 at 18:36:45 UTC, bauss wrote: On Tuesday, 6 March 2018 at 18:31:08 UTC, bauss wrote: On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote: [...] I'm unsure how I'd go about implementing prepared statements in a vibe.d application correctly. [...] Like more specifically do I still call lockConnection() on a MySQLPool? I think it would be easier to help me if I put some examples. I just tried changing stuff and I can't seem to get it working. I kept using lockConnection() as before, I assume it's the right way. Then I changed the way I retrieve prepared statements from: auto prepared = prepare(connection, sql); prepared.setArgs(params); to: auto prepared = connection.prepare(sql); prepared.setArgs(params); Then ex. for reading many entries: From: return prepared.querySet().map!((row) { auto model = new TModel; model.row = row; model.readModel(); return model; }); To: return connection.query(prepared).map!((row) { auto model = new TModel; model.row = row; model.readModel(); return model; }); But it doesn't seem to work. I get the following exception: "Attempting to popFront an empty map" which I assume is because the result is empty. So what am I doing wrong in using prepared statements with the new updates?
Re: Article: Why Const Sucks
On Tuesday, March 06, 2018 10:47:36 H. S. Teoh via Digitalmars-d-announce wrote: > On Tue, Mar 06, 2018 at 01:31:39PM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: > > On 3/6/18 10:39 AM, Jonathan M Davis wrote: > > > Yeah. If you're dealing with generic code rather than a specific > > > range type that you know is implicitly saved when copied, you have > > > to use save so often that it's painful, and almost no one does it. > > > e.g. > > > > > > equal(lhs.save, rhs.save) > > > > > > or > > > > > > immutable result = range.save.startsWith(needle.save); > > > > Yep. The most frustrating thing about .save to me is that .save is > > nearly always implemented as: > > > > auto save() { return this; } > > > > This just screams "I really meant just copying". > > Yeah, and also: > > auto save() { > auto copy = this; > copy.blah = blah.dup; > return this; > } > > Which just screams "I'm really just a postblit in disguise". That's exactly what it is. It's a postblit constructor that you have to call manually and which works for classes and dynamic arrays in addition to structs. - Jonathan M Davis
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #28 from Tomer Filiba (weka)--- My point is, @safe is so constrained that it's practically unusable, so I don't consider it a viable solution for this problem. --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #27 from Tomer Filiba (weka)--- (In reply to Andrei Alexandrescu from comment #25) > > So... more special cases? > > That's a straight use of scope per DIP 1000, in fact the very design intent: > scope in a function signature specifies the function won't escape the > parameter. I don't suppose this would help. It seems the & operator is just not allowed in safe code: void main() @safe { int x; auto tmp = // Error: cannot take address of local x in @safe function } --
Re: DIP 1006 - Preliminary Review Round 1
On Tuesday, 6 March 2018 at 17:34:08 UTC, 12345swordy wrote: On Tuesday, 6 March 2018 at 17:24:35 UTC, Jonathan M Davis wrote: On Tuesday, March 06, 2018 16:30:09 John Colvin via Digitalmars-d wrote: On Tuesday, 6 March 2018 at 02:05:58 UTC, Walter Bright wrote: > [...] So, to clarify, adding asserts to my code makes my release builds violate @safe? If the compiler actually optimized based on assertions, then yes, but not right now. As I understand it, the problem is theoretical at the moment, because the compiler does not yet optimize based on assertions, but once it does, if it's allowed to introduce optimizations that would be not be memory safe if the assertion would have failed if it hadn't been compiled out, then @safe will be violated, and at that point, I would be telling everyone to never use assertions, because they're too dangerous. If we can restrict the compiler to optimizations that are memory safe, then I don't see a problem, but clearly, Walter is not in agreement that the optimizations should be restricted in that manner. - Jonathan M Davis I think a reasonable compromise is to introduce a new system attribute such as @unsafeoptimize to tell the programmer that this function may have it's @safe attribute removed when making optimizations based on the asserts. We have @trusted attribute for a good reason here. I simply don't understand why enforce or a custom check can't be used @safe code, if you want that behaviour. If the program must HALT on this or that, well, what is better than an explicit piece of unremovable code that do that? Instead of writing 'assert', one should write 'enforce'. /Paolo
Re: Article: Why Const Sucks
On Tue, Mar 06, 2018 at 01:31:39PM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: > On 3/6/18 10:39 AM, Jonathan M Davis wrote: > > Yeah. If you're dealing with generic code rather than a specific > > range type that you know is implicitly saved when copied, you have > > to use save so often that it's painful, and almost no one does it. > > e.g. > > > > equal(lhs.save, rhs.save) > > > > or > > > > immutable result = range.save.startsWith(needle.save); > > Yep. The most frustrating thing about .save to me is that .save is > nearly always implemented as: > > auto save() { return this; } > > This just screams "I really meant just copying". Yeah, and also: auto save() { auto copy = this; copy.blah = blah.dup; return this; } Which just screams "I'm really just a postblit in disguise". T -- This is not a sentence.
Re: How to use globals correctly?
On Tuesday, March 06, 2018 18:34:34 bauss via Digitalmars-d-learn wrote: > On Monday, 5 March 2018 at 19:51:33 UTC, Steven Schveighoffer > > wrote: > > On 3/5/18 2:25 PM, Marc wrote: > >> Can __gshared be used instead of static in the singleton > >> pattern? I, comming from C++, ignorantly, have never used > >> _gshared so I went to static instead of (being static also > >> means thread-safe, as far I know)... > > > > static in D is thread safe, because it's thread-local. > > __gshared is shared between threads, so it's not thread safe, > > but has the exact same type as just static data. > > > > Can you use it for singleton? Sure, classic singleton is shared > > between threads. But using thread-local data, you can solve the > > singleton problem in a better way: > > > > https://wiki.dlang.org/Low-Lock_Singleton_Pattern > > > > Note, it still uses __gshared, which means it doesn't protect > > you from race conditions when you actually USE the singleton > > object. This means you need some synchronization inside the > > methods. > > > > -Steve > > Singletons are always smelly code tbh. > > Especially in D with thread-local storage. > > I can't think of a situation where you truly need singletons in D. I confess that I've never really understood why some folks dislike singletons so much, but then again, I've only rarely found cases where I thought that they made sense, and I gather that some folks out there use the singleton pattern way too much (I've heard it suggested that it's because it was one of the few design patterns from the design pattern book that was easy). In fact, one of my coworkers was telling me at one point about how someone had argued to him about how a "doubleton" pattern made sense, which just seems crazy to me, but I've found that a disturbingly large percentage of programmers are not what I would consider competent. I think that the singleton pattern should be used when it really makes sense to use it, but in most cases, there's no reason to restrict the type to a singleton. And I expect that the dislike for singletons comes from them being used far too often when it clearly made no sense. The one place that I can think of that I've used singletons in the last decade or so is with the LocalTime and UTC classes for time zones (both in std.datetime and in the C++ version that I wrote for work at one point). Having multiple instances of those classes made no sense and would have been pointlessly inefficient. But at the moment, that's the only case I can think of where I've used singletons. They just don't make sense very often. - Jonathan M Davis
Replace import expression with intrinsic
In case it didn't get enough visibility: https://issues.dlang.org/show_bug.cgi?id=1985#c11 give your opinion. Not sure if a better disruption management is desired for a possibly low profit change, e.g. it can have a long grace period.
Re: Speed of math function atan: comparison D and C++
On Tue, Mar 06, 2018 at 06:05:59PM +, jmh530 via Digitalmars-d-learn wrote: > On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote: > > [snip] > > > > I'm not advocating for getting *rid* of 80-bit float support, but > > only to make it *optional* rather than the default, as currently > > done in std.math. [...] > Aren't there two issues: 1) std.math functions that cast to real to > perform calculations, 2) the compiler sometimes converts things to > real in the background when people don't want it to. > > Number 1 seems straightforward to fix. Introduce new versions of the > std.math functions for float/double and the user can cast to real if > the additional accuracy is necessary. The fix itself may be straightforward, but how to do it without breaking tons of existing code and provoking user backlash is the tricky part. > Number 2 would require a compiler switch, I imagine. It may not always be the compiler's fault. In the case of x87, it's the hardware itself that internally promotes to 80-bit and truncates later. IIRC, the original intent was that user code would only deal with 64-bit, and the 80-bit stuff would only happen inside the x87 (C, for example, does not provide direct access to this type, except via vendor extensions). However, due to the necessity to be able to save intermediate computational states, there are instructions that can load/extract 80-bit intermediate values to/from the x87, and eventually people ended up just using these instructions for working with the 80-bit type directly. You can suppress the compiler from issuing these instructions, but 64-bit doubles may still be internally converted by the hardware to 80-bit intermediate values during computation. But I suppose you could force the compiler to use SSE instructions for double operations instead of x87, then it would bypass the 80-bit intermediate values completely. T -- Being able to learn is a great learning; being able to unlearn is a greater learning.
Re: mysql-native v2.1.0
On Tuesday, 6 March 2018 at 18:31:08 UTC, bauss wrote: On Saturday, 3 March 2018 at 07:37:38 UTC, Nick Sabalausky (Abscissa) wrote: [...] I'm unsure how I'd go about implementing prepared statements in a vibe.d application correctly. [...] Like more specifically do I still call lockConnection() on a MySQLPool?
Re: How to use globals correctly?
On Monday, 5 March 2018 at 19:51:33 UTC, Steven Schveighoffer wrote: On 3/5/18 2:25 PM, Marc wrote: Can __gshared be used instead of static in the singleton pattern? I, comming from C++, ignorantly, have never used _gshared so I went to static instead of (being static also means thread-safe, as far I know)... static in D is thread safe, because it's thread-local. __gshared is shared between threads, so it's not thread safe, but has the exact same type as just static data. Can you use it for singleton? Sure, classic singleton is shared between threads. But using thread-local data, you can solve the singleton problem in a better way: https://wiki.dlang.org/Low-Lock_Singleton_Pattern Note, it still uses __gshared, which means it doesn't protect you from race conditions when you actually USE the singleton object. This means you need some synchronization inside the methods. -Steve Singletons are always smelly code tbh. Especially in D with thread-local storage. I can't think of a situation where you truly need singletons in D.
Re: Advent of D
On 3/6/18 11:09 AM, Jordi Gutiérrez Hermoso wrote: I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/ I really enjoyed this. Thank you!
Re: Article: Why Const Sucks
On 3/6/18 10:39 AM, Jonathan M Davis wrote: Yeah. If you're dealing with generic code rather than a specific range type that you know is implicitly saved when copied, you have to use save so often that it's painful, and almost no one does it. e.g. equal(lhs.save, rhs.save) or immutable result = range.save.startsWith(needle.save); Yep. The most frustrating thing about .save to me is that .save is nearly always implemented as: auto save() { return this; } This just screams "I really meant just copying". -Steve
[Issue 1985] import expression should return ubyte[] not string
https://issues.dlang.org/show_bug.cgi?id=1985 anonymous4changed: What|Removed |Added Keywords||spec --
[Issue 1985] import expression should return ubyte[] not string
https://issues.dlang.org/show_bug.cgi?id=1985 --- Comment #11 from anonymous4--- I think it's better to replace import expression with intrinsic, say, importText (like std.file.readText). This will also reduce grammar complexity and remove second and rarely used meaning from the import keyword. Due to how rarely import expression is used it confuses newcomers that are used only to it's usage as module import statement. --
[Issue 17448] Move semantics cause memory corruption and cryptic bugs
https://issues.dlang.org/show_bug.cgi?id=17448 --- Comment #26 from Eyal--- What solution is there for this use-case then? We need objects to register themselves (i.e: set out-of-scope pointers to point at them) and RAII-wise have them de-register themselves. While they are registered, we need a guarantee that they won't be moved. Doesn't sound like D has any solution for us here? 1) We can't use classes, because: 1.A) they are hard to use without GC 1.B) cannot reasonably nest classes so they re-use the same allocation as the container class 1.C) cannot easily allocate them on the stack 2) We can't use structs, because there's no way to make sure structs aren't moved when they're registered. In my experience, this use-case of registered objects is extremely common. Immovable structs, even if those require some effort, sound like they should be well worth virtually any effort they'd require. In practice, we use structs for this, and we don't really have a choice so we'll keep using structs. But D is fighting us here, instead of helping us. --
Re: Article: Why Const Sucks
On Tue, Mar 06, 2018 at 11:20:56AM -0700, Jonathan M Davis via Digitalmars-d-announce wrote: > On Tuesday, March 06, 2018 09:41:42 H. S. Teoh via Digitalmars-d-announce > wrote: > > As they say, hindsight is always 20/20. But it wasn't so easy to > > foresee the consequences at the time when the very concept of ranges > > was still brand new. > > Except that even worse, I'd argue that hindsight really isn't 20/20. > We can see a lot of the mistakes that were made, and if we were > starting from scratch or otherwise willing to break a lot of code, we > could change stuff like the range API based on the lessons learned. > But we'd probably still screw it up, because we wouldn't have the > experience with the new API to know where it was wrong. [...] Well, that means *hind*sight is still 20/20: we see where we went wrong, but *fore*sight is still blurry, because what we think is the solution to that wrong may not turn out to be a good solution later. :-D T -- Question authority. Don't ask why, just do it.
Re: Article: Why Const Sucks
On Tuesday, March 06, 2018 09:41:42 H. S. Teoh via Digitalmars-d-announce wrote: > As they say, hindsight is always 20/20. But it wasn't so easy to > foresee the consequences at the time when the very concept of ranges was > still brand new. Except that even worse, I'd argue that hindsight really isn't 20/20. We can see a lot of the mistakes that were made, and if we were starting from scratch or otherwise willing to break a lot of code, we could change stuff like the range API based on the lessons learned. But we'd probably still screw it up, because we wouldn't have the experience with the new API to know where it was wrong. Consider all of the stuff that was improved in D over C++ but which still has problems in D (like const). We build on experience to make the new stuff better and frequently lament that we didn't know better in the past, but we still make mistakes when we do new stuff or redesign old stuff. Frequently, the end result is better, but it's rarely perfect. - Jonathan M Davis
Re: I have a patch to let lldb demangle D symbols ; help welcome to improve it
On Friday, 2 March 2018 at 00:17:13 UTC, Timothee Cour wrote: yes, I've fixed the issue with crashes on large symbols using a patched `demangle` ; will update code soon; but feel free to take a look at lldb side of things What version of LLVM did you base it on? On my LLVM fork for RISC-V and MSP430 work it doesn't build (no llvm/Support/DJB.h) and on the latest stable, 5.0.1, cmake fails to configure (Unknown CMake command "add_llvm_install_targets").
Re: Article: Why Const Sucks
On Tuesday, March 06, 2018 09:36:43 H. S. Teoh via Digitalmars-d-announce wrote: > Andrei has said before, and probably on more than one occasion, that if > he were to redesign ranges today, one of the things he would do > differently was to change the definition of forward range so that .save > is basically implicit on copying the range object, and non-forward input > ranges would just be reference / non-copyable types. > > But that boat has long sailed, and we just have to make do with what we > have today. Changing this now will literally break just about *every* D > program that uses ranges, which is breakage of an ecosystem-killing > magnitude that I can't even contemplate. I would much rather go with a > less intrusive breakage like killing autodecoding with fire, than with > something that will basically require me to rewrite practically every D > program I ever wrote. I'm not actually convinced that killing auto-decoding is really much better. As it stands, changing it would break a large percentage of string-based code, and the functions in question sit in std.range.primitives along with all of the other core range stuff such that I don't see how we can change them any more than we can change the basic range API. I would love to be proven wrong, but I don't know how we could change it at this point without code breakage that comes pretty close to the breakage that changing the range API would cause. - Jonathan M Davis
[Issue 18561] postblit should allow writing const/immutable members just like constructors
https://issues.dlang.org/show_bug.cgi?id=18561 --- Comment #3 from anonymous4--- This passes: --- struct A { int a; this(int b) const { a=b; } } int main() { const A a; assert(a.a==0,"0"); a.__ctor(1); assert(a.a==1,"1"); return 0; } --- --
Advent of D
I wrote a blog post about working on Advent of Code in D. You can read it here: http://jordi.inversethought.com/blog/advent-of-d/
Re: Speed of math function atan: comparison D and C++
On Tuesday, 6 March 2018 at 17:51:54 UTC, H. S. Teoh wrote: [snip] I'm not advocating for getting *rid* of 80-bit float support, but only to make it *optional* rather than the default, as currently done in std.math. T Aren't there two issues: 1) std.math functions that cast to real to perform calculations, 2) the compiler sometimes converts things to real in the background when people don't want it to. Number 1 seems straightforward to fix. Introduce new versions of the std.math functions for float/double and the user can cast to real if the additional accuracy is necessary. Number 2 would require a compiler switch, I imagine.
Fetch and pre-build dub dependencies
I have a Dockerfile to build a vibe.d project. Docker has a nice caching system so it continues building the docker image from the step where it's needed when something changes. This is typically at the step of adding my source files, then building the binary. The problem is that fetching and building vibe dependencies takes a lot of time every time some source files of mine changes. I can pre-fetch dub dependencies, although it's a bit cumbersome as fetch doesn't load dependencies of the given package. RUN dub fetch vibe-d --cache=system RUN dub fetch vibe-core --cache=system RUN dub fetch eventcore --cache=system But there's no easy way to build these dependencies before I add my project source files to the docker image. If I could do that the docker build process would be tremendously faster, as it would be simply skipped automatically by the Docker cache system. Currently 99% of the time spent on building the dependencies when i am creating a docker image. (I have to use ldc for ARM, which is slower.) Is there an easy way to fetch and prebuild a dub package dependencies? something like "dub fetch-and-build vibe-d --recursive --cache=system"
Re: What's the proper way to add a local file dependence to dub?
On 2018-03-04 17:46, Marc wrote: then copy it to sources folder? let's say I have a small library folder at C:\mylibrary\D where I want to use dir.d from it. How do I add that file dependence to dub? But I do not want to that file be passed directly to dmd, I want to that file be copied to application's source folder (so it's easy to distribuite, with the dependences together as possible) then compiled. So, what I want to some extension is dub work with loca files. Is this possible to do solely with dub? I know I can easily write a script to run before dub which copies the dependence files from C:\mylibrary to application's source but I'm looking for a more elegant approach as possible; I'm afraid of rewriting a makefile-like soon (I find cmake/make/makefiles just ugly). You can use "preGenerateCommands" or "preBuildCommands" to run arbitrary commands before Dub builds the project [1]. Alternativly you can use the "import" expression [2], together with the "stringImportPaths" Dub build setting. The "import" expression will embed the file into the executable as a string literal. [1] https://code.dlang.org/package-format?lang=sdl#build-settings [2] https://dlang.org/spec/expression.html#import_expressions -- /Jacob Carlborg
Re: Is it possible to return the subclass from a method of the parent class in dlang?
On 2018-03-02 21:23, Christian Köstlin wrote: To give an example: class Thread { ... Thread start() {...} } class Timer : Thread { ... } void main() { // Timer timer = new Timer().start; // this does not work auto timer = new Timer().start; // because timer is of type Thread } You can also try a template this parameter [1] in the base class: class Thread { T start(this T) () { ... } } But if this "Thread" is core.thread.Thread that won't work. [1] https://dlang.org/spec/template.html#template_this_parameter -- /Jacob Carlborg
Re: Speed of math function atan: comparison D and C++
On Tue, Mar 06, 2018 at 08:12:57AM +0100, Robert M. Münch via Digitalmars-d-learn wrote: > On 2018-03-05 20:11:06 +, H. S. Teoh said: > > > Walter has been adamant that we should always compute std.math.* > > functions with the `real` type, which on x86 maps to the non-IEEE > > 80-bit floats. However, 80-bit floats have been deprecated for a > > while now, > > Hi, do you have a reference for this? I can't believe this, as the > 80-bit are pretty important for a lot of optimization algorithms. We > use it all the time and it's absolutly necessary. [...] http://www.zdnet.com/article/nvidia-de-optimizes-physx-for-the-cpu/?tag=nl.e539 Quotation: Intel started discouraging the use of x87 with the introduction of the P4 in late 2000. AMD deprecated x87 since the K8 in 2003, as x86-64 is defined with SSE2 support; VIA’s C7 has supported SSE2 since 2005. In 64-bit versions of Windows, x87 is deprecated for user-mode, and prohibited entirely in kernel-mode. Pretty much everyone in the industry has recommended SSE over x87 since 2005 and there are no reasons to use x87, unless software has to run on an embedded Pentium or 486. I'm not advocating for getting *rid* of 80-bit float support, but only to make it *optional* rather than the default, as currently done in std.math. T -- Once bitten, twice cry...
Re: Article: Why Const Sucks
On Mon, Mar 05, 2018 at 10:21:47PM -0500, Nick Sabalausky (Abscissa) via Digitalmars-d-announce wrote: > On 03/05/2018 12:38 PM, H. S. Teoh wrote: > > > > This broke the by-value assumption inherent in much of Phobos code, > > Wait, seriously? Phobos frequently passes ranges by value? I sincerely > hope that's only true for class-based ranges and forward-ranges (and > more specifically, only forward ranges where copying the range and > calling .save are designed to do the exact same thing). Otherwise, > that's really, *REALLY* bad since non-forward ranges *by definition* > cannot be duplicated. I think you misunderstood. :-D Passing ranges by value means passing the range itself, usually a struct, which is a value type. I did *not* say the *content* of ranges are *copied* -- that would be so horribly wrong that I would be thinking twice about using D for my projects. :-D [...] > The definition of "what is a forward/non-forward range" for > struct-based ranges should have been "is this() @disabled (non-forward > range), or is this() enabled *and* does the same thing as .save > (forward range)?" [...] Yeah, Andrei has admitted before that this is probably what he would do today, if he were given a second chance to design ranges. But at the time, the landscape of D was rather different, and certain language features didn't exist yet (sorry, can't recall exactly which off the top of my head), so he settled with the compromise that we have today. As they say, hindsight is always 20/20. But it wasn't so easy to foresee the consequences at the time when the very concept of ranges was still brand new. T -- What do you get if you drop a piano down a mineshaft? A flat minor.
#dbugfix Issue 15984
[REG2.071] Interface contracts retrieve garbage instead of parameters https://issues.dlang.org/show_bug.cgi?id=15984 This regression from 2016 causes random crashes if you use one of the key features of D - Contract Programming.