On Tuesday, 3 December 2019 at 02:02:08 UTC, mipri wrote:
> This level of scare-mongering about some trivial array
> manipulation is absurd to the point that I actually start to
> suspect malicious intentions. Who sent you and how much are
> they paying you?

I wasn't kidding about this, but a more charitable
interpretation is: you don't use scripts, don't much care about
rdmd, and just want resources to go towards something else
instead. "c'mon guys, have you heard of makefiles? This is a
solved problem. Please work on something instead of this rdmd
thing that I'm not sure anyone even uses." Due to the
restricted communication channel (text) and certain internet
habits (everyone's spouting off like an authority about
everything, so weakly-stated claims are easily lost in the
noise) this reasonable wish can come across as I took it.

Well, not to worry:

1. This feature would only affect people using scripts, and
realistically any bugs would also only affect people using the
feature.

2. Technically it's easy enough that pretty much anyone could
do it. It'd be a good task for me, for example, when I probably
can't contribute to whatever you're thinking about as a more
desirable development.

So more relevant objections are stuff like "wouldn't letting
someone add -J in a script let them steal /etc/passwd with a
string import?" (there's no reason to give the dmd binary
setuid privs or anything so compile-time and run-time access
should be the same, but maybe there's some crazy circumstance
where this matters with selinux or OpenBSD stuff).

On Tuesday, 3 December 2019 at 02:02:08 UTC, mipri wrote:
> On Tuesday, 3 December 2019 at 01:28:00 UTC, bachmeier wrote:
>> On Monday, 2 December 2019 at 22:18:06 UTC, mipri wrote:
>>
>>> A script is a file with source code in it that you can execute.
>>> The essential feature of scripts is that the source code is
>>> what
>>> you're executing.
>>
>> If you include compiler directives inside the file, you're
>> *not* executing the code, because you're adding code to tell
>> the compiler what to do with the file.
>
> There's no operational difference. The user types ./foo, stuff
> happens. If the user edits foo and then types ./foo again,
> something different happens. The illusion break for D is that
> some invocations are slower than others due to compilation
> overhead. Python had (or has) the same effect, though less
> noticeable, with its .pyc cache files. This is bearable and
> compiler directives do not change it in any way.
>
>> You lose portability
>> once you add compilation information.
>
> This is actually an offensively ridiculous concern.
>
>>> In deployed systems, on servers, in other people's code, when
>>> you come across a binary that you have a problem with, it can
>>> be
>>> a long adventure to find the source of that binary, and then
>>> you
>>> may still have not found *the* source to *the* binary, but just
>>> *some* source that could create similar binaries. For example,
>>> if you find a repo link in a near by document, what commit to
>>> that repo was used to build the binary that you have?
>>
>> You can add a comment explaining how to compile the code.
>
> Comments are not code, and when you compile a script you get a
> binary, not a script. The exact same problems can arise: I have
> a problem with this binary and the source is nowhere to be
> found. Or I have a problem with this binary and the nearby
> script has a comment that may or may have not been followed to
> build it.
>
>> The
>> proposed change to rdmd would require a bunch of added
>> complexity,
>
> Adding code adds complexity. This is true.
>
>> probably introduce bugs
>
> Adding code probably adds bugs. This is also true.
>
>> duplicating Makefile functionality.
>
> Makefiles have nothing to do with scripts.
>
>> Let's leave currently
>> working tools alone.
>
> rdmd is not a "working tool" when your task requires some
> compiler flags.
>
> This level of scare-mongering about some trivial array
> manipulation is absurd to the point that I actually start to
> suspect malicious intentions. Who sent you and how much are
> they paying you?

I've had the same thoughts and feelings many times on this forum and in the Dlang community in general.  I've learned to spend less time trying to convince people so I can spend more time doing what I love, which is programming.  If I can't convince someone, or they are being unreasonable then I figure out how I can get what I want without their permission.  It usually means I must spend more time learning and possibly duplicating effort, but in my experience the trade-off is usually worth it.

After so much time arguing with people about rdmd, I created rund.  As a result, I now have a much faster and better tool that I've been using for over a year, and I've been spared a large amount of frustration.  Since I sometimes use this tool hundreds of times a day it was worth the investment, and I'm very happy with the result.  If others want to use it, improve it, or add it to package management systems then I'm happy to work with them and will be glad to see it help others as well.

