On Friday, 1 March 2019 at 01:38:13 UTC, H. S. Teoh wrote:
> On Thu, Feb 28, 2019 at 12:45:56PM -0500, Nick Sabalausky (Abscissa) via Digitalmars-d wrote:
>> - This following workflow needs to be a BASIC STANDARD FULLY-ROBUST use-case with the same priority and importance as running "dub" to build a project: I have a non-DUB project and I want to include a library (say, Vibe.D) via DUB. I have my CLI command(s) to invoke the compiler, and all I have to do to use Vibe.d (or whatever) is insert this as part of my compiler invocation:
>> 
>> dmd blah blah `dub include vibe-d:~0.8.3` blah blah
>> 
>> And boom, -I... paths, libs, Have_vibe_d, etc., all guaranteed working, correct and ready to go.
>> 
>> At one point, I did a lot of work to make that happen, and I made some progress, but it was just so contrary to the way dub wanted to work I finally gave up.
> [...]
>
> I tried doing a non-dub project with dub dependencies before, and ended up with so much frustration that I threw in the towel and resorted to the hack of creating an empty dummy dub project in a subdirectory, whose sole purpose was to declare dub dependencies. I'd only run dub from the subdirectory when one or more dependencies need to be updated, but the actual compilation / linking is done by a different, sane build system that pulls in the objects dub built.

I've also had this use case, and also ended up hacking around it using a dummy empty project.

I wrote a tool that parsed the output of "dub describe", but it only mostly works because that stuff is a confusing mess.

Hi, all! I discovered D looking through the GSoC organizations page, and I'm really intrigued by it. I installed the compiler and messed around with it a bit, but I don't really have much wisdom as to what could make a good project.

One of the ideas I came up with was Python extension modules for D. Does this seem like something that would be useful/feasible? I'm planning on doing more research when I get on spring break, but I was hoping to bounce this idea off people who would know better.

Cheers!

On 03/03/2019 3:55 AM, jpvalley wrote:
> Hi, all! I discovered D looking through the GSoC organizations page, and I'm really intrigued by it. I installed the compiler and messed around with it a bit, but I don't really have much wisdom as to what could make a good project.
> 
> One of the ideas I came up with was Python extension modules for D. Does this seem like something that would be useful/feasible? I'm planning on doing more research when I get on spring break, but I was hoping to bounce this idea off people who would know better.
> 
> Cheers!

https://github.com/ariovistus/pyd

