On Tuesday, 3 December 2019 at 09:46:59 UTC, Petar Kirov [ZombineDev] wrote:
> On the contrary. Without compiler directives or a tool that has them built-in, like dub or rdmd/rund you don't have any portability, because you have no idea how run build the script. It's ridiculous to expect just the right set dependencies to be magically installed on the system where the script will run.

None of this is relevant if you have a tool that is limited to running code that doesn't need compiler directives. I'm aware that some people think you have to add every feature to every tool. I disagree. Especially in cases where the functionality is already provided by other tools.

On Tuesday, 3 December 2019 at 13:56:33 UTC, bachmeier wrote:
> On Tuesday, 3 December 2019 at 09:10:16 UTC, Petar Kirov [ZombineDev] wrote:
>
>> Instead of bashing it, I think this discussion could be more productive if you shared your criticism in a constrictive way.
>
> There have been many, many long threads on this already.

And it is merely technically *possible* to receive them. It's
not easy, or convenient, or definitely going to happen. The
retrieved conversation is not necessarily even useful to
someone capable of taking action on any matters raised but not
capable of telling, without unrelated efforts, which of the
matters raised is even still relevant, or not obviated by later
(as yet unearthed) conversation.

If you don't put your words in a wiki or an issue you should
better treat the conversation as if it happened in person and
your words were lost to the wind. Teams of archaeologists are
not available.

On Tuesday, 3 December 2019 at 14:45:47 UTC, mipri wrote:
> On Tuesday, 3 December 2019 at 13:56:33 UTC, bachmeier wrote:
>> On Tuesday, 3 December 2019 at 09:10:16 UTC, Petar Kirov [ZombineDev] wrote:
>>
>>> Instead of bashing it, I think this discussion could be more productive if you shared your criticism in a constrictive way.
>>
>> There have been many, many long threads on this already.
>
> And it is merely technically *possible* to receive them. It's
> not easy, or convenient, or definitely going to happen. The
> retrieved conversation is not necessarily even useful to
> someone capable of taking action on any matters raised but not
> capable of telling, without unrelated efforts, which of the
> matters raised is even still relevant, or not obviated by later
> (as yet unearthed) conversation.
>
> If you don't put your words in a wiki or an issue you should
> better treat the conversation as if it happened in person and
> your words were lost to the wind. Teams of archaeologists are
> not available.

Sounds good.

On Tuesday, 3 December 2019 at 13:07:04 UTC, aliak wrote:
> On Tuesday, 3 December 2019 at 09:10:16 UTC, Petar Kirov [ZombineDev] wrote:
>> On Monday, 2 December 2019 at 21:43:17 UTC, bachmeier wrote:
>>> On Monday, 2 December 2019 at 20:04:17 UTC, aliak wrote:
>>>
>>>> Dub is painfully slow for scripting
>>
>> On the contrary, I think it's great for what it offers.
>> I just made a quick test and it contributed to to 0.3sec slow down, compared to `dmd -run` of minimal D script (0.21sec vs 0.51sec). I think that could be improved, but still it's a small price to given its feature set. There's no alternative tool for D that empowers single-file scripts to use third-party libraries with zero fiddling with import paths, dependency downloading, build order, linking and so on.
>
> The script I run takes over a second each invocation (when doing nothing). With rdmd that happens once and then it uses the same binary (and is instant).
>
> Do you know if dub caches the binary? If it does then it's just dependency checking. And if that can be turned off then I believe the experience can be satisfactory. But right now it's painful.

Dub is supposed to cache every build artifact, but for some reason the `isUpToDate` function returns `false` for a single-file package I am testing with.

BTW, on what OS and hardware are you testing?
I am on Linux with an SSD, so this may explain why I get faster results than you.

Dub has everything necessary to reach execution time parity up +/- 5% with rdmd.
The dependency checking is relatively fast for me, but if necessary that can be easily disabled, using the `--skip-registry` option.
If it's not already like that IMO dub shouldn't check for updates for single-file packages. For projects with dub.selections.json AFAIK it doesn't check for updates if dub.selection.json contains the versions of transitive dependencies and they had already been fetched.

I'll look into the problem with Dub's `isUpToDate`.

