GDC with D frontend 2.081.2
As some of you may know D frontend was merged into GDC some time ago and is up to date. D version currently supported by GDC is 2.081.2 and it can be found in "gdc-7" and "gdc-8" branches. I will say a bit more about GDC development and development plans later. I prepared GDC/GCC 7.3.0 binaries for x86-64 Linux built on Ubuntu 18.04: https://download.dlackware.com/gdc/gdc-7.3.0_2.081.2-linux-x86_64.tar.xz I’m not a regular Ubuntu user, and built GDC in a VM, so don't blame me (too much) if something doesn’t work, but let me know anyway. For testing I've used a minimal Ubuntu installation and had to install only "libc-dev" package. The package includes gcc, g++, gdc and standard GNU tools, but no D tools like dub. I still need some time to automate the building, then I can build for more platforms and provide some core tools. We support several GCC versions and we still support C++-frontend (D version: 2.076). The reason for this is that C++-frontend should be merged into the next GCC version (GCC 9), then it can be built without another D compiler. D frontend goes into GCC 10 and can be built with GCC 9, so GCC can be bootstrapped without external compilers and can be used to bootstrap other D compilers. Current branch model. There are 2 "master" branches: master and stable. master contains D frontend and follows DMD master (we'll see if we can update every week or every two weeks). stable contains C++ frontend which doesn't get new D features anymore but of course we merge bug fixes from master. Both follow GCC master (master is updated weekly to GCC snapshots, stable from time to time). stable has 4 derivates: gdc-8-stable, gdc-7-stable, gdc-6-stable and gdc-5-stable. It seems to be a lot, but the last merge from stable was really trivial, so the most work is done on the master derivates: "gdc-8" and "gdc-7" branches. These two follow DMD stable and contain stable D releases.
Re: reduxed - Redux for D
On Thursday, 23 August 2018 at 19:48:19 UTC, Robert burner Schadek wrote: It is still rough around the corners and https://issues.dlang.org/show_bug.cgi?id=19084 gives me somewhat of a hard time, but give it try and scream at me because it is not nogc. I've posted a comment on issue 19084 but I'll post the response here as well. This is not supposed to compile. I've actually run into this before, but using T.stringof to mixin code for a type name is not supported. When I've asked about adding support for this, no one was interested. I tried to find my forum posts on this but the post is so old I couldn't find it in search. What happens is you mixin the string "Foo", but that type doesn't mean anyting in the scope of Bar. The actual type name is something like "__unittest__20.Foo", however, even if you got the fully qualified type name it won't work because the type is private and can't be accessed outside of the unittest using the symbol name. You have to access the type by "alias". The `bitfields` function in phobos suffers from this same problem and I created a PR in phobos to add bitfields2 to workaround this issue by using a "mixin template" instead of a normal "mixin": https://github.com/dlang/phobos/pull/5490 [QUOTE FROM THE PR] The main advantage of bitfields2 is that it is able to reference the field types by alias, whereas the current implementation converts each field type alias to a string and then mixes in the type name. I know the example you've provided is contrived so I'm not sure how to help you with your exact situation. Maybe I can help you find a solution with a bit more detail?
Re: reduxed - Redux for D
On Thursday, 23 August 2018 at 19:48:19 UTC, Robert burner Schadek wrote: After working some with Angular and ngrx/store I really came to like the redux pattern. Unfortunately, I couldn't find a package on code.dlang.org that filled that spot when coming back to D. So I build my own. It is called reduxed. If you're interested you can find reduxed here https://code.dlang.org/packages/reduxed and https://github.com/burner/reduxed. It is still rough around the corners and https://issues.dlang.org/show_bug.cgi?id=19084 gives me somewhat of a hard time, but give it try and scream at me because it is not nogc. Thank you :) as for the hard timer : https://run.dlang.io/is/Bsf8Us Works if struct Foo is defined in the scope of struct Bar(T) ?
reduxed - Redux for D
After working some with Angular and ngrx/store I really came to like the redux pattern. Unfortunately, I couldn't find a package on code.dlang.org that filled that spot when coming back to D. So I build my own. It is called reduxed. If you're interested you can find reduxed here https://code.dlang.org/packages/reduxed and https://github.com/burner/reduxed. It is still rough around the corners and https://issues.dlang.org/show_bug.cgi?id=19084 gives me somewhat of a hard time, but give it try and scream at me because it is not nogc.
Re: xserial 1.0.0 - binary serialization and deserialization library
On Thursday, 23 August 2018 at 11:11:11 UTC, Mark White wrote: Binary serialization and deserialization library. Features: - Serializes and deserializes booleans, numbers, chars, arrays, tuples, structs and classes. - Specify the endianness and the array's length when serializing and deserializing. - Numerous attributes for structs and classes. Some code examples are available in the project's README. DUB: https://code.dlang.org/packages/xserial GitHub: https://github.com/Kripth/xserial Attributes: https://github.com/Kripth/xserial#attributes Except for the explicit endianness (which I've been meaning to work on), why one would use this instead of cerealed? Atila
xserial 1.0.0 - binary serialization and deserialization library
Binary serialization and deserialization library. Features: - Serializes and deserializes booleans, numbers, chars, arrays, tuples, structs and classes. - Specify the endianness and the array's length when serializing and deserializing. - Numerous attributes for structs and classes. Some code examples are available in the project's README. DUB: https://code.dlang.org/packages/xserial GitHub: https://github.com/Kripth/xserial Attributes: https://github.com/Kripth/xserial#attributes
Re: LDC 1.11.0
On Thursday, 23 August 2018 at 09:51:30 UTC, Brian wrote: On Tuesday, 21 August 2018 at 15:31:16 UTC, Joakim wrote: On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote: Many thanks for your effort! And hope the subsequent LDC releases with LLVM 7.0 will be mature enough on AArch64 and RISC-V for production environment. Who is actually running AArch64 or RISC-V in a "production environment?" Maybe a few for AArch64, but pretty much nobody for RISC-V. I tried looking for a RISC-V VPS or dev board recently and found basically nothing, just two boards from SiFive that are too small or too expensive. We need support AArch64 :) Why?
Re: LDC 1.11.0
On Tuesday, 21 August 2018 at 15:31:16 UTC, Joakim wrote: On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote: Many thanks for your effort! And hope the subsequent LDC releases with LLVM 7.0 will be mature enough on AArch64 and RISC-V for production environment. Who is actually running AArch64 or RISC-V in a "production environment?" Maybe a few for AArch64, but pretty much nobody for RISC-V. I tried looking for a RISC-V VPS or dev board recently and found basically nothing, just two boards from SiFive that are too small or too expensive. We need support AArch64 :)
Re: RFC: initial release of dtoh
On Wednesday, 22 August 2018 at 17:58:15 UTC, Manu wrote: This is very topical for me just now... but no extern(C++)?? I have some extern(C++) classes that need to have .h files generated for them. Is this a goal for the project? Not if I can get away without it. I am rather opinionated against `extern(C++)` on principle and stand by the point it is not a suitable language for inter-language operations. Sorry, I know you have a very different opinion here :) Actual production cases may end up requiring it anyway but I'll see how it goes.
