Re: Five Projects Selected for SAOC 2019
On Tuesday, 27 August 2019 at 17:11:33 UTC, Mike Franklin wrote: If you look at the vibe.d compile-time graph, you'll see there's a 2.5s increase around Mid-2014. Sorry, that should be Mid-2015.
Re: Five Projects Selected for SAOC 2019
On Tuesday, 27 August 2019 at 12:58:20 UTC, Vladimir Panteleev wrote: It will eventually zero in to commit-level accuracy after it's been running for a while. I cleared the database as the last time it was running, it was on another CPU, so the timings are going to be different. (Still need to decide on a way to measure execution time in some deterministic way.) If you look at the vibe.d compile-time graph, you'll see there's a 2.5s increase around Mid-2014. When I zoom in and visit the commit, it's just a DDoc comment change (https://github.com/dlang/phobos/pull/3542). I don't see how that could account for the large increase in compile time. Mike
Re: Five Projects Selected for SAOC 2019
On Monday, 26 August 2019 at 18:51:54 UTC, Vladimir Panteleev wrote: Here's the original blog post: https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/ I'll give it a kick and get it back online if there is interest. Seems wasteful to reimplement it from scratch, though. It's great to see this back up and running. The compile-time data is quite interesting. Is there any way to identify a particular offending commit. The commits identified in the data points on the chart don't seem to be precise. Mike
Re: UPB D Summer School
On Wednesday, 17 July 2019 at 13:56:38 UTC, RazvanN wrote: We have encouraged the graduating students to participate to SAOC and also we are in discussions with some of them to initiate them into contributing to D. And we'd love to have them. "Well done!" to everyone involved. Mike
Re: Ownership and Borrowing in D
On Monday, 15 July 2019 at 14:58:55 UTC, Mike Parker wrote: In the Draft Review for Walter's DIP, Argument Ownership and Function Calls (which in the next half hour or so will be starting a community review as DIP 1021), some folks asked for some information about the bigger picture. In response, Walter has put together a post outlining his current thinking on how to add Ownership and Borrowing to D. Thank you, Walter. This is very exciting. I've said that if I could have my ideal language, it would be Dust, and now I just might get it :) Mike
Re: Release D 2.087.0
On Monday, 15 July 2019 at 13:00:08 UTC, Vladimir Panteleev wrote: We are trying to implement many of those `extern(C)` runtime hooks as templates. Those templates need to be implicitly imported through object.d. That means code that was in `rt` is converted to a template, and then moved to object.d. However, as we do more and more of them object.d becomes unwieldy. I took the initiative to prevent object.d from turning into a more of a monstrosity that it already is, and moved those runtime templates (which used to reside in `rt`) back into `rt`. This is not a problem, and not at all related to the issue we're discussing. The problem is that you chose to move them into `rt` instead of somewhere under `core`, which would respect existing conventions and avoid breakages like the ones we've seen reported in this thread. It is related. If I follow your suggestion to move these implementations to `core.internal` and continue with the objective of converting all runtime hooks to templates, the vast majority of `rt` will end up being moved to `core.internal`. Is that what you're suggesting? `rt` is the language implementation. `core.internal` contains the utilities used internally by druntime and "privately" imported by Phobos. Following that established convention, I made the right decision. I'm sorry it broke digger, but digger is not how we typically build DMD, druntime, and Phobos. Mike
Re: Release D 2.087.0
On Monday, 15 July 2019 at 13:06:58 UTC, Vladimir Panteleev wrote: On Monday, 15 July 2019 at 12:42:57 UTC, Mike Franklin wrote: ... and are the exception, not the rule. I believe they should be moved to `rt`. BTW, from this discussion it seems to me that you did not have a good overview of the situation and made a bad decision based on that. No problem there, however, throughout this discussion, you've made a number of claims that have been refuted, and instead of re-evaluating the situation, you've stuck to your position while presenting continuously more radical counter-arguments. At this point, I apologize and would like to ask you to carefully consider whether you are trying to neutrally argue for the best outcome to make D better, or merely to continue supporting your position. I'm not thoughtless and clueless, and I've acted in the best interest of D. I asked for input from other developers before moving forward. They helped me understand that `rt` is where the core language features are implemented. The code that I moved into `rt/array` initially came from `rt`, depends on implementations in `rt` and is the core implementation of D's built-in arrays, so it is perfectly logical for it to be in `rt`. I submitted PRs that were scrutinized by the reviewers and merged. Even after considering your arguments, I still believe I made the right decision. I'm sorry you disagree and don't find my explanations convincing. Mike
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:27:22 UTC, Vladimir Panteleev wrote: This isn't exactly true. The restriction is that core should not *import* rt. Have a look at all the extern(C) definitions in Druntime - using extern(C) functions to communicate between the compiler and rt, as well as core and rt, is not a "hack", but an established mechanism to invoke the low-level implementations in Druntime. We are trying to implement many of those `extern(C)` runtime hooks as templates. Those templates need to be implicitly imported through object.d. That means code that was in `rt` is converted to a template, and then moved to object.d. However, as we do more and more of them object.d becomes unwieldy. I took the initiative to prevent object.d from turning into a more of a monstrosity that it already is, and moved those runtime templates (which used to reside in `rt`) back into `rt`. Mike
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:40:50 UTC, Vladimir Panteleev wrote: - core.internal.hash contains the implementation of hashing routines used for associative arrays. - core.internal.arrayop contains the implementation of array vector operations. This one doesn't seem to be too far from your work in question. ... and are the exception, not the rule. I believe they should be moved to `rt`.
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:19:02 UTC, Vladimir Panteleev wrote: You don't need to move the implementations themselves into core.internal. Adding declarations there for the rt implementations would suffice. Many of the implementations in `rt/array` are templates, so the entire implementation should be available through object.d, not just declarations. So is the rest of core.internal. Please take a few minutes to have a look at the contents of the core.internal package, as well as all the places in object.d where modules from core.internal are already imported. Would you say that those cases are very unlike the case of this particular change? If so, would you mind explaining how? In `core.internal`, I see utilities that appear to be intended for use only within runtime, or "privately" imported by Phobos. I do not see implementations for fundamental language features as can be found in `rt`. The code in `rt/array` implementations for fundamental language features, not utilities to be used privately with druntime. Based on what you and Vladimir have said, I'm even more confident I've made the right decision putting them in `rt`. I really don't see the series of logical steps one would need to take to reach that conclusion. "rt can import core, but core can't import rt." makes it pretty clear to me. Mike
Re: Release D 2.087.0
On Monday, 15 July 2019 at 12:02:35 UTC, Seb wrote: I think that fits core.internal better than rt. Have you considered that during said discussion? The implementations in `rt/array` contain templates that are ports of runtime hooks that used to reside in `rt`. The implementations also require importing implementations from `rt` so it makes sense to me that they should all stay within `rt`. For reference, the discussion was this one: http://imgur.com/a/HszdtHd I'm sorry that I missed it, because Vladimir makes a very good point. rt isn't supposed to be available nor importable by the user. `rt` is not imported by the user; it is imported by the compiler indirectly through `object.d`. rt can import core, but core can't import rt. Many of the implementations in `rt/array` require importing or referencing other implementations in `rt` (e.g. `rt.lifetime`). If they were moved to `core.internal` they would require importing `rt` or peeking into `rt` with various hacks, which exactly what you've said should not be done. Based on what you and Vladimir have said, I'm even more confident I've made the right decision putting them in `rt`. Mike
Re: Release D 2.087.0
On Monday, 15 July 2019 at 10:52:08 UTC, Vladimir Panteleev wrote: On Thursday, 4 July 2019 at 12:57:43 UTC, Mike Franklin wrote: The copy should take place when building druntime from the makefiles. The files to be copied are listed at https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/COPY#L405-L408 and, for Windows, should be copied https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/WINDOWS#L1187-L1197 is executed. But, I don't know if that happens or not with digger. Why have these declarations been placed in the "rt" package, and not in "core.internal"? The "rt" package has historically always been for the Druntime implementation part which is not importable from D programs. I think "core.internal" would have been more suitable. I discussed that briefly on Slack with a couple other developers. My understanding is the `rt` is the language implementation and `core` is the low level library for users. The code in `rt/array` are language implementations. They are not to be imported by the user. They are, however, required by the language to implement D's built-in arrays, so that is why they are publicly imported in object.d. Mike
Re: Release D 2.087.0
On Thursday, 4 July 2019 at 12:48:15 UTC, Robert M. Münch wrote: So, the problem is, that digger somehow misses to copy over the new source to the install directory. It does for some parts (phobos, but I'm not sure if for every file necessary) but not for druntime files. I just manually copied the files now. The copy should take place when building druntime from the makefiles. The files to be copied are listed at https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/COPY#L405-L408 and, for Windows, should be copied https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/WINDOWS#L1187-L1197 is executed. But, I don't know if that happens or not with digger. Mike
Re: Release D 2.087.0
On Thursday, 4 July 2019 at 10:01:10 UTC, Robert M. Münch wrote: On 2019-07-04 08:11:26 +, Martin Nowak said: Glad to announce D 2.087.0, ♥ to the 63 contributors. This release comes with types matching single template alias parameters, nested template methods/local template functions, multi-threaded GC marking, and a phobos compiled with -preview=DIP1000. http://dlang.org/download.html http://dlang.org/changelog/2.087.0.html -Martin I just updated with Digger to the newest version and get: ...d-language\test> dub test -a=x86_64 -f Failed to invoke the compiler C:\D\dmd2\windows\bin\dmd.exe to determine the build platform: predefs DigitalMars Windows CRuntime_Microsoft CppRuntime_Microsoft LittleEndian D_Version2 all D_SIMD D_InlineAsm_X86_64 X86_64 Win64 D_LP64 assert D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat binaryC:\D\dmd2\windows\bin\dmd.exe version v2.087.0 configC:\D\dmd2\windows\bin\sc.ini DFLAGS-IC:\D\dmd2\windows\bin\..\..\src\phobos -IC:\D\dmd2\windows\bin\..\..\src\druntime\import -L/OPT:NOICF parse dub_platform_probe_956c8798_90a5_4300_b011_2b9e6cc8ace5 importall dub_platform_probe importobject (C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d) C:\D\dmd2\windows\bin\..\..\src\druntime\import\object.d(42): Error: module `comparison` is in file 'rt\array\comparison.d' which cannot be read import path[0] = C:\D\dmd2\windows\bin\..\..\src\phobos import path[1] = C:\D\dmd2\windows\bin\..\..\src\druntime\import Not sure what this is telling me. Related to the release? Yes, it's probably related to the release. Some runtime hooks were taken out of object.d and moved to `rt/array` to help set direction for a GSoC project that is in the process converting many runtime hooks to templates, and to help prevent object.d from becoming even more unwieldy than it already is. Move such refactorings are planned. I don't know what digger is doing, but from the error messages, it appears that the new files in `rt/array` can't be found. I believe the build is trying to use a new compiler with an older or existing runtime. You'll need both the latest compiler and the latest runtime together for them to work. If you can identify a bug in the makefiles, or some other such problem preventing the build, let me know and I'll try to fix it right away. Mike
Re: Let's celebrate Dlang on D day
On Saturday, 25 May 2019 at 21:56:57 UTC, Murilo wrote: Sorry people It's ok. I know you meant well, and we're happy to have people in this community so passionate about D. Mike
Re: Let's celebrate Dlang on D day
On Saturday, 25 May 2019 at 03:22:50 UTC, Murilo wrote: On the 6th of June(6/6) we celebrate the D day on Normandy, but I have decided to turn it into our own holiday to celebrate the D language. I'm sure you mean well, but I will be spending D-Day remembering the sacrifice of these men: https://en.wikipedia.org/wiki/Normandy_landings#/media/File:Normandy_American_Cemetery_and_Memorial,_June_2012.jpg Perhaps you could find a way to use the D language to honor them. Mike
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 11:41:12 UTC, Atila Neves wrote: I'd been holding off on announcing this until DIP1008 actually got implemented, and now it has: https://code.dlang.org/packages/nogc This dub package has a @nogc version of `std.conv.text` (which probably isn't as good yet) that, instead of returning a `string` returns an `automem.vector.Vector` of char. This handles managing memory allocation for the exception message itself in `NoGcException`, which does what it says on the tin. Confused? Here's some code: Ok, so exceptions don't rely on the GC anymore. That's super cool. However, they are still classes. So does that mean they also need RTTI (i.e. TypeInfo)? BetterC builds and some of use trying to use D in a pay-as-you-go fashion intentionally eliminate RTTI from the runtime. Is there any way we can take this a bit further to no longer require RTTI? Do exceptions even necessarily need to be classes? Thanks, Mike
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 20:59:43 UTC, Mike Franklin wrote: I don't think it does because `Queue!(T).store` has infinite lifetime beyond that of even `main`, at least as far as the compiler is concerned. The compiler doesn't have enough information to know that `store` is tied to the lifetime of `Queue!(T)` (a.k.a `rawData`) and maybe that's a missing language feature. Maybe we should be allowed to declare aggregate fields as `scope` to convey that, but the compiler currently disallows it. Or we build in some way for slices to know their lifetime relative to the source array from which they were created. But I'm not sure how that would work. Mike
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 17:03:51 UTC, Meta wrote: If you look at `main` above, `rawData` has the same lifetime as the `dataRange` struct returned from `makeDataRange` and the queue returned from `copyToQueue`. True, there is some traditionally unsafe stuff happening in between; however, I thought that the point of adding all these annotations is to tell the compiler how the lifetimes of these objects propagate up and down the call stack, so that it can check that there will be no memory corruption. I'm not doing anything here that will result in a pointer to an expired stack frame, or otherwise cause memory corruption or use after free, or anything like that (*unless* I allow either `dataRange` or `result` to escape from the main function - which dip1000 correctly disallows). I don't think it does because `Queue!(T).store` has infinite lifetime beyond that of even `main`, at least as far as the compiler is concerned. The compiler doesn't have enough information to know that `store` is tied to the lifetime of `Queue!(T)` (a.k.a `rawData`) and maybe that's a missing language feature. Maybe we should be allowed to declare aggregate fields as `scope` to convey that, but the compiler currently disallows it. loosely related: https://issues.dlang.org/show_bug.cgi?id=18788#c7 Mike
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 05:22:30 UTC, Mike Franklin wrote: My assessment (which could be wrong): `scope` and `return` only apply to pointers and `ref`s. If you remove all `scope` and `return` attributes from the function `push`, it works fine. I consider it a bug that the compiler doesn't emit an error when using attributes on types for which they are not intended. Mike Working example: https://run.dlang.io/is/TCP0td
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 04:50:52 UTC, Meta wrote: Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you. https://forum.dlang.org/post/laqjadtwrsdhdrqok...@forum.dlang.org My assessment (which could be wrong): `scope` and `return` only apply to pointers and `ref`s. If you remove all `scope` and `return` attributes from the function `push`, it works fine. I consider it a bug that the compiler doesn't emit an error when using attributes on types for which they are not intended. Mike
Re: bool (was DConf 2019 AGM Livestream)
On Wednesday, 15 May 2019 at 01:15:43 UTC, Andrei Alexandrescu wrote: That we even discuss just how bad bool is while we have no done deals for safety, reference counting, shared, package distribution/versioning, pay-as-you-go runtime, collections, ..., is a fascinating puzzle. It can all be done simultaneously. I'm working on a couple of those items along with a few others simultaneously. I can't dedicate all my energy to one item, though. I often need to work on something, and then step away from it for a while. I then work on something else, and when I get back to the first item, I see with greater clarity. Also, sometimes I have to wait for others. For example, I submit a DIP, and I need to wait for it to go through the process. While that's happening I work on something else. And then, sometimes, I just don't have many cycles left at the end of the day. But I still find it therapeutic to work on trivial things; it relaxes me. There's no reason any and all work that moves D forward shouldn't be encouraged. If bool is clowny, and someone's willing to do something about it, why discourage them from doing so? Mike
Re: bool (was DConf 2019 AGM Livestream)
On Wednesday, 15 May 2019 at 00:23:44 UTC, Andrei Alexandrescu wrote: There are many clowny things in D, of which bool is at best somewhere beyond the radar. I suggest investing time * expertise in the larger ones. Once again, I disagree with what you think is important. `bool` is a fundamental type on which many things in D depend. If it doesn't work right, neither will the features that depend on it. But, that's your decision, and there's little to nothing we can do about it, so I guess we just accept the fact that D is clowny and deal with it; it's what so many of us, so often do.
Re: bool (was DConf 2019 AGM Livestream)
On Tuesday, 14 May 2019 at 15:40:19 UTC, Kagamin wrote: On Sunday, 12 May 2019 at 06:27:21 UTC, Nick Sabalausky (Abscissa) wrote: All this effort strongly implies that there's no such thing as a satisfactory bool type *in languages which conflate booleans with integers* FWIW I write C# for food and to me D bool is better than C# bool. Didn't watch, but if it's about the DIP I think of, its rationale was overload rules, Walter said he's not opposed to tune them. It was derailed into discussion about strong bool? At the time the DIP was written, we didn't know Walter conflates bool and bit. Now that we do a new DIP could argue differently that bool and bit should not be conflated and that that would also fix the overload issues. Mike
Re: bool (was DConf 2019 AGM Livestream)
On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote: Sure it is convenient to have some properties of bool also be similar to an integer, but it can definitely not be swapped in to be used like a 1-bit integer and there are already plenty of special rules for it. Thanks for that analysis. So we have a bool that is neither a boolean nor a bit. That stinks. Walter and Andrei have made their decision, so it doesn't look like we'll be able to do anything about it unless maybe Atila feels that it's something that needs to be addressed. Anyway, I'm of the mind that the language should just provide a set of powerful, composable primitives and delegate course-grained features and specializations to the library. I've been re-imagining druntime and phobos at lot lately and I'm more confident that we can define a wrapper around `bool` to give it proper boolean semantics. Maybe, if Walter would support it, we could then fix bool to make it a proper `bit`. Then in the library `alias bit = bool;` and live happily ever after. If anyone's looking for a challenge, I welcome them to propose a new `Bool` type (note the capital B) for inclusion in my new library. Mike
Re: DConf 2019 AGM Livestream
On Saturday, 11 May 2019 at 20:35:40 UTC, Exil wrote: Regarding the discussion of how bool is handled... It's a one bit integer so it should behave like a one bit integer https://www.youtube.com/watch?v=cpTAtiboIDs#t=2h17m50s I think Walter is conflating how bool is stored in memory with its semantics. I'm currently considering using D's rich modeling features to create a new boolean type that behaves more like a boolean and less like a bit. But it's unfortunate and disappointing we have to resort to something like that. Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Saturday, 11 May 2019 at 05:39:12 UTC, H. S. Teoh wrote: So potentially a D-based memcpy could have multiple concrete implementations (copying strategies) that are statically chosen based on the properties of T, like alignment and size. Exactly. [...] However, DMD won't do the right thing. Honestly, at this point I don't even care. Personally I'd be fine with just killing of DMD's backend and just investing in LDC and GDC, but I don't think that's going to happen, and because of that, we have to care. DMD is where policy and precedent is set for D. To influence the direction of D, it must be done throught DMD. It could be possible to select multiple different memcpy implementations by statically examining the properties of T. I think that might be one advantage D could have over just calling libc's memcpy. But you have to be very careful not to outdo the compiler's optimizer so that it doesn't recognize it as memcpy and fails to apply what would otherwise be a routine optimization pass. I understand. That's why I'm calling it an "exploration" at this time. I want to see what can and can't be done. At a certain point, this just begs the question "should I just let the compiler's backend do its job by telling it plainly that I mean memcpy, or should I engage in asm-hackery because I'm confident I can outdo the compiler's codegen?". I get that, but DMD is not the kind of backend that does that stuff. If I could rely on DMD's, LDC's, and GDC's backend to just insert an optimized compiler intrinsic, without the C standard library, I would just leverage that. But that doesn't seem to be the world we're currently in. One thing that might be worth considering is for the *compiler* to expose a memcpy intrinsic, and then let the compiler decide how best to implement it (using its intimate knowledge of the target machine arch), rather than trying to do it manually in library code. I would love for the backends to just know how to copy memory efficiently for all of their targets without me having to do anything, and without linking in the C standard library, but that's not what I'm seeing from the compilers right now. Based on what Andrei has voiced, the way to go would be to merge Phobos and druntime into one, by making Phobos completely opt-in so that you don't pay for what you don't use from the heavier / higher-level parts of Phobos. At a certain point it becomes clear that the division between Phobos and druntime is artificial, the result of historical accident, and not a logical necessity that we have to keep. If Phobos is made completely pay-as-you-go, the distinction becomes completely irrelevant and the two might as well be merged into one. Yes, but is making Phobos pay-as-you-go a real possibility? I don't see it that way because all of Phobos has been developed under the assumption that all language features are implemented and available. utiliD would be usable in an environment where only a subset of D's language features are available. Also, Phobos has been developed under the assumption that any module in Phobos or druntime can be utilized as a dependency in any other module. That has created a dependency mess in Phobos and I don't see how that can be disentangled without breaking everyone's code. Furthermore, there is no clear hierarchy in Phobos where it is clear at the API level what language features are required for each module/function/whatever. With utiliD, it is much clearer where the line is drawn in the hierarchy of language features. Phobos will never be pay-as-you-go if you can't see what you're paying for as you go. See, this trouble is caused by the artificial boundary between Phobos and druntime. We should look into breaking down this barrier, not enforcing it. I agree. We could actually merge druntime and Phobos into a single library today. I also find the divide between Phobos and druntime artificial, but my goal with utiliD is different. I'm trying to create a library that does not require runtime language features. I'm not proposing an artificial division that currently exists. I'm trying to build something equivalent to a stack, where you start at a very low level (utilid) and add layers of increasing capability. That's not what we have with Phobos and druntime today. I think the logical goal is to make Phobos completely pay-as-you-go. IOW, an actual *library*, as opposed to a tangled hairball of dependencies that always comes with strings attached (can't import one small thing without pulling in the rest of the hairball). A library is supposed to be a set of resources which you can draw from as needed. Pulling out one book (module) should not require pulling out half the library along with it. I agree, but that hairball is exactly what Phobos is right now. I don't see any way to start from that mess and achieve the pay-as-you-go opt-in continuum. In a way,
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Saturday, 11 May 2019 at 00:32:54 UTC, H. S. Teoh wrote:
When it comes to performance, I've essentially given up looking
at DMD output. DMD's inliner gives up far too easily, leading
to a lot of calls that aren't inlined when they really should
be, and DMD's optimizer does not have loop unrolling, which
excludes a LOT of subsequent optimizations that could have been
applied. I wouldn't base any performance decisions on DMD
output. If LDC or GDC produces non-optimal code, then we have
cause to do something. Otherwise, IMO we're just uglifying D
code and making it unmaintainable for no good reason.
I think this thread is beginning losing sight of the larger
picture. What I'm trying to achieve is the opt-in continuum that
Andrei mentioned elsewhere on this forum. We can't do that with
the way the compiler and runtime currently interact. So, the
first task, which I'm trying to get around to, is to convert
runtime hooks to templates. Using the compile-time type
information will allow us to avoid `TypeInfo`, therefore classes,
therefore the entire D runtime. We're now much closer to the
opt-in continuum Andrei mentioned previously on this forum. Now
let's assume that's done...
Those new templates will eventually call a very few functions
from the C standard library, memcpy being one of them. Because
the runtime hooks are now templates, we have type information
that we can use in the call to memcpy. Therefore, I want to
explore implementing `void memcpy(T)(ref T dst, const ref T src)
@safe, nothrow, pure, @nogc` rather than `void* memcpy(void*,
const void*, size_t)` There are some issues here such as
template bloat and compile times, but I want to explore it
anyway. I'm trying to imagine, what would memcpy in D look like
if we didn't have a C implementation clouding narrowing our
imagination. I don't know how that will turn out, but I want to
explore it.
For LDC we can just do something like this...
void memcpy(T)(ref T dst, const ref T src) @safe, nothrow, @nogc,
pure
{
version(LDC)
{
// after casting dst and src to byte arrays...
// (probably need to put the casts in a @trusted block)
for(int i = 0; i < size; i++)
dstArray[i] = srcArry[i];
}
}
LDC is able to see that as memcpy and do the right thing. Also
if the LDC developers want to do their own thing altogether, more
power to them. I don't see anything ugly about it.
However, DMD won't do the right thing. I guess others are
thinking that we'd just re-implement `void* memcpy(void*, const
void*, size_t)` in D and we'd throw in a runtime call to
`memcpy([0], [0], T.sizeof())`. That's
ridiculous. What I want to do is use the type information to
generate an optimal implementation (considering size and
alignment) that DMD will be forced to inline with
`pragma(inline)` That implementation can also take into
consideration target features such as SIMD. I don't believe the
code will be complex, and I expect it to perform at least as well
as the C implementation. My initial tests show that it will
actually outperform the C implementation, but that could be a
problem with my tests. I'm still researching it.
Now assuming that's done, we now have language runtime
implementations that are isolated from heavier runtime features
(like the `TypeInfo` classes) that can easily be used in -betterC
builds, bare-metal systems programming, etc. simply by importing
them as a header-only library; it doesn't require first compiling
(or cross-compiling) a runtime for linking with your program; you
just import and go. We're now much closer to the opt-in
continuum.
Now what about development of druntime itself. Well wouldn't it
be nice if we could utilize things like `std.traits`, `std.meta`,
`std.conv`, and a bunch of other stuff from Phobos? Wouldn't it
also be nice if we could use that stuff in DMD itself without
importing Phobos? So let's take that stuff in Phobos that
doesn't need druntime and put them in a library that doesn't
require druntime (i.e. utiliD). Now druntime can import utiliD
and have more idiomatic-D implementations.
But the benefits don't stop there, bare-metal developers,
microcontroller developers, kernel driver developers, OS
developers, etc... can all use the runtime-less library to
bootstap their own implementations without having to re-invent or
copy code out of Phobos and druntime.
I'm probably not articulating this vision well. I'm sorry.
Maybe we'll just have to hope I can find the time and energy to
do it myself and then others will finally see from the results.
Or maybe I'll go have a nice helping of crow.
Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Saturday, 11 May 2019 at 00:09:08 UTC, Mike Franklin wrote: On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote: I'm not 100% sure it's a good idea to implement memcpy in D just to prove that it can be done / just to say that we're independent of libc. Libc implementations of fundamental operations, esp. memcpy, are usually optimized to next week and back for the target architecture, taking advantage of the target arch's quirks to maximize performance. Not to mention that advanced compiler backends recognize calls to memcpy and can optimize it in ways they can't optimize a generic D function they fail to recognize as being equivalent to memcpy. I highly doubt a generic D implementation could hope to beat that, and it's a little unrealistic, given our current manpower situation, for us to be able to optimize it for each target arch ourselves. I understand that point of view. Indeed we have to demonstrate benefit. One benefit is to not have to obtain a C toolchain when building D programs. That is actually quite an inconvenient barrier to entry when cross-compiling (e.g. for developing microcontroller firmware on a PC). I'm also hoping that a D implementation would be easier to comprehend than something like this: https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S The D implementation still has to handle all of those corner cases, but I'd rather read D code with inline assembly sprinkled here and there than read the entire thing in assembly. The goal with the D implementation would be to minimize the assembly. For compilers that already do something special with memcpy and don't require a C standard library, there's no reason to do anything. My initial exploration into this has shown that DMD is not one of those compilers. Also, take a look at this data: https://forum.dlang.org/post/jdfiqpronazgglrkm...@forum.dlang.org Why is DMD making 48,000 runtime calls to memcpy to copy 8 bytes of data? Many of those calls should be inlined. I see opportunity for improvement there. Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Friday, 10 May 2019 at 23:51:56 UTC, H. S. Teoh wrote: I'm not 100% sure it's a good idea to implement memcpy in D just to prove that it can be done / just to say that we're independent of libc. Libc implementations of fundamental operations, esp. memcpy, are usually optimized to next week and back for the target architecture, taking advantage of the target arch's quirks to maximize performance. Not to mention that advanced compiler backends recognize calls to memcpy and can optimize it in ways they can't optimize a generic D function they fail to recognize as being equivalent to memcpy. I highly doubt a generic D implementation could hope to beat that, and it's a little unrealistic, given our current manpower situation, for us to be able to optimize it for each target arch ourselves. I understand that point of view. Indeed we have to demonstrate benefit. One benefit is to not have to obtain a C toolchain when building D programs. That is actually quite an inconvenient barrier to entry when cross-compiling (e.g. for developing microcontroller firmware on a PC). I'm also hoping that a D implementation would be easier to comprehend than something like this: https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S The D implementation still has to handle all of those corner cases, but I'd rather read D code with inline assembly sprinkled here and there than read the entire thing in assembly. The goal with the D implementation would be to minimize the assembly. For compilers that already do something special with memcpy and don't require a C standard library, there's no reason to do anything. My initial exploration into this has shown that DMD is not one of those compilers. On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote: [...] > Whereby I should say that tanya‘s range definitions differ > from Phobos. [..] I'm a bit uncomfortable with having multiple, incompatible range definitions. While the Phobos definition can be argued whether it's the best, shouldn't we instead be focusing on improving the *standard* definition of ranges, rather than balkanizing the situation by introducing multiple, incompatible definitions just because? It's one thing for Andrei to propose a std.v2 that, ostensibly, might have a new, hopefully improved, range API, deprecating the current definition; it's another thing to have multiple alternative, competing definitions in libraries that user code can choose from. That would be essentially inviting the Lisp Curse. Agreed. We should decide on one consistent definition. I don't know what that looks like right now. I'm more focused on low-level details right now. I do, however, like the idea of delegating the memory management (allocation/deallocation) outside of the library. If that's not feasible for some reason, then I would suggest it not be included in utiliD. I don't want dynamic memory allocation in utiliD; that should go into a higher-level library that may import utiliD. Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Friday, 10 May 2019 at 17:55:53 UTC, Johan Engelen wrote: Why would you use inline assembly ? (generalizing but: extremely bad portability, bad performance, bad readability) The only reason to use inline assembly is to achieve something that can't be achieved directly with D. For example, prior to the introduction of `volatileLoad` and `volatileStore` inline assembly was required to achieve `volatile` semantics. For memcpy and memcmp, one would first attempt to write a good implementation in straight D, but if the compiler doesn't generate good code for it, it would be appropriate to take control and provide an implementation in inline assembly. I don't know how a proper assembly implementation would not be performant. Perhaps you could elaborate. Recent discussion on LLVM mailinglist about the problem of the optimizer recognizing memcmp implementation and substituting it with a call to memcmp: https://lists.llvm.org/pipermail/llvm-dev/2019-April/131973.html Yes, that bit me a while back when I was doing some bare-metal ARM Cortex-m development https://forum.dlang.org/post/clptjumxigcozfcyh...@forum.dlang.org For compilers that already provide an optimized intrinsic implementation for memcpy none of this is necessary; one could simply add a naive implementation, the compiler would recognize it, and replace it with their optimized version. DMD, to my understanding, is not one of those compilers. One of the goals is to no longer require a C toolchain to build D programs. If the compiler already provides intrinsics without needed a C standard library, Great! The other goal is to explore what D could improve upon with its design-by-introspection features and compiler guarantees (e.g. `pure` and `@safe`). My initial exploration into that can be found at https://github.com/JinShil/memcpyD I find it much easier to read D code like that than something like this: https://github.com/opalmirror/glibc/blob/c38d0272b7c621078d84593c191e5ee656dbf27c/sysdeps/arm/memcpy.S Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Friday, 10 May 2019 at 05:20:59 UTC, Eugene Wissner wrote: - Memcmp, memcpy, memmove and memset are named equal, copy, copyBackward and fill respectively. I just wanted to create native implementations that are bit safer than their C counterparts. So they do the same job, but accept void[] instead of pointers. There are also templated functions with the same names, that work with ranges. I‘m not very comfortable with GCC‘s inline asm and it doesn‘t support naked asm as DMD does, so I put asm in the .S files and compile them separately. But I‘m fine with inline asm too. A problem with the inline asm is that it should be written in several versions since DMD uses different calling conventions (unless we use extern(C)) and GDC and LDC use different asm syntax. Yeah, that is indeed unfortunate, and something I'll have to consider. I have had to write 3 different inline-asm implementations for some of my exporations, and didn't find it to be too bad. I very much prefer to read the D with the inline-asm than a straight assembly file. I've studied the ARM implementation of memcpy a little, and it's quite hard to follow. I'd like for the D implementations to make such code easier to understand and maintain. Tanya contains pretty much stuff now and I‘m just thinking to split it in a smaller parts (of a reasonable size), that are probably interesting for other people, who is ready to contribute, so I don‘t have to maintain everything myself. I don‘t know exactly what goes into this more „low-level“ library, we can always talk about it. Yes, I'm still working that out too. If you apply the rule that it should not require anything from druntime, the C standard library, or dynamic memory allocation, it does eliminate quite a bit, and narrows the scope. What I'm trying to do now is just focus on the obvious, and hopefully with that out of the way the rest will begin to reveal themselves. - OS API Not sure if it belongs to the scope of utilD. Some time ago it became clear to me, that while C has functions for dynamic memory management, it uses them internally very seldom. Instead it lets the user to allocate the memory. So there functions like: char *if_indextoname(unsigned int ifindex, char *ifname); that take an output buffer as the last argument. The same can be done with output ranges in D, so these system functions can be rewritten in D with a better interface. Whereby I should say that tanya‘s range definitions differ from Phobos. Yes, I like that. The buffer and memory management is then delegated outside of the library. That, IMO, makes the library more broadly useful. Fundamental algorithms (e.g. from std.algorithm, std.range, etc.) that can operate on memory buffers/ranges in this way would be good candidates for utiliD, IMO. But I'd want them to meet the criteria of being fundamental and broadly useful; not too specialized. Specialized algorithms that are designed for specific problem domains should probably go in a library designed for that problem domain. - meta Another thing probably interesting for utilD library is meta-programming. Tanya has „tanya.meta“ package which contains templates similar to to std.traits and std.meta + some nice extras like Union/Intersection/Difference working on sets of types, that are inspired by Boost Hana. This part is completely independent (from Phobos and the rest of tanya) and can even be a separate library. I'm thinking metaprogramming modules and packages are good candidates for utilitD as long as they are broadly useful. I see them more as extensions of the language than a library. Though, in a way, that's basically what libraries are too. I'll have to think about this some more but at the moment I'm leaning towards inclusion in utiliD. Mike
Re: DConf 2019 Day 2 Livestream
On Thursday, 9 May 2019 at 07:45:41 UTC, Andrei Alexandrescu wrote: Just checked, it works: https://youtu.be/Vj6jNAlv03o Thank You!
Re: DConf 2019 Livestream
On Wednesday, 8 May 2019 at 08:21:33 UTC, Thomas Brix Larsen wrote: I am able to join with Firefox. I can see the video, but no audio. I'm still troubleshooting. Mike I had to click Audio Connection -> Computer to get audio. You mean the "Call using computer" option. That gives me an error: "Can't Call Using Computer, We're having a problem connecting to audio using your computer. Choose another audio connection option or try again." I guess it's unique to my computer. I'll have to try from another computer. Can you see Walter's presentation though? It looks like just an overexposed whitewash. I can't see anything on the presentation screen except white. Mike
Re: DConf 2019 Livestream
On Wednesday, 8 May 2019 at 08:00:15 UTC, Andrej Mitrovic wrote: On Wednesday, 8 May 2019 at 07:57:40 UTC, Mike Parker wrote: The venue uses WebEx for livestreaming. All the information is available in this PDF: https://drive.google.com/open?id=1yekllbfOmxHqJNuuWIVeP9vNeROmfp1I "When joining: Please connect using Internet Explorer, not Google Chrome or another web browser." You guys can't be serious, you're using WebEx? I am able to join with Firefox. I can see the video, but no audio. I'm still troubleshooting. Mike
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Sunday, 5 May 2019 at 05:23:26 UTC, Eugene Wissner wrote: you may remember that I'm working on a library named "tanya" (https://github.com/caraus-ecms/tanya). It is now almost phobos-free and I reimplemented some routines from libc for x86-64 linux. Ideally I'd like to get rid of libc for some platforms. While the library isn't interesting for you since it's too high-level, it could be based on something like utilD. So, as for me, I'd be very much interested in collective effort in this direction and can contribute. Excellent! Yes, I remember seeing tanya. As you can tell I have very few details worked out with regard to utiliD. You obviously have some more experience creating such a library. I see that https://github.com/caraus-ecms/tanya/tree/master/arch/x64/linux/memory has what appears to be something equivalent to memcpy, memcmp, and memset. I am very interested in having D implementations of those (inline assembly is D) but I also want to explore the idea keeping things strongly-typed (as least as long as possible) and utilize design-by-introspection to branch the implementation. I'd be interested in hearing more about what you have in mind. Thanks, Mike
Re: DStep 1.0.0 on the Blog
On Monday, 22 April 2019 at 12:24:16 UTC, Mike Parker wrote: To coincide with the announcement of DStep 1.0.0, Jacob submitted a post to the D Blog that goes into detail on all the new stuff included in this release. The blog: https://dlang.org/blog/2019/04/22/dstep-1-0-0/ Reddit: https://www.reddit.com/r/programming/comments/bg1ezr/dstep_100_generate_d_bindings_from_c_and/ Nice work, Jacob! Very cool! Mike
Re: New DConf Blog Post
On Friday, 12 April 2019 at 17:55:28 UTC, Piotrek wrote: Coding guidelines like MISRA and AUTOSAR have been developed and matured for C++ for years. There is no equivalent for D for it to be even considered by the automotive industry. Well, MISRA is an evidance that C (C++) is quite error prone by desing. I think, D can do better, . And the lack of dedicated tools is just a consequence of shortage on funds. And I always say that the fact that C needs so many different tools (including those for AUTOSAR) is its disadventage actually (they consumes a lot of money and development time). But it is how the World works now. But who knows the furure? ;) +1
Re: Spasm 0.1.3 released - with bindings to web apis
On Saturday, 26 January 2019 at 10:24:05 UTC, Sebastiaan Koppe wrote: Spasm is a betterC library for web development that uses LDC to compile to WebAssembly, and I just released a major update. It now has bindings to most web api's, like the dom, fetch, audio, webgl, etc. [...] See the repo for more info: https://github.com/skoppe/spasm It is still a WIP but I am getting there. This is really cool; nice work! Over the past 6 months I've been working a lot with .Net's WASM implementation, code-named Blazor. I estimate I can build GUI applications at 20% the development cost, while also getting portability, and a more rich features set (alpha transparency, flow layout, SVG, video, GL, etc...). Bundled with Electron, it makes for a convenient cross-platform application GUI framework. It's actually changed everything I do for desktop and ARM Cortex-A embedded GUI work (still need something for Cortex-M, though), and I don't think I'll be going back. The upcoming .Net Core 3.0 will include something called Razor Components, previously called Server-Side Blazor. It uses Microsoft's SignalR (think web sockets) to create signals on the server, slots on the client, and to push UI render changes to the client. Are you aware of SignalR, and do you see something similar eventually being added to Spasm? Also, what are the limitations that prevent the D runtime (just druntime, not Phobos) from being ported to WASM? Again, nice work! Mike
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 05:31:27 UTC, Paul Backus wrote: When something like an object system is made part of the language (or at the very least, the standard library), it becomes a focal point [2] that the community can coordinate around. Due to the diverse, distributed nature of any programming-language community, trying to coordinate through explicit communication is not really a viable option, so having these kinds of focal points is very important if we want to be able to work together on anything. [1] http://winestockwebdesign.com/Essays/Lisp_Curse.html [2] https://en.wikipedia.org/wiki/Focal_point_(game_theory) I think D's structs are a sufficient object system for such a focal point. With design by introspection, `alias`, templates, `alias this`, `static if`, CTFE, mixins, and a few new D features, classes would be unnecessary. Rust and Zig are pretty good examples of this. D's implementation could even be improved to keep its runtime, yet still allow D to be used as I'm suggesting, without introducing any breakage for anyone. I made some significant progress in that direction when I was working on the compiler in the 2017~2018 timeframe, but my abilities ultimately fell short, and I couldn't see a way forward without support. Mike
Re: My Meeting C++ Keynote video is now available
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 I especially like how design by introspection was contrasted with concepts and metaclasses, culminating in "We want to generate more smart code, not more boilerplate. We want to generate code that matters." Indeed. But what language features do we already have that are as "bo-riing" as concepts and metaclasses? What I wonder is, with design by introspection and the right mix of other language features (e.g. `alias`, `alias this`, mixins, etc...), what traditional language features can be removed from the compiler and delegated to library facilities? For example, https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html Because design by introspection allows us to "assemble programs atomically", perhaps high-level language features like classes and interfaces can become obsolete, and the language itself can be reduced simpler primitives that don't require the overhead of a runtime. Mike
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 14:38:25 UTC, Steven Schveighoffer wrote: @property: This was almost about to be awesome, but squabbling amongst the D core team killed it. Yes, the problem with @property is that it is neither correctly implemented nor completely implemented. And to do the former something will have to break. Note that you can't use binary assignment operators on parentheses-less function calls, and returning by ref is not a solution either. Not only does that break encapsulation, but some @property functions may not return an addressable lvalue (e.g. when working with bitfields). One might be able to fix the @property implementation, but now, there's so much disdain for the incorrect, incomplete @property implementation it's going to take some serious sweetener to remove the bitter taste from some people's mouths. Mike
Re: A brief survey of build tools, focused on D
On Monday, 10 December 2018 at 18:27:48 UTC, Neia Neutuladh wrote: I wrote a post about language-agnostic (or, more accurately, cross- language) build tools, primarily using D as an example and Dub as a benchmark. Spoiler: dub wins in speed, simplicity, dependency management, and actually working without modifying the tool's source code. https://blog.ikeran.org/?p=339 Why not just write your build/tooling scripts in D? That's what I prefer to do, and there's been a recent effort to do just that for the DMD compiler as well: https://github.com/dlang/dmd/blob/master/src/build.d It still resembles the makefiles it was modeled from, but in time, I think it will clean up nicely. Mike
Re: DMD backend now in D
On Sunday, 11 November 2018 at 23:40:16 UTC, Walter Bright wrote: As: https://github.com/dlang/dmd/pull/8946 removes the header files for the old C++ code! This is a significant milestone. Congratulations, Walter! There are still a few .c files in https://github.com/dlang/dmd/tree/master/src/dmd/backend, so what's the significance of those? Will there ever be a day when we no longer need a C/C++ compiler to build DMD? Has that day arrived? Mike
Re: Add D front-end, libphobos library, and D2 testsuite... to GCC
On Monday, 29 October 2018 at 03:43:49 UTC, Mike Parker wrote: Congratulations are in order for Iain Buclaw. His efforts have been rewarded in a big way. Last Friday, he got the greenlight to move forward with submitting his changes into GCC: Congratulations! Iain. It's an extraordinary accomplishment. I salute you. Mike
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 12:08:37 UTC, Martin Nowak wrote: Seems like they knew most artifacts within the installer by now, scanning for the submitted binary was a lot faster than last time. I guess we should keep an eye on this for the next releases, could you take care of this Mike? Take care of what exactly? What specifically needs to be done?
Re: Release D 2.082.0
On Sunday, 2 September 2018 at 01:05:10 UTC, Martin Nowak wrote: Glad to announce D 2.082.0. The Windows installer gave me no warning messages this time. Thanks, everyone. Mike
Re: RFC: initial release of dtoh
On Friday, 24 August 2018 at 10:09:07 UTC, Uknown wrote: This is all very nice. I agree that this kind of thing should be a part of the compiler, but I think it should be a compiler plugin. If dmd had compiler plugins, I think stuff like this and `dpp` would be much nicer to use. I agree. We also need compiler plugins for things like this: https://github.com/dlang/dmd/pull/6961 Mike
Re: Beta 2.082.0
On Saturday, 18 August 2018 at 08:22:54 UTC, Mike Franklin wrote: It's a little old, but from what I'm reading we need "reputation" with Microsoft or an EV certificate, or publish on the Windows Store. I'm also reading that once the executable has been downloaded a number of times from different IP addresses, it will be registered as safe in Microsoft's database. Maybe we just need to wait for more people to download it and run it. Mike
Re: Beta 2.082.0
On Saturday, 18 August 2018 at 08:04:41 UTC, Mike Franklin wrote: I'll research a little and see if I can find some more information. This thread was also quite informative: https://stackoverflow.com/questions/12311203/how-to-pass-the-smart-screen-on-win8-when-install-a-signed-application It's a little old, but from what I'm reading we need "reputation" with Microsoft or an EV certificate, or publish on the Windows Store. Mike
Re: Beta 2.082.0
On Saturday, 18 August 2018 at 08:04:41 UTC, Mike Franklin wrote: I'll research a little and see if I can find some more information. Ok, so it is indeed signed: https://imgur.com/a/jGdoXSc I found this which was disappointing: https://stackoverflow.com/questions/39833000/avoid-windows-protected-your-pc-message-for-a-authenticode-cert-signed-install Mike
Re: Beta 2.082.0
On Saturday, 18 August 2018 at 08:04:41 UTC, Mike Franklin wrote: I get the "Windows Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk" message. In other words this: https://cdn1.tekrevue.com/wp-content/uploads/2017/09/windows-protected-your-pc.jpg I'm running Windows 10. Mike
Re: Beta 2.082.0
On Saturday, 18 August 2018 at 06:52:21 UTC, Martin Nowak wrote: On Friday, 17 August 2018 at 22:01:29 UTC, Mike Franklin wrote: On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote: Windows installer and binaries are now code-signed - https://dlang.org/changelog/2.082.0.html#signed_windows_binaries Was this beta installer supposed to be signed? Because it doesn't seem to be. Yes it is signed and I actually checked it on Windows 7. What makes it appear to be unsigned on your system. I just downloaded it again. To be specific, this is the file I'm downloading and executing: downloads.dlang.org/pre-releases/2.x/2.082.0/dmd-2.082.0-beta.1.exe I get the "Windows Defender SmartScreen prevented an unrecognized app from starting. Running this app might put your PC at risk" message. In other words this: https://cdn1.tekrevue.com/wp-content/uploads/2017/09/windows-protected-your-pc.jpg It recognizes the publisher as "D Language Foundation" but I still don't think that message should be popping up. I'll research a little and see if I can find some more information. Mike
Re: Beta 2.082.0
On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.082.0 release According to https://issues.dlang.org/show_bug.cgi?id=18786 VirusTotal used to report a virus for the installer. This beta is now reporting clean: https://www.virustotal.com/#/file/dabf7c3b10ecb70025789c775756bee39bb401d7ef31f5a9131ff8760450fcab/detection Windows Defender also reports it as clean. Mike
Re: Beta 2.082.0
On Friday, 17 August 2018 at 20:01:32 UTC, Martin Nowak wrote: Windows installer and binaries are now code-signed - https://dlang.org/changelog/2.082.0.html#signed_windows_binaries Was this beta installer supposed to be signed? Because it doesn't seem to be. Mike
Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 09:43:13 UTC, Dukc wrote: On Saturday, 4 August 2018 at 02:39:23 UTC, Mike Franklin wrote: Cool! Can we now deprecate and eventually jettison C/C++ bindings from druntime, please? Why? The C standard library not a true and intrinsic dependency of D, and is outside of D's charter. There are druntime implementations that leverage the C standard library, but I believe that was largely done for expediency. If one wants to leverage the C standard library for a certain druntime implementation, that's fine, but it should be privately imported. D is a much more capable programming language than C, and whatever functionality is being imported from the C standard library can be better implemented in D with compile-time optimizations via templates, memory safety, and other benefits. Mike
Re: Symmetry Autumn of Code
On Sunday, 5 August 2018 at 04:47:42 UTC, tanner00 wrote: Hi, I’m interested in working on this project and just wanted to touch base. Is there any word on who will be mentoring this project? I’m entering college this fall but I’ve been programming since a very young age and enjoy systems programming. The project is mostly about creating high-performance, resource-efficient 2D software rasterizer, something like this (http://nothings.org/gamedev/rasterize/) or (https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445) If that isn't enough work for the event you can build on it by creating path objects with clipping and offsetting (http://angusj.com/delphi/clipper.php), rasterizing TrueType or OpenType fonts, creating drawing primitives, and even potentially creating 2D widgets (buttons, text labels, etc.) I think it's up to you how much of it you want to take on. I proposed the idea, but I don't think I'd be a very good mentor for the project because I've never created a 2D rasterizer myself. However, I'd be happy to help anyone working on the project in an unofficial capacity, and can probably articulate the intended use case for it. Mike
Re: Dpp on run.dlang.io
On Saturday, 4 August 2018 at 01:27:49 UTC, Laeeth Isharc wrote: Thanks to Seb and Atila it is now very easy to show a D program just #includeing C headers. If just works. Modulo bugs. In time I am hopeful Atila will start to have more of C++ headers working too. https://run.dlang.io/is/JlH3Th Cool! Can we now deprecate and eventually jettison C/C++ bindings from druntime, please?
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 10:24:14 UTC, Ecstatic Coder wrote: But this BetterC minimalistic standard library (allocations, arrays, strings, slices, maps) is something which can be reused by many similar hardware-level projects. This is a project on its own, and as I said, I think it should better be provided to the candidate so he can use his development time on developing the rasterizer, and, if there is enough time, a minimalistic nuklear-like gui system over it to demonstrate its performance and usefulness. Indeed, having to port the druntime to new hardware is definitely not in scope. I can't anticipate what features of the language the developer will employ, but as long as they stay within the -betterC subset of the language, I think it will be portable to something like that used in https://github.com/JinShil/stm32f42_discovery_demo Even if it isn't portable, if it compiles and runs in -betterC on a PC, it will still be an excellent foundation to build on, and I'd still call it a success. Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 09:52:54 UTC, Zheng (Vic) Luo wrote: Regarding floating point operations, I plan to use dmd.builtins/ldc.builtins instead of linking with libm. That reminds me. Something else to consider is that some of these microcontrollers don't have FPUs. Graphics libraries designed for microcontrollers often use fixed-point math as a lowest common denominator. I think, given the features of D, fixed-point or floating point could be selected at compile-time. But, I don't wish to expand the scope of the project. An all-floating point library would be fine, IMO, and fixed-poing math could be added to the library in a future iteration. Mike
Re: Symmetry Autumn of Code
On Sunday, 22 July 2018 at 17:12:31 UTC, Ecstatic Coder wrote: 2/ Nuklear (https://github.com/vurtun/nuklear) Reading the documentation for Nuklear, I found this: https://rawgit.com/vurtun/nuklear/master/doc/nuklear.html#drawing To draw all draw commands accumulated over a frame you need your own render backend able to draw a number of 2D primitives. This includes at least filled and stroked rectangles, circles, text, lines, triangles and scissors That's basically what the Autumn of Code proposal would like to have built in D: A rasterizer with fundamental drawing primitives. So, it seems Nuklear is a library intended to be built on top of the proposed rasterizer. Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote: Should we assume a multi-threading model? I say, no. To get threads on microcontrollers, you typically first need to implement a Real-time Operating System (RTOS). If you want to implement an RTOS in D, and then build the rasterizer on that, that would be very cool!but also very challenging ;-) Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote: You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal. Yikes! too many typos there. It should say... You can put those software building blocks in their own module, and let the user of the software rasterizer library link in their own implementation if they wish to deviate from the spirit of the proposal. Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 06:24:04 UTC, Zheng (Vic) Luo wrote: Moreover, The term "dependency-free" in the project description often confuses me, because as a hardware-agnostic library the project does have to depend on external implementations like "sin"/"memset" or even "thread_start", and I'm not sure which kind of dependency is proper for this project: Should we assume a multi-threading model? Should this library rely on "malloc"/"free"? Correct me if my understanding is wrong since I had few experience on embedded programming. There is more to this project than just getting a software rasterizer in D. Part of the goal is to demonstrate D as a formidable alternative to C in micrcontroller firmware programming. D will never achieve that notoriety if it's always depending on C, the C runtime, the C standard library, or some library implemented in C. So, IMO, if you need to link in a library or object file that was not compiled from D code, then you're cheating. This is also one of the reasons why I suggested re-implementing software building blocks such as `memcpy`, `memset`, `malloc`, `free`, etc. in D as another potential project for the Autumn of Code. So, to keep this software rasterizer project within scope, I suggest creating naive implementations of those functions in D for now to stay true to spirit of the project (no dependencies, everything in D), and "make the point". You can those software building blocks in their own module, and let the user of the software rasterizer library link it their own implementation if they wish to deviate from the spirit of the proposal. Mike
Re: Symmetry Autumn of Code
On Monday, 23 July 2018 at 06:00:14 UTC, Zheng (Vic) Luo wrote: Thank you for the suggestion. Previously I interned at a VR company and had some experiences writing code related to graphics, but I don't have any experience on embedded system programming, so I was wondering that do I need to buy a microcontroller or just testing it on PC would be enough? If it's the former one, could you give some suggestions on the starter kit? Well, I won't be the one paying you, and I don't think I'll be the one evaluating your work, so I don't think my opinion matters, but as the one who proposed the idea, I'll just explain my point of view. Microcontrollers have limited CPU and memory resources. Generally, they operate by filling a dedicated buffer in RAM (width * height * pixel_format_size) with pixel data. The size and format of the pixel data is generally decided at compile-time based on the needs of the application. Some microcontrollers have a dedicated hardware peripheral to aid in the blitting and blending of pixel data, but most don't. So, for all intents and purposes, this project is a software rasterizer in D; you definitely won't find any CUDA cores here. Understanding the capabilities and limitations of the microcontrollers will give you some perspective and understanding about the design tradeoffs you will most certainly need to make, but, once you have that perspective, in the end, you're just filling a buffer with pixel data, and I don't see why one couldn't do the vast majority (if not all) of development for that on their PC. That being said, getting a low-speed MCU with as little memory as 256KB animating an LCD display can be a thrilling experience. If you're interested, I suggest obtaining one of the STM32 Discovery Kits with a built-in LCD screen. See https://www.st.com/en/evaluation-tools/stm32-mcu-discovery-kits.html?querycriteria=productId=LN1848 (Typically one ofSTM32F4 or STM32F7 models) This is the one that I have, and it only costs about $30: https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/32f429idiscovery.html#samplebuy-scroll Furthermore, I've already created the platform code for you at https://github.com/JinShil/stm32f42_discovery_demo, so you should just need to import your library to main.d and try it out. Mike
Re: Symmetry Autumn of Code
On Saturday, 14 July 2018 at 06:02:37 UTC, Mike Parker wrote: We're also in search of potential mentors and ideas for student projects I posted a number of different ideas for ROSEdu Summer of Code at https://forum.dlang.org/post/aqlzjjfrwwxswptil...@forum.dlang.org. I believe those ideas could also be considered for Symmetry Autumn of Code. Mike
Re: Symmetry Autumn of Code
On Sunday, 22 July 2018 at 16:33:10 UTC, Zheng (Vic) Luo wrote: I'm interested in the "Graphics library for resource constrained embedded systems" project and have some spare time this autumn, but I have some questions: - Does this project aim at creating a hardware-agnostic rasterizer supporting a few primitives like https://skia.org/ or implementing a full GUI library like emWin rendering widget and handling I/O events such as mouse? The latter one sounds a little bit challenging to finish in four months I'm JinShil, the one who proposed the idea. As far as I'm concerned, if you're doing the work, you can make it into whatever you'd like, but I would consider a basic 2D, anti-aliasing rasterizer to be a success. I have in mind something like http://www.antigrain.com or Skia. A bonus would be a font renderer that leverages the aforementioned rasterizer (See also https://medium.com/@raphlinus/inside-the-fastest-font-renderer-in-the-world-75ae5270c445). The software should be efficient enough to use on embedded systems like https://github.com/JinShil/stm32f42_discovery_demo Under that constraint, you'd probably want to try to accomplish the task with the -betterC-like subset of the language (https://dlang.org/spec/betterc.html). That being said, there's no reason the software couldn't be used on a PC with resources to spare, and it would probably be easier to do the development on a PC and just verify the implementation on an microcontroller periodically. I, myself, don't have much experience in graphics, so I don't know if I'd be a very good mentor, but if you have any questions about the goal or use case for the project, let me know. - In the past year I primarily wrote C++ and don't have much experiences with production-level D programming, can I get involved into this program? I think much of your experience with C++ will carry forward to D, but there will still be a learning curve. Mike
Re: LDC 1.11.0 beta
On Thursday, 5 July 2018 at 09:40:46 UTC, kinke wrote: I failed to see a benefit from being able to use classes with static members only (abuse as namespace?) Yeah, pretty much, but also static inheritance. You can see the pattern where I use it at https://github.com/JinShil/stm32f42_discovery_demo/blob/c324bbf861cf258a819478481521528fca88dcb3/source/stm32f42/pwr.d#L24 It's for an ARM Cortex-M microcontroller. The structure, layout, and memory locations of all memory-mapped IO registers (there are 100s of them) are all known at compile-time, so there's no need for instances of anything. The static inheritance allows me to reuse implementation code and also model the hierarchy according to my mental model. After all that's one of the pillars of D, modeling power. Also, modeling them as static classes allows me to avoid the memory layout mess in the linker script (Yuck!), as all the memory addresses accompany the code itself. This also makes it much, much easier to cross-reference the code to the microcontroller's datasheet. D's the only language I know of that can do this; it's not a strength, not a weakness. Mike
Re: LDC 1.11.0 beta
On Thursday, 5 July 2018 at 10:57:17 UTC, Mike Franklin wrote: I failed to see a benefit from being able to use classes with static members only (abuse as namespace?) Yeah, pretty much, but also static inheritance. You can see the pattern where I use it at https://github.com/JinShil/stm32f42_discovery_demo/blob/c324bbf861cf258a819478481521528fca88dcb3/source/stm32f42/pwr.d#L24 Also, it allows me to dot-walk the hierarchy in my editor with code-completion and documentation comments. I describe this and illustrate with images in the readme. https://github.com/JinShil/stm32f42_discovery_demo Mike
Re: LDC 1.11.0 beta
On Wednesday, 4 July 2018 at 20:38:54 UTC, kinke wrote: Glad to announce the first beta for LDC 1.11. Thanks for all the work on this. I notice the minimal2.d test from the DMD test suite is disabled: https://github.com/ldc-developers/dmd-testsuite/blob/977ef0696f7941357385925c07617544c3527f4c/runnable/minimal2.d#L5 How permanent/temporary is that? Is there something blocking the implementation? Mike
Re: Encouraging preliminary results implementing memcpy in D
On Monday, 18 June 2018 at 02:31:25 UTC, Mike Franklin wrote: Unfortunately the code gen is quite a bit worse: Scratch that. If compiling with -O it seems to do the right thing. Mike
Re: Encouraging preliminary results implementing memcpy in D
On Sunday, 17 June 2018 at 17:00:00 UTC, David Nadlinger wrote:
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).
Yes, I'm already aware of that. My plan is to create optimized
implementations for aligned data, and then handled unaligned data
as compositions of the various aligned implementations. For
example a 3 byte copy would be a short copy plus a byte copy.
That may not be appropriate for all cases. I'll have to measure,
and adapt.
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.
Thanks! I think you're right.
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).
Unfortunately the code gen is quite a bit worse:
Exibit A:
https://run.dlang.io/is/jIuHRG
*(cast(void16*)()) = *(cast(const void16*)());
_Dmain:
pushRBP
mov RBP,RSP
sub RSP,020h
lea RAX,-020h[RBP]
xor ECX,ECX
mov [RAX],RCX
mov 8[RAX],RCX
lea RDX,-010h[RBP]
mov [RDX],RCX
mov 8[RDX],RCX
movdqa XMM0,-020h[RBP]
movdqa -010h[RBP],XMM0
xor EAX,EAX
leave
ret
add [RAX],AL
.text._Dmainends
Exhibit B:
https://run.dlang.io/is/PLRfhW
storeUnaligned(cast(void16*)(), loadUnaligned(cast(const
void16*)()));
_Dmain:
pushRBP
mov RBP,RSP
sub RSP,050h
lea RAX,-050h[RBP]
xor ECX,ECX
mov [RAX],RCX
mov 8[RAX],RCX
lea RDX,-040h[RBP]
mov [RDX],RCX
mov 8[RDX],RCX
mov -030h[RBP],RDX
mov -010h[RBP],RAX
movdqu XMM0,[RAX]
movdqa -020h[RBP],XMM0
movdqa XMM1,-020h[RBP]
movdqu [RDX],XMM1
xor EAX,EAX
leave
ret
add [RAX],AL
.text._Dmainends
If the code gen was better, that would definitely be the way to
go; to have unaligned and aligned share the same implementation.
Maybe I can fix the DMD code gen, or implement a `copyUnaligned`
intrinsic.
Also, there doesn't seem to be any equivalent 32-byte
implementations in `core.simd`. Is that just because noone's
bother to implement them yet? And with AVX512, we should
probably have 64-byte implementations as well.
Mike
Re: Encouraging preliminary results implementing memcpy in D
On Thursday, 14 June 2018 at 20:35:23 UTC, baz wrote: I asked on IRC yesterday and actually tHose memcpy are not the memcpy we use to copy wide chunks, apparently it's rather for an internal druntime thing, i.e cpy type to type so likely always aligned. Correct! D already has features like `a[] = b[]` so there is no reason to call `memcpy` directly; that is a job for the druntime. `memcpyD` is intended to be an internal druntime utility. However, we should still be good D citizens when we write our low level druntime code, so the interface will be `memcpy(T)(T a, T b)` and `memcpy(T)(T[] a, T[] b)` instead of `memcpy(void* a, void* b, size_t size)`. This will ensure the code, at compile-time, adheres to D's guarantees such as `@safe`, `nothrow`, and `pure`. And, given that it won't require `TypeInfo` it will be usable in -betterC. Although rare, I believe it is still possible to have misaligned memory in D. My understanding is that misaligned copies usually involve copying smaller chunks of the memory until they are aligned, and then copying the aligned memory in larger chunks. I suspect that will work well with the D implementation. TL;DR, Unaligned memory will be handled after optimized aligned memory copies are implemented. Mike
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 12:45:26 UTC, Fra Mecca wrote: I get this on Linux 4.16.3-gentoo, AMD FX(tm)-6100 Six-Core Processor, 8GiB ram, using ldc2 -O3L: size memcpyC memcpyD 1 5 0 2 0 0 4 0 0 8 0 0 16 1519 0 32 1833 0 64 3816 0 128 7543 0 256 146500 0 512 194818 0 1024 329593 846142 2048 714945 1117132 4096 1596170 1803621 8192 5899818 6110026 16384 12338384 14141850 32768 24971315 26771484 65536 49806637 63260128 size memcpyC memcpyD 1 0 0 1 0 0 1 0 0 2 0 0 2 0 0 4 0 0 4 0 0 8 0 0 8 0 0 4 0 0 8 0 0 core.exception.AssertError@memcpyd.d(9): Assertion failure ??:? _d_assert [0xcaf056d5] ??:? [0xa015e7fe] ??:? [0xa0158cb0] ??:? void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll() [0xcaf29daf] ??:? _d_run_main [0xcaf29c7b] ??:? __libc_start_main [0xca160eeb] ??:? [0xa0158b29] Yes, optimizations are throwing code away. I'm working on it. Mike
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 08:55:40 UTC, drug wrote: Ubuntu 18.04 Linux 4.15.0-23-generic AMD® Fx(tm)-8350 eight-core processor × 8 size memcpyC memcpyD 1 51089 36921 2 45896 35733 4 46079 36200 8 48443 37509 16 48669 24925 32 52917 27787 64 55631 44928 128 84282 47795 256 107350 66009 512 159310 126795 1024 247683 452560 2048 440687 673211 4096 1129135 1304085 8192 4740910 4095254 16384 8389579 8874273 32768 16630336 17370310 65536 33032013 42904705 size memcpyC memcpyD 1 52354 28365 1 48407 28445 1 50264 30273 2 51312 27708 2 46138 28973 4 52753 28535 4 52150 27418 8 52220 27276 8 49625 27804 4 49356 33510 8 48529 27668 16 52662 135357 Interesting! I have an AMD 8370 running Windows 8, and I get more favorable results in Windows: size memcpyC memcpyD 1 45361 43626 2 55091 43791 4 70507 43714 8 50910 42854 16 63328 28831 32 72817 30790 64 76307 45823 128 97180 55368 256 164935 68362 512 230508 132100 1024 502189 490590 2048 892968 823070 4096 1896480 1456353 8192 4530645 4516681 16384 10886602 9921215 32768 21717080 19116839 65536 59787610 43549445 size memcpyC memcpyD 1 48770 30084 1 49169 30921 1 43370 30144 2 51404 27571 2 56002 29729 4 69588 29804 4 63743 29510 8 55492 29002 8 46752 31793 4 72673 28858 8 48989 27547 10 55527 121628 In your results, I see that for sizes 1024 and higher (that's when is dispatches to the REP MOVSB algorithm), the performance begins to degrade for Linux. I'm going to install Linux soon and see if I can fix that. Thanks for the data, Mike
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 10:13:13 UTC, Dukc wrote: On Wednesday, 13 June 2018 at 09:59:52 UTC, Mike Franklin wrote: The benchmark doesn't allocate any data; it's just copying data. Mike Ah of course. I was thinking other stuff while writing. Well, actually, I probably should divide that time by 10,000,000 to make a more accurate representation. Thanks for the feedback, Mike
Re: Encouraging preliminary results implementing memcpy in D
On Wednesday, 13 June 2018 at 09:40:05 UTC, Dukc wrote: If I read your benchmark graphs right, they claimed that allocating 16 kilobytes takes over 10^^6 usecs, with both mallocs. Doesn't that mean over a second, 16 kilobytes? Can't be! Are you confusing usecs with nsecs? The benchmark doesn't allocate any data; it's just copying data. Each benchmark is run 10,000,000 times to smooth out some of the entropy in the results: https://github.com/JinShil/memcpyD/blob/2e0d3c33ea876a25a04358a3ae505b2eba9f99cb/memcpyd.d#L78 The usecs in the graph is the time it takes to run the benchmark 10,000,000 times. Mike
Encouraging preliminary results implementing memcpy in D
I had a little fun today kicking the crap out of C's memcpy with a D implementation. https://github.com/JinShil/memcpyD Request for help: I don't have a Linux system running on real hardware at this time, nor do I have a wide range of platforms and machines to test with. If you'd like to help me with this potentially foolish endeavor, please run the program on your hardware and send me the results. Feedback, advise, and pull requests to improve the implementation are most welcome. Mike
Re: Looks like Digital Mars C++ is on the front page of HN at the moment!
On Thursday, 24 May 2018 at 01:52:24 UTC, Nick Sabalausky (Abscissa) wrote: "C++, now powered by D" :) :) +1
Re: A bit more Emscripten
On Tuesday, 8 May 2018 at 08:53:36 UTC, Vladimir Panteleev wrote: I heard there was a bit of general interest on the subject, so would be interesting to hear about more potential use cases. I've been recently assigned the task of building a web-based Ladder Logic editor/compiler (https://en.wikipedia.org/wiki/Ladder_logic). This would not be a short-lived application, however. I'd like to use D so I can take advantage of its fantastic modeling features to help manage the complexity of building such tool. It would also be more familiar, and therefore more productive, for me to use a language like D, so I don't have to do so much study and figuring to implement my ideas in Javascript, or learn some new API/framework/library/tool/whatever. One of my primary motivations for learning D is to avoid having to learn a different programming language for every different platform or problem domain: modeling power, modern convenience, and native efficiency are the trifecta for me (we should have kept that motto, IMO). Add some platform independence, and I'm extremely happy. For now, unfortunately, it looks like I'll probably be using primarily Javascript and C#. I'm not sure if I would be much help with this, but know that there is demand for it. I think the difficult part would be porting the D runtime to "browser" environment, and I'm not sure what's involved with that, especially given all platform dependencies that the runtime is currently bound to. Mike
Re: GDB + ddemangle
On Friday, 20 April 2018 at 10:36:25 UTC, drug wrote: 20.04.2018 13:03, Joakim пишет: You are aware that gdb has built-in support for demangling D for 3-4 years now? But how to enable it? It doesn't work out of box at least for me. I believe you enable it with `-demangle=dlang` The original announcement is here: https://forum.dlang.org/post/rvoqllpimfskvlabp...@forum.dlang.org There are a few posts on the forum with some example usages: https://forum.dlang.org/search?q=%22demangle%3Ddlang%22=1 Mike
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 3 April 2018 at 23:50:24 UTC, Arredondo wrote: I could not get this to work for me in the past (I'm using Windows 10). I saw this announcement so I decided to try again. I have a little more experience to share... std.process.ProcessException@std\process.d(753): Failed to spawn new process (The system cannot find the file specified.) 0x00384D1F 0x00384AD2 0x00382ADD This seems to appear due to the import timing feature. You can disable it in your settings with `"d.enableDMDImportTiming": false` Moreover, the extension is completely SPAMMING the output console, making it pop up constantly with endless messages like: The spam to the output console is normal (I think). It's actually quite useful when troubleshooting, and I don't think the popup window should show up uninvited. It doesn't for me, anyway. Mike
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 3 April 2018 at 23:50:24 UTC, Arredondo wrote: I could not get this to work for me in the past (I'm using Windows 10). I saw this announcement so I decided to try again. I'm using it in Windows 10 right now, but I did have trouble trying to upgrade an existing installation. To remedy that, try to first delete the %appdata%\code-d directory, and then open VS Code again. It should try to re-install serve-d, and I believe it will then succeed. mike
Re: Beta 2.079.0
On Friday, 23 February 2018 at 09:18:33 UTC, Jacob Carlborg wrote:
On 2018-02-19 11:49, Martin Nowak wrote:
Glad to announce the first beta for the 2.079.0 release, ♥ to
the 77
contributors for this release.
The following is a regression that breaks DWT:
extern (C) void foo(int) { }
extern (C) void foo(double) { }
The above used to compile but now results in:
main.d(2): Error: function main.foo(double) cannot be
overloaded with another extern(C) function at main.d(1)
Was reported before the beta was released [1].
[1] https://issues.dlang.org/show_bug.cgi?id=18385
Overloaded `extern(C)` functions has also been reported as a bug
at https://issues.dlang.org/show_bug.cgi?id=15217
Re: Beta 2.079.0
On Tuesday, 20 February 2018 at 08:46:02 UTC, meppl wrote: @"16.": https://dlang.org/changelog/2.079.0.html#minimal_runtime So, now someone could "easily" write his own memory managment for allocations who would be usually done by the default GC - e.g. classes? Easily? unlikely, but it's probably possible. For example, whenever you use `new` to instantiate a class, it calls `_d_newclass` (https://github.com/dlang/druntime/blob/098a08a9593a8e265a9b02da55bda53393f3d5c1/src/rt/lifetime.d#L66). You could potentially make that do something different. You will, unfortunately, need some implement some "infrastructure" to get it to work, namely `ClassInfo` which is an alias for `TypeInfo`. At the moment the runtime is heavily dependent on `TypeInfo` for type information that's already known at compile-time, which stinks. To mitigate that some of us are working on modifying the the compiler/runtime interface to use templates instead. That would allow implementing the runtime hooks without requiring so much of the infrastructure. Btw, this is all possible now even without the features of 2.079. 2.079 just allows one to do this more incrementally. It's still a long way from being a pleasant experience, but it's getting better. Mike
Re: Beta 2.079.0
On Monday, 19 February 2018 at 18:50:47 UTC, Dukc wrote:
Huh? Did I understand right? Just add an empty object.d into
your project and --BetterC is now basically needless, plus the
executable is most likely even smaller?
Kindof, but not exactly. The -betterC switch still adds some
nuance such as...
assert failures are directed to the C runtime library
https://dlang.org/spec/betterc.html
... just to name one.
Though, with 2.079, you should be much less constrained in your
no-/partial- runtime implementation.
For example, I'm exploring a minimal runtime implementation for
using D on bare-metal microcontrollers
(https://github.com/JinShil/stm32f42_discovery_demo) The device
tree (i.e. bus/peripherals/registers/bitfields) is statically
known at compile-time. I use this pattern to model the device
tree...
final abstract class RCC : Peripheral!(AHB1, 0x3800)
{
final abstract class CR : Register!(0x00,
Access.Byte_HalfWord_Word)
{
alias PLLSAIRDY = Bit!(29, Mutability.r);
alias PLLISAION = Bit!(28, Mutability.rw);
}
}
https://github.com/JinShil/stm32f42_discovery_demo/blob/93f2c53578a18e8ce8e6a3985db14f361590f07f/source/stm32f42/rcc.d#L24
That would be impossible with -betterC, because -betterC doesn't
support classes.
I suspect others will find more compelling use cases.
With 2.079 it may also be possible to implement certain features
of D that are disabled in -betterC by providing custom
implementations of runtime hooks
(https://wiki.dlang.org/Runtime_Hooks) or other features in the
runtime.
I'm of the opinion, however, that with the right changes to the
compiler-runtime coupling, as demonstrated in 2.079, a better C
can be achieved without the -betterC compiler switch. There's
still more work to be done, though, and the -betterC compiler
switch will still have its uses. It should be noted, however,
that it was the work done on -betterC that made the changes in
2.079 possible.
Mike
Re: The Expressive C++17 Coding Challenge in D
On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote: Someone revived the Expressive C++17 Coding Challenge thread today and I thought this is an excellent opportunity to revive my blog and finally write an article showing why I like D so much: https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d It's mostly targeted at beginners as I explain many basic D features, but maybe it's helpful for beginners looking into D. Nice work! I was recently asked by my employer "why D?". I think I need to show them this. Aren’t you concered that Rust is faster in this benchmark? Not at all. The challenge was to write expressive code and if performance really matters I can always opt to optimize the hot path of the program and don’t need to pay a > 4x code duplication cost upfront. You've gotta address this, IMO. What's the performance/expressiveness tradeoff like in D? Mike
Re: Official Dub package for DWT
On Wednesday, 7 February 2018 at 21:33:22 UTC, Jacob Carlborg wrote: This has been long overdue but I would like to announce that I've just released an official Dub package for the DWT library http://code.dlang.org/packages/dwt This is great! Nice work, and thank you! Mike
Re: run.dlang.io can now display ASM + AST + IR
On Saturday, 27 January 2018 at 01:31:45 UTC, Seb wrote: https://github.com/dlang-tour/core/pull/649 It's fixed now. I have also increased the maximal output limit to 500.000 bytes - I hope that's enough for everyone :O Seb, you're awesome! Thanks for all these great features. Mike
Re: Another take on decimal data types
On Monday, 8 January 2018 at 22:16:25 UTC, rumbu wrote: This is my first D finalized project (+16k loc). I know that there are other two projects intended to provide a decimal data type for D, but I consider mine the most complete and most compliant to the standards (at least until now). Wow!. So thorough. Documentation is fantastic. Very nice work, indeed! Mike
Re: Release D 2.078.0
On Thursday, 4 January 2018 at 17:40:55 UTC, David Nadlinger wrote: it would be fairly easy to manually look up the set of ModuleInfos in a druntime-less D program. ModuleInfo is declared and defined in druntime (https://github.com/dlang/druntime/blob/7bfaa8c0755771b807a8344b8c0bfcf73aec7c82/src/object.d#L1443). If one is doing a druntime-less build, how would it be possible have a set of `ModuleInfo`s to manually look up? Mike
Re: run.dlang.io - a modern way to run D code
On Thursday, 14 December 2017 at 06:26:16 UTC, Seb wrote: It's interesting to see that no one complained about gdc not being there - I thought that this would be the first comment. Allow me to be the first. But seriously, considering the use case for run.dlang.io, I don't see the need for hosting any compilers other than dmd-latest and dmd-nightly. Everything else is just gravy. Mike
Re: run.dlang.io - a modern way to run D code
On Tuesday, 12 December 2017 at 18:37:38 UTC, Seb wrote: After it has been in stealth mode for quite a while, I'm happy to announce that there's https://run.dlang.io I've actually been using it a lot recently to communicate bugs/ideas/patterns with others. Due to the nightlies, I can quickly see if a bug has been addressed in master. I've closed a couple of bugs recently with "worksforme" that way. I also use it to quickly try ideas when I'm out waiting somewhere, or just when an idea occurs to me. It is such a great resource. Thanks to those who put their time into it. Mike