If you want to talk to us more casually you can do so, by joining IRC (FreeNode), Slack or Discord (https://discord.gg/3aUX5nv).

Happy coding!

On 3/1/19 1:13 PM, Dennis wrote:
> On Friday, 1 March 2019 at 17:22:47 UTC, JN wrote:
>> It's obvious no one will win the SDL vs JSON debate. The only solution is to dump both and switch to YAML :)
> 
> Believe it or not, there is a proposal for a third format (the 'tree' format).
> https://github.com/dlang/dub/wiki/DEP7

Not that I think there's even a slightest chance DUB will ever gain another format, but that page contains some questionable claims about SDL, and at least one claim that's just downright false:

It says:
----------------------------------
[Tree's] Comparison to SDL:
    Easy fast syntax
    Syntax highlighting in few editors (Idea, VSCode, Atom, SynWrite)
    More implementations (D,TS/JS)
----------------------------------

The third claim is flat out wrong. SDL has implementations for D, Java, Python and Ruby (that I know of). In fact. the D implementation is the youngest of those four. (Sometimes I get the impression that people think I created SDLang, and did so for D, despite my attempts to dispel that notion. I was looking for a sane alternative to XML/JSON/YAML, found SDL, and wanted to use it in D. Just like how I once looked for a sane alternative to C++ and Java2/4, and found D.)

The second claim is tenuous at best: Even without a dedicated "SDLang highlighter", I can go right through my editor's list of supported highlighters and most of them do an entirely useable job highlighting SDLang. It's not exactly a complicated language: It's basically just custom identifiers and a few literals and grouping symbols. Just like JSON/etc, there's just not much semantic or syntactic detail there TO highlight.

The first one is a highly subjective matter of opinion. SDL and Tree (based on what I can tell from the example provided) *both* have very simple easy syntaxes that put XML, JSON and YAML to shame. Comparing the two directly against each other, well, they're pretty much on par with each other in this regard, any advantage to be had is slight at best.

Someone else mentioned TOML, too. Just looked it up. That's also a very nice data language too, just like Tree and SDLang are. Hell, there's so much out there that just puts the XML/JSON/YAML popular kids clique to shame. I find it absolutely disgusting, shameful and frankly, professionally negligent, that a *technical* field such as ours routinely prioritizes and even promotes following the cool kids' table over actual, freaking technical merit.

On Thursday, 28 February 2019 at 15:50:49 UTC, Seb wrote:
> @community: what features do you miss the most from DUB?

Dub support for building code.dlang.org packages with LDC's LTO. The idea would be to support something analogous to the way LDC provides LTO support for druntime and phobos. See https://github.com/ldc-developers/ldc/releases/tag/v1.9.0 for a description.

Building with LTO against druntime/phobos is a substantial performance win for certain classes of programs. This would likely hold true for a number of code.dlang.org packages as well. My benchmarks involving druntime/phobos are here: https://github.com/eBay/tsv-utils/blob/master/docs/lto-pgo-study.md.

LDC supports druntime/phobos by shipping these prebuilt as LTO libraries (with IR code). For  packages it probably makes more sense to build them from source after being downloaded.

This is probably not a long project, but it might fit well as part of a suite of Dub changes. Dub may well have the necessary facilities already, I'm not sure, but this is not supported in a straightforward manner. There are likely some open questions, for example, should the package provider mark whether package supports LTO or not.

On Saturday, 2 March 2019 at 18:22:01 UTC, Nick Sabalausky (Abscissa) wrote:
> Someone else mentioned TOML, too. Just looked it up. That's also a very nice data language too, just like Tree and SDLang are. Hell, there's so much out there that just puts the XML/JSON/YAML popular kids clique to shame. I find it absolutely disgusting, shameful and frankly, professionally negligent, that a *technical* field such as ours routinely prioritizes and even promotes following the cool kids' table over actual, freaking technical merit.


Well, to me the ONLY reasons DUB use SDLang and cargo use TOML is obviously... to make things as different as possible! It's just trying to be different for being different's sake.

Sociology explains this way more than any technical merit, we are prone to this in the D community because well it's an alternative language, it selects for people who likes alternatives.

This is the elephant in the room, why else would we argue (with so much passion) the technical merit of 20-lines recipe files?

And TOML is really tragic, I don't know if you have tried using it, I have and reverted to XML.

On Thursday, 28 February 2019 at 15:50:49 UTC, Seb wrote:
> My personal favorite "missing feature" in DUB is a direct git support. It would be really awesome if we would implement a "GitRegistry" for packages, s.t. one can directly depend on git repositories:
>
> dependency "my-package" version="git://.../my-branch#my-commit"

One can already just add a git submodule and point the dub dependency declaration at the resulting directory.  What features are you missing that aren't covered by this?

On Sunday, 3 March 2019 at 13:24:21 UTC, Joseph Rushton Wakeling wrote:
> One can already just add a git submodule and point the dub dependency declaration at the resulting directory.

Dub doesn't support git submodules (because it downloads the Zip archive from GitHub/GitLab).
So `dub fetch my-package` won't fetch any submodules. This is already a huge annoyance, but the mentioned point was about supporting git checkouts in dub, s.t. you can have Dub dependencies from any git source like in almost any other major package manager without them needing to be registered on the dub registry or to be manually checked out.

On Sunday, 3 March 2019 at 13:43:15 UTC, Seb wrote:
> On Sunday, 3 March 2019 at 13:24:21 UTC, Joseph Rushton Wakeling wrote:
>> One can already just add a git submodule and point the dub dependency declaration at the resulting directory.
>
> Dub doesn't support git submodules (because it downloads the Zip archive from GitHub/GitLab).

I think we may be talking at cross-purposes.  Here's what I was suggesting w.r.t. using git repos as a source for dub dependencies:

(1) add a submodule to your current project (let's use mir-glas as an example):
    git submodule add --name mir-glas https://github.com/libmir/mir-glas.git mir-glas

(2) add a dependency to dub.json pointing at the submodule directory:

        "dependencies": {
            "mir-glas": { "path": "./mir-glas" }
        }

This is only really needed though if one wants to create dependencies on projects that are not public DUB packages.  I think this ought to also support nested submodules, though I have not tried it.

Now OTOH if I understand your concerns right:

> So `dub fetch my-package` won't fetch any submodules. This is already a huge annoyance, but the mentioned point was about supporting git checkouts in dub, s.t. you can have Dub dependencies from any git source like in almost any other major package manager without them needing to be registered on the dub registry or to be manually checked out.

... you're concerned about the case where a DUB package relies on submodules for its complete source code?  I wonder if you could be more specific about the exact use case you have in mind, and why one would want to use submodules in that way?

What strikes me is that all the use cases one could think of probably come down to different examples of this: "How does one make DUB aware of and able to handle a codebase that does not include its own DUB package config?"

I'd suggest that considering that problem independent of any particular VCS might be more illuminating than asking how to make DUB git-repo-aware.

On Thursday, 28 February 2019 at 15:50:49 UTC, Seb wrote:
> @community: what features do you miss the most from DUB?

(1) Support for library maintainers' test requirements

Specifically: when a library has dependencies of its own, one wants to be sure the library stays compatible with the stated minimum supported version, because changing that could be a breaking change for downstreams.

With this in mind it would be useful to have:

  * a command to downgrade all dependencies in dub.selections.json
    to the minimum supported (including dependencies of dependencies)

  * a flag for build and test commands to request that the minimum
    versions of all dependencies be used

  * a flag to specify the maximum kind of version change `dub upgrade`
    can perform: patch, minor, or major.

(2) Cleanly and clearly separate between test options and build options

Specifically, this involves fixing the problems with `dub test` when the `--build` flag is used.

Example: if one runs `dub test --build=release` then intuitively one would expect (unit)tests to be run with release flags and optimizations enabled. In fact no unittests are run, because `--build=release` mandates a specific set of D flags that does not include `-unittest`.