Re: Truly algebraic Variant and Nullable
On Sunday, 20 December 2020 at 11:00:05 UTC, Tobias Pankrath wrote: 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! For me choose between sumtype and mir.algebraic ends when I not found any solution for working with type kind [1] in sumtype. Kind represents in taggedalgebraic [2] too, but it can't work in compile time (important for me in current project). Also I find tagged_union [3] library, but it haven't any visit [4] or match functions. [1] http://mir-core.libmir.org/mir_algebraic.html#.TaggedVariant [2] https://code.dlang.org/packages/taggedalgebraic [3] https://code.dlang.org/packages/tagged_union [4] http://mir-core.libmir.org/mir_algebraic.html#visit
Re: Truly algebraic Variant and Nullable
On Wednesday, 16 December 2020 at 15:58:21 UTC, 9il wrote: On Wednesday, 16 December 2020 at 14:54:26 UTC, Oleg B wrote: 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. Great library! Have you any plan to separate it from mir-core (to mir-algebraic for example)? Thanks! Maybe, but mir-core is quite small itself and mir.algebraic is the only part that would be extended or updated in the near future. Other parts are quite stable. If there would be a strong reason to split it, we can do it. That are you planing update? It's will be perfect if you add `get` overload for kind type and more work with tags [2] like that: ``` alias TUnion = Algebraic!( TaggedType!(int, "count"), TaggedType!(string, "str") ); auto v = TUnion("hello"); S: final switch (v.kind) { static foreach (i, k; EnumMembers!(k.Kind)) case k: someFunction(v.get!k); // [1] by now v.get!(TUnion.AllowedTypes[i]) break S; } if (v.is_count) // [2] writeln(v.count); ``` or may be I miss this feature in docs?
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. Great library! Have you any plan to separate it from mir-core (to mir-algebraic for example)?
aslike: duck-typing with check interface
Hello! I wrote library, that can be helpful in some cases: 1. easy and readable check interface of structures without 'templatisation' of function or method 2. cache virtual methods table lookup for OOP implementations using: 1. define interface 2. use `Like` wrap as argument 3. wrap objects by `as` function example: https://github.com/deviator/aslike/blob/master/example/struct/app.d https://github.com/deviator/aslike/blob/master/example/cache/app.d in cache example at my machine I have ~2 increase of performance: ``` $ ldc2 -O -I../../source/ app.d; and rm app.o; and ./app delegates avg: [18 ms, 281 μs, and 7 hnsecs] impliface avg: [36 ms, 70 μs, and 3 hnsecs] likecache avg: [18 ms and 243 μs] ``` dub: https://code.dlang.org/packages/aslike git: https://github.com/deviator/aslike
Re: gtkui: aux lib for using gtkd with glade
On Wednesday, 12 February 2020 at 14:12:29 UTC, Ferhat Kurtulmuş wrote: On Tuesday, 11 February 2020 at 18:40:33 UTC, Oleg B wrote: If you want use Glade [1] as UI builder with gtkd [2] you can be interested by this library [Dub] http://code.dlang.org/packages/gtkui [Git] https://github.com/deviator/gtkui [1] https://glade.gnome.org/ [2] https://gtkd.org/ Very good. I wish attribute names would follow Vala's rules as much as it could be so that possible transitions from vala-gtk users can feel home. But this is my personal choice though: eg. gtkwidget -> GtkChild Good idea, thanks! But I think it should follow d-style for UDA https://dlang.org/dstyle.html#naming_udas and should be camelCase or fully lowercase like @nogc. I will add @gtkchild and @gtkcallback in next version and add deprecate message for @gtkwidget and @gtksignal.
gtkui: aux lib for using gtkd with glade
If you want use Glade [1] as UI builder with gtkd [2] you can be interested by this library [Dub] http://code.dlang.org/packages/gtkui [Git] https://github.com/deviator/gtkui [1] https://glade.gnome.org/ [2] https://gtkd.org/
Re: ssll - simple shared library loader
On Monday, 6 January 2020 at 10:04:38 UTC, Sönke Ludwig wrote: I've written something similar with the goal to make it work transparently with existing static bindings: https://code.dlang.org/packages/dynamic It uses a mixin to specify the module(s) containing the declarations instead of a UDA Interesting solution. Do you plain implement betterC compatible?
Re: ssll - simple shared library loader
On Monday, 6 January 2020 at 04:32:25 UTC, Mike Parker wrote: On Sunday, 5 January 2020 at 23:23:48 UTC, Oleg B wrote: Nice work! One thing I would recommend, though, is that you not bake in extern(C). Some libraries require extern(System) (because they're stdcall on Windows and cdecl everywhere else). So to be robust, you'll want to implement support for both into SSLL. Thanks for the advice! I will continue work on ssll and will try implement this feature. There are only two declarations required for the dynamic bindings in BindBC: an alias and a pointer. And of course the loader is separate. The reason is historical. When I was working on the earliest version of Derelict back in 2004, we didn't have all the fancy compile-time features we have now. I (and a couple of contributors) tried doing it by declaring the function pointers without aliases, but we ran into a couple of issues and settled for taking the alias + pointer approach. (It's been so long that I can't recall what the issues were). Thanks for the clarification and thanks for Derelict bindings!
ssll - simple shared library loader
It's analog of bindbc, but without need write boilerplate code. May be bindbc is designed for another cases, but I don't understand need writing triple definition for one function (pointer, loading, wrap-function). ssll betterC compatible too, and tested on windows (x86) and linux (x86, ARM). package: http://code.dlang.org/packages/ssll github: https://github.com/deviator/ssll Example usage: Mosquitto binding and wrapper https://github.com/deviator/mosquittod/blob/master/source/mosquittod/api/load.d libsystemd binding https://github.com/deviator/sdutil/blob/master/source/systemd/daemon.d I think somebody can find it handy.
Re: Cross-compiling dub projects with LDC
Is this supports only in dub-1.17.0-beta.2 and it's not include to ldc2-1.17.0? It feature only in dub-master by now But it's cool works) Thanks!
Re: Cross-compiling dub projects with LDC
On Sunday, 25 August 2019 at 21:16:22 UTC, kinke wrote: The resulting cctest.exe (incl. 2 DLLs) can be copied to a Win64 box and then runs fine, as long as a Visual C++ runtime ≥ 2015 is installed. Tested on a Linux host, but should work on any host. Is this supports only in dub-1.17.0-beta.2 and it's not include to ldc2-1.17.0?
Re: serialport v1.0.0
On Wednesday, 9 May 2018 at 14:41:45 UTC, Andrea Fontana wrote: On Sunday, 6 May 2018 at 22:02:05 UTC, Oleg B wrote: Stable version of serialport package * Blocking `SerialPortBlk` for classic usage * Non-blocking `SerialPortNonBlk` and `SerialPortFR` for usage in fibers or in vibe-d * Variative initialization and configuration * Hardware flow control config flag Doc: http://serialport.dpldocs.info/v1.0.0/serialport.html Dub: http://code.dlang.org/packages/serialport Git: https://github.com/deviator/serialport I wonder if someone can benchmark serialport lib against this test: http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ I think it's different things. serialport is wrap around system calls, it's not control hardware directly. You could be misled by the phrase about 'hardware flow control': is't set on or off using of RTS and CTS pins of UART. Firmware control RTS and CTS pins directly. http://www.brainboxes.com/faq/items/what-is-rts--cts-hardware-flow-control-
serialport v1.0.0
Stable version of serialport package * Blocking `SerialPortBlk` for classic usage * Non-blocking `SerialPortNonBlk` and `SerialPortFR` for usage in fibers or in vibe-d * Variative initialization and configuration * Hardware flow control config flag Doc: http://serialport.dpldocs.info/v1.0.0/serialport.html Dub: http://code.dlang.org/packages/serialport Git: https://github.com/deviator/serialport
Re: LDC 1.3.0-beta2
On Monday, 12 June 2017 at 17:49:46 UTC, kinke wrote: Hi everyone, LDC 1.3.0-beta2, the LLVM-based D compiler, is available for download! This release is based on the 2.073.2 frontend and standard library and supports LLVM 3.5-4.0. It's been a while since beta1, so besides numerous fixes there are also new features. Change log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.3.0-beta2 Regards, kinke You plain build armhf version, like for 1.1.0? Or will it never happen again?
Re: DLang users telegram group
On Tuesday, 8 December 2015 at 17:51:01 UTC, Kingsley wrote: On Monday, 30 November 2015 at 10:58:34 UTC, Quentin Ladeveze wrote: Hi everybody, I just created a Telegram group for dlang users : https://telegram.me/joinchat/BeLaugMz35ZxQUq2fks4YQ Feel free to join ! says the link has expired yet another english group https://telegram.me/dlangTelegram