Sokol now has official D bindings
I just saw this yesterday, and i haven't see anybody talk about it here, so i decided to share this great news for D here Sokol is a popular gamedev library https://github.com/floooh/sokol It now officially supports D, thanks to the work led by https://github.com/kassane https://github.com/floooh/sokol/blob/master/CHANGELOG.md#13-may-2024 https://twitter.com/FlohOfWoe/status/1790043272385114421
Re: Sokol now has official D bindings
It'll be interesting to know what the experience was for the maintainer to play around with D (for the first time?) From what i could gather, problems encountered: - rvalue ref params (wich led to someone telling him to use -preview=all wich led to other issues) - attributes soup - float nan default - no warning on use of uninitialized floats I think it is time to decide what to do with all these -previews, rvalue ref params should be a feature already imo For float nan default, i personally think everything should be consistent therefore 0 initialized
Re: Sokol now has official D bindings
LDC yet again is proving how essential it is for D, now that more OS are embracing ARM, having LDC available and maintained to support latest version of LLVM and all kind of platforms is a blessing The maintainer is using macOS, and his library targets many platforms including the web with WASM, both supported by LDC out of the box DMD for fast iteration time (on x86, hopefully ARM in the future) And LDC for everything else It's a deadly combo, thanks to everyone working hard on maintaining both projects
Re: Sokol now has official D bindings
On Tuesday, 14 May 2024 at 12:46:13 UTC, ryuukk_ wrote: LDC yet again is proving how essential it is for D, now that more OS are embracing ARM, having LDC available and maintained to support latest version of LLVM and all kind of platforms is a blessing The maintainer is using macOS, and his library targets many platforms including the web with WASM, both supported by LDC out of the box DMD for fast iteration time (on x86, hopefully ARM in the future) And LDC for everything else It's a deadly combo, thanks to everyone working hard on maintaining both projects - On my work with redub, I've used dmd as a default. If it is not being able to find it, it will give an warning and try LDC instead. - No need to change float default from nan to 0, excluding my own opinion, Walter concretely believes that nan is better than 0. I would like to at least get warnings on uninitialized floats, so it becomes 50-50 and no one will ever initialize float to nan again. - Could we get official LDC full D support to WASM? I haven't been having much time to work with D. When I do have time, the last thing I want to do is updating my custom runtime again. Beyond that, people always get the wrong impression from the WASM status quo. I know we won't have a garbage collection, but 90% of the work will be done. Just send a warning for anyone using D wasm runtime that support is incomplete. D always done that nevertheless.
Re: Sokol now has official D bindings
On Tuesday, 14 May 2024 at 12:36:27 UTC, ryuukk_ wrote: It'll be interesting to know what the experience was for the maintainer to play around with D (for the first time?) From what i could gather, problems encountered: - rvalue ref params (wich led to someone telling him to use -preview=all wich led to other issues) - attributes soup - float nan default - no warning on use of uninitialized floats I think it is time to decide what to do with all these -previews, rvalue ref params should be a feature already imo Yep, i think it was there long enough already so rvalue ref parameters should already be in. Also what's with this `in` const parameters transition, it just like umm hanging in there for years?
D Language Foundation January 2024 Monthly Meeting Summary
The D Language Foundation's monthly meeting for January 2024 was held on Friday the 12th. There were two things of particular note about this meeting. First, Jonathan Davis joined us for the first time and is now a permanent member. We're very happy to have him aboard. Second, this was the first meeting where we adopted a new format. Previously, we'd go around the "room" to give each participant a turn to say everything they needed to say or as much as they could say before we had to move on in the interest of time. Sometimes people had problems they wanted to solve, other times they just had status updates or progress reports. When our membership was small, it all worked well, but as the invitation list grew, we could end up with long meetings in which important topics got cut short because they didn't get brought up until later in the meeting. For the new process, I ask everyone to send me any agenda items they'd like to discuss that are not progress reports or status updates. At the meetings, I'll go round-robin through the lists in the order I receive them: first item from each list, second item, etc, until either there are no more items or we've hit the hour-and-a-half mark. If we get through the items early, then I'll open the floor to anyone who has something to report. If we still have agenda items at the hour-and-a-half mark, I'll ask if we should continue for another 30 minutes or call it. This new approach has worked well for us since. It's also going to change how I write the monthly summaries. Each section heading is a topic of discussion rather than a participant's name. The only agenda items I received from the members for this meeting came from Timon. He had quite a list, and we went through pretty much the whole thing. But I did give the floor to Robert at the beginning for a very brief update. I also had one item that came in the form of a request on the Discord server. ## The Attendees The following people attended the meeting: * Andrei Alexandrescu * Walter Bright * John Colvin * Jonathan M. Davis * Timon Gehr * Martin Kinkelin * Dennis Korpel * Mathais Lang * Razvan Nitu * Mike Parker * Robert Schadek * Steven Schveighoffer * Adam Wilson ## The Summary ### Item 1: Bugzilla to GitHub migration As I noted in the [November meeting summary](https://forum.dlang.org/post/lywqaaibghfinljxo...@forum.dlang.org), some potential issues had come up regarding the effect of the Bugzilla to GitHub migration on the dlang bot. Robert had said he'd investigate them. As an update, he'd discovered some changes needed to be made to the changelog generator and had made good progress on that. He said Vladimir Panteleev had been working on some changes to the dlang bot related to how it closed solved issues. When that was all completed, they'd be able to test it. He wanted to put it through multiple tests to make sure it held up and worked as intended. ### Item 2: D data structures Monkyyy asked me on the Discord server to bring his article on [D data structures](https://monkyyyscience.substack.com/p/d-data-structures?r=99zq&utm_campaign=post&utm_medium=web) to the meeting. I emailed a link to everyone before the meeting. I received a little bit of feedback in the email thread. In summary: * Monkyyy's complaint that allocators are "unmerged" highlights why Átila wants them out of `std.experimental`. * The article doesn't specify any specific data structures he'd like to see in the standard library. * Any redesign of Phobos needs to consider containers at some point, but how comprehensive should it be? How high of a priority? * Some simple containers can easily be built on top of arrays. Should we add that kind of thing to Phobos, or only more complex ones? * Would it be better to have a comprehensive container library in the dub registry? I asked if anyone had any more feedback that they hadn't raised in the email thread. Timon suggested that someone should do what Paul did with the sumtype package: write a container library and then we could put it in Phobos if it was good enough. Adam said he'd been having discussions about containers with Rikki and others. He told us that Rikki felt that we needed to focus on allocators first, then once that was solved we could start looking at containers. Adam said he didn't know if that was necessary or not, but based on that and other conversations he'd had on Discord, he thought that was the point of the article. Steve said he agreed with Timon: if we were going to have something that was going into Phobos, it should be put up on dub first to prove that it was worth including. There were so many different opinions around containers and their APIs that it wasn't something we should just say, "Here's some space in Phobos, now put them in." Put it in dub first, work out the API we wanted, make sure it all works, and then put it in Phobos. Razvan wondered what the procedure would be. There
Re: D Language Foundation January 2024 Monthly Meeting Summary
On Tuesday, 14 May 2024 at 13:23:17 UTC, Mike Parker wrote: The D Language Foundation's monthly meeting for January 2024 was held on Friday the 12th. There were two things of particular note about this meeting. [...] I have some things to feedback on those points ### Item 6 I had done my DIP thinking mostly about intermediate values on mixin template. That would make the value not included in mixin template, but yes, static foreach also needs that, so a good solution would be one that solves them both. ### Item 7 Redub is a tool that is basically a dub clone which improves what dub is not doing very smartly: building. Recently I've done a simple, yet major UX improvement: if dmd is not found, it tries ldc. But the apex of UX I've done is inside my engine, but I've shared a plenty of times: build selector. This tool is focused into: All the items ending with a `*` are optionally done by the user. - Downloads a D compiler if none is found on the user system - Downloads and installs git [only on Windows that is automatic. Other systems it shows an error requiring that to be done] - [Windows] - Installs MSVC and vcruntime so D is able to build it on systems that doesn't have this option (I needed that when running with a VM). - Download Android SDK/NDK [based on the user system], with the supported LDC compiler and sets up the DFLAGS required to build for Android.* - Sets up a custom D runtime which supports building to WASM, sets up the DFLAGS required to build it. May also get a supported compiler.* - Sets the DFLAGS required for being able to build for iOS.* ### Item 8 There was a project which is basically rdmd but faster out there, done by Jonathan Marler. - https://github.com/dragon-lang/rund Sometime ago I thought about just pushing to d tools, but since no one cared about, I simply abandoned the idea, but there it is:
Re: D Language Foundation January 2024 Monthly Meeting Summary
On Tuesday, 14 May 2024 at 14:01:28 UTC, Hipreme wrote: [snip] ### Item 8 There was a project which is basically rdmd but faster out there, done by Jonathan Marler. - https://github.com/dragon-lang/rund Sometime ago I thought about just pushing to d tools, but since no one cared about, I simply abandoned the idea, but there it is: I was thinking the same thing! I had used it a few times, but I just don't use rdmd enough to want to use an alternative to it. If the improved functionality were built-in, then that would be a positive.
Re: Sokol now has official D bindings
On Tuesday, 14 May 2024 at 12:36:27 UTC, ryuukk_ wrote: - float nan default Complaints from C and C++ programmers could mention that at least stack variables gets initialized to something.
My interest in contributing to the D language and participation in the Symmetry Autumn of code
Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that.
Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote: Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that. Hi Dennis, nice to hear that! Razvan and Mike probably are good persons to ask such question. There are some project milestones in GitHub repo.. But you can start with issues https://forum.dlang.org/group/issues
Re: LDC 1.38.0
On Saturday, 11 May 2024 at 01:22:58 UTC, kinke wrote: Glad to announce LDC 1.38.0. Major changes: - Based on D 2.108.1. - Support for LLVM 18; the prebuilt packages use v18.1.5. - Android: Switch to native ELF TLS, supported since API level 29 (Android v10), dropping our former custom TLS emulation (requiring a modified LLVM and a legacy ld.bfd linker). The prebuilt packages themselves require Android v10+ (armv7a) / v11+ (aarch64) too, and are built with NDK r26d. Shared druntime and Phobos libraries are now available (`-link-defaultlib-shared`), as on regular Linux. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.38.0 Thanks to all contributors & sponsors! Thanks a lot Martin! I'm super excited to integrate the new NDK support to my engine tool so it can still automatically integrate with the most up to date version :)
Re: D Language Foundation January 2024 Monthly Meeting Summary
Wow I see I was mentioned at a lot at this meeting! In saying that I do have some points to add about Item 2 data structures. Data structures come in one of two forms generally: owning and non-owning. ### Non-owning Non-owning is the simplest, its an index. It doesn't own any memory that isn't internal. Takes in a single memory allocator for its internal state. For its memory safety you are pretty limited to concerns surrounding read-only-ness of its internal state. Which only exist because the GC allocator might be in use. You pass a value in, you get a value out. No references. ### Owning Owning data structures come with two subsets which may be mixed to form a third combined subset. Cleans up Takes in two memory allocators, one for its internal state, one for its deallocation of values. Will deallocate any memory given to it, which also means that once memory is placed into it, it now owns it and is responsible for its cleanup. As for memory safety you have only one (as long as you don't use references out). Owner escape analysis, this is a DIP Walter has required for me to work on before reference counting. So its going in anyway. References out I'll assume here that it does not clean up any memory passed in, that you handle this manually, that the data structure is merely an index. In almost all ways its similar to non-owning, one memory allocator, still has the memory safety concerns of the owner. An you also have to worry about borrows typically from a struct acting as a reference. Which once again is resolved with owner escape analysis (noticing a trend yet?). What this tells us is that non-owning data structures can go in pretty much immediately, although there will need to be some remedial work once we get reference counting and with that a solution to read only memory. But of course because Walter wants owner escape analysis first, it doesn't matter, both owning and non-owning will need to go together. Note: concurrent data structures will need the read only memory solution due to the locks (notice a trend yet?) as well. We'll likely want to use long names to differentiate all these behaviors unfortunately. As it could be quite desirable to have all the different variations.
Re: My interest in contributing to the D language and participation in the Symmetry Autumn of code
On Tuesday, 14 May 2024 at 18:42:56 UTC, Dennis wrote: Hello everyone, My name is Dennis and I’m from Nigeria and I want to contribute to the D language, perhaps engage in the upcoming Symmetry Autumn of code, and contribute immensely to the D language and beyond. I’m open to anyone directing me on things to work on. I'd really appreciate that. Hi, Dennis. Nice to meet you. I'll be making the announcement about SAOC 2024 in a few weeks. In the meantime, you can visit the SAOC page to learn everything you need to know about how to apply: https://saoc.io It's still got the info from last year, but very little will change for this year. The application deadline could be different this time, but the rest of the dates should be the same. It will run from September 15 of this year to January 14 of next year. I'll leave it to Razvan Nitu and/or Dennis Korpel to help you with contributing.
