Re: Write for the D Blog!
On Monday, 13 August 2018 at 16:16:31 UTC, Dukc wrote: But I want to say, that the fairly recent post about SARC moving to D was great stuff to read! It had so many links and viewpoints rarely mentioned, I was not even aware about them. The naval architecht viewpoint is a refresher! That’s nice to hear, thanks a lot! Update on that project: I have moved out from the laboratory and today I successfully transpiled the second real-world Pascal module. The next one requires more thought, as it’s interface and implementation are in separate files. Morale of the story? I think that one should not be afraid to post there if he does not consider himself a "regular" programmer, because thats precisely what produces the best posts. I appreciate that morale. There's definitely no reason to be shy, and Mike is a very helpful editor!
Re: silly is released - new test runner for the D programming language
On Monday, 13 August 2018 at 11:57:34 UTC, Atila Neves wrote: On Monday, 13 August 2018 at 04:13:46 UTC, Anton Fediushin wrote: On Sunday, 12 August 2018 at 21:33:21 UTC, Dechcaudron wrote: On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote: Problem with unit-threaded and similar tools is that they are too complicated for no particular reason. Yes, I often wake up and think to myself "what feature can I add that aren't going to be useful to anyone at all?" then write some code. Nobody adds complication "for no particular reason". Even people who shouldn't be doing it do it because they're trying to accomplish something else. Hacking into dub.json to add some scripting into it is not something everybody wants to waste their time on. Agreed. Other than manually listing modules however (which is what I do these days anyway due to a dub bug), I don't know of a better way. I wish there were a compile-time trait like __traits(allModules). I've thought of writing a DSI Sadly, there's no better way yet. Silly imports `dub_test_root` which contains all of the modules. That's why no `main()` should be defined and tests must be run with `dub test`. Another thing, these tools are trying to be everything people might need adding all kinds of features nobody really uses. For example, assertions in unit-threaded and a lot of different reporters in trial. This is a good point. I think I should split unit-threaded up into separate dub subpackages. Thanks for the idea! That'd be nice. These tools also advertise usage of built-in `unittest` blocks for integration testing. I think it's just wrong because `unittest`s are obviously meant for unit testing and slapping integration tests on with some duct tape and zip ties is not a good solution. Integration testing needs it's own tool and it's quite possible that I'll end up writing one soon or later. I'm curious as to why you think that's the case. Well, 'advertise' might not be the right word for that, but both unit-threaded and trial provide means to write integration tests. Even though there is support for some simple things like creating temporary files and defining steps, it goes beyond "unit testing" but is not enough for integration tests. This kind of testing can require things like setting up a database or running other services which cannot be done with existing tools. ...
Re: Write for the D Blog!
On Mon, Aug 13, 2018 at 02:29:30PM +, Mike Parker via Digitalmars-d-announce wrote: [...] > If you've got something D-related you'd like to tell the world about, > please let me know. It doesn't have to be a guest post -- project > highlights, where you give me info about your project and I write the > post, are also welcome. I'm open to ideas for other formats, too. > Just drop me a line at aldac...@gmail.com and let me know what you'd > like to do. [...] I'm too busy to actually work on much right now, but if you're running short of material to post, what about this draft wiki article that I haven't been able to finish? https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time It's pretty much ready except for some details that need to be updated (that I'm sorry to say I haven't had time to get around to). You can freely copy/adapt/etc. whatever you need from this article to throw together a blog post. Just throwing it out there. T -- Живёшь только однажды.
Re: Write for the D Blog!
On Monday, 13 August 2018 at 14:29:30 UTC, Mike Parker wrote: You may have noticed the blog is relatively quiet right now. That's not from a lack of trying. Good to know, and thanks for trying. If you've got something D-related you'd like to tell the world about, please let me know. I'll keep in mind, but nothing right now. But I want to say, that the fairly recent post about SARC moving to D was great stuff to read! It had so many links and viewpoints rarely mentioned, I was not even aware about them. The naval architecht viewpoint is a refresher! Morale of the story? I think that one should not be afraid to post there if he does not consider himself a "regular" programmer, because thats precisely what produces the best posts.
Re: Dub support was added to Meson
On Mon, 2018-08-13 at 14:33 +, Matthias Klumpp via Digitalmars-d-announce
wrote:
[…]
> This is intentional, see this comment from Jussi:
> https://github.com/mesonbuild/meson/pull/3592#issuecomment-390421754
I am not entirely sure I agree with everything there, but he is BDFL of the
project so his view wins.
> Unfortunately, this makes the dub feature almost useless for
> Linux distro integration.
> However, I hope we might be able to implement reading dub.json
> files that are locally installed and incorporate D sources from
> the dependency into the regular Meson build process.
I am rapidly heading this route for SCons: instead of using Dub to create the
libraries just use it to get the sources and then compile the sources as a
sub-project. However I still prefer having a Meson build for the library and
building that way. If however there is a way of using dub.sdl or dub.json that
would be interesting.
> This would mean that Meson's dlang plugin would have to implement
> quite a bit of dub and dub.json parsing, which is some effort.
> The benefit would be the creation of a near-seamless bridge
> between the dub and Meson worlds (you'd only have to locally
> install a dub package), that is also useful for Linux
> distribution packaging.
Perhaps there is a route whereby there can be a separate Python package to do
this that both Meson and SCons can use? Otherwise it risks there being
implementation of the same code for Meson and SCons separately.
[…]
> Jup, deterministic source lists are useful for split-building
> stuff efficiently. And globbing sources is possible with Meson,
> but highly discouraged (and even looks ugly).
I am not entirely convinced explicit manual lists are better, nor are they
required for consistent builds. If the source files structure changes you have
to create a new build anyway.
What is the ugly globbing way you know – I'm wondering if it better than the
hack I have.
[…]
> At the moment, I think for a final project, adding Meson files to
> dependencies still is the better way. However, for quickly
> testing out things and for building something locally, the new
> dub support is quite valuable.
> Also, we can expand it in future, this is a first step :-)
I get the feeling Meson Rust/Cargo support is easier and better than D/Dub
support, even though D seems to get more publicity in the Meson documentation.
I think a really good way forward for Meson (and analogously SCons) would be
to have the Dub dub.{json,sdl} file usable to create (and deploy if using
shared objects) a Meson (Scons) build of the dependency and then building the
project based on the created dependencies.
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
Re: Dub support was added to Meson
On Friday, 10 August 2018 at 14:38:10 UTC, Russel Winder wrote: On Sat, 2018-08-04 at 16:07 +, Filipe Laíns via Digitalmars-d-announce wrote: Hello, Dub support was finally merged to the Meson's upstream. For the ones that don't know, Meson[1] is a fast build system that uses ninja[2] as a backend. Until now it was impossible to use dependencies via the Dub and many many packages only supported Dub. Now you can import dependencies that already exist in Dub's local repo. You still need to fetch and build them though. Sadly not in Meson 0.47.1 is a new release due soon? There is no fixed release schedule, but from experience, this might take a few months. First, you need to fetch and build the dependency. dub fetch vibe-d dub build vibe-d This feels a little unsatisfactory. Dub (and soon SCons I hope) builds handle getting the dependency as well as building it and thence linking the project to it. Meson both depends on the dub executable and yet isn't doing the getting, it is assuming already got. Of course Meson relies on all dependencies being present at build specification time, so nothing inconsistent, it just seems a wee bit incomplete. This is intentional, see this comment from Jussi: https://github.com/mesonbuild/meson/pull/3592#issuecomment-390421754 Unfortunately, this makes the dub feature almost useless for Linux distro integration. However, I hope we might be able to implement reading dub.json files that are locally installed and incorporate D sources from the dependency into the regular Meson build process. This would mean that Meson's dlang plugin would have to implement quite a bit of dub and dub.json parsing, which is some effort. The benefit would be the creation of a near-seamless bridge between the dub and Meson worlds (you'd only have to locally install a dub package), that is also useful for Linux distribution packaging. [...] I have been getting projects such as Unit-Threaded, DInotify, TinyEndian, and D_YAML to have Meson builds so as to create shared libraries prior to using pkg-config to handle D project being dependent on these libraries. It's working nicely (for me anyway) except Dub uses GitHub tags for versioning and Meson requires version numbers in the meson.build file. This duplication is getting quite annoying for all concerned. As is the Meson requirement to list all source files, rather than have a convention over configuration approach as Dub does – SCons has a different approach but still avoids explicit source lists. I can get round it with Meson, but I am informed it is naughty and should not be done. Jup, deterministic source lists are useful for split-building stuff efficiently. And globbing sources is possible with Meson, but highly discouraged (and even looks ugly). These builds create shared objects and allow for dynamic linking. Using Dub built archives means static linking. Unless Meson somehow manages to get shared objects out of the Dub build. Unless Dub can generate shared objects, having the dependencies build locally and creating pkg-config files actually seems a better way that accessing Dub builds. [...] At the moment, I think for a final project, adding Meson files to dependencies still is the better way. However, for quickly testing out things and for building something locally, the new dub support is quite valuable. Also, we can expand it in future, this is a first step :-)
Write for the D Blog!
You may have noticed the blog is relatively quiet right now. That's not from a lack of trying. I am in a dry spell with my own writing at the moment. I've got two posts in progress that shouldn't be difficult to write, but the words haven't been coming out the way I want them to nor as easily as they usually do. One is the next post in the GC series (I'm currently on my fifth revision) and the other is the first in a Sociomantic profile. I'll finish them eventually and my dry spell will pass, but until then, I need backup! My usual approach to drum up guest posts is to contact people directly as broad calls in the forums tend to come up empty. Thought I'd give it a go, though If you've got something D-related you'd like to tell the world about, please let me know. It doesn't have to be a guest post -- project highlights, where you give me info about your project and I write the post, are also welcome. I'm open to ideas for other formats, too. Just drop me a line at aldac...@gmail.com and let me know what you'd like to do. Thanks!
Re: silly is released - new test runner for the D programming language
On Monday, 13 August 2018 at 04:13:46 UTC, Anton Fediushin wrote: On Sunday, 12 August 2018 at 21:33:21 UTC, Dechcaudron wrote: On Sunday, 12 August 2018 at 15:07:04 UTC, Anton Fediushin wrote: Problem with unit-threaded and similar tools is that they are too complicated for no particular reason. Yes, I often wake up and think to myself "what feature can I add that aren't going to be useful to anyone at all?" then write some code. Nobody adds complication "for no particular reason". Even people who shouldn't be doing it do it because they're trying to accomplish something else. Hacking into dub.json to add some scripting into it is not something everybody wants to waste their time on. Agreed. Other than manually listing modules however (which is what I do these days anyway due to a dub bug), I don't know of a better way. I wish there were a compile-time trait like __traits(allModules). I've thought of writing a DSI Another thing, these tools are trying to be everything people might need adding all kinds of features nobody really uses. For example, assertions in unit-threaded and a lot of different reporters in trial. This is a good point. I think I should split unit-threaded up into separate dub subpackages. Thanks for the idea! These tools also advertise usage of built-in `unittest` blocks for integration testing. I think it's just wrong because `unittest`s are obviously meant for unit testing and slapping integration tests on with some duct tape and zip ties is not a good solution. Integration testing needs it's own tool and it's quite possible that I'll end up writing one soon or later. I'm curious as to why you think that's the case. Silly is just my attempt to improve current state of D's ecosystem where programmers don't use advanced test runners, well, because it doesn't worth it for small projects. The trouble with small projects is that they tend to not remain small if people find them useful. Also, even if they do, I'd still rather use a good test runner, the same way I don't think any project is too small for git.