On Tuesday, 3 December 2019 at 14:01:07 UTC, bachmeier wrote:
> On Tuesday, 3 December 2019 at 09:46:59 UTC, Petar Kirov [ZombineDev] wrote:
>> On the contrary. Without compiler directives or a tool that has them built-in, like dub or rdmd/rund you don't have any portability, because you have no idea how run build the script. It's ridiculous to expect just the right set dependencies to be magically installed on the system where the script will run.
>
> None of this is relevant if you have a tool that is limited to running code that doesn't need compiler directives. I'm aware that some people think you have to add every feature to every tool. I disagree. Especially in cases where the functionality is already provided by other tools.

This is true in most cases.  The problem is that some requirements of a D program can't be configured in the source file.  They can only be specified on the command-line.

For example, if you have a D program that requires -betterC, you couldn't declare this source file itself.  You can't specify import paths, versions and many other options in the source file.

Not all programs need to specify any of these options, but some do.  Here's an example of a D script that requires import paths, a version, betterC, and no dmd.conf file:

https://github.com/dragon-lang/mar/blob/master/test/go.d

Without "Source Compiler Directives" this source file would not be able to declare the options that are required to build/run it correctly.  These requirements would need to be satisfied outside the source file itself, either through user intervention on the command-line or through some other tool.

Some D scripts have requirements that can only be specified via compiler flags.  I would rather have a way to specify these in the language but for now this feature solves the issue without having to make any big changes to the language.

On Tuesday, 3 December 2019 at 14:01:07 UTC, bachmeier wrote:
> On Tuesday, 3 December 2019 at 09:46:59 UTC, Petar Kirov [ZombineDev] wrote:
>> On the contrary. Without compiler directives or a tool that has them built-in, like dub or rdmd/rund you don't have any portability, because you have no idea how run build the script. It's ridiculous to expect just the right set dependencies to be magically installed on the system where the script will run.
>
> None of this is relevant if you have a tool that is limited to running code that doesn't need compiler directives. I'm aware that some people think you have to add every feature to every tool. I disagree. Especially in cases where the functionality is already provided by other tools.

I don't follow, are you arguing that worse is better? Why would one use an inferior tool, if there's another one providing a strict superset of features (or at least a superset of the ones that one needs) at the same level or better performance?

Unless one is in the unlikely position of writing a single source file (with no imports/includes) bare-metal application I don't see a situation where one doesn't have any dependencies. Even shell scripts have implicit dependencies on things like the shell interpreter (dash vs bash vs zsh vs fish vs ...), its version, the available executable files in $PATH, other environment variables, and other things.

Instead, I believe every program meant to be used by more than one person should contain complete dependency information, so building and running it is completely reproducible. For example, I was one of the supporters of a Dub feature [0] using which you specify the requirements on the D toolchain like this:

  toolchainRequirements dub=">=1.14.0" frontend=">=2.080 <2.090"

This one of reason why I use NixOS [1][2][3].

[0]: https://dlang.org/changelog/2.085.0.html#toolchain_requirements
[1]: https://nixos.org/
[2]: https://nixos.org/nix/
[3]: https://nixos.wiki/wiki/NixOS

On Tuesday, 3 December 2019 at 16:33:32 UTC, Petar Kirov [ZombineDev] wrote:
>
> Dub is supposed to cache every build artifact, but for some reason the `isUpToDate` function returns `false` for a single-file package I am testing with.
>
> BTW, on what OS and hardware are you testing?
> I am on Linux with an SSD, so this may explain why I get faster results than you.

I'm on this year's macbook pro with catalina (latest macOS), ssd as well.

>
> Dub has everything necessary to reach execution time parity up +/- 5% with rdmd.
> The dependency checking is relatively fast for me, but if necessary that can be easily disabled, using the `--skip-registry` option.
> If it's not already like that IMO dub shouldn't check for updates for single-file packages. For projects with dub.selections.json AFAIK it doesn't check for updates if dub.selection.json contains the versions of transitive dependencies and they had already been fetched.
>
> I'll look into the problem with Dub's `isUpToDate`.

Cool! I think if that's all it is then even a 1 sec initial run is not horrible.

