Thread overview | |||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
December 02, 2019 How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
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 |
December 02, 2019 Re: How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
Posted in reply to aliak | 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.
|
December 02, 2019 Re: How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
Posted in reply to aliak | 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 |
December 02, 2019 Re: How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bachmeier | 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).
|
December 02, 2019 Re: How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Seb | 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 ... 🤔
|
December 02, 2019 Re: How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
Posted in reply to aliak | 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.
|
December 02, 2019 Re: How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
Posted in reply to aliak | 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. |
December 02, 2019 Re: How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bachmeier | 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. |
December 03, 2019 Re: How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
Posted in reply to mipri | 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. |
December 03, 2019 Re: How do people feel about putting source compiler directives inside rdmd? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bachmeier | 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? |
Copyright © 1999-2021 by the D Language Foundation