Re: Preparing for the New DIP Process
On Sunday, 21 January 2024 at 07:11:50 UTC, Jordan Wilson wrote: On Saturday, 20 January 2024 at 22:53:15 UTC, privateWHAT wrote: On Thursday, 18 January 2024 at 07:19:19 UTC, Mike Parker wrote: * establish support for fleshing out ideas before a DIP is even written It's 2024. That should have been the principle a decade ago Remember how the so called 'discussions' about the 'privateThis' concept always got heaped on. People just wanted to shut it down rather that discuss it. 'Go write a DIP' was the response...remember. The class vs module level of encapsulation was fleshed out a lot in the forums awhile back. I think it's fair to say most people where happy (or neutral) with the status quo, and were not convinced by the pro-class-level arguments. I also suspect those that did prefer class level private (I believe this is what Atila prefers), it's not high on their list of priorities. I like private as it is now. Especially because if anyone wants it to be "class-private", they can do that anyway: write a class per module like one has to in Java. My 2 centimes (cos I live in Switzerland) is that if you're worried about too much code having access to your private functions, your module is probably too large.
Re: reggae v0.10.0 - The meta build system just got better
On Tuesday, 26 September 2023 at 16:17:34 UTC, Andrey Zherikov wrote: On Thursday, 21 September 2023 at 15:59:10 UTC, Atila Neves wrote: ... I got your point. Why does it have multiple languages (front-ends)? Is there anyone willing to write build script for C++ on JavaScript or Ruby, for example? I thought that if I built it people would come, but nah. Also why is it meta build system? Because I think that's a superior design. For instance, all the start up time dub has to spend on every build disappears. Why can't it just build by itself without calling external tools (make, ninja)? It can: https://github.com/atilaneves/reggae/blob/master/bootstrap.sh
Re: reggae v0.10.0 - The meta build system just got better
On Thursday, 21 September 2023 at 13:38:30 UTC, Andrey Zherikov wrote: On Wednesday, 20 September 2023 at 21:19:22 UTC, Atila Neves wrote: Because we don't have one now. Using CMake for D is horrible, I would say just using CMake is horrible :-D But there are a lot of people using it (even myself) and they all are trapped with the language. Not anymore! ;) Have you looked as Meson, for example - it even has a [section about D](https://mesonbuild.com/D.html)? Yes, and even had to use it for D. I don't know what state it's in now, but it was pretty much unusable if one had dub dependencies which... is nearly always the case. I believe this is applicable to all build systems atm - they don't know what dub is and how to deal with it. Well, no, since reggae *does* know what dub is and uses it as a library. Then there's the language: I'd rather use D or Python. If anything, Meson's use case could be questioned just as well by "why another build language?". TBH I thought Meson uses python but just found out it's not. My bad. Just took a quick look at [known build tools](https://en.wikipedia.org/wiki/List_of_build_automation_software#Licensing_overview) and noticed that there are (at least) two build tools that have Python as a build language and support D: [SCons](https://en.wikipedia.org/wiki/SCons#Major_features) and [Waf](https://en.wikipedia.org/wiki/Waf_(build_system)#Features). Although I don't how well they support it. I'm aware of both and looked at them many, many, years ago. My whole comment was about the reasoning why we need new build system and can't improve existing one. dub, for starters, and the fact that `dub describe` doesn't work. Then there's building by D package, which isn't going to be easy anywhere else.
Re: reggae v0.10.0 - The meta build system just got better
On Thursday, 21 September 2023 at 14:19:27 UTC, jmh530 wrote: On Wednesday, 20 September 2023 at 21:19:22 UTC, Atila Neves wrote: On Wednesday, 20 September 2023 at 15:24:52 UTC, Andrey Zherikov wrote: On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves wrote: [...] Out of curiosity, why do we need one more build tool? Because we don't have one now. Using CMake for D is horrible, and none of the alternatives are that much better. Hand-written Makefiles are a nightmare and will never get dependencies right. dub isn't a build system, although it includes a very limited one that can't be extended. Want to build D and C++ [snip] You can call CMake with a pre-build command right? Would it make sense to add an example of that? Yes, and I've done that, but it's not great. I'm going to add CMake support to reggae by making CMake export its compilation DB and importing that. It also might make sense to include in the tests/projects folder an importC example (not sure it makes sense to include a CMake example there). That's a great idea, thanks!
Re: reggae v0.10.0 - The meta build system just got better
On Wednesday, 20 September 2023 at 15:24:52 UTC, Andrey Zherikov wrote: On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves wrote: https://code.dlang.org/packages/reggae For those who don't know, reggae is a meta-build system for and in D. It's like CMake, if you replace their terrible language with D*. Like CMake, it can output make and ninja files. Unlike CMake, it can also output tup files and has its own binary generator in case the dependency on one of those programs is undesired. Also unlike CMake, it supports dub projects out-of-the-box by using dub as a library. Out of curiosity, why do we need one more build tool? Because we don't have one now. Using CMake for D is horrible, and none of the alternatives are that much better. Hand-written Makefiles are a nightmare and will never get dependencies right. dub isn't a build system, although it includes a very limited one that can't be extended. Want to build D and C++ code in the same project? Hah, good luck. TBH I had the same thought - we should have "good" build tool for D that has D as a language. Since I have some experience with CMake and agree with a lot of people that it have horrible language, I thought it would be beneficial. But then I looked round and realized that it will be like this: In practice, this doesn't seem to happen with build systems. Instead each language ecosystem ends up using its own: CMake, Gradle, Rake, ... Have you looked as Meson, for example - it even has a [section about D](https://mesonbuild.com/D.html)? Yes, and even had to use it for D. I don't know what state it's in now, but it was pretty much unusable if one had dub dependencies which... is nearly always the case. Then there's the language: I'd rather use D or Python. If anything, Meson's use case could be questioned just as well by "why another build language?".
Re: reggae v0.10.0 - The meta build system just got better
On Tuesday, 12 September 2023 at 13:17:50 UTC, Adam D Ruppe wrote: On Tuesday, 12 September 2023 at 13:12:29 UTC, Atila Neves wrote: It does mean adding `-I` flags to every dependency though, so there's that. Not if you install them properly. That's the job of the package manager does that. An argument could be made that it could/should install the dependencies such that only one `-I` flag is needed. Even then, I'm not sure how it'd handle different versions of the same package unless it did something like what Ikey showed at DConf. And for larger codebases `dmd -i` can't and won't work. Define "larger". ~190k SLOC (not counting the many dub dependencies) killed dmd on a system with 64GB RAM + 64GB swap after over a minute. Even if it worked, it'd be much, much slower.
Re: reggae v0.10.0 - The meta build system just got better
On Monday, 11 September 2023 at 23:15:28 UTC, Adam D Ruppe wrote: I tried reggae today. It did not go well. http://dpldocs.info/this-week-in-d/Blog.Posted_2023_09_11.html#reggae-editorial One thing I learned from you is that for small projects `dmd -i` is just as fast as incremental compilation, which is rather surprising to me. It does mean adding `-I` flags to every dependency though, so there's that. And for larger codebases `dmd -i` can't and won't work.
Re: reggae v0.10.0 - The meta build system just got better
On Thursday, 7 September 2023 at 21:25:27 UTC, German Diago wrote: On Thursday, 7 September 2023 at 17:34:48 UTC, Atila Neves wrote: https://code.dlang.org/packages/reggae For those who don't know, reggae is a meta-build system for and in D. It's like CMake... How mature is the build system? FWIW, I would like to stay in Meson if I can, since I use C++ also and that makes combining libs and other niceties easier. Mature enough that we've been using it at work for years now, but YMMV depending on what you use it for. It also supports C++ BTW.
reggae v0.10.0 - The meta build system just got better
https://code.dlang.org/packages/reggae For those who don't know, reggae is a meta-build system for and in D. It's like CMake, if you replace their terrible language with D*. Like CMake, it can output make and ninja files. Unlike CMake, it can also output tup files and has its own binary generator in case the dependency on one of those programs is undesired. Also unlike CMake, it supports dub projects out-of-the-box by using dub as a library. TL;DR: you can use to build your dub project and it'll be faster and not rebuild the whole thing if you only change one module**. Highlights of this release: When dinosaurs roamed the Earth, `dmd -makedeps` didn't work so to automatically handle dependencies between D modules reggae had to wrap the compiler with a binary named `dcompile`. This would call the compiler with `-v`, get the imports from the output, and use them to only rebuild what was necessary. Now that `dmd -makedeps` got fixed, the extra complication (and time to build the extra binary) is gone. Default dub builds are much faster now. Before, reggae would create a reggaefile.d if one didn't exist for dub projects. I got tired of waiting for the compiler, and realised that I don't actually have to compile D code on-the-fly if I know ahead of time what the code is anyway. Now, reggae immediately*** spits out the build files for such projects. Automatically detect when new files are added/deleted: this is the main reason that the CMake devs erroneously advise people to not use "globs" to just "give me all the source files". The issue is when the file list changes, you need to remember to rerun the metabuild system to detect the filesystem changes. No more: reggae builds now rerun reggae when files are added or deleted. Tup, of course, has always done this but it's the only one I know of that did. Before, if the compiler binary changed, then... oops it was if you rebuilt in between updating your distro. Now the object files depend on the compiler binary. * Or Python, Ruby, Javascript, or Lua. ** Unless you made every module depend on every other module, in which case, don't do that. ** dub can be slow to start up. Slows for me is ~200ms.
Re: D Language Foundation March 2023 Monthly Meeting Summary
On Thursday, 13 April 2023 at 01:44:24 UTC, Walter Bright wrote: On 4/11/2023 7:35 PM, bachmeier wrote: [...] It's a seductive idea, and I've considered that (and variations on it) many times. We have done this, after a fashion, in having our own versions of the .h files in the form of the D translations in core.stdc.* import files. [...] I've now lost count of how many times changes in the Python headers break code using it. The only way to consume headers is to parse/translate/etc. them on the fly.
Re: D Language Foundation Quarterly Meeting, October 2021
On Saturday, 6 November 2021 at 15:46:57 UTC, JN wrote: On Friday, 5 November 2021 at 13:19:24 UTC, zjh wrote: D can aim at `experts`, especially `meta programming users`. On this point,`rust` can't compete. `Silky general meta programming`. Use my `strengths` to attack theirs weaknesses. This is much less of a strength than you think. For 90% of cases, lack of metaprogramming is resolved by putting a Python script in build step that autogenerates the necessary code. Python has no idea about D syntax or semantics (or any other language not called Python), and therefore can't even do something as simple as "what are all the D structs in module x". You'd have to invent a templating language on top of the code you're already writing, then write some Python code to parse and generate on top of *that*. To me, that's like saying that C/Fortran aren't that big of a deal compared to assembly. Who needs for loops, amirite?
Re: Symmetry looking for D programmers in Singapore/Hong Kong/Australia/New Zealand
On Wednesday, 16 June 2021 at 15:48:07 UTC, Vladimir Panteleev wrote: On Wednesday, 16 June 2021 at 14:40:05 UTC, Atila Neves wrote: Interested? Please send a CV to dot name> at Replying for the benefit of forum.dlang.org users, for whom the tags were not visible due to Markdown. Also, what about remote? I did wonder what the warning was about when I posted and didn't even know it was markup to begin with... oops.
Symmetry looking for D programmers in Singapore/Hong Kong/Australia/New Zealand
Interested? Please send a CV to dot name> at
Re: Symmetry Investments and the D Language Foundation are Hiring
On Thursday, 14 January 2021 at 14:23:28 UTC, Dukc wrote: On Thursday, 14 January 2021 at 13:24:55 UTC, Atila Neves wrote: https://forum.dlang.org/post/wdsgkozpnhegqkcwe...@forum.dlang.org On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg wrote: BTW, is timestamps vs SHA-1 hashing really the most pressing issue with Dub? Not really, no. You just made a new announcement theard with that reply. Intentional? Nope. No idea what happened there.
Symmetry Investments and the D Language Foundation are Hiring
https://forum.dlang.org/post/wdsgkozpnhegqkcwe...@forum.dlang.org On Tuesday, 1 September 2020 at 09:09:36 UTC, Jacob Carlborg wrote: On Sunday, 30 August 2020 at 14:13:36 UTC, Mike Parker wrote: Looking for a full-time or part-time gig? Not only is Symmetry Investments hiring D programmers, they are also generously funding two positions for ecosystem work under the D Language Foundation. And they've put up a bounty for a new DUB feature. Read all about it here: https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/ As an alternative to use SHA-1 hashing. There's the option to have a daemon running the background listing on filesystem events. BTW, is timestamps vs SHA-1 hashing really the most pressing issue with Dub? Not really, no.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Wednesday, 13 January 2021 at 15:31:33 UTC, Nick Treleaven wrote: On Wednesday, 13 January 2021 at 14:48:07 UTC, Atila Neves wrote: Why do they have to scroll to the top? They don't, you're right. But if you want to use it throughout the module you need a top-level import, by convention at the top. Also the convention seems to be to put a local import at the start of a scope rather than sandwiched in the middle of statements. Yes. 1. Save point 2. Jump to start of function 3. Write local import 4. Jump back More work than not having to do anything, obviously, but still.
Re: Discussion Thread: DIP 1039--Static Arrays with Inferred Length--Community Review Round 1
On Monday, 11 January 2021 at 12:32:42 UTC, Nick Treleaven wrote: On Friday, 8 January 2021 at 14:07:29 UTC, Luhrel wrote: Example a3 is straightforward the primary use case for staticArray: auto a3 = [1,2,3].staticArray; I really don't like the `.staticArray` because it's non-esthetic. I don't know if it's really argument, mainly because it's very personal. The worst thing about it is you have to import std.array, so probably people won't bother scrolling to the top to add the import and losing/bookmarking their place, Why do they have to scroll to the top? Even if they did, what editor are they using that they can't jump back to where they were?
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 01:19:12 UTC, jmh530 wrote: On Sunday, 3 January 2021 at 20:31:41 UTC, welkam wrote: [snip] [snip[ Regardless, the DIP likely could have been improved by mentioning its inclusion in C++ 11 (and perhaps focused a bit less on implementation). Yes.
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 4 January 2021 at 15:42:05 UTC, Ola Fosheim Grøstad wrote: On Monday, 4 January 2021 at 15:25:13 UTC, Atila Neves wrote: On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim Grøstad wrote: 1. acknowledgment of the issue 2. acknowledgment of what the issue leads to in terms of inconvenience 3. a forward looking vision for future improvements Your two #1 points aren't the same - understanding/acknowledging the issue. I think I could have done more to acknowledge it now that you brought it up. In this case, maybe #1 and #2 are the same. But sometimes people will complain about the "inconvenience" and not drill it down to the real cause in terms of language-mechanics. A valid response could be "I will look and see if I can find the source of this problem, but I totally see the inconvenience you are experiencing. We will look at this more closely when planning for release X.Y.Z where we do an overhaul of subsystem Q.". I don't think a process oriented response has to be more concrete than that? I wasn't a process-oriented answer, nor do I think it should have been. The PR was a change to the compiler with an accompanying DIP. I'm a fan of giving an opinion early to save everyone a lot of work and bother.
Re: Printing shortest decimal form of floating point number with Mir
On Tuesday, 29 December 2020 at 19:59:56 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 29 December 2020 at 16:14:59 UTC, Atila Neves wrote: [...] I am not speaking for Ilya, but from skimming through the dialogue it struck me that you didn't respond from the perspective of managing the process, but from a pure engineer mindset of providing alternatives. It would've been better if you started by 1. understanding the issue 2. acknowledging that the type system has an obvious bug 3. looking at the issue from the perspective of the person bringing attention to the issue. I don't think anyone was looking for workarounds, but looking for 1. acknowledgment of the issue 2. acknowledgment of what the issue leads to in terms of inconvenience 3. a forward looking vision for future improvements Your two #1 points aren't the same - understanding/acknowledging the issue. I think I could have done more to acknowledge it now that you brought it up.
Re: Printing shortest decimal form of floating point number with Mir
On Thursday, 24 December 2020 at 14:14:33 UTC, 9il wrote: On Thursday, 24 December 2020 at 14:08:32 UTC, welkam wrote: On Wednesday, 23 December 2020 at 18:05:40 UTC, 9il wrote: It was a mockery executed by Atila Read the all comments and didnt saw any mockery Yes, it wasn't explicit. He didn't write bad words, he did a bad decision. Bad for D. I apologise if what I wrote came across as mockery; it certainly wasn't intended that way. How would you have liked for me to have handled it better?
Re: Truly algebraic Variant and Nullable
On Tuesday, 22 December 2020 at 04:09:59 UTC, 9il wrote: On Sunday, 20 December 2020 at 12:32:35 UTC, Petar Kirov [ZombineDev] wrote: How does your work compare to sumtype? Would mir.algebraic offer any benefits, which would make it worth switching over? replied at https://forum.dlang.org/post/zlphfxktclgdookqt...@forum.dlang.org If we can work together to consolidate on a single API, I think it would be better for the language ecosystem. Agreed. On the other hand, my public association with a DIP would be a red flag and will increase the chance the DIP would be declined. Cooperation is better to make silently. What makes you think that?
Re: Blog Post: What Does Memory Safety Really Mean in D?
On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote: https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html What exactly do we mean when we talk about "memory safety" in D? Is it the same thing as "undefined behavior"? Is it ever correct to mark and `extern(C)` function as `@trusted`? This post is my attempt to understand, and answer, questions like these. If you think I've gotten anything wrong, please leave a reply--this is definitely an area where I'm still learning. Nice, thanks for the write-up. I've been owing the D community a blog post on memory safety for a few months now. I started writing it, then DIP1028 happened and I wanted to wait for a while to bring it up again.
Re: Mocking framework mockeD
On Wednesday, 29 July 2020 at 09:49:36 UTC, Martin Tschierschke wrote: On Wednesday, 29 July 2020 at 08:25:34 UTC, Eugene Wissner wrote: I'm happy to announce a new mocking library developed at Funkwerk. [...] https://github.com/funkwerk/mocked By searching for the exact definition of Mocking Framework I found the Wikipedia Page for it, so you might want to add your framework there, too: https://de.wikipedia.org/wiki/Mocking_Framework Beside the frameworks for the other languages. Actually I am searching for the best way to make unit tests for a small program, reading values from a pdf converted to txt and than writing them into mysql. So I might just use your work. Thank you. Best regards mt. See also: https://github.com/atilaneves/unit-threaded#mocking
Re: Talk by Herb Sutter: Bridge to NewThingia
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu wrote: How to answer "why will yours succeed, when X, Y, and Z have failed?" https://www.youtube.com/watch?v=wIHfaH9Kffs Very insightful talk. Great talk. Similar to what I was trying to say in my DConf19 talk but in many ways better.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Wednesday, 17 June 2020 at 16:01:29 UTC, Paul Backus wrote:
On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote:
With a few changes, yes (added missing semicolons, changed
IGeometry to Geometry in `measure`, passed the current module
so tardy can find the UFCS functions, added `@safe pure` to
the UFCS functions:
[...]
void main() {
auto r = Rect(3.0, 4.0);
auto c = Circle(5.0);
Geometry.create!__MODULE__(r).measure;
Geometry.create!__MODULE__(c).measure;
}
IMO this can be done more elegantly by separating out the code
that looks up methods in the current module from the code that
does the actual type erasure.
A while ago, I collaborated briefly with Adam Kowalski from the
Dlang discord server on some code to emulate C++-style
argument-dependent lookup in D. Using that code, your example
above would be written:
Geometry.create(r.extended).measure;
Geometry.create(c.extended).measure;
Interesting.
The issue I see here is you might not be able to control which
module has the extension methods. I guess you could alias them in
the module you want to use but that seems clumsy.
In any case, this is trivial:
template extended(string mod = __MODULE__) {
auto extended(A...)(auto ref A args) {
return create!mod(args);
}
}
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Wednesday, 17 June 2020 at 11:31:09 UTC, jmh530 wrote: On Wednesday, 17 June 2020 at 10:04:59 UTC, Atila Neves wrote: [...] Cool. [...] If I'm understanding you correctly, you could modify Polymorphic (and a similar change to VirtualTable) to struct Polymorphic(Interface, InstanceAllocator = DefaultAllocator) if(is(Interface == interface) || is(Interface == class) || is(Interface == struct)) and the current functionality would still work. However, compared to normal inheritance, it would be missing the "base" class's member variables that don't exist in the "derived" one. You also couldn't call the "base" class member functions. Polymorphic is assuming the member functions are all implemented in the instance passed to it, correct? I think these questions are good motivators for making it interface-only since then I don't have to check for data definitions.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Wednesday, 17 June 2020 at 10:43:35 UTC, Stanislav Blinov wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: Tardy lets users have their cake and eat it too by not making them have to use classes for runtime polymorphism. I've got to ask though. Why "tardy"? Search engines be damned? :) Late binding ;)
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 15:50:07 UTC, jmh530 wrote: On Tuesday, 16 June 2020 at 13:31:49 UTC, Atila Neves wrote: [snip] Pretty cool, thanks for the fixups. It may make for a good documentation example, in that it may help make clear that you need to pass the module in somehow when dealing with non-member functions (AFAICT). You could include a comment about how it would be different if it were split into separate files. Good point. In your original example, is there any issue if we then make transform a templated non-member function that is generic over types like Adder (maybe there is an enum hasAddableMember that is true for Adder and false for Plus1)? I was going to say "it should work" but instead I wrote the code and... it does. It all falls out of how UFCS works and usual language rules. https://github.com/atilaneves/tardy/blob/feb26282608081098134c8846be87d398772ccb0/tests/ut/polymorphic.d#L102 https://github.com/atilaneves/tardy/blob/feb26282608081098134c8846be87d398772ccb0/tests/modules/ufcs/template_.d Am I right that the shared static constructor in vtable means that there is one vtable for all the instances? All instances of the same concrete type share the same vtable pointer, yes. Originally I built the vtable on the spot with `new` and assigned to each function pointer but then I realised that was a waste of time and allocations - the vtable is unique per concrete type. Are there any technical issues preventing Polymorphism from accepting a class in addition to an interface? None. It could even accept a struct, really.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 12:30:24 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 11:31:14 UTC, Atila Neves wrote:
On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote:
On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote:
[snip]
In the more longer-term, is the goal of the project to
implement a Typescript / Go interfaces like structural type
system in user space?
Yes. Other than allowing multiple interfaces, I think it's
already implemented.
I'm not familiar with what Typescript does, but doesn't Go
allow interfaces to be implemented by free-standing functions?
So does tardy.
Sorry, I had not realized that. I took Go's interface example
and converted it to D. Would this work with tardy?
With a few changes, yes (added missing semicolons, changed
IGeometry to Geometry in `measure`, passed the current module so
tardy can find the UFCS functions, added `@safe pure` to the UFCS
functions:
import tardy;
interface IGeometry
{
double area() @safe pure const;
double perim() @safe pure const;
}
alias Geometry = Polymorphic!IGeometry;
struct Rect {
double width, height;
}
struct Circle {
double radius;
}
double area(Rect r) @safe pure {
return r.width * r.height;
}
double perim(Rect r) @safe pure {
return 2 * r.width + 2 * r.height;
}
double area(Circle c) @safe pure {
import std.math: PI;
return PI * c.radius * c.radius;
}
double perim(Circle c) @safe pure {
import std.math: PI;
return 2 * PI * c.radius;
}
void measure(Geometry g) {
import std.stdio: writeln;
writeln(g);
writeln(g.area);
writeln(g.perim);
}
void main() {
auto r = Rect(3.0, 4.0);
auto c = Circle(5.0);
Geometry.create!__MODULE__(r).measure;
Geometry.create!__MODULE__(c).measure;
}
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 11:24:05 UTC, jmh530 wrote: On Tuesday, 16 June 2020 at 09:15:10 UTC, Atila Neves wrote: [snip] In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space? Yes. Other than allowing multiple interfaces, I think it's already implemented. I'm not familiar with what Typescript does, but doesn't Go allow interfaces to be implemented by free-standing functions? So does tardy. That is a little bit more similar to open methods. This requires the type inherit from the interface and implement member functions. There is no inheritance anywhere, otherwise that'd defeat the point of the library in the first place. I used interfaces because they exist and intuively make sense, and support classes because why not. Otherwise it could be just structs and other values with candidate UFCS functions. I'm not that knowledgeable of Boost, but I see some similarities with Boost's type_erasure library. However, one main difference is that it is implemented with concepts, rather than the equivalent of interfaces. I would guess using interfaces has some benefits in terms of implementation since you know exactly what functions need to be called. Something like @models is very flexible, but that might be a downside. Using an interface means using familiar syntax with the added benefits of being able to write a signature like this: int* fun(int*, int) @safe @nogc pure return scope const; And then have all of those attributes and `this` modifiers used in the vtable function pointer declarations. Overloading and UFCS get dealt with naturally by usual language rules.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Tuesday, 16 June 2020 at 03:56:52 UTC, Petar Kirov [ZombineDev] wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy Looks interesting, nice work! How does it compare to: https://dlang.org/phobos/std_experimental_typecons#.wrap ? For starters, that uses a class and inheritance internally and therefore has all the drawbacks of that approach as laid out in tardy's README.md. Then there's the lack of allocator support. In the more longer-term, is the goal of the project to implement a Typescript / Go interfaces like structural type system in user space? Yes. Other than allowing multiple interfaces, I think it's already implemented. Also how would it compare to Rust traits? Rust's traits are usually used like D's template contraints and Haskell's type classes. The only way they're relevant here are trait objects: https://doc.rust-lang.org/reference/types/trait-object.html The main difference is that tardy is supposed to give the user choices over how the dispatch is actually implemented. Allocators alone are huge. I guess the main difference, would be that Rust enforces a nominal type system like approach, where 2 differently named traits that otherwise define the same interface are not considered interchangeable. Yes, that's also a difference.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Monday, 15 June 2020 at 20:47:16 UTC, 12345swordy wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy [...] Wouldn't a top type be a better way to achieve this? -Alex How?
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Saturday, 13 June 2020 at 18:39:14 UTC, Paul Backus wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy Cool stuff! What's the reasoning behind implementing your own vtables instead of using D's built-in object system? Don't want to be stuck inheriting from Object? That's one reason, but even more importantly this gives the implementation more freedom and potentially more options for client code. I haven't added it yet (mostly due to laziness) but I considered compile-time policies to inline the vtable in the object, or to determine ordering of the vtable and the implementation (might have performance considerations), and a few other things. Also: more fun to implement, and shows that it can be done as a library.
Re: tardy v0.0.1 - Runtime polymorphism without inheritance
On Saturday, 13 June 2020 at 16:15:49 UTC, jmh530 wrote: On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote: https://code.dlang.org/packages/tardy https://github.com/atilaneves/tardy [snip] This is pretty cool. Thanks for sharing. I have a few questions/comments: 1) It might make a good blog post at some point to discuss this and the performance (perhaps with reference to the earlier open methods blog post). I actually need to benchmark it though! 2) It looks like Polymorphic can only take one interface. Would you consider adding the ability to have more than one? I suppose a work-around would be to combine all the interfaces you would want to use into a new interface before combining. I... completely forgot about that, thanks for bringing it up. 3) Do arrays work, as in Transformer(Adder(2), Plus1()) or [Transformer(Adder(2)), Transformer(Plus1())] Yep: https://github.com/atilaneves/tardy/blob/d5f1102a6a791e77e0a27ee1a7920166fba8fcc8/tests/ut/polymorphic.d#L222
tardy v0.0.1 - Runtime polymorphism without inheritance
https://code.dlang.org/packages/tardy
https://github.com/atilaneves/tardy
Tardy lets users have their cake and eat it too by not making
them have to use classes for runtime polymorphism. No inheritance
anywhere to be found, which means structs, ints, and arrays can
be used with dynamic dispatch (classes as well). It uses the GC
by default but users can specify their own allocator type for
flexibility, including a built-in "small buffer optimisation"
allocator. Sample usage code:
import tardy;
interface ITransformer {
int transform(int) @safe pure const;
}
alias Transformer = Polymorphic!ITransformer;
int xform(Transformer t) {
return t.transform(3);
}
struct Adder {
int i;
int transform(int j) @safe pure const { return i + j; }
}
struct Plus1 {
int transform(int i) @safe pure const { return i + 1; }
}
unittest {
assert(xform(Transformer(Adder(2))) == 5);
assert(xform(Transformer(Adder(3))) == 6);
assert(xform(Transformer(Plus1())) == 4);
}
Re: unit-threaded v1.0.0
On Monday, 1 June 2020 at 09:03:20 UTC, ag0aep6g wrote:
On 01.06.20 10:49, Atila Neves wrote:
That got fixed a few weeks back - your code doesn't compile
for me.
Huh. Maybe you forgot to commit that? I'm just running this
through `dub --single test.d`:
/+ dub.json:
{
"dependencies": {
"unit-threaded": "~>1.0.0",
},
}
+/
import unit_threaded.light: check;
void main() @safe
{
check!((int a) @system {
/* ... can do unsafe stuff here ... */
return true;
});
}
https://run.dlang.io/is/NbiYBB
I missed that you imported `unit_threaded.light`. Thanks for
reporting! That whole module needs to be redone.
Re: unit-threaded v1.0.0
On Thursday, 28 May 2020 at 19:01:22 UTC, jmh530 wrote: On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote: [snip] This last is sad, for me. I like using test functions rather than named unittest blocks. I recall playing with them when it was originally announced and thought they were quite nice, but I haven't used them since. The unit-threaded library certainly seems chocked full of features. Some of them overlap with the fluent-asserts library. It may make sense to split off some of that stuff as well so that people can evaluate custom assert libraries on their own merits. Similarly, the mocking and integration stuff could probably (?) be split off into separate packages. This would imply unit-threaded could be focused on the runner subpackage. The assertions are their own subpackage, as is the runner, and mocking, and integration.
Re: unit-threaded v1.0.0
On Friday, 29 May 2020 at 14:20:53 UTC, ag0aep6g wrote:
On 28.05.20 17:35, Atila Neves wrote:
https://code.dlang.org/packages/unit-threaded
You got a bad @trusted:
import unit_threaded.light: check;
void main() @safe
{
check!((int a) @system {
/* ... can do unsafe stuff here ... */
return true;
});
}
I searched for "trusted" and that was the first hit. I didn't
look further. There's probably more.
That got fixed a few weeks back - your code doesn't compile for
me.
Re: unit-threaded v1.0.0
On Thursday, 28 May 2020 at 17:45:26 UTC, Russel Winder wrote:
On Thu, 2020-05-28 at 15:35 +, Atila Neves via
Digitalmars-d-announce wrote:
I decided to stop being like Google and finally tag version 1
of unit-threaded:
https://code.dlang.org/packages/unit-threaded
From now on I'm going to focus on compilation speed (no matter
how ugly that might make the implementation), and also dropping
support in v2.x.x for anything other than unittest blocks (bye
bye test classes and functions).
This last is sad, for me. I like using test functions rather
than named unittest blocks.
Out of curiosity, what is the difference for you between:
testFoo() { /* ... */ }
and:
@("foo")
unittest { /* ... */ }
unit-threaded v1.0.0
I decided to stop being like Google and finally tag version 1 of unit-threaded: https://code.dlang.org/packages/unit-threaded From now on I'm going to focus on compilation speed (no matter how ugly that might make the implementation), and also dropping support in v2.x.x for anything other than unittest blocks (bye bye test classes and functions).
Re: Rationale for accepting DIP 1028 as is
On Tuesday, 26 May 2020 at 16:10:24 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:54:31 UTC, Bastiaan Veelo wrote: On Tuesday, 26 May 2020 at 15:39:11 UTC, Bruce Carneal wrote: On Tuesday, 26 May 2020 at 15:01:06 UTC, Bastiaan Veelo wrote: @safe: the compiler checks The compiler does not and cannot check inside @trusted. Whether or not one requires extern(C[++]) to be behind or within @trusted does not change what the compiler can or cannot check.j Completely agree but my above says nothing about @trusted. @safe post 1028: the compiler checks, sometimes, just not in the scary parts The amount of code that requires human auditing remains the same. What matters is how to find that code, and how to maintain the validity of the audits. Another distinction: pre 1028 your compilation will error out. Post 1028 it will not. Quite the opposite. Most code out there isn't marked as @safe/@trusted/@system. If I add a dub dependency and don't bother with @safe, I can call anything, in any way. Post 1028... nope. Unmarked @system function definitions themselves won't compile.
Re: DIP1028 - Rationale for accepting as is
On Tuesday, 26 May 2020 at 12:28:06 UTC, NaN wrote: On Tuesday, 26 May 2020 at 06:55:31 UTC, Petar Kirov [ZombineDev] wrote: [...] If the greenwashing part was separated and delayed it would give time to find out if Walters hypothesis about people just doing it themselves is true. -preview=safe now -revert=safe "tomorrow"
Re: DIP1028 - Rationale for accepting as is
On Monday, 25 May 2020 at 17:01:24 UTC, Panke wrote: On Monday, 25 May 2020 at 16:29:24 UTC, Atila Neves wrote: A few years ago I submitted several PRs to Phobos to mark all unittests that could with @safe explicitly. I'd say that was a good example of nobody reviewing them for their @systemness. Ideally you should be able to blindly mark every function definition with @safe, because the compiler will catch you if you fall. Only if you type @trusted you should need to be careful. Doesn't work for templated functions since their @safety might depend on the the particular instantiation (consider std.algorithm.map).
Re: DIP1028 - Rationale for accepting as is
On Sunday, 24 May 2020 at 16:44:01 UTC, Paul Backus wrote: On Sunday, 24 May 2020 at 03:28:25 UTC, Walter Bright wrote: I'd like to emphasize: 1. It is not possible for the compiler to check any declarations where the implementation is not available. Not in D, not in any language. Declaring a declaration safe does not make it safe. 2. If un-annotated declarations cause a compile time error, it is highly likely the programmer will resort to "greenwashing" - just slapping @safe on it. I've greenwashed code. Atila has. Bruce Eckel has. We've all done it. Sometimes even for good reasons. 3. Un-annotated declarations are easily detectable in a code review. [...] If we were designing a new language from scratch, I would agree 100% with your reasoning. The problem is that there are un-annotated declarations in existing code that have already been reviewed, committed, and published under the assumption of @system-by-default. Those declarations need to be flagged for re-review in order to avoid introducing silent safety violations to existing D projects. I share your concerns on this, but disagree on the likelihood of reviews having gone by under the assumption of @system by default. I doubt most people even thought about @safe/@trusted/@system, and that's assuming anyone reviewed the code in the first place. A few years ago I submitted several PRs to Phobos to mark all unittests that could with @safe explicitly. I'd say that was a good example of nobody reviewing them for their @systemness.
Re: DIP1028 - Rationale for accepting as is
On Saturday, 23 May 2020 at 10:55:40 UTC, Dukc wrote: The more I think of Atila's and Walter's responses, the more they are starting to make sense. [...] Thank you for the anecdote, especially since it captures the spirit of what I've been trying to convey here.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 20:08:37 UTC, Dukc wrote:
On Friday, 22 May 2020 at 18:27:42 UTC, Atila Neves wrote:
Sorry, I didn't express myself well. I meant that the user can
still mark functions as @system, they just have to do it
explicitly.
Hm, DPP might be of help here. Becuse I quess you are going to
make sure it'll mark everything `@system`?
My plan is probably to do that, yes. I've been thinking about it
and I'll likely need to give users options to opt-in to declaring
functions @safe, otherwise none of them every would be with this:
@system {
#include "header.h"
}
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 18:17:29 UTC, ag0aep6g wrote: On 22.05.20 19:54, Atila Neves wrote: We care. Annotations become explicit. Do I think this is ideal? No. "Annotations become explicit." - What now? I probably misunderstand that sentence, but DIP 1028 does not require explicit annotations. That's why everyone is upset. Sorry, I didn't express myself well. I meant that the user can still mark functions as @system, they just have to do it explicitly.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 18:11:28 UTC, ag0aep6g wrote:
So the DIP itself wasn't good enough to convince you.
Had that been the case, I would have rejected it.
Your reasoning is fine when you're dealing with a function that
has a safe interface. I.e., it can only corrupt your code when
it's buggy. Then it makes sense so say "I trust the authors". D
users do it with Phobos. Phobos authors do it with the C
standard library. This kind of trust is perfectly ok.
Your reasoning is completely wrong when you're thinking about a
function that doesn't have a safe interface. E.g., C's `memcpy`
just isn't safe.
memcpy isn't a good example since it's explicitly @system:
https://dlang.org/phobos/core_stdc_string.html#.memcpy
It doesn't matter whether you trust the authors or not. The
user has to make sure that the call is correct. Otherwise,
`memcpy` will corrupt your memory. And `memcpy` is far from the
only such function.
Yes. But most of them aren't like memcpy. Most D code calls other
D code, not C.
Am I saying nothing bad can happen if we implicitly trust
extern(C) declarations? No. I'm saying we'll be no worse off if
they're all implicitly @system.
This compiles with no warnings right *now*:
void main() {
import core.stdc.stdlib: free;
free(cast(void*) 42);
free(new int);
free();
}
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 17:41:38 UTC, Steven Schveighoffer wrote: On 5/22/20 1:07 PM, Atila Neves wrote: And so I was convinced that everything being @safe is actually ok, especially because in real life, most C/C++ APIs aren't going to secretly corrupt your code. Yes, it can, but not secretly. Just obviously and easily. Note this function: https://github.com/atilaneves/libclang/blob/5415707fa6072700bdbf21f827567ffa2fd5c424/source/clang/c/index.d#L861 And so, you are free to pepper your @safe code with dangling pointers. Sure, you can claim that the C++ library didn't "corrupt your code", which is the case for ALL libraries if you use them properly. You did it, you created a dangling pointer, not the library. Right. And the point I was trying to make wasn't "look at what I did, it's cool". No, what I did was dumb. So dumb it took you no time at all to point out one of my mistakes. My point is that the result of making declarations implicity @system instead of @safe would make people just slap @safe on them without really thinking about it to get their code to compile. Like I did. The point of @safe is to protect you from corrupting your own code based on the guarantees that @safe provides. I agree. If we don't care about the guarantees of @safe as long as you are using C libraries, why are we bothering at all with any of this? We care. Annotations become explicit. Do I think this is ideal? No. BTW, you should fix that invalid attribute, freeing a pointer is never @safe unless you can guarantee nobody else has a copy of that pointer (and considering it's passed by value, the CALLER still has that pointer!) You're completely right.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 17:33:11 UTC, rikki cattermole wrote: On 23/05/2020 5:07 AM, Atila Neves wrote: [...] It is not about the linkage. The problem is solely does the compiler have the source to the function body to verify it? That's what I meant, sorry for not making it clearer. [...] That is a failure of the language that should be resolved. And how do you suggest we fix it? One of the arguments that has been brought up (although I don't remember if it made its way to the N.G.) is that if you don't have the body, can a function /even/ be @safe? Yes. [...] You might, but that doesn't give the compiler the right to do so by default. This a decision for a skilled programmer to make. They still can (and should). The DIP is about changing the default. [...] No. We simply do not agree, nor do I expect for us to come to terms on it anytime soon. I meant "did I explain myself well enough that now you understand where I'm coming from, even though you might not ultimately agree?".
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 14:37:04 UTC, bachmeier wrote: On Friday, 22 May 2020 at 13:57:27 UTC, Mike Parker wrote: [...] I think the source of the problem is that Walter's DIPs require the community to prove that Walter's proposal is so bad that he needs to reject it. Anyone else's proposal has to prove that it's worthy of being added to the language. There's a big perceived gap between those two. As I've said many times, it's odd for someone to judge his own DIPs, and as someone that is an academic administrator and runs a high-profile journal, I can say this type of practice is not the norm in those areas because it doesn't lead to good decisions. I could have rejected it, and nearly did.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 14:13:20 UTC, Paul Backus wrote: On Friday, 22 May 2020 at 13:58:14 UTC, bachmeier wrote: On Friday, 22 May 2020 at 03:36:03 UTC, Paul Backus wrote: This is the nightmare scenario that people are worried about: safety violations being introduced *silently* into existing, correct D code. Honest question: What is the use case for an absolutely-positively-has-to-be-safe program that calls C code? Why would anyone ever do that? C is not and will never be a safe language. "Someone looked at that blob of horrendous C code and thinks it's safe" does not inspire confidence. Why not rewrite the code in D (or Rust or Haskell or whatever) if safety is that critical? The problem isn't that safety is critical, it's that the D compiler is lying to me about the safety of my code. I understand your argument, especially since I wrote nearly identical words weeks ago. For me, what it boils down to is this: currently the compiler isn't doing what it could because of the @system default. I work on a D codebase that can't be called from a @safe unittest and we could (probably are) be hiding bugs due to this. Flipping the default will cause more incorrect code to fail to compile. Yes, there's a cost, which is carefully vetting extern(C) and extern(C++) declarations. The decision came down to finding this an acceptable trade-off.
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote: On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote: With the rationale laid out clearly as it is here, I do have some responses in mind. But before sharing them, I'd like to know whether that would be useful right now: I've no wish to just press for a re-hashing of conversations that have already been had. No. This wasn't the first and certainly won't be the last time we as a community have been very unhappy with how Walter conducts himself with his DIP's. Although it seems an improvement has been made to how he needs to respond to the DIP assessment. It should also include a statement from Atila as well given his position. I'm going through posts in order, so apologies if I'm "ignoring" something that shows up later in the discussion. Personally and initially, I would have preferred it if non-extern(D) declarations were implicitly @system. I understood Walter's argument about special cases and how they're bad, but the thought of them being @safe made me feel, for lack of a better word, "icky". Then I talked to Walter and he pointed out that if those declarations were @system, users would be prevented from calling them from now @safe code. A regular user would probably just slap `@safe:` at the top of the bindings module anyway. Then I realised that I did exactly that with my libclang bindings: https://github.com/atilaneves/libclang/blob/5415707fa6072700bdbf21f827567ffa2fd5c424/source/clang/c/index.d#L254 "Worse", I made all functions `pure` and all parameters `in` as well for good measure. Why? I wanted to call them from my @safe pure code with `const` arguments. My reasoning at the time was "I trust libclang". And so I was convinced that everything being @safe is actually ok, especially because in real life, most C/C++ APIs aren't going to secretly corrupt your code. Then there's the fact that, today, there's no safety anyway calling anything because everything is @system by default. And D source code won't be able to lie. Does that clear it up?
Re: DIP1028 - Rationale for accepting as is
On Friday, 22 May 2020 at 03:57:22 UTC, H. S. Teoh wrote: On Thu, May 21, 2020 at 06:22:19PM -0700, Walter Bright via Digitalmars-d-announce wrote: I have made these points before, but I'll summarize them here for convenient referral. [...] Thank you. This makes your position clear, even if I don't entirely agree with it. On that note, though: this really should have been part of the DIP acceptance announcement, not added as an afterthought. Otherwise people will perceive (correctly or not) the DIP as being accepted without acknowledging any of the issues raised. This summary is exactly what would have defused a lot of the frustrations raised here. For the future may I recommend making it a point to include such a summary with the announcement of each DIP accepted/rejected. T This is a very good point, and I think that in the future Walter and I should attach an explanation of why a DIP got accepted or not for transparency and communication reasons.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On Thursday, 21 May 2020 at 23:49:22 UTC, Bruce Carneal wrote: On Thursday, 21 May 2020 at 16:32:32 UTC, Adam D. Ruppe wrote: On Thursday, 21 May 2020 at 16:14:02 UTC, Seb wrote: [...] ditto, I think we should have like a seven person elected DIP committee who pass/fail things by majority vote. It is obvious to me that the current process is totally useless. As noted earlier, I'm with Steve, Seb, Adam, and "everyone but Walter" as far as I can see. If this stands we'll have gone from @safe meaning "the compiler is responsible" to "the compiler can't guarantee anything unless you're pure D all the way down". Atila, what's your take on all this? Is it fork time? No.
Re: DConf 2020 Canceled
On Monday, 16 March 2020 at 19:36:20 UTC, Walter Bright wrote: On 3/16/2020 9:15 AM, bachmeier wrote: "Have an online conference" isn't especially helpful. There haven't been any detailed proposals, and Walter hasn't said anything one way or the other about doing something online. Oh, I'm quite in favor of an online conference. Anyone who wants to step up and take charge of it has my support. Same here.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 20:00:52 UTC, H. S. Teoh wrote: On Thu, Feb 27, 2020 at 11:26:37AM -0800, Walter Bright via Digitalmars-d-announce wrote: [...] [...] [...] For all the trouble they've given us, built-in AA's is one of the primary reasons I love D. [...] The reason for C++ forcing users to do that is the lack of compile-time reflection.
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 20:57:53 UTC, H. S. Teoh wrote: On Wed, Feb 26, 2020 at 08:45:31PM +, Atila Neves via Digitalmars-d-announce wrote: On Wednesday, 26 February 2020 at 17:39:14 UTC, jmh530 wrote: > On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves > wrote: > > [snip] > > > > A lot of the comments were about how stupid I was for not > > just using ctypes or cffi. I tried today and both of them > > are horrible. As I say in the blog post below, either they > > didn't read the article (people on the internet commenting > > on things they didn't even read? Shock! Horror!) or just > > aren't lazy enough. > > > > My followup: > > > > https://atilaoncode.blog/2020/02/26/seriously-just-use-d-to-call-c-from-python/ > > I basically just ignored any of the comments about ctypes or > cffi having looked at them briefly once like 5-10 years ago > and throwing up my hands. But I also throw up my hands a lot! I didn't know anything about them last week, so I didn't think I could reply properly. After looking into them today I just shook my head a lot. It's incredible the lengths that people go to justifying their pre-existing beliefs. At this point, I don't know how to convince the masses if "nanomsg in Python in 4 lines of code" isn't enough! Perhaps a side-by-side comparison of how clean the D version would look vs how lousy the equivalent ctypes/cffi version is? Just a thought. That was exactly what I was going to do yesterday with cffi and I even started writing the code. Midway through I realised how much work it was going to be and decided that ain't nobody got time for that. Then shook my head vigorously that anyone would dare suggest this was "easy" and in any way comparable to what I'd shown to be possible.
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 17:39:14 UTC, jmh530 wrote: On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves wrote: [snip] A lot of the comments were about how stupid I was for not just using ctypes or cffi. I tried today and both of them are horrible. As I say in the blog post below, either they didn't read the article (people on the internet commenting on things they didn't even read? Shock! Horror!) or just aren't lazy enough. My followup: https://atilaoncode.blog/2020/02/26/seriously-just-use-d-to-call-c-from-python/ I basically just ignored any of the comments about ctypes or cffi having looked at them briefly once like 5-10 years ago and throwing up my hands. But I also throw up my hands a lot! I didn't know anything about them last week, so I didn't think I could reply properly. After looking into them today I just shook my head a lot. It's incredible the lengths that people go to justifying their pre-existing beliefs. At this point, I don't know how to convince the masses if "nanomsg in Python in 4 lines of code" isn't enough!
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 16:17:06 UTC, Panke wrote: On Wednesday, 26 February 2020 at 14:51:06 UTC, Atila Neves wrote: [...] Very good read. I my opinion your work with integrating different languages with D is the most exciting stuff going on in the moment. If you had an RSS feed, I would subscribe. Wasn't there a planet D in the past? Thanks! I guess you could either follow me on github, the blog itself, or Twitter.
Re: Blog post on calling C from Python via D
On Wednesday, 19 February 2020 at 16:30:04 UTC, Atila Neves wrote: https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/ Discussion elsewhere: https://www.reddit.com/r/programming/comments/f6agvt/want_to_call_c_from_python_use_d/ https://news.ycombinator.com/item?id=22365166 A lot of the comments were about how stupid I was for not just using ctypes or cffi. I tried today and both of them are horrible. As I say in the blog post below, either they didn't read the article (people on the internet commenting on things they didn't even read? Shock! Horror!) or just aren't lazy enough. My followup: https://atilaoncode.blog/2020/02/26/seriously-just-use-d-to-call-c-from-python/
Re: DIP 1027---String Interpolation---Format Assessment
On Monday, 24 February 2020 at 15:41:16 UTC, Steven Schveighoffer wrote: On 2/24/20 4:38 AM, Atila Neves wrote: There's also the practical question of template instantiations and compile times even if the DIP that was being discussed were to be modified in the way suggested. I want to actually explore this. Thanks for the detailed write-up, there are a lot of good things here.
Re: DIP 1027---String Interpolation---Format Assessment
On Sunday, 23 February 2020 at 18:57:55 UTC, Adam D. Ruppe wrote: On Sunday, 23 February 2020 at 16:22:46 UTC, Mike Parker wrote: The decision was primarily influenced by the lack of consensus over the implementation and the syntax demonstrated in the two review threads. That's not true, we had consensus minus one - the community rallied around just one small tweak to the proposal. I don't think that the proposed change was one small tweak. Even if it were, the DIP that just got rejected didn't have it. There's also the practical question of template instantiations and compile times even if the DIP that was being discussed were to be modified in the way suggested. Would you have preferred the DIP were accepted "as-was"?
Blog post on calling C from Python via D
https://atilaoncode.blog/2020/02/19/want-to-call-c-from-python-use-d/ Discussion elsewhere: https://www.reddit.com/r/programming/comments/f6agvt/want_to_call_c_from_python_use_d/ https://news.ycombinator.com/item?id=22365166
Re: dud: A dub replacement
On Thursday, 28 November 2019 at 14:06:39 UTC, Adam D. Ruppe wrote: On Thursday, 28 November 2019 at 13:10:44 UTC, Atila Neves wrote: This is the done already by reggae. Unfortunately, since every D module is effectively a header, the number of files that need to be recompiled is usually large, despite the fact that for most changes the recompilation isn't actually necessary. Do you think it might work if it did dmd -H and make the auto-generated .di file and then did a content-based change detection on them for recompiling dependencies? Probably. In fact, I had a plan to do exactly that and measure to see what the difference was. I just haven't gotten around to doing it yet. It'd prolly still do more work than it has to, but seeing .d changed, rebuild .di, if .di changed, rebuild other stuff might just avoid full rebuilds upon just simple function body changes. That was my idea as well.
Re: dud: A dub replacement
On Monday, 25 November 2019 at 15:27:10 UTC, Robert Schadek wrote: On Monday, 25 November 2019 at 13:14:09 UTC, Sebastiaan Koppe wrote: The biggest thing for me would be incremental compilation. As well as a dub build and test 'watch' mode to avoid scanning the dependencies every time. I think there are two levels to incremental compilation (IC). 1. File level IC. Meaning, if you have one file change, you only recompile all files that depend on that directly or transitively. Finally, you relink. This is the done already by reggae. Unfortunately, since every D module is effectively a header, the number of files that need to be recompiled is usually large, despite the fact that for most changes the recompilation isn't actually necessary. For 1. my goal with dud is to do that. My first target is to emit ninja files. That isn't going to work: https://issues.dlang.org/show_bug.cgi?id=14188 reggae wraps dmd to act in a way that ninja can use. I'd also suggest that writing more ninja emitting code when reggae already does the job might be unnecessary. The reason I stopped working on my own dub replacement is because I needed to attach to "a real build system", and since I want to rewrite reggae from scratch by building on the "Build Systems à la carte" paper...
Re: dud: A dub replacement
On Monday, 25 November 2019 at 13:14:09 UTC, Sebastiaan Koppe wrote: On Monday, 25 November 2019 at 12:15:42 UTC, Joseph Rushton Wakeling wrote: What's currently broken or impossible in DUB? What parts of that can be fixed without changing the config or CLI? And what improvements are most efficiently made via breaking changes? Please, let's bring our focus on that. The biggest thing for me would be incremental compilation. https://github.com/atilaneves/reggae Works right now with any (*) dub project. * If it doesn't, please file a bug
Re: Blog Post: Beating std::visit Without Really Trying
On Wednesday, 16 October 2019 at 15:23:01 UTC, Paolo Invernizzi wrote: On Wednesday, 16 October 2019 at 15:01:17 UTC, Atila Neves wrote: [...] I don't think it's political: the change implies breakage for downstream users who inherit from the class who might not even care about @nogc. The proposed solution is to "add" a new @nogc method, with the correct signature, so that if someone want to write application and care about @nogc and @safe can rely on the D standard library being complaint to that. What's the problem with that, if not a _political_ one? We have a "wrong" signature, we don't break anything, but we add "correct" signature. That's what already was done in Mutex with lock_nothrow, but it's seen as "annoying to have to define/use alternate names for all the methods, though" Oh. I missed that.
Re: Blog Post: Beating std::visit Without Really Trying
On Wednesday, 16 October 2019 at 12:32:28 UTC, Paolo Invernizzi wrote: On Wednesday, 16 October 2019 at 10:56:40 UTC, Atila Neves wrote: On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright wrote: On 10/7/2019 12:37 AM, Paolo Invernizzi wrote: - adding another method to a class, marked @nogc, and (maybe) deprecating the previous method is seen as 'annoying', also if it's a _clear_ improvement over the actual situation (you can write _better_ code with that in place compared to the actual situation, I mean) @nogc doesn't actually enable writing better code. It doesn't change the generated code at all. I'm on the same boat with you, regarding what you wrote, but ... I still don't understand the number printed on the bar level. Atila is in charge of this, and he is because he's shown excellent judgement about these matters over the years. I think that I need to ruminate on Phobos v2. In the meanwhile, a much easier and shorter route to improving the D library ecosystem is to put something up on code.dlang.org, which requires no gatekeeping. While I agree on the ecosystem, the problem of keeping the actual Phobos modules in a good shape still apply. Please take a look at the cited pull request: it's a *trivial* Phobos patch, that can be added aside to the current implementation, blocked for months waiting for a _political_ decision. I don't think it's political: the change implies breakage for downstream users who inherit from the class who might not even care about @nogc. This a technical point. The easiest way out in my opinion is to to inherit from it yourself and mark `receive` @nogc, as was suggested in the PR. I understand that "there's always something else better for the language to do", but Phobos is the current "home sweet home" for everyone approaching D, and it's the first library inspected in details. I understand that and sympathise. It's simply embarrassing to explain to an external reviewer that a standard library method signature is inaccurate after 88 releases of version 2 of the language. And that yes, 'assumeNoGC' is needed, 'trust' that, and yes, an issue was filed along with a potential fix. Indeed. We're hardly alone in this: std::auto_ptr was/is an embarassment in C++. Then there's std::vector...
Re: Blog Post: Beating std::visit Without Really Trying
On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright wrote: On 10/7/2019 12:37 AM, Paolo Invernizzi wrote: - adding another method to a class, marked @nogc, and (maybe) deprecating the previous method is seen as 'annoying', also if it's a _clear_ improvement over the actual situation (you can write _better_ code with that in place compared to the actual situation, I mean) @nogc doesn't actually enable writing better code. It doesn't change the generated code at all. I'm on the same boat with you, regarding what you wrote, but ... I still don't understand the number printed on the bar level. Atila is in charge of this, and he is because he's shown excellent judgement about these matters over the years. I think that I need to ruminate on Phobos v2. In the meanwhile, a much easier and shorter route to improving the D library ecosystem is to put something up on code.dlang.org, which requires no gatekeeping.
Going on holiday for the next 3 weeks...
... So not going to be available until I'm back.
Re: bolts meta programming library version 1.0.0 - including the from idiom
On Tuesday, 16 July 2019 at 20:18:30 UTC, John Colvin wrote: On Tuesday, 16 July 2019 at 18:18:50 UTC, Atila Neves wrote: On Tuesday, 16 July 2019 at 00:10:19 UTC, Aliak wrote: On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote: On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote: [...] Nice! I'm working on something similar but with a different goal. Thanks! How’s the thing similar and what’s the goal (if you don’t mind me asking)? Similar: One-stop shop for reflection unifying the disparate APIs. Goal: allow "regular" code for reflection purposes by (also) returning everything as strings. Is this related to the talk Andrei gave at a recent dconf? Yep!
Re: bolts meta programming library version 1.0.0 - including the from idiom
On Tuesday, 16 July 2019 at 00:10:19 UTC, Aliak wrote: On Monday, 15 July 2019 at 21:20:16 UTC, Atila Neves wrote: On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote: I've been using a set of meta tools for a while now, so decided to release it as 1.0.0 with a few enhancements chucked on. [...] Nice! I'm working on something similar but with a different goal. Thanks! How’s the thing similar and what’s the goal (if you don’t mind me asking)? Similar: One-stop shop for reflection unifying the disparate APIs. Goal: allow "regular" code for reflection purposes by (also) returning everything as strings.
Re: bolts meta programming library version 1.0.0 - including the from idiom
On Monday, 15 July 2019 at 11:13:10 UTC, aliak wrote: I've been using a set of meta tools for a while now, so decided to release it as 1.0.0 with a few enhancements chucked on. [...] Nice! I'm working on something similar but with a different goal.
Re: Cushion the state transition table library released
On Thursday, 27 June 2019 at 22:36:14 UTC, ag0aep6g wrote: On 27.06.19 23:34, aliak wrote: I really love that you go in to the code and find things like this, especially when it comes to abuse of @trusted, but maybe a little explanation as to why would be more helpful to the OP ;) Probably. But this isn't D.learn, and I'm getting tired of explaining @trusted. Would you consider writing a blog post about it? I'm sure it would be helpful to a lot of people.
Re: nogc v0.5.0 - DIP1008 works!
On Monday, 27 May 2019 at 10:31:10 UTC, ag0aep6g wrote: On 27.05.19 12:06, Atila Neves wrote: No, and I guess it can't. I'm trying to figure out what the implications are. Can Vector only be @safe for Mallocator? Is it possible to write a @safe Vector at all without having to force the allocator to be @safe? For @safe allocators, Vector can be @safe. For specific @system allocators, like Mallocator, you can make special @trusted cases in Vector. For generic @system allocators, Vector cannot be @safe (or @trusted). It's ugly but would work. Right now I don't think I can do any better than to follow your suggestion, but I predict many beard-stroking walks for me along Lake Geneva in the near future. I'd be nice if I could detect at compile-time that it's not just Mallocator but an allocator that's built using it as well (e.g. FallBackAllocator).
Re: nogc v0.5.0 - DIP1008 works!
On Monday, 27 May 2019 at 09:48:27 UTC, ag0aep6g wrote: On 27.05.19 10:54, Atila Neves wrote: I don't see the problem here. This example would throw RangeError at runtime instead of actually overwriting memory unless bounds checking is turned off. No, it doesn't. It's a complete, runnable example. You can try it at home. It does overwrite `foo` and `bar`. It does not throw a RangeError. You're right - I should have run it first. Yes, you can use @trusted to use Mallocator safely. And your code (probably) does that. But the allocator in my example isn't Mallocator, it's UnsafeAllocator. Your code doesn't use that one safely. No, and I guess it can't. I'm trying to figure out what the implications are. Can Vector only be @safe for Mallocator? Is it possible to write a @safe Vector at all without having to force the allocator to be @safe? In this thread, you're the author of that 3rd party library. You've got the bad @trusted functions that lead to memory corruption. I'm the guy who looked at it, noticed the problem, and tells you. Thanks for bringing it up.
Re: nogc v0.5.0 - DIP1008 works!
On Monday, 27 May 2019 at 09:07:48 UTC, Paolo Invernizzi wrote: On Monday, 27 May 2019 at 08:54:45 UTC, Atila Neves wrote: On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote: Then there's the fact that if a 3rd party library really does want to corrupt memory they can just tag all their functions with @trusted, and unless someone looks at their code nobody will be the wiser. ... and a @safe conscious programmer will not touch that library ever with a 5 five meters pole. I'm still not convinced that trusted code should accept generic system code ... can you elaborate more? I'm not convinced either - I'm having a dialogue to figure out potential issues.
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 16:51:11 UTC, ag0aep6g wrote:
On 24.05.19 18:19, Atila Neves wrote:
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote:
[...]
My `puts`s might not do any harm, but they could just as well
be buffer overflows.
Could you please give an example of how @system allocator code
could do that?
Sure. You just write beyond some buffer instead of calling
`puts`:
char[3] buf;
char[3] foo = "foo";
char[3] bar = "bar";
struct UnsafeAllocator
{
import std.experimental.allocator.mallocator: Mallocator;
static instance = UnsafeAllocator.init;
size_t i;
void deallocate(void[] bytes) @nogc @system
{
buf.ptr[i .. i + 3] = '!';
Mallocator.instance.deallocate(bytes);
}
void[] allocate(size_t sz) @nogc @system
{
buf.ptr[i .. i + 3] = '!';
return Mallocator.instance.allocate(sz);
}
}
void main() @safe @nogc
{
{
import nogc: BUFFER_SIZE, text;
UnsafeAllocator.instance.i = 8;
/* greater than buf.length, whoops */
auto t = text!(BUFFER_SIZE, UnsafeAllocator)(42);
assert(foo == "foo"); /* fails */
UnsafeAllocator.instance.i = 16;
/* also greater than buf.length, whoops again */
}
assert(bar == "bar"); /* fails */
}
You just can't trust user-provided @system code. It doesn't
matter if it's allocator code or whatever.
I don't see the problem here. This example would throw RangeError
at runtime instead of actually overwriting memory unless bounds
checking is turned off.
The other issue is that Mallocator has a @safe allocate function
and a @system deallocate function since it's up to the user of
the interface to supply a slice that was actually malloc'ed. It's
clear that this interface is one that can be used @safely (and is
by automem.vector.Vector). Likewise, reallocating is @system
because there might be references to the old pointer, but it
makes sense that a @trusted block could exist where the reviewer
makes sure that there's only ever one reference to the allocated
memory.
Then there's the fact that if a 3rd party library really does
want to corrupt memory they can just tag all their functions with
@trusted, and unless someone looks at their code nobody will be
the wiser.
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 13:30:05 UTC, ag0aep6g wrote: On Friday, 24 May 2019 at 13:13:12 UTC, Atila Neves wrote: Thanks for this. I think the only violation is calling `stringz` on `Z`, and that was due to a poorly designed DbI check on being able to call `stringz`. Allocating generally isn't @system, and freeing is ok to trust since vector is taking care of it for us. I've pushed a fix. I think you're missing the point. When your function is marked as @safe or @trusted, then any execution of a user-provided @system function is a safety violation. My `puts`s might not do any harm, but they could just as well be buffer overflows. Could you please give an example of how @system allocator code could do that?
Re: nogc v0.5.0 - DIP1008 works!
On Friday, 24 May 2019 at 12:32:45 UTC, ag0aep6g wrote:
On 24.05.19 13:41, Atila Neves wrote:
[...]
You've got safety violations:
/+ dub.sdl:
name "test"
dependency "nogc" version="~>0.5.0"
+/
import core.stdc.stdio: puts;
struct S1
{
S2 s2;
this(ref const S1 src) const @nogc @system { this.s2 =
src.s2; }
}
struct S2
{
this(ref const S2 src) const @nogc @system { puts("@system
1"); }
}
struct Z
{
char* stringz() const @nogc @system
{
puts("@system 2");
return null;
}
}
struct UnsafeAllocator
{
import std.experimental.allocator.mallocator: Mallocator;
enum instance = UnsafeAllocator.init;
void deallocate(void[] bytes) @nogc @system
{
puts("@system 3");
Mallocator.instance.deallocate(bytes);
}
void[] allocate(size_t sz) @nogc @system
{
puts("@system 4");
return Mallocator.instance.allocate(sz);
}
}
void main() @safe @nogc
{
import nogc: BUFFER_SIZE, text;
S1 a;
Z* z;
auto t = text!(BUFFER_SIZE, UnsafeAllocator)(a, z);
}
All of the `puts` lines are executed. That should not be
possible in @safe code. You're applying @trusted too liberally.
Thanks for this. I think the only violation is calling `stringz`
on `Z`, and that was due to a poorly designed DbI check on being
able to call `stringz`. Allocating generally isn't @system, and
freeing is ok to trust since vector is taking care of it for us.
I've pushed a fix.
nogc v0.5.0 - DIP1008 works!
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:
@safe @nogc unittest {
import nogc;
import std.algorithm: equal;
int a = 1, b = 2;
try
enforce(a == b, a, " was not equal to ", b);
catch(NoGcException e) {
assert(equal(e.msg, "1 was not equal to 2"));
}
try
throw new NoGcException(42, " foobar ", 33.3);
catch(NoGcException e) {
assert(equal(e.msg, "42 foobar 33.30"));
assert(e.file == __FILE__);
assert(e.line == __LINE__ - 4);
}
}
It doesn't leak memory either, as proved by ldc's asan.
Re: Mir Algorithm 3.4.1 - RCArray and RCPtr
On Wednesday, 24 April 2019 at 10:52:14 UTC, jmh530 wrote: On Wednesday, 24 April 2019 at 01:34:58 UTC, 9il wrote: Thread safe RC Array and Ptr. Plus C++ headers for code integration. [snip] Cool. Does this make any use of DIP1000? How is the run-time/memory performance vs. the GC versions? Can't answer for mir, but automem uses DIP1000: https://github.com/atilaneves/automem I haven't profiled it against "the GC version", but it would highly depend on the allocators used and the application.
Re: DPP on the D Blog
On Tuesday, 9 April 2019 at 21:11:28 UTC, DanielG wrote: re: the difficulties of interfacing D with certain types of C/C++ code ... Has anybody looked into something like a JavaCpp[1] approach for D? Instead of trying to get D to speak directly with C++, or translating C/C++ headers to D, why not use special annotated D code to generate a middleman .cpp file, which then exports a D-friendly interface? Then all the dirty work gets handled by a C++ compiler. Wouldn't that be an order of a magnitude easier to implement? [1]: https://github.com/bytedeco/javacpp I've considered this, and am still considering it, despite not having heard of javacpp before. Thanks for the link, I'll take a look.
Re: DPP on the D Blog
On Monday, 8 April 2019 at 11:30:48 UTC, Andre Pany wrote: On Monday, 8 April 2019 at 10:28:04 UTC, Mike Parker wrote: I've just published a new Project Highlight, this one on dpp. Atila shares some anecdotes about how and why the project came together. He'll be speaking more about it at DConf next month. The blog: https://dlang.org/blog/2019/04/08/project-highlight-dpp/ Reddit: https://www.reddit.com/r/programming/comments/bas2my/dpp_include_c_and_c_headers_directly_in_your_d/ Somewhere on HN: https://news.ycombinator.com/ Great functionality and great article. I just realized DPP would be a perfect candidate for a Dub plugin. Just write the .dpp files, add the dependency to DPP in dub.json and the Dub plugin mechanism (to be implemented) will do all the rest for you. John Colvin was working on this.
Re: jupyter-wire v0.0.3 - markdown/HTML support
On Sunday, 7 April 2019 at 07:05:32 UTC, bauss wrote:
On Friday, 5 April 2019 at 12:03:48 UTC, Atila Neves wrote:
http://code.dlang.org/packages/jupyter_wire
It's now possible to send markdown or HTML to a jupyter
notebook from D:
return markdownResult("# Header");
Simple, but looks pretty.
Thanks Atila for all your great work and projects!
Thanks for the kind words!
jupyter-wire v0.0.3 - markdown/HTML support
http://code.dlang.org/packages/jupyter_wire
It's now possible to send markdown or HTML to a jupyter notebook
from D:
return markdownResult("# Header");
Simple, but looks pretty.
Re: Compiler benchmarker for D, C, C++, Go, Rust with more to come
On Tuesday, 19 March 2019 at 10:10:28 UTC, Seb wrote: On Monday, 18 March 2019 at 21:34:40 UTC, Per Nordlöw wrote: On Monday, 18 March 2019 at 12:33:12 UTC, Seb wrote: [1] https://github.com/dlang/installer Does this include a script for building dmd with ldc or this not yet possible? Well, you don't really need a script: git clone https://github.com/dlang/dmd HOST_DMD=ldmd2 make -f posix.mak -j10 HOST_DMD=ldmd2 make -f posix.mak -j`nproc` FTFY. It's bad enough make is a dinosaur that defaults to one thread, let's not hard-code the number of cores. Additionally, you can add `ENABLE_RELEASE=1` to create a fully optimized release binary. Awesome. BTW, the Arch DMD package [1] is the only package that I know of which is actually using LDC to compile DMD for the released binaries. Huh, I didn't know that. Yay Arch! And yet, compilation times are still my mortal enemy...
Re: Blog post on the joys of hand-translating C++'s std::function to D
On Friday, 8 March 2019 at 10:27:54 UTC, Jacob Carlborg wrote: On 2019-03-07 16:45, Atila Neves wrote: C++ is hard: https://atilaoncode.blog/2019/03/07/the-joys-of-translating-cs-stdfunction-to-d/ Using ".mangleof" and "pragma(mangle)" on the same symbol looks like something that could easily break. Maybe. Who knows how else to do it though.
Blog post on the joys of hand-translating C++'s std::function to D
C++ is hard: https://atilaoncode.blog/2019/03/07/the-joys-of-translating-cs-stdfunction-to-d/
Re: DIP 1018--The Copy Constructor--Formal Review
On Tuesday, 26 February 2019 at 03:56:27 UTC, Walter Bright wrote: On 2/25/2019 7:45 AM, Atila Neves wrote: I have no idea what people are talking about when they mention on this forum that D's const is useless. Nearly every function parameter in my code is `in`. Nearly every variable declaration uses `const` instead of `auto`, the main exception being when a function is constructing a value to return. Most member functions I write are const or inout. I use const in D as I do in C++: pretty much everywhere. Nearly every single time a function parameter in my code isn't const is when it's an input range. I'm going to make an educated guess that you're experienced at FP programming! Indeed. Functional is my default in any language. The good thing about D is I can get my hands dirty when needed as opposed to jumping through hoops or forcing me to use recursion when it doesn't fit the problem (hello C++ metaprogramming). I'd love it if functions were `@safe` and `pure` by default.
Re: DIP 1018--The Copy Constructor--Formal Review
On Monday, 25 February 2019 at 00:38:02 UTC, Walter Bright wrote: The problem with C++ const is it only goes one level, i.e. what I call "head-const". If you pass a T to a const parameter, anything T references remains mutable. It's more of a suggestion than anything reliable or enforceable. It only works if your data structures are simple aggregates, not graphs. D's const has teeth. Nothing can be modified through T. If you're used to writing code that tweaks const data under the hood, D's const will never work for you. Yes, it means rethinking how the data and code is organized, and that can be painful. But it is how FP works. FP offers a number of advantages, and D's const offers a path into that. I have no idea what people are talking about when they mention on this forum that D's const is useless. Nearly every function parameter in my code is `in`. Nearly every variable declaration uses `const` instead of `auto`, the main exception being when a function is constructing a value to return. Most member functions I write are const or inout. I use const in D as I do in C++: pretty much everywhere. Nearly every single time a function parameter in my code isn't const is when it's an input range. I happened to be working on dpp at the time I wrote this: $ ag 'auto ' source | wc -l 67 $ ag 'const ' source | wc -l 204 The *only* problem I have with const in D is that const values can't be copied, which is silly. I'd expect DIP1018 to fix that.
Re: kwargs v0.0.1 - Keyword arguments with strong types
On Monday, 11 February 2019 at 22:32:59 UTC, Vladimir Marchevsky
wrote:
On Monday, 11 February 2019 at 17:03:36 UTC, Atila Neves wrote:
import kwargs;
struct Foo { string value; }
struct Bar { string value; }
struct Baz { string value; }
size_t funImpl(in Foo foo, in Bar bar = Bar("lebar"), in Baz
baz = Baz("lebaz")) {
return foo.value.length + bar.value.length +
baz.value.length;
}
alias fun = kwargify!funImpl;
fun(Foo()).should == 10;
fun(Bar("b"), Foo("fo")).should == 8;
fun(Bar("b"), Baz("ba"), Foo("foo")).should == 6;
So all arguments should have different types, right? Like here
we have 3 strings wrapped in structs to distinguish them
Yes, they all have to have different types.
kwargs v0.0.1 - Keyword arguments with strong types
https://code.dlang.org/packages/kwargs
There have been many posts asking about keyword arguments for D a
la Python. Usually I reply saying to just use the type system,
but that has the incovenience of having to pass all 7 parameters
before the optional 8th one you actually care about despite you
being ok with the default values before that. std.process.execute
is a particular thorn in my side since I usually only want to
change `workDir`, but I digress. Behold:
--
import kwargs;
struct Foo { string value; }
struct Bar { string value; }
struct Baz { string value; }
size_t funImpl(in Foo foo, in Bar bar = Bar("lebar"), in Baz baz
= Baz("lebaz")) {
return foo.value.length + bar.value.length + baz.value.length;
}
alias fun = kwargify!funImpl;
fun(Foo()).should == 10;
fun(Bar("b"), Foo("fo")).should == 8;
fun(Bar("b"), Baz("ba"), Foo("foo")).should == 6;
--
The API for compile-time parameters isn't as nice, but seeing as
how there's no way in D that I know of currently to reflect on
those, this is what I managed to conjure up:
--
struct Foo { int val; }
struct Bar { int val; }
struct Baz { int val; }
int[] funImpl(Foo foo, Bar bar, Baz baz)() {
return [foo.val, bar.val, baz.val];
}
alias fun = kwargify!(funImpl, Required!Foo, Optional!(Bar(2)),
Optional!(Baz(3)));
fun!(Foo(1)).should == [1, 2, 3];
fun!(Baz(9), Foo(7)).should == [7, 2, 9];
fun!(Baz(9), Bar(8), Foo(7)).should == [7, 8, 9];
--
Re: unit-threaded v0.8.0
On Thursday, 31 January 2019 at 16:01:33 UTC, jmh530 wrote:
On Thursday, 31 January 2019 at 14:42:43 UTC, Atila Neves wrote:
[snip]
I've never had a need to use complicated values, so I haven't
coded that.
If presented with an example, I think there's a high chance
I'd consider it an anti-pattern.
I was thinking about something like what is in one of mir's sum
unittests
https://github.com/libmir/mir-algorithm/blob/deb64093afa7f934956c1568358444a803d2240c/source/mir/math/sum.d#L1587
The code builds up a bunch a tuple of tuples with each
containing an array and a value that the array is supposed to
sum to. It then runs through them all with a foreach loop.
Here's another example:
https://github.com/libmir/mir-algorithm/blob/deb64093afa7f934956c1568358444a803d2240c/source/mir/math/sum.d#L1762
Ah. I wasn't clear, so sorry for that. Whatever is doable in CTFE
you can use as an attribute. I thought you meant runtime values.
This is perfectly ok:
struct Foo {
int i;
}
Foo doubleFoo(int i) {
return Foo(i * 2);
}
@Values(doubleFoo(42), doubleFoo(33)) unittest {}
I tried by using examples, but without knowing what's not
clear it's hard for me to know what to do about it.
I was just thinking like some more real-world examples of how
you have used it. The readme.md is good!
For types, I just wrote this as part of rewriting cerealed from
scratch:
@UnitTest
@Types!(
bool, byte, ubyte, char,
short, ushort,
int, uint,
)
@Types!(BigEndian!DefaultOutput, LittleEndian!DefaultOutput, JSON)
void thereAndBackAgain(Type, Backend)() {
check!((Type val) => val.cerealise!Backend.decerealise!(Type,
Backend) == val);
}
8 types x 3 backends = 24 tests in very few lines of code, each
of them trying 100 random values, and with the advantage that I
can run just one of those 24 tests if need be, and error
reporting for each of them separately.
Re: unit-threaded v0.8.0
On Thursday, 31 January 2019 at 15:03:26 UTC, Colin wrote:
On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves
wrote:
New release of unit-threaded, the advanced test framework for
D:
https://code.dlang.org/packages/unit-threaded
Besides bug fixes, the main difference is now cartesian
product of types works as it did for values when it comes to
parameterized tests:
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof == 4);
}
--
This now generates 6 tests, one for each combination of types,
similarly to what already worked with the @Values UDA.
Thanks for this library. One of the more useful on
code.dlang.org!
Thanks!
Re: unit-threaded v0.8.0
On Wednesday, 30 January 2019 at 14:55:37 UTC, jmh530 wrote:
On Wednesday, 30 January 2019 at 14:27:25 UTC, Atila Neves
wrote:
[snip]
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof == 4);
}
--
This now generates 6 tests, one for each combination of types,
similarly to what already worked with the @Values UDA.
I'm a little confused on this. What if you have void fun(T0,
T1, T2)) {}, but only two @Types listed? Does it just do the
first two?
It would fail to compile.
Also, there is an example in the readme on @Values of
@Values(1, 2, 3) unittest { assert(getValue!int % 2 == 0); }
What if it's not so easy to create the values? I suppose you
could pass the parameters in @Values to some other function
that will then create what you actually need and then test
using that.
I've never had a need to use complicated values, so I haven't
coded that.
If presented with an example, I think there's a high chance I'd
consider it an anti-pattern.
Maybe good to provide some more examples of advanced usage?
Documentation is hard. :(
I tried by using examples, but without knowing what's not clear
it's hard for me to know what to do about it.
unit-threaded v0.8.0
New release of unit-threaded, the advanced test framework for D:
https://code.dlang.org/packages/unit-threaded
Besides bug fixes, the main difference is now cartesian product
of types works as it did for values when it comes to
parameterized tests:
--
@Types!(ubyte, byte)
@Types!(int, uint, float)
@UnitTest
void fun(T0, T1)() {
static assert(T0.sizeof == 1);
static assert(T1.sizeof == 4);
}
--
This now generates 6 tests, one for each combination of types,
similarly to what already worked with the @Values UDA.
Re: Last Year in D
On Thursday, 24 January 2019 at 13:58:59 UTC, Mike Parker wrote: I said in my annual D Blog retrospective that I wanted to do a similar post focused on D at large. Sebastian Wilzbach sent me a tremendously helpful info dump of all sorts of goings on, most of which I knew nothing about. When I sat down to write the post, it occurred to me that since Adam Ruppe had recently revived 'This Week in D', it would be fun to have him write up a 'Last Year in D'. I asked, he accepted, I sent him Seb's data (thanks Seb!) and the result is now live on the blog. The blog: https://dlang.org/blog/2019/01/24/last-year-in-d/ Reddit: https://www.reddit.com/r/d_language/comments/ajclv0/last_year_in_d_the_d_blog/ "March also introduced experimental @nogc exception throwing (as proposed in DIP1008)" Too bad it doesn't work at all right now: https://issues.dlang.org/show_bug.cgi?id=19463
