setup-dlang v0.4.0 released
https://github.com/mihails-strasuns/setup-dlang/releases/tag/v0.4.0 Note: assuming no new issues will be found in a next few weeks, this will be eventually promoted to the 1.0.0 release. Fingers crossed. Fixes - * ldc-master will use latest uploaded asset for the current platform Fixes rare issue when actions runs during new nightly asset upload and not all platforms are available for the latest commit. New features * Use github access token for the api (#15) Oauth access token is supposed to come from a yml configuration file if ldc-master is used. Github actions provide one that can be used out of the box with secrets.GITHUB_TOKEN variable. * Verify DMD downloads with GPG (#5) DMD does not use HTTPS for download links, thus using GPG signature is necessary to avoid MitM. LDC currently does not need/provide those.
Re: Blog post about printing associative arrays from GDB
Cool, if you (or someone else) can give me the fields or functions in the druntime.rt package that can be used to print associative arrays from GDB, then I can try my hand at building a pretty-printer using GDB's Python API next week. AA implementation is provided by https://github.com/dlang/druntime/blob/master/src/rt/aaA.d, and you can either try reimplementing key logic in Python (more work but cleaner impl) or just call relevant functions via gdb python api and parse results. It should actually be possible to call functions like __aaGetX even with release build of druntime, you just to do a manual cast to the correct function type from a raw pointer.
Re: Blog post about printing associative arrays from GDB
On Thursday, 24 October 2019 at 13:16:39 UTC, Johannes Riecken wrote: GDB uses internal functions of C++'s runtime to do the pretty-printing for C++. Implementing that for D's runtime library in its current form would seem like a considerable effort to me, since D's runtime library seems to be a bit hairier with respect to the internal fields, no? That wouldn't be a considerable effort on its own (I think all necessary machinery is already part of druntime.rt package) but right now you would need to have druntime built with debugging symbols to get anything done. For C++ standard containers it is not a problem because those are defined in header files. If AA implementation was switched to templates, it would "just work" for druntime too.
Re: Blog post about printing associative arrays from GDB
GDB has some dedicated functionality to improve pretty-printing and expression evaluation of things that too complex to figure out automatically: - https://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing.html - https://sourceware.org/gdb/onlinedocs/gdb/Writing-an-Xmethod.html GCC, for example, provides such scripts for improved debugging of C++ standard library as part of its distribution. Writing something similar for DMD/GDC/LDC shouldn't be too hard.
Re: Github Action: cross-platfrom D compiler installation
On Thursday, 12 September 2019 at 13:52:14 UTC, Mihails wrote: https://github.com/marketplace/actions/d-compiler-installation https://github.com/mihails-strasuns/setup-dlang https://github.com/mihails-strasuns/setup-dlang/releases/tag/v0.2.0 - Now supports 'ldc-latest', 'ldc-beta', 'dmd-latest' and 'dmd-beta' as compiler versions - If now compiler version is specified, will default to 'dmd-latest' instead of failing
Re: setup-dmd GitHub action
On Thursday, 12 September 2019 at 22:00:11 UTC, kinke wrote: Seems like a tighter integration of Azure Pipelines (somewhat adapted) into GitHub, an obvious move by Microsoft to foster their position. So Windows/Linux/macOS on x86_64 (Azure) hosts, max. 6 hours runtime per job, max 20 jobs in parallel (Azure: 10). Cleaned up workflow yml syntax and typescript API stand out as a major improvement for me compared to old Azure. Also streamlined docker integration. There is much less boilerplate involved overall. And it is worth mentioning that even before that Azure was among the best available CI options if you need to test a project on all 3 major OS, I can't remember any other free CI out of my head which provides windows/linux/macos runners without having to maintain separate test scripts for those. So essentially Github Actions takes existing top CI offer and makes it easier to use.
Github Action: cross-platfrom D compiler installation
https://github.com/marketplace/actions/d-compiler-installation
https://github.com/mihails-strasuns/setup-dlang
Main difference from
https://forum.dlang.org/thread/lrbcmnblvfplkpfao...@forum.dlang.org is that this is written using Github Action Typescript API instead of a docker container and thus allows testing with all platforms supported by Github Actions.
Example yml:
```
name: Test My D Project
on: [push, pull_request]
jobs:
test:
name: Test
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macOS-latest]
dc: [dmd-2.088.0, ldc-1.17.0]
runs-on: ${{ matrix.os }}
steps:
- uses: actions/checkout@master
- name: Install D compiler
uses: mihails-strasuns/setup-dlang@v0
with:
compiler: ${{ matrix.dc }}
- name: Run tests
run: dub -q test
```
Example test run:
https://github.com/mihails-strasuns/d-simpleconfig/commit/5107baedcb5db11cf0076e5c74e3f68594fb495b/checks
Currently only supports DMD and LDC with exact version
specifiers. Supporting GDC and convenience bits like `latest` or
`nightly` is planned but not currently implemented.
Re: DC v1.0.0 - cross-platform D compiler install management tool
On Sunday, 31 March 2019 at 19:15:20 UTC, Jacob Carlborg wrote: It's kind of funny that you decided to release this exactly the same day as I planned to release a new version of DVM [1] :) [1] https://forum.dlang.org/post/q7r3i5$2cdh$1...@digitalmars.com Nice, I must admit I have had my mind set about DVM as something that has existed for years and wasn't quite the right thing. Had no idea you kept improving it lately. Well, it is not a big enough project for me to be sad about the duplicate effort :)
DC v1.0.0 - cross-platform D compiler install management tool
Glad to announce first version of https://github.com/mihails-strasuns/dc suitable for public destruction. It is a small utility originally created to fulfill similar purpose to existing `install.sh` script but also with Windows support. https://github.com/mihails-strasuns/dc/releases/tag/v1.0.0 It is provided as an independent statically linked binary which creates and maintain own toolchain directory with `bin`/`lib`/`imports` sub-directories and allows to quickly switch between compiler versions. Two main use cases: - Cross-platform CI, being able to just say `dc use ldc-1.14.0` in your test spec for both Linux and Windows - Quicky and dirty switching between compiler versions on development machines. Contrary to `install.sh` and DVM approach, DC changes active compiler globally instead of a current shell context only. This done intentionally to simplify integration with IDEs and other non-CLI tools - though temporary shell-only switching is also planned once I come with a decent design. It is also possible (and encouraged) to put own development tools and static libraries in toolchain `bin` and `lib` folders accordingly to make them easily available without doing any system install. Right now the tool is in "works for me" stage, any feedback is welcome.
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.
Re: RFC: initial release of dtoh
On Wednesday, 22 August 2018 at 11:51:59 UTC, Seb wrote: Yeah, the dub registry is "smart" enough to reject all tags from the dmd repository as they all don't conform with SemVer. There has been a long discussion on this (https://forum.dlang.org/post/drcekmxvfszpwifbu...@forum.dlang.org), but sadly it seems that no consensus has been reached. This is a bit sad, because that means no stable tool can be built to use DMD FE as a library as long as it want to be available via code.dlang.org (also afair branch dependencies are deprecated in dub itself now). For dtoh it is probably less of a problem as I intend to propose it for inclusion in dmd if it proves itself good enough in production, but it feels like a missed opportunity overall.
RFC: initial release of dtoh
https://gitlab.com/mihails.strasuns/dtoh Tool to grab all `extern(C)` declarations in a D module and generate C header file based on it. Partially addresses https://issues.dlang.org/show_bug.cgi?id=9285 but is intended to be much more simple (no C++, no human-readable emphasis). Main differences from version written by Adam some years ago: - Uses DMD frontend as a library directly - Has tests Former is quite intentional decision though I do expect it to be controversial. Using json output requires parsing information that is already present in DMD FE in a strongly typed way - and the only benefit is that the tool becomes more decoupled from compiler. In my opinion, this functionality _should_ be part of compiler itself, similar to .di generation. Sadly can't put it on code.dlang.org right now because there are no tagged versions of http://code.dlang.org/packages/dmd to depend on, thus have to resort to submodule.