P.S. you mentioned the 'noexec' issue, I noticed this a while back and opened an issue on it for rund (https://github.com/dragon-lang/rund/issues/17).  I have a few solutions but no one's really asked for it yet so I haven't chosen a solution yet.  When someone brings up a need and/or use case for it then I'll be implementing one of the solutions.

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
>
> Dub is painful for everything else so I'm not surprised to hear it's painful for scripting.
>
>> if you require a makefile whenever someone wants to write a script then python it is.
>
> If that's all it takes for someone to use Python, they'll be using Python regardless. I can understand the idea of rdmd if you can use it without configuration. If you're going to add compiler configuration information to your "script", you no longer have a script, you have something really confusing for Python users.

This is not true. I'd rather use D for scripting, but not if it requires the user to deal with make files - that's just compiling then. Your other point is also untrue, node had a 'use strict' interpreter directive for a long time, which people used willingly because it made the script code better. For the script user there was no difference (they just use the script, they don't care if it uses dip1000 or not).

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.

> Dub is painful for everything else so I'm not surprised to hear it's painful for scripting.

Dub is probably the best thing that happened to D in the past 5 years. Yes, it has its share of problems, but I don't think any of them are unfixable or by design. Instead of bashing it, I think this discussion could be more productive if you shared your criticism in a constrictive way.

On Tuesday, 3 December 2019 at 06:55:41 UTC, Jonathan Marler wrote:
>
> I've had the same thoughts and feelings many times on this forum and in the Dlang community in general.  I've learned to spend less time trying to convince people so I can spend more time doing what I love, which is programming.  If I can't convince someone, or they are being unreasonable then I figure out how I can get what I want without their permission.  It usually means I must spend more time learning and possibly duplicating effort, but in my experience the trade-off is usually worth it.

I understand where you're coming from. I really appreciate the amount and quality of work that you have contributed to D over the years. I think it's quite unfortunate if D's community can't reach a consensus and work together, instead of being divided (or even just duplicating effort).

>
> After so much time arguing with people about rdmd, I created rund.  As a result, I now have a much faster and better tool that I've been using for over a year, and I've been spared a large amount of frustration.  Since I sometimes use this tool hundreds of times a day it was worth the investment, and I'm very happy with the result.  If others want to use it, improve it, or add it to package management systems then I'm happy to work with them and will be glad to see it help others as well.

Given the amount of good work invested in D build tools, such as rdmd, rund, build.d and dub, it's really sad that they're becoming a source of contention and divisive among the D community.

I believe that the best thing that can happen to D is if all the effort that's invested across all of them gets merged into a single code base, maintained by all authors and endorsed by the community as whole.

I see no reason why we couldn't work on a shared code base that it's as easy and fast to use as rund, offer larger-scale development features, such as dependency management and also offer direct and expressive way to manually declare new targets, like build.d.

On Monday, 2 December 2019 at 22:18:06 UTC, mipri wrote:
>
> I have a bash script that uses 'dub run' to invoke dfmt, and the
> chief problem with that is that any random use of dfmt may
> trigger a slow library upgrade. If shebang uses of dub work like
> this as well, that's a big problem for scripting. In the more
> limited use of dub scripts that I've used, they're fine. Caching
> is very similar to rdmd.

The first time `dub run dfmt` is run, dfmt will be fetched and built.
After that you can run it like this:

   dub run dfmt --skip-registry=standard -- <DFMT args>

to skip network checks.

> I'm not fond of /tmp as a default (it's often noexec) but
> there's no variation here in the tooling.

Dub keeps packages and build artifacts in `$HOME/.dub/packages`, and in my experience this works really well.

>>> if you require a makefile whenever someone wants to write a
>>> script then python it is.
>>
>> If that's all it takes for someone to use Python, they'll be
>> using Python regardless. I can understand the idea of rdmd if
>> you can use it without configuration. If you're going to add
>> compiler configuration information to your "script", you no
>> longer have a script, you have something really confusing for
>> Python users.
>
> A script is a file with source code in it that you can execute.
> The essential feature of scripts is that the source code is what
> you're executing.
>
> In deployed systems, on servers, in other people's code, when
> you come across a binary that you have a problem with, it can be
> a long adventure to find the source of that binary, and then you
> may still have not found *the* source to *the* binary, but just
> *some* source that could create similar binaries. For example,
> if you find a repo link in a near by document, what commit to
> that repo was used to build the binary that you have?
>
> With a script, the source is always there. This helps enormously
> in troubleshooting, especially hands-on kind of troubleshooting
> where you temporary modify the program to see how this affects
> what you're investigating. If someone has coded in an ill-advised
> restriction, you can temporarily bypass it. If there's a bug and
> the fix can't be deployed for whatever reason, you can tell
> people about a sed oneliner that fixes the script in situ on
> machines where they need the fix. You may not even have access
> to see the repo that the script's source is in, but since you
> have the script you can fix a problem and email the author a
> patch.
>
> The documentation is also often always there, as it can be
> inline with the script. You may be able to 'perldoc
> /root/bin/special_sysadmin_thing' and get more detailed notes
> about the exact version of the exact thing at hand.
>
> Compiler configuration flags change nothing at all about this.

I completely agree.

On Tuesday, 3 December 2019 at 01:28:00 UTC, bachmeier wrote:
> On Monday, 2 December 2019 at 22:18:06 UTC, mipri wrote:
>
>> A script is a file with source code in it that you can execute.
>> The essential feature of scripts is that the source code is what
>> you're executing.
>
> If you include compiler directives inside the file, you're *not* executing the code, because you're adding code to tell the compiler what to do with the file. You lose portability once you add compilation information.

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. Instead good scripts should contain all the necessary information to be run in a self-sufficient and cross-platform manner. This can include the compiler version (e.g. DMD 2.085.0 or LDC 1.19.0-beta2), the build tool (e.g. dub 1.16.0), the build flags (e.g. -dip1000) and any libraries that they depend on (e.g. phobos 2.089.0, mir-algorithm 3.7.2).

>> In deployed systems, on servers, in other people's code, when
>> you come across a binary that you have a problem with, it can be
>> a long adventure to find the source of that binary, and then you
>> may still have not found *the* source to *the* binary, but just
>> *some* source that could create similar binaries. For example,
>> if you find a repo link in a near by document, what commit to
>> that repo was used to build the binary that you have?
>
> You can add a comment explaining how to compile the code.

A mechanically verifiable and executable directive is infinitely better ;)

> The proposed change to rdmd would require a bunch of added complexity, and probably introduce bugs, all in the name of duplicating Makefile functionality. Let's leave currently working tools alone.

IMO these use cases already solved by dub and rund, so I think there's no need to duplicate the functionality. The functionality is very much worth it there.

On Tuesday, 3 December 2019 at 09:10:16 UTC, Petar Kirov [ZombineDev] wrote:
> [snip]
> Dub is probably the best thing that happened to D in the past 5 years. [snip]

I agree. Dub is not perfect, but it is a great thing.

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.

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.