Re: Using D for Raspberry Pi expirements
On Sunday, 29 September 2019 at 11:36:00 UTC, aberba wrote: I have no idea how to do that from D. Any help/resources on that? You should be able to use the techniques at https://dlang.org/spec/interfaceToC.html to declare the C functions that you wish to use in your *.d source files, and then, when you compile, pass `-lpigpiod_if2` to the linker. Mike
Re: Using D for Raspberry Pi expirements
On Wednesday, 25 September 2019 at 23:56:45 UTC, aberba wrote: I'm looking for resources on using D for basic Raspberry Pi programming...stuff like turning on and off an LED light. I believe it requires being able to call the Raspberry OS core APIs from D as available in Python. Anyone here tried something like that using D? I haven't tried with D yet, but I use C# and mono calling into the pigpio C library (http://abyz.me.uk/rpi/pigpio/pdif2.html) and it workes great. You should be able to do the same with D. Mike
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: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 18:37:49 UTC, Jonathan M Davis wrote: There's probably at least one bug report on it, but as I understand it, it's not a bug in the sense that the implementation is currently expected to handle such a case. It's an area where betterC should be improved upon, but it would be an enhancement, not a bug fix. Yes. The point is that libraries have to be written with betterC and compile-time evaluation in mind. If they aren't the code is likely not going to work in those use cases. Much of the code in Phobos was written long before betterC was introduced. There are probably changes that could be made to Phobos so the OP could get a build, but that requires someone with enough interest in the issue to volunteer their time and talent to improve the implementation for betterC and compile-time use cases. We have a GSoC student making changes the druntime to help with this matter and I have been picking away at it too. It will take time and could use more contributors. Mike
Re: Is betterC affect to compile time?
On Thursday, 25 July 2019 at 12:01:40 UTC, Oleg B wrote:
Hello everyone!
I try build this code with betterC
import core.stdc.stdio;
import std.format : format;
extern(C) int main()
{
mixin(format!`enum str = "%s\0";`("hello"));
fprintf(stderr, "%s\n", str.ptr);
return 0;
}
but compilation fails
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6278):
Error: Cannot use try-catch statements with -betterC
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6308):
Error: template instance
`std.format.checkFormatException!("enum str = \"%s\\0\";",
string)` error instantiating
onlineapp.d(6):instantiated from here: format!("enum
str = \"%s\\0\";", string)
/dlang/dmd/linux/bin64/../../src/phobos/std/format.d(6311):
while evaluating: static assert(!e)
/dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3204):
Error: TypeInfo cannot be used with -betterC
Is this a bug?
https://run.dlang.io/is/TG1uhg
If you read the documentation for betterC
(https://dlang.org/spec/betterc.html#consequences) you'll see
that there are features of the D language which are not
supported. Therefore, libraries that use such features (e.g.
std.format, std.array) are also not supported, and that is why
you are encountering such errors.
There are some features of Phobos which can be used in betterC
builds, but you're going to find that it's hit-and-miss.
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: DWT doesn't compile with dmd 2.87.0
On Sunday, 14 July 2019 at 17:00:53 UTC, Patrick Schluter wrote: DWT doesn't build anymore with the new compiler. Wasn't DWT supposed to be part of the build job of compiler so that regressions are caught in time? It's not a regression; deprecations are a normal progression for evolving the language. Please just submit a PR to DWT to bring the code up to modern expectations. 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: Stack-based @nogc dynamic array
On Thursday, 16 May 2019 at 12:16:26 UTC, Marco de Wild wrote:
Or are there any tips to roll my own implementation?
I took a stab at it:
---
@nogc:
nothrow:
pure:
struct NoGcArray(size_t maxSize, T)
{
private T[maxSize] _buffer;
private T[] _slice;
private size_t _frontIndex;
size_t length() const
{
return _slice.length;
}
void opOpAssign(string op)(T element)
{
static if(op == "~")
{
_buffer[_frontIndex + length] = element;
_slice = _buffer[_frontIndex..(length + 1)];
}
else
{
static assert(false, "Only concatenation supported");
}
}
T opIndex(size_t index) const
{
return _slice[index];
}
T front() const
{
return _slice[0];
}
void popFront()
{
_frontIndex++;
_slice = _slice[1..$];
}
bool empty() const
{
return _slice.length == 0;
}
}
void main()
{
import std.algorithm : sum, map;
NoGcArray!(4, int) array;
array ~= 420;
array ~= 42;
assert(array.map!(x => x*2).sum == 924);
}
---
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: Do @property attributes not allow postincrement operators
On Sunday, 14 April 2019 at 01:54:39 UTC, Jamie wrote:
Do @property attributes not allow postincrement operators?
import std.stdio;
struct Foo {
@property bar() { return 10; }
@property bar(int x) { writeln(x); }
}
void main()
{
Foo foo;
writeln(foo.bar); // actually calls foo.bar();
foo.bar = 10; // calls foo.bar(10);
// following doesn't work
foo.bar++; // would expect this to call foo.bar(foo.bar() +
1);
// have to use:
foo.bar = foo.bar + 1;
writeln(foo.bar);
}
It's a long standing issue (going on 7 years old)
https://issues.dlang.org/show_bug.cgi?id=8006
There's an implementation at
https://github.com/dlang/dmd/pull/7079
It requires a DIP, which you can find at
https://github.com/dlang/DIPs/pull/97
However, in preparing that DIP other issues were discovered with
@property, so we need to create a DIP to fix those issues first.
I plan on getting to it, but there are other pressing things I'm
trying to get out of the way.
Mike
Re: Where is GDC being developed?
On Thursday, 21 March 2019 at 22:51:21 UTC, James Blachly wrote: Thanks -- I also tried to figure out how to install GDC just yesterday and gave up. All wiki links and google top results seemed dead ends. I'm also a little puzzled by how GDC is structured, but I have learned a few things with the help of some of the GDC developers, and I'll share my understanding below (though be aware that my assumptions may be wrong). GDC is in a weird state right now where it needs to boostrap itself. The bootstrap compiler has a front-end written in C++, but the lastest GDC on GitHub has a front-end written in D. My understanding is that this bootstrap compiler with the front-end written in C++ is what is being released with GCC 9. Since GCC always needs to be able to be built with a prior version of GCC, GCC 10 will be the first release with the latest D frontend. So, to build your own GDC compiler, you need to first build the bootstrap compiler. I have a script for that at https://github.com/JinShil/native-gdc Then, using the bootstrap compiler, you can build the latest GDC with the D frontend from GitHub. I have a script for that too, but it is only for building an ARM cross-compiler. See https://github.com/JinShil/arm-none-eabi-gdc Mike
Re: Where to start with SafeD?
On Wednesday, 13 February 2019 at 22:29:18 UTC, solidstate1991 wrote: When I tried to apply to a position at Symmetry, I've got a criticism from Atila Neves that some of my code relied too much on memcpy, thus making it unsafe. After digging into std.array, I found some function that could possibly replace it to emulate writing in the middle of a file, but at least for VFile, I need some type agnostic solution. I don't understand your use case, but for me, I try not to escape the type system. Instead of using void*, I recommend templating. That is the approach I took here: https://github.com/JinShil/memcpyD It still does explicit casts to prevent code bloat, which is still escaping the type system, but at least it avoids pointer arithmetic. I'm not sure if that's helpful, but regardless, there it is. Mike
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: int/longRe: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Friday, 14 September 2018 at 23:08:34 UTC, Nicholas Wilson wrote: On Friday, 14 September 2018 at 13:41:40 UTC, Mike Parker wrote: DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool", is now ready for Final Review. This is a last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage: https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review The current revision of the DIP for this review is located here: https://github.com/dlang/DIPs/blob/299f81c2352fae4c7fa097de71308d773dcd9d01/DIPs/DIP1015.md In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on September 28 unless I call it off before then. Thanks in advance for your participation. Small typo under Breaking Changes and Deprecations "4. After the time period specified in step 4 has elapsed, stage 2 can be merged." should be "4. After the time period specified in step _3_ has elapsed, stage 2 can be merged." Thanks! https://github.com/dlang/DIPs/pull/134/files The only thing I think is missing is a flag to accelerate the process s.t. the examples f(E.a); f(E.b); g(a - b); can be made to call their int/long overloads straight away. But otherwise, er, no. A resounding yes with a small request to make the transition faster! I'm not too keen on adding a compiler flag, because then I have to worry about deprecating the compiler flag. I don't know if the bugs that this DIP fixes are serious enough to justify it. I'd be happy to add it if others are willing to voice their support for it, demonstrating sufficient demand. Or, I suppose I could add it as an option for Walter and Andrei to approve or reject on judgement day. Mike
Re: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Saturday, 15 September 2018 at 20:07:06 UTC, Steven
Schveighoffer wrote:
Looks pretty good to me. The only question I have is on this
part:
enum YesNo : bool { no, yes } // Existing implementation: OK
// After stage 1: Deprecation
warning
// After stage 2: Error
// Remedy: `enum YesNo : bool {
no = false, yes = true }`
Why is this necessary? I can't see how there are integer
literals being used here, or how implicitly going from `false`
to `true` in the 2 items being enumerated is going to be
confusing.
You're right, I just tested the implementation, and this is not
necessary. I'll remove it. Thanks!
Mike
Re: What changes to D would you like to pay for?
On Wednesday, 5 September 2018 at 07:00:49 UTC, Joakim wrote: The D foundation is planning to add a way for us to pay for changes we'd like to see in D and its ecosystem, rather than having to code everything we need ourselves or find and hire a D dev to do it: "[W]e’re going to add a page to the web site where we can define targets, allow donations through Open Collective or PayPal, and track donation progress. Each target will allow us to lay out exactly what the donations are being used for, so potential donors can see in advance where their money is going. We’ll be using the State of D Survey as a guide to begin with, but we’ll always be open to suggestions, and we’ll adapt to what works over what doesn’t as we go along." https://dlang.org/blog/2018/07/13/funding-code-d/ I'm opening this thread to figure out what the community would like to pay for specifically, so we know what to focus on initially, whether as part of that funding initiative or elsewhere. I am not doing this in any official capacity, just a community member who would like to hear what people want. Please answer these two questions if you're using or would like to use D, I have supplied my own answers as an example: 1. What D initiatives would you like to fund and how much money would you stake on each? (Nobody is going to hold you to your numbers, but please be realistic.) I'd be willing to pay at least $100 each for these two: https://issues.dlang.org/show_bug.cgi?id=19159 https://issues.dlang.org/show_bug.cgi?id=18788 Quite honestly, though, I probably wouldn't do it myself for $100. These bounties really need to be $500 or more. If D is to be funded by individuals, there needs to be some way to organize individuals around common interest and raise funds for those tasks. For example, the D Language Foundation has a "Corporate Bronze" offer on its OpenCollective page that includes 3 priority bug fixes per month for $12,000. If we could get 24 like-minded people, willing to contribute $500 each, and vote on priority bugs, that could potentially get things moving in the right direction. That would be 1 1/2 bugs per contributor. I don't think that's bad. I'd be willing to join such a collective if I got at least 1 priority bug fix out of it. Even better, IMO, it'd be nice if the "Individual Sponsor" or "Organizational Sponsor" offers on the OpenCollective page included at least 1 priority bug fix. Mike
Re: What changes to D would you like to pay for?
On Thursday, 6 September 2018 at 01:24:35 UTC, Laeeth Isharc wrote: $500.00 to fix these three together - they may well be essentially the same bug: https://issues.dlang.org/show_bug.cgi?id=19179 https://issues.dlang.org/show_bug.cgi?id=5570 https://issues.dlang.org/show_bug.cgi?id=13957 According to BountySource (https://www.bountysource.com/teams/d/issues?tracker_ids=383571) Issue 5570 already has a bounty of $445. With the addition of your $500 that would make the bounty $945, which isn't bad. Mike
Re: Random thought: Alternative stuct
On Wednesday, 5 September 2018 at 18:41:15 UTC, Jacob Carlborg wrote: On 2018-09-04 06:03, Mike Franklin wrote: For that it needs to support all the features as classes do today. In that case, what would be the difference compared to classes? Indeed, the idea is that structs, with a few additional features added to the language, should be able to fill the role classes fill today. Polymorphism can be achieved in the library using methods similar to what Sarn demonstrated in the article I linked previously. Features like mixins can cut down on the boilerplate; other boilerplate-removing features would likely be needed. Multiple-alias-this and some form of `protected` for structs would be examples of additional features that would help to implement class-like behavior; again, others would also likely be needed. Reference semantics can be achieved much like C++ does today with it's smart pointers and things like `T&`. For example, D might have `GC` for garbage-collected types, `RC` for reference counted types, etc, so the ownership and reference semantics are delegated to a container type in concert with DIP1000-like features of some kind. In general, classes, to me, are looking more and more like syntax sugar over existing fundamental language features, and I think with the right supplemental language features for reducing boilerplate and encapsulate details, something very much like classes can be implemented in the library. I'm just thinking out-loud though. I doubt something like this will happen, especially without me or someone else demonstrating such a thing with a thorough proof-of-concept implementation. Mike
Re: Random thought: Alternative stuct
On Tuesday, 4 September 2018 at 03:38:41 UTC, Nick Sabalausky (Abscissa) wrote: We have classes and structs: Classes: - Default Storage: GC Heap - Indirection Overhead: Yes - Semantics: Reference - Passed By: Copying the Data's Address Structs: - Default Storage: Stack - Indirection Overhead: No - Semantics: Value - Passed By: Copying the Data (except where the compiler can determine it can safely and more efficiently pass by reference...at least, IIUC) But we seem to have a lot of need for stuff in-between: emplace for classes, @disable this and move/moveEmplace for structs. Actually there's even more overlap. `scope`-decorated classes are allocated on the stack. `new`-allocated structs are allocated on the heap. We have both `ref` and pointers for reference semantics on value types and structs. There are also a few additional differences. classes can inherit implementations, but using the technique illustrated in https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html, you can get something very much like classes. With `alias this` and multiple-`alias this` (https://github.com/dlang/dmd/pull/8378) it gets even better. Just tossing this out there: What if there was a third version, an alternate to struct that: - Prohibited implicit copying (perhaps unless the compiler knew the original was never used again?) - Was always passed by moving (except where the compiler can determine it can safely and more efficiently pass by reference)? - And, after passing it to a function, it would automatically be moved back to the caller (unless compiler can determine it doesn't have to bother). In my opinion, we shouldn't add a third option. Rather, we should deprecate classes, and make and expand the capabilities of structs. Languages like Zig and Rust have done away with classes and all runtime overhead that accompanies them, and are showing great promise by expanding on structs with much more composable features. My suggestion: forget about ProtoObject and investing more into the resource pit that is classes. Just make a better struct and supporting features so noone would even want to use classes anymore. Ie: Move-Structs: - Default Storage: Stack - Indirection Overhead: No - Semantics: Reference-like - Passed By: Moving the Data (except where compiler...blah blah blah) IIUC, this would give it the *effect* of reference semantics, but without the indirection (and vtable) overhead, and would allow it to perform RAII cleanup in its dtor when it goes out of scope without ever needing reference counting. Is this nothing more than reinventing the future "struct with copy constructor and @disable-ed default constructor...and...maybe some other necessary part of the idiom I'm overlooking"? Is it really just (badly) re-inventing some other XYZ except for differences UVW? Or would this be a horrible thing to exist? Any tweaks that would change it from a horrible idea to a fantastic one? Or is it all just total nonsense? It's not nonsense, but unless you're willing to invest your time and effort into doing something about it, it's equivalent to nonsense. 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: D is dead
On Friday, 24 August 2018 at 22:52:07 UTC, Steven Schveighoffer wrote: I really don't want to see dlang have to maintain posix system calls on all supported OSes when that's already being done for us. Windows makes this simpler -- the system calls are separate from the C runtime. It would be nice if Posix systems were that way, but it's both silly to reinvent the system calls (they are on every OS anyways, and in shared-library form), and a maintenance nightmare. Keep in mind that we only need to implement the system calls that we need. I haven't looked into Phobos, and probably never will. My interest is mostly in druntime. At this time, I think we only need 2: `sbrk` and `mmap` for `malloc`. I don't consider that much of a maintenance burden, and `malloc` and friends are my least concern at the moment. We're disproportionately leveraging libc in druntime; there are only a few things needed from libc for druntime, and I think I can demonstrate benefit writing them in D (or if someone else wants to, please do, I may never even get to it). If I even stick around in the D community long enough to pursue this, this change it'll be incremental and I'll demonstrate benefit each step of the way. Mike
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 13:21:25 UTC, Jonathan M Davis wrote: I think that you're crazy. No, I just see more potential in D than you do. Mike
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 11:15:21 UTC, Jonathan M Davis wrote: Linux is the only OS I'm aware of that considers the syscall layer to be something that anything outside the OS would normally call. I think Linux considers system calls the OS API. Other OSes consider libc to be part of the OS. Not Windows. Windows has it's own API, and when interfacing with the OS, I never use libc. In theory, you could call the syscalls directly in the BSDs (and probably on Mac OS), but the expectation is that you're going to use libc. That's the expectation for application programming, not systems programming. Calling them directly would be way more error-prone, since you'd basically have to reimplement portions of libc and have to deal with any changes they make which normally would be hidden by libc. Most of what we need is already implemented in the language, druntime, and Phobos. We just need a few fundamental building blocks that are currently implemented in C and a few calls into the OS APIs (syscalls for linux, Window API for Windows, not sure about Mac...probably syscalls). And just like DMD benefited from being written in D, so would those building-blocks, and the code that calls into them. You're basically trying to bypass the OS' public API if you're trying to bypass libc. No I'm trying to bypass libc and use the OS API directly. Honestly, I don't see how it's at all reasonable to be trying to access syscalls directly rather than using libc under any kind of normal circumstances - especially if you're not on Linux. I think it'd be nice if D were freestanding and portable without requiring libraries written in other languages. Purity, safety, CTFE, introspection, etc... all the way down. Mike
Re: Embrace the from template?
On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote: One idea is we could add this template to `object.d`. This would allow it to be used from any module that uses druntime without having to import it first. The template itself is also very friendly to "bloat" because it only has a single input parameter which is just a string, extremely easy to memoize. Also, unless it is instantiated, adding it to object.d will have virtually no overhead (just a few AST nodes which would dwarfed by what's already in object.d). It would also be very easy to add, a single PR with 4 lines of code to druntime and we're done. I don't know. It's not a bad idea, but I don't consider it a major enabler either. It's easy enough to just cut and paste it to one's arsenal, though I understand the inconvenience of having to maintain it in multiple projects. One thing to consider is `from` is a *very* general word, and if it's placed in object.d it might cause naming conflicts. I'd like the name to be more specific, but I know how such naming discussions tend to go. 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: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 09:46:08 UTC, Jonathan M Davis wrote:
For any kind of normal operating system, you _have_ to use
libc. It's part of the OS. Some pieces could be done without
it, but on the whole, you use libc if you want to talk to the
OS. That's just life. The only exceptions I'm aware of to that
are embedded devices, and my understanding is that if anything,
such devices are more and more likely to run a fullblown OS,
making it that much less likely that you'd ever do anything
without libc.
That is not true. You can write your own system calls. Here's
"hello world" with no libc:
---object.d
module object;
alias immutable(char)[] string;
private long __d_sys_write(long arg1, in void* arg2, long arg3)
{
long result;
asm
{
mov RAX, 1;
mov RDI, arg1;
mov RSI, arg2;
mov RDX, arg3;
syscall;
}
return result;
}
void write(string text)
{
__d_sys_write(2, text.ptr, text.length);
}
private void __d_sys_exit(long arg1)
{
asm
{
mov RAX, 60;
mov RDI, arg1;
syscall;
}
}
extern void main();
private extern(C) void _start()
{
main();
__d_sys_exit(0);
}
---main.d
module main;
void main()
{
write("Hello, World\n");
}
$dmd -c -lib -conf= object.d main.d -of=main.o
$ld main.o -o main
$size main
textdata bss dec hex filename
176 0 0 176 b0 main
$main
Hello, World
You just need to re-implement what you need in D. For Phobos,
that might be a big job (or maybe not, I haven't looked into it).
For druntime, it's not so bad -- it's mostly just memcpy,
memcmp, malloc, free, and maybe a couple of others. Those are
not trivial implementations, but it's not out of reach, and I
think there is opportunity with, with CTFE, templates, __traits,
inline asm, and a number of other D features, to do even better
than C, and make it more type- and memory-safe while we're at it.
Implementing those building-blocks in D, would be good for the
language, would solve a number of issues I'm currently having
with druntime updates, and would be a fun project for those that
are interested in that kind of stuff.
Mike
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 04:12:42 UTC, Jonathan M Davis wrote: Unless you're trying to argue for folks dropping Phobos, that's just not going to fly. Phobos uses libc heavily, and it really can't do what it needs to do without it (e.g. file operations). Divorcing druntime from libc may help folks focused on embedded development and who don't want to use Phobos, but for most D programs, it really doesn't provide any real benefit to try to make druntime not use libc. So, while such an effort may provide some benefits, I don't see how it could really be for anything other than a niche part of the community. It's not a problem for Phobos to depend on the C standard library. My goals have to do with making D, the language, freestanding (a.k.a nimble-D). If and when druntime no longer depends on the C standard library, the bindings can be moved to a separate repository (e.g. Deimos). A compatibility shim can also be created in a separate repository to forward `core.stdc` names to `c.std` or whatever name the new repository chooses. That compatibility shim could be marked deprecated in favor of the new name, and then many years down the line it can be removed (or kept, I don't care). It then becomes part of the toolchain packaging process to add Deimos-libc and the compatibility shim to the dmd.conf file and include it in the distribution. Users won't even know it happened. Users's coding in D, the language (no Phobos), will no longer have to obtain a C toolchain to generate their binaries. We're at least half a decade away from any of this, and there's a good chance it will never even happen, so don't sweat it. And about niche use case. They're niche right now because D doesn't provide good support for them, and noone's writing D software for them. If I have my druthers, that's going to change, and those use case will become major considerations when making language design choices, and it will become obvious that C is a more of a liability than an asset. Mike
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 00:58:35 UTC, Guillaume Piolat wrote: D programs tend to use the C runtime directly, and quite a lot of it: https://github.com/search?l=D=%22import+core.stdc%22=Code I know. They should get that from https://github.com/D-Programming-Deimos/libc or perhaps even Dub.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 00:53:20 UTC, Guillaume Piolat wrote: Do you also mean to reimplement everything related to FILE*? floating-point parsing and conversion to string? multithreaded malloc? Only what's need for druntime. That would include multi-threaded malloc, but not the FILE* string-related stuff.
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 00:32:59 UTC, Guillaume Piolat wrote: For example: why implement AVX in DMD backend? Who are the users that will be delighted by that? Those interested in performance already use some other back-end, it's imo a completely useless development since _no one_ use D_SIMD seriously apart from compiler tests (https://github.com/search?l=D=4=D_SIMD=Code) But I need it to implement `memcpy` and `memcmp` in D, so we can remove the dependency on the D standard library :-) https://github.com/JinShil/memcpyD I know. I'm weird. Phobos shouldn't even be a thing, we always read "hopefully this will be moved into Phobos" which is entirely wrong. People should be pushed to use the community to their advantage. SemVer is where it's at. Totally agree. It seems, from someone without much historical perspective, that Phobos was intended to be something like the .Net Framework for D. Perhaps there are a few fundamentals (std.algorithm, std.allocator, etc.) to keep, but for the others... move 'em to Dub and let the "free market" sort it out. Mike
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Friday, 24 August 2018 at 00:46:14 UTC, Mike Franklin wrote: But I need it to implement `memcpy` and `memcmp` in D, so we can remove the dependency on the D standard library :-) Gah! What a typo. I mean the C standard library.
Re: Is @safe still a work-in-progress?
On Thursday, 23 August 2018 at 23:36:07 UTC, Chris M. wrote:
Heck, now that I'm looking at it, DIP25 seems like a more
restricted form of Rust's lifetimes. Let me know if I'm just
completely wrong about this, but
I think DIP 25 is analogous to Problem #3 for Rust's Non-Lexical
Lifetimes:
http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/#problem-case-3-conditional-control-flow-across-functions
http://smallcultfollowing.com/babysteps/blog/2016/05/09/non-lexical-lifetimes-adding-the-outlives-relation/#problem-case-3-revisited
would basically be like (pseudosyntax)
@safe ref'a int identity(ref'a int x) {
return x; // fine
}
Maybe the more sane thing would be a syntax that visually ties
them together as above. Obviously we're looking at possibly
breaking changes, but how widespread would they be?
void betty(ref'a scope int* r, scope'a int* p); // syntax is
not so nice since I just arbitrarily stuck them on different
keywords, but that's besides the point here
I wish I had been more involved in D when DIP 25 and DIP 1000
were being proposed, as I don't think the designs were thoroughly
vetted. It's taken me at least a year to even begin getting a
grasp on it.
I think DIP 25 and DIP 1000 should have been combined and thought
of holistically as simply "annotated lifetimes in D" rather than
separate things. I think then it becomes easier to visualize
what the problem is and see, potentially many, alternatives.
Given the investments that have already been made in DIP 25 and
DIP 1000, it's going to take an extremely motivated individual to
fight an uphill battle to change direction now, I'm afraid. If
working on D was my full-time job, I'd do it, but who in this
community has such resources.
Mike
Re: D is dead
On Thursday, 23 August 2018 at 13:22:45 UTC, Shachar Shemesh wrote: Because in D, structs can't inherit, Forgive me if I'm not helping, but if you are willing to create a little infrastructure, I think you can create polymorphic structs with the technique described at https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html. See https://gitlab.com/sarneaud/xanthe/blob/master/src/game/player.d#L18 for a concrete example. I can't do that for structs, and if I defined SockAddr as a class, I'd mandate allocating it on the GC, violating the whole point behind writing Mecca to begin with. There are other ways to allocate memory for classes, without the GC. Do any of the techniques described at https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation give you an alternative? The general consensus, however, is that these problems will not be resolved (we used to file bugs in Bugzilla. We stopped doing that because we saw nothing happens with them), and as far as the future of the language goes, that's bad news. I've fixed 4 bugs in the past 2 weeks: https://github.com/pulls?utf8=%E2%9C%93=is%3Apr+author%3AJinShil+archived%3Afalse+is%3Aclosed+Fix But I admit they were quite simple. I agree, the more difficult bugs tend to not get fixed. I've tried to fix a few of them, but they were beyond my current abilities. Again, you might have more success if you put some financial incentive behind them. Mike
Re: D is dead
On Thursday, 23 August 2018 at 10:41:03 UTC, Jonathan M Davis wrote: Languages pretty much always get more complicated over time, and unless we're willing to get rid of more stuff, it's guaranteed to just become more complicated over time rather than less. "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery I think that's actually a mistranslation from what he actually said, but it's still quite good. I think that's a important point of focus. We should be trying to get rid of stuff. It's one of the reasons I've been trying to move forward on some of the deprecations. Once the decision to deprecate is made it takes at least 2 years to get it done. The longer we wait, the longer we have to carry its baggage and risk its poor interaction with new features. It's a good question to ask: What can we get rid of? I know it's radical, but I'd like to see if we could enhance structs a little and get rid of classes and interfaces. See https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html for what I mean. Mike
Re: D is dead (was: Dicebot on leaving D: It is anarchy driven development in all its glory.)
On Thursday, 23 August 2018 at 03:50:44 UTC, Shachar Shemesh wrote: And it's not just Weka. I've had a chance to talk in private to some other developers. Quite a lot have serious, fundamental issues with the language. You will notice none of them speaks up on this thread. They don't see the point. No technical project is born great. If you want a technical project to be great, the people working on it have to focus on its *flaws*. The D's community just doesn't do that. To sum it up: fatal flaws + no path to fixing + no push from the community = inevitable eventual death. The D Foundation has an Open Collective page (https://opencollective.com/dlang) with a $12,000 annual "Corporate Bronze" option that includes 3 priority bug fixes per month. Is that not a worthwhile investment for Weka or other organizations invested in D to help address some of the problems you're encountering? If not, is there an option that would be? Mike
Re: [OT] Leverage Points
On Saturday, 18 August 2018 at 13:33:43 UTC, Andrei Alexandrescu wrote: where are the best leverage points in making the D language more successful. I'm still internalizing the article and thinking about how it applies to the "D system", but I've always thought facilitating the incorporation of GDC into GCC to be the single most accelerating thing we could do to gain more adoption. It somewhat fits into *7. The gain around driving positive feedback loops*. But there's risk associated with that. Walter has often said that "build it and they will come" is a Hollywood myth, but I disagree. Part of the reason why D hasn't achieved mass adoption, isn't because it's not marketed well, but because it has a number of flaws. Most of us see the *potential* of D, and are able to look past the flaws, with the faith (hopefully not misplaced) that they will one day be addressed. Others only see the flaws and the appeal of other programming languages with more resources, better management, more talent, and especially more velocity toward their goals. I often worry that if we encourage adoption, before we have something worthy of adoption, we'll only leave users with a bad taste in their mouth [0]. I've already seen a number of people, some major contributors, leave D for greener pastures. Most of the contributors that built the D runtime and did the majority of bug fixing in the compiler are gone now. At this point in time, I can only recommend D professionally to teams that are risk takers, have the aptitude to solve their own problems, and have the resources and willingness to be D contributors. We should probably be looking more for leverage points to help us better capitalize on the resources and talent we have and bring in more. Unfortunately I'm seeing an over-correction in *8. The strength of negative feedback loops, relative to the impacts they are trying to correct against*. As we try to get contributors to focus on the things that matter (at least to the powers that be), we frustrate them until they close their pull requests or just give up [1] [2]. It took me a few years to find my "in", and I'm still not really "in", but I learned that the *little things* that some consider a distraction are how people get started contributing to D. I've often said that we actually don't need more contributors; but more reviewers. There's a catch to that, though; they're not going to become reviewers if they can't first become contributors. So perhaps, I need to correct my perspective. So, I'll close with this: We should probably be more welcoming to those willing to contribute, let them work on the little stuff that's important to them, throw them a bone or two, review their pull requests in a timely manner, etc... I think those contributors will eventually become our reviewers, and then they will eventually lessen the burden so veterans can focus on the things that they think are higher priorities. This is a positive feedback loop. Help people become positive contributors, and those contributors will eventually help the next generation. I think there are a few little things the leadership, especially, can do to prime that pump, starting with being more active, helpful, and gracious with things that are currently sitting in the PR queue. Though it's a two-way street, and some contributors could also be more cooperative also. Walter and a few others have been quite gracious to me [3] [4]. I've tried to pay that forward and help other contributors find their "in", but I'm still not able to review and make decisions about many things, so I'm only of limited help. I don't think others have been treated as well. Mike [0] - https://issues.dlang.org/show_bug.cgi?id=14100 - Link in that issue no longer exists, but let's just say the user wasn't happy with D [1] - https://github.com/dlang/dmd/pulls?q=is%3Apr+author%3Amarler8997+is%3Aclosed [2] - https://github.com/dlang/dmd/pull/8378 [3] - https://github.com/dlang/dmd/pull/7395#issuecomment-349200847 [4] - https://github.com/dlang/dmd/pull/7055#issuecomment-320006283
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 11:02:00 UTC, Seb wrote: No, it's behind a flag, so you can't really say that we're shipping it as "production ready release". The changes to Phobos are not behind a flag. We're making changes to Phobos in the release branch to accommodate a draft/experimental/choose-your-adjective feature. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote:
dip1000 has been around for two years, and its predecessor
dip25 several years now. Plenty of time for anyone to comment
and/or propose something better.
Part of the problem is that the implementation keeps changing
without keeping the documentation in sync. For example you're
implementing all of these inference rules without documenting
them:
https://github.com/dlang/dmd/pull/8346
https://github.com/dlang/dmd/pull/8408
I asked you about, instead of inferring the attributes, allowing
users to add such logic themselves:
void foo(T)(T x)
if (__traits(isPointer, T)) { T = scope T; }
{ }
But, then the PR got rubber-stamped, and now here we are.
Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote: I want to ensure Atila is successful with this. But that means Phobos has to compile with dip1000. So I need to make it work. There's a good chance you'll get your PR merged when it's documented and vetted, then you'll be able to make it work for Atila. The only think holding it up is you. I'm not asking for much. Sufficiently document the idea, open it up for comment and Q & A, transfer the documentation to the spec to accompany the DMD implementation PR. Assuming there's no major flaws in the design, it should get merged. Mike P.S. Actually, I've been trying to document it myself, since you don't seem willing to, but it's going to take me a lot longer to figure out what's in your head than it would take you.
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 09:23:26 UTC, Walter Bright wrote: The proposed idea wants to make the first parameter, if it's `ref`, special. This is because Phobos is written with functions of the form: void put(sink, parameters...) which corresponds to: sink.put(parameters...) The two forms are fairly interchangeable, made more so by the Uniform Function Call Syntax. Makes perfect sense. This is the kind of stuff I'd like you to put in a formal document and present to us as an RFC along with your PR. Then transfer that information to the spec to accompany the DMD PR, after you've received feedback. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 05:39:05 UTC, Mike Franklin wrote: I understand that Walter's DIPs have been put through the process just like the others, but with regard to the specific issue in this thread (https://issues.dlang.org/show_bug.cgi?id=19097), the accompanying PR (https://github.com/dlang/dmd/pull/8504), and similarly undocumented PR (https://github.com/dlang/dmd/pull/8408), they are amending DIP 1000 and DIP 25 "under the table". There is no accompanying PR to the specification, no formal rational, no RFC from the community, etc... A 3rd example (https://github.com/dlang/dmd/pull/8346) to throw a little more salt on the wound. The DIP25/1000 rabbit hole is deepening behind the curtain. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 05:04:25 UTC, Mike Parker wrote: Whatever the status of DIP 1000, I would point out that that one of Walter's DIPs is in Community Review right now after sitting in the PR queue in Draft Review for a while. Once this review stage is done, it will go back into the queue to await Final Review like any other DIP. The only difference between this and other DIPs is that there will be no Formal Assessment for it. And this is the second DIP from Walter that has gone through the process since I've come on board, with DIP 1008 being put on pause at his request. I understand that Walter's DIPs have been put through the process just like the others, but with regard to the specific issue in this thread (https://issues.dlang.org/show_bug.cgi?id=19097), the accompanying PR (https://github.com/dlang/dmd/pull/8504), and similarly undocumented PR (https://github.com/dlang/dmd/pull/8408), they are amending DIP 1000 and DIP 25 "under the table". There is no accompanying PR to the specification, no formal rational, no RFC from the community, etc... Yet I and others have to go through the DIP process for much less significant changes to the language, and rightly so: https://github.com/dlang/dmd/pull/7310 https://github.com/dlang/dmd/pull/7079 All I want to see from Walter is: 1) a sufficiently documented proposal for his idea 2) an RFC from the community 3) a PR to the spec documenting the final design I don't think that's too much to ask. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 04:49:15 UTC, Mike Franklin wrote: It is hypocritical an arrogant to believe that only our ideas have flaws and require scrutiny. Sorry, that was poorly stated and conveyed the wrong intent. It should read: It is hypocritical an arrogant to believe that only our ideas should require thorough documentation and scrutiny. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 04:23:52 UTC, Jonathan M Davis wrote: The reality of the matter is that the DIP system is a formal way to propose language changes in order to convince Walter and Andrei that those changes should be implemented, whereas if Walter or Andrei writes the DIP, they're already convinced. This isn't a democracy. Walter is the BDFL, and it's his call. So, I really don't think that it's hypocritical Walter and Andrei need to have their ideas vetted by the community, not in an effort to convince anyone, but for quality assurance, to ensure they're not overlooking something. It is hypocritical an arrogant to believe that only our ideas have flaws and require scrutiny. Mike
Re: Is @safe still a work-in-progress?
On Wednesday, 22 August 2018 at 01:07:28 UTC, Mike Franklin wrote: But what bothers me the most... Something else that rubs me the wrong way is that DIP 1000 is currently in a status of `DRAFT`: https://github.com/dlang/DIPs/blob/master/DIPs/README.md What the heck is going on here? We're adding features to the compiler and modifying Phobos in production releases based on a `DRAFT` proposal? Furthermore, I find it hypocritical that some of us are put through a disproportionately burdensome DIP process requiring thorough documentation, multiple peer reviews, excessive delays, and judgement that defaults to "no" for some of the most minute changes to the language, but a game-changing feature like DIP 1000 can just be amended on a whim. Mike
Re: Is @safe still a work-in-progress?
On Tuesday, 21 August 2018 at 21:17:25 UTC, Atila Neves wrote: I don't have merge rights. I took a look anyway and it mostly looks ok, but I'm not familiar enough with that part of the codebase. It's not the implementation that's preventing it from being merged. It's the idea itself, weak rationale, lack of peer review, lack of consideration for alternatives, and lack of documentation supporting it. It reeks of "designed on a whim to quickly patch some oversight in the design DIP1000 while trying to get Phobos to compile with -dip1000". With the proposed idea, order of parameters matters. We'll need to establish a convention that return parameters must be declared first, which is opposite of https://dlang.org/phobos/std_algorithm_mutation.html#copy. Is that a good idea? Maybe it is. We haven't vetted the design yet, so I'm not sure. Why haven't we vetted the design? Because there currently isn't one; there's just an informal back-of-the-napkin memo uploaded to a bugzilla entry. The proposed idea wants to make the first parameter, if it's `ref`, special. Why not the first `ref` parameter regardless of whether it's the absolute first in the list. Why not the last `ref` parameter? Why not all `ref` parameters? But what bothers me the most is I think it's missing the bigger picture: D needs a way to annotate lifetimes. Maybe `scope` and `return` with weird conditions based on the order of parameters and their attributes are the way to go. Maybe there's another way that hasn't yet been considered. Put together a thorough description of the proposal, justify it, ask the larger community for comment, vet it, and document it. At least that's what it's going to take to get me to take action on the PR. Or maybe someone else is willing to just rubber stamp it in the interest of expediency. 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: Windows dev anyone? [was: Re: Signed DMD binaries]
On Friday, 17 August 2018 at 16:42:08 UTC, Martin Nowak wrote: - help to test, debug, and fix the experimental lld/mingw toolchain (https://dlang.org/changelog/2.079.0.html#lld_mingw) I'd be happy to test this, but where are the instructions for using it?Do I need to uninstall Visual Studio first (please no)? Mike
Re: Windows dev anyone? [was: Re: Signed DMD binaries]
On Friday, 17 August 2018 at 16:42:08 UTC, Martin Nowak wrote: On 08/17/2018 01:24 AM, Mike Franklin wrote: Well from my point of view the most important outstanding Windows tasks are: [...] Thanks. I'm currently working on getting build.d to work on Windows. https://github.com/dlang/dmd/pull/8570 https://github.com/dlang/dmd/pull/8568 https://github.com/dlang/dmd/pull/8566 https://github.com/dlang/dmd/pull/8546 I think once that's done it won't be such a huge burden to set up a development environment for Windows, and hopefully we'll see more participation. I'd be happy to add anyone remotely interested in Windows-support to our #Windows channel on slack (https://dlang.slack.com/messages/C6D5FEJ78). It's unfortunately fairly quiet atm. Joined. Mike
Re: Is @safe still a work-in-progress?
On Friday, 17 August 2018 at 16:00:26 UTC, 12345swordy wrote: On Friday, 17 August 2018 at 15:27:22 UTC, Mike Franklin wrote: I actually started writing a DIP for this about a year ago, but I need to pick my battles. Mike Is it on github? Alex No,but here are some notes I found in my files. @safe by default Before Transition Write a program that parses D code and explicitly adds @system if no function is not decorated with any safety attribute Add a transitional -explicit-safety compiler switch that emits a warning if a safety attribute is not explicitly specified. Update all dlang repositories and maybe others with explicit attributes using aforementioned program. Turn on -explicit-safety for all CIs so any new PRs so explicit safety is added to all new functions. Add transitional @system-by-default compiler switch for backward compatibility This will be especially useful to keep our CIs running with legacy code This will also be useful for programs with dub dependencies that need to continue running Add -@system-main compiler switch for backward compatibility Add -@safe-main and -@safe-by-default compiler switch for forward-looking D projects Update all of D's tutorials, examples, etc… with explicit safety attributes. Transition Add changelog entry warning that @safe-by-default is coming and how they can use the aforementioned tools eliminate disruption Run this change log for 1 year (4 releases)? After Transition Remove @safe attributes in D's example code. Remove @safe attributes from phobos/druntime/dmd etc.. Turn off -explicit-safety for those libraries that have updated their code. Deprecate @safe-main and @safe-by-default compiler switch through the normal deprecation process. -explicit-safety, @system-main and @system-by-default remain for an indeterminate amount of time. They should eventually be deprecated, but only after they have outlived their usefulness. Difficulties The difficulty will be with printed material (books, etc…) that will become out-of-date. Recommendation is to add information to their published errata, or create a new edition. Mike
Re: Is @safe still a work-in-progress?
On Friday, 17 August 2018 at 14:26:07 UTC, H. S. Teoh wrote: On Fri, Aug 17, 2018 at 01:50:32AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...] Honestly, the reality of the matter is that @safe is probably always going to be somewhat broken, because it's implemented via blacklisting rather than whitelisting. Instead of @safe only allowing stuff that's been proven to be @safe, it disallows stuff that a programmer decided was @system. Sigh: https://issues.dlang.org/show_bug.cgi?id=12941 This was reported 4 years ago, but was unfortunately closed as invalid. It will continue to be a problem as long as @safe is implemented via blacklisting, because every single time there's a new language feature, there's a chance that a loophole is introduced into @safe. And that's not counting the combinatorial explosion of existing language features that might lead to @safe loopholes, that we simply haven't thought of yet. It's like allowing anyone to enter your house freely except those few people whom you've explicitly named. You can't possibly expect *not* to get robbed that way. I knew there was something fundamentally wrong with @safe, but I could never put my finger on it. Now that you and Jonathan mention this, it becomes clear. This makes me exceptionally sad. D is great in so many ways, but then this taints the pool. I asked if D was ever going to be @safe by default at DConf (https://youtu.be/HvqsUO77FGI?t=13242), but it didn't elicit a very positive answer. It seems D is backtracking in some ways (@nogc, -betterC), trying to evolve it into something it wasn't originally envisioned to be, and now we have another one to add to the list. The bug you ran into is a pretty glaring one that arguably should have been fixed ages ago, but given how hard it is to prove what is and isn't @safe, there are bound to be corner cases which have been missed. As we find them, they'll be fixed, but who knows how many are left or whether we'll ever actually get them all. [...] And that is exactly why the whole implementation of @safe is currently rather laughable. By blacklisting rather than whitelisting, we basically open the door wide open to loopholes -- anything that we haven't thought of yet could potentially be a @safe-breaking combination, and we wouldn't know until somebody discovers and reports it. Sadly, it seems there is little interest in reimplementing @safe to use whitelisting instead of blacklisting. I think there is probably some interest, though maybe not from the ones with the position or ability to make it happen. A DIP might be the way forward, but it seems like quite a difficult task to turn it right-side-up at this point. I actually started writing a DIP for this about a year ago, but I need to pick my battles. Mike
Re: Is @safe still a work-in-progress?
On Friday, 17 August 2018 at 07:50:32 UTC, Jonathan M Davis wrote: That particular bug is a duplicate of https://issues.dlang.org/show_bug.cgi?id=8838, which was closed as fixed based on the fact that -dip1000 fixes the problem by treating marking the slice of a static array with scope. It's still quite broken without -dip1000 though. It still appears to be broke even with -dip1000: https://run.dlang.io/is/gJi2Fa