On Tuesday, 3 December 2019 at 17:16:07 UTC, Petar Kirov [ZombineDev] wrote:
> On Tuesday, 3 December 2019 at 14:01:07 UTC, bachmeier wrote:
>> On Tuesday, 3 December 2019 at 09:46:59 UTC, Petar Kirov [ZombineDev] wrote:
>>> On the contrary. Without compiler directives or a tool that has them built-in, like dub or rdmd/rund you don't have any portability, because you have no idea how run build the script. It's ridiculous to expect just the right set dependencies to be magically installed on the system where the script will run.
>>
>> None of this is relevant if you have a tool that is limited to running code that doesn't need compiler directives. I'm aware that some people think you have to add every feature to every tool. I disagree. Especially in cases where the functionality is already provided by other tools.
>
> I don't follow, are you arguing that worse is better?

I'm saying we have different definitions of "worse". In your opinion, the only thing that matters is the number of features, and that's fine. In my opinion, we need to account for the ease of use of a tool, particularly for beginners, the difficulty of maitenance of the tool, the possibility of clashing with current and future features, and the number of bugs users encounter. rdmd works, so let's not break it without a really good reason, and I haven't seen a really good reason.

> Why would one use an inferior tool, if there's another one providing a strict superset of features (or at least a superset of the ones that one needs) at the same level or better performance?

Nobody would use an inferior tool (that's an interesting choice of language) but I don't agree fewer features implies it's inferior.

> Unless one is in the unlikely position of writing a single source file (with no imports/includes) bare-metal application I don't see a situation where one doesn't have any dependencies. Even shell scripts have implicit dependencies on things like the shell interpreter (dash vs bash vs zsh vs fish vs ...), its version, the available executable files in $PATH, other environment variables, and other things.

rdmd has worked well for many years without the proposed duplication of features.

On Tuesday, 3 December 2019 at 16:45:52 UTC, Jonathan Marler wrote:

>> None of this is relevant if you have a tool that is limited to running code that doesn't need compiler directives. I'm aware that some people think you have to add every feature to every tool. I disagree. Especially in cases where the functionality is already provided by other tools.
>
> This is true in most cases.  The problem is that some requirements of a D program can't be configured in the source file.  They can only be specified on the command-line.
>
> For example, if you have a D program that requires -betterC, you couldn't declare this source file itself.  You can't specify import paths, versions and many other options in the source file.

Why is it necessary to do this with rdmd? Aren't there already tools that do this? I'm honestly surprised that someone using -betterC would even want a script.

> Not all programs need to specify any of these options, but some do.  Here's an example of a D script that requires import paths, a version, betterC, and no dmd.conf file:
>
> https://github.com/dragon-lang/mar/blob/master/test/go.d

But you were able to do that without rdmd.

On Tuesday, 3 December 2019 at 18:47:06 UTC, bachmeier wrote:
> On Tuesday, 3 December 2019 at 16:45:52 UTC, Jonathan Marler wrote:
>
>>> None of this is relevant if you have a tool that is limited to running code that doesn't need compiler directives. I'm aware that some people think you have to add every feature to every tool. I disagree. Especially in cases where the functionality is already provided by other tools.
>>
>> This is true in most cases.  The problem is that some requirements of a D program can't be configured in the source file.  They can only be specified on the command-line.
>>
>> For example, if you have a D program that requires -betterC, you couldn't declare this source file itself.  You can't specify import paths, versions and many other options in the source file.
>
> Why is it necessary to do this with rdmd? Aren't there already tools that do this? I'm honestly surprised that someone using -betterC would even want a script.

There are always going to be people who use tools in ways that you don't - probably, the majority of use cases are not your use cases.

While person A will make a makefile and source file, and have the user download it, run make, install, and then be able to run it, person B will use a tool that allows their users to "just run it".

>
>> Not all programs need to specify any of these options, but some do.  Here's an example of a D script that requires import paths, a version, betterC, and no dmd.conf file:
>>
>> https://github.com/dragon-lang/mar/blob/master/test/go.d
>
> But you were able to do that without rdmd.

You asked for compiler source directive use cases.

And yes, point being he can't use rdmd for writing the scripts he needs to write.