Re: Thanks for the bounty!
On Thursday, 3 July 2014 at 21:57:14 UTC, Benoit Rostykus wrote: We just set up a significant bounty for this bug: https://www.bountysource.com/issues/2900969-struct-destructors-are-not-called-by-the-gc-but-called-on-explicit-delete However, it is referenced on BountySource under the "DLang's Issue Tracking System - D" project instead of the (more publicized) "D Programming Language" project, so it is hard to find. Andrei, is there any reason to have 2 different projects there? How to make sure our bounty also appears on the main project page on BountySource? Thanks! I had a similar problem, and had to contact the folks at BountySource to get it straightened out. Mike
Re: Some Observations on the D Development Process
On Friday, 5 January 2018 at 03:28:10 UTC, Walter Bright wrote: There's a lot of technical debt I've been trying to fix with that, and nobody else seems willing to do it. For example, fixing the error messages so they make use of color syntax highlighting. It's boring, tedious, unfun work, meaning I get to do it :-) If you have simple, mundane work that needs to be done, make a list and send it my way; you should have my e-mail address. But please be specific; "fix error messages" is just going to get a reply from me asking questions. Mike
Re: Some Observations on the D Development Process
On Saturday, 6 January 2018 at 02:53:38 UTC, Walter Bright wrote: For example, there were several uses of the word 'ctor' instead of 'constructor'. I couldn't find any cases like that. If you know of them, please explicitly identify them for me. Thanks, Mike
Re: Shouldn't invalid references like this fail at compile time?
On Monday, 22 January 2018 at 23:30:16 UTC, Aedt wrote:
I was asked in Reddit
(https://www.reddit.com/r/learnprogramming/comments/7ru82l/i_was_thinking_of_using_d_haxe_or_another/) how would D handle the following similar D code. I'm surprised that both dmd and ldc provides no warnings even with -w argument passed.
import std.stdio;
void main()
{
string foo = "foo";
string* p1, p2;
string*[] ls;
ls ~= &foo;
p1 = ls[0];
ls.destroy();
p2 = ls[0];
writeln(p2);
}
D is not memory safe by default (unfortunately), so it's not
surprising to me that you can do this in `@system` code. I would
be surprised if the compiler allowed you to do something like
this in `@safe` code. To make your programs memory safe, you
should add `@safe` to your `main` function.
Mike
Re: Shouldn't invalid references like this fail at compile time?
On Tuesday, 23 January 2018 at 01:08:19 UTC, ag0aep6g wrote: If you add `@safe`, the compiler rejects this line: ls ~= &foo; But that line would only be problematic if the pointer would leave the scope of the function. It doesn't, so this is actually safe. But the compiler isn't smart enough to see this. https://issues.dlang.org/show_bug.cgi?id=18281
Re: Shouldn't invalid references like this fail at compile time?
On Tuesday, 23 January 2018 at 01:08:19 UTC, ag0aep6g wrote: The real question is about this line: p2 = ls[0]; That's an out-of-bounds access, and the compiler does not catch this statically. Instead, it inserts bounds-checking code that crashes the program safely with an `Error`. In trying to work out a solution to that, I ran across this oddity: https://issues.dlang.org/show_bug.cgi?id=18282
Re: Shouldn't invalid references like this fail at compile time?
On Tuesday, 23 January 2018 at 01:08:19 UTC, ag0aep6g wrote:
The real question is about this line:
p2 = ls[0];
That's an out-of-bounds access, and the compiler does not catch
this statically. Instead, it inserts bounds-checking code that
crashes the program safely with an `Error`.
Due to the aforementioned bugs in my prior posts, I couldn't even
make an example to demonstrate in @safe code, so I modified the
example slightly in an effort to reproduce the same problem.
import std.stdio;
void main() @safe
{
string foo = "foo";
string* ls0;
string* p1, p2;
ls0 = &foo;
p1 = ls0;
ls0.destroy();
p2 = ls0;
writeln(p2.length);
}
Error: program killed by signal 11
https://run.dlang.io/is/ecYAKZ
Yeah, that's pretty poopy.
Not sure how to precisely define the problem here. Should
`destroy` be `@system` so it can't be called in `@safe` code, or
should the compiler be smart enough to figure out the flow
control and throw an error?
Mike
Re: Shouldn't invalid references like this fail at compile time?
On Tuesday, 23 January 2018 at 02:25:57 UTC, Mike Franklin wrote:
Due to the aforementioned bugs in my prior posts, I couldn't
even make an example to demonstrate in @safe code, so I
modified the example slightly in an effort to reproduce the
same problem.
import std.stdio;
void main() @safe
{
string foo = "foo";
string* ls0;
string* p1, p2;
ls0 = &foo;
p1 = ls0;
ls0.destroy();
p2 = ls0;
writeln(p2.length);
}
Error: program killed by signal 11
https://run.dlang.io/is/ecYAKZ
Gah!!! I screwed up that example, and I can't edit the post. See
the example here:
import std.stdio;
void main() @safe
{
string foo = "foo";
string* ls0;
string* p1, p2;
ls0 = &foo;
p1 = ls0;
ls0.destroy();
p2 = ls0;
writeln(p2.length);
}
Compile with `-dip1000`
Error: program killed by signal 11
https://run.dlang.io/is/6L6zcH
So that's bad. But it looks like a bug in `-dip1000`, because if
I compile without `-dip1000`, I get:
onlineapp.d(9): Error: cannot take address of local foo in @safe
function main
https://run.dlang.io/is/rHpuf1
Mike
Re: Shouldn't invalid references like this fail at compile time?
On Tuesday, 23 January 2018 at 02:38:42 UTC, Mike Franklin wrote: So that's bad. But it looks like a bug in `-dip1000` https://issues.dlang.org/show_bug.cgi?id=18283
Re: Shouldn't invalid references like this fail at compile time?
On Tuesday, 23 January 2018 at 02:25:57 UTC, Mike Franklin wrote:
Should `destroy` be `@system` so it can't be called in `@safe`
code, or should the compiler be smart enough to figure out the
flow control and throw an error?
Interestingly, `destroy` is an unsafe operation for classes.
import std.stdio;
class A
{
void hello() @safe { writeln("hello"); }
}
void main() @safe
{
A a = new A();
a.hello();
destroy(a); // onlineapp.d(12): Error: @safe function 'D
main' cannot call
// @system function 'object.destroy!(A).destroy'
a.hello();
}
https://run.dlang.io/is/AwKBc3
But it's not an unsafe operation for structs
import std.stdio;
struct A
{
int i;
void print() @safe { writeln(i); }
}
void main() @safe
{
A* a = new A();
a.print(); // OK
a.destroy();
a.print(); // Error!
}
https://run.dlang.io/is/Fm7qBR
Not sure if that's a bug or not.
Mike
Re: Shouldn't invalid references like this fail at compile time?
On Tuesday, 23 January 2018 at 21:53:24 UTC, Steven Schveighoffer wrote: Interestingly, `destroy` is an unsafe operation for classes. Because it's calling a @system function, rt_finalize. This function calls whatever is in the destructor, and because it works on Object level, it has no idea what the actual attributes of the derived destructor are. This needs to be fixed, but a whole host of issues like this exist with Object. Are there any bugzilla issues that you are aware of that document this? Mike
Re: Shouldn't invalid references like this fail at compile time?
On Tuesday, 23 January 2018 at 21:53:24 UTC, Steven Schveighoffer wrote: [1] Note: the reason they are safe is because they generally result in a segfault, which doesn't harm any memory. This is very much a user-space POV, and doesn't take into account kernel-space where null dereferences may actually be valid memory! It also doesn't (currently) take into account possible huge objects that could extend into valid memory space, even in user space. That's what kindof ticks me off about this "null is memory safe" argument; it seems to be only applicable to a specific platform and environment. I have a micocontroller in front of me where an address of null (essentially 0) is a perfectly valid memory address. Mike
Re: Shouldn't invalid references like this fail at compile time?
On Wednesday, 24 January 2018 at 01:44:51 UTC, Walter Bright wrote: Microcontroller code tends to be small and so it's unlikely that you'll need to worry about it. I think you need to get involved in programming microcontrollers again because the landscape has changed drastically. The microcontrollers I use now are more powerful than PCs of the 90's. The project I'm currently working on is an HMI for industrial control with a full touchscreen 2D GUI. The code base is 240,084 lines of code and that doesn't even include the 3rd party libraries I'm using (e.g. 2D graphics library, newlib C library, FreeType font rendering library). That's not "small" by my standard of measure. And with devices such as this being increasingly connected to the Internet, such carelessness can easily be exploited as evident in https://en.wikipedia.org/wiki/2016_Dyn_cyberattack And that's not to mention the types of critical systems that run on such platforms that we are increasingly becoming more dependent on. We better start worrying about it. Mike
Re: Shouldn't invalid references like this fail at compile time?
On Wednesday, 24 January 2018 at 03:46:41 UTC, lobo wrote: Well if your embedded device has all that on it you should be sitting on an OS with proper memory management support. I don't see how the OS can help if the underlying hardware doesn't have an MMU. That being said, admittedly, the more capable microcontrollers do have an MPU that can be configured to throw a hardware exception. We don't use D, it is all C++ and some Ada in the older systems. Why don't you use D? Mike
Re: Shouldn't invalid references like this fail at compile time?
On Thursday, 25 January 2018 at 02:41:53 UTC, Walter Bright wrote: Ok, but are these devices with 0 being a valid address? It seems weird to me that any sane modern CPU design that can access megabytes of memory would have 0 be a valid address. Yes, 0 is a valid address and typically points to ROM (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CHDBIJJE.html). "The initial stack pointer and the address of the reset handler must be located at 0x0 and 0x4 respectively." (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CHDBIJJE.html) So you read address 0, dereference it, and you're at the bottom of the stack. Some microcontrollers have an MPU to mitigate this. You can read one technique here: http://nuttx.org/doku.php?id=wiki:howtos:stm32-null-pointer But the MPU is an optional component, and many microcontrollers in the ARM Cortex-M family do not have one. Mike
Re: Shouldn't invalid references like this fail at compile time?
On Thursday, 25 January 2018 at 04:01:47 UTC, Mike Franklin wrote: "The initial stack pointer and the address of the reset handler must be located at 0x0 and 0x4 respectively." (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CHDBIJJE.html) Sorry! Wrong link. Try this one: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s01s01.html
Re: Shouldn't invalid references like this fail at compile time?
On Thursday, 25 January 2018 at 04:45:34 UTC, Walter Bright wrote: This implies a ROM must be located there. Else how do initial values get there? I'm not sure what you mean. When you upload your firmware to the MCU, it writes the initial stack pointer to address 0x00 and the address of the reset handler to 0x04. It is up the developer to set these values properly in the linker script (a.k.a scatter file). Mike
Re: Shouldn't invalid references like this fail at compile time?
On Thursday, 25 January 2018 at 04:45:34 UTC, Walter Bright wrote: This implies a ROM must be located there. Else how do initial values get there? Yes, ROM is at address 0. Address 0 contains the initial stack pointer. So you read address 0, dereference it, and then do your damage. Mike
Re: Shouldn't invalid references like this fail at compile time?
On Thursday, 25 January 2018 at 04:59:55 UTC, Mike Franklin wrote: Yes, ROM is at address 0. Address 0 contains the initial stack pointer. So you read address 0, dereference it, and then do your damage. Keep in mind too that the ROM, on these devices, is actually reprogrammable from the firmware itself, so one could do some clever exploitation of that feature to insert whatever they want into the product's firmware. Mike
Re: Shouldn't invalid references like this fail at compile time?
On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote: And I'm broken after using D, going back to C++ is awful and Rust just has too much friction to be enjoyable. Yep, I know exactly what you mean.
Re: The daily D riddle
On Sunday, 28 January 2018 at 06:25:51 UTC, Shachar Shemesh wrote:
What will the following code print? Do not use the compiler:
import std.stdio;
struct A {
int a = 1;
void initialize() {
a = a.init;
}
}
void main() {
A a;
a.initialize();
writeln(a.a);
}
I find this behavior unexpected.
Works exactly as I predicted.
Re: What libraries should run.dlang.io support?
On Sunday, 28 January 2018 at 15:39:41 UTC, Seb wrote: As I just addded emsi_containers to it, I was wondering what other libraries would be useful for you? What about adding a small frame buffer on the page for displaying 2d graphics, or to render vibe.d's html output? Then add libraries like cairo, or some other for rendering 2d images.
Re: What libraries should run.dlang.io support?
On Tuesday, 30 January 2018 at 11:03:07 UTC, Mike Franklin wrote: On Sunday, 28 January 2018 at 15:39:41 UTC, Seb wrote: As I just addded emsi_containers to it, I was wondering what other libraries would be useful for you? What about adding a small frame buffer on the page for displaying 2d graphics, or to render vibe.d's html output? Then add libraries like cairo, or some other for rendering 2d images. Maybe it would be as simple as providing 3 different "views" of the output: Text, HTML, Image (RGB888-fixed size).
#dbugfix Issue 2043
https://issues.dlang.org/show_bug.cgi?id=2043 It's a really old bug, and top-voted in bugzilla according to https://issues.dlang.org/buglist.cgi?bug_status=__open__&columnlist=component%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate%2Cvotes&list_id=218657&order=votes%20DESC%2Cpriority%2Cbug_severity&query_format=specific
Re: missing HexString documentation
On Wednesday, 7 February 2018 at 23:30:57 UTC, Walter Bright wrote: Can you please provide a list of these issues, and file issues that aren't on bugzilla yet, and tag them with the betterC keyword? I see only one: https://issues.dlang.org/buglist.cgi?quicksearch=%5Bbetterc%5D&list_id=219382 Don't search for "[betterC]". Instead, use "betterC" (without the brackets). https://issues.dlang.org/buglist.cgi?quicksearch=betterc&list_id=219390 We can't reliably rely on informal conventions. Mike
Re: missing HexString documentation
On Wednesday, 7 February 2018 at 16:03:36 UTC, Steven Schveighoffer wrote: They are deprecated: https://dlang.org/changelog/pending.html#hexstrings https://dlang.org/deprecate.html#Hexstring%20literals Wow, that's... a little superfluous. I agree with the notion that the language should be an aggregate of primitives, and anything that can be composed of those primitives should be implemented in a library (unless a compelling reason is found to justify otherwise). The deprecation of hex string literals has exposed flaws in the library implementation and the compiler's template implementation. That doesn't mean deprecation was the wrong thing to do; it just brings the aforementioned flaws to the forefront, so let's not shoot the messenger. Here's a few fundamental flaws I see in our library implementations. * Some library implementations are not very cohesive, and have too many interdependencies. This is what seems to prevent `HexString` from being used in -betterC. * Some Phobos implementations would be quite useful in Druntime and in code that doesn't want to employ the runtime (e.g. libraries consumed by other languages, resource-constrained systems, and bare-metal programming), but alas, Druntime can't have a circular dependency on Phobos (nor should it). This is a difficult problem, and I don't have any solutions; just ideas. Maybe Phobos and Druntime should be divided into 3 libraries: 1. A library with no dependencies whatsoever, not even druntime, c runtime, or the C standard library. Some stuff in `std.traits`, `std.conv`, and even `HexString` could go here. Let's call this library DLib. 2. Druntime would only depend on DLib, but never publicly expose it. 3. Phobos could depend on DLib or Druntime, but again, never publicly expose it. 4. Phobos could be refactored by identifying packages that have too much coupling, and factoring out the dependencies into a 3rd, more cohesive library, imported by the previous two. For extra credit: 2a. Move C/C++ standard library bindings to Deimos, and have the desktop OS ports import it privately. There's no reason to impose this interface on bare-metal ports, and it's a superficial dependency anyway. 3a. Phobos shouldn't have any dependency on C/C++ language bindings. DRuntime should expose an idiomatic D (and preferably @safe) interface for Phobos to use. DLib could then be used in -betterC and other use cases where Druntime is more of a liability than an asset. Mike
Re: missing HexString documentation
On Thursday, 8 February 2018 at 00:25:21 UTC, H. S. Teoh wrote: hexString is in Phobos, and druntime can't use Phobos. Should templates like octal and hexString be in druntime instead? IMO, no. I think the interdependencies between the compiler, druntime, phobos, and even the packages contained within needs some remodeling. I posted some of my initial thoughts here: https://forum.dlang.org/post/wvmgimzlwuwywxhhy...@forum.dlang.org Mike
#dbugfix Issue 1983
https://issues.dlang.org/show_bug.cgi?id=1983 A PR addressing this issue (https://github.com/dlang/dmd/pull/2130), is the oldest PR in the DMD repository. The issue also is almost a decade old. I'd love to see it finally resolved.
Re: A betterC base
On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote:
How difficult would it be for D at this point to move towards a
pay for what you use system that out of the box is betterC and
requires the garbage collector to be explicitly imported?
I'm not sure if this is what you're looking for, but I've been
trying to work on something like that, and have successfully
submitted a few PRs:
Opt-in ModuleInfo
https://github.com/dlang/dmd/pull/7395
https://github.com/dlang/dmd/pull/7768
Opt-in Throwable
https://github.com/dlang/dmd/pull/7786
Opt-in TypeInfo
https://github.com/dlang/dmd/pull/7799 (not yet merged; someone
please review it)
With all of the above PRs merged, the compiler will no longer
complain about the above missing runtime features if your code
doesn't use them. It also allows one to create really small
binaries with no dependencies.
Example 1
=
object.d
module object;
private alias extern(C) int function(char[][] args) MainFunc;
private extern (C) int _d_run_main(int argc, char** argv,
MainFunc mainFunc)
{
return mainFunc(null);
}
main.d
--
void main() { }
dmd -conf= -defaultlib= main.d object.d -of=main
size main
textdata bss dec hex filename
1403 584 162003 7d3 main
Example 2
This will avoid linking in the C standard library and C runtime.
But you have to provide your own replacements.
=
object.d
module object;
extern(C) 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
--
void main() { }
dmd -c -lib main.d object.d -of=main.o
ld main.o -o main
size main
textdata bss dec hex filename
56 0 0 56 38 main
If you are creating a library to be consumed by another language,
you just need to add an empty object.d file in your current
directory. I tried to remove that silly limitation, but it met
resistance: https://github.com/dlang/dmd/pull/7825
I have a changelog PR describing all this at
https://github.com/dlang/dmd/pull/7829, with the intention of it
being available in the next DMD release, but I need my other PRs
reviewed and merged before I can move forward.
This is just the tip of the iceberg, though. After this stage, I
would like to start tackling the overuse of TypeInfo in the
coupling between the compiler and the runtime. See this comment
(https://issues.dlang.org/show_bug.cgi?id=18312#c2) for more
about what I mean there.
Mike
Re: A betterC base
On Thursday, 8 February 2018 at 17:10:00 UTC, bachmeier wrote: What are D's limitations on do-it-yourself reference counting? * Types that are built into the language like dynamic arrays, associative arrays, and exceptions won't benefit from DIY reference counting. * Much of Phobos probably wouldn't be compatible with DIY reference counting. That being said, there may be a way to override some runtime hooks like _d_newclass (https://dlang.org/library/rt/lifetime/_d_newclass.html), etc... to make it work. But I haven't tried. Also, I think Walter is currently working on getting reference counted exceptions into the language: https://github.com/dlang/druntime/pull/1995 Mike
Re: A betterC base
On Friday, 9 February 2018 at 01:31:41 UTC, Mike Franklin wrote: On Thursday, 8 February 2018 at 17:10:00 UTC, bachmeier wrote: What are D's limitations on do-it-yourself reference counting? * Types that are built into the language like dynamic arrays, associative arrays, and exceptions won't benefit from DIY reference counting. * Much of Phobos probably wouldn't be compatible with DIY reference counting. That being said, there may be a way to override some runtime hooks like _d_newclass (https://dlang.org/library/rt/lifetime/_d_newclass.html), etc... to make it work. But I haven't tried. Also, I think Walter is currently working on getting reference counted exceptions into the language: https://github.com/dlang/druntime/pull/1995 Mike Also, I think DIY reference counting is already done for us in the automem library https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/ Mike
#dbugfix Issue 18068 - No file names and line numbers in stack trace
https://issues.dlang.org/show_bug.cgi?id=18068 I tried to fix this one myself, but it beat me. It's also currently causing me friction when working on DMD. I would love to see it fixed. Interestingly, however, it works fine in the auto-tester. But, problem can be reproduced at https://run.dlang.io/ (e.g. https://run.dlang.io/is/hatIXE). Maybe it's dependent on the host compiler being used; I don't know. Mike
Re: Being Positive
On Tuesday, 13 February 2018 at 14:17:00 UTC, Steven Schveighoffer wrote: On 2/12/18 11:29 PM, Nick Sabalausky (Abscissa) wrote: A bunch of stuff I 100% agree with. Me too. So refreshing to read. Mike
Re: OT: Photo of a single atom by David Nadlinger wins top prize
On Wednesday, 14 February 2018 at 01:11:33 UTC, David Nadlinger wrote: On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote: David (aka klickverbot) is a longtime D contributor […] … who is slightly surprised at the amount of media interest this has attracted. ;) David, this is so cool. Congratulations! But I've been wondering something: Obviously atoms are not this large, so what are we seeing in that photograph? atom motion-blur? Mike
Re: Status of @nogc with the runtime
On Saturday, 17 February 2018 at 12:18:28 UTC, Peter Campbell wrote: I was checking the 2017 vision pages and was wondering why there hasn't been a 2018H1 vision page but also what the current status of being able to use D without a garbage collector is? There are a number of ways to use D without the garbage collector. However, one of the easiest is with the -betterC flag. You'll want to read the two blog articles here (https://dlang.org/blog/category/betterc/) for more information about that. 2.079, the upcoming release will also have a way to use D without the runtime and without -betterC. What this allows you to do is partially implement just the runtime features you wish to support. You can read more about it in the nightly changelog here (https://dlang.org/changelog/pending.html#minimal_runtime) You might also be interested in this article: https://wiki.dlang.org/Memory_Management Mike
Re: -libpath?
On Tuesday, 6 February 2018 at 17:49:33 UTC, Jonathan Marler wrote: What do people think of adding an argument to DMD to add library search paths? Currently the only way I know how to do this would be via linker-specific flags, i.e. GCC: -L-L/usr/lib MSVC: -L-libpath:C:\mylibs OPTLINK: -L+C:\mylibs\ NOTE: the optlink version only works if no .def file is specified. If you have a .def file, then you can't add any library search paths :) If we added a new "linker-independent" flag to dmd, then you could add paths using the same interface regardless of which linker you are using. I'd expect the argument to be something like: -libpath= The disadvantage is it would be another command line option added to DMD. If there is general agreement that this is a desirable feature, I'll go ahead and implement it. Given the current state of things, and the issue described above, I think a linker/platform independent flag would be nice. However, I'd much rather have the compiler just be a compiler and not have to worry about all the intricacies building. IMO, the compiler should get out of the linking business altogether, and just generate object files. A separate build tool could then call the compiler, linker, and whatever else to do builds. But that ship has probably sailed. Mike
Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529
On Tuesday, 27 February 2018 at 08:43:32 UTC, Timothee Cour wrote: see rationale in https://issues.dlang.org/show_bug.cgi?id=18529 It looks like the actual deprecation was made with this PR: https://github.com/dlang/dmd/pull/5860 Meaning it's been deprecated for more than a year and a half. I think you're going to have to take it up with Walter. Mike
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei "If you could wave a magic wand and change one thing about any part of C++, what would it be, and how would that change help your daily work?" Deprecate C++, endorse D, and allocate all existing resources to either improving D, or implementing a fork of D. "Do you have any additional feedback for C++ standardization?" It's time for C++ to retire, and make room for better, emerging languages. I hate having to use it.
Re: Opt-in non-null class references?
On Wednesday, 28 February 2018 at 13:43:37 UTC, SimonN wrote: Hi, Andrei said in 2014 that not-null-references should be the priority of 2014's language design, with consideration to make not-null the default. In case the code breakage is too high, this can be an opt-in compiler flag. You might be interested in this little experiment: https://github.com/dlang/dmd/pull/7375 Mike
Re: Vtable for virtual functions in D
On Wednesday, 7 March 2018 at 22:02:17 UTC, sarn wrote: When I wrote Xanthe a year ago, I rolled my own classes using alias this and explicit vtables: https://gitlab.com/sarneaud/xanthe/blob/master/src/game/rigid_body.d#L15 (I did this because normal D classes use the druntime library, and Xanthe was an experiment in not using the D runtime at all.) Nice! I was thinking about something almost exactly like this recently since 2.079.0 has features to further decouple the language from the runtime. It would be nice to read a blog post about this technique. Mike
Re: Question over C++ to D conversion
On Monday, 12 March 2018 at 01:10:41 UTC, Richard wrote: There's a couple of outstanding things at the moment though The first is the use of BetterC, although from what I can tell DMD now has support for a minimal runtime feature as part of 2.079.0 https://dlang.org/changelog/2.079.0.html#minimal_runtime so hopefully when this makes it's way into LDC I can then make use of it for an Arm MCU for creating class's without the full runtime. https://github.com/ldc-developers/ldc/pull/2587 I'm hoping for that to land soon as well. The minimal runtime features and -betterC do have some overlap, but there are some specific things -betterC does that the minimal runtime doesn't do. See https://dlang.org/spec/betterc.html. At least one such feature is "assert failures are directed to the C runtime library". The minimal runtime has uses for those wishing to port the druntime to a new platform or architecture and do so incrementally. It's also useful for those that may choose to implement minimal subset of runtime features or provide an alternate implementation of a runtime feature for their application. This is especially useful in the embedded domain where there is typically one process running, and you know upfront what features you will need or not need; and you won't have to do the work of porting everything just to get a build. -betterC, on the other hand, is somewhat of a blunt instrument, and removes certain features of the runtime wholesale. With the minimal runtime features, you will be able to create a betterC-like application by simply avoiding features that you haven not implemented in your port of the runtime. That wasn't possible prior to 2.079.0. I was wondering if there are any other ways that are known about for translating C++ into D, or accessing C++ libraries. I'm sorry I don't know of any reliable tool that can create bindings to C++ libraries automatically. Mike
Re: #dbugfix Issue 5710
On Tuesday, 20 March 2018 at 00:00:22 UTC, ciechowoj wrote: Digging out and old yet important issue. https://issues.dlang.org/show_bug.cgi?id=5710 +1
Re: #dbugfix Issue 5710
On Tuesday, 20 March 2018 at 02:28:21 UTC, Manu wrote: On 19 March 2018 at 17:17, Mike Franklin via Digitalmars-d wrote: On Tuesday, 20 March 2018 at 00:00:22 UTC, ciechowoj wrote: Digging out and old yet important issue. https://issues.dlang.org/show_bug.cgi?id=5710 +1 Oh oh, https://issues.dlang.org/show_bug.cgi?id=5227 !! Submit a #dbugfix 5227 to the General Forum to make sure this gets counted. For more information see https://dlang.org/blog/2018/02/03/the-dbugfix-campaign/ Mike
Re: #dbugfix Issue 5710
On Tuesday, 20 March 2018 at 02:45:34 UTC, Jonathan M Davis wrote: IMHO, it would be _huge_ if this issue could be fixed. Mike Parker, I think that means +1.
Re: Bachelor level projects
On Tuesday, 20 March 2018 at 14:44:39 UTC, Alexandru Jercaianu wrote: Hello, At the Polytechnic University of Bucharest we are organizing a special program called CDL[1], where Bachelor students are mentored to make their first open source contributions. I think it's a great idea to involve D in this program, but for this to be successful, I need your help in finding ideas for Bachelor level projects, which can be solved until the end of May (anything from new features to more impactful bugs). If there is anything on your wish list which matches the criteria above, feel free to share. Thanks, Alex J There's a lot of good low-barrier-to-entry stuff in this post by Walter: https://forum.dlang.org/post/p6oibo$1lmi$1...@digitalmars.com It's not really a project in itself, but it is an excellent stepping stone for getting involved in contributing to DMD. Mike
Re: Bachelor level projects
On Tuesday, 20 March 2018 at 14:44:39 UTC, Alexandru Jercaianu wrote: If there is anything on your wish list which matches the criteria above, feel free to share. There's also a lot of low-barrier-to-entry stuff in this project I created a while ago: https://github.com/dlang/dmd/projects/3 I haven't worked on it because it's not a high priority to me, but it would be nice to have an aspiring software developer start picking away at it. Mike
Re: #dbugfix 17592
On Tuesday, 20 March 2018 at 21:27:53 UTC, 12345swordy wrote:
This is very important to me as I am very interested in using
the language for game development.
Yes I know that it's marked as "Duplicated", but I strongly
disagree as it is different enough to consider is own issue.
Alex
https://issues.dlang.org/show_bug.cgi?id=17592
Yeah that's pretty poopy. I looked into this and I think this is
fixable. Here's my proof of concept:
-
import core.stdc.stdio;
import std.traits;
/***
* This code was copied right out of druntime and
* attributed with @nogc
***/
extern (C) void rt_finalize(void *data, bool det=true) @nogc;
void destroy(T)(T obj) @nogc if (is(T == class))
{
rt_finalize(cast(void*)obj);
}
/***
* This emplace implementation below was copied
* right out of std.conv and attributed with @nogc
***/
@nogc pure nothrow @safe
void testEmplaceChunk(void[] chunk, size_t typeSize, size_t
typeAlignment, string typeName)
{
assert(chunk.length >= typeSize, "emplace: Chunk size too
small.");
assert((cast(size_t) chunk.ptr) % typeAlignment == 0,
"emplace: Chunk is not aligned.");
}
T emplace(T, Args...)(T chunk, auto ref Args args) @nogc
if (is(T == class))
{
static assert(!isAbstractClass!T, T.stringof ~
" is abstract and it can't be emplaced");
// Initialize the object in its pre-ctor state
enum classSize = __traits(classInstanceSize, T);
(() @trusted => (cast(void*) chunk)[0 .. classSize] =
typeid(T).initializer[])();
static if (isInnerClass!T)
{
static assert(Args.length > 0,
"Initializing an inner class requires a pointer to
the outer class");
static assert(is(Args[0] : typeof(T.outer)),
"The first argument must be a pointer to the outer
class");
chunk.outer = args[0];
alias args1 = args[1..$];
}
else alias args1 = args;
// Call the ctor if any
static if (is(typeof(chunk.__ctor(args1
{
// T defines a genuine constructor accepting args
// Go the classic route: write .init first, then call ctor
chunk.__ctor(args1);
}
else
{
static assert(args1.length == 0 && !is(typeof(&T.__ctor)),
"Don't know how to initialize an object of type "
~ T.stringof ~ " with arguments " ~
typeof(args1).stringof);
}
return chunk;
}
T emplace(T, Args...)(void[] chunk, auto ref Args args) @nogc
if (is(T == class))
{
enum classSize = __traits(classInstanceSize, T);
testEmplaceChunk(chunk, classSize, classInstanceAlignment!T,
T.stringof);
return emplace!T(cast(T)(chunk.ptr), args);
}
/***
* This code was copied from
https://wiki.dlang.org/Memory_Management#Explicit_Class_Instance_Allocation
* and attributed with @nogc
***/
class TestClass
{
int x;
this(int x) @nogc
{
puts("TestClass's constructor called");
this.x = x;
}
~this() @nogc
{
puts("TestClass's destructor called");
}
}
T heapAllocate(T, Args...) (Args args) @nogc
{
import core.stdc.stdlib : malloc;
import core.memory : GC;
// get class size of class instance in bytes
auto size = __traits(classInstanceSize, T);
// allocate memory for the object
auto memory = malloc(size)[0..size];
if(!memory)
{
import core.exception : onOutOfMemoryError;
onOutOfMemoryError();
}
puts("Memory allocated");
// notify garbage collector that it should scan this memory
GC.addRange(memory.ptr, size);
// call T's constructor and emplace instance on
// newly allocated memory
return emplace!(T, Args)(memory, args);
}
void heapDeallocate(T)(T obj) @nogc
{
import core.stdc.stdlib : free;
import core.memory : GC;
// calls obj's destructor
destroy(obj);
// garbage collector should no longer scan this memory
GC.removeRange(cast(void*)obj);
// free memory occupied by object
free(cast(void*)obj);
puts("Memory deallocated");
}
void main() @nogc
{
// allocate new instance of TestClass on the heap
auto test = heapAllocate!TestClass(42);
scope(exit)
{
heapDeallocate(test);
}
printf("test.x = %d\n", test.x);
}
-
Step 1. Make `emplace` @nogc
So we need to attribute `std.conv.emplace` as @nogc. Based on
the code above, that looks feasible. The difficulty, though will
be writing thorough tests for it.
Step 2. Make `destroy` @nogc
`destroy` simply calls `rt_finalize` in the runtime, at least for
classes. I declared it as `@nogc` in the cod
Re: understanding Auto-Test
On Thursday, 22 March 2018 at 01:46:08 UTC, John Belmonte wrote: I'm trying to understand why my pull request was queued in D2 Auto-Test for only 2 of 8 tests, with the remaining left in pending state. https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1&repoid=1&pullid=8051 Since there are pending tests, I'd expect it to appear in the standard priority pull queue under "Has passes". https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 What I'm I overlooking? Kindly, --John I believe what happened is a different PR was merged. When a PR is merged, all tests are invalidated, and the autotester begins testing them again. There is also a priority affecting which PRs get tested first. Those that are labeled with "AutoMerge" are given a higher priority. Mike
Re: understanding Auto-Test
On Thursday, 22 March 2018 at 04:17:52 UTC, Mike Franklin wrote: Let's see what happens after the auto-tester starts testing it again. Note that it could be a while, as there are PRs that will be getting merged in the next 24 hours that will restart the test queue. Mike
Re: understanding Auto-Test
On Thursday, 22 March 2018 at 04:12:00 UTC, John Belmonte wrote: I'm still rather puzzled. My pull request remains with 8 tests pending after several hours. I can't find any confirmation on the pulls display https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 that it intends to run the tests. Surely being listed in the "Old results" table doesn't imply pending runs against a new SHA, otherwise why would there be entries there dated 2017? I see. It appears GitHub didn't pick of the latest status (or the auto-tester didn't notify GitHub; I'm not which way the data flows). Let's see what happens after the auto-tester starts testing it again. I'll keep an eye on it. Mike
Re: Vtable for virtual functions in D
On Monday, 2 April 2018 at 07:02:07 UTC, sarn wrote: On Thursday, 8 March 2018 at 22:07:24 UTC, sarn wrote: On Thursday, 8 March 2018 at 04:37:08 UTC, Mike Franklin wrote: Nice! I was thinking about something almost exactly like this recently since 2.079.0 has features to further decouple the language from the runtime. It would be nice to read a blog post about this technique. Mike I didn't realise there was any interest. Sure, I'll try to make it one of my next few posts. I decided to pull some basic background info about vtables, etc, into its own post. I'll write about taking advantage of alias this and template metaprogramming in a later post. https://theartofmachinery.com/2018/04/02/inheritance_and_polymorphism.html Nice! Looking forward to part 2. Mike
Re: Vtable for virtual functions in D
On Wednesday, 7 March 2018 at 22:02:17 UTC, sarn wrote: When I wrote Xanthe a year ago, I rolled my own classes using alias this and explicit vtables: https://gitlab.com/sarneaud/xanthe/blob/master/src/game/rigid_body.d#L15 (I did this because normal D classes use the druntime library, and Xanthe was an experiment in not using the D runtime at all.) I'm curious about this comment in the code: Unfortunately, "protected" doesn't work, so a lot of members end up being public. This seems to just be an oversight in the language, so maybe it will change in future versions of D. What specifically do you think should be changed in the language to support your idea? Thanks, Mike
Re: [OT] Unity migrating parts of their engine from C++ into High Performace C# (HPC#)
On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote: Interesting that they are going the "No classes allowed" approach. It looks like the bullet points can be done in better c mode of D. I think you'll find Sarn's work on Xanthe quite interesting: https://forum.dlang.org/post/qjowkuwstewnmdune...@forum.dlang.org https://forum.dlang.org/post/ntnvrdoqgjpuogoxe...@forum.dlang.org D provides some remarkable features (type introspection, mixins, templates, etc...) that could make something like this possible in D. Regardless, I been pushing for a way to deallocated classes in the @nogc context, which apparently not very much people here seemed to care about. I think people care, but it's a difficult problem to solve due to the burden of some of D's technical debt. I know you are aware of the proposed ProtoObject which may provide an eventual solution. I, for one, am considering abandoning classes altogether and looking for ways to build on Sarn's aforementioned work to make object hierarchies in D using only structs. Mike
Re: DIP 1013: The Deprecation Process -- Community Review Round 1
On Monday, 2 April 2018 at 07:05:45 UTC, Mike Parker wrote: DIP 1013 is titled "The Deprecation Process". https://github.com/dlang/DIPs/blob/d8f6bfa1810c9774bd7d3b3dc6a7a6776ed5e17e/DIPs/DIP1013.md I think there should be some clarification on the stages of deprecation. For example, something like this: Stage 1: T0 - Start of deprecation 1. The deprecated feature is added to the Deprecated Features page to notify the public that a decision has been made to deprecate the feature. 2. Pull requests are submitted to update relevant sections of the documentation notifying readers that the feature has been deprecated. 3. Pull requests are submitted to remove all usages of the deprecated feature from DLang repositories. 4. Pull requests are submitted to cause the compiler to emit deprecation messages for any usage of the deprecated feature, and to update the Deprecated Features page with the release version of this change. A changelog entry is also required at this time. Stage 2: T0 + 5 non-patch releases 1. Pull requests are submitted to cause the compiler to emit error messages for any usage of the deprecated feature, and to update the Deprecated Features page with the release version of this change. A changelog entry is also required at this time. Stage3: T0 + 10 non-patch releases 1. Pull requests are submitted to remove all knowledge of the deprecated feature from both the documentation and the implementation. The Deprecated Features page is updated with the release version of this change. A changelog entry is also required at this time. In order to facilitate on schedule deprecations, a comment of the format @@@DEPRECATED_[version]@@@ should be added to the top of the code to be removed/disabled. Is `[version]` the version in which the deprecation took place, or the future version in which the next stage is to take place. For example, if I'm deprecating a feature in 2.080, should `[version]` be 2.080, or 2.085 (the version in which the features is changed to an error)? Mike
Re: Embedded Systems (STM32) LDC Absolute minimal runtime
On Thursday, 5 April 2018 at 15:58:28 UTC, Cora Dias wrote: Hi...i am a new user here. Welcome! As per my observation as suggested above you need a minimal runtime implementation that implements the features of D that your code is using, some that your code is not using but is required by the compiler just to get a build. Yeah, so D can be both a systems programming language and an applications programming language, and it's even convenient enough to use a scripting language :-) But that means that it has both high level and low level features. If you want to do bare-metal programming on the STM32 (or any resource-constrained micrcontroller), you may not want or need things like the garbage collector, runtime type information, etc. (though with something like the STM32F7, it may be the right choice). To do the low-level stuff, you just need the fundamental compiler facilities, and not much, if anything, from the runtime. So, you have a few options: 1) The -betterC switch - This switch allows you to use D like C. No classes, No runtime-type information, no exceptions, but you still get the compiler facilities like templates, mixins, etc. that aren't found in C. Thus it is a "better C". See https://dlang.org/spec/betterc.html and https://dlang.org/blog/category/betterc/ for lots of information about that. I am, personally, not a fan of betterC, and affectionately call it worseD. IMO, if the compiler would just be fixed to reduce coupling to the runtime (as was done recently in 2.079.0) betterC would not be needed. 2) A v2.079.0 compliant compiler - 2.079.0 did some long overdue decoupling of the compiler from the runtime so you no longer get compiler errors for missing features that your code doesn't even make use of. See https://dlang.org/changelog/2.079.0.html#minimal_runtime for more information about that. 3) A pre-2.079.0 version of a compiler with useless stubs to get the compiler to shut up and generate your binary. Trying to make a minimal runtime with the current LDC release is fraught with problems: (1) https://github.com/ldc-developers/ldc/issues/781 (2) https://github.com/ldc-developers/ldc/issues/552 GDC is much better, but still requires a few useless stubs to get a build (e.g. https://github.com/JinShil/stm32f42_discovery_demo/blob/master/source/runtime/object.d) LDC is currently working on adding the 2.079.0 features: https://github.com/ldc-developers/ldc/pull/2641 I hope it will be in the next LDC release. When that's done it will be a much better competitor with GDC (and may even surpass it) when it comes to ARM Cortex-M programming in D. I'm currently trying to find a way to contribute to GDC to accelerate its progress, but I have a lot to learn. A few resource which you may find interesting: https://bitbucket.org/timosi/minlibd - probably the most complete port of the D runtime to the ARM Cortex-M platform. I think it's only compatible with GDC at the moment though. https://github.com/JinShil/stm32f42_discovery_demo - A proof of concept illustrating the bare-metal programming ARM Cortex-M microcontrollers without the need for -betterC, opting for minimal runtime instead, is feasible. https://forum.dlang.org/post/qjowkuwstewnmdune...@forum.dlang.org, https://theartofmachinery.com/2018/04/02/inheritance_and_polymorphism.html - A very cool way of using D's mixin features to simulate classes without the D runtime. I hope that will give you some of what you were looking for. Mike
Re: #dbugfix 18493
On Monday, 16 April 2018 at 13:40:55 UTC, jmh530 wrote: On Monday, 16 April 2018 at 13:01:44 UTC, Radu wrote: A blocker for more advanced 'betterC' usage. https://issues.dlang.org/show_bug.cgi?id=18493 From what I can gather this appears to be caused by a `scope(failure)` statement (https://dlang.org/spec/statement.html#scope-guard-statement) being added to the Postblit body (a.k.a. __fieldPostblit internally in the compiler). I'm assuming `scope(failure)` is just syntactic sugar for a try-catch. I don't know how Walter wants to handle such a situation in -betterC. If I knew, I might be able to fix this bug. Mike
Re: #dbugfix 18493
On Tuesday, 17 April 2018 at 00:27:07 UTC, Nicholas Wilson wrote:
It is odd though since
void foo (){}
extern(C) void main()
{
scope(exit) foo();
}
compiles and runs with -betterC
I believe `scope(exit)` is fine because it is basically
try-finally, but `scope(failure)` won't work because it is
try-catch.
Mike
Re: #dbugfix 18493
On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:
This is very odd, as the following compiles:
---
struct S
{
this(this)
{
}
~this()
{
}
}
struct C
{
S s1;
}
---
If the scope failure would cause this then I assume it would
not work at all in any case.
Yeah! I think that is also a bug. So (at least right now in my
investigation) I think we first need to fix it so that it emits
the error even with a single statement, and then fix it so it no
longer generates the `scope(failure)` in -betterC.
Mike
Re: #dbugfix 18493
On Tuesday, 17 April 2018 at 12:13:06 UTC, Mike Franklin wrote:
On Tuesday, 17 April 2018 at 05:33:53 UTC, Radu wrote:
This is very odd, as the following compiles:
---
struct S
{
this(this)
{
}
~this()
{
}
}
struct C
{
S s1;
}
---
If the scope failure would cause this then I assume it would
not work at all in any case.
Yeah! I think that is also a bug.
Nope, that's not a bug. The reason the try-catch is only
generated with two or more fields is to ensure that if an
exception is thrown while blitting `s2`, `s1`'s destructor will
still be called.
I'm not sure what the proper fix is yet. The compiler could
require you to attribute `this(this)` with `nothrow` in order to
promise the compiler that it won't throw. Then the compiler
would know that it wouldn't need to add the try-catch around the
postblit because there's no way for it to throw. That would also
ensure consistent behavior when compiling the same code with or
without -betterC.
However, since throwing is off-limits entirely for -betterC, it
doesn't make much sense to generate try-catch statements, only to
have the compiler emit an error about it.
Maybe I should implement both. I need to sleep on it.
Mike
Re: DIP 1013: The Deprecation Process -- Community Review Round 1
On Monday, 2 April 2018 at 07:05:45 UTC, Mike Parker wrote: DIP 1013 is titled "The Deprecation Process". https://github.com/dlang/DIPs/blob/d8f6bfa1810c9774bd7d3b3dc6a7a6776ed5e17e/DIPs/DIP1013.md I've been thinking about the deprecation schedule being measure in terms of releases, and I don't like it. How was the 10-version schedule determined anyway; probably because it equated to 2 years under the current release schedule (1 year as a deprecation warning, 1 year as an error). So time is the intrinsic impetus. If we were to move to a schedule of releases every 6 months, would that require a deprecation period of 5 years? I sure hope not. Or, if we were to move to a schedule of releases every month, would the deprecation period be only 10 months? Cool! I suggest making it "a minimum of 2 years and a maximum of 10 releases", or something of that nature. Mike
Re: DIP 1013: The Deprecation Process -- Community Review Round 1
On Wednesday, 18 April 2018 at 12:28:59 UTC, Jonathan M Davis wrote: > In order to facilitate on schedule deprecations, a comment > of the format @@@DEPRECATED_[version]@@@ should be added to > the top of the code to be removed/disabled. Is `[version]` the version in which the deprecation took place, or the future version in which the next stage is to take place. For example, if I'm deprecating a feature in 2.080, should `[version]` be 2.080, or 2.085 (the version in which the features is changed to an error)? As I said before, it's never changed to an error. The DIP quite specifically never does that, and really I don't think that it should. The current process, as I understand it for language features, is the deprecated feature is a deprecation message for a year, and then an error for a year. After 2 years of being deprecated it is removed. Perhaps you were only referring to a deprecated library feature. Mike
Re: Using D without libphobos
On Thursday, 26 April 2018 at 03:04:55 UTC, A. Nicholi wrote: I am working on a large cross-platform project, which will be written primarily in D, interfacing to C as necessary. To get finer control over memory safety, binary size, and use of the GC, we would like to disclude libphobos as a dependency in lieu of our own code. The project is compiled using LDC. I am not sure if this is possible though, as it seems there are certain things in libphobos that are tightly coupled into the D runtime. There are several things in the core namespace that would be helpful for us (SIMD, C bindings, etc), but I am not sure if that is not also part of libphobos along with the other namespaces. How do I remove libphobos as a runtime dependency with ld and MSVC’s link.exe? Is it possible to decouple core from other parts of the runtime, and if so, how? I suggest reading the following 2 items before digging deeper: https://dlang.org/blog/2017/08/23/d-as-a-better-c/ https://dlang.org/changelog/2.079.0.html#minimal_runtime Next you should realize that Phobos and DRuntime are actually 2 different things that are, unfortunately, often compiled together into one "libphobos2" binary when the compiler is released. Phobos is the standard library: https://github.com/dlang/phobos DRuntime contains C language bindings, OS bindings, and some D language feature implementations, including the GC. https://github.com/dlang/druntime It's quite unfortunate there so much hard coupling between all of these components, but that's the way it is. Phobos depends on DRuntime. DRuntime depends on C language bindings and OS bindings. Compiling the simplest of programs with DMD (https://run.dlang.io/is/KMjKsJ) results in the following C compiler invocation: -- cc onlineapp.o -o /tmp/dmd_run3nK4IS -g -m64 -Xlinker -v -L/dlang/dmd/linux/bin64/../lib64 -Xlinker --export-dynamic -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread -lm -lrt -ldl Which in turn calls the following linker invocation: -- GNU gold (GNU Binutils for Ubuntu 2.29.1) 1.14 collect2 version 7.2.0 /usr/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccg3GKxT.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o /tmp/dmd_run3nK4IS /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/dlang/dmd/linux/bin64/../lib64 -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/dlang/dmd/linux/lib64 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. onlineapp.o -v --export-dynamic -Bstatic -lphobos2 -Bdynamic -lpthread -lm -lrt -ldl -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o The compiler uses the C compiler (unfortunately again) to do its linking; and it becomes evident that D is in some ways a layer on top of C. You can compile some D programs without linking libphobos2, but will require separate compilation and linking because the compiler itself actually hard-codes the call to the linker (actually the C compiler as demonstrated above). Example 3 at https://dlang.org/changelog/2.079.0.html#minimal_runtime demonstrates this. If you use that method, you won't be able to use certain features of D that have runtime implementations. The obvious ones are classes, dynamic arrays, and exceptions. I could go on, but I'd have to make some assumptions about what you're really after. Feel free to ask more specific questions and I'll be happy to share what I know (or at least what I think I know; sometimes I'm wrong). Mike
Re: Using D without libphobos
On Thursday, 26 April 2018 at 09:24:19 UTC, A. Nicholi wrote:
So in a way, the D runtime is similar to libstdc++, providing
implementations of runtime language features.
I would argue that Phobos is more analogous to libstc++, but
there are some language features in C++ that are implemented in
libstc++. For example, if you try to compile the following code.
---main.cpp
int main()
{
throw 1;
return 0;
}
$g++ -c main.cpp
$ld main.o
ld: warning: cannot find entry symbol _start; defaulting to
004000e8
main.o: In function `main':
main.cpp:(.text+0xa): undefined reference to
`__cxa_allocate_exception'
main.cpp:(.text+0x1c): undefined reference to `typeinfo for int'
main.cpp:(.text+0x24): undefined reference to `__cxa_throw'
So, yeah those "__cxa_..." functions are very similar to what
you'll find in Druntim. D calls them runtime hooks, and you can
find an unmaintained list of them here:
https://wiki.dlang.org/Runtime_Hooks
Here's similar experiment in D. IMO D is actually better than
C++ in this regard because it emits a compile-time error, instead
of a linker error, when it can't find something in the runtime
that it needs.
---object.d
module object;
// this useless object.d file is currently required, though I'm
trying to
// find a way to get rid of such nonsense.
// See https://github.com/dlang/dmd/pull/7825
---main.d
void main()
{
throw new Exception("whatever");
}
$dmd -conf= -defaultlib= main.d
main.d(3): Error: Cannot use throw statements because
object.Throwable was not declared
But it is also like C++ in that those language features can be
avoided, correct?
That was the goal with the "minimal runtime" features released in
v2.079. It's still a work in progress though. See
https://github.com/dlang/dmd/pull/8204
But, yes, as long as you avoid certain features that require
runtime implementations in your code, you should still be able to
write software in D. And, if I am allowed to have may way, it
should get even better.
At least with the use of minimal D, I mean. This means that as
a language, there is enough granularity to theoretically
provide as few or as many features as one desires for their use
case, making the penning of new C and C++ code redundant? Do I
get this right?
Not sure if I totally understand that, but it sounds right on.
The goal with the minimal runtime features is to allow one use D
on any platform in a pay-as-you-go fashion. That is, you only
need to implement what you intend to use. The primary use case I
have in mind is using D for resource-constrained
microcontrollers, though it would also be useful for libraries
written in D, but intended to be linked in by applications
written in other languages. I'm there are also use cases that I
haven't even thought of.
Mike
Re: Bugzilla & PR sprint on the first weekend of every month
On Tuesday, 8 May 2018 at 18:48:15 UTC, Seb wrote: What do you guys think about having a dedicated "Bugzilla & PR sprint" at the first weekend of very month? We could organize this a bit by posting the currently "hot" bugs a few days ahead and also make sure that there are plenty of "bootcamp" bugs, s.t. even newcomers can start to get involved. Even if you aren't too much interested in this effort, being a bit more active on Slack/IRC or responsive on GitHub on this weekend would help, s.t. newcomers interested in squashing D bugs get over the initial hurdles pretty quickly and we can finally resolve the long-stalled PRs and find a consensus on them. What do you think? Is this something worth trying? Maybe the DLF could also step in and provide small goodies for all bug hunters of the weekend (e.g. a "D bug hunter" shirt if you got more than X PRs merged). I like the idea, but our current deficiency is not contributions, but reviews. If we do something like this, we'll probably get more PRs in the queue, but they may end up sitting there waiting for a decision through to the next sprint. I, alone, could easily fill the PR queue with more contributions from my backlog, but that will just take resources away from other PRs waiting for review. IMO what we need is a way to increase the number of people who have the talent and good judgement to quickly bring PRs to a resolution (merge or close), and to mentor contributors so they can become mentors themselves. With more review capacity (and velocity) we'd probably get more contributions organically without any additional effort or organization. Mike
Re: Is D releasing too often?
On Monday, 14 May 2018 at 07:20:48 UTC, Joakim wrote: There are obviously pros and cons to each pace, and this has been debated internally before, with one of the ldc devs again posting to the Internals mailing list today questioning the current speed. The post is here: https://forum.dlang.org/post/ingkexhebiaqdzkni...@forum.dlang.org My interpretation of that post is it's not the frequency of releases that's the problem, but rather that bug fixes and language changes are mixed together in each release. If it's really a problem, one potential solution could be to keep bug fix releases every 2 months, but only release language changes every 4 or 6 months. But that's not cost-free either, as it will put more of a burden on compiler developers and release managers to maintain parallel branches and deal with the inevitable hassle and controversy involved in deciding which PR goes in which branch, as sometimes bug fixes and language changes are the same thing. Reviewing PRs requires quite a bit of subjective judgement and conflicting opinions, and it's best to not add more aggravation to an already aggravating process. I thought I'd open it up to the community: now that you've experienced this faster pace, as a user of the D compilers, how do you like it? Would you prefer a slower release schedule, say 3-4 major releases a year? I think the pace is just about right, though I could even tolerate even more frequent releases. Less frequent releases would actually be a somewhat irritating to me. For example, I have a language change in 2.081 that I really need in LDC today, but it looks like I'm going to have to wait at least 4 months to get it. IMO, the current schedule is working out quite well. Mike
Re: DIP 1011 library alternative
On Tuesday, 15 May 2018 at 22:26:54 UTC, Jonathan M Davis wrote: I _think_ that it only works if the function isn't templated. A PR to remove that limitation has been submitted at https://github.com/dlang/dmd/pull/8195, but once again, we're waiting on someone from the top to give it their blessing. Mike
Re: Arduino and D
On Wednesday, 16 May 2018 at 08:48:26 UTC, Russel Winder wrote: Is D wthout Phobos useful for IoT or should one stick with C,Lua, and MicroPython? Is IoT an opportunity for D or is it a false direction given D is an x86/x86_64 oriented programming language? Using D for programming ARM Cortex-M 32-bit microcontrollers is one of my primary interests for learning and contributing to D. https://github.com/JinShil/stm32f42_discovery_demo When 2.081 arrives at LDC, I'll hopefully get that demonstration working with LDC. -betterC is not necessary, but you have to be selective about which features you use in D. Some parts of Phobos could be used, but they'd have to be selectively pulled out of the source code. Mike
Re: Expression based contract syntax
On Friday, 18 May 2018 at 05:28:10 UTC, Arun Chandrasekaran wrote: Has this been implemented in DMD master? So I was looking at the changelog[1] and tried to build the example, but it erred. https://github.com/dlang/dmd/blob/master/changelog/expression-based_contract_syntax.dd https://github.com/dlang/dmd/pull/8155 I believe it will arrive in the next release, 2.081. I think you can use it from one of the nightly builds, but there might currently be a problem with our the publishing of our nightlies: https://github.com/dlang-tour/core/issues/696 Mike
Re: Help me please fix the bug
On Friday, 18 May 2018 at 05:44:12 UTC, Majestio wrote: == log: == [majestio@freebsd ~/Projects/webapp]$ dub Performing "debug" build using /usr/local/bin/dmd for x86_64. taggedalgebraic 0.10.11: target for configuration "library" is up to date. eventcore 0.8.34: building configuration "kqueue"... /home/majestio/.dub/packages/eventcore-0.8.34/eventcore/source/eventcore/drivers/posix/kqueue.d(43,46): Error: function 'eventcore.drivers.posix.kqueue.KqueueEventLoop.this.__lambda1' is not nothrow /home/majestio/.dub/packages/eventcore-0.8.34/eventcore/source/eventcore/drivers/posix/kqueue.d(41,2): Error: nothrow constructor 'eventcore.drivers.posix.kqueue.KqueueEventLoop.this' may throw /home/majestio/.dub/packages/eventcore-0.8.34/eventcore/source/eventcore/drivers/posix/kqueue.d(60,20): Error: function 'core.sys.freebsd.sys.event.kevent' is not nothrow /home/majestio/.dub/packages/eventcore-0.8.34/eventcore/source/eventcore/drivers/posix/kqueue.d(48,16): Error: nothrow function 'eventcore.drivers.posix.kqueue.KqueueEventLoop.doProcessEvents' may throw /usr/local/bin/dmd failed with exit code 1. I'm not sure, but I recently fixed an issue very much related to this: https://github.com/dlang/dmd/pull/8184 I'm curious if you could download one of the nightly compilers and test if it is still problem: http://nightlies.dlang.org/dmd-master-2018-05-18/ Mike
Re: Help me please fix the bug
On Friday, 18 May 2018 at 05:44:12 UTC, Majestio wrote:
this()
@safe nothrow {
m_queue = () @trusted { return kqueue(); } ();
m_events.length = 100;
assert(m_queue >= 0, "Failed to create kqueue.");
}
Also, I believe this is __lambda1:
m_queue = () @trusted { return kqueue(); } ();
Is `kqueue()` nothrow? You probably need to decorate that lambda
with `nothrow`. (i.e. put a `nothrow` right after `@trusted`.
Mike
Re: Help me please fix the bug
On Friday, 18 May 2018 at 09:35:28 UTC, Majestio wrote:
Also, I believe this is __lambda1:
m_queue = () @trusted { return kqueue(); } ();
Is `kqueue()` nothrow? You probably need to decorate that
lambda with `nothrow`. (i.e. put a `nothrow` right after
`@trusted`.
Mike
`kqueue()` is not nothrow. From log: "Error: function
'core.sys.freebsd.sys.event.kqueue' is not nothrow"
This decoration does not solve the problem :(
But you're calling it from a `nothrow` function through a lambda
that is also not `nothrow`. Decorate your lambda as `nothrow`
and then, if you can't make `kqueue()` `nothrow`, put it in a
try-catch and figure out what to do if it does throw.
m_queue = () @trusted nothrow
{
try
{
return kqueue();
}
catch(Exception ex)
{
// what do you want to do about it?
}
} ();
Mike
Re: Need help with the dmd package on NixOS
On Friday, 18 May 2018 at 10:28:37 UTC, Thomas Mader wrote: On Friday, 11 May 2018 at 04:27:20 UTC, Thomas Mader wrote: My suspicion about the switch to glibc 2.27 being the problem was wrong. I did a very timeconsuming bisection and found the problem commit to be the one which bumped binutils to 2.30. Can somebody help me to answer the question from https://sourceware.org/bugzilla/show_bug.cgi?id=23199#c4 please. The object is created by the dmd backend but where in the code is binutils used? I'm not sure I understand. Does binutils need to be used to generated an object file? My understanding is the DMD creates the object file without the help of binutils. The only time binutils is really called is when it calls `gcc` to do the link at https://github.com/dlang/dmd/blob/b61d1c8989bed54489c9c7eb5acc2e1f4312b8c6/src/dmd/link.d#L157 Mike
Re: CI buildbots
On Monday, 21 May 2018 at 07:21:31 UTC, Manu wrote: A few of those machines can build AND run the tests in 5-6 mintues. A lot under 10 minutes... Then there's a few that take 45+ minutes. Why are they in the pool? Is it really worth having 20 machines build the thing, especially when a few of them blow the turn-around time to into hours rather than minutes? I'm not sure of the best way to elicit action on this issue, but if it were me, I'd try filing and issue at https://github.com/braddr/d-tester/issues and see what Brad says. Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! I would like to see a dependency-less Phobos-like library that can be used by the DMD compiler, druntime, -betterC, and other runtime-less/phobos-less use cases. It would have no dependencies whatsoever. There's a lot of useful stuff in Phobos that does not need to be dependent on other Phobos modules or Druntime. std.meta is the first that likely comes to mind, but then there's also traits, typecons, demangle, etc.. As a contrived illustration, take a look at the code in https://github.com/dlang/druntime/blob/master/src/core/internal/string.d Those same features are also in Phobos. Such a library would make more D idioms available to the compilers, druntime, and those that are programming runtime-less applications like bare-metal, operating systems, microcontrollers, or libraries used from other languages. I already started a project at https://github.com/JinShil/utiliD just a few days ago. It'd be great is someone else could do the work instead :-) Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! It might be useful for measuring D's progress if we had some kind of stats about D updated on a daily basis. This is the most useful page I know of at the moment: https://auto-tester.puremagic.com/chart.ghtml?projectid=1 Some stats that would be nice to see: * Pull Requests per hour/day/week/month/year * PR reviews per hour/day/week/month/year * Stats about website (basically the kind of stuff you'd get from google analytics dashboard) * Number of D repositories on Github/Bitbucket/whatever * Number of contributions to D repositories per hour/day/week/month/year Those are just things that popped into my head while writing this post. I'm sure someone invested in such a project could come up with more useful stats. We just want some data to measure progress (or lack thereof) so we can inform where to allocate resources. Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! Make WebAssembly a thing in D. See https://forum.dlang.org/post/ejplfelcqsvjmdvxt...@forum.dlang.org Currently C++ and Rust dominate that domain. D could kick some web asm there too. Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! An apprentice for Walter. I think Walter needs an apprentice (or 10). Too much knowledge about D's design decisions, present, and future are locked up in his mind. He needs to be disseminating his knowledge, training the next generation of D maintainers, and widening the bottleneck that currently exists for fixing bugs and evolving the language. Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! Get some help allocated to GDC. It seems progress on GDC has stalled for reasons I'm not quite sure of. I'm trying to help, but it's becoming more apparent that I'm not the right person for the job. Getting GDC up to date as much as possible with DMD's frontend and getting GDC merged into the next GCC release would be a boon for D. Is there something we can do to move that along? Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! Find a way to improve the performance of our CIs. See https://forum.dlang.org/post/mailman.1018.1526887297.29801.digitalmar...@puremagic.com The more time a PR is "green" the higher the likelihood it will be reviewed. Having a more performant CI infrastructure could help with our review bottleneck, and also make the experience for contributors less frustrating. GDC is using Buildbot (https://buildbot.net/) for some of its CIs. I've been wondering if it might be less costly and more performant to create a distributed Buildbot CI for the dlang repositories, and allow community members volunteer their hardware resources to bring down the cost and increase the throughput of our testing. Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! Fork newCTFE and bring it to completion: https://dlang.org/blog/2017/04/10/the-new-ctfe-engine/ Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! I haven't looked into this myself, but I vaguely remember an ongoing problem with DMDs performance (especially memory usage) gradually degrading with time. I think it would be a nice exercise for someone to do some profiling on DMD and make some recommendations, or under the guidance of Walter, do some refactoring to improve DMDs performance. Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! An LDC or GDC cross-compiler generator for the Raspberry Pi. There are already some instructions out there (e.g. http://d-land.sepany.de/einstieg-in-die-raspberry-pi-entwicklung-mit-ldc.html), but what we really need are shell scripts for Linux and Windows that we can download and run, and out pops a read-to-use compiler that can generate binaries on either Windows or Linux for the Raspberry Pi. See my GDC cross-compiler generator at https://github.com/JinShil/arm-none-eabi-gdc I do a lot of support for scientists, engineers, and entrepreneurs of other non-software-related disciplines. The all need to write code and all want to create embedded systems for their research or their product. I believe many of them would enjoy D (due to their current knowledge of C) for their work if there wasn't such a high barrier to entry just to get the development tooling set up. Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! Building and running the DMD test suite on vanilla Windows is a pain. I never succeeded but it appears to require the user to first set up a posix environment and then battle environment configuration, and other vague dependencies such as whether you are building for 32-bit or 64-bit and whether Visual Studio 2017 is installed. I believe most contribute to D with a Linux development machine, but sometimes there are Windows-only issues that need to be solved. For that we need to be able to build and test our changes on Windows without hassle. I'd like to see the requirement for a posix environment lifted by porting all makefiles to D, so the same code (with appropriate `version`ing of course) could be used to compile and build dlang repositories on all platforms without a lot of environment setup and configuration. All that would be required a recent D compiler in one's PATH. See https://github.com/dlang/dmd/pull/8162 for some working moving in that direction. Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! Try to replace some of the basic software building blocks (memcpy, memcmp, malloc, free, realloc) that are currently leveraged from the platform's C library with counterparts, and provide a D API that uses `T[]` instead of void* and provides some of D's compile-time guarantees like safety, purity, and nothrow. Implementation would take into consideration a platform's unique features such a SIMD. Determine if there are any special features of D that can actually improve the performance of the highly optimized C implementations, perhaps leveraging information known at compile-time. The project would provide an exemplary illustration of D's capabilities with benchmarks comparing it with C, and hopefully demonstrate that we don't need to have artificial dependencies on libc anymore. Mike
Re: Ideas for students' summer projects
On Wednesday, 23 May 2018 at 04:17:19 UTC, Mike Franklin wrote: On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! Try to replace some of the basic software building blocks (memcpy, memcmp, malloc, free, realloc) that are currently leveraged from the platform's C library with counterparts, and Sorry, I didn't really complete my thought well in that sentence. I meant to say "... with counterparts written in D". Mike
Re: Ideas for students' summer projects
On Wednesday, 23 May 2018 at 04:58:17 UTC, rikki cattermole wrote: In essence a -betterC libc with wrapper functions for extern(D). I'd prefer to not even need to link in libc. I mean rewrite memcpy, memcmp, malloc, free, and realloc in D. Once those building blocks exist in D, everything becomes possible without libc. Mike
Re: Ideas for students' summer projects
On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! I've often wondered if D has the right features to implement a borrow-checker in the library. Something similar to this: https://www.youtube.com/watch?v=Lj1GppqNr8c https://gist.github.com/foonathan/023ff0fe923c6b0312dfc15e17ebb595 Probably not, but it would be a fun exercise. Mike
Re: Ideas for students' summer projects
On Wednesday, 23 May 2018 at 03:43:16 UTC, Mike Franklin wrote: On Tuesday, 22 May 2018 at 16:27:05 UTC, Eduard Staniloiu wrote: Let the brainstorming begin! An LDC or GDC cross-compiler generator for the Raspberry Pi. There are already some instructions out there (e.g. http://d-land.sepany.de/einstieg-in-die-raspberry-pi-entwicklung-mit-ldc.html), but what we really need are shell scripts for Linux and Windows that we can download and run, and out pops a read-to-use compiler that can generate binaries on either Windows or Linux for the Raspberry Pi. See my GDC cross-compiler generator at https://github.com/JinShil/arm-none-eabi-gdc I do a lot of support for scientists, engineers, and entrepreneurs of other non-software-related disciplines. The all need to write code and all want to create embedded systems for their research or their product. I believe many of them would enjoy D (due to their current knowledge of C) for their work if there wasn't such a high barrier to entry just to get the development tooling set up. Clarification: It's not just the cross-compiler that we need. We need the whole toolchain including druntime, phobos, and a linker that can generated both dynamic and static-liked libraries from a host PC. Including other utilities from binutils, LLVM, and even a debugger for remote-debugging from the host development PC would be ideal. Mike
Re: run.dlang.io/ add scrolling window and possibly src line mapping
On Wednesday, 23 May 2018 at 22:33:05 UTC, IntegratedDimensions wrote: Large code is produced for assmly and others and it would be nice if it had it's own window to scroll rather than scrolling the entire window. Also it would be nice if clicking on a line in the src scrolled to the proper location in the output It would also be nice if the imports were removed or hiddable from the source. Probably would be easier to read if also the source code lines that generate the assembly were inserted in the code where they are disassembled. Please file issues for run.dlang.io at https://github.com/dlang-tour/core/issues Thanks, Mike
Contributing to DMD
On Wednesday, 23 May 2018 at 14:25:44 UTC, Steven Schveighoffer wrote: Common questions I have when looking at dmd code: Where is this in the source? How do I know I'm in a function? How do I know I'm in a template? What module am I in? How do I know what has been run? What is the proper way to generate lowered code? I hear you, I think most of us have been there. Razvan also mentioned this in the beginning of his DConf talk. The only documentation that I know of is https://wiki.dlang.org/DMD_Source_Guide. I believe its very outdated, but probably still helpful. You get to it from the from page of the wiki by going to "Compilers & Tools" --> "DMD". I'll share how I got started, as I think it might serve as a path for others. 1. I filed this issue about `static alias this`: https://issues.dlang.org/show_bug.cgi?id=17684 2. Vladimir identified it as a regression, and posted the PR that broke it. 3. The PR that broke it was super simple, so I figured if it was simple to break, it would be simple to fix. 4. Yep, after a lot of grepping, it was pretty simple to fix: https://github.com/dlang/dmd/pull/7055 5. It got a little euphoric about fixing this and that motivated me to do more. And it just took off from there. I recognize not everyone will have a simple fix like this to get them past the barrier to entry. And fewer will get their PR reviewed and merged like mine was (Thanks Petar). I actually learned a lot by studying other people's PRs, trying to learn what they were doing any why. If you have a bug you'd like to fix, search through the open and closed PRs and see if you can find something similar. Study it and see if you can extrapolate any understanding from it. I also received a LOT of help from Iain when I attempted this ambitions fix: https://github.com/dlang/dmd/pull/7079. Again, few people will receive such valuable help, so I am very fortunate, but it may be a strategy to just try, knowing your fix is wrong, and hope in the review process you'll get the information you need to make it correct. But you could also irritate a lot of people if such a PR shows little effort on your part. A few questions I had when I got started: Q. How do I build the compiler? A: `make -f posix.mak -j4` Q: How do I run the test suite locally? A: `make -C test/ -f Makefile -j4` Finally, if anyone needs help, please ask questions on the forum (General or Internals for compiler devs), slack, IRC, etc. If you don't get an answer, it doesn't mean you're being ignored; not many people know how to answer such questions. That all being said, here's the kicker which both Steven and Rikki alluded to: We have a review bottleneck, not a contribution bottleneck. If we could attract more talent with the domain expertise needed to certify a PR, then the contributions would increase organically. That's a terrible reality, but I fear that if anyone heeds any of what I said and starts making PRs, their PRs will just rot in the PR queue waiting for a review. Finding minuscule problems with a PR is easy, being able to say "yes, this is the right fix" is hard...very hard, and comes with consequences if you're wrong. Unfortunately, those with the expertise to certify difficult PRs tend to be very part-time reviewers, and sorry, I'm not one of them. There are a few characteristics of a PR that will increase likelihood of review: * Has tests and passes the test suite * Is noncontroversial * Benefit is obvious (i.e. Fixes a bug, especially a regression, and is not an enhancement). This is preventing me from certifying Rikki's PR. * Has clear explanation of the problem and the fix so anyone can understand it. Not everyone has an intimate understanding of the problem like you, help them out. This is what is preventing me from reviewing and certifying Steven's and Rikki's PRs. * It's simple. The fewer lines of change, the better. There are few characteristics of a PR that will decrease likelihood of a review: * No tests and/or test suite shows a red X * Is controversial or benefit is not obvious * Reviewer has to spend a lot of time studying the code to figure out why and what * Has a lot of refactoring changes that aren't needed for the actual fix I was thinking about making a set of videos about how to get started contributing to the compiler, but I decided it wouldn't be a good idea until we can do something about our PR bottleneck; it'd probably just fill the PR queue making matters worse. Anyway, that's my two-cents. Take everything I've said with a grain of salt (as they say); I'm often wrong. Mike
Re: D's Destructors are What Scott Meyers Warned Us About
On Wednesday, 23 May 2018 at 13:12:57 UTC, Steven Schveighoffer wrote: Hm.. that should be fixed. I don't see why we can't just do = T.init, we should at least be optimizing to this for small enough structs. The problem I ran into with this is that if you use T.init directly you end up making copies (postblit) and then needing to destruct those copies since they are temporary. That's why I had to lower it to simpler byte array primitive. Mike
Re: Ideas for students' summer projects
On Wednesday, 23 May 2018 at 14:25:44 UTC, Steven Schveighoffer
wrote:
How do I know I'm in a function?
I don't think you're ever actually "in a function". The code is
just data passing through the compiler. I think what your may be
asking is "How do I know I'm working on a function?". That
depends on what stage in the the code->binary translation process
your at (parsing, semantic, {not sure about others}). Usually
this is done with a `visit(` method. grep for
`visit(FuncDeclaration` or `visit(FuncExp`. You may be deep in
the body of a function, processing some other expression, though.
For that, you'll want to turn on the logging features in DMD
when you do a build so you can see output each time an expression
is visited; grep for `LOGSEMANTIC`.
How do I know I'm in a template?
Same principle as above. grep for `visit(TemplateInstance` or
`visit(TemplateDeclaration`.
What module am I in?
grep `visit(Module`, maybe?
I think for all of my answers above, you can also navigate up the
AST using the `.parent` property of a symbol; see the
dmd.dsymbol.Dsybmol class.
How do I know what has been run?
I'd say by turning on logging in the various source files.
What is the proper way to generate lowered code?
You're basically writing D code with D code. The `Expression`
class and it's derived classes are where its at. See my failed
attempt at lowering array literals to template here:
https://github.com/dlang/dmd/pull/8245/files
Also my Binary Assignment Operators PR is an exemplary exercise
in lowering: https://github.com/dlang/dmd/pull/7079/files
Hope that helps at least a little. It'll probably just generate
more questions, but keep them coming.
Mike
Re: Ideas for students' summer projects
On Thursday, 24 May 2018 at 18:08:35 UTC, Patrick Schluter wrote: As a contrived illustration, take a look at the code in https://github.com/dlang/druntime/blob/master/src/core/internal/string.d Those same features are also in Phobos. OT, numberDigits enters an infinite loop if radix == 1. and crashes for radix == 0 All the more reason to implement my proposal.
Re: Ideas for students' summer projects
On Friday, 25 May 2018 at 12:23:35 UTC, Seb wrote: I just gave converting the DMD Make build script to D a quick shot and it doesn't look too complicated: Very Nice! Many thumbs up! And, welcome back! Mike
Re: Draft for DIP concerning destroy is up.
On Friday, 25 May 2018 at 20:08:23 UTC, 12345swordy wrote: https://github.com/dlang/DIPs/pull/120 Feedback would be very appreciated. I was under the impression that Andrei's ProtoObject was supposed to remedy that: https://forum.dlang.org/post/pa1lg6$1lud$1...@digitalmars.com Mike
Re: D's Destructors are What Scott Meyers Warned Us About
On Wednesday, 23 May 2018 at 19:05:38 UTC, Manu wrote: For my money it would be: destroy() <- just destroy reset() <- destroy and re-init Or something like that. Maybe: class.destruct(); <- destroy without init? Yeah that. I'll make a PR! I had an in-depth discussion with Andrei about this at https://github.com/dlang/druntime/pull/2115 He ultimately gave up on trying to explain it to me and created his own PR here: https://github.com/dlang/druntime/pull/2126 It's be good to review that discussion, and perhaps weigh in on #2126. Mike
Re: D's Destructors are What Scott Meyers Warned Us About
On Friday, 25 May 2018 at 23:47:33 UTC, sarn wrote: That std.signals code that Steven filed a bug report for is example of why we can't just fix the behaviour, though. If we just fixed __dtor/__xdtor, any code that used std.signals would start having ugly bugs at run time. I think that longer term we'll have to deprecate and remove these functions. I'm very much interested in doing something about these functions. __xdtor is just one. There are others at https://github.com/dlang/druntime/blob/54ab96e9977e0c6baa7ed9740810058fd4aec6ef/src/object.d#L1212-L1229. __xtoHash is currently causing problems at https://github.com/dlang/dmd/pull/8222 TypeInfo has become my nemesis. I've been trying to replace runtime hooks that depend on TypeInfo with templates that can get their information at compile-time, but I'm running into all sorts of problems. e.g. Did you know array.length can be set in @safe nothrow pure code, but it lowers to runtime functions that are neither @safe, nothrow, nor pure? Anyway, I'm getting better at modifying the compiler/runtime interface. If we can come up with a solution to this mess, and I can understand it, I might be able to implement it. Mike
Re: DIP 1012--Attributes--Preliminary Review Round 1
On Thursday, 27 July 2017 at 14:44:23 UTC, Mike Parker wrote: DIP 1012 is titled "Attributes". https://github.com/dlang/DIPs/blob/master/DIPs/DIP1012.md All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on August 10 (3:59 AM GMT August 11), or when I make a post declaring it complete. I don't know what's happening with this DIP, but I've recently encountered a real-world problem for which there is no palatable workaround that this DIP would likely solve: https://github.com/dlang/druntime/pull/2184#pullrequestreview-120643123 My attempts to workaround the issue I posted at https://forum.dlang.org/post/uhgzgmowqcczczrdt...@forum.dlang.org That PR may be useful for motivating this DIP. Mike
Re: D's Destructors are What Scott Meyers Warned Us About
On Sunday, 27 May 2018 at 16:06:21 UTC, 12345swordy wrote: You are replacing runtime typeinfo with compiletime templates. Unless you can guarantee that the type information won't change during runtime, you are going to have a hard time. Read this thread for context https://forum.dlang.org/post/mr7a65$2hc$1...@digitalmars.com See this PR for an example https://github.com/dlang/dmd/pull/7225 And see this talk for a demonstration of the benefits https://www.youtube.com/watch?v=endKC3fDxqs Mike
Re: The problem with D's properties
On Thursday, 31 May 2018 at 01:49:42 UTC, DigitalDesigns wrote: https://dpaste.dzfl.pl/6c6e614b58ac The problem given in the list, is that a ref getter is used when a setter does not exist. Why have a setter then? One problem is that if the setter has different behavior than the getter there will be problems. The other problem is that += modifies the value. normally getters are thought to be immutable in the since that they just return a value. but a += will modify what a points to. Using setters, we might want to trigger an event when the value changes. But since the getter is used and can modify the event won't be triggered. This is a bad design. any modifying operator should call the setter. This is precisely what "set mean". a += b is suppose to be syntactic sugar for a = a + b, yet we get different behavior. In one case only a getter is called and in the second case the getter and then the setter. How D currently handles this is wrong and error prone. Either depreciate the use of op assignments using properties or fix it! lvalues should ALWAYS use the setter, it makes no sense otherwise. In case you're not already aware, there is a DIP in progress to remedy this issue: https://github.com/dlang/DIPs/pull/97. A few bugs have already been filed on this, and the DIP intends to address that. If you have anything to add, please voice your thoughts in the DIP's PR. Mike
