Re: Is D programming friendly for beginners?
On Tuesday, 12 March 2024 at 16:20:29 UTC, matheus. wrote: On Tuesday, 12 March 2024 at 14:52:32 UTC, Mike Shah wrote: ... I really think D would be a wonderful first language. Fast feedback, no need to manage memory, and easy to use built-in data structures would make for a nice intro course. If you say that D would be a good language to learn in lieu C++/Rust I'd agree, but as a First Language neither one would be my choice. Most here already program and know things, but as a first language forget, at least where and when I did college (Already knowing how to program), most people were lost with all the concepts of C++ for example. Bitwise shifts like << >> and the same operators being used in cin/cout may be OK for most people already in programming and using shell, but for those learning was a hell. Matheus. I think it really depends on the person. My first language was C++, which was absolute hell to learn as a complete beginner to programming, but I really wanted to learn a language with low-level capabilities that could also do gamedev. Learning C++ as my first language was incredibly difficult, but it also made the programming parts of my CS degree a breeze - especially courses like machine level programming. Nobody else in the class even understood what a pointer was for the first couple weeks.
Re: Preparing for the New DIP Process
On Thursday, 25 January 2024 at 15:03:41 UTC, Max Samukha wrote:
On Monday, 22 January 2024 at 23:28:40 UTC, Jonathan M Davis
wrote:
Of course, ultimately, different programmers have different
preferences, and none of us are going to be happy about
everything in any language.
It's not only about preferences. The feature is inconsistent
with how 'invariant' and 'synchronized' are specified. They
imply class-instance-level private, while the language dictates
module-level. Consider:
```
synchronized class C
{
private int x;
private int y;
invariant () { assert (x == y); }
}
void foo(C c)
{
// mutate c
}
```
With module-level private, 'foo' is part of C's public
interface, but it neither locks on c, nor runs the invariant
checks. I personally have no idea how to fix that sensibly
except by ditching class invariant/synchronized entirely.
This is the only valid reason for introducing class-private
that's ever been put forth in this forum. I saw someone else post
a similar argument around class invariants awhile back as well
and it completely changed my mind on the issue.
Re: DIP 1043---Shortened Method Syntax---Accepted
On Wednesday, 21 September 2022 at 10:40:42 UTC, Mike Parker wrote: On Wednesday, 21 September 2022 at 10:39:27 UTC, Mike Parker wrote: DIP 1043, "Shortened Method Syntax", has been accepted. https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1043.md That's awesome! Congrats to Max.
Re: Release D 2.099.0
On Wednesday, 9 March 2022 at 12:06:40 UTC, evilrat wrote: On Wednesday, 9 March 2022 at 10:08:50 UTC, meta wrote: On Wednesday, 9 March 2022 at 09:04:03 UTC, Martin Nowak wrote: Glad to announce D 2.099.0, ♥ to the 100 contributors. This release comes with __traits(parameters), unittests only from root modules, throw expressions, and plenty of more changes. http://dlang.org/download.html http://dlang.org/changelog/2.099.0.html -Martin The download links doesn't work.. I get access denied, what is happening? Are CI/CD builds available somewhere? on GitHub? it seems like upload script error, download link is https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2021/dmd-2.099.0.exe but if you change it to (notice 2022 instead of 2021) https://s3.us-west-2.amazonaws.com/downloads.dlang.org/releases/2022/dmd-2.099.0.exe it now works I still get access denied error on the download page, nobody test the releases? I had a similar issue for downloaded the beta, and it was still not fixed.. This needs to be sorted out, it's 2 release in a row that is messed up
Re: Release D 2.099.0
On Wednesday, 9 March 2022 at 09:04:03 UTC, Martin Nowak wrote: Glad to announce D 2.099.0, ♥ to the 100 contributors. This release comes with __traits(parameters), unittests only from root modules, throw expressions, and plenty of more changes. http://dlang.org/download.html http://dlang.org/changelog/2.099.0.html -Martin The download links doesn't work.. I get access denied, what is happening? Are CI/CD builds available somewhere? on GitHub?
Re: trash-d version 15
On Tuesday, 8 March 2022 at 14:29:07 UTC, rushsteve1 wrote: Hello! I thought I would give an update on `trash-d`, the utility that I've been writing in D for the last several months. https://github.com/rushsteve1/trash-d Previous announcement thread: https://forum.dlang.org/thread/onpukmibdjhtwwsva...@forum.dlang.org Since my last post there have been a number of new releases, the latest being version 15 which I tagged yesterday. `trash-d` can now handle cross-device trashing, report orphaned files in the trash, presents info as nicer tables, and there are now DEB and RPM packages built by CI. And a whole host of bugfixes and smaller features, as well as a pretty solid test set with about 85% coverage. I'm still a bit of a D novice, so any feedback or suggestions (or PRs) are highly appreciated! That's a very nice project, thanks for sharing, the code is very clean and easy to read, well done! The only note I can make so far is the lack of proper modules ``module x;`` I'm surprised you could import other files without it, is it common practice to ignore that rule when everything is top level?
Re: D Language Foundation Monthly Meeting for February 2022
On Sunday, 27 February 2022 at 11:53:18 UTC, Mike Parker wrote: ### Vladimir Vladimir opened with a progress report. Back in December, [we discussed migrating our Bugzilla issues to Github](https://forum.dlang.org/post/wnnwxyjtizvhyswwq...@forum.dlang.org). An alternative solution is to [upgrade to Bugzilla Harmony](https://github.com/bugzilla/harmony), a project Vladimir had been contributing to for some time. After that meeting, we agreed that Robert Schadek would move forward with implementing his migration script, while Vladimir would get the new Bugzilla instance set up so we can test it out in the interim. I was looking forward the Github migration.. I'm not liking the constant switch from Github/bugzilla, referencing/looking for issues is also a major pain.. LLVM recently migrated fully to Github/Github Issues, that's is the way to go in my opinion.. Can't beat the nice integration and ease of access Github provides, we need stay fresh to attract new younger souls
Re: Added copy constructors to "Programming in D"
On Thursday, 10 February 2022 at 20:34:29 UTC, Walter Bright wrote: On 2/10/2022 12:06 AM, Mathias LANG wrote: I think an *immediate* improvement we could make to ease people's life is to make `auto` peel the outermost qualifier level inside functions. So that: ```D const int* ptr; auto p2 = ptr; static assert(is(typeof(p2) == const(int)*)); ``` I really can't think of any downside to it, only upsides: - It is still predictable / consistent; - It *might* reduce the number of template instantiations in some cases; - It just flows more naturally... If you want full constness, there's still `const`; It sounds sensible to me. Didn't Scott Meyers cover exactly this in his "the last thing D needs" talk? It seems like a really bad idea.
Re: Added copy constructors to "Programming in D"
Why do we even bother with `in` when we can do:
alias In(T) = const scope T;
void test(In!int n) {
pragma(msg, typeof(n));
}
?
onlineapp.d(3): Deprecation: storage class `scope` has no effect
in type aliases
const(int)
...oh
Re: Release D 2.096.0
On Sunday, 14 March 2021 at 05:31:27 UTC, Max Haughton wrote: On Sunday, 14 March 2021 at 03:25:28 UTC, starcanopy wrote: On Saturday, 13 March 2021 at 21:33:20 UTC, Meta wrote: It's pretty neat, but a DIP has to be drafted and approved for it to be enabled by default, right? (Unless I missed it.) Correct. To be completely honest it shouldn't have ever been merged since there was no approval from WalTila and they steer the language. I raised a similar concern before with something else (don't remember what it was), but apparently things can be merged without W's approval if they're behind a switch (in the opinion of at least some of the core maintainers, at least).
Re: Release D 2.096.0
On Saturday, 13 March 2021 at 21:15:40 UTC, Martin Nowak wrote:
Glad to announce D 2.096.0, ♥ to the 54 contributors.
This release comes with improved ABI compatibility for complex
types, clarified copy constructor and postblit interaction,
optional libunwind based backtraces, runtime-allocated global
synchronized mutexes, and a preview for shortened lambda-style
function definitions.
http://dlang.org/download.html
http://dlang.org/changelog/2.096.0.html
-Martin
Allow shortened function implementations for single-expresssion
functions.
-preview=shortenedMethods is added. This allows functions to be
written in a similar form to lambda functions:
// these 2 are equivalent
int foo() { return 1; }
int foo() => 1;
The syntax allows the form => expr to replace the function body {
return expr; }
Amazing! I had no idea this got in. I love the syntax.
Re: Bubel ECS - Entity-Component-System architecture implementation
On Tuesday, 9 March 2021 at 15:21:26 UTC, Mergul wrote: On Tuesday, 9 March 2021 at 14:29:37 UTC, Meta wrote: Awesome! In the demo, I noticed that if there are >3000 entities spawned, there will be periodic dips in the FPS. Could this be Javascript's GC kicking in? What browser are you using? I've tested couple of browsers. In general JavaScript shouldn't be a problem, from what I know WASM only growth its memory. Library itself almost never call malloc (so memory is always allocated). On firefox I had problem with FPS most of a time and I'm not sure what cause this problem (I found several bug reports which could be related to that). Besides Firefox every web browser I tested was based on chromium engine. I didn't see any periodic dips, even with <200k entities. Maybe there is some problem related to WebGL or JS Workers. When JS side detects that WASM threads are enabled in browser it loads multithreaded version of WASM code and spawn workers. But overall multithreaded execution is always more stable for me. This is in Chrome 88.0.4324.192 on my 2015 Macbook Pro.
Re: Bubel ECS - Entity-Component-System architecture implementation
On Tuesday, 9 March 2021 at 16:36:31 UTC, ryuukk_ wrote: That's impressive, and shows the D capabilities, the future is WASM!!! glad to see D ready for it! Yes, I forgot to mention this, but WASM support out of the box is awesome!
Re: Bubel ECS - Entity-Component-System architecture implementation
On Monday, 8 March 2021 at 19:45:58 UTC, Mergul wrote: Hello everyone, I'm glad to announce release of my Bubel ECS library. Bubel ECS is Entity-Component-System architectural pattern implementation in D language. Library aims to delivery fast and flexible architecture for developing games. It's @nogc and betterC compatible. WASM is supported through Emscripten. Library has no external dependencies and was tested on Linux, Windows, Android and WASM. Project was developed in data oriented designed fashion and supports multithreading with automatic job generation. For more information go to Gitlab repository page. Its beta version but core is fully functional and finished. I have planned some bigger features like Worlds support, better events handling or even C-API which can lead to some changes in API. If you want try Bubel ECS I prepared demo which works in browers through WASM (Emscripten) and even supports multithreading (on Chromium based browsers, Firefox had some performance issues even on single threaded version when last tested) Demo is still WIP and it can be hard to understad how it works (how to use its features). There is possibility to enable/disable almost all systems in runtime and changing components and data for all entities. All components and systems are exact representation of what they are in code. I'm using Gitlab CI for automated testing (betterC testing included) Note: Library support multithreading but has no code for actual parallel execution, it only generates jobs and dependencies. In demos I'm using mmutils.thread_pool (my brother's library) .I will add simple integration code for it in near future for people who wants multithreading working out-of-the-box. Dub: https://code.dlang.org/packages/bubel_ecs Gitlab: https://gitlab.com/Mergul/bubel-ecs Documentation: https://mergul.gitlab.io/bubel-ecs/ecs.html Wiki: https://gitlab.com/Mergul/bubel-ecs/-/wikis/home (WIP I've started making tutorial there) Online demo: https://mergul.gitlab.io/bubel-ecs/ecs_demo.html Awesome! In the demo, I noticed that if there are >3000 entities spawned, there will be periodic dips in the FPS. Could this be Javascript's GC kicking in?
Re: Beta 2.096.0
On Sunday, 28 February 2021 at 11:56:28 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.096.0 release, ♥ to the 53 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.096.0.html As usual please report any bugs at https://issues.dlang.org -Martin "Support for instantiating local and member templates with local symbols was implemented in DMD 2.087.0. However, the implementation was incompatible with GDC and LDC backends. In order to maintain feature parity among D implementations, this improvement has been deprecated, and may be removed from a future DMD release." Urgh, so sad this was deprecated. Is the implementation being redone at some point?
Re: DIP 1034--Add a Bottom Type (reboot)--Formal Assessment Concluded
On Tuesday, 16 February 2021 at 07:07:09 UTC, Mike Parker wrote: When I emailed Walter and Atila to officially launch the Formal Assessment of DIP 1034, "Add a Bottom Type (reboot)", I expected it would be three or four weeks before I received their final decision. So I was surprised when Walter replied two days later with the following response: "Accepted with pleasure and enthusiasm. This is what DIPs should be like. I intuitively felt that a bottom type was right for D, but failed to express it in DIP1017. Dennis has done it right." Atila was on vacation at the time, but as soon as he got back he responded: "Seconded." Congratulations to Dennis Korpel for a job well done, and thanks to everyone who provided feedback on this DIP from the Draft Review through to the Final Review. Great news! Congrats to Dennis.
Re: Say Hello to Our Two New Pull-Request/Issue Managers
On Wednesday, 13 January 2021 at 11:33:44 UTC, Mike Parker wrote: I'm very, very happy that I can finally announce the news. Some of you may recall the job announcements I put out on the blog back in September [1]. Symmetry Investments offered to fund one full-time, or two part-time, Pull Request Manager positions, the goal being to improve the efficiency of our process (prevent pull requests from stagnating for ages, make sure the right people see the PRs in need of more than a simple review, persuade the right people to help with specific Bugzilla issues, etc). Several people applied for the job, including some unknown in the D community. Ultimately, two people were selected: one to fill an administrative/managerial role, the other to fill a more technical role. Today I can tell you who they are. Please congratulate Andrew Edwards and Razvan Nitu on their new positions! They have already been on the job for several days and are eager to make a difference. Currently, their responsibilities are outlined here at: https://dlang.org/foundation/prman.html Please consider this a living document. We will amend and revise it as we learn more about what they and the community need for them to do this job right. I ask that everyone please give them time to settle in. I expect we'll hear from them once they have, with some details regarding how they'll perform their duties and any relevant information for contributors. Congratulations to Andrew and Razvan, and tremendous thanks to Symmetry for making this happen. [1] https://dlang.org/blog/2020/08/30/symmetry-investments-and-the-d-language-foundation-are-hiring/ That's great! Congrats to Razvan and Andrew, and thanks to Symmetry for sponsoring the positions.
Re: Our community seems to have grown, so many people are joining the Facebook group
On Monday, 28 December 2020 at 17:31:21 UTC, Murilo wrote: In the past 2 weeks we went from 225 to 240 members in our Facebook group(https://www.facebook.com/groups/ProgrammingInDlang), an average of a person per day. First it was an average of a person per month or less. I wonder if someone has advertised the group or the world is finally embracing Dlang now. In 2018 I didn't find a single Dlang Facebook active group, there were 1 or 2 very old groups with no members. So I created one and I've been working hard to make it official and big, it worked! At first I added my friends list to give it number but then, as people joined it, I removed all of my friends and left only people who joined voluntarily, there were only 150, over time it grew to 225 and now we are getting close to 250. At first there was only a post per week, all posted by me, now I don't need to post something every week because the members are already doing it themselves, there is regular activity including posts and discussions. I'm very happy, at first the people here did not like my idea, they thought a Facebook group was unnecessary, but what is the biggest social media in the world? Facebook! So that's is the best way to communicate with the world and advertise Dlang. Cheers. Cool, I didn't know this exists. Congrats on 200+ members; that's no mean feat!
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 21:19:02 UTC, Seb wrote: On Thursday, 1 October 2020 at 21:09:55 UTC, Meta wrote: On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: [...] Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview? Approval is not required for -preview. It's the testing phase of a new feature or change. As I tried to mention earlier real data and experimentation is super helpful for a DIP / formal approval (in this case one important question answered was how much code in the D ecosystem would need to be changed). There's a bit of implicit approval by no objection as something that's worthwhile to be explored/tested, but it's only a good chance that it will be activated by default, not a guarantee. Okay, fair enough. Looks like I was mistaken and thought -preview implied that the feature will be moved out from under the switch after a certain number of releases (as the word "preview" means an early look at something that will be released in the future).
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 20:40:39 UTC, Seb wrote: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: I've read the discussion but skipped the presentation. All I see is Atila expressing distaste for the compiler choosing how to pass values, and no explicit sign-off from either Walter or Atila before it was merged. My objection is not to `in`'s new behaviour (although having something that functions similarly to auto ref but in subtly different ways is not good language design, IMO). My objection is that we have a major change to a language feature, that was merged without the apparent blessing of either of the two people who are supposed to be the gatekeepers for these decisions, and without a DIP (yes, it is behind -preview, but that implies that this will eventually make it into the language proper). That is what I am calling "ridiculous". If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. You seem to have a wrong understanding of -preview. It doesn't even pretend to be an officially approved feature. I think this is what's been causing the confusion. Preview flags are what other compilers call "experimental". In fact, -preview is intended to predate a DIP or formal approval in other ways, because if you don't know the impact of a feature or usefulness, it's very hard to make an informed decision. This has the nice side effect that sometimes it becomes clear during an implementation that the idea as is unfeasible. implies that this will eventually make it into the language proper No, it doesn't. Okay, fair enough. Should this still not have had approval from either Walter or Atila before being merged in? Or is that not the case for changes behind -preview?
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 20:37:04 UTC, kinke wrote: On Thursday, 1 October 2020 at 18:29:14 UTC, Meta wrote: If W or A did approve it and I just wasn't aware, then I apologize and retract my objection. https://github.com/dlang/dmd/pull/11000#issuecomment-675605193 As far as I understand it, Andrei does not have any say over the direction of the language anymore since he stepped down. By "W or A" I meant "Walter or Atila".
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 16:19:48 UTC, Steven Schveighoffer wrote: On 10/1/20 10:36 AM, Meta wrote: On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Why was this added when we already have `auto ref`? Yes, it makes the function a template, but if `in` can automatically choose whether the variable is ref or not, then auto ref could easily do the same. There is a difference. `in` is choosing it based on the type, not whether it's an rvalue or lvalue. auto ref doesn't care whether it's an int or a 1k-sized struct, if it's an lvalue, it's ref, and if it's an rvalue, it's non-ref. This seems ridiculous to me. We now have ANOTHER way of asking the compiler to choose for us whether to pass by ref or by value, completely mutually exclusive of auto ref. Where was the DIP (apologies if I just didn't see it)? Did Walter approve this? How do we explain the difference between in and auto ref with (as Andrei would say) a straight face? Not only that, but every auto-ref parameter is another template parameter varying on the usage. So calling on an lvalue and rvalue will generate 2 separate mostly-identical functions. With -preview=in, only one function is generated per type. That's a QOI problem IMO. -Steve
Re: Release D 2.094.0
On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG wrote: Author here. The most complete way to know would be to read the changelog: https://dlang.org/changelog/2.094.0.html#preview-in The TL;DR is that, in addition to `const scope`, `in` now automatically behaves as `ref` when "it makes sense" such as large value types or presence of destructors / postblit (more details in the changelog!) and will accept rvalues, unlike other ref parameters. Why was this added when we already have `auto ref`? Yes, it makes the function a template, but if `in` can automatically choose whether the variable is ref or not, then auto ref could easily do the same.
Re: News on the D Blog: SAOC 2020 and More
On Tuesday, 23 June 2020 at 13:45:56 UTC, user1234 wrote: On Tuesday, 23 June 2020 at 12:00:30 UTC, Mike Parker wrote: On Tuesday, 23 June 2020 at 12:00:06 UTC, Mike Parker wrote: Symmetry Autumn of Code 2020 is on! My latest news post on the D Blog talks about that, some D Language Foundation finance updates, and whispers on the wind. And you can read all about it here: https://dlang.org/blog/2020/06/23/saoc-2020-and-other-news/ "Thanks are also in order to those who have supported the foundation through smile.amazon.com. Your purchases have brought over $288" That is interesting, that means that dlang users spent ~57,600.0 bucks on Amazon recently. And that's probably only a minority as people don't necessarily remembers that smile.amazon thing. I guarantee I spent at least $1000 on Amazon in 2019, and I've ordered a lot of stuff off there that I wouldn't normally, given the quarantine. I don't usually buy from amazon.com as I'm not in the US, but I did set mine to donate to the DLF when I do.
Re: DIP 1028 "Make @safe the Default" is dead
On Friday, 29 May 2020 at 12:22:07 UTC, Steven Schveighoffer wrote: On 5/29/20 12:53 AM, Walter Bright wrote: The subject says it all. If you care about memory safety, I recommending adding `safe:` as the first line in all your project modules, and annotate individual functions otherwise as necessary. For modules with C declarations, do as you think best. For everyone else, carry on as before. Thank you Walter. I'm sure this was not easy to decide, and is frustrating. It's unfortunate that the thrust of DIP1028 could not be saved and we had to throw out the whole thing for the one bad piece. It's not unfortunate - it's unnecessary. @safe by default is still a laudable and (seemingly) attainable goal. Why throw out the entire DIP instead of removing or altering the controversial aspect?
Re: Our HOPL IV submission has been accepted!
On Saturday, 29 February 2020 at 01:00:40 UTC, Andrei Alexandrescu wrote: Walter, Mike, and I are happy to announce that our paper submission "Origins of the D Programming Language" has been accepted at the HOPL IV (History of Programming Languages) conference. https://hopl4.sigplan.org/track/hopl-4-papers Getting a HOPL paper in is quite difficult, and an important milestone for the D language. We'd like to thank the D community which was instrumental in putting the D language on the map. The HOPL IV conference will take place in London right before DConf. With regard to travel, right now Covid-19 fears are on everybody's mind; however, we are hopeful that between now and then the situation will improve. That's great. Congratulations to the three of you and thanks for all the hard work on this.
Re: DIP 1027---String Interpolation---Format Assessment
On Thursday, 27 February 2020 at 18:07:19 UTC, Arine wrote:
On Thursday, 27 February 2020 at 09:34:23 UTC, Walter Bright
wrote:
On 2/26/2020 7:41 AM, Arine wrote:
Yah, what's unwanted about that?
1. unwanted extra string allocation
2. poor performance
3. doesn't work with printf
4. doesn't work with writef
5. non-default formats require extra temp strings to be
generated
Sometimes I wonder if you even bother to read posts to
understand.
This is a problem with YOUR DIP. Where you said, "what's wrong
with that, it's working as intended".
void CreateWindow(string title, int w = -1, int h = -1);
int a;
CreateWindow(i"Title $a");
// becomes
CreateWindow("Title %s", a);
That's what your fine with, that's what the DIP your wrote
would allow.
It's like you are just reading what you want to, instead of
actually understanding what people are saying. I'd have more
luck talking to a brick wall at the rate this thread is going,
jesus.
Come on, this isn't Reddit. Be more civil.
Re: Blog post on calling C from Python via D
On Wednesday, 26 February 2020 at 17:11:18 UTC, bachmeier wrote: There needs to be a variant of "mansplaining" modified for Python users. Agreed, and there also needs to be a variant of prison, modified for people who post dumb comments on Hacker News.
Re: Release D 2.090.0
On Wednesday, 8 January 2020 at 21:58:29 UTC, H. S. Teoh wrote: On Wed, Jan 08, 2020 at 09:43:05PM +, Meta via Digitalmars-d-announce wrote: [...] Deprecated module std.experimental.all was removed All symbols contained in Phobos can now be used with import std Maybe I'm wrong, but this seems like a bad idea to me (unless we're getting rid of std.experimental). I think you misunderstood what happened here. Originally std.experimental.all *was* the same thing as today's std/package.d; the only reason it was put in std.experimental was because it was still an experiment to see if importing all of Phobos is actually feasible in practice. Since it apparently worked quite well, it was moved from std/experimental/all.d to std/package.d. Ergo, import std.experimental.all != import std.experimental.*; rather, import std.experimental.all == import std.* in the past, and now we've just made it official by allowing you to write: import std; T Ah, I misunderstood. Thanks.
Re: Release D 2.090.0
On Tuesday, 7 January 2020 at 10:30:09 UTC, Martin Nowak wrote: Glad to announce D 2.090.0, ♥ to the 48 contributors. This release comes with the ability to convert lazy parameters to delegates, new intrinsics to force rounding to specific floating point precision, unittest builds that no longer execute main by default, a new GC.inFinalizer API, and various other changes. http://dlang.org/download.html http://dlang.org/changelog/2.090.0.html -Martin Deprecated module std.experimental.all was removed All symbols contained in Phobos can now be used with import std Maybe I'm wrong, but this seems like a bad idea to me (unless we're getting rid of std.experimental).
Re: interfaces and contracts - new pattern
On Tuesday, 3 December 2019 at 17:10:04 UTC, Meta wrote: On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote: In short use `in(false)` when you `override` a function to inherit the contract, unless you explicitly want to expand the input - which you shouldn't do when implementing an interface! Wrote about it in more details here: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through. destroy if i missed anything lol I thought this was a defect that was fixed a long time ago, where if the overriding function has no contract, it is implicitly given a "in (true)" contract, causing the contract of the overridden function to not be run. Am I mistaken as to what the defect was, or as to whether it was fixed, or both? I think this is the defect in question: https://issues.dlang.org/show_bug.cgi?id=6856 I see a PR in comment 35: https://github.com/dlang/dmd/pull/4200 But it was closed. However, Iain Buclaw created a successor to 4200: https://github.com/dlang/dmd/pull/7510 Which is still open, but Iain ran into stack corruption issues when compiling with the -m64 flag... and no further progress. So I guess it's just a matter of the bug not being fixed.
Re: interfaces and contracts - new pattern
On Monday, 2 December 2019 at 20:30:49 UTC, Adam D. Ruppe wrote: In short use `in(false)` when you `override` a function to inherit the contract, unless you explicitly want to expand the input - which you shouldn't do when implementing an interface! Wrote about it in more details here: http://dpldocs.info/this-week-in-d/Blog.Posted_2019_12_02.html i think this is a pretty cool little discovery, thanks too for the folks on irc for chatting it through. destroy if i missed anything lol I thought this was a defect that was fixed a long time ago, where if the overriding function has no contract, it is implicitly given a "in (true)" contract, causing the contract of the overridden function to not be run. Am I mistaken as to what the defect was, or as to whether it was fixed, or both?
Re: D code running on the Nintendo 3DS
On Sunday, 20 October 2019 at 06:06:48 UTC, TheGag96 wrote: Hi, all. I wanted to get into the world of 3DS homebrew, but I really didn't feel like coding in C or C++. So, through an effort of sheer will, I somehow got a hello world example written in D up and running, along with bindings for most of libctru and citro3d. https://github.com/TheGag96/3ds-hello-dlang Included are instructions on how to set this up (although it's pretty hacky). I imagine one could easily start writing Switch homebrew in D by following most of these steps as well. Once GCC 10 comes out with an updated GDC, it might become a pretty attractive alternative to C/++ for such projects if some work is put into bindings and stuff. Hope someone finds this interesting! Awesome work. I used to hack around on my original NDS and thought about maybe trying to get D working on it, but didn't have sufficient time or motivation. I'll definitely play around with this.
Re: Átila's Vision of D's Future
On Wednesday, 16 October 2019 at 09:46:49 UTC, aliak wrote: It's better to link straight to an item on hackernews as links on the front page disappear very fast. https://news.ycombinator.com/item?id=21257943 Cheers, - Ali HN has this (IMO) ridiculous policy of going to great lengths to prevent upvotes from people following a direct link to the post.
Re: Blog Post: Beating std::visit Without Really Trying
On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote: I was curious how C++17's std::variant compared to the options we have in D, like Algebraic and SumType, so I did a simple comparison of the generated assembly for each of them. You can read about it at the link below. And as you can probably guess from the title, D comes out ahead, in the end. https://pbackus.github.io/blog/beating-stdvisit-without-really-trying.html This is my first attempt at sharing something like this, so any comment or feedback is very much appreciated! I'm not sure if you're aware, but funnily enough, I also wrote an article[1] on std::variant vs. the D alternative that references Matt Kline's article on std::visit. It seems we're really making getting our money's worth from his article. I really enjoyed this - I think you're right in that it comes down to the complexity of implementation, and I suspect that C++ forced the developers of std::variant to choose between a usable API (usable, not good) and performance. I've been trying to communicate this major selling point of D to my coworkers, but it's a real uphill battle. I haven't even been able to convince them that built-in unit tests are a killer feature. As an aside, I actively use your sumtype library and for the most part find it very nice to use. Thanks for the great work. 1.https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/
Re: SAOC Experience Report: Porting a fork-based GC
On Monday, 22 July 2019 at 14:03:15 UTC, Mike Parker wrote: Francesco Mecca ha written an experience report for the D Blog about his SAOC 2018 project, porting Leandro Lucarella's old GC from D1 to D2. The blog: https://dlang.org/blog/wp-admin/post.php?post=2148=edit Reddit: > https://www.reddit.com/r/programming/comments/cgdk1r/symmetry_autumn_of_code_experience_report_porting/ A pull request to the D runtime was my final milestone. I was ready at the beginning of February, but I started to procrastinate. I’d had no previous communication with any of the reviewers and I was timorous about engaging with them. I spent a lot of time refactoring my code back and forth and delaying my pull request. At a certain point, I even considered abandoning the final milestone and providing the GC as a library. In the meantime, Rainer Scheutze published a threaded implementation of the mark phase that reduced the mark time in the GC and I lost faith in my project. This seems like a major failure in the process that this was allowed to happen - good work almost went abandoned. How can we prevent this in future SAoC/GSoC? Without knowing what the mentor did/didn't do, an obvious answer seems like there should be a follow-up to ensure that the work done is actually getting in to the compiler/runtime/etc. To go so far and trip right at the finish line is unfortunate (glad to see that a PR is now open).
Re: UPB D Summer School
On Wednesday, 17 July 2019 at 13:56:38 UTC, RazvanN wrote: Hello, Edi and myself are glad to announce that the first edition of the D Summer School that we organized for the students at the University Politehnica of Bucharest has just ended. We had 8 practical sessions and a hackathon, during which students had to work on their project a peer-to-peer client implementation using vibe.d). The students were lucky enough to actually have Andrei present them the "Design by Introspection" course. It goes without saying that they were thrilled. Our materials can be found here [1] if anybody is interested ( big thanks to Ali for his approval on basing our course on his book). Photos from the hackathon and Andrei's lecture can be found here [2]. We hope that by bringing D bootcamp courses to students we can raise awarness on D and increase its popularity and enlarge our community. We have encouraged the graduating students to participate to SAOC and also we are in discussions with some of them to initiate them into contributing to D. Cheers, RazvanN [1] https://ocw.cs.pub.ro/courses/dss/ [2] https://photos.google.com/share/AF1QipMRoQCmOcPh4E9nvn4hL4gGXeebPDYV9lSlH8lMhaZJmL4z6lt6QcCNs8iFvPkmxw?key=WUU3eXY3T05vR09HZlQ3X3ZBTXdidTBNQ3YzU01n That's awesome! Did the students earn actual credit hours for this bootcamp, or was it more interest-based?
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.
That's right. If you are wrapping code that is provided by a
third party, you should not mark any code as @trusted that makes
calls to the third party library. By doing this, you are saying
"any third party code I call is memory safe (source: dude just
trust me)". That may work in the case where this third party code
is set in stone and has been hand-audited by either you or the
maintainers (ideally both), but you're accepting any
implementation through a template argument. Doing this is
extremely dangerous, because you're making memory safety promises
about every single Allocator implementation in existence, in the
present AND for the future.
What you have to do is leave the functions that make these calls
unmarked (no @system, @trusted OR @safe), and allow the compiler
to infer it based on the whether the third party implementation
is @system/@trusted/@safe. That's the only sane way I can think
of to do this.
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 21:57:51 UTC, Meta wrote: I see what you're getting at. The compiler sees a slice type (i.e., Data[]), knows that it's GC-backed and thus has infinite lifetime, and concludes "the data you're trying to put in the store has too long of a lifetime". Should be "too _short_".
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 18:45:12 UTC, Jonathan M Davis wrote: On Friday, May 17, 2019 11:25:40 AM MDT Meta via Digitalmars-d-announce wrote: I don't want to *restrict* the lifetime of a heap allocation. I want the compiler to recognize that the lifetime of my original data is the same as the processed output, and thus allow my code to compile. It is my understanding that DIP 1000 really doesn't track lifetimes at all. Then why does the DIP, in addition to many of the error messages, use the word lifetime? I feel like I know less about DIP1000 and what it actually does than when I started. Can someone _please_ point me at any up to date documentation on this?
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 20:59:43 UTC, Mike Franklin wrote: On Friday, 17 May 2019 at 17:03:51 UTC, Meta wrote: If you look at `main` above, `rawData` has the same lifetime as the `dataRange` struct returned from `makeDataRange` and the queue returned from `copyToQueue`. True, there is some traditionally unsafe stuff happening in between; however, I thought that the point of adding all these annotations is to tell the compiler how the lifetimes of these objects propagate up and down the call stack, so that it can check that there will be no memory corruption. I'm not doing anything here that will result in a pointer to an expired stack frame, or otherwise cause memory corruption or use after free, or anything like that (*unless* I allow either `dataRange` or `result` to escape from the main function - which dip1000 correctly disallows). I don't think it does because `Queue!(T).store` has infinite lifetime beyond that of even `main`, at least as far as the compiler is concerned. I see what you're getting at. The compiler sees a slice type (i.e., Data[]), knows that it's GC-backed and thus has infinite lifetime, and concludes "the data you're trying to put in the store has too long of a lifetime". That makes sense, but slices don't necessarily have to be backed by the GC, so that seems like a faulty heuristic to me and possibly a vector for bugs. The compiler doesn't have enough information to know that `store` is tied to the lifetime of `Queue!(T)` (a.k.a `rawData`) and maybe that's a missing language feature. According to the DIP, "from a lifetime analysis viewpoint, a struct is considered a juxtaposition of its direct members." Who knows if that's still the case, because Walter has considerably changed how it works but has not documented those changes (IIRC, I may be wrong on that). That probably means that a Queue!T has an infinite lifetime, assuming that the compiler sees its T[] member as having an infinite lifetime. Maybe we should be allowed to declare aggregate fields as `scope` to convey that, but the compiler currently disallows it. That might be nice but would also probably cause a dramatic increase in complexity. I haven't thought through the possible ramifications of making a change like that.
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 05:27:02 UTC, Walter Bright wrote: On 5/16/2019 9:50 PM, Meta wrote: Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you. https://forum.dlang.org/post/laqjadtwrsdhdrqok...@forum.dlang.org As always, I recommend drastically reducing the example. It nearly always makes the actual problem emerge from all the noise. I'll try to reduce it further, but this example is already as reduced as I could make it while still having the same structure as my actual code.
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 17:05:21 UTC, ag0aep6g wrote: On 17.05.19 14:10, Meta wrote: Your explanation was fine, but I need a good solution, other than wrapping the array assignment in @trusted. I see. As far as I understand DIP 1000, it's not supposed to enable your use case without having to use `@trusted`. If this is true, then I have a big problem with DIP1000. This is an extremely common use case (copying memory from an inner scope with a limited lifetime to some store in an outer scope with a longer or infinite lifetime). DIP 1000 stops at heap allocations. It just assumes infinite lifetime for them. Yes, as per the DIP. If you want to restrict the lifetime of a heap allocation (in your case: tie it to the lifetime of a struct), you have to do it manually. I don't want to *restrict* the lifetime of a heap allocation. I want the compiler to recognize that the lifetime of my original data is the same as the processed output, and thus allow my code to compile.
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 05:32:42 UTC, Mike Franklin wrote:
On Friday, 17 May 2019 at 05:22:30 UTC, Mike Franklin wrote:
My assessment (which could be wrong):
`scope` and `return` only apply to pointers and `ref`s. If
you remove all `scope` and `return` attributes from the
function `push`, it works fine.
I consider it a bug that the compiler doesn't emit an error
when using attributes on types for which they are not intended.
Mike
Working example: https://run.dlang.io/is/TCP0td
That does compile, but I don't think that it's working the way I
want it to. I believe it only works because a GC-managed string
is used for the backing storage. If you change that to a static
array on the stack:
@safe
void main()
{
immutable(char)[16] rawData = "2 6 4 1 0 2 9 4 5";
auto dataRange = makeDataRange(rawData);
auto result = dataRange.copyToQueue();
import std.stdio;
writeln("The result of data processing is: ", result);
}
It will refuse to compile with this message:
Error: reference to local variable rawData assigned to non-scope
parameter input calling makeDataRange
`makeDataRange` is defined like this:
@safe
DataRange makeDataRange(string input)
{
auto range = DataRange(input);
return range;
}
So that static array is getting implicitly sliced, i.e., its
address is being taken. It's pretty obvious why `input` is not
being inferred as scope - it's being returned from
`makeDataRange`. However, when I try to manually annotate it with
return or return scope, I run into further errors:
DataRange makeDataRange(return scope string input)
{ ...etc. }
Error: scope variable input assigned to non-scope parameter
rawData calling DataRange.this
Error: scope variable dataRange assigned to non-scope parameter
data calling copyToQueue
So I continue annotating things with scope or return or return
scope whenever the compiler complains about it, going up through
the call chain until I arrive back at my original problem
mentioned in the post I linked.
(My original example with changes made going through this
exercise: https://run.dlang.io/is/uQDXG6)
This is why I say that I'm not sure that I quite understand
dip1000. I *thought* I did, but an example that seems like it
should clearly work (at least to me), does not.
If you look at `main` above, `rawData` has the same lifetime as
the `dataRange` struct returned from `makeDataRange` and the
queue returned from `copyToQueue`. True, there is some
traditionally unsafe stuff happening in between; however, I
thought that the point of adding all these annotations is to tell
the compiler how the lifetimes of these objects propagate up and
down the call stack, so that it can check that there will be no
memory corruption. I'm not doing anything here that will result
in a pointer to an expired stack frame, or otherwise cause memory
corruption or use after free, or anything like that (*unless* I
allow either `dataRange` or `result` to escape from the main
function - which dip1000 correctly disallows).
Re: Phobos is now compiled with -preview=dip1000
On Friday, 17 May 2019 at 05:22:31 UTC, ag0aep6g wrote: On 17.05.19 06:50, Meta wrote: Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you. https://forum.dlang.org/post/laqjadtwrsdhdrqok...@forum.dlang.org You don't like my explanation? https://forum.dlang.org/post/q6r4bf$2hu4$1...@digitalmars.com (same thread) Your explanation was fine, but I need a good solution, other than wrapping the array assignment in @trusted.
Re: Phobos is now compiled with -preview=dip1000
On Wednesday, 15 May 2019 at 08:32:09 UTC, Walter Bright wrote: On 5/15/2019 12:21 AM, Dukc wrote: Could be worth a try even without docs, but in the long run we definitely need some explaining. True, but I've tried fairly hard with the error messages. Please post your experiences with them. Walter, can I get you to take a look at this post I made a few months ago, and the contained example? I feel that this is a case that *should* definitely work, but I'm not sure if it can *currently* work - and so far, nobody else seems to be either, save for you. https://forum.dlang.org/post/laqjadtwrsdhdrqok...@forum.dlang.org
Re: DMD metaprogramming enhancement
On Friday, 26 April 2019 at 06:34:26 UTC, Simen Kjærås wrote: BTW, at least two people have promised money outside BountySource to have 5710 fixed: https://forum.dlang.org/post/gjzrklkxfmgjjdfor...@forum.dlang.org -- Simen And my offer still stands. Suleyman, do you have an email address I can contact you at to arrange payment?
Re: Phobos now compiling with -dip1000
On Saturday, 23 March 2019 at 05:04:58 UTC, H. S. Teoh wrote: Also, does it only apply to @safe code, so that I have to start annotating stuff with @safe in order to benefit from it? T As per the DIP and from my experience, yes.
Re: Containerize Your D Server Application
On Friday, 15 March 2019 at 04:43:21 UTC, Nick Sabalausky (Abscissa) wrote: On 3/14/19 8:38 AM, Mike Parker wrote: One of the items on my list of "things I'd like to do if I only had the time" is to create a Mud server with D and deploy it with Docker. Just for kicks. If I ever do get around to it, my ignorance of all things Docker will not be the time sink it could have been thanks to this latest post on the D Blog by Kai Nacke. The Blog https://dlang.org/blog/2019/03/14/containerize-your-d-server-application/ Reddit https://www.reddit.com/r/programming/comments/b0zqck/containerize_your_d_server_application/ Interestingly, this appears to be by far the best introduction to docker I've ever come across - and that's *including* docker's own vacuous website. Agreed; it's a good starter tutorial to familiarize someone with the basics. Great article Kai!
Re: Containerize Your D Server Application
On Thursday, 14 March 2019 at 18:02:31 UTC, Arun Chandrasekaran wrote: On Thursday, 14 March 2019 at 12:38:30 UTC, Mike Parker wrote: One of the items on my list of "things I'd like to do if I only had the time" is to create a Mud server with D and deploy it with Docker. Just for kicks. If I ever do get around to it, my ignorance of all things Docker will not be the time sink it could have been thanks to this latest post on the D Blog by Kai Nacke. The Blog https://dlang.org/blog/2019/03/14/containerize-your-d-server-application/ Reddit https://www.reddit.com/r/programming/comments/b0zqck/containerize_your_d_server_application/ Can we make dub generate the docker container as well? CMake can do that. The usage would be simply ``` dub build -b release dub build docker Couldn't you use `postBuildCommands` for that? https://dub.pm/package-format-json.html#build-settings
Re: New Fundraiser: D Forums Server
On Friday, 25 January 2019 at 19:14:31 UTC, Mike Parker wrote: On Friday, 25 January 2019 at 19:11:59 UTC, Mike Parker wrote: Flipcause donors are not American. Did you have trouble? If so, you can go to the donation page and use the PayPal link. Sorry: https://dlang.org/foundation/donate.html For anyone else donating via Paypal, it didn't go through the first two times and just spit out some generic error message (using Paypal One Touch; not sure if that matters). If you get an error when trying to donate through the link on the donation page, just keep trying until it succeeds. Only the successful payment will actually be charged to your Paypal account, so there's no worry of making multiple payments by mistake.
Re: D-lighted, I'm Sure
On Saturday, 19 January 2019 at 22:09:57 UTC, Ron Tarrant wrote: On Friday, 18 January 2019 at 19:55:34 UTC, Meta wrote: Great read Ron. Can I ask which town in Newfoundland it was where you stayed back in 1985? Sure. I was in St. Lawrence on the Burin Peninsula. Do you know it? Unfortunately (or fortunately?) not. I've spent a good deal of time exploring the western side of NFLD but have only visited Gander and St. John's on the eastern side.
Re: D-lighted, I'm Sure
On Friday, 18 January 2019 at 16:42:15 UTC, Ron Tarrant wrote: Just to set the record straight, I only had access to that Coleco Adam for the few weeks I was in that Newfoundland outport. Within a year, I too had my very own C-64 plugged into a monster Zenith console job. Remember those? I don't remember what I paid for a used C-64, but the Zenith 26" was $5 at a garage sale up the street and another $5 for delivery. Great read Ron. Can I ask which town in Newfoundland it was where you stayed back in 1985?
Re: Top Five World’s Most Underrated Programming Languages
On Friday, 18 January 2019 at 01:15:06 UTC, Bill Baxter wrote: Gotta laugh at Ruby being listed as "Underrated", though. --bb On Mon, Jan 14, 2019 at 12:25 PM Andrei Alexandrescu via Digitalmars-d-announce wrote: Of possible interest: https://www.technotification.com/2019/01/most-underrated-programming-languages.html I get the feeling that Ruby's popularity is waning with the rise of Node.js and the broad ecosystem of Javascript-based web application frameworks. At one time it probably came close to rivaling Python in popularity and sheer volume of new development, but I think that's firmly in the past now (not that it is dead, by any means).
Re: B Revzin - if const expr isn't broken (was Re: My Meeting C++ Keynote video is now available)
On Thursday, 17 January 2019 at 01:59:29 UTC, Walter Bright wrote: Bartosz Milewski is a C++ programmer and a Haskell fan. He once gave a presentation at NWCPP where he wrote a few lines of Haskell code. Then, he showed the same code written using C++ template metaprogramming. The Haskell bits in the C++ code were highlighted in red. It was like a sea of grass with a shrubbery here and there. Interestingly, by comparing the red dots in the C++ code with the Haskell code, you could understand what the C++ was doing. Without the red highlighting, it was a hopeless wall of < > :-) Since I mention Bartosz, I should link to his blog: https://bartoszmilewski.com/ It was an article on Bartosz's blog where I first found out about D. I think this was the first one: "The more things change, the more we need “immutable”" https://bartoszmilewski.com/2009/01/
Re: The New Fundraising Campaign
On Friday, 4 January 2019 at 16:21:16 UTC, Mike Parker wrote: On Friday, 4 January 2019 at 15:43:41 UTC, Meta wrote: Awesome; funding goal reached in a little less than 2 months. I didn't even get around to donating yet, so maybe I'll save it for the next one instead. On a related note, D really needs a merch shop. I don't think I'm the only one that wants a shirt or mug with (a|the) D logo on it, or Dman. There's an entire industry that's popped up to make paraphernalia sales far easier in the wake of Youtube/Deviantart/etc. which is geared toward community-based projects similar to D. It's coming. Can't wait!
Re: The New Fundraising Campaign
On Friday, 4 January 2019 at 10:30:07 UTC, Martin Tschierschke wrote: On Saturday, 10 November 2018 at 16:09:12 UTC, Mike Parker wrote: [...] Please read the blog post for more details: https://dlang.org/blog/2018/11/10/the-new-fundraising-campaign/ https://www.flipcause.com/secure/cause_pdetails/NDUwNTY= $3,014 Raised of $3,000 Goal 41 days left 51 Supporters Cool, what a wonderful start to the year 2019! A big thank you to all pushing the development of D with money and time! What next Mike? Awesome; funding goal reached in a little less than 2 months. I didn't even get around to donating yet, so maybe I'll save it for the next one instead. On a related note, D really needs a merch shop. I don't think I'm the only one that wants a shirt or mug with (a|the) D logo on it, or Dman. There's an entire industry that's popped up to make paraphernalia sales far easier in the wake of Youtube/Deviantart/etc. which is geared toward community-based projects similar to D.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 20:44:28 UTC, Dukc wrote: On Tuesday, 11 December 2018 at 15:34:28 UTC, Simen Kjærås wrote: I believe a reasonable case can be made for .! for UFCS - it's currently invalid syntax and will not compile, and ! is the symbol we already associate with template instantiation: alias memberFunctions = __traits(allMembers, T) .!staticMap!Member .!Filter!(isSomeFunction); -- Simen Perhaps. I also think that it might be good if types could be results of compile-ime expressions, including ufcs expressions (so that 42.typeof would become legal, meaning an int). I vaguely remember a very ancient version of D that had .typeof instead of typeof(). This might've been D1... the details are fuzzy.
Re: Blog post: What D got wrong
On Tuesday, 11 December 2018 at 10:45:39 UTC, Atila Neves wrote: A few things that have annoyed me about writing D lately: https://atilanevesoncode.wordpress.com/2018/12/11/what-d-got-wrong/ Template lambdas and better eponymous template syntax are the two big ones that I would really like. It's very painful not having them in code that makes heavy use of metaprogramming.
Re: Copy Constructor DIP and implementation
On Sunday, 23 September 2018 at 01:08:50 UTC, Jonathan M Davis wrote: @implicit is just there because of the fear of breaking a theoretical piece of code that's going to be extremely rare if it exists at all and in most cases would continue to work just fine even if it did exist. - Jonathan M Davis I somewhat agree with this argument, but overall I hate this attitude of "we should just make the change because it *probably* won't break any code", and then bonus points for "code that does this is wrong anyway so we shouldn't care if we break it". I've already been burned by that a couple times using D, and I imagine heavy corporate users with large code bases have many more problems with this.
Re: Copy Constructor DIP and implementation
On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote: Hello everyone, I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it! Thanks, RazvanN [1] https://github.com/dlang/DIPs/pull/129 [2] https://github.com/dlang/dmd/pull/8688 If @implicit is the contentious part of this DIP, maybe it would be a good idea for us to instead use a `pragma(copyCtor)` or the like to avoid having to add another attribute while preserving backward-compatibility. Like @implicit, it's very easy to turn existing constructors into copy constructors just by adding the pragma, and they can be added to code with impunity because even older versions of the compiler will just ignore pragmas they don't recognize.
Re: dpp now compiles julia.h headers
On Friday, 13 July 2018 at 19:02:56 UTC, Laeeth Isharc wrote: Atila Neves' d++ now compiles julia.h. Modulo bugs this makes it possible to embed Julia in D (and probably the other way around, but I have not tried). https://github.com/kaleidicassociates/juliad Very cool. It's awesome to be able to directly #include C++ headers.
Re: Blogpost about the T.init problem
On Wednesday, 11 July 2018 at 07:35:24 UTC, FeepingCreature wrote: On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote: Then just stick it in a Nullable. No explicit .init needed. To clarify this point some more, since on reflection it's ambiguous: you might well say that "well yeah, the default constructor returns an invalid value, no shit it breaks." The semantics of Nullable are weird here though - Nullable!S constructs an S while pretending to not contain an S. The deeper problem is that there is straight up *no way* to implement Nullable correctly in a way that lets it handle types with @disabled this(); I hate to say I told you so, but... https://github.com/dlang/phobos/pull/5855#issuecomment-345783238 Just joking, of course =) Nullable has needed to be completely overhauled for a long time because it was only really designed with POD types in mind.
Re: Blogpost about the T.init problem
On Tuesday, 10 July 2018 at 13:41:56 UTC, FeepingCreature wrote: I've written up a short blogpost about the T.init issue. It is not very enthusiastic. https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43 Related links: https://github.com/dlang/phobos/pull/6594 problem with T.init and toString https://github.com/dlang/phobos/pull/6619 Nullable can't work with types where T.init violates invariants https://github.com/dlang/dmd/pull/8462 A somewhat sketchy PR to disable invariant on struct ~this D's contract programming features have been around since D1 and haven't really been updated to work with newer D2 features (this is no excuse IMO; these issues should have been addressed long ago). My opinion is that it's a vicious circle; D's contract programming features are underutilized, thus nobody cares enough to put effort into ironing out the bugs, thus contract programming in D is buggy and interacts poorly with other language features, thus D's contract programming features are underutilized. IMO, if you don't have the knowledge, desire, or time to fix them, the next best thing to do is write articles like these bringing some attention to the various defects of contract programming in D, and/or write DIPs to propose ways to fix it.
Re: How an Engineering Company Chose to Migrate to D
On Wednesday, 20 June 2018 at 13:21:30 UTC, Mike Parker wrote: If you saw Bastiaan Veelo's DConf 2017 presentation, you'll know that his employer was evaluating D as a candidate for migrating their code base away from Extended Pascal. Recently, the decision was made and D was the coice. In this post, Bastiaan tells the story of how that came to be and how they'll be moving forward. The blog: https://dlang.org/blog/2018/06/20/how-an-engineering-company-chose-to-migrate-to-d/ Reddit: https://www.reddit.com/r/programming/comments/8si75b/how_an_engineering_company_chose_to_migrate_to_d/ Man, proggit can be savage with the criticism. Every Nim/Rust and the one Ada programmer have come out of the woodwork to make sure you know their language supports nested functions. You've seemingly got to be an expert in every current language to write a comparison article that suggests D may have some advantages.
Re: Looks like Digital Mars C++ is on the front page of HN at the moment!
On Thursday, 24 May 2018 at 20:10:24 UTC, Walter Bright wrote: Maybe. I was thinking about using DasBetterC for the DMC runtime library instead of C :-) That would be very cool Walter.
Re: Funding for code-d/serve-d
On Saturday, 5 May 2018 at 11:21:29 UTC, Mike Parker wrote: This morning at the Hackathon I announced that the D Foundation is raising money for code-d/serve-d, the plugin for Visual Studio Code and its companion Microsoft Language Server Protocol implementation for D. We've set up a goal of $3000 at our Open Collective page: https://opencollective.com/dlang# At the top of the page, you'll see our current balance, the projected balance at the end of the year based on the current level of monthly donations, and the goal of $3000 on the far right. We're sitting at just over $1100 as I write this, which means we're almost halfway there already. We encourage those of you who use Webfreak's VS Code plugin to contribute whatever you can in order to fund its development, especially if you want to see it improve. An important point is that development on serve-d can ultimately benefit not just code-d, but other IDE and editor plugins where it may be used. If we reach $2700 within 30 days, the D Foundation will throw in the remaining $300 and we'll let Webfreak get to work. If this proves successful, we hope to use future goals to fund development across the D ecosystem. Some of our targets will be driven by the results of the recent State of D Survey and others will be driven by other concerns. If you are interested in helping to move the state of D development forward, please consider contributing! I'm a little unclear how OpenCollective works. Do you have to specifically donate to this goal, or does every donation made just go to that? Furthermore, I don't really want to create an OpenCollective account just to donate; I'd prefer to do it directly with my Paypal. Is that possible? Also, does anyone have an image of the supporter t-shirts? If possible I want to donate an amount to get one of those.
Re: DConf 2018 Livestream
On Thursday, 3 May 2018 at 00:32:07 UTC, Ali Çehreli wrote: On 05/02/2018 04:01 PM, Juan wrote: On Wednesday, 2 May 2018 at 17:47:43 UTC, Ali Çehreli wrote: https://www.youtube.com/watch?v=HvqsUO77FGI Ali Hi Ali, Thanks for the link, and by the way could you share the link for the first 3 talks? Taking Advantage of D Within Existing C Code Bases Walter Bright A Decade of D @ Funkwerk Mario Kröplin, Stefan Rohe Exploring D via Benchmarking of eBay's TSV Utilities Jon Degenhardt It looks like that's not available on their channel any more. It looks like I'm just lucky to have posted the link above to the Turkish forum, where I copied it back. Do others know the link to the first 3 talks? Ali There was some talk during the stream of them being lost due to a LAN failure. I'm not sure if that's all 3 talks or just the first.
Re: std.variant Is Everything Cool About D
On Wednesday, 4 April 2018 at 11:40:58 UTC, Steven Schveighoffer wrote: On 4/3/18 11:29 PM, Meta wrote: Also, with Nullable your data is guaranteed to not be boxed, whereas it's a possibility with Variant/Algebraic if the types you're working with are large enough. Not with Algebraic. -Steve Ah yes, you're right. Thanks Steven. This exact thing came up in the Reddit thread from a few days ago.
Re: std.variant Is Everything Cool About D
On Wednesday, 4 April 2018 at 03:09:22 UTC, helxi wrote: On Thursday, 29 March 2018 at 14:10:39 UTC, Mike Parker wrote: Jared Hanson (a.k.a Meta and MetaLang around these parts) was inspired by an article titled "std::visit is everything wrong with modern C++" to contrast it with D's std.variant.visit. The result is this well-written post for the D Blog. The blog: https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/ Reddit: https://www.reddit.com/r/programming/comments/881hmi/stdvariant_is_everything_cool_about_d/ What is the difference between https://dlang.org/phobos/std_typecons.html#Nullable and Algebraic!(T, typeof(null))? Nullable is specifically specialized to this particular use-case and only has to store a boolean in addition the wrapped data (and there is a template "overload" that allows you to specify a specific value for the `null` state, which removes even that boolean). Also, with Nullable your data is guaranteed to not be boxed, whereas it's a possibility with Variant/Algebraic if the types you're working with are large enough.
Re: std.variant Is Everything Cool About D
On Saturday, 31 March 2018 at 17:36:30 UTC, Pjotr Prins wrote: Great blog. Thanks. Thank you, glad you liked it.
Re: std.variant Is Everything Cool About D
On Friday, 30 March 2018 at 13:44:50 UTC, Meta wrote: I've submitted it to Hacker News as well (looks like someone posted it yesterday, but it only got 1 vote and there was no discussion, so I figured that was grounds enough for resubmission). If you've got an account, please give me your meaningless internet points. https://hn.algolia.com/?query=std.variant%20is%20everything%20cool%20about%20d=byDate=0=custom=story=1522368000=1522454400 And it seems they're still not biting. Looking at the front page, I can't believe how few actual programming or startup-related submissions there are. https://imgur.com/a/hFlbs
Re: std.variant Is Everything Cool About D
On Thursday, 29 March 2018 at 14:10:39 UTC, Mike Parker wrote: Jared Hanson (a.k.a Meta and MetaLang around these parts) was inspired by an article titled "std::visit is everything wrong with modern C++" to contrast it with D's std.variant.visit. The result is this well-written post for the D Blog. The blog: https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/ Reddit: https://www.reddit.com/r/programming/comments/881hmi/stdvariant_is_everything_cool_about_d/ I've submitted it to Hacker News as well (looks like someone posted it yesterday, but it only got 1 vote and there was no discussion, so I figured that was grounds enough for resubmission). If you've got an account, please give me your meaningless internet points. https://hn.algolia.com/?query=std.variant%20is%20everything%20cool%20about%20d=byDate=0=custom=story=1522368000=1522454400
Re: std.variant Is Everything Cool About D
On Thursday, 29 March 2018 at 14:10:39 UTC, Mike Parker wrote: Jared Hanson (a.k.a Meta and MetaLang around these parts) was inspired by an article titled "std::visit is everything wrong with modern C++" to contrast it with D's std.variant.visit. The result is this well-written post for the D Blog. The blog: https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/ Reddit: https://www.reddit.com/r/programming/comments/881hmi/stdvariant_is_everything_cool_about_d/ Unfortunately, this turned out to be the worst possible day for me to try to actively monitor the thread and respond to questions. I'm surprised that people latched onto my little quip about C++ using the name variant for a tagged union.
Re: Draft Review DIP: Enum and Function Parameter Attributes
On Wednesday, 21 March 2018 at 05:57:47 UTC, Mike Parker wrote: On Wednesday, 21 March 2018 at 02:26:02 UTC, Meta wrote: Low hanging fruit: Thanks for the feedback, but Draft Review comments should go in the PR thread. I'll add a link over there to the post, but when you get a chance, it would help to paste your remarks into a comment there. Thanks! Whoops, sorry.
Re: Draft Review DIP: Enum and Function Parameter Attributes
On Wednesday, 21 March 2018 at 00:12:43 UTC, Mike Parker wrote:
As it stands, this DIP [1] is currently the candidate to become
DIP 1013. Any an all feedback for Draft Review is welcome.
Please read the intent [2] behind the Draft Review before
participating. Thanks!
[1] https://github.com/dlang/DIPs/pull/105
[2]
https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#draft-review
Low hanging fruit:
IMO, the abstract is not right. This may differ between
institutions, but the way I was taught to write abstracts is that
they should be a condensed summary of what your document is
about. Think of it as an overview so someone can quickly read it
to get an idea of what you'll be talking about through the rest
of the document.
It is currently not possible to attach attributes to both enums
and function parameters
Again, probably a matter of taste, but I think this reads better
as "...not possible to attach attributes to enums _or_ function
parameters..."
Attributes and user-defined attributes (UDA) serve as a means
to provide extra meta data
I believe it's usually written "metadata", as one word. See this
from Google Books' Ngram viewer:
https://books.google.com/ngrams/graph?content=meta+data%2Cmetadata_insensitive=on_start=1965_end=2000=15=3=_url=t4%3B%2Cmeta%20data%3B%2Cc0%3B%2Cs0%3B%3Bmeta%20data%3B%2Cc0%3B%3BMeta%20Data%3B%2Cc0%3B%3BMeta%20data%3B%2Cc0%3B%3BMETA%20DATA%3B%2Cc0%3B.t4%3B%2Cmetadata%3B%2Cc0%3B%2Cs0%3B%3Bmetadata%3B%2Cc0%3B%3BMetadata%3B%2Cc0%3B%3BMETADATA%3B%2Cc0
What can be said for why attributes were included as a feature
in D can also be said for why they should be extended to enums
and function parameters.
This sentence reads very awkwardly.
It is benefitial to provide extra meta data about a symbol that
can be used at compile-time.
You assert this but don't provide any logical argument or
examples of why it's useful (yes, I know you have examples below).
Most of the framework for attributes already exist and it would
just be...
Should be "most of the framework for attributes already
_exists_". Also, it's more a matter of personal taste, but I
would suggest an Oxford comma between "exist" and "and" in that
sentence.
Allow additional meta information (attributes) to be attached
with enums and functions parameters
Should be "...to be attached _to_ enums and _function_
parameters..."
...and it would just be a matter of extending that into the
respective symbols...
I think that this should be "to" as opposed to "into".
A current solution for applying an UDA...
Should be "_a_ UDA".
A solution for applying the deprecation attribute to an enum
member can be done by
reimplementing an enum as a structure with static enums. This
allows the attribute to be
placed with the desired enum member. While still allowing for
any existing code that
simply used an enum before hand to still work accordingly, as
if the struct was an enum.
enum SomeEnumImpl
{
none = -1,
actualValue2 = 2,
actualValue3 = 3,
}
struct SomeEnum
{
SomeEnumImpl x;
alias this x;
deprecated("reason for deprecation")
static enum deprecatedValue0 = none;
deprecated("reason for deprecation")
static enum deprecatedValue1 = none;
}
AFAIK `static` on an enum does nothing. Also, `enum
deprecatedValue0 = none` should qualify `none`, i.e.,
`SomeEnumImpl.none`.
Allowing to deprecate enums which should not be used anymore as
seen here:
This language is sloppy. It could be better written as
"Deperecating individual enum values" or something similar. Also,
this is just a copy of the same example from the "Existing
Solutions" section; I don't think the whole bit with creating a
struct with enum members, etc. really needs to be repeated.
All of these examples except the first seem to rely on function
parameter attributes being accessible outside that function. If I
recall correctly, this caused some controversy in past discussion
which must be addressed in this DIP.
Re: OT: Coffee prices [was Re: The D Language Foundation at Open Collective]
On Thursday, 15 March 2018 at 13:10:57 UTC, Seb wrote: (though in Germany that's often cheaper than one cup of coffee) On second thought, maybe I'll move to Germany. I'll suffer expensive coffee in exchange for cheap beer ;-)
Re: The D Language Foundation at Open Collective
On Wednesday, 14 March 2018 at 12:00:42 UTC, Seb wrote: Yeah, the idea is that 5$ a month isn't much (~ one coffee in most countries), but if 500 people donate one coffee a month, you get the entire coffee machine with a warp engine :) Sorry to derail, but I had to ask: where does 1 coffee (even extra large) cost $5 USD? Let me know so I know to never move there.
Re: Vision document for H1 2018
On Tuesday, 13 March 2018 at 01:23:39 UTC, psychoticRabbit wrote: hey... I have 25+ years experience as a systems administator. i.e I'm very, very used to doing very complex things. complex, is my day at the office. But even I couldn't get my head around how to compile D from source on Windows ;-) I do have it compling just fine on my freebsd system, and multiple different linux's I use. But Windows? Forget it. Someone will need to explain in detail how that is actually done - I no longer have the patience for working that one out. As a counterpoint, I _did_ manage to compile DMD, Phobos and Druntime on Windows as a lowly university student using only the instructions from the wiki, and I'm no genius. It _is_ possible and not very difficult as long as you follow the instructions to the letter. Of course this was also before you needed to have HOST_DC defined in your path, and the repo layout was a bit different, but it's not an insurmountable problem. And if you run into problems, you can come here or go on IRC to ask for help.
Re: Vision document for H1 2018
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu wrote: Hello, the vision document of the Founation for the first six months of 2018 is here: https://wiki.dlang.org/Vision/2018H1 In addition to the expected items, we have a new top-level priority - locking down the language definition. This is in recognition of the fact that we need a precise definition of the language going forward. Thanks, Andrei Establish the DIP as a clear, solid means to get a language enhancement going Very excited about this one. Hopefully some faith can be restored in the process.
Re: Article: Why Const Sucks
On Tuesday, 6 March 2018 at 10:02:10 UTC, Radu wrote: On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote: Here's something I wrote up on const: http://jmdavisprog.com/articles/why-const-sucks.html I suppose that it's not exactly the most positive article, but I feel that it's accurate. - Jonathan M Davis Spot on article, and touches some of my pain points when working with const/immutable structs. Recently I tried to create a ref-counted immutable struct, oh boi... This later use case is of tremendous value for safe concurrent code that's @nogc. Unfortunately I couldn't find a way to make it work efficiently and in the same time not look like a disgusting hack. I suspect a possible solution is to allow immutable(const) postblit overloads as well as immutable dtors that will act as an escape hatch for unsafe work and in the same time provide hints that you are operating on an immutable(const) this. AFAIK this is a solved problem. Dicebot (not sure if he's still around) had initially proposed it: store the reference count just before the immutable piece of memory. | ref count |object/struct| In fact, Andrei added a new allocator to std.experimental.allocator to support this: https://dlang.org/library/std/experimental/allocator/building_blocks/affix_allocator/affix_allocator.prefix.html
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 00:39:08 UTC, psychoticRabbit wrote: On Thursday, 1 March 2018 at 21:49:31 UTC, Jonathan M Davis wrote: That being said, I think that it's a given that we need to make breaking changes at least occasionally. The question is more how big they can be and how we go about it. Some changes would clearly be far too large to be worth it, whereas others clearly pay for themselves. The harder question is the stuff in between. ... - Jonathan M Davis Personally. I think the D1..D2 transistion was great idea. I think D2..D3 should follow the same principle. D1 -> D2 nearly killed D (can't remember which, but it was either Walter or Andrei that have said this on multiple occasions). A D2 -> D3 transition might generate a lot of publicity if done very carefully, but more than likely it would just put the nails in the coffin for good and destroy all the momentum D has built up over the past 3 years (I feel like 2015 was a big turning point where D finally got back on peoples' radars).
Re: An optional/maybe type with range semantics
On Monday, 26 February 2018 at 20:04:14 UTC, aliak wrote: Meta: Is this your stuff btw? -> https://github.com/skirino/d-option :) me thinks I may have gotten some inspiration from you if so, so thanks! Nope. I'm MetaLang on Github.
Re: An optional/maybe type with range semantics
On Monday, 26 February 2018 at 15:21:27 UTC, Dukc wrote: Honestly, I fail to see the idea behind this... Ranges do not need any nullability on top of them IMO, because an empty range can already be used to denote a kind of "default", "unassigned" or "nothing" - type of value. On the other hand I may just be missing something... do you have an example use case for this where phobos ranges would be a bad option? Anyway, good effort. The idea is to treat `Option!T` as a regular input range so it can be used with all the regular range algorithms without special casing it. You're right in that the null/non-null dichotomy is equivalent to the notion of a range being empty or non-empty.
Re: run.dlang.io - a modern way to run D code
On Wednesday, 13 December 2017 at 00:54:07 UTC, H. S. Teoh wrote: On Wed, Dec 13, 2017 at 12:50:40AM +, Meta via Digitalmars-d-announce wrote: On Tuesday, 12 December 2017 at 18:37:38 UTC, Seb wrote: > After it has been in stealth mode for quite a while, I'm > happy to announce that there's https://run.dlang.io [...] This is a real life saver considering dpaste is blocked at work. It gets very tedious having to create a file, invoke the compiler, and run it in 3 separate steps just to test out some quick snippet. Can't you just do: rdmd --eval='' ? T This works for short snippets that are one-off but I usually like to play around with a piece of code and that gets tedious as well trying to edit it on the command line. Not to mention trying to get quotation marks to match up and escape them correctly.
Re: run.dlang.io - a modern way to run D code
On Tuesday, 12 December 2017 at 18:37:38 UTC, Seb wrote: After it has been in stealth mode for quite a while, I'm happy to announce that there's https://run.dlang.io === Features === * Color-highlighted DMD errors * Format source code with dfmt * Generate a short URL for link sharing * Import/Export to GitHub Gist * Typical key shortcuts like CTRL+Enter -> Run * Build cache for fast execution of common examples (e.g. the ones on front page of dlang.org) * Usable on your phone * Integrated with dlang.org (you can open any example on dlang.org in run.dlang.io by clicking the right arrow button) * Integrated with tour.dlang.org (you can open any example on the DTour in run.dlang.io by clicking on the "Export" button) === Supported D Compilers === * Latest DMD nightly * Latest DMD beta * Latest DMD * Latest LDC beta * Latest LDC The Docker images are rebuilt every day automatically. === Running DUB packages === Via "Add library" DUB packages can be added to the build. Currently only a whitelist of packages is allowed. Examples: mir: https://run.dlang.io/is/FIc6rd mir-algorithm: https://run.dlang.io/is/3pNRH8 === DReg === When I watched CyberShadow's Bugzilla cruise [1] I spotted this amazing tool dreg [2] and it's not that hard to build a docker image [3] for it and make it available for everyone, s.t. no setup is required. Dreg allows running old versions of the D compiler in parallel and compares their output. However, it's a lot easier to show than to explain: https://run.dlang.io/is/ckNT9i https://run.dlang.io/is/UZhQDh Currently all versions from 2.060 up to the latest greatest 2.077.1 are run, so the execution will take a bit longer than a single run. [1] https://youtu.be/qpUTvMokTCs [2] https://github.com/CyberShadow/misc/blob/master/dreg.d [3] https://github.com/dlang-tour/core-dreg === Source code & report issues === Please don't hesitate to open issues or submit pull requests: -> https://github.com/dlang-tour/core (it uses Vibe.d) This is a real life saver considering dpaste is blocked at work. It gets very tedious having to create a file, invoke the compiler, and run it in 3 separate steps just to test out some quick snippet.
Re: LDC 1.7.0-beta1
On Sunday, 10 December 2017 at 17:33:34 UTC, kinke wrote: Hi everyone, on behalf of the LDC team, I'm glad to announce the first beta for LDC 1.7. The highlights of this version in a nutshell: * Based on D 2.077.1. * Catching C++ exceptions supported on Linux and Windows. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.7.0-beta1 Thanks to all contributors! Very impressive. I'm curious, is the work done to catch C++ exceptions separate from Walter's previous efforts with dmd, or does it build on his work in some way?
Re: Meet our new scholarship recipient, Alexandru Jercaianu
On Monday, 2 October 2017 at 17:04:30 UTC, Andrei Alexandrescu wrote: Hello everyone, it is my pleasure to announce that Alexandru Jercaianu, a starting MSc student at University "Politehnica" Bucharest, is recipient of our scholarship. Alex is up and running working on his bootcamp tasks. Currently he is attempting unsuccessfully to post in our general group :o). Please join me in welcoming Alexandru! Andrei Welcome, Alexandru! So does this bring to total number of scholarship recipients up to 4? How many are planned?
Re: Beta 2.076.0
On Saturday, 26 August 2017 at 12:32:54 UTC, Martin Nowak wrote: On 08/18/2017 02:58 PM, Martin Nowak wrote: First beta for the 2.076.0 release. Second beta out now! http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.076.0.html Compiler changes AVX2 was added as -mcpu=avx2 architecture. Fix Issue 17697 - Ddoc: automatically highlight URLs outside of macro arguments **Implement DIP 1010 - Static foreach** Awesome.
Re: D as a Better C
On Wednesday, 23 August 2017 at 14:01:30 UTC, jmh530 wrote: On Wednesday, 23 August 2017 at 13:12:04 UTC, Mike Parker wrote: To coincide with the improvements to -betterC in the upcoming DMD 2.076, Walter has published a new article on the D blog about what it is and why to use it. A fun read. And I'm personally happy to see the love this feature is getting. I have a project I'd like to use it with if I can ever make the time for it! The blog: https://dlang.org/blog/2017/08/23/d-as-a-better-c/ Reddit: https://www.reddit.com/r/programming/comments/6viswu/d_as_a_better_c/ Great piece. It might be useful to beef up the documentation on some of the things that betterC changes. For instance, here http://dlang.org/dmd-windows.html#switch-betterC links to TypeInfo, which has like one line of explanation of what it's for, and ModuleInfo isn't linked to at all (and I'm still a little unclear on what that does). Walter has made a PR to improve the ModuleInfo documentation: https://github.com/dlang/druntime/pull/1906
Re: I'm the new package maintainer for D on ArchLinux
On Wednesday, 9 August 2017 at 20:42:48 UTC, Wild wrote: Hi everyone, The D packages for ArchLinux has been orphaned since Dicebot stepped down as the maintainer and no one else stepped up. So I decided to step up and apply to become a Trusted User, and I got accepted yesterday[1]. So from now on I will be the one who maintains all the D packages (in the [community] repo), and it will be my job to fix them if they break. Thanks for stepping up Dan.
Re: d_to_html.d
On Saturday, 5 August 2017 at 19:07:50 UTC, WebFreak001 wrote:
Hi, I made a D to HTML generator which is basically diet, but
fully using the D compiler as generator and not some
complicated parser, etc. Here an example what you pass in:
string page = html(
head(
title("wtf is this"),
style(
html(
font-family = "Roboto",
background = 0xEFEFEF
),
div.content(
max-width = 800.px,
margin = auto_,
margin-top = 32.px,
box-shadow = "0 2px 5px rgba(0, 0, 0, 0.3)",
background = white,
padding = 32.px
),
div.footer(
text-"align" = center
)
)
),
body(
div.content(
h1("The most crappy HTML generator ever"),
div.teaser(
p("Super fast")
),
hr,
p("Reasons why you should use d_to_html:"),
ul(
li("TODO: no reason yet") * 5
)
),
div.footer(
p(raw!" 2017 webfreak.org")
)
)
).toString;
Which generates: https://i.webfreak.org/fStzn0.html
Full source:
https://gist.github.com/WebFreak001/6a1916779e48898c7ababc47a3113829
Though some things (like min and max for example) won't work
correctly, so you need to manually write `attr!"min" = 4` if
you wanted to add that to an input element.
btw this is just a joke project, it's totally abusing operator
overloading just to show what is possible with it. The idea
came up in Wild's discord server, you can join us too, we have
a programming and a dplug channel:
https://discordapp.com/invite/bMZk9Q4
Just because you *can* do something, it doesn't mean you
*should*. ;-)
Very creative, I don't think reading source code has ever made me
chuckle before.
Re: DMD library available as DUB package
On Tuesday, 18 July 2017 at 12:07:27 UTC, Jacob Carlborg wrote:
During the dconf hackathon I set out to create a DUB package
for DMD to be used as a library. This has finally been merged
[1] and is available here [2]. It contains the lexer and the
parser.
A minimal example:
#!/usr/bin/env dub
/++ dub.sdl:
name "dmd_lexer_example"
dependency "dmd" version="~master"
+/
void main()
{
import ddmd.lexer;
import ddmd.tokens;
import std.stdio;
immutable sourceCode = "void test() {} // foobar";
scope lexer = new Lexer("test", sourceCode.ptr, 0,
sourceCode.length, 0, 0);
while (lexer.nextToken != TOKeof)
writeln(lexer.token.value);
}
[1] https://github.com/dlang/dmd/pull/6771
[2] http://code.dlang.org/packages/dmd
Nice, I was not aware that DMD as a library was so close to being
a reality.
Re: Inside D's GC blog article on hacker news front page
On Tuesday, 20 June 2017 at 11:59:57 UTC, Gary Willoughby wrote: Inside D's GC blog article currently No.3 on hacker news Here's the article, visit hacker news to read the comments. http://olshansky.me/gc/runtime/dlang/2017/06/14/inside-d-gc.html Impressive. The article managed to blow up on both HN *and* Reddit. Usually it seems to be just one or the other.
Re: DIP 1003 (Remove body as a Keyword) Accepted!
On Friday, 2 June 2017 at 14:17:10 UTC, Mike Parker wrote: Congratulations are in order for Jared Hanson. Walter and Andrei have approved his proposal to remove body as a keyword. I've added a summary of their decision to the end of the DIP for anyone who cares to read it. In short: * body temporarily becomes a contextual keyword and is deprecated * do is immediately allowed in its place * body is removed and do replaces it fully Congratulations, Jared! https://github.com/dlang/DIPs/blob/master/DIPs/DIP1003.md Well, guess I'm a bit late to the party but I just wanted to echo the sentiment that Mike has done a great job stepping up to oversee the DIP process. All I had to do was write it, and he did the rest. I'm very pleased with how smoothly things went and how easy Mike made the whole process. Thanks Mike!
Re: Trip notes from Israel
On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote: What hurts us the most and stands like a sore thumb is the occasional use of abusive language. We need to stop that. Interesting. Are there any examples you're willing to provide? It seems to me that stuff like this is immediately condemned, but only if it comes from somebody who is new or doesn't post here often. There's been a few cases I can think of where a regular contributor/frequent poster said something that I'd consider "abusive language" and it's allowed to slide without (public) reprimand or apology, but again it's not completely clear what you have in mind when you say "abusive language".
Re: Terminix renamed to Tilix
On Tuesday, 21 March 2017 at 12:17:58 UTC, Gerald wrote: On Tuesday, 21 March 2017 at 08:22:13 UTC, Andrea Fontana wrote: So, is Ubuntu Budgie going to use Tilix as default? [1] That's a big news for D imo :) https://github.com/UbuntuBudgie/budgie-desktop-environment/issues/33 That's their plan, they haven't asked me about it specifically but it's an interesting choice. I'm glad it's one of the smaller spins of Ubuntu, I don't think I could keep up with support cases if a larger one adopted Tilix as the default terminal. Thanks for the reminder about this, I posted a note letting them know about the name change. Wow, congratulations!
Re: Moonshot: a DMD fork that outputs Lua
On Tuesday, 21 February 2017 at 12:45:47 UTC, Mithun Hunsur wrote: Hi all, I've been working on a little project over the last month and a half, inspired by Adam's dtojs (https://github.com/adamdruppe/dtojs). I've always wanted a typed, powerful, embeddable scripting language, but found the contenders lacking - which is why I decided to hack up DMD to emit Lua. Introducing Moonshot (https://github.com/Philpax/moonshot)! Moonshot's based off an early DMD 2.074, and builds up a Lua AST from the D AST. It aims to compile a reasonable subset of @safe code, so that high-level D can be used in scripting environments (i.e. games, scriptable applications, and more.) Because it's based upon the D frontend, it can already compile a lot of what we consider to be D - including foreach, the full power of metaprogramming, *ranges*, and more. There's an awful lot missing, as well (see the GitHub page for more information), but it's quite promising so far. Of course, this is still a very early, very untested project - so it's going to break on 99.9% of D code. I'd like to gauge community reaction, but it's nowhere near ready to show off to the wider programming community. This is really cool. I'd also like to find out if anyone would be interested in me submitting a DConf talk about how Moonshot works, and the benefits of using D as a typed scripting language. Cheers! -- Absolutely. I'd love to hear you talk about this.
Re: Beta D 2.073.1-b1
On Thursday, 9 February 2017 at 00:31:17 UTC, Martin Nowak wrote: First beta for the 2.073.1 point release. This version resolves a few regressions and bugs in the 2.073.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.073.1.html Please report any bugs at https://issues.dlang.org -Martin https://issues.dlang.org/show_bug.cgi?id=17162
Re: Release 2.072.2
Congratulations and thank you for your hard work. Most prominently scope classes work again in @safe code I haven't been following too closely. Does this mean that DIP1000 has been implemented and is behind a feature switch, or is the above entry just a small related bugfix?
