Re: D Language Foundation October Monthly Meeting Summary
On Sunday, 31 December 2023 at 11:12:23 UTC, Mike Parker wrote: Finally, he brought up code-d, [the Visual Studio Code extension for D](https://github.com/Pure-D/code-d) maintained by Jan Jurzitza (Webfreak). Steve said that it was great when it worked, but there were a lot of weird things that caused it to break. And what about https://code.dlang.org/packages/dlangide/0.8.18 or https://gitlab.com/basile.b/dexed? They are both not extensions, but full IDEs. I tried to install both of them (dlangide does not compile with dmd 2.097), dexed has working executables and looks good.
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 14 January 2022 at 07:14:25 UTC, Mike Parker wrote: On Friday, 14 January 2022 at 06:12:51 UTC, Konstantin wrote: Hello, Max! Are there any news or estimates about the roadmap? I posted a note about it in a meeting summary or a blog post (can't remember where) a few weeks ago. But the short of it: in the process of revising it, I realized it needs a complete rewrite. The document we ended up with isn't what we said we wanted. The rewrite will be a high priority for me once I wrap up the DConf Online Q & A videos and get the DIP queue moving again. I'll need more input from other people, and the time that takes is never predictable, but I intend to get it published in the first quarter of this year. And for the record, it's *not* a roadmap (assuming roadmap means a step-by-step plan for language evolution). It's broader than that. The intent is to outline Walter's and Atila's current focus, their longer-term goals, and areas where contributors can direct their efforts. It's a living document that will evolve as priorities change. Thanks, Mike! I will be waiting for news!
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 23:53:46 UTC, max haughton wrote: On Friday, 1 October 2021 at 21:48:23 UTC, Konstantin wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker [...] Offtopic: Are there any plans to publish the roadmap for the language and stdlib development on wiki or elsewhere? Mike is editing it at the moment. It will probably go into the foundation Ddoc sources (Not a huge of the wiki since it's not tracked in git) Hello, Max! Are there any news or estimates about the roadmap?
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 23:53:46 UTC, max haughton wrote: On Friday, 1 October 2021 at 21:48:23 UTC, Konstantin wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker [...] Offtopic: Are there any plans to publish the roadmap for the language and stdlib development on wiki or elsewhere? Mike is editing it at the moment. It will probably go into the foundation Ddoc sources (Not a huge of the wiki since it's not tracked in git) Thank you, Max! Do I understand correctly, that roadmap section will be available at https://dlang.org/foundation/index.html
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: Attendees: Andrei Alexandrescu Walter Bright Iain Buclaw Ali Çehreli Max Haughton Martin Kinkelin Mathias Lang Razvan Nitu Mike Parker [...] Offtopic: Are there any plans to publish the roadmap for the language and stdlib development on wiki or elsewhere?
Re: How to allocate/free memory under @nogc
On Thursday, 21 May 2020 at 15:09:57 UTC, Steven Schveighoffer wrote: On 5/20/20 10:50 PM, data pulverizer wrote: how do you allocate/free memory without using the garbage collector? Use C malloc and free. Does allocating and freeing memory using `GC.malloc` and `GC.free` avoid D's garbage collector? No, an allocation can trigger a collection. D does not have a scheduled GC, it basically runs the GC when it can't allocate any more memory from it's pools before it tries to get more from the OS. I *think* that @nogc is supposed to mean "Be able to run this without a GC implemented", not that no collections will run. -Steve Hi all! I will try to ask again(previous two posts still have no answers) : are there any site/page/docs somewhere to track actual info about @nogc support in language itself and in phobos library? Or, at least plans to extend such support?
How to move from Unique(someClass) to Unique(someInterface)?
import std.stdio;
import automem;
import std.experimental.allocator.mallocator : Mallocator;
interface IGetInt
{
@nogc int GetInt();
}
class Foo : IGetInt
{
@nogc int GetInt()
{
return 42;
}
}
@nogc void main()
{
auto foo = Unique!(Foo, Mallocator).construct;
printf("Value is %d!\n", foo.GetInt());
// Unique!(IGetInt, Mallocator) ifoo = Unique!(Foo,
Mallocator).construct;
// printf("Value is %d!\n", ifoo.GetInt());
}
How to cast from a class to an interface in such situation? Is it
possible?
And one more question: Where can i find actual status(or plans)
of @nogc support for Phobos and language constructs?
Right ways to work without gc without betterC.
I saw docs for std.experimental.allocator and also had found automem library(https://code.dlang.org/packages/automem) for c++ style memory management via smartpointers. From GC documentation std.experimental.allocator can not be used for: NewExpression Array appending Array concatenation Array literals (except when used to initialize static data) Associative array literals Any insertion, removal, or lookups in an associative array Extracting keys or values from an associative array Taking the address of (i.e. making a delegate to) a nested function that accesses variables in an outer scope A function literal that accesses variables in an outer scope An AssertExpression that fails its condition Is that actual information? Does someone work to implement switch between gc and non-gc approach? I learned for now automem's smartpointers which based on std.experimental.allocator can be used to store structs/classes. Does automem(or std.experimental.allocator) has support for inherited classes, polymorphism like std::unique_ptr (or base class) in c++? Does Phobos support std.experimental.allocator? Are there another gotchas with "c++ like" memory management way in D? P.S. Sorry for my bad english.
Re: Garbage Collector
On Wednesday, 15 June 2016 at 18:23:52 UTC, Jack Stouffer wrote: They're not acceptable for a systems programming language as they require you to pay for something that you might not use. According to our resident GC maintainer (among many other things), they would cause a 1%-5% slow down in the language: https://github.com/dlang/druntime/pull/1081#issuecomment-69151660 Well I’m not sure about the 5% (MS says their write barrier overhead is comparable to the cost of a simple method call, namely 6.4ns: https://msdn.microsoft.com/en-us/library/ms973852.aspx), but yeah, there’s some tradeoff, for having a good GC. By the way, Go implemented those barriers in version 1.5 a year ago: https://blog.golang.org/go15gc
Re: Garbage Collector
On Wednesday, 15 June 2016 at 17:02:11 UTC, rikki cattermole wrote: Higher level languages like Java have the benefit of using pools and optimizing for this usage pattern, D does and will never have this. Why don't you want the same for D? Well if you really insist to have a String class don't be too surprised for some reason it doesn't have the same performance to say Java. Some areas, like compiling, or producing HTML/XML/JSON documents, manipulate strings a lot. Other areas, like GUI editors for sufficiently complex documents, or level editors for videogame, need to efficiently manipulate huge trees of assorted small objects, not necessarily strings. Aka don't go around creating/destroying classes a huge amount unless you have rolled some form of memory management policy such as reserving memory for the GC to use. Yeah, that’s what I regularly do in C++ when I need to efficiently create/destroys many small objects. Sure, this typically leads to the best performance, e.g. because I can make the memory layout as cache friendly as humanly possible. But not all projects need that. And even for very performance demanding apps, not all components of the app need that. For such cases, a good GC (that just works well out of the box like .NET's GC does) can reduce development costs significantly.
Re: Garbage Collector
On Wednesday, 15 June 2016 at 13:56:09 UTC, Jack Stouffer wrote: One guy wrote the LuaJIT GC, which beat almost everyone else in performance when I last checked “The current garbage collector is relatively slow compared to implementations for other language runtimes. It's not competitive with top-of-the-line GCs, especially for large workloads.“ https://github.com/LuaJIT/LuaJIT/issues/38 They have planned something for 3.0 that may or may not work: http://wiki.luajit.org/New-Garbage-Collector But that’s merely a design, AFAIK there’s no implementation. They’re still looking for a sponsor for that. Has anyone thought about taking GC from .NET and reusing it in D? Two words: write barriers. What about them? You mean not all D’s target platforms support them?
Re: Garbage Collector
On Wednesday, 15 June 2016 at 13:40:11 UTC, rikki cattermole wrote: 5. The requirements for our GC is quite intricate. I.e. you can't just pop in one that doesn't understand about our Thread Local Storage (TLS) and stuff. D’s TLS that different from .NET's TLS? https://msdn.microsoft.com/en-us/library/system.threadstaticattribute(v=vs.110).aspx I forgot to mention, good D code is not the same as a higher level language like Java. Here you don't have the automagick behavior of arrays. If you append it will have a high cost. All allocations have a large cost. Instead allocate in one large block which will of course be a whole lot faster then small tiny ones. You’re saying memory allocations in D are generally very expensive, but that’s not a problem, because it already functions as designed? So even if the GC is enabled, good D code won't cause too much slow down unless you decide to write heavy OOP code. I’ve been developing heavy OOP code in various languages (mostly C++, but also C# and Objective-C) for decades already. OOP works very well for me.
Re: Garbage Collector
On Wednesday, 15 June 2016 at 13:27:47 UTC, jmh530 wrote: Possible to disable. I don’t want to: for the last couple years I’ve been developing 50/50 C++/C#, and I admit I’m usually more productive using C#, one of the reasons of that is GC. They've got a GSOC guy workin' on it now. I would hold off judgements until that effort is concluded. OK let's see.
Garbage Collector
Started learning D. Like the language. However, found several people complaining about garbage collector’s reliability and performance. For me it’s a showstopper. I don’t believe a community is capable of creating a good GC. It’s just too complex engineering task. It’s been a known problem for years, still no solution. Since recently, Microsoft’s .NET framework and runtime are open source under MIT license. Here’s the main parts of their GC: https://github.com/dotnet/coreclr/tree/master/src/gc As you see, it’s in C++, and contains 10-20 times more code, then D’s GC. Theoretically, it should be cross-platform: there’re build instructions for Linux (including ARM), OSX, and BSD; but I haven’t tried building on those. Has anyone thought about taking GC from .NET and reusing it in D? That GC is very efficient for wide range of applications. I’ve been using .NET since 3.0 on desktops, servers, embedded and mobiles, never had issues with GC, it just works, and the performance is good. I don‘t know architectural details of either GC. I perfectly aware it might happen so they are completely incompatible, or very hard to port: because .NET’s System.Object vs. D’s Object differences; because D’s fibers or just very different threading model; because different CRT; many other reasons possible. But if we’re lucky, this GC could lead to a great improvement for D ecosystem, not costing too much time. IMO that is something doable by a single person in a spare time. Thoughts?
Re: Multithreading in D
Are you looking for parallel?
http://dlang.org/library/std/parallelism/parallel.html
I have seen this, but I'm not sure how to use it.
Maybe:
float[][] maps = new float[#threads][resolution * resolution];
foreach(i, ref elem; parallel(maps)){
elem = generateTerrain(...);
}
Does this look right?
Multithreading in D
Hello D-World,
I've written a small terraingenerator in D based on the
Hill-Algorithm.
To generate a terrain I only need to call the method
generateTerrain(...) which returns a float-Array containing the
height of each pixel (2D Array mapped with a 1D array with length
resolution^2).
What I'd like to do:
Generate #treads seperate maps in a own thread and combine and
normalize them afterwards.
I have little to no experience working with multiple threads. I
tried it once in java for University but did not really get
working.
What I imagine as solution (I know it won't work this way, but to
give you a better idea):
for(int i = 0; i #threads; i++){
runInThread(generateTerrain(...));
}
Greetings and thanks in advance Konstantin
