Like these in rund? https://github.com/dragon-lang/rund#source-compiler-directives

Is that something that dlang would be open to for rdmd?

Cheers
- Ali

On Monday, 2 December 2019 at 18:48:41 UTC, aliak wrote:
> Like these in rund? https://github.com/dragon-lang/rund#source-compiler-directives
>
> Is that something that dlang would be open to for rdmd?
>
> Cheers
> - Ali

What is the advantage relative to the added complexity? Can't you use Dub or a Makefile if that's what you want? I'm disagreeing, I just don't know the use case.

On Monday, 2 December 2019 at 18:48:41 UTC, aliak wrote:
> Like these in rund? https://github.com/dragon-lang/rund#source-compiler-directives
>
> Is that something that dlang would be open to for rdmd?
>
> Cheers
> - Ali

Why not replace rdmd with rund?


RDMD is not actively developed anymore (last commit was 1 1/2 years ago [1]) and it's still twice as slow as rund as the -i upgrade PRs were rejected (see e.g. [2]).


[1] https://github.com/dlang/tools/commits/master/rdmd.d
[2] https://github.com/dlang/tools/pull/292

On Monday, 2 December 2019 at 19:32:58 UTC, bachmeier wrote:
> On Monday, 2 December 2019 at 18:48:41 UTC, aliak wrote:
>> Like these in rund? https://github.com/dragon-lang/rund#source-compiler-directives
>>
>> Is that something that dlang would be open to for rdmd?
>>
>> Cheers
>> - Ali
>
> What is the advantage relative to the added complexity? Can't you use Dub or a Makefile if that's what you want? I'm disagreeing, I just don't know the use case.

Dub is painfully slow for scripting, and if you require a makefile whenever someone wants to write a script then python it is.

The usecase is being able to have your scripts use the compiler flags you want (e.g. dip1000 and optimize, or whatever else).

On Monday, 2 December 2019 at 19:44:53 UTC, Seb wrote:
> On Monday, 2 December 2019 at 18:48:41 UTC, aliak wrote:
>> Like these in rund? https://github.com/dragon-lang/rund#source-compiler-directives
>>
>> Is that something that dlang would be open to for rdmd?
>>
>> Cheers
>> - Ali
>
> Why not replace rdmd with rund?
>
>
> RDMD is not actively developed anymore (last commit was 1 1/2 years ago [1]) and it's still twice as slow as rund as the -i upgrade PRs were rejected (see e.g. [2]).
>
>
> [1] https://github.com/dlang/tools/commits/master/rdmd.d
> [2] https://github.com/dlang/tools/pull/292

Hmm, there seems there's a bit too much resistance indeed :/ Why is that? THere's so much you can do with rdmd.

The only reason for rdmd really is that it comes with a default installation on osx. Asking people to install the dmd package via osx is already some friction, but then telling them to do rund as well.... well basically we just go to python.

I could maybe make a brew out of rund though ... 🤔

On Monday, 2 December 2019 at 20:13:24 UTC, aliak wrote:
> On Monday, 2 December 2019 at 19:44:53 UTC, Seb wrote:
>> [...]
>
> Hmm, there seems there's a bit too much resistance indeed :/ Why is that? THere's so much you can do with rdmd.
>
> The only reason for rdmd really is that it comes with a default installation on osx. Asking people to install the dmd package via osx is already some friction, but then telling them to do rund as well.... well basically we just go to python.
>
> I could maybe make a brew out of rund though ... 🤔

It's not a big deal if D tools are in separate packages.  I added rund to the nix package manager already, adding it to brew should be fine.

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.

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.

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.

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

>> 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.

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.

> 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. 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.

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? Suppose a General asked for input on how to
assault a position, and a Colonel responded by waxing about the
very serious hazards posed by the very small rocks to be found
in the desert near the position? "Why, if a soldier were to
kneel down during the battle to inspect one of these rocks, he
might scratch a finger. It is also conceivable that some
arrangement of small rocks might make for slippery footing. For
these reasons we should take the much more heavily defended
western approach, which--"

Are you serious? Are you actually serious?