Re: New DConf Blog Post
On Saturday, 6 April 2019 at 22:30:58 UTC, bauss wrote: On Friday, 22 March 2019 at 13:58:01 UTC, Mike Parker wrote: The DConf schedule was announced last Sunday. I've just published a write-up about it on the blog for the world-at-large. Please help us out by sharing this post in your social media circles. The blog: https://dlang.org/blog/2019/03/22/dconf-2019-london-programme/ Reddit: https://www.reddit.com/r/programming/comments/b45bxp/dconf_2019_london_programme/ Just going to respond to this: "If you haven’t visited the site in a while, you’ll surely notice that it’s been redesigned. The old version was not responsive and was quite annoying to manipulate on small screens." The design is terrible and it really looks unprofessional. While the old site wasn't responsive, the design was at least slightly better. It just doesn't look very well done. I'm not trying to be negative or anything, but it looks like someone who just learn html/css in 1999 tried to make the design of the page. No offense, but http://motherfuckingwebsite.com/ I'd just tag a Planet-earth-with-a-green-leaf icon and a speech bubble reading "Thank you!" J/K But seriously I prefer the '19 version over the '18 one. The '18 version is super bloated and slow.
Re: New DConf Blog Post
On Thursday, 11 April 2019 at 16:56:27 UTC, Nick Sabalausky (Abscissa) wrote: On 4/11/19 10:11 AM, wjoe wrote: No offense, but http://motherfuckingwebsite.com/ That is the best website EVER. Times a billion. Says exactly the things I've been wanting to scream at jet-engine volume straight into the faces of every web designer and full-stacker in the world. "Responsive web" always made me cringe. HTML-freaking-version-ONE was responsive. And semantic. It was specifically *designed* to be. But then the designers and the know-nothing software managers came, hated that stuff, and killed it all with fire. Then when the sausage-finger small screens came (not to mention browser diversity and "emerging markets"), they shit a brick and started over-re-engineering everything that was already there all along (plus some extra garbage nobody needs). Idiots. Yeah, that, and it respects a browser's font and size configuration :) Visiting a web-site I often think to myself: Fail! You can still manage to read that 7pt font by attaching your eyeballs to the screen! If you don't want people to be able to read it, you should remove that text altogether! Saves you all the effort, too. These so called web designers who work s hard to find all possible ways to stop you from comfortably reading the thing with tons of useless java script "coolness" and distracting banners and drop downs and otherwise hidden information you need to find the spot to tickle to make it appear (is that a secret cry for help?) and pictures that stalk you but can't make text flow around a picture without using DIV - and then need to nail everything else in place with more DIVs. Amusing :) They can't even make normal hyperlinks work and spend tons of effort trying to imitate it with java script. Delicious :) And their white on black design which makes you see nothing but zebras for the rest of the day or so after spending 2 minutes on it...love it! :)
Re: GCC 10.2.1 Released
Thank you :)
Re: GCC 10.2.1 Released
On Saturday, 29 August 2020 at 18:40:36 UTC, Iain Buclaw wrote: On Thursday, 27 August 2020 at 04:05:15 UTC, M.M. wrote: On Monday, 24 August 2020 at 23:49:42 UTC, Iain Buclaw wrote: [...] Likely the deciding factor will come down to how much free time I will get to do so. There's still a few outstanding issues in dmd-master and gcc middle-end that have hampered progress by a few weeks. Thank you for your work. I cross my fingers for you to have enough free time in the upcoming months! If people want to share my workload on gdc, then it'll certainly help. I'm exactly 100% unfamiliar with the code base. How can I help ? Where do I start ?
Re: GCC 10.2.1 Released
On Monday, 31 August 2020 at 13:24:50 UTC, wjoe wrote: I'm exactly 100% unfamiliar with the code base. How can I help ? Where do I start ? Reading this again after a few hours it comes across in sort of a rude way - apologies if that was the case. The question is if I haven't got any experience with GCC and GDC, how to get involved - where to get started ?
Re: GCC 10.2.1 Released
On Tuesday, 1 September 2020 at 17:53:04 UTC, Iain Buclaw wrote: Some parts of the infrastructure could do with some TLC. I'm not familiar with the acronym 'TLC'. CI currently uses semaphore CI for native x86_64, and Buildkite with a couple hosted Linux VMs for testing various cross-compilers. I used to have ARM and ARM64 bare metal servers with Scaleway, but sadly they decided to scrap them. Ideas that could be investigated: 1. Is Cirrus CI good enough to build gdc? And if so, look into adding Windows, MacOSX, and FreeBSD platforms to the pipeline. What does 'good enough' mean ? I found this reply (March/2019) by Johannes Pfau here [1]: We use https://github.com/D-Programming-GDC/gcc for CI, but commits will go to the GCC SVN first, so GCC SVN or snapshot tarballs is the recommended way to get the latest GDC. Is this information still up to date ? There's a semaphore folder. I suppose that's the one currently used with Semaphore CI. Is there something else ? [1] https://forum.dlang.org/thread/lqdjlwmgrfstifcbu...@forum.dlang.org PS. Sorry for the Announce group abuse.
Re: GCC 10.2.1 Released
On Friday, 4 September 2020 at 22:00:51 UTC, Iain Buclaw wrote: On Friday, 4 September 2020 at 15:12:54 UTC, wjoe wrote: PS. Sorry for the Announce group abuse. We can take this to D.gnu instead. :-) I continued this thread here: https://forum.dlang.org/thread/kruxkrrzithkrswoq...@forum.dlang.org
Re: gamut v0.0.7 ask for what you want
On Friday, 29 July 2022 at 10:59:02 UTC, Guillaume Piolat wrote: Ask for what you want... Since it's super easy to calculate the amount of memory required to hold the decompressed data... If you'd add a buffer parameter (akin to std.stdio.File.rawRead/Write), a slice to allocated memory that holds the decompressed data, people could use their allocator of choice to allocate the buffer and your lib would not just be @nogc but @no_allocation.
Re: gamut v0.0.7 ask for what you want
On Tuesday, 9 August 2022 at 22:02:37 UTC, Guillaume Piolat wrote:
On Monday, 8 August 2022 at 16:07:54 UTC, wjoe wrote:
your lib would not just be @nogc but @no_allocation.
All image decoders in gamut need to malloc more than just for
pixel data.
Even STB allocates for format conversion, zlib buffers, 16-bit
<-> 8-bit, etc. it's not just pixel data.
Single allocation pessimizes the size a lot because since you
haven't encoded yet, you need to prepare a buffer for a large
worst-case.
I imagined you could allocate internal buffers for
encoding/decoding on the stack but your reply suggests otherwise.
However shouldn't a single function call back be enough?
Something like
``` D
void[] need_more_ram(size_t amount, void[] old_chunk, void* user)
{
MyAllocator* a = cast(MyAllocator*)user;
void[] result = a.alloc(amount); // MyAllocator would return an
empty slice if amount == 0
if (amount && chunk.length) result[0..chunk.length] = chunk; //
it is assumed that on re-allocation amount > chunk.length
a.free(chunk.ptr);
return result;
}
```
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote: But indeed, being able use D in a GC-free environment (like C++ and Rust do) would be something many people may NEED, for instance to be able to EASILY use D for soft-realtime applications like games. This has to be the no. 1 excuse. Why is C++ the language of choice currently? My bet is productivity and economic concerns. Amongst other things the productivity gain from resource management via constructor and destructor. Which solves like 75% of the headaches of manual resource management and goto nightmares. Back in the day when C was used to make games, the excuse not to use C++ was vtable, exception and RTTI overhead. Now it's called the bare metal best performance language which everything and their grandma is measured against. This C++ overhead didn't make C any slower or C++ any faster than C but it made C++ superior in productivity. This was around 2002/03, and C++, at the time, some 23+ years old. Games have been made with GC'd languages, 3D games, even. And successfully, too. Minecraft, a very successful one, comes to mind, which is or at least was made in Java. Plenty of games are made in C#, too. My bet, again, would be productivity and economic concerns. The countless hours wasted on debugging memory leaks and cyclic dependencies are better spent making the actual game/software. And smart pointers introduce overhead of their own which makes them inferior to C's bare metal raw pointer performance - or GC'd pointers for that matter. The culprit being the collection cycle. The best thing about this whole argument, however, is the claim for GC no can do and with the next breath they pull LUA into their games. A scripting language that brings a VM, GC and extraordinarily inflated loading times when the scripts are compiled to byte code at the end user's PC which make C64 loading times shine. The reasoning probably being productivity again and C++'s lunch break compile times. Using the D compiler as a library, instead of LUA, D code could be used for 'scripting', as well, and compiled to native machine code. In a snap. I have no metrics between any AAA game engine and their port to D but I do know that I wrote a sound/music player library in Java, which folks like you claim impossible because GC, never bothered with GC and had no performance issues whatsoever - and I don't expect any porting it to D. And there is EASTL. A STL made by Electronic Arts. Because the standard implementation shipped with the compiler is too slow ? Even though written by C++ wizards ? Slow code is slow and allocating memory in a tight loop is a huge performance killer - regardless of language. Also, why do you feel like a GC is inacceptable for games but doesn't matter for your file handling program? Handling dozens, maybe thousands, of files sounds like an awful lot of memory management involved and whether a e.g. grep takes 15 seconds to do it's job or under 1 matters not? Nothing forces anyone to use the GC, memory can be managed manually via malloc/free and you get to do it with scope statements/nested functions which makes it nicer than in C. You could also implement shared/weak ptr stuff in D - warts and all. If you need a GC free standard library, I believe there is an ongoing effort -or several- at code.dlang.org and probably other places. You said do this and that, GC, etc. to motivate C++ folks to come to D. I say it's an excuse not to use D and no matter the effort of advertising, a GC free phobos, etc. on part of the D-Lang Foundation and contributors would make these folks switch. They would simply find a different excuse. And where's the usefulness of toy examples like 2 line web servers which essentially do nothing? And how is that helping with getting attention from the game devs ? Putting on the front page a 12 line maze game which can be imported from the standard library? Not using the GC?
Re: I have a plan.. I really DO
On Wednesday, 4 July 2018 at 19:29:55 UTC, Ecstatic Coder wrote: First, to be clear, I mainly use D as a scripting language for file processing, and for this use case, having a GC is a blessing. This is a non issue and a GC doesn't matter at all in this case. You could allocate all you wanted and never free and as long as there's enough memory to finish the script you couldn't tell the difference. Once a script or program is done the OS reclaims all memory. But memory leaks in software, running in some kind of main loop, become real performance bottlenecks eventually and a time sink to debug. You say that garbage collection is not a real problem for game development. No, what I'm saying is that I've hadn't had any issues with the GC so far and that I don't expect any. I'm also saying that I keep hearing this argument against using D but it was never backed up by anthing substantial so it sounds like an excuse by folks who never really considered D in the first place. Like, what does it matter if a collection cycle is triggered during a loading screen ? Performance aware C++ folks do have to do resource management at some point, too, and that's not free either and is usually done while the loading screen is displayed. For instance, have you read Unity's own official recommandations on how to overcome this problem ? No, I haven't. It probably boils down to pre-allocation, object pools, reusing objects, don't allocate in a loop, caching data, be mindful of what you do and when and how, etc, etc. Which would be good advice for game development in general and I'd do exactly that in C/C++, or any non-GC'd language, too. And about developing video games in C++, actually most studios use orthodox C++. This means no exceptions, no RTTI, few virtual methods, fast lightweight smart pointers and collections, etc. They could get that with -betterC which also does not use a GC. And about the scripting language, it's not my fault if some game engine developers don't care for the performance or GC issues when adding a scripting language to their game engine. Never said it was your fault, just pointed out the fact that it's a very common occurance. So, as I said, those who use C++ or Rust because D's GC is a problem for them, won't probably use D in its current state. Or any other language tagged GC for that matter, except maybe LUA. Nobody and nothing forces anyone to use the GC or features which use it. Just go ahead and manage your memory manually. They will not be using features like dynamic arrays, the standard library, and such but that's not a loss since they'd roll their own, more performant implementations, anyways. But I'm convinced that they wouldn't consider D - even if there was a GC-free Phobos. They would find the next excuse. Those who are willing find solutions, those who are not find excuses.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 13:15:43 UTC, Ecstatic Coder wrote: Just by curiosity, can you tell me how many successful commercial games based on a D game engine are released each year ? Just out of curiosity, how many games have been released based on a C++ game engine in 1998 ? The original Unreal engine was almost completely written in asm, back in the late 90ies. The first C++ game engine I found was the Object Oriented Graphical Redering Engine, started some time around 2001. Carmack resisted C++ for a longer time and I believe I read something about the engine was ported to C++ when they developed Id Tech 4 around 2004.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:30:22 UTC, Ecstatic Coder wrote: On Friday, 6 July 2018 at 15:07:41 UTC, wjoe wrote: [...] Actually, as I said, even today many game engines are still written in a C-inspired manner, i.e. C + classes, templates and polymorphism, mainly for performance reasons (cache friendly data oriented designs, etc). You can do that in D.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 15:53:56 UTC, Ecstatic Coder wrote: With D, ANY forgotten allocation during the game loop (and I really mean even JUST ONE hidden allocation somewhere in the whole game or engine), may cause the game to regularly freeze at the wrong time, because of an unwanted GC. Hence the phobia. You make it sound like a C++ game codes, debugs, profiles and optimizes itself. And like there are no gotchas with C++. Anyway, I know I'm on a D forum here, so "those who don't want to understand won't, and those who want will", to paraphrase a former poster here. Well, it appears that you don't. And since you point out the D forum folks, I know game developers are a very special lot, too, with ther mantra like repetition of GC is the devil, acting like it's 1985 and the need to count clock cycles and top-of-the-food-chain I-never-make-mistakes arrogance like nobody else knows how to write fast code, yet most games of those clever guys are bug ridden pieces of poor quality even years after release, including top AAA titles *cough* TES. Despite - or more likely because - being made in C++. Maybe performance aware game developers would do well to also adopt the idea of code quality and D offers a lot in that regard. Plus C++ish performance on top of that.
Re: I have a plan.. I really DO
On Friday, 6 July 2018 at 17:26:26 UTC, wjoe wrote: And since you point out the D forum folks, I know game developers are a very special lot, too ... Edit: This should read: I know game developers who are a very special lot My point was to only refer to the people I know, not game developers in general.
Re: I have a plan.. I really DO
On Tuesday, 10 July 2018 at 17:25:11 UTC, Yuxuan Shui wrote: (Although I don't quite agree with you. Some people DO resist change, that's why some decades old languages are still popular. But look at the popularity of new languages like Go, and Rust, and the ever-change landscape of front-end development. There're tons of people who adapt certain technology just because it is new, why can't that happen to D?) Because they are humans. Because the masses fly to hip stuff like moths to light. Because people make decisions out of a mood or because of peer pressure and based on opinion rather than facts. Because a lot of people use it so it can't be bad !? You can see that phenomenon in Hardware and end user software and really every other aspect of life, too, by the way. It's almost always the hyped shh-stuff that gets wide spread use. How many of these people are using it because they want to ? How many are happy with the language, rather than just being part of the flock ? To be able to call oneself hip ? To be part of the group ? Whether or not rust, go, etc. are just as or more popular than C++ or Java in 30 years remains to be seen.
