Re: Release D 2.087.0
On Monday, 15 July 2019 at 20:57:59 UTC, Johannes Pfau wrote:
I don't see how "should be made public" can be interpreted as
"should be installed", especially considering that templates
need source code installed (core.internal), but that's
completely orthogonal to what functions should be private
(core.internal) / public to users of druntime.
However, I'll open a PR to clarify that paragraph.
Yes, clarifying that paragraph is a good idea. The intended
meaning used to be unambiguous especially given this part:
"If a public module consists of a header file and an
implementation file (which are both maintained by hand) then it
is OK to import private modules in the implementation file."
This refers to the fact that some modules (object, core.thread)
used to have hand-written .di files to separate the public
interface from the implementations (which made use of rt.*
imports).
Now that those duplicate .di files have (fortunately!) been done
away with, I can see how the wording could be unclear without
that prior knowledge. And in either case, avoiding to use heavily
overloaded terms ("private"/"public") without further explanation
is a good idea.
This split has been in place since back in the D1/Tango days.
Sure, the core vs rt split did. But core.internal did not exist
in D1.
How core is organised internally has little do with whether rt is
public or not.
— David
Re: Release D 2.087.0
On Monday, 15 July 2019 at 20:27:16 UTC, Johannes Pfau wrote: I guess this should be documented somewhere then. See druntime/CONTRIBUTING.md: ``` In general, only modules in the 'core' package should be made public. The single exception is the 'object' module which is not in any package. The convention is to put private modules in the 'rt' or 'gc' packages depending on what they do and only put public modules in 'core'. Also, always avoid importing private modules in public modules. […] ``` This split has been in place since back in the D1/Tango days. — David
Re: Release D 2.087.0
On Monday, 15 July 2019 at 19:41:11 UTC, Johannes Pfau wrote: And duplicating extern(C) declarations, syncing them manually, ... is a safety liability and maintainance nightmare (see my other post). So in no way should we start to add more such functions interfacing rt to core.internal. core.internal.traits.externDFunc takes care of the safety aspect. This is a non-issue. (Interdependencies should be avoided regardless, of course; it is still just a crutch.) — David
Re: Release D 2.087.0
On Monday, 15 July 2019 at 14:00:23 UTC, Mike Franklin wrote: I'm sorry it broke digger, but digger is not how we typically build DMD, druntime, and Phobos. It also breaks the LDC build system. Just shipping rt.* too by itself would be simple, but as the frontend takes various libraries when referring to rt symbols internally (using types that don't match, etc.), compiling code that uses certain parts of rt.* at the same time as rt.* itself leads to non-obvious breakage. The easiest way of making sure this doesn't happen is to just not ship rt.*. Either way, there is a simple resolution here: Put new template code or other artefacts that are actually used via import in core.* (e.g. core.internal.*). This also provides a natural boundary between legacy code and the new runtime interface. If more and more code gets template-ised, rt.* will slowly wither away, but there is nothing wrong with that. At some point, it will just cease to exist naturally. — David
Re: Release D 2.087.0
On Monday, 15 July 2019 at 19:52:57 UTC, David Nadlinger wrote: On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote: My understanding is the `rt` is the language implementation and `core` is the low level library for users. This understanding would be mistaken. We haven't been shipping `rt` on the import path for a long time. `core.internal` exists precisely to fill this role, i.e. code that needs to be around at druntime import time, but isn't supposed to be accessed directly by users. (Corollary: This should be fixed in a point release to unbreak various tooling and dependent build systems.)
Re: Release D 2.087.0
On Monday, 15 July 2019 at 11:33:44 UTC, Mike Franklin wrote: My understanding is the `rt` is the language implementation and `core` is the low level library for users. This understanding would be mistaken. We haven't been shipping `rt` on the import path for a long time. `core.internal` exists precisely to fill this role, i.e. code that needs to be around at druntime import time, but isn't supposed to be accessed directly by users. — David
Re: Looking for a mentor for SAoC
On Monday, 27 August 2018 at 20:47:08 UTC, Stefam Koch wrote: generating it is not the problem but linking it on windows currently requires the MS linker. Is that true, though? DMD ships with LLD these days. — David
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 22:53:44 UTC, Walter Bright wrote:
On 8/25/2018 2:46 PM, David Nadlinger wrote:
At least for the transition period, I'd have attributes only
apply to the user-specified code and infer them for the actual
full constructor. (We can still print a deprecation warning if
they don't match.) —David
Inferring is not good enough, for example:
https://github.com/dlang/dmd/pull/6816#issuecomment-307972790
There the @safe constructor is calling a destructor that calls
free(). It can't be inferred as @safe.
How did you interpret "only apply to the user-specified code"? In
this example, the `@safe` in `this() @safe {}` would only apply
to `{}`.
This necessitates being careful with the error message in a case
like this
struct UnsafeDtor { @system ~this() {} }
struct Foo {
UnsafeDtor ud;
this(int a) @safe {
if (!a) throw Exception("boo");
}
}
void bar() @safe {
auto f = Foo(1);
}
as just printing "cannot call @system constructor" would be a bit
misleading. It should work without surprises otherwise, though,
and can be supplemented with deprecation warnings if the
specified "inner" and inferred "outer" attributes don't match.
—David
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 20:52:06 UTC, Walter Bright wrote: If I fix the bug, I break existing code, and apparently a substantial amount of existing code. What's your advice on how to proceed with this? At least for the transition period, I'd have attributes only apply to the user-specified code and infer them for the actual full constructor. (We can still print a deprecation warning if they don't match.) —David
Re: D is dead
On Friday, 24 August 2018 at 03:53:38 UTC, David Nadlinger wrote: […] All this is not to say that nothrow constructors aren't a good idea, though. This was meant to say nothrow DEstructors, as hopefully obvious from context. —David
Re: D is dead
On Thursday, 23 August 2018 at 23:06:00 UTC, Ethan wrote: Is that actually true, or would handling exceptions within the constructor allow one to initialise the object to an invalid state and thus still follow RAII paradigms correctly? If you end up needing to check for that uninitialised state in all the other member functions for correctness (to avoid operating on invalid pointers/handles/…), that's a imho bastardisation of RAII that destroys most of the benefits. Also, how do you inform the client code that something went wrong internally? Most likely, you'd want to construct the objects internally and pass them into the constructor to get around that; hence the composability argument. The amount of bugs and pain I've had to deal with in production code because of throwing constructors makes me lean more towards Walter's viewpoint here. What was the root cause of these issues? Why can't RAII objects do the same if it performs operations it *knows* throw exceptions? Apart from the above argument, this would require making all constructors implicitly nothrow to avoid degrading into faith-based programming. — David
Re: D is dead
On Thursday, 23 August 2018 at 23:27:51 UTC, Walter Bright wrote: D deals with it via "chained exceptions", which is terrifyingly difficult to understand. If you believe it is understandable, just try to understand the various devious test cases in the test suite. I don't think that assessment is accurate. Yes, I ported EH to a few new targets and wrote the first correct implementation of exception chaining for LDC, so I'm probably a couple of standard deviations off the average D user in that regard. But said average D user doesn't care about most of the nuances of this problem, like the details of implementing exception chaining without allocating too much, or which exceptions take precedence in various intentionally twisted test cases. What they do care about is that the fact that an error has occurred is propagated sensibly in all cases without requiring extra attention, and that information as to the origin is not lost (hence chaining rather than just replacement). Heck, the fact that we still don't have default backtrace handlers that consistently work on all platforms is probably a much bigger problem than the minutiae of exception chaining behaviour. All this is not to say that nothrow constructors aren't a good idea, though. ——— 1) They are expensive, adding considerable hidden bloat in the form of finally blocks, one for each constructing field. These unwinding frames defeat optimization. […] This cost is inherent to the problem, at least as long as exceptions are used to represent the error conditions in question in the first place. Whether the potentially throwing operations are performed in the constructor or in another method, either way the object will need to be destructed and all preceding initialisation steps undone when an error occurs. 2) The presence of constructors that throw makes code hard to reason about. (I concede that maybe that's just me.) I like looking at code and knowing the construction is guaranteed to succeed. This might be just you indeed. How are constructors different than other method calls in that regard? (Granted, constructors can be called implicitly in C++.) Somehow, I've been able to use C++ for decades without needing throwing constructors. How much of what would be considered "modern" C++ code have you written in that time, as opposed to C-with-classes style? It [having a separate initialisation method]'s still RAII One might wonder about the acronym then, but whether your example should be called RAII is an entirely different debate, and one I'm not particularly interested in (I've always thought something like "Resource Release Is Destruction" or just "Scope-based resource management" would be a better name anyway). You might argue "my code cannot handle that extra check in the destructor." It's not just one extra check in the destructor. It's an extra check in every member function, to throw an exception if called on an object that has not been initialised. You might argue that these should be errors/assertions instead, and hence are not as expensive. True, but this points to another problem: Splitting up the initialisation procedure invites a whole class of bugs that would otherwise be syntactically impossible to write. There is considerable theoretical and practical beauty to the idea that as an object is accessible, it is in a valid state. (Linear/affine types, cf. Rust, show the power of this notion extended to ownership.) RAII in the conventional sense (acquisition in the constructor) effectively provides a way to encode 1 bit of typestate. By blurring the line between object initialisation and the phase where it is fully initialised, that descriptive power is lost. […] (for me) the inherently unintuitive nature of a constructor that tries to do far too much. I suppose our opinions just differ here then. To me, this is exactly what I intuitively expect a constructor to do: Create an instance of an object in a normal state. Drawing the line anywhere else, for example (implicitly) allocating memory but not initialising it to a fully usable state, seems artificial to me. 3) Much of the utility of throwing constructors in C++ comes from "what if the constructor fails to allocate memory". In D, out of memory errors are fatal, no recovery is necessary. This is unrelated to the discussion at hand, but std.experimental.allocator does allow handle allocation failure, and with good reason: It doesn't make sense to abort the program when a fixed-size local cache or a static global object pool (common in embedded programming) is exhausted. — David
Re: D is dead
On Thursday, 23 August 2018 at 17:02:12 UTC, Shachar Shemesh wrote: On 23/08/18 18:35, Joakim wrote: […] How much time or money exactly has Weka spent on getting this issue and other "critical" bugs fixed? Weka is paying prominent D developers as contractors. We've had David Nadlinger and currently employ Johan Engelen. Both said they are cannot fix this particular bug. Not to put too fine a point on this, but I don't think I've ever said I couldn't fix the bug; although I probably did mention it would be better to fix in the upstream DMD frontend than in LDC. I would be happy to have a look at it for Weka at this point, actually. — David
Re: D is dead
On Thursday, 23 August 2018 at 21:31:41 UTC, Walter Bright wrote: My personal opinion is that constructors that throw are an execrable programming practice, and I've wanted to ban them. (Andrei, while sympathetic to the idea, felt that too many people relied on it.) I won't allow throwing constructors in dmd or any software I have authority over. Throwing constructors are fundamental for making RAII work in a composable fashion. If constructors are not allowed to throw and you want to avoid manually creating a "uninitialized" state – which is error-prone and defeats much of the point of an RAII strategy –, all dependencies need to be injected externally, that is, constructed independently and then passed into the constructor. Sometimes, inversion of control is of course the right call – cf. the hype around DI –, but sometimes you'd rather cleanly abstract the implementation details away. Banning them from the language only pushes the complexity of handling semi-constructed objects into ad-hoc user code solutions, which I'd argue is worse in terms of usability and potential for bugs. I suppose you view this as advantageous because you place more weight on the language not having to explicitly deal with this scenario in the text of the specification? — David
Re: High-level vision for 2018 H2?
On Saturday, 18 August 2018 at 07:50:04 UTC, Dukc wrote: On Thursday, 16 August 2018 at 14:11:20 UTC, Andrei Alexandrescu wrote: we're working on a HOPL submission. What's HOPL? https://hopl4.sigplan.org, presumably. —David
Re: When did gdc and ldc start?
On Tuesday, 31 July 2018 at 18:21:15 UTC, Walter Bright wrote: What I'm doing is preparing a submission to HOPL on the origins of D. There's an emphasis on accuracy, references, correct dates, correct attributions, and correct credit to the right people. I'd put together a timeline for my LDC talk at DConf 2013: http://dconf.org/2013/talks/nadlinger.pdf I don't have my old notes with the NG post links handy, but the relevant announcements shouldn't be hard to find knowing the year – you'd want to cross-check them anyway. The Git history (which includes all the old SVN commits) should also be handy. As Iain mentioned, the first commit to the SVN repo was on September 1, 2007, which seems to have already compiled quite a bit of D code, judging from the test suite. — David
Re: Help with DMD internals
On Monday, 18 June 2018 at 10:19:57 UTC, Nicholas Wilson wrote: You should get in contact with Manu Evans, he's working on this as well IIRC. Might be a lonely conversation – this is a spam-bot repost of one of Manu's messages. ;) —David
Re: Encouraging preliminary results implementing memcpy in D
On Sunday, 17 June 2018 at 17:00:00 UTC, David Nadlinger wrote: core.simd.loadUnaligned instead Ah, well… https://issues.dlang.org/show_bug.cgi?id=19001 — David
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
https://github.com/JinShil/memcpyD
[…]
Feedback, advise, and pull requests to improve the
implementation are most welcome.
The memcpyD implementation is buggy; it assumes that all
arguments are aligned to their size. This isn't necessarily true.
For example, `ubyte[1024].alignof == 1`, and struct alignment can
also be set explicitly using align(N).
On x86, you can get away with this in a lot of cases even though
it's undefined behaviour [1], but this is not necessarily the
case for SSE/AVX instructions. In fact, that's probably a pretty
good guess as to where those weird crashes you mentioned come
from.
On other architectures, unaligned accesses might be outright
unsupported.
For loading into vector registers, you can use
core.simd.loadUnaligned instead (ldc.simd.loadUnaligned for LDC –
LDC's druntime has not been updated yet after {load,
store}Unaligned were added upstream as well).
— David
[1] This is applying C rules to D, where creation of unaligned
pointers is undefined behaviour. The D specification doesn't
mention
Re: Replacing C's memcpy with a D implementation
On Monday, 11 June 2018 at 03:34:59 UTC, Basile B. wrote: - default linux: https://github.com/gcc-mirror/gcc/blob/master/libgcc/memcpy.c To see what is executed when you call memcpy() on a regular GNU/Linux distro, you'd want to have a look at glibc instead. For example, the AVX2 and AVX512 implementations are in sysdeps/x86_64/multiarch/memmove-avx512-no-vzeroupper.S and sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S, as forwarded to by memmove-avx2-unaligned-erms.S and memmove-avx512-unaligned-erms.S. (Pop quiz: Why might a separate "no-vzeroupper" variant be a good idea?) — David
Re: Replacing C's memcpy with a D implementation
On Monday, 11 June 2018 at 08:02:42 UTC, Walter Bright wrote: On 6/10/2018 9:44 PM, Patrick Schluter wrote: See what Agner Fog has to say about it: Thanks. Agner Fog gets the last word on this topic! Well, Agner is rarely wrong indeed, but there is a limit to how much material a single person can keep up to date. On newer uarchs, `rep movsb` isn't slower than `rep movsd`, and often performs similar to the best SSE2 implementation (using NT stores). See "BeeOnRope"'s answer to this StackOverflow question for an in-depth discussion about this: https://stackoverflow.com/questions/43343231/enhanced-rep-movsb-for-memcpy AVX2 seems to offer extra performance beyond that, though, if it is available (for example if runtime feature detection is used). I believe I read a comment by Agner somewhere to that effect as well – a search engine will certainly be able to turn up more. — David
Re: Replacing C's memcpy with a D implementation
On Sunday, 10 June 2018 at 22:23:08 UTC, Walter Bright wrote: On 6/10/2018 11:16 AM, David Nadlinger wrote: Because of the large amounts of noise, the only conclusion one can draw from this is that memcpyD is the slowest, Probably because it does a memory allocation. Of course; that was already pointed out earlier in the thread. The CPU makers abandoned optimizing the REP instructions decades ago, and just left the clunky implementations there for backwards compatibility. That's not entirely true. Intel started optimising some of the REP string instructions again on Ivy Bridge and above. There is a CPUID bit to indicate that (ERMS?); I'm sure the Optimization Manual has further details. From what I remember, `rep movsb` is supposed to beat an AVX loop on most recent Intel µarchs if the destination is aligned and the data is longer than a few cache lines. I've never measured that myself, though. — David
Re: Replacing C's memcpy with a D implementation
On Sunday, 10 June 2018 at 12:49:31 UTC, Mike Franklin wrote: I'm not experienced with this kind of programming, so I'm doubting these results. Have I done something wrong? Am I overlooking something? You've just discovered the fact that one can rarely be careful enough with what is benchmarked, and having enough statistics. For example, check out the following output from running your program on macOS 10.12, compiled with LDC 1.8.0: --- $ ./test memcpyD: 2 ms, 570 μs, and 9 hnsecs memcpyDstdAlg: 77 μs and 2 hnsecs memcpyC: 74 μs and 1 hnsec memcpyNaive: 76 μs and 4 hnsecs memcpyASM: 145 μs and 5 hnsecs $ ./test memcpyD: 3 ms and 376 μs memcpyDstdAlg: 76 μs and 9 hnsecs memcpyC: 104 μs and 4 hnsecs memcpyNaive: 72 μs and 2 hnsecs memcpyASM: 181 μs and 8 hnsecs $ ./test memcpyD: 2 ms and 565 μs memcpyDstdAlg: 76 μs and 9 hnsecs memcpyC: 73 μs and 2 hnsecs memcpyNaive: 71 μs and 9 hnsecs memcpyASM: 145 μs and 3 hnsecs $ ./test memcpyD: 2 ms, 813 μs, and 8 hnsecs memcpyDstdAlg: 81 μs and 2 hnsecs memcpyC: 99 μs and 2 hnsecs memcpyNaive: 74 μs and 2 hnsecs memcpyASM: 149 μs and 1 hnsec $ ./test memcpyD: 2 ms, 593 μs, and 7 hnsecs memcpyDstdAlg: 77 μs and 3 hnsecs memcpyC: 75 μs memcpyNaive: 77 μs and 2 hnsecs memcpyASM: 145 μs and 5 hnsecs --- Because of the large amounts of noise, the only conclusion one can draw from this is that memcpyD is the slowest, followed by the ASM implementation. In fact, memcpyC and memcpyNaive produce exactly the same machine code (without bounds checking), as LLVM recognizes the loop and lowers it into a memcpy. memcpyDstdAlg instead gets turned into a vectorized loop, for reasons I didn't investigate any further. — David
Re: General problem I'm having in D with the type system
On Sunday, 27 May 2018 at 06:00:30 UTC, IntegratedDimensions
wrote:
[…] This is a potential suggestion for including such a feature
in the D language to provide sightly more consistency.
Solving this in the general case requires explicitly allowing,
specifying, and tracking covariance and contravariance relations
throughout the type system.
Object-oriented programming in the usual sense only models arrows
in one direction – covariance of return types (and possibly
contravariant argument types). As far as I'm aware, there is
little more useful to be done without making both compile-time
and run-time representations (i.e., type system and memory
layout) significantly more complex.
The only problem where it can leak is when we treat an cat as
an animal then put in dog food in to the animal, which is valid
when cat as treated as an animal, then cast back to cat. […]
But I've already pointed out two things about this: 1. The
hierarchy is maintained to be non-leaky at runtime(I never down
cast). […]
Even without explicit downcasts, there are still implicit upcasts
and covariant `this` pointers. Consider this:
---
class Food;
class Catfood : Food;
class Animal { Food f; void eat() { /+ eat f +/ } }
class Cat : Animal { Catfood : Food f; override void eat() { /+
eat f +/ } }
Animal a = new Cat;
a.f = new Food;
a.eat(); // calls Cat.eat()
---
As per your problem statement, given a (this) pointer of type Cat
– such as in Cat.eat() –, you'd presumably want `f` to be of type
Catfood. However, as shown, this is incompatible with Cat being a
subtype of Animal.
Haskell can handle these situations just fine.
Haskell also (mostly) lacks subtyping and mutable data.
–––
In general, this is a fun problem to think about – at least if
one does not expect to (quickly) come up with generic solutions.
Given your Haskell background, you might enjoy having a look at
what Scala and others have done with generics for an illustration
of what makes this tricky in an OOP environment.
As for D, I'd recommend taking a closer look at what your actual
design requirements are. If you don't require the full
flexibility of arbitrary co-/contravariance relations on an
unrestricted set of types, it is likely that you can brew your
own subtyping system with template magic to provide exactly the
required structure and behaviour. Template application is
invariant, so you have full freedom to allow precisely those
conversions you want to exist. The implementation will involve
structs that internally cast unrelated pointers, but that can be
hidden from the interface. You can always package this up as a
library if you succeed in making it generally useful.
— David
Re: Of possible interest: fast UTF8 validation
On Wednesday, 16 May 2018 at 14:48:54 UTC, Ethan Watson wrote: And even better - LDC doesn't support core.simd and has its own intrinsics that don't match the SSE/AVX intrinsics API published by Intel. To provide some context here: LDC only supports the types from core.simd, but not the __simd "assembler macro" that DMD uses to more or less directly emit the corresponding x86 opcodes. LDC does support most of the GCC-style SIMD builtins for the respective target (x86, ARM, …), but there are two problems with this: 1) As Ethan pointed out, the GCC API does not match Intel's intrinsics; for example, it is `__builtin_ia32_vfnmsubpd256_mask3` instead of `_mm256_mask_fnmsub_pd`, and the argument orders differ as well. 2) The functions that LDC exposes as intrinsics are those that are intrinsics on the LLVM IR level. However, some operations can be directly represented in normal, instruction-set-independent LLVM IR – no explicit intrinsics are provided for these. Unfortunately, LLVM doesn't seem to provide any particularly helpful tools for implementing Intel's intrinsics API. x86intrin.h is manually implemented for Clang as a collection of various macros and functions. It would be seriously cool if someone could write a small tool to parse those headers, (semi-)automatically convert them to D, and generate tests for comparing the emitted IR against Clang. I'm happy to help with the LDC side of things. — David
Re: Benchmark Game
On Saturday, 19 May 2018 at 01:15:10 UTC, RhyS wrote: More then worth the effort because its used a lot when discussions are ongoing regarding languages like Go, C, ... Its one of the best form of free advertisement. D used to be there, but at some point was at the maintainer's whim for no specific reason. Isaac has acknowledged the arbitrariness of (t)his decision multiple times, and is usually quick to add, "but you can host your own copy". Of course this is only true in a very literal sense – our own copy wouldn't get nearly the same exposure than his "official" one. Still, it would be useful to have a page comparing optimized D results with C/C++, as the Benchmarks Game still enjoys quite a bit of popularity despite the maintainer's antics. — David
Re: Wait-free MPSC and MPMC implement in D
On Wednesday, 9 May 2018 at 04:17:17 UTC, Shachar Shemesh wrote: On 09/05/18 01:09, David Nadlinger wrote: The algorithm isn't wait-free (haven't thought too carefully about this, though) This mirrors a discussion I had with Maor (who originally wrote it). Let's see if I bring you around the way I was brought around. Ah, and I've been taking Liran to be the originator of this fine piece of work up to now… ;) At the API level, there are two areas where the algorithm *cannot* be wait free. If a consumer tries to consume from an empty queue, or a producer tries to produce to a full one. True, but some applications might favour APIs which can provide these guarantees by blocking instead of aggressively early-returning. For example, one could use a helping scheme to implement a MPSC queue that doesn't starve any producers even if the queue is close to full, or a SPMC queue that doesn't starve any consumers even if the queue is close to empty. Those two aside […] the algorithm actually is wait free. Is it, though? If we assume the usual definition of wait-freedom (bounded number of steps for each thread to make progress), then MCSPQueue.pop() is problematic, as any one thread could get persistently unlucky with the cas(). This could also be the case in the steady state with a non-empty queue; for example, if the producer pushes elements at a rate matching that at which (n - 1) of n consumer threads pop them. I'd need to think more carefully about the non-sequentially-consistent isFull() before making any statements about SCMPQueue. — David
Re: LDC 1.10.0 beta
On Monday, 14 May 2018 at 18:31:13 UTC, Jacob Carlborg wrote: Out of curiosity, how come the Objective-C integration seem to always lack behind when LDC merges a new DMD release with some new Objective-C integration? Is it less prioritized, not so much knowledge in this area, something else? Basically all of the latter – many of us LDC devs are not really interested in the Objective-C integration for our own/company use, and kinke (who has been doing virtually all of the frontend merging work lately) IIRC doesn't have access to an OS X box. Not breaking existing features without direct access to a target is one thing, but implementing new features off the CI only is another. Help would be very welcome, though. — David
Re: Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile
On Monday, 14 May 2018 at 11:53:44 UTC, Nick Treleaven wrote: On Monday, 14 May 2018 at 01:20:38 UTC, Jonathan M Davis wrote: Yeah. It's been discussed that it should be illegal to declare a struct or class member named init, but that change has yet to happen. https://issues.dlang.org/show_bug.cgi?id=7066 Walter and Timon have considered redefinition potentially useful. A compromise would be to require `init` and `stringof` to be `static`. That would probably prevent the accidental conflicts that arise with `init`. Well, Walter mentioned that "so far [no use cases] have materialized" in 2012, and I don't think that has changed since. @disabling .init might be an exception – although one that flirts with grey areas in the language definition –, but that could still be supported while providing useful diagnostics for other uses. — David
Re: Building a standalone druntime for LDC
On Sunday, 13 May 2018 at 13:37:06 UTC, A. Nicholi wrote: I am trying to build LDC’s druntime by itself (without phobos) […] Make says: “No rule to make target '../dmd/src/osmodel.mak'” LDC uses its own CMake-based build system for druntime/Phobos, see runtime/CMakeLists.txt I'm the main repository. The ldc-build-runtime tool streamlines (re)building certain runtime versions without having to manually manage the build process: https://wiki.dlang.org/Building_LDC_runtime_libraries —David
Re: DConf 2018 Livestream
On Thursday, 10 May 2018 at 09:11:20 UTC, Walter Bright wrote: This isn't the only time videos of my talks (and others) have been lost due to technical problems or simple screwups. I'm tired of this happening. One hopes that the contract with the respective company providing A/V services would include penalties for that case (which could be funnelled into the foundation funds). — David
Re: Wait-free MPSC and MPMC implement in D
On Wednesday, 9 May 2018 at 00:20:39 UTC, Andy Smith wrote: What's MPSP? :-) Whoops, MPMC, of course. ;) And that wasn't even the only typo; I should know better than to post while distracted… So if any D codebase has got bragging rights on the term 'industry-grade' I think this has to be one of them. So if they've copy/pasted a few comments ... meh ... I for one happy to let it slide. These guys have got bigger fish to fry :-) Oh, it's definitely industry-grade in that it is used to great effect within Weka. It's just much more of an example for an interesting algorithm than it is for "mechanical" code quality. By the way, if anyone ends up testing/benchmarking this on non-TSO CPUs, I'd be curious to hear about the results. I hope I got the memory order semantics right, but of course you don't necessarily see much of that on x86. It would also be interesting to see how bad the lack of fairness can get in synthetic test cases. — David
Re: Wait-free MPSC and MPMC implement in D
On Tuesday, 8 May 2018 at 17:20:33 UTC, Dmitry Olshansky wrote: On Tuesday, 8 May 2018 at 04:00:03 UTC, manumaster wrote: Is there some implement like this in D ? https://github.com/pramalhe/ConcurrencyFreaks/blob/master/papers/multilist-2017.pdf Look for Mecca by Wekka.io team. It has great idustry-grade lock-free implementations for both. Not very flexible but these things usually are. Are you referring to https://github.com/weka-io/mecca/blob/master/src/mecca/containers/otm_queue.d? These are SPMC and MPSC variants only, not MPSP. It is also bounded-length (power-of-two sizes only), whereas the paper mentioned implements a linked-list based version. The algorithm isn't wait-free (haven't thought too carefully about this, though), and should be used with a queue size much larger than the number of threads to make sure all of them make progress. If you are considering to use it in your projects, definitely keep an eye on the real-world performance in the beginning (but then, if you weren't, you wouldn't be reaching for something like this anyway). There are a few interesting points about the algorithm in this respect; for example, the availability of queue space is checked with loads that use only raw memory order, as changes typically appear fast enough across cores on x86 anyway. If your use case is similarly enough to Weka's, it is indeed very highly optimised, though. As far as industry-grade goes, note that many of the comments have not been updated since a previous combined implementation for SPMC/MPSC was split up into two types, so there is quite a bit of stale cruft around. — David
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 20:32:05 UTC, Seb wrote: On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila FYI people have been fighting with this for a long time: https://github.com/dlang/druntime/pull/1316 FYI this appears to work just fine in Calypso: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d — David
Re: that is bug?
On Saturday, 7 April 2018 at 09:07:48 UTC, sdvcn wrote: true?stt="AA":stt="BB";-///Out:BB writeln(stt); As I just pointed out in Ali's bug report [1], this is correct, as true ? stt = "AA" : stt = "BB" means (true ? (stt = "AA") : stt) = "BB", in accordance to D's grammar [2]: AssignExpression: ConditionalExpression ConditionalExpression = AssignExpression […] We should probably require explicit parentheses here. Relying on this behaviour is just asking for trouble anyway, as evidenced by the amount of confusion in this thread. — David [1] https://issues.dlang.org/show_bug.cgi?id=18743 [2] https://dlang.org/spec/expression.html#assign_expressions
Re: that is bug?
On Saturday, 7 April 2018 at 21:22:07 UTC, kdevel wrote: Can the ternary conditional even be used to assign objects of the wrong type? […] Congratulations, I'm pretty sure you found an actual bug, even though it doesn't have anything to do with the conditional operator per se: https://issues.dlang.org/show_bug.cgi?id=18744 — David
Re: How to build static linked executable
On Tuesday, 20 March 2018 at 10:37:55 UTC, zunkree wrote: On Sunday, 18 March 2018 at 14:36:04 UTC, Jacob Carlborg wrote: FYI, -static is not support on macOS. So, how to build static binary for macOS? Static binaries aren't really supported by Apple (anymore). What do you need it for? — David
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote: Are there ways to reduce this to below 0.1s, or should I just leave idiomatic D and make a betterC program? The best solution would be to profile the startup process and file a bug accordingly. ;) — David
Re: Does the compiler inline the predicate functions to std.algorithm.sort?
On Sunday, 18 March 2018 at 14:15:37 UTC, Stefan Koch wrote: On Sunday, 18 March 2018 at 12:59:06 UTC, tipdbmp wrote: I can't read assembly but it seems to me that it doesn't: https://godbolt.org/g/PCsnPT I think C++'s sort can take a "function object" that can get inlined. Correct it does not get in-lined. Even with -O3 it does not. The reason is that the code the sort instantiation produces is too big for the inliner cost function. If you have a look at the the cg file produced when you specify -vcg-ast you can see that it's a massive amount of code. I believe the original poster was asking about the *predicate* to sort, which is indeed inlined with optimizations on. (@tipdbmp: The string gets turned into the function _D3std10functional__T9binaryFunVAyaa5_61203c2062VQra1_61VQza1_62Z__TQBvTiTiZQCdFNaNbNiNfKiKiZb. No references to it remain with -O3; the LLVM IR obtained with -output-ll might be easier to read than assembly.) — David
Re: Convert output range to input range
On Friday, 16 March 2018 at 07:57:04 UTC, John Chapman wrote: I need to write to a range created with outputRangeObject, then read from it. Is there a way to convert it to an input range? Could you illustrate your problem a bit further? In the literal sense, converting from an output to an input range would require using coroutines (where .empty() blocks until the output range has supplied the next element). However, I suspect what you want to do is to write results from the output range to a buffer (e.g. an Appender) first, and after that – or possibly every so often in chunks – process the results further? — David
Re: Vision document for H1 2018
On Thursday, 15 March 2018 at 10:48:45 UTC, Radu wrote: You have to remember that the really big first client of betterC(++) was DMD, porting DMD from C++ was a big undertaking. Right now both DMD and LDC use a form of betterC, so it is critical to have it finalized. This is entirely wrong. DMD and LDC rely extern(C++), but this has nothing to do with -betterC whatsoever. Both compilers link and initialise the runtime as normal (and then disable the GC at runtime). — David
Re: Is the following well defined and allowed?
On Thursday, 1 March 2018 at 14:54:41 UTC, Shachar Shemesh wrote: I.e. - is it well defined to copy between overlapping slices? No: https://dlang.org/spec/arrays.html#overlapping-copying —David
Re: OT: Photo of a single atom by David Nadlinger wins top prize
On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote: David (aka klickverbot) is a longtime D contributor […] … who is slightly surprised at the amount of media interest this has attracted. ;) — David
Re: proposal: heredoc comments to allow `+/` in comments, eg from urls or documented unittests
On Monday, 12 February 2018 at 22:35:23 UTC, Walter Bright wrote: I take it dstep spawns the clang compiler? It embeds the Clang frontend, which is designed to be usable as a library. — David
Re: My choice to pick Go over D ( and Rust ), mostly non-technical
On Monday, 5 February 2018 at 22:02:09 UTC, Boris-Barboris wrote: Oh, and look what I just found: https://github.com/rust-lang/rust/issues/26179 Oh, look: https://github.com/ldc-developers/druntime/blob/7b77937c70b4aba720e98727dcaad3323c29bd8d/src/ldc/intrinsics.di#L579-L587 — David
Re: Terminating multiple processes
On Thursday, 1 February 2018 at 11:42:32 UTC, Russel Winder wrote: The problem is actually a thread blocked in an inotify blocking read. As both Steven and yourself have pointed out I am going to have to use a timeout to check the state of the application. There are better solutions (select/...), But couldn't you in theory just send a custom signal to the thread (which you ignore), and then check for the exit flag after the syscall returned EINTR? The DInotify wrapper might of course have the retry loop hardcoded; I didn't check. —David
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 13:03:21 UTC, Mike Parker wrote:
https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/
In normal D code, struct destructors are executed when an
instance goes out of scope. This is handled by DRuntime, […]
This is slightly inaccurate. Regular stack cleanup doesn't
involve the runtime at all; druntime only comes into play for
exception handling. Since destructors also need to be run when
the scope is left by an exception, they are implemented via `try
{} finally {}` internally. The EH part of these depends on
druntime, but not the regular path.
One of the seemingly obscure features dependent upon DRuntime
is the ModuleInfo type. It’s a type that works quietly behind
the scenes as one of the enabling mechanisms of reflection and
most D programmers will likely never hear of it.
This is somewhat confusingly worded as well. It's actually mostly
the other way around – druntime depends on ModuleInfo to be
emitted, crucially for static constructor, destructors and unit
tests to be run. At least without shared libraries in the
picture, it would be fairly easy to manually look up the set of
ModuleInfos in a druntime-less D program.
— David
Re: Get aliased type
On Tuesday, 2 January 2018 at 11:42:49 UTC, John Chapman wrote: Because an alias of a type is just another name for the same thing you can't test if they're different. I wondered if there was a way to get the aliased name, perhaps via traits? (.stringof returns the original type.) There is indeed no way to do this; as you say, aliases are just names for a particular reference to a symbol. Perhaps you don't actually need the names in your use case, though? — David
Re: Is there a way to call scope guard without throw exception?
On Saturday, 30 December 2017 at 13:48:16 UTC, ChangLong wrote:
After fiber yield, the spoke guard is not able to execute,
unless I throw a exception in Fiber. I am look if there is
some hack method to make the fiber Interrupted at any time with
scope(exit) code executed.
There isn't. In fact, ensuring that the scope isn't left is the
whole point of fibre context switches – how else would execution
continue after the fibre is returned to? (How would objects be
"un-destroyed"?)
However, there is nothing stopping you from creating a registry
of resources yourself, and then wrapping the Fiber.yield() call
into something like:
void myYield() {
registry.releaseResources();
Fiber.yield();
registry.reacquireResources();
}
You could have the resource handles be structs that register
themselves with the registry to integrate with fibre scheduling,
and that also have a destructor to execute the cleanup when the
scope is left (like `scope(exit)`).
— David
Re: partial application for templates
On Monday, 25 December 2017 at 20:39:52 UTC, Mengu wrote:
is partially applying templates possible?
Check out std.meta.Apply{Left, Right}.
— David
Re: Does LDC support profiling at all?
On Saturday, 23 December 2017 at 12:23:33 UTC, Johan Engelen wrote: Fine grained PGO profiling: -fprofile-instr-generate http://johanengelen.github.io/ldc/2016/07/15/Profile-Guided-Optimization-with-LDC.html Function entry/exit profiling: -finstrument-functions https://github.com/ldc-developers/ldc/issues/1839 https://www.youtube.com/watch?v=LNav5qvyK7I I suspect it is not too much effort to add DMD's -profile and -profile=gc to LDC, but noone has done it yet. Another thing that is relatively easy to add to LDC: https://llvm.org/docs/XRay.html Apart from profiling based on compiler instrumentation, don't forget that LDC uses the standard object file formats/runtime libraries for the various platforms, so all the usual profiling tools like perf, VTune, Valgrind, etc. work just fine. I would usually start with one of the latter for general-purpose optimization work. — David
Re: lld status
On Thursday, 21 December 2017 at 18:40:54 UTC, Andrei Alexandrescu wrote: I heard ldc already uses its embedded variant for linking programs (on Widows? Posix? 32bit? 64bit?) Internal linking is currently enabled by a separate command-line flag; we still use the system linker by default (just as a precaution to avoid needless breakage because of a new feature). lld works for COFF, ELF as well as Mach-O. For the latter, there is the problem of locating the appropriate C runtime libraries to consider, though (those that the `gcc` linker driver implicitly passes to the underlying `ld`). Can we distribute it as an alternative to optlink? Yes, that should work. As far as I know, it doesn't support OMF, though, so we would need to find COFF C/system libraries we can redistribute - it is unclear whether Microsoft's license allows redistribution of their static libraries. - David
Re: Blog post: using dynamic libraries in dub
On Thursday, 21 December 2017 at 12:43:51 UTC, Jacob Carlborg wrote: On 2017-12-20 11:31, Benjamin Thaut wrote: Would this work in all cases? Do tls variables work across Linux shared libraries? As far as I know it works on Linux and FreeBSD, but it doesn't work on macOS. I don't know about windows. Just to clarify, that's true for for DMD only – TLS should work just fine on macOS with LDC. Do we expect all dub libraries to have correct export annotations once export goes live? No. There would probably have to be some sort of compatibility flag to avoid breaking all libraries on systems where symbols are visible externally by default (Linux, ...). — David
Re: What does rt/sections_elf_shared.d do? (Porting dmd to musl)
On Sunday, 17 December 2017 at 12:45:58 UTC, Yuxuan Shui wrote:
Although this might also be a bug on musl side: it tries to
call init functions even when RTLD_NOLOAD is passed to dlopen.
Ah, interesting. Might be worth reporting as a bug indeed;
without looking too hard, I didn't see anything to indicate that
trying to get a handle during initialization would be forbidden
(undefined behaviour/...).
However, going through sections_elf_shared.d, it makes me feel
it's doing some magic tricks with dl functions, but I don't
know what for?
The module is responsible for everything related to
loading/unloading images (that is, shared libraries and the main
executable itself) that contain D code, for those loaded at
runtime (dl{open, close}() etc.) as well as those linked into a
program or dragged in as a dependency of another shared library.
This involves registering global data and TLS segments with the
garbage collector, as you point out, but also running global and
per-thread constructors and destructors (e.g. shared static
this), running GC finalizers defined in shared libraries that are
about to be unloaded, etc.
All these things also need to work across multiple threads that
might be loading and unloading the same libraries concurrently,
and for libraries loaded indirectly as dependencies of another
shared library. These two considerations are where a lot of the
complexity comes from (since there are per-thread constructors,
libraries can be initialized on some threads but not on others,
and if a thread spawns another one, the libraries from the parent
thread should also be available in the child thread, even if the
parent thread later dies, etc.).
If that's the case, there must be simpler ways to do that.
Patches are welcome – a significant amount of work (mostly by
Martin Nowak, some by me on the LDC side of things) has gone into
this, and we have been unable to come up with a simpler solution
so far. Note that even if a less complex implementation was
indeed possible, I wouldn't expect to make such a change without
spending several days on testing and fixing the fallout due to
e.g. linker bugs. All this needs to work in a variety of
scenarios ({C, D} programs using {C, D} shared libraries at
{link, run}-time; static linking with --gc-sections, etc.).
That being said, from what I understand, D shared libraries might
not be very interesting for many users of musl libc. In that
case, you might it worthwhile to simply switch back to the old
module registration code for your target. The latter doesn't
support libraries, but is less complex. For LDC, the most general
option would be
https://github.com/ldc-developers/druntime/blob/5afd536d25ed49286d441396f75791e54a95c593/src/rt/sections_ldc.d
which requires no runtime/linker support apart from global
(static) constructors and a few widely-used magic symbols. There
are also implementations that use bracketing sections for various
other platforms. (You'll need to change the corresponding support
code in the compiler to match; for LDC switching to the old
mechanism would be a line or two, not sure about DMD.)
Also, it would be awesome if someone could write proper
documentation for this core part of druntime. I've been meaning
to draft an article about it for some quite time, but by now it
has been on my to-do list for so long that the chances I'll ever
get around to it are rather slim.
– David
Re: Is there anyway to access LLVM's 128 bit int type for C from LDC?
On Thursday, 14 December 2017 at 19:47:53 UTC, Jack Stouffer wrote: Clang has __int128. Is there anyway to use this with D with LDC? There has been some work on this a while ago, by Kai, but it hasn't been merged yet: https://github.com/ldc-developers/ldc/pull/1355 — David
Re: run.dlang.io - a modern way to run D code
On Wednesday, 13 December 2017 at 01:14:26 UTC, Seb wrote: Also the storage on the machine is limited and we can't drop an unlimited amount of Docker images there. Shouldn't the overhead from that be fairly manageable? After all, the last layer would only be as large as a single DMD/LDC installation. Surely you would have at least a few gigabytes spare on the server? — David
Re: is there any plan to support shared libraries in OSX?
On Sunday, 10 December 2017 at 21:00:08 UTC, Timothee Cour wrote: ldc has better support Just to be clear, LDC doesn't aim at incrementally "better support", but support, full stop. Granted, it has probably seen less real-world use than shared library support on Linux so there might be some bugs still, but the design should be technically sound. but we lose compile time speed of dmd It might be true that non-release builds in DMD are a bit quicker to compile, but the difference definitely isn't large enough to "render[s] many use cases impossible, preventing more widespread adoption" as you mentioned earlier. Yes, having shared library support in DMD would certainly be nice to have (given that there is already a working implementation, that shouldn't even be too difficult). But in the meantime, there is a perfectly workable alternative. —David
Re: Get pointer or reference of an element in Array(struct)
On Saturday, 9 December 2017 at 06:46:27 UTC, Arun Chandrasekaran wrote: Thanks. Just curious why reference can't be obtained here. Saves nasty null checks in most places. D simply doesn't have a (C++-style) concept of references as part of the type. Arguments can be passed by reference - hence the `ref` keyword -, but "free" references don't exist in the language. The ref in foreach loop variables can be conceptually thought of as a parameter to the loop body as well. (For opApply-based iteration, the loop body indeed gets turned into a function; for "plain" iteration the compiler AST internally has special ref variables, but they are not visible to the language.) -David
Re: -unittest doesn't work when linking against shared libraries
On Saturday, 9 December 2017 at 00:32:36 UTC, Timothee Cour wrote: They are on LDC; would be interesting to see whether the problem occurs there as well (I'm having issues with my Mac right now, so can't check myself until later). just updated bug report: same issue with ldc! Only if not linking against the shared runtime libraries, which is always required to get shared library support in LDC. (We should probably figure out a way to warn about this.) a lot of things work with shared libraries on OSX, it would be great if this worked too. It's not because shared libraries are not 100% fully officially supported that we should ignore this issue. Certain use cases are impossible without using shared libraries. Solution: Use LDC and be happy. ;) As far as partial support goes, you can't really build parts of a house without pouring the foundation first. Unit test support is one of the "upper storey" language niceties without too many cross-dependencies, but it builds on the underlying runtime machinery. Are you sure your program can work sensibly when the GC starts collecting random live objects? Or thread-local storage doesn't work from shared libraries? When module constructors aren't run? Do your tests comprehensively detect any sporadic issues with these? If you find any dylib-related bugs in LDC, it will be easily possible to fix them, since all the groundwork is in place. But you can't expect to paper over a hole in the floor and then continue to build on top of that; that is to just hack unit test support into DMD in a sensible fashion without supporting the rest of it. (Feel free to just port "my" LDC/macOS implementation to DMD, though; the hardest work has already been done, especially given Jacob's (?) recent work on native TLS for DMD.) —David
Re: @ctfeonly
On Friday, 8 December 2017 at 18:59:00 UTC, Manu wrote: Nicholas wants a *compile* error, not a link error. I don't think this is necessarily implied from the original post. Certainly, a linker error would just work fine for the original use case (avoiding unsupported codegen on compute targets). -David
Re: -unittest doesn't work when linking against shared libraries
On Friday, 8 December 2017 at 16:17:14 UTC, Jacob Carlborg wrote: Well, shared libraries are not officially support on macOS. They are on LDC; would be interesting to see whether the problem occurs there as well (I'm having issues with my Mac right now, so can't check myself until later). But yes, you can't really expect any sort of runtime infrastructure to work with shared libraries on DMD/macOS right now. -David
Re: LDC 1.6.0-beta1
On Saturday, 2 December 2017 at 15:47:23 UTC, Jacob Carlborg wrote: On 2017-12-02 13:41, kinke wrote: Nope, unfortunately still waiting for one of my compadres to create and upload the OSX package. Have you thought of automatically build and upload packages using Travis CI? That would be a good idea. Also, I uploaded the OS X package just now. (Didn't realise it wasn't built yet…). —David
Re: Note from a donor
On Friday, 17 November 2017 at 02:01:41 UTC, solidstate1991 wrote: It's filled with Assembly code, and otherwise not very readable. Would need a lot of work, I don't think it would worth it. Let's hope that MS will allow us to distribute a linker alongside DMD. The more promising avenue would probably be to distribute LLD with DMD. This still leaves the system library licensing to deal with, but if I remember correctly, one of the usual suspects (Rainer? Vladimir?) was working on generating them from MinGW headers. — David
Re: LDC 1.5.0
On Friday, 3 November 2017 at 23:50:33 UTC, Nicholas Wilson wrote: Does `-link-internally` mean that you don't require command line tool/dev installation for OS X and Windows? That would be awesome for getting workshops for non-programmers (the biologists at my Uni) to work. You still need the system libraries to link against, unfortunately. — David
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 17:24:32 UTC, Igor Shirkalin wrote: Does new "-betterC" mean we may use parallelism with using separate linker? `-betterC` does not add any emulation of missing platform features — on the contrary, it *removes* language runtime functionality! Thus, if TLS doesn't work for you (IIRC, emulated TLS should work on Android following Joakim's work!), adding `-betterC` won't improve the situation. Could you please open an ticket on the LDC GitHub tracker with details on the issue? — David
Re: TLS + LDC + Android (ARM) = FAIL
On Wednesday, 1 November 2017 at 17:30:05 UTC, Iain Buclaw wrote: GDC supports the same or maybe more platforms than LDC. :-) Or quite possibly fewer, depending on what one understands "platform" and "support" to mean. ;) What is the state of GDC on Android/ARM – has anyone been using it recently? — David
Re: How can I use ldc2 and link to full runtime on arm with no OS
On Wednesday, 21 June 2017 at 16:10:41 UTC, Dan Walmsley wrote: My idea is to build the whole thing, see what the code size and performance is, and then one by one reduce things down as needed. Starting from nothing so far has been a bit of a none starter! This way, you'll end up having to port all of druntime to your target, though, only to then throw away considerable amounts of work that went into the parts you don't want to use. I don't think the notion of implementing a feature being easier than understanding how to rip it out is very realistic. — David
Re: GDC generate wrong .exe ("not a valid win32 application")
On Monday, 19 June 2017 at 14:08:56 UTC, Patric Dexheimer wrote: Fresh install of GDC. (tried with 32x ad 32_64x) Where did you get the GDC executable from? The GDC project doesn't currently offer any official builds that target Windows; the 6.3.0 builds from https://gdcproject.org/downloads in fact generate Linux binaries. — David
Re: libc dependency
On Wednesday, 21 June 2017 at 06:58:43 UTC, Jacob Carlborg wrote: Musl (or similar) should be available as an alternative. That will make it easier to cross-compile as well. This is not relevant for cross-compilation, as long as you have the libraries available. You can actually link a D Windows x64/MSVCRT executable from Linux today if you copy over the necessary libraries. The question is just how we can make this as easy as possible for users. — David
Re: How can I use ldc2 and link to full runtime on arm with no OS
On Wednesday, 21 June 2017 at 14:53:04 UTC, Dan Walmsley wrote: when trying to compile I'm getting lots of errors like this one: C:\dev\repos\druntime\src\gc\impl\manual\gc.d(28): Error: module config is in file 'gc\config.d' which cannot be read import path[0] = C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import\ldc import path[1] = C:\Users\danw\AvalonStudio\AppData\Repos\AvalonStudio.Toolchains.LDC.win-x64.4.0.0-build2-alpha\content\bin\..\import Build Failed any ideas what could be the cause? You are not adding druntime/src to the import path. I'd suggest you focus on other things first, though. Having D's GC on a platform with less than 1 MiB RAM is a rather sketchy proposition. — David
Re: How can I use ldc2 and link to full runtime on arm with no OS
On Tuesday, 20 June 2017 at 17:52:59 UTC, Dan Walmsley wrote: I need to know, how does the run time know which area of ram to use for heap? It uses C's malloc/calloc(). — David
Re: libc dependency
On Tuesday, 20 June 2017 at 18:51:17 UTC, Moritz Maxeiner wrote: On Tuesday, 20 June 2017 at 12:09:06 UTC, Jacob Carlborg wrote: LLD, the LLVM linker [1]. As far as I understand it, it also support cross-platform linking. Using LDC, musl and LLD you have a fully working cross-compiler tool chain. You might need some extra libraries as well, depending on what you need. Hm, so then we could provide a self-contained installer for all major platforms that bundles all you need to get started with D. Neat. Yes, that's part of the idea behind the ongoing work to integrate LLD into LDC: https://github.com/ldc-developers/ldc/pull/2142 For Windows, we use the MS C runtime, though, and the legal situation around redistribution seems a bit unclear. — David
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 19:01:06 UTC, Stefan Koch wrote:
On Tuesday, 20 June 2017 at 18:58:36 UTC, David Nadlinger wrote:
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote:
Hit me with brittle numeric code please!
[…]
Unfortunately this also broke the phobos unitttests since now
more of is attempted to be evaluated.
Just making sure that the Phobos unit tests pass at compile
time (with 64 bit reals, if that is what you support) should
be a good start.
— David
Fixed.
But how much of the std.math code are you actually executing with
newCTFE? What I meant is that if the std.math{,special}
implementations of the various mathematical functions work, there
shouldn't be any egregious issues. I'm not sure how much of it is
usually run during CTFE, though.
— David
Re: CTFE Status 2
On Tuesday, 20 June 2017 at 17:35:28 UTC, Stefan Koch wrote: Hit me with brittle numeric code please! […] Unfortunately this also broke the phobos unitttests since now more of is attempted to be evaluated. Just making sure that the Phobos unit tests pass at compile time (with 64 bit reals, if that is what you support) should be a good start. — David
Re: anyone using msgpackrpc-d ? it's currently broken and doesn't seem maintained
On Wednesday, 14 June 2017 at 19:55:49 UTC, Yawniek wrote: Msgpack rpc with vibe.d works. We used it. Its extremely fast, youll never get that speed with thrift. I don't think Thrift is fundamentally much different in performance than MessagePack, see e.g. https://github.com/thekvs/cpp-serializers. Do you have data to suggest otherwise? (I of course originally wrote Thrift/D, but that was long enough ago that I like to think I'm not particularly biased either way.) As for the performance of the RPC server, I'd think that just hooking vibe.d sockets into Thrift should give you similar performance to msgpack-rpc/vibe.d. — David
Re: atomic operations compared to c++
On Wednesday, 14 June 2017 at 12:48:14 UTC, Russel Winder wrote: On Wed, 2017-06-14 at 10:40 +, gzp via Digitalmars-d wrote: […] cas in all api I've seen on a failed swap, the current value is retrieved (in c/c++ there are intrinsic for them) This appears to be in core.atomic. There is a misunderstanding here. cas() is in core.atomic, but it returns true/false rather than the read value. However, this is just fine for virtually all algorithms. In fact, the respective functions in C++11 also return a boolean result. exchange no api for it and not implementable without spinning (in c/c++ there are intrinsic for them) atomicFence No memory ordering is considered in the API Even tough it falls back to the strongest/slowest one for the current implementation it should be part of the API. Appears to be in core.atomic. Where exactly would that be? There is no unconditional swap/xchg in core.atomic, and atomicFence() indeed only supports sequentially consistent semantics. — David
Re: atomic operations compared to c++
Hi, On Tuesday, 13 June 2017 at 06:12:46 UTC, gzp wrote: the docs are quite minimal That's true. In fact, this applies not only to atomic intrinsics, but all of `shared`. We need to sit down and properly specify things at some point. Andrei has been trying to get an initiative going to do just that recently. There is no consume in D. There is indeed no equivalent to memory_order_consume. Note, however, that consume is about to be deprecated in C/C++, as it turned out to be more or less unimplementable in its current form (at least while still being useful). Introducing the notion of source-level dependencies into a language that otherwise operates with as-if semantics on an abstract machine is a tricky business. But what about compare_exchange (CAS) ? […] Does it mean, it is the strongest sequaential all the time Yes, core.atomic.cas() is always seq_cst for the time being (we should fix this). Another issue is the fence. In D there is no memoryordering for fence, only the strongest one exists. Is it intentional? No; it is just a questionable design decision/unnecessary limitation which can easily be remedied by adding an optional parameter. — David
Re: C++17 cannot beat D surely
On Sunday, 4 June 2017 at 10:39:09 UTC, rikki cattermole wrote: Should be a way, since you can pass arg directly via ldc to ld. But I would expect it to have done it by default anyway. It is indeed done by default on Windows and Linux. If you dump the object code before it gets to the linker, it will still show the unused symbols, though. — David
Re: GPGPU progess
On Saturday, 3 June 2017 at 23:13:09 UTC, Nicholas Wilson wrote: Good idea, name of global needs to be known in advance though. Why, and how would that be a non-trivial problem? — David
Re: Benchmark
On Friday, 2 June 2017 at 21:56:47 UTC, Robert burner Schadek wrote: If that works out, the next step is properly to integrate that in the phobos/druntime/dmd CI. Which properly means putting the benchmark library through the experimental integration process, and finding a place for the benchmarks to life. As I've pointed out before, having the benchmark support code be part of the public standard library is not required for the Phobos project to make use of it internally. — David
Re: std.path.buildPath
On Saturday, 3 June 2017 at 14:12:03 UTC, Russel Winder wrote: I have no idea what drugs the person who chose that last one to be correct semantics was on at the time, but it was some seriously bad stuff. Of all people, I certainly didn't expect you to stray so far from the tone appropriate here. Please keep it civil. I cannot find any excuse for this to be even remotely reasonable. I suspect the original author had applications in mind where you want to resolve user-specified file system paths that might be relative or absolute. One could just use buildPath to prepend the root path if necessary. (Whether this is useful or just unnecessarily error-prone is another question, of course.) — David
Re: C macros vs D can't do the right thing
On Saturday, 3 June 2017 at 14:19:00 UTC, Jacob Carlborg wrote: Perhaps using the variadic template with a constraint on one element trick will work. Ugly, but I think that will work. We could also finally fix the frontend to get around this. At DConf 2015, Walter officially agreed that this is a bug that needs fixing. ;) — David
Re: C macros vs D can't do the right thing
On Saturday, 3 June 2017 at 13:17:46 UTC, Russel Winder wrote: Is this a problem in D or a problem in DStep? It's a limitation of DStep – for that use case, it would need to transform one of the macro arguments into a template argument rather than a runtime function parameter. If you need to make the code work as-is, I suppose you could create some aliases like `enum u32 = __u32.init;` and pass these instead of the types – using runtime values just to convey their type. — David
Re: GPGPU progess
On Saturday, 3 June 2017 at 12:13:41 UTC, Nicholas Wilson wrote: Alas no. __attribute__((target(...)) works because it targeting different targets of the _same_ backend, this targets different backends. But surely you could just take the buffer with the object code emitted by the compute target backend and emit it as constant global data into the host llvm::Module? — David
Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks
On Tuesday, 23 May 2017 at 19:47:49 UTC, Andrei Alexandrescu wrote: A big one will be making the GC lazily initialize itself. How detailed are your plans for this? The interaction between GC and shared library loading is a bit non-trivial to get right. — David
Re: Libdivide ported to D
On Sunday, 14 May 2017 at 15:30:19 UTC, Walter Bright wrote: On 5/14/2017 3:39 AM, Tomer Filiba wrote: Of course it only applies to runtime division -- the compiler can do the same if the divisor is known in compile time. I hate to say this, but modern compilers already do this for generated runtime code when dividing by a constant. […] As Tomer points out, a runtime implementation can still be useful if the divisor is only known dynamically (but constant across number of operations). — David
Re: DConf 2017 Hackathon report [OT]
On Thursday, 11 May 2017 at 21:37:45 UTC, Iain Buclaw wrote: This is not a problem that needs to be solved for GDC. It's not a problem that needs to be solved *in* GDC, but it has to be tackled *for* (packaging) GDC, as you need to have a bootstrap compiler available. Hence, building a C++-based compiler is less complex than a D-based compiler – that is, if you don't want to depend on a pre-existing D compiler, but are fine with using a pre-existing C++ compiler, which is what the LDC snap packages currently does. — David
Re: DConf 2017 Hackathon report [OT]
On Thursday, 11 May 2017 at 21:14:16 UTC, Iain Buclaw wrote: Oh, do you have to do the multi-stage build yourself? I don't. So you intend to keep a copy of the (old) bootstrap compiler sources in-tree for all future D-based GDC versions (if/when you start requiring D)? We could do that just as well, but it seems a bit pointless. — David
Re: DConf 2017 Hackathon report [OT]
On Thursday, 11 May 2017 at 20:54:45 UTC, Iain Buclaw wrote: My rebuttal still stands. Switching build from C++ to D should be a one line change, if it isn't then you have a problems with your build process. How does snap requiring more than a one-line change for a multi-stage build imply that anybody's build process is problematic? — David
Re: DConf 2017 Hackathon report
On Thursday, 11 May 2017 at 17:56:00 UTC, Iain Buclaw wrote: I can only infer that you are saying that using a D project means it's more difficult to get working with snap. To which I will insert an obligatory "Woah!", and "I expect you to know better" rebuttal. ... Woah, I expect you to know better. Incorrect. My (implied) statement was that a dependency on D makes the build process more complex *if that project is a D compiler, and you don't want to depend on another one in build-packages*. — David
Re: DConf 2017 Hackathon report
On Wednesday, 10 May 2017 at 19:46:01 UTC, Joseph Rushton Wakeling wrote: Ironically, given that I'd always been worried this would be the most finnicky compiler snap to create, it's actually the simplest package definition out of all the Big 3 ;-) Without even having seen your snap file, I can confidently say that this is just due to the idiosyncrasies of the snap environment, though. Oh wait, no, GDC is still stuck on an ancient C++-based frontend. Not too surprising, then. ;P — David
Re: DLang quarterly EU?
On Saturday, 6 May 2017 at 23:53:45 UTC, Ethan Watson wrote: This is quite feasible in Europe, since everything is quite close together. I'm keen. Atila is keen. Anyone else think this is a great idea? I'd definitely be interested as well. —David
Re: The D ecosystem in Debian with free-as-in-freedom DMD
On Tuesday, 2 May 2017 at 19:34:44 UTC, Marco Leise wrote: static Phobos2 : 806968 bytes dynamic Phobos2 : 18552 bytes That's about 770 KiB to share or 97.7% of its total size! Awesome! By the way, using LDC: 402736 bytes for the static build (Linux x86_64). ;) — David
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Saturday, 22 April 2017 at 10:12:04 UTC, Arek wrote: And no output for ARM64. :/ LDC has beta-quality support for AArch64. --David
Re: "Competitive Advantage with D" is one of the keynotes at C++Now 2017
On Tuesday, 11 April 2017 at 09:30:28 UTC, Jacob Carlborg wrote: And no official support on macOS. LDC officially supports shared libraries on macOS. -David
GtkD static/shared library linking performance [was: The D ecosystem in Debian with free-as-in-freedom DMD]
On Tuesday, 11 April 2017 at 18:13:11 UTC, Russel Winder wrote: I have only the data that compiling and linking a GtkD application against a shared library is a lot shorter than against a static library. Sure, but that might be easily fixed, and if you really want to use shared libraries, you can always make Dub create/use a library in a local directory (and set the rpath appropriately, …). I don't quite see how any of this is related to the topic at hand (distro packaging). I'd indeed be interested in some data on the linking times, though. Be sure to test with ld.gold as well, if you are not using it already. — David
Re: [OT] Re: The D ecosystem in Debian with free-as-in-freedom DMD
On Tuesday, 11 April 2017 at 12:03:27 UTC, Matthias Klumpp wrote: On Monday, 10 April 2017 at 22:15:53 UTC, David Nadlinger wrote: So do we need to put a reminder about the ABI being unstable into set of every release notes to make sure we won't get angry bug reports once users actually build their own D code against your packages? ;) Nah, there are several options here, one would simply be to tell people not to use the distro packages with anything but the default D compiler used in the respective Debian release. So as long as one sticks to packages in the official apt repos, all the libraries are guaranteed to be built with the distributed compiler as well? When you mentioned that you'd read the release notes regarding the ABI change, I got the impression that you had to manually rebuild the world for that to happen – hence my tongue-in-cheek remark about reminding you to do this in the release notes. Otherwise, you might get lucky as far as the distributed applications are concerned (i.e. happen not to hit any ABI issues), but users might still be hosed when it comes to their own code. — David
Re: The D ecosystem in Debian with free-as-in-freedom DMD
On Monday, 10 April 2017 at 22:36:39 UTC, Iain Buclaw wrote: All the regression fixes and none of the bugs! That's an interesting approach (spoken with British language sensibilities). Is anybody using GDC on a big "modern" D2 codebase (metaprogramming-heavy, …) right now? From my experience with Thrift, Weka, and so on, even regression fixes have a habit of breaking that sort of code in weird and wonderful ways. And that's not even mentioning other improvements/fixes/additions people might be relying on. Right now, the frontend version serves as a convenient aid for users to navigate those issues (apart, of course, from us trying to improve things by making semantic analysis more deterministic, etc). If something works on DMD 2.072.2, then users can also expect it to work on the corresponding LDC version as well. I'm not sure you are helping anybody by introducing another set of weird in-between versions. — David
Re: The D ecosystem in Debian with free-as-in-freedom DMD
On Tuesday, 11 April 2017 at 14:49:03 UTC, Russel Winder wrote: Having played a bit with GtkD, you always want this as a shared library for development. Why would a shared library be preferable to a static library for that (which might still be re-used between different projects, etc.)? — David
Re: The D ecosystem in Debian with free-as-in-freedom DMD
On Tuesday, 11 April 2017 at 12:38:01 UTC, Matthias Klumpp wrote: If you could change the SOVERSION with every one of these changes, or simply just tie it to the respective Phobos release, distributions would automatically do the right thing and compile all D code using Phobos against the new version. As you mention, this is already done in LDC; not just the Debian packages, but also upstream. The soname will always be `libphobos2-ldc.so.74` or what have you. (Thinking about it, it should probably include the patch version as well, although we haven't had a situation so far where we would have wanted to release multiple LDC versions for ABI-incompatible patch releases.) — David
