Re: NuMem - safe(r) nogc memory managment
On Saturday, 30 December 2023 at 16:36:38 UTC, ryuukk_ wrote: We plan to add more memory management utilities, thereby making writing completely GC-less D code a lot more user-friendly. I'd be happy to help What D really is missing _right now_, and will hopefully get _before_ phobosv3 is a good and minimalistic Allocator API, i modeled mine around zig's, no RAII, just a simple struct with 3 function ptr Yes, but first we can replace all the data structures in druntime to use non GC versions. I don't think there are that many of them. The non GC dynamic array would be a good fit here.
Re: DConf Online '22 Addendum: D-based Next Generation Hardware Description Language
On Monday, 2 January 2023 at 12:04:48 UTC, Mike Parker wrote: Feng Li's talk on Vlang, a D-based HDL, There is another language called vlang. https://vlang.io/ Unfortunate name clash.
Re: Binary Literals Not Going Anywhere
On Monday, 26 September 2022 at 04:40:02 UTC, Mike Parker wrote: You may have seen [the long discussion about the deprecation of binary literals(https://forum.dlang.org/thread/vphguaninxedxopjk...@forum.dlang.org). A few hours ago, Walter and I recorded a second conversation for our YouTube channel. Before we got started, I asked him about the binary literal situation. He confirmed that they will not be deprecated. If you're using them today, you can keep using them tomorrow. That's good to hear as depreciating binary literals wouldn't make any sense. I first assumed that people made too much of the comment as sometimes you just say something like a speculative comment without too much meaning or afterthought. Then Walter got into the discussion at forum not really retracting what he said so that left many people wondering.
Re: Druntime merged into dmd repo
On Saturday, 9 July 2022 at 22:24:45 UTC, max haughton wrote: Say thank you to Iain, Mathias, Vladimir, and Martin. This will make D better. More details to come. Does this mean that druntime for LDC and GDC were also moved into the same repo? Same branch?
Re: D Language Quarterly Meeting Summary for January 2021
On Friday, 21 January 2022 at 12:33:25 UTC, Mike Parker wrote: ### Adam Adam was unable to fully participate due to an issue with his microphone. He did leave comments in the text chat, and he noted that he was fine this time as an observer. We'll invite him to future meetings when his mic is working. The ever haunting issue with the microphone. It's 2022 and the microphone support on laptops/desktops still works sporadically. Don't I know it, it's been several times I had to call in with a phone instead.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Monday, 4 October 2021 at 15:44:11 UTC, Ki Rill wrote: About (1): I've written some C++ code recently. I was very happy with the code. I've read the code multiple times in search for potential bugs and errors. I decided to rewrite some of the code in D just to see the difference code-wise and performance-wise. Guess what happened? It didn't compile. I got out-of-bounds access error in D meanwhile the C++ version ran happily with no sign of any failure. That's a classic with C++ and static arrays. C++ now has the STL array which is standard now but who cares because not many know about it and there so many ways to do the same things in C++ you get lost. Also, it's ugly. In the case for D, I think D is a "sky is the limit" kind of language. D handles so many different areas, from low level to rather high level quite nicely. However, this together with one of the best metaprogramming out there, the versatility of the language is really among the highest. Now, the metaprogramming in C++ is just as powerful but not many people can handle it and they tend to avoid more complicated solutions. With D, metaprogramming is much more approachable and tasks that the programmer was unable to do in C++ can be done in D relatively easy.
Re: D and C++ renderer side by side demonstration
On Saturday, 7 August 2021 at 03:15:30 UTC, Ki Rill wrote: Here is a youtube [link](https://www.youtube.com/watch?v=7nWXbmLsIRI). I was watching Timur Gafarov’s videos on Dagon Engine and stumbled upon a video that demonstrated a C++ Renderer Engine using the same Sponza scene. I thought it would be a great idea to show them side by side. This is not a “X vs Y” video! It just demonstrates the capabilities of D and C++ side by side. You can do rendering engines in D, nice example. Next questions would be 1. Is GC being used or is custom memory management being used? 2. How much is D and how much are library calls (to OpenGl, DirectX whatever which presumably are done in C++)?
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 10 June 2021 at 10:55:50 UTC, sighoya wrote: I think the switch to arc with cycle detection as opt out (like in python) is the right direction, it fits more to a system level language making use of destructors more often. Rewriting cyclic code to acyclic code is easier than lifetime management in general. Further, optimizations can be introduced that detect acyclic structures in D just as it is the case for nim (https://nim-lang.org/docs/manual.html#pragmas-acyclic-pragma). That doesn't mean tracing GC is bad, I'm still skeptical that arc + cycle detection is better than tracing in general for true high level languages. Yes, this is a way forward. Walter doesn't want to add fat pointers, however he hasn't mentioned if that's part of the language or fat pointers as a library (like C++). It doesn't need to be part of the language but as a library type. Classes in D are essentially already library fat pointers. What we need is to extend this so that we have a generic fat pointer type (that can be recompiled to whatever GC type we want) that can be used for any type through out the entire code base if the programmer wishes that. Then we need refactor druntime/phobos to only use this fat pointer type. As you mentioned, in order to have better support for different GC, we can support compiler hooks (like your acyclic example) in order to give the compiler optimization hints. Whatever GC type you think is better for you, you should decide that and not forced by the D compiler and library. Basically GC X is better than Y is not an argument. What is the argument is how we can allow people to choose.
Re: D Language Foundation Monthly Meeting Summary
On Monday, 7 June 2021 at 18:37:54 UTC, sai wrote: Hopefully D will not stop covering these use cases. I know all the web-apps folks who wants to serve 100 requests per second will not like GC, I guess. Absolutely not, D must continue with automatic memory management and I think about everybody agree with that. The discussion is about how D can support different types of memory management and how to approach that, this is where the opinions are very different.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 19:56:06 UTC, sighoya wrote: This uniformization sounds too good to be true. I think most people think that, but it's simply not true. malloc/free is incompatible to garbage collection. This is true and even druntime has a malloc/free option for the GC. However, its implementation is really bad. Also the implementation of the current GC has a lot of room for improvements. It is still not appropriate for many embedded systems as it requires another layer that steals CPU time and code memory. In the case of Phobos, in order to make as versatile as possible it shall not assume any other layer than malloc/free. I'm asking myself, even if we don't care about the cons, would that at all be possible with a ~20 years old language with a ~20 years of ecosystem evolution. How many things need to be rewritten? D certainly has the power to do so but the question is if there is any will power in this community. Nothing has happened for almost 20 years.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 18:34:32 UTC, Imperatorn wrote: You might be surprised, but it's actually not up to you what topic fits or not. I said GC-phobia is irrational, I did not say any criticism of it is. Obviously GC is good for some things and not good at all for other things. What *is* irrational is saying it has absolutely no place at all. I don't think it is a phobia but it is a question of choice. We can clearly observe how different the demands are for different programmers in this forum. I enjoy GC for the appropriate programs, however there are SW where GC is a problem and cannot be used. Because of this Phobos must take the lowest common denominator approach (malloc/free) in order to be able to accommodate all the different needs. D is one these Swiss army knife languages that can be used for everything, including low level software and everything in between. What D should strive for is to give programmers a choice and put up as few barriers as possible. It's certainly challenging to make a library and language fitting everyone needs but D is at least one of the best foundation of achieving that goal.
Re: D Language Foundation Monthly Meeting Summary
On Friday, 4 June 2021 at 00:14:11 UTC, zjh wrote: Zim: the grammar is ugly. Zim? Is that what they speak in Zimbabwe?
Re: D Language Foundation Monthly Meeting Summary
On Thursday, 3 June 2021 at 23:47:07 UTC, zjh wrote: The GC of D is a burden.in the speaking of AA. D does not owns the advantages of GC , but all the disadvantages of GC .Why not discard it? Yes, for Phobos v2 one of the primary goals should be to not being forced to rely on GC. Phobos should only rely on malloc/free. Phobos may be using reference counting internally as it also only relies on malloc/free.
Re: Destroy All Memory Corruption
On Tuesday, 20 April 2021 at 01:12:22 UTC, Walter Bright wrote: I'll be doing a reprise of my DConf 2020 talk on Destroy All Memory Corruption on April 21, 2021 at 7PM PST. https://nwcpp.org/ Except this time it'll be live, not prerecorded. All are welcome! One remark I found interesting regarding reference counting. "In order to properly run the destructor, you have to run the destructor in an exception handler" Why do you need to run the destructor in an exception handler?
Re: Please Congratulate My New Assistant
On Monday, 18 January 2021 at 09:21:45 UTC, Mike Parker wrote: Thanks once more to Symmetry Investments, we have a new paid staffer in the D Language Foundation family. Though I call him my "assistant", I can already see he will be more than that. He'll be taking some things off my shoulders, sure, but he also has ideas of his own to bring into the mix. Adding him to the team is certain to be a boon for the D community. So, a word of warning to those of you who haven't heard from me in a while pestering you for blog posts: get used to the name "Max Haughton". And congratulate him while you're at it! What is the tasks of this new "assistant"?
Re: styx, a programming languange written in D, is on the bootstrap path
On Thursday, 14 January 2021 at 17:51:51 UTC, Basile B. wrote: This is the last[1] occasion to speak about a programming language initiatly made in D, as the bootstrap phase is very near. I'd like to thank the D compiler developers, that let me work on DMD even if I borrow another path. [1] : https://gitlab.com/styx-lang/styx Interesting project. A few questions. I see that you use "var auto name" in order to automatically infer the type. Would it be possible just using "var name" for that, similar to other popular languages. There is currently no information about memory management, is this something you have an idea how to design right now?
Re: DConf Online 2020 Schedule
On Wednesday, 14 October 2020 at 12:41:34 UTC, Mike Parker wrote: The DConf Online schedule is now live on the website. I've got a blog post coming tomorrow which will, among other things, include an announcement about the schedule aimed at the world outside our community in a form suitable for /r/programming. https://dconf.org/2020/online/index.html Were the seminars recorded so that we can view them later?
Re: Updated compiler-benchmark
On Thursday, 16 July 2020 at 15:56:45 UTC, Per Nordlöw wrote: D's compiler `dmd` is still far ahead of all its competition especially when it comes to default build (standard compilation) performance. I don't think this comparison is fair as dmd is far behind when it comes to code generation compared to the competitors. What should be included are benchmarks done with LDC as well. Since you already have the D code, adding LDC should be pretty easy.
Re: Visual D 1.0.0 released
On Friday, 10 July 2020 at 13:53:39 UTC, psycha0s wrote: Just installed Visual Studio Community 2019 and then VisualD from scratch. It looks like VS has no idea that VisualD is installed at all. So there is definitely an issue here. I think you have the same problem as this reported bug. https://issues.dlang.org/show_bug.cgi?id=21028 Check the comments how to fix the problem with an existing VisualD installation.
Re: Visual D 1.0.0 released
On Saturday, 4 July 2020 at 13:00:16 UTC, Rainer Schuetze wrote: Cheers, Rainer I installed it but I cannot choose a D project when creating a new project. I have VS2019 community edition but I'm running as a user without admin rights. If I use an account with admin rights, then I can actually choose a D project.
Re: Decimal string to floating point conversion with correct half-to-even rounding
On Sunday, 5 July 2020 at 12:46:58 UTC, Joseph Rushton Wakeling wrote: Can't speak for Walter or the D foundation here, but I'm not sure the concern is really about licensing. It's about putting in place a required dependency on code where maintenance decisions are outside the hands of the D Foundation. It's a resource question again. I'm all for that for example D should have a native alternative to curl including SSL/TLS support. If someone is willing to invest the man hours into such project, I'm all for it. Nim went that way having partial native http support so it isn't impossible.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Thursday, 2 July 2020 at 18:22:54 UTC, Dibyendu Majumdar wrote: So why was Java successful? It was not compatible with an existing language. Neither Rust nor Go are compatible with C++. Rust, D and Go are all compatible with C in some sense. Basically Herb is claiming to succeed a language must be able to be a drop in replacement for C++ in a mix-match way. I think it is a fallacy. There is no single recipe that will make a language successful. It's funny nobody has mentioned ease of use. Why is Java so popular? I'd say it's easy to use among other things. Why is Python so popular? Because it is easy to use and many can quickly learn it. Why is C++ so popular? It is or at least has been easy to use in its domain, at least if you use it conservatively and do not dig too deep into its language features. Ease of use is a big factor.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote: If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering. This can be mechanically checked by the compiler with the @nogc attribute. The point is even in C++ you should never ever do malloc/free in the audio thread, you might get away with it under low CPU load, but if you're running at high load it can barf the audio. So GC is just a variation on the same problem. Dont call malloc/free, dont use GC in anyway. You also have to make sure that the GC knows about your pointers, so if you have a pointer to something, make sure it's reachable from stuff the GC will scan. If it exists only on the stack in the audio thread the GC could collect it as it wont know it is still in use. Also see this... https://github.com/AuburnSounds/Dplug I think you can make a callback thread to D work if you have a trampoline function and then call thread_attachThis rt_moduleTlsCtor before calling the actual callback. Then the thread will be known to D runtime.
Re: Talk by Herb Sutter: Bridge to NewThingia
On Monday, 29 June 2020 at 22:23:57 UTC, Guillaume Piolat wrote: In reality you can actually disable the GC and still use: - classes - associative arrays (dplug:core) - dynamic arrays if you manage their lifetime Honestly, a guide how to do this would be very helpful. I'm particularly interested in how managing the lifetime of dynamic arrays in order to avoid GC means in practice, or are you referring to "dynamic arrays" as slices?
Re: Talk by Herb Sutter: Bridge to NewThingia
On Saturday, 27 June 2020 at 15:48:33 UTC, Andrei Alexandrescu wrote: How to answer "why will yours succeed, when X, Y, and Z have failed?" https://www.youtube.com/watch?v=wIHfaH9Kffs Very insightful talk. Back to C++20 and beyond which Herb Sutter refers to a lot. Is C++20 a success, or even C++17? Does anyone know this? Modern C++ isn't a programming standard so what I've seen is just a mix of everything. I have lost track of all new C++ features and now he even refers it as "NewLang" what that is. Is that Bjarnes famous quote "Within C++, there is a much smaller and clearer language struggling to get out."? I believe it when I see it. One thing that isn't mention that is very important for a language to succeed is libraries. C++ has a lack of standard libraries which forces the programmer to look for third party alternatives, which are of varying standard. This leads to that the there is no particular programming API standard it must gravitate to the lowest common denominator. This in contrast to Phobos which is more complete. Does C++ need more language features or does C++ need better standard libraries? I would say the latter. If it weren't for Qt, C++ would just be a skeleton language. Qt is a great library and was that even before C++11 which proves that the new language features weren't that important. What do you think, did "modern C++" really succeed?
Re: D as a C Replacement
On Wednesday, 5 February 2020 at 04:31:21 UTC, Walter Bright wrote: https://www.reddit.com/r/programming/comments/eyzrm9/d_as_a_c_replacement_the_art_of_machinery/ https://theartofmachinery.com/2019/04/05/d_as_c_replacement.html There was a comment in reddit regarding the article so I quote it from here. Problem with D is the lack of direction: LOTS of bugs, that has been accumulating and being ignored due to the desire of adding new features instead insane technical debt from all the "hacked" half-implemented features the GC is slow and leaks.. nobody seems to care, basically the whole reason to use a GC thrown out the window its all about adding the latest "cool" feature, as soon as its half-implemented its abandoned and a new one is added, see multiple alias-this, contracts, etc Now they want a borrow checker.. because ofc they do, rust has one so we need one as well. Already a hacked version of it already exists, and as always it will be ignored.. The language is used as an academic sandbox for testing stuff by their creators. Theres no direction whatsoever. Ignoring the lack of tools, documentation, etc I must say that it is summarized very well. Especially that it is focusing implementing the latest cool feature instead of stability.
