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: BeerConf Mid-December Edition
On Saturday, 19 December 2020 at 17:48:37 UTC, Ethan wrote: On Saturday, 19 December 2020 at 15:15:16 UTC, Iain Buclaw wrote: I've started up a meeting for people to come and go as they please. BEERCONF Did I miss this? That sucks! When's the next one and what is this "stream". Sorry if it's a totally n00b quesiton. Best, S
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. Nullable is defined as ``` alias Nullable(T...) = Variant!(typeof(null), T); ``` Variant and Nullable with zero types are allowed. `void` type is supported. Visitors are allowed to return different types. Cyclic referencing between different variant types are supported. More features and API: http://mir-core.libmir.org/mir_algebraic.html Cheers, Ilya The work has been sponsored by Kaleidic Associates and Symmetry Investments. I have been using SumType [1] for a while in some of my projects and I'm quite happy with it. The author has been very responsive to feedback and the quality bar of his work is definitely higher than that of many other D libraries (e.g. support for @safe/pure/@nogc/nothrow, immutable, betterC and DIP1000, etc.). That said, I'm also a fan of your work with Mir! mir.algorithm (which I'm most familiar with) is a text book example of high-quality generic algorithm design. How does your work compare to sumtype? Would mir.algebraic offer any benefits, which would make it worth switching over? IMO, algebraic types (sum and tuple types) should be a core language feature part of druntime and should have have corresponding syntax sugar: // Same as Tuple!(T, "open", T, "high", T, "low", T, "close"): alias OhlcTuple(T) = (T open, T high, T low, T close); // Same as: // Union!(long, double, bool, typeof(null), string, // This[], This[string]; alias Json = | long | double | bool | typeof(null) | string | Json[] | Json[string]; // Syntax sugar for nullable/optional types - // T? == Nullable!T == Union!(typeof(null), T): alias ResponseParser = OhlcTuple!double? delegate(Json json); If we can work together to consolidate on a single API, I think it would be better for the language ecosystem. [1]: https://code.dlang.org/packages/sumtype
Re: Truly algebraic Variant and Nullable
On Sunday, 20 December 2020 at 12:32:35 UTC, Petar Kirov [ZombineDev] wrote: On Sunday, 15 November 2020 at 04:54:19 UTC, 9il wrote: [...] I have been using SumType [1] for a while in some of my projects and I'm quite happy with it. The author has been very responsive to feedback and the quality bar of his work is definitely higher than that of many other D libraries (e.g. support for @safe/pure/@nogc/nothrow, immutable, betterC and DIP1000, etc.). [...] I'm increasingly thinking these should be a language feature, it just seems right.
Re: BeerConf Mid-December Edition
On Sunday, 20 December 2020 at 11:39:14 UTC, Selim Ozel wrote: On Saturday, 19 December 2020 at 17:48:37 UTC, Ethan wrote: On Saturday, 19 December 2020 at 15:15:16 UTC, Iain Buclaw wrote: I've started up a meeting for people to come and go as they please. BEERCONF Did I miss this? That sucks! When's the next one and what is this "stream". Sorry if it's a totally n00b quesiton. Best, S It will be open all weekend. They usually run both Saturday and Sunday. If no one is there when you peek in, just keep the tab open or check again later. I believe the peak time is usually in the central European evening.
Beta 2.095.0
Glad to announce the first beta for the 2.095.0 release, ♥ to the 61 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.095.0.html As usual please report any bugs at https://issues.dlang.org -Martin
Re: Printing shortest decimal form of floating point number with Mir
On Monday, 14 December 2020 at 06:47:32 UTC, 9il wrote: Hi all, Generic version of Ryu algorithm [1] was ported to D, well optimized, and adopted to mir packages. [...] Default formatting has been reworked to be more human-friendly: 1.23e1 -> 1.23 https://github.com/ulfjack/ryu/tree/master/ryu Microsoft, Clang++, and others are adopting Ryu as well.
Re: BeerConf Mid-December Edition
On Sunday, 20 December 2020 at 13:07:32 UTC, Mike Parker wrote: On Sunday, 20 December 2020 at 11:39:14 UTC, Selim Ozel wrote: On Saturday, 19 December 2020 at 17:48:37 UTC, Ethan wrote: On Saturday, 19 December 2020 at 15:15:16 UTC, Iain Buclaw wrote: I've started up a meeting for people to come and go as they please. BEERCONF Did I miss this? That sucks! When's the next one and what is this "stream". Sorry if it's a totally n00b quesiton. Best, S It will be open all weekend. They usually run both Saturday and Sunday. If no one is there when you peek in, just keep the tab open or check again later. I believe the peak time is usually in the central European evening. Thanks! Somehow I missed the link above. S
Re: Printing shortest decimal form of floating point number with Mir
On 12/13/2020 10:47 PM, 9il wrote: Note that D's compiler floating-point literals parsing and Phobos floating-point literals parsing are not precise [5,6,7,8]. It is recommended to use Mir's to!double/float/real to convert floating-point numbers from a string. Can the improved parsing be added to D? (It would need to be Boost licensed.)
Re: Chimpfella - new library to do benchmarking with ranges (even with templates!)
On Saturday, 19 December 2020 at 05:08:56 UTC, Max Haughton wrote: This will soon support Linux's perf_event so you will be able to measure cache misses (and all the other thousands of pmc's intel expose), use LBR msrs etc. Are you going to read stdout from calling perf or are you going to read perf.data file?
Re: Chimpfella - new library to do benchmarking with ranges (even with templates!)
On Monday, 21 December 2020 at 03:27:14 UTC, welkam wrote: On Saturday, 19 December 2020 at 05:08:56 UTC, Max Haughton wrote: This will soon support Linux's perf_event so you will be able to measure cache misses (and all the other thousands of pmc's intel expose), use LBR msrs etc. Are you going to read stdout from calling perf or are you going to read perf.data file? I already have code that uses perf_event_open directly, it's much more efficient at the expense of having to decipher shit linux documentation. I tried to get the bindings into druntime but they weren't up to snuff apparently. The architecture of the counters is designed around a stateless widget giving you a stateful gadget specifically because this makes using perf_event_open less of a minefield. You can also enable userspace-rdpmc, which I will support eventually (but you get a general protection fault if something goes wrong so it's hard to debug).
Re: Printing shortest decimal form of floating point number with Mir
On Sunday, 20 December 2020 at 22:21:56 UTC, Walter Bright wrote: On 12/13/2020 10:47 PM, 9il wrote: Note that D's compiler floating-point literals parsing and Phobos floating-point literals parsing are not precise [5,6,7,8]. It is recommended to use Mir's to!double/float/real to convert floating-point numbers from a string. Can the improved parsing be added to D? (It would need to be Boost licensed.) If I am correct there is open PR that set DMD to use C’s primitives for literals parsing. So, for compiler itself we don’t need Mir. If you mean Phobos - one can use Mir instead.