Re: D-wrappers BLAKE3 wrapping C library libblake3
On Tuesday, 19 March 2024 at 08:40:37 UTC, Per Nordlöw wrote: On Tuesday, 19 March 2024 at 08:35:55 UTC, Per Nordlöw wrote: I just added a D implementation to dmd (https://github.com/dlang/dmd/blob/master/compiler/src/dmd/common/blake3.d) which doesn't support streaming, so is probably somewhat simpler/smaller, in case that's useful
Re: Pry parser v0.6.0 is out
On Monday, 10 July 2023 at 10:22:08 UTC, Dmitry Olshansky wrote: Not much in way of new features but now atom set actually take a set as runtime parameter making it all the more useful. https://github.com/DmitryOlshansky/pry-parser -- Dmitry Olshansky CEO @ Glow Labs http://olshansky.me Cool stuff, looks like it has some stuff in common with a lib I was working on a while back: https://github.com/benjones/autoparsed/
Re: D Language Foundation Monthly Meeting Summary (September 24, 2021)
On Wednesday, 6 October 2021 at 06:23:01 UTC, WebFreak001 wrote: On Friday, 1 October 2021 at 12:32:20 UTC, Mike Parker wrote: [...] new slogan [...] want to generate controversial heat? Do it in D (DIID) (careful with there being a trademark for DiiD though) How about "from prototype to production" or something? I was reading yesterday about how both memcached and redis were originally written in scripting languages and then rewritten in C for performance.
Re: Origins of the D Programming Language now published by ACM!
On Saturday, 13 June 2020 at 03:16:05 UTC, Walter Bright wrote: https://dl.acm.org/doi/abs/10.1145/3386323 Many, many thanks to Mike Parker and Andrei Alexandrescu for their endless hours spent fixing the mess I originally wrote. Interesting history! Did Eric Niebler lose interest in D? I didn't realize he was involved early on.
Re: Earcut polygon triangulation
On Monday, 24 February 2020 at 19:15:13 UTC, JN wrote: On Sunday, 23 February 2020 at 16:20:09 UTC, Ahmet Sait wrote: Out of curiosity, why would you need to triangulate polygons instead of using stencil buffer? I'm assuming you're using OpenGL (or something similar) since you talked about your hobby game. Any advantage of triangulating shapes? (anti-aliasing maybe?) Triangulation goes beyond rendering. I imagine this library might be useful when making a level editor for a DOOM-like 2.5D engine. It's very poorly documented, but I wrote a delaunay refinement triangulator: https://github.com/benjones/dtriangulate . It's mostly a reimplementation of Shewchuk's Triangle which is probably the most common delaunay triangulator.
Re: DIP 1021--Argument Ownership and Function Calls--Formal Assessment
On Monday, 28 October 2019 at 20:23:50 UTC, Walter Bright wrote: On 10/28/2019 12:23 PM, jmh530 wrote: Is there a connection between this DIP and the restrict qualifier in C? This DIP basically ensures that in @safe code, if a piece of data is accessed only through scope pointers, then there must be only one mutable pointer to said data or they are all const. That there is only one mutable way to access data sounds like restrict to me. I would think that would enable some optimizations in @safe code. I hadn't thought of that, it is an interesting observation. Just for context, here's a paper arguing restrict without tooling is a bad idea: http://people.cs.pitt.edu/~mock/papers/clei2004.pdf . Having the compiler enforce it changes the game substantially, I think.
Re: My Meeting C++ Keynote video is now available
On Monday, 14 January 2019 at 21:22:32 UTC, Andre Pany wrote: On Monday, 14 January 2019 at 21:08:50 UTC, Ben Jones wrote: On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei A lot of the questions were about documenting the hook API and catching misspelling errors when defining a hook. It seems like it would be nice if you could list the hook method names a static array or dictionary or struct containing a field for each method, etc. One each for the required and optional methods. The hook author could grab the name/signature of the method they're intending to implement from that data structure and any misspellings would be caught immediately. Is it possible to declare a function whose name is a CTFE computed string? For ranges there are concepts like Input Range. A struct/class must have several methods to be compliant. You can check the compliance using function isInputRange https://dlang.org/library/std/range/primitives/is_input_range.html Maybe something similiar can be done here. Not checking individual methods, but concepts... Kind regards Andre I don't think that's quite sufficient because a hook may/may not have the optional methods, and could have extra stuff. What you want is to specify per method "this method is part of the hook interface," which as I type it kind of sounds like the job of an annotation...
Re: My Meeting C++ Keynote video is now available
On Saturday, 12 January 2019 at 15:51:03 UTC, Andrei Alexandrescu wrote: https://youtube.com/watch?v=tcyb1lpEHm0 If nothing else please watch the opening story, it's true and quite funny :o). Now as to the talk, as you could imagine, it touches on another language as well... Andrei A lot of the questions were about documenting the hook API and catching misspelling errors when defining a hook. It seems like it would be nice if you could list the hook method names a static array or dictionary or struct containing a field for each method, etc. One each for the required and optional methods. The hook author could grab the name/signature of the method they're intending to implement from that data structure and any misspellings would be caught immediately. Is it possible to declare a function whose name is a CTFE computed string?
