Re: SLF4D - A proposal for a common logging interface for Dub projects
On Wednesday, 22 February 2023 at 21:46:32 UTC, Andrew wrote: I've been spending some time in the last few weeks to prototype a logging framework that's inspired by [SLF4J](https://www.slf4j.org/). To that end, I've created [SLF4D](https://github.com/andrewlalis/slf4d), which provides a common logging interface, and a pluggable architecture to allow third-parties to handle log messages generated by any logger in an application. Why not std.experimental.logger?
Re: D Language Foundation Quarterly Meeting, October 2021
On Monday, 8 November 2021 at 12:02:43 UTC, Atila Neves wrote: On Saturday, 6 November 2021 at 15:46:57 UTC, JN wrote: On Friday, 5 November 2021 at 13:19:24 UTC, zjh wrote: D can aim at `experts`, especially `meta programming users`. On this point,`rust` can't compete. `Silky general meta programming`. Use my `strengths` to attack theirs weaknesses. This is much less of a strength than you think. For 90% of cases, lack of metaprogramming is resolved by putting a Python script in build step that autogenerates the necessary code. Python has no idea about D syntax or semantics (or any other language not called Python), and therefore can't even do something as simple as "what are all the D structs in module x". You'd have to invent a templating language on top of the code you're already writing, then write some Python code to parse and generate on top of *that*. To me, that's like saying that C/Fortran aren't that big of a deal compared to assembly. Who needs for loops, amirite? What C# does and what's probably easier for tooling and newbes is to let users hook into the compilation step and generate code on the fly given full compiler knowledge to the already existing code prior to generation.
Re: Mir Ion and Asdf benchmakrs
On Sunday, 16 May 2021 at 09:50:21 UTC, 9il wrote: mir-ion and Asdf JSON libraries have been added to the Kostya/benchmarks. https://github.com/kostya/benchmarks#json If we exclude parsers with inaccurate number parsing then the top will be 1. C++, simdjson 2. Rust, Serde 3. Dlang, Mir Amazon's Ion DOM 4. Dlang, Mir Asdf DOM 5. C++ RapidJSON (Precise) Mir Ion has been inspired by simdjson and Amazon's Ion binary format, which is used as DOM. Thus the mir-ion DOM for the 112 MiB file costs 16 MiB comparing with 176 MiB DOM in simdjson. Kind regards, Ilya Great work! What makes simdjson faster?
Re: Our community seems to have grown, so many people are joining the Facebook group
On Wednesday, 30 December 2020 at 02:31:36 UTC, Murilo wrote: On Tuesday, 29 December 2020 at 15:06:07 UTC, Ola Fosheim Grøstad wrote: No, the OP clearly stated that he made the group "official". That is a deliberate attempt to fracture. I'm sorry you see it like this but my intention when I created the group was to expand Dlang by bringing it to places people couldn't find it yet. The whole point of the FB group is to aggregate people into our community, to bring more people to Dlang and make Dlang famous. My whole intention was to help our community grow, not fracture. No need to be sorry. Keep up the good work. There is a tendency around here to kill the good that is for the better that never will be. Don't get discouraged by this. If I had facebook, I'd join.
Re: Our community seems to have grown, so many people are joining the Facebook group
On Tuesday, 29 December 2020 at 11:34:38 UTC, Ola Fosheim Grøstad wrote: Not quite, if you split up then each community might have stronger social bonding, but in terms of aggregating helpful advice you will be worse off. It would be suitable for geographic groups (e.g. for a country/city). For instance slashdot is very poor in social boding terms, but much better than the dlang forums for aggregating helpful advice. So the "learn" forum is beneficial socially, but does erode the slashdot presence. You have a valid point, but still I am sure the facebook group is a net positive for the community. I'd see it as a digital version of a local user group. Would be useful to have the option to post D.learn questions automatically on stack overflow as well.
Re: Truly algebraic Variant and Nullable
On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote: Truly algebraic Variant and Nullable with an order-independent list of types. Thanks for sharing it! Could you give a (very short) explanation on why sumtype could not meet your requirements? I am just starting a new D project and have to choose between sumtype and your solution. The work has been sponsored by Kaleidic Associates and Symmetry Investments. Much appreciated!
Re: during: a io_uring wrapper library
On Sunday, 8 December 2019 at 10:35:24 UTC, tchaloupka wrote: Main difference with C liburing echo server is that we're using preregistered IO buffer so the kernel has less work with it. Otherwise it should perform similarly. [1] https://github.com/tchaloupka/during [2] https://github.com/axboe/liburing [3] https://github.com/tchaloupka/during/tree/master/examples/echo_server I like the range interface.
Re: dud: A dub replacement
On Monday, 18 November 2019 at 19:54:38 UTC, Russel Winder wrote: Probably yes. Though Cargo has taken many different decisions to Dub and mostly I think Cargo took better decisions. Could you elaborate a bit, please? I am not familiar with Cargo though.
Re: Blog Post: Beating std::visit Without Really Trying
On Sunday, 6 October 2019 at 00:52:38 UTC, Andrei Alexandrescu wrote: Anyhow, currently we would have to name it differently (e.g. dts - https://github.com/wilzbach/dts). Maybe the upcoming SAoC project will change this and allow multiple versions of a library to co-exist in a binary. Adding it as a new facility is a possibility, but only if the challenges of keeping the existing interface are too large. I just want to chime in as a returning D user, who stumbled upon Nullable, Typedef and Algebraic. I think is is important to have high quality and well supported versions of these kinds of type constructors in the standard library, because to really shine support for them has to be pervasive. I could roll my own (or use some package from code.dlang.org), but one of the key features have to be that they 'just work'. I want to std.conv.to them [1], use them in a json serialization library out of the box, etc, etc. [1] https://issues.dlang.org/show_bug.cgi?id=11704
Re: 2015 H1 Vision
KDE is a german e.V. (eingetragener Verein, registered association [1] ). Maybe that's an option for D, too. [1] http://en.wikipedia.org/wiki/Eingetragener_Verein
Re: [OT?] C compiler written form scratch in D
On Wednesday, 10 December 2014 at 17:19:28 UTC, Stefan Koch wrote: On Wednesday, 10 December 2014 at 13:02:43 UTC, Tobias Pankrath wrote: I will use a handwritten recursive decent parser. Since that is what I deem the easiest thing to do. Take a look at the std.lexer proposal first. Thanks for your suggestion. In fact, I know and like std.lexer. But this is an educational project to showcase compiler construction. So everything will be written from scratch. I didn't want to suggest to use std.lexer, but to showcase the nice compile time tricks it employs, e.g. the generation of a Trie at compile time.
Re: [OT?] C compiler written form scratch in D
I will use a handwritten recursive decent parser. Since that is what I deem the easiest thing to do. Take a look at the std.lexer proposal first.
Re: German D Community?
It might make sense for the few companies to stir up some community. Promote D to students and get job candidates in return. Build a website mostly consisting of a job board and events calendar. Integrate Twitter, mailing list, etc to keep low-traffic connections to people. Wouldn't use it. If you have a question, you'll get more people reading and answering it here. If you want to participate in language discussion or development you'll have to do it here either. Only useful topic in a german subforum would be events in german speaking countries. Just mark them with [German] in the topic and post them here. If it starts to annoy people, we're big enough to justify a german forum.
Re: Dconf 2014 talks - when to be available
On Tuesday, 3 June 2014 at 08:39:12 UTC, Mike Parker wrote: On 6/3/2014 1:27 AM, Dicebot wrote: On Monday, 2 June 2014 at 15:47:19 UTC, Mike Parker wrote: Until someone stumbles across the video and posts it to Reddit before Andrei intends to. If community can't respect such a simple request we have bigger problems than marketing. Oh, I don't necessarily mean someone who follows the newsgroup. My point is that any random Joe looking for D stuff, and who has no clue about the release schedule, can stumble across it and share it. It's the downside of separating the release and the announcement of the release -- loss of control. Then just post them on the newsgroup.
Re: Real time captioning of D presentations
On Sunday, 1 June 2014 at 20:48:56 UTC, Walter Bright wrote: On 6/1/2014 1:17 PM, Tobias Pankrath wrote: On Sunday, 1 June 2014 at 18:46:18 UTC, Walter Bright wrote: https://lkuper.github.io/blog/2014/05/31/your-next-conference-should-have-real-time-captioning/ I know I'd find this very useful - what do you guys think? I definitively prefer reading over watching video (and I've got the feeling I'm not alone). Wouldn't spend a single buck for this though. To publish the slides along with a text version of the talk would be an alternative. You're not alone. I can read a transcript far, far faster than watching a video. The point is: real time captioning is not faster than listening regardless of your reading speed. It's useful for people you cannot hear properly, but I'd say our efforts are better spend with proper text version of talks published later.
Re: Real time captioning of D presentations
On Sunday, 1 June 2014 at 18:46:18 UTC, Walter Bright wrote: https://lkuper.github.io/blog/2014/05/31/your-next-conference-should-have-real-time-captioning/ I know I'd find this very useful - what do you guys think? I definitively prefer reading over watching video (and I've got the feeling I'm not alone). Wouldn't spend a single buck for this though. To publish the slides along with a text version of the talk would be an alternative.
