Re: text based file formats
On 19/12/2022 4:56 AM, Robert Schadek wrote: > * xml, there is some code already, the old std.experimental.xml code I've toyed with std.experimental.xml. I'm not convinced that it is a good code base for inclusion. * no return by ref As a bit of a follow up of what we were talking about on BeerConf: Because these are not data structures, they won't own externally facing memory (thats the GC job). So these lifetimes issues with ref should never be encountered. > * make it @safe and pure if possible (and its likely possible) pure is always a worry for me, but yeah @safe and ideally nothrow (if they are forgiving which they absolutely should be, there is no reason to throw an exception until its time to inspect it).
Re: Beerconf for dconf online 2022
Hope everyone got your brews ready! I for one, have some nice cold iced water, in 29 degree temperatures you must stay hydrated! https://meet.jit.si/Dlang2022DConfOnline
Re: Beerconf for dconf online 2022
On 16/12/2022 1:53 AM, rikki cattermole wrote: Reminder this is happening tomorrow! In ~24 hours Will be posting in about an hour. Get your brews if you haven't already!
Re: DConf Online '22 this weekend! Videos are up!
Here is a mailto link that'll setup an email ready to go! mailto:q...@dlang.org?subject=PersonToAsk=Question%0D%0A%0D%0A--%20YourName%20anonymous%3F%0D%0A%0D%0AI%20want%20a%20prize!
Re: Beerconf for dconf online 2022
Reminder this is happening tomorrow! In ~24 hours
Re: Beerconf Noveber 2022 -- Turkey edition
https://meet.jit.si/Dlang2022NovemberBeerConf
Re: Beerconf Noveber 2022 -- Turkey edition
~T-3 hours Time to go acquire your favorite brews if you haven't already!
Re: D + Qt + QtDesigner
Don't forget about UI automation too! That's a key feature people always seem to forget... (unless you require it).
Re: Beerconf Noveber 2022 -- Turkey edition
On 18/11/2022 2:16 PM, Ethan Watson wrote: On Saturday, 12 November 2022 at 21:51:38 UTC, Steven Schveighoffer wrote: # BEERCONF! Reminding myself to remember this for a change. Don't worry, you won't miss it this time! I'll bug you everywhere I can when I (or someone else) put the link up ;)
Re: Release D 2.101.0
On 16/11/2022 2:13 PM, torhu wrote: On Tuesday, 15 November 2022 at 20:54:03 UTC, Iain Buclaw wrote: Glad to announce D 2.101.0, ♥ to the 63 contributors. For some reason my project build fails with this version, but only the x86 release build. Only tried it on Windows. This is the error, I'll post a bug report if I can narrow it down more: Error C:\prog\dmd\windows\bin\dmd.exe failed with exit code -1073741795. Yeah, you'll want to use dustmite. Hopefully the project isn't too big.
Re: Call for action: Easily improve D's ecosystem - DUB documentation improvements
I've filled in some details about shared libraries wrt. plugins the issue for it. Will need compiler specific information CC: Walter, Martin, Iain. Still massive shame that dmd is still a write off for Windows support when using D from D. Wahoo export + ModuleInfo + DLLs. Oh and don't forget about the no Unicode exported on Windows!
Re: Beerconf October 2022
On 02/11/2022 4:05 AM, Mike Parker wrote: On Tuesday, 1 November 2022 at 11:54:45 UTC, data pulverizer wrote: It might just be my browser (Chrome) but I've noticed that there's nothing in the events calendar (https://dlang.org/calendar.html). Wouldn't it be helpful to include these sorts of things in the calendar so that people visiting the site would be aware of them? I don't think anyone involved in organizing BeerConf knew that was there. That's the first I've seen it. I've certainly seen it before, but its not like I have access to it (assuming it works).
Re: Beerconf October 2022
And now for some good news! Its almost Halloween, so grab your candy and any spooky brews you may have, and join us for a ghostly chat! https://meet.jit.si/Dlang2022OctoberBeerConf
Re: D Language Foundation Meeting September 2022 Monthly Meeting Summary
On 18/10/2022 3:10 AM, Mike Parker wrote: ### Iain Over the preceding month, Iain had little going on with D due to a personal situation. Most of the work he'd done had been on the infrastructure project and not on the compiler. He noted that I had migrated the dlang.org and dlang.io DNS servers to Cloudflare, and that several records had failed to transfer across (we had some other hiccups, but Iain, Vladimir Panteleev, Petar Kirov, and Mathias Lang, provided invaluable assistance in resolving those). We had managed to recover most of them. I wonder if this has anything to do with run.dlang.org is using a certificate for run.dlang.io for a while now (and hence not usable). But either way, awesome work everyone!
Re: Beerconf September 2022
Linkity link: https://meet.jit.si/Dlang2022SeptemberBeerConf
Re: Meanwhile on the audio front
Very nice and exciting! Congrats everyone.
Re: Introducing alid
On 14/09/2022 8:44 PM, Ali Çehreli wrote: On 9/12/22 09:34, rikki cattermole wrote: > dub.json > errornogc/alid/errornogc.d > circularblocks/alid/circularblocks.d Considering I may want to let the users import the entire package as well with import alid; how can I achieve my goal of subpackages? Telling me to forget about subpackages altogether :) is an option because I've already spent hours trying to find my way through different directory structures, random dub.json edits, experimenting with ways of stopping dub from fetching and using the bad version of the repo repeatedly, and many other random things... In your root package you can still have the package.d file. You would use the version added by Dub to detect if you should public import the other modules. > DUB provides version identifier of dependencies for conditional compilation with version conditions. Have_ version identifier can be used for conditional compilation. https://dub.pm/advanced_usage
Re: Introducing alid
On 14/09/2022 2:48 PM, Salih Dincer wrote: I'm far from making a solid recommendation. Immutable with const still doesn't make sense to me. I claim we can live without them. Immutable confuses me a lot. I think we should take control by creating our own types. D Language should be unornamented. We have to have immutable. You need a way in a systems language to say that a given chunk of memory is read only to prevent accidental writes. Of course you are free to lie and say its mutable, but you can't lie to the cpu. It'll error if you try to write to it, resulting in the end of a process.
Re: Introducing alid
On 13/09/2022 4:25 AM, Ali Çehreli wrote: On 9/12/22 07:43, rikki cattermole wrote: Looks pretty well tested, nice! Thanks! Proud with 100% coverage. :) I was going to ask about coverage, that is awesome! But in other less nice things, I take it you did not test with GDC? GDC does not support cli args with the same names as dmd. One of these is -mv. So far, I started learning by copying arsd's dub.json. (Thank you, Adam! The misunderstandings are mine. :) ) It has the same issues, which is why I recommended against copying it. The file structure of subPackage/alid/subPackage will not require it and you will not have the cross import issues, where if you depend on errornogc you can also import (and then get linker errors) for circularblocks. If I understand you correctly, the directory structure need to be the following (also introducing src, which is clearly missing :)): alid/src/errornogc/alid/errornogc.d .../circularblocks/alid/circularblocks.d [...] No, you don't need the src directory, the subPackage directory functions as this. So: dub.json errornogc/alid/errornogc.d circularblocks/alid/circularblocks.d That'll work. Can I add a CI step to catch all such issues? It would be awesome if dub provided that. There is: https://github.com/dlang-community/setup-dlang But it doesn't look to support gdc or have been updated in a little while. Guess I need to start pinging people about it. Ali P.S. Another issue is function attributes seemingly used inaccurately but I asked that question on the 'learn' newsgroup already. Ping! ;) I have no solution to that unfortunately beyond template all the things.
Re: Introducing alid
Looks pretty well tested, nice! But in other less nice things, I take it you did not test with GDC? GDC does not support cli args with the same names as dmd. One of these is -mv. The file structure of subPackage/alid/subPackage will not require it and you will not have the cross import issues, where if you depend on errornogc you can also import (and then get linker errors) for circularblocks.
Re: SAOC 2022 Projects
On 29/08/2022 11:46 PM, Mike Parker wrote: ### Lucian Danescu Lucian gave [his first DConf talk this year](https://youtu.be/ksNGwLTe0Ps?t=21650) on the subject of integrating DMD as a library with D-Scanner. And that's the project that he submitted, and that the judges accepted, for SAOC. To Lucian: If you need someone to ping for dlang-community side of things, I'm available @rikkimax for admin-y stuff.
Re: Beerconf August 2022
Its live! https://meet.jit.si/Dlang2022AugustBeerConf
Re: my d blog has idea of effect system to replace @nogc etc
On 17/08/2022 3:05 AM, Guillaume Piolat wrote: On Tuesday, 16 August 2022 at 15:01:05 UTC, rikki cattermole wrote: But one key difference is it is designed to work with the GC even if it is -betterC @nogc @safe nothrow. How do you do that? Via dub's injectSourceFiles (that I added). https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/gc_hook.d https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/gc.d https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/allocators/locking.d#L111
Re: my d blog has idea of effect system to replace @nogc etc
And I'm building another. Allocators already working, tons of Unicode stuff implemented. Working on string builders atm. But one key difference is it is designed to work with the GC even if it is -betterC @nogc @safe nothrow.
Re: New WIP DUB documentation
It is pretty awesome, a lot easier to digest and get into!
Re: Giving up
On 07/08/2022 10:45 AM, Walter Bright wrote: On 8/6/2022 1:29 PM, Timon Gehr wrote: Seems you should just use a long double/real literal? real x = 0x1p-16383L; // (works) Looks like that settles it. (Why didn't I notice that? Sheesh!) Needs a better error message. https://issues.dlang.org/show_bug.cgi?id=23284
Re: DConf 2022 pre+watch party!
Iain ended up creating a Jitsi room: https://meet.jit.si/Dconf2022OnlineBeerConf
Re: DConf 2022 pre+watch party!
On 01/08/2022 1:04 AM, Iain Buclaw wrote: How did this work out? :-) It has been low turn out so far, but since everything has had low amount of chatter that isn't too surprising. Shall we start a jitsi meet-up? I'm waiting to hear about the IRL beerconf, see if somebody will join in from there. If they do yeah we should.
DConf 2022 pre+watch party!
Hello everyone! It is back, DConf IRL. To celebrate we will have a bit of a pre-party over in the Discord voice channel, as well as a bit of a watch party going on during the conference live streams. We may switch over to Jitsi later on depending on how the IRL BeerConf goes and if someone ends up joining from there. Discord invite link: https://discord.gg/bMZk9Q4 It all starts tomorrow, so stock up because it's going to be 6 days of D!
Re: Beerconf July 2022
I've been getting a few pings about setting this up, so here it is: https://meet.jit.si/Dlang2022JulyBeerConf No password.
Re: Druntime merged into dmd repo
Very well done! I do hope this isn't the end, because things like bindings really shouldn't be in the dmd repository.
Re: The D Programming Language Vision Document
On 05/07/2022 11:49 PM, ryuukk_ wrote: Hopefully that includes proper built in Tagged Union, non OOP people need that otherwise we are stuck in C's era of programming C's era of programming also happens to coincide with ML which had tagged unions ;) The C family has never been very expressive.
Re: The D Programming Language Vision Document
On 04/07/2022 7:39 PM, Ola Fosheim Grøstad wrote: Yes, that is a common one that is maintained, but maybe there are BOOST licensed implementations too? One can do an exhaustive test for say two-character normalization against ICU to see if they are compliant. https://www.unicode.org/Public/14.0.0/ucd/NormalizationTest.txt My implementation passes this :3 It should be complete test cases.
Re: The D Programming Language Vision Document
On 04/07/2022 5:30 PM, Andrej Mitrovic wrote: Aren't these the polar opposites of each other? The GC is one of D's strengths, yet we should avoid it as much as possible in the standard library. Not necessarily. It could and should most likely mean that it won't do any heap allocations. Heap allocations are expensive after all.
Re: The D Programming Language Vision Document
We have a perfectly good Unicode handling library already. (Okay, little out of date and doesn't handle Turkic stuff, but fixable). The standard one is called ICU. Anyway, we are straying from my original point, that limiting ourselves to the string alias and not supporting wstring or dstring in Phobos is going to bite us. Its not what people expect, its not what we have supported and code that looks like it should work won't. There better be a good reason for this that isn't just removing templates.
Re: The D Programming Language Vision Document
On 04/07/2022 8:16 AM, Ola Fosheim Grøstad wrote: On Sunday, 3 July 2022 at 19:32:56 UTC, rikki cattermole wrote: It is required for string equivalent comparisons (which is what you should be doing in a LOT more cases! Anything user provided when compared should be normalized first. Well, I think it is reasonable for a protocol to require that the input is NFC, and just check it and reject it or call out to an external library to convert it into NFC. Anyway, UTF-8 is the only format that isn't affected by network byte order… So if you support more than UTF-8 then you have to support UTF-8, UTF16-LE, UTF16-BE, UTF-32LE, UTF-32BE… That is five formats for just a simple string… and only UTF-8 will be well tested by users. :-/ https://issues.dlang.org/show_bug.cgi?id=23186 We only support UTF-16/UTF-32 for the target endian. Text input comes from many sources, stdin, files and say the windowing system are three common sources that do not make any such guarantees.
Re: The D Programming Language Vision Document
On 04/07/2022 7:18 AM, Ola Fosheim Grøstad wrote: I hardly ever use anything outside UTF-8, and if I do then I use a well tested unicode library as it has to be correct and up to date to be useful. The utility of going beyond UTF-8 seems to be limited: https://en.wikipedia.org/wiki/UTF-32#Analysis I have just finished implementing string normalization which is based around UTF-32. It is required for string equivalent comparisons (which is what you should be doing in a LOT more cases! Anything user provided when compared should be normalized first.
Re: The D Programming Language Vision Document
On 04/07/2022 6:10 AM, Ola Fosheim Grøstad wrote: People who are willing to use 4 bytes per code point are probably using third party C-libraries that have their own representation, so you have to convert anyway? If you use Unicode and follow their recommendations, you are going to be using dstrings at some point. For example, string equivalence, and anything to do with case is going to use them and very likely to require multiple memory allocations to do it. Its just an unnecessary goal, when most of the string algorithms we have probably don't care about the encoding and those that do probably will be using dstrings.
Re: The D Programming Language Vision Document
> Stronger integration with other languages One of the things I judge D's compilers by is how well they can build a shared library. This is crucial for a lot of different applications of D and can be an complete stopper in using D if it doesn't "just work". To be blunt this is embarrassing, this should have been a top priority 10+ years ago... > Phobos and DRuntime I am very worried that this is going ahead without signatures. Its a major usability issue that concepts like ranges are not written into a function signature and is a common tripping point for people new to the language. I've been meaning to talk with Walter about this, this year. Times just haven't lined up at BeerConf to sort out lining up my designs into something that could actually go in. > No wstring or dstring. Any functions in Phobos v2 that deal with strings should deal exclusively with the string type. Users can convert from and to the other string types as needed. NOPEEE That's going to bite us big time when it comes to Unicode handling which wants to work with dstring's. > Provide automatic CI for actively-maintained third-party projects. I would like a big endian system to be included if possible, if a library is actively maintained you don't want surprises to arise from that.
Re: Beerconf June 2022
In celebration of Matariki (the Māori New Year) of the 24th, and Ethan's birthday, lets start Beerconf! So happy birthday Ethan and remember, today is all about togetherness! https://meet.jit.si/Dlang2022JuneBeerConf https://www.newzealand.com/nz/matariki/
Re: Intellij D Language plugin v1.28.1
Very nice. Only one error in about 30 minute time frame. Significantly down! :D Thanks.
Re: Intellij D Language plugin v1.28.0
Looking good so far! Been watching keenly on this release, cheers!
Re: Beerconf May 2022
Adam created the link this time: https://meet.jit.si/Dlang2022MayBeerConf No password
Re: A New Game Written in D
On 19/05/2022 7:03 AM, H. S. Teoh wrote: We keep coming back to this impasse: write barriers. It's high time somebody implemented this in a dmd fork so that we can actually test out more advanced GC designs. No. Not dmd. LDC or GDC. DMD is not suitable for experimentation due to the situation with atomics. Advanced GC's may need concurrent data structures like lock-free, and you cannot implement them with dmd due to the atomic instructions being 3 function calls deep. You get segfaults. Been there done that, what a waste of 7 months.
Re: A New Game Written in D
On 19/05/2022 5:51 AM, Kenny Shields wrote: Also, I know that D has some sort of interface for allowing custom GC implementations -- has anyone ever made a functional alternative? Something that takes the incremental approach that you mentioned as opposed to the pause and scan method? Severely doubtful, like pretty much all the advanced GC designs, it appears to require write barriers (book barely touches on it however). https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795
Re: Beta 2.100.0
Its compiled in statically to Phobos (however this may depend on compiler ext.).
Re: Release D 2.100.0
Very excited for this release! Still waiting on a documentation PR for dub, kinda need to get this merged + deployed since the feature is now live. https://github.com/dlang/dub-docs/pull/43
Re: Release: serverino - please destroy it.
On 12/05/2022 11:33 PM, Andrea Fontana wrote: Too bad dub doesn't work with wsl, it sounds like a lost opportunity. Does dmd/rdmd work? Serverino uses std.net.curl just for running its unittests, so maybe that bug is not blocking. It doesn't look like it is dub that is failing. This is a problem in Phobos/compiler.
Re: Library associative array project v0.0.1
On 12/05/2022 4:55 AM, templatedperson wrote:
for a good reason, the default is the GC.
Good reason or not, people sometimes need to do manual memory management.
I usually use the GC and like that we have it, but if you care about
performance you gotta drop down to manual managements sometimes. If
libraries don't let users decide what sort of memory management pattern
they want to use we have two languages essentially.
I'd rather all of phobos had overloads with allocator arguments, but
sadly it doesn't.
They are classes hidden inside structs.
I'm well aware of the issues, I have my own -betterC allocator library
(that will hopefully be available soon-ish) that does not have these issues.
```d
struct RCAllocator {
private {
void delegate() @safe @nogc pure nothrow refAdd_;
void delegate() @safe @nogc pure nothrow refSub_;
void[]delegate(size_t, TypeInfo ti = null) @safe @nogc pure
nothrow allocate_;
bool delegate(scope void[]) @safe @nogc pure nothrow deallocate_;
bool delegate(scope ref void[], size_t) @safe @nogc pure
nothrow reallocate_;
Ternary delegate(scope void[]) @safe @nogc pure nothrow owns_;
bool delegate() @safe @nogc pure nothrow deallocateAll_;
bool delegate() @safe @nogc pure nothrow empty_;
}
@safe @nogc pure nothrow:
```
Re: Library associative array project v0.0.1
On 12/05/2022 3:54 AM, templatedperson wrote: 2. Look at alternatives to GC for allocation/deallocation. Maybe add `@nogc` overloads that take `std.experimental.allocator`s? That could be the best way to accomplish this. That won't help much. The virtual types are not @nogc, and for a good reason, the default is the GC.
Re: Release: serverino - please destroy it.
On 09/05/2022 11:44 AM, Ali Çehreli wrote: While we are on topic :) and as I finally understood what generational GC is[1], are there any fundamental issues with D to not use one? This is not a D issue, its an implementation one. We don't have write barriers, that's it. Make them opt-in and we can have more advanced GC's. Oh and book recommendation for the subject: https://www.amazon.com/Garbage-Collection-Handbook-Management-Algorithms/dp/1420082795
Re: GCC 12.1 Released (D v2.100-rc.1)
Well done Iain! We should do a celebration party for both it and 2.100.0 release!
Re: D Language Foundation April Quarterly Meeting and Server Meeting Summaries
For me the bug that is potentially limiting me (design wise) is: https://issues.dlang.org/show_bug.cgi?id=21416 #dbugfix Good stuff moving forward and that tool looks interesting to try out.
Re: Beerconf April 2022
On 30/04/2022 5:22 AM, Adam D Ruppe wrote: On Friday, 29 April 2022 at 17:07:27 UTC, rikki cattermole wrote: Password: `dub4life` I see you are gatekeeping to keep a certain clique out! Lol, given the amount of emotions that has gone into it in recent days I got a little inspired as to what the password should be. But no, no intent on gate keeping.
Re: Beerconf April 2022
It is that time of the month, once again! Beerconf. https://meet.jit.si/Dlang2022AprilBeerConf Password: `dub4life` See you all there!
Re: Beta 2.100.0
This release is very exciting. Semver versioning, lots of shared library support for dub, @mustuse and lots of deprecations + removals.
Re: D Language Foundation Monthly Meeting Summary for March 2022
## Razvan ### Reference counting Going through some old DRuntime pull requests, Razvan found several PRs adding reference-counted things (RCArray, RCPointer, etc) from a period when reference counting was a hot topic in the D community. The problem with reference counting in D has been the transitivity of qualifiers (e.g., you can't reference count an immutable object). Razvan remembered he had drafted [a DIP for a `__metadata` storage class](https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md). In a forum discussion on that DIP, Timon Gehr had pointed out two fundamental issues with it (anyone interested can see [the forum discussion thread](https://forum.dlang.org/post/3f1f9263-88d8-fbf7-a8c5-b3a2a5224...@erdani.org)). Ultimately Razvan's progress stalled and he never submitted the DIP. I stand by my comments about read only memory. A person can still at runtime mark memory as read only, unfortunately I don't know how you can detect this in a compiler and fail compilation because of it. My preference continues to be three new operator overloads methods for classes and structs. opRefAdd, opRefSub, opReadOnly. The first two are like destructors, they ignore const. The last tells the type (must not be const) that it is going into read only memory allowing it to know that it is no longer writable. It would be required if reference counting methods are implemented. The main difference to __mutable which was argued that it should not allow going into read only memory is that: the compiler can't detect if the user does it, but can prevent itself from doing it. That gives a very false sense of guarantee that it will not be. Where as with this approach it is clearly the responsibility of the one who put it into read only memory to call the method and for the programmer who wrote the type to have done the right thing in the methods. Giving no guarantees and hence no sense of security. ### Attribute inference on private functions Mathias thinks that inference on private functions is something everyone would want. It's something he heard Walter mention in the past. The current blocker on that is that attribute inference doesn't work for recursive functions. He thinks the solution is simple: you should assume that the function has all the attributes; if you recurse on yourself, the rest of the code will help you infer the attributes. Walter said that makes sense; the more attribute inference we can do the better. +1 infer everything! I suspect you can do some quick and cheap tests in the parser to determine if given a function scope if a given attribute such as @safe should be inferred later on. If done well, it could mean @safe by default! ## Andrei He started by arguing that reflection on built-in bitfields is "just warped". You're going to have things less than 8-bit and to which you cannot take a pointer. Any proposal for bitfields must account for that. Walter's solution of having `__traits(getMembers)` return an aggregate is only half of the story. What about the getters and setters? A library solution has those, but for the built-ins, they're compiler magic. Martin agreed (and this is his main sticking point; he brought it up in the last meeting). enum __c_bitfield; is(typeof(value.bitfield) == __c_bitfield) As long as .sizeof is the real size accounting for "empty" bits and alignment that should be a fairly safe way to go. It accounts for a single pointer and requires a special reflection mechanism to get the tuples of number of bits + names + types.
Re: Beerconf March 2022
Hello hello hello! Beerconf is inviting you to a meeting. Join the meeting: https://meet.jit.si/Dlang2022MarchBeerConf Password: `ValueTypeExceptions` **How do I join?** You'll need to have a [compatible browser](https://jitsi.github.io/handbook/docs/user-guide/supported-browsers) to connect to the meeting. Alternatively you can install jitsi-meet with flatpak. **Wait, it's not Saturday?** Timezones are weird, right? **OK, so what do I do?** Join and [wear your Beerconf T-Shirt](https://www.zazzle.com/store/dlang_swag?rf=238129799288374326).
Re: DIP 1035, "@system Variables", Formal Assessment Has Begun
Changes look good +1
Re: Beta 2.099.0
There are a few goodies hiding in the nightlies that didn't make it into the beta. Stuff like https://issues.dlang.org/show_bug.cgi?id=18362 And https://dlang.org/changelog/pending.html#actual-dynamiclibrary (which I did :3) This is gonna be a good release I think!
Re: DConf 2022 in London?
On 17/02/2022 6:37 PM, StarCanopy wrote: On Tuesday, 15 February 2022 at 12:22:05 UTC, Mike Parker wrote: [...] I regret not getting into D sooner, when I could have driven to a dconf. There will be plenty of stuff online. Depending on how BeerConf will be scheduled I'm sure we could do something on Discord as well.
Re: DIP 1038--"@mustUse" (formerly "@noDiscard")--Accepted
On 10/02/2022 5:21 AM, Paul Backus wrote: - C (gcc/clang): __attribute__((warn_unused_result)) C23 will also have [[nodiscard]] Not only will it have that on functions, but also support a string too. Unfortunately its looking like we have chosen to diverge from C, and therefore won't be completely C compatible soon. Will be exciting as to what kind of bugs crop up because of this!
Re: Beerconf January 2022
BeerConf is among us once again! https://meet.jit.si/Dlang2022JanuaryBeerConf Password: @mustUse
Re: All Community Discord channels are now being bridged to Matrix
On 16/01/2022 12:45 PM, Ali Çehreli wrote: On 1/15/22 10:45, WebFreak001 wrote: > we have now bridged all the Discord rooms to Matrix rooms. What does all that mean? Is that something that only Discord users should understand be interested in? :) Ali This is for Matrix users, so that they may communicate with the Discord channels without using Discord. If you don't use Matrix, you can ignore this.
Re: DMD now incorporates a disassembler
On 09/01/2022 4:01 PM, Walter Bright wrote: I buried my PDP-11 long ago. Sob. There is a kit for the control panel[0]. Backed by a raspberry pi. I'm pretty keen to eventually buy one and build it. These kits are cool! [0] https://www.tindie.com/products/obso/pdp-11-replica-kit-the-pidp-11/
Re: Classes in D with betterC
On 21/11/2021 3:13 PM, russhy wrote: betterC already is niche on its own, so let's do the move? Except -betterC is not niche at all. It is simply the language with any of the runtime dependencies disabled. No language level changes have to be made for this. Both full D and -betterC should eventual converge as we make druntime pay as you go.
Re: Beerconf for Dconf
It is 2 hours before DConf starts! I welcome everyone to hope on over to Discord and join our General voice channel while we wait for the action to begin.
Re: Beerconf September 2021
On 27/09/2021 7:05 AM, Brian wrote: What is Beefconf, indeed. Are we getting an additional online meetup this month? :) Considering I was running polls about giving beef to dogs during BeerConf, I'm afraid that it has already passed. But maybe we can do something impromptu on Discord in like 5 hours if people want ;)
Re: Beerconf September 2021
The link will be added closer to the time (its immediately available). From there, just use a compatible web browser.
Re: Beta 2.097.2
On 10/08/2021 4:32 AM, Tejas wrote: Just switch to LDC? The discussion on bugzilla seems to conclude that its purely DMD backend problem. While that is a good workaround to issues like this, dmd-be does need to be fixed regardless.
Re: Beerconf July 2021
On 16/07/2021 11:45 PM, Iain Buclaw wrote: Just a forewarning, it was brought to my attention last month that for some people, Beerconf would fall on the Sunday/Monday 25-26th for them. Why? If you're living in Apia, Saturday 24th July would begin on Friday 23rd at 13:00 CEST, while in neighbouring Alofi, Sunday 25th ends on Monday 26th at 13:00 CEST. Wooow, thanks Iain!
Re: LDC 1.27.0-beta3
Will -fvisibility=public support be upstreamed into dmd? If yes, it might be worth it to get rid of export as a keyword out right in a DIP (as it introduces the possibility of linker errors that would otherwise not need to exist).
Re: LWDR (Light Weight D Runtime) v0.3.0
On 10/07/2021 2:30 AM, lili wrote: Why standard D Runtime can not run on MCU? It requires things like threads. Basically it assumes there is a kernel. Anyway, you don't want the regular runtime on a MCU, a MCU is too small in memory to really hold it all and your own logic and any libraries you need for the hardware its connected to.
Re: LDC 1.27.0-beta1
On 06/06/2021 4:53 AM, kinke wrote: - Greatly improved DLL support on Windows, including bundled druntime and Phobos DLLs, making it almost as easy as on Posix. Nicee!
Re: From the D Blog: Driving with D
On 04/06/2021 8:50 PM, Max Samukha wrote: On Tuesday, 1 June 2021 at 11:57:34 UTC, Mike Parker wrote: Dylan Graham writes about his experience using D in a microcontroller project and why he chose it. Does anyone know of any similar projects using D? I don't. This may well be the first time it's been employed in this specific manner. The blog: https://dlang.org/blog/2021/06/01/driving-with-d/ Reddit: https://www.reddit.com/r/programming/comments/nps6k5/driving_with_dlang/ FWIW, I tried D in a simple project using an atmega32a. It almost worked (thanks to Webfreak and LDC people), but there were a couple of issues: 1. No support for ISRs. I had to implement thunks in C calling D. 2. No slices, because 'length' is typed as 32-bit. Worked around by accessing the array's elements via .ptr. 3. No foreach (as a consequence of 2, I guess) Does this form of foreach work? foreach(i; 0 .. 10)
Re: LWDR (Light Weight D Runtime) for Microcontrollers v0.2.3
On 31/05/2021 1:05 PM, Dylan Graham wrote: I haven't put any thought into the license. Since LWDR is derived from DRuntime, I assume I'll have to use its license. If not, I'd like to go with something permissive like MIT. Boost is permissive.
Re: GCC 11.1 Released
On 27/05/2021 1:04 PM, Iain Buclaw wrote: - New aliases have been added to gcc.attributes for compatibility with ldc.attributes. mm compact, very nice!
Re: From the D Blog -- Interfacing D with C: Strings Part One
On 25/05/2021 3:39 AM, zjh wrote: use chrome ,cannot open the DEV. press `F12` of no use. `Alt+U`of no use. continue rotating the small circle.You can do nothing. There is something seriously wrong with your install then. It isn't related to the website itself.
Re: From the D Blog -- Interfacing D with C: Strings Part One
Use the dev tools, network + performance tabs could be very useful information for debugging this.
Re: Contacting DlangScience maintainers
On 31/03/2021 7:28 AM, Chris Piker wrote: Since I'm not orphaning packages soon and since physical science packages have a relatively small user base, it sounds like interaction with the dlang-community group is not recommended at this time. It is neither not recommended, nor recommended. Get something solid that people want to use, then it doesn't matter about how many people are available to maintain it. Dlang-Community exists primarily as a backup in case of the original owners disappear (doesn't matter why, could just by life and only be gone for a year or two). See: https://github.com/dlang-community/discussions
Re: Contacting DlangScience maintainers
On 30/03/2021 3:55 PM, James Blachly wrote: Does this [hiding to non org members] really help D's visibility and adoption? What sorts of things are discussed that do not benefit from openness? For example, I am a bona fide scientist using Dlang, but had no idea dlang-science was even an active group (I was aware of the org, and repos, but assumed it was not very active) As far as I know its not actively used. Both teams and the discussion feature Github offers them. And yes I did try to make it public, that wasn't an option.
Re: Contacting DlangScience maintainers
On 29/03/2021 12:16 PM, Chris Piker wrote: On Sunday, 28 March 2021 at 04:06:57 UTC, mw wrote: On Friday, 26 March 2021 at 21:55:18 UTC, Chris Piker wrote: Let's discuss it here: https://github.com/orgs/dlang-community/teams/science/discussions @wilzbach is the maintainer of the group. Sounds good to me, but the link above returns a 404, could be a temporary error. Maybe I'm supposed to join a team first? "A visible team can be seen and @mentioned by every member of this organization."
Re: Beerconf March 2021
On 28/03/2021 2:45 PM, Dylan Graham wrote: I might join some time after work (late afternoon) AEST if you guys will still be on. I have some progress updates on the D powered automatic gearbox system and a new project I've got in the works. Ah huh an aussie. I'll be on in the AM from CHCH with voice (cam is very art worky).
Re: Windows Bindings v1.0
On 17/02/2021 9:45 AM, Rumbu wrote: On Tuesday, 16 February 2021 at 08:53:06 UTC, rikki cattermole wrote: All of the symbols and modules need to be documented so that the documentation generators will generate documentation for them. Sincerely, I doubt that it's a good idea to duplicate gigs of WinAPI documentation which can be found on the official Microsoft sites. Or may be you want to stress test the D compiler when it's generating documentation :) Its documented (partially). https://github.com/dlang/druntime/blob/master/src/core/sys/windows/aclui.d#L1 Note I am only talking about some ///'s at the end of the line. https://dlang.org/spec/ddoc.html#parsing
Re: Windows Bindings v1.0
On 16/02/2021 9:45 PM, Rumbu wrote: The D Windows SDK projection reached first version. Generated bindings were compiled succesfully. https://github.com/rumbu13/windows-d Destroy! All of the symbols and modules need to be documented so that the documentation generators will generate documentation for them. By the looks a good percentage of DirectX is in there. Which is wonderful. I checked as it will be important for a project like this, but it doesn't seem like the docs around IUnknown is correct. https://dlang.org/spec/interface.html#com-interfaces It seems the exact location for IUnknown doesn't matter. Great work!
Re: LDC 1.24.0-beta1
On 26/10/2020 8:14 PM, Patrick Schluter wrote: You underestimate how spoiled windows developer are. Even these simple step are completely out of character for most software on the platform. 20 years ago it wasn't a problem, now on Windows 10 it's a whole other story. How many clicks to get the dialog to set PATH? On NT4 it was 2 clicks, now on Windows 10 I still haven't figured out how to do it without searching like a madman. To make it short. The Windows platform is getting more and more hostile to manual tuning. Right click start menu, System -> System Info -> Advanced system settings -> Environment variables Or: Open start menu: type "environment", select "Edit environment variables for your account" Windows is hiding stuff that the majority of users should not need to know about. But everything is easily accessible if you know what you want to do (well everything except changing updates).
Re: Visual D 1.0.0 released
On 10/07/2020 9:04 PM, Walter Bright wrote: I hope cv2pdb is in D, as that is a fine way to get C++ people used to D! https://github.com/rainers/cv2pdb Nope.
Re: Visual D 1.0.0 released
On 09/07/2020 10:22 PM, Manu wrote: Then the general autocomplete engine, which is fairly dependent on the detail expressed in the project files. DCD is due for a rewrite into using dmd-fe. However as it stands, I do not believe it is mature enough to use as a library for this purpose. So I commend Rainer for helping to mature it! It'll help in the long run to get IDE's up to VisualD's experience for everything but debugging.
Re: DIP 1028 "Make @safe the Default" is dead
Thank you Walter.
Re: DIP 1028--Make @safe the Default--Formal Assessment
On 28/05/2020 12:33 AM, aberba wrote: On Thursday, 21 May 2020 at 18:36:51 UTC, H. S. Teoh wrote: On Thu, May 21, 2020 at 05:49:27PM +, Paul Backus via Digitalmars-d-announce wrote: [...] Even if we suppose for the sake of argument that the decision is sound on a technical level, this is poor leadership, and bodes ill for the future of the D language and its community. D excels at the technical aspects, but time and time again has shown that it lacks proper management / leadership. Contrary to my own inclinations I'm compelled to suggest hiring a *non-technical* person to take up the management/leadership roles (emphatically non-technical, because let's face it, we techies just don't have the people skillz it takes to do this properly), because the current situation clearly isn't working, and is quite detrimental to D and its future. T Ha ha. I tried suggesting something like this some yrs ago as I saw it happen and deadalnix bashed me like crazy. Didn't articulate it as well as you just did though. This needs to happen. I've been saying since 2012 that we need a project manager to help with communication. Mike has taken on parts of this role and has done quite a good job of it.
Re: DIP1028 - Rationale for accepting as is
On 27/05/2020 10:12 PM, Johannes Loher wrote: Am 27.05.20 um 11:25 schrieb Walter Bright: On 5/24/2020 3:40 AM, Stefan Koch wrote: The distinction is that you can find a slapped on trusted with a grep. It's just as easy to use grep to *not* find @trusted. But that's not enough. You need a regexp that searches for extern (C(++)) declarations that do not have any of @safe, @trusted, @system. The attributes can also be either before the return type + name + parameters or after it. They can also be mixed with any other attributes. Sure, you can probably write a regex that matches all of this but it is a _lot_ more complicated than simply searching for @trusted. extern(Windows) extern(System) COM Few more things there.
Re: DIP1028 - Rationale for accepting as is
On 27/05/2020 10:03 PM, Walter Bright wrote: Frankly, I feel that if I could sit down with you folks, I can get the idea across what I'm trying to accomplish. Okay, how is your camera and mic situation? Lets do a Twitch stream, make sure there are some moderators in place as well. Open to everybody and it can be recorded by Twitch.
Re: DIP1028 - Rationale for accepting as is
On 27/05/2020 9:50 PM, Walter Bright wrote: BTW, one good thing that has come out of this issue is people are strongly in favor of what @safe does. That bodes well for DIP1000 and the @live code, for a long time I seemed to be the only one who cared about it. Most of the arguments against @safe by default I have seen over the years (including from me) originate in /how/ to make it default, not in it becoming the default. For me at least, I will not ever want to use @live, pointers with multiple behaviors depending on how it is used which don't change the syntax? No thanks, I thought we had learned that was a bad idea. But a head const storage class that handles lifetimes with no extra syntax thanks to DIP25/1000, yes please! I will use that.
Re: DIP1028 - Rationale for accepting as is
On 25/05/2020 10:29 PM, Zoadian wrote: you complain about @trusted losing it's meaning, but @safe was ment to mean "mechanically verified memory safety". it should be forbidden to add @safe to any function that can not be verified by the compiler. It is meant to mean that at some point it has been mechanically checked by the compiler. Either during current compilation or a prior one. Which means it has to be valid on function declarations without bodies so i.e. .di file generation works correctly which is just a generated D file, nothing special syntax of semantics wise.
Re: DIP1028 - Rationale for accepting as is
On 23/05/2020 5:40 AM, Atila Neves wrote: On Friday, 22 May 2020 at 17:33:11 UTC, rikki cattermole wrote: On 23/05/2020 5:07 AM, Atila Neves wrote: [...] It is not about the linkage. The problem is solely does the compiler have the source to the function body to verify it? That's what I meant, sorry for not making it clearer. It kept being swapped about in the discussion thread, so I have been a little on edge over people using non-extern(D). Because linkage doesn't mean anything to anything but to cpu and linker in this discussion. [...] That is a failure of the language that should be resolved. And how do you suggest we fix it? I don't know. It is a problem that needs to be explored in more detail. Adam had one idea that I convinced him to write up, but that didn't get very far when commented relating to propagation of attributes. Major changes like this, should have been discussed and RFC'd instead of going to straight to a DIP. That is effectively what happened. [...] No. We simply do not agree, nor do I expect for us to come to terms on it anytime soon. I meant "did I explain myself well enough that now you understand where I'm coming from, even though you might not ultimately agree?". Yeah. - I didn't look at the binding, since you described it well previously, but of note is that you used @safe. What you should have used is @trusted instead. If the programmer wants to slap @trusted: at the top of the file, I have no problems with that. You checked it (i.e. its LLVM, so of course its fine!).
Re: DIP1028 - Rationale for accepting as is
On 23/05/2020 5:07 AM, Atila Neves wrote: On Friday, 22 May 2020 at 12:28:56 UTC, rikki cattermole wrote: On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote: With the rationale laid out clearly as it is here, I do have some responses in mind. But before sharing them, I'd like to know whether that would be useful right now: I've no wish to just press for a re-hashing of conversations that have already been had. No. This wasn't the first and certainly won't be the last time we as a community have been very unhappy with how Walter conducts himself with his DIP's. Although it seems an improvement has been made to how he needs to respond to the DIP assessment. It should also include a statement from Atila as well given his position. I'm going through posts in order, so apologies if I'm "ignoring" something that shows up later in the discussion. Personally and initially, I would have preferred it if non-extern(D) declarations were implicitly @system. I understood Walter's argument about special cases and how they're bad, but the thought of them being @safe made me feel, for lack of a better word, "icky". This is one of the issues I had a problem with. It is not about the linkage. The problem is solely does the compiler have the source to the function body to verify it? Then I talked to Walter and he pointed out that if those declarations were @system, users would be prevented from calling them from now @safe code. A regular user would probably just slap `@safe:` at the top of the bindings module anyway. Then I realised that I did exactly that with my libclang bindings: https://github.com/atilaneves/libclang/blob/5415707fa6072700bdbf21f827567ffa2fd5c424/source/clang/c/index.d#L254 That is a failure of the language that should be resolved. One of the arguments that has been brought up (although I don't remember if it made its way to the N.G.) is that if you don't have the body, can a function /even/ be @safe? "Worse", I made all functions `pure` and all parameters `in` as well for good measure. Why? I wanted to call them from my @safe pure code with `const` arguments. My reasoning at the time was "I trust libclang". You might, but that doesn't give the compiler the right to do so by default. This a decision for a skilled programmer to make. And so I was convinced that everything being @safe is actually ok, especially because in real life, most C/C++ APIs aren't going to secretly corrupt your code. What you did was give up some security in favor of freedom and now you can't get certified to work on top secret projects (analogy). Then there's the fact that, today, there's no safety anyway calling anything because everything is @system by default. And D source code won't be able to lie. Does that clear it up? No. We simply do not agree, nor do I expect for us to come to terms on it anytime soon. To me at least, this butchers @safe/trusted/system into a system that is near useless for guarantees for an entire program. Sure its convenient for a single function, but absolutely useless in trying to solve the actual problem it was trying to solve in the first place.
Re: DIP1028 - Rationale for accepting as is
On 23/05/2020 12:19 AM, Joseph Rushton Wakeling wrote: With the rationale laid out clearly as it is here, I do have some responses in mind. But before sharing them, I'd like to know whether that would be useful right now: I've no wish to just press for a re-hashing of conversations that have already been had. No. This wasn't the first and certainly won't be the last time we as a community have been very unhappy with how Walter conducts himself with his DIP's. Although it seems an improvement has been made to how he needs to respond to the DIP assessment. It should also include a statement from Atila as well given his position.
Re: BindBC Updates: new loader function, SDL_net, streamlined SDL_* version indentifiers
On 22/05/2020 12:21 PM, Daniel C wrote: Can this library be used in a 64-bit build? I only see the one lib, and was curious if the function definitions make any assumptions about argument size or stack configuration etc. There are no binary files provided in the bindbc-sdl repository. https://github.com/BindBC/bindbc-sdl It is a binding, it should match 1:1 definition wise to the C definition.
Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)
On 05/05/2020 9:05 PM, Robert M. Münch wrote: On 2020-05-04 21:34:27 +, rikki cattermole said: On 05/05/2020 7:26 AM, notna wrote: Maybe you want to add an additional constraint... It would be great if this would result in a tool, scripts or at least a simple-to-follow to-do (say Wiki?!)... so best case we could use this also for the next updates / releases in the future?! The reason we can't just grab a newer copy of the unicode database and throw it into Phobos is because the format was changed. Sure, nevertheless, I think it makes sense to have the reproducibility of the process in mind. Maybe not with a script that lasts for 10 years. But the process, some tools for a specific version, which can be used as inspiration for upcoming changes. Strange, I thought they were in the repo. Okay after looking through his fork of Phobos to see if its lying around somewhere, it looks like we need to hear from Dmitry Olshansky.
Re: $750 Bounty: Issue 16416 - Phobos std.uni out of date (should be updated to latest Unicode standard)
On 05/05/2020 7:26 AM, notna wrote: Maybe you want to add an additional constraint... It would be great if this would result in a tool, scripts or at least a simple-to-follow to-do (say Wiki?!)... so best case we could use this also for the next updates / releases in the future?! It wouldn't help. The reason we can't just grab a newer copy of the unicode database and throw it into Phobos is because the format was changed.
