On Wednesday, 17 January 2024 at 15:30:27 UTC, zjh wrote:
>Very similar to the plugin style development of vim!
Transform the 'dip'
of 'd'
into a 'vim '
like' plugin
that users can freely assemble
and update at any time.
January 17 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to zjh | On Wednesday, 17 January 2024 at 15:30:27 UTC, zjh wrote: >Very similar to the plugin style development of vim! Transform the |
January 17 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to zjh | On Wednesday, 17 January 2024 at 15:30:27 UTC, zjh wrote: >On Wednesday, 17 January 2024 at 15:17:47 UTC, zjh wrote: >I think it's more convenient to integrate it into the
This is a good point. Rust has unstable features that are only available on their nightly builds. Some of them are also gated behind a feature flag. The end result is that the community has plenty of time to test out new features and hash out any dark corners. |
January 17 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | On Wednesday, 17 January 2024 at 19:29:28 UTC, Meta wrote: >This is a good point. Rust has unstable features that are only available on their nightly builds. Some of them are also gated behind a feature flag. The end result is that the community has plenty of time to test out new features and hash out any dark corners. Forgot the link: |
January 17 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to zjh | On 1/17/2024 7:07 AM, zjh wrote:
> Yes, why don't I participate in these debates because I can't even `try them out`. How do I know the `pros and cons`?
> Only after `practical testing` can a more specific understanding be obtained. Otherwise, it is just `nonsense`.
> And the `endless debate` is a waste of time!
If you can build the compiler, it's not hard to merge a fork into your local copy and then build it.
I had trouble with that because every search query gave me the wrong git command to do this. I wound up asking some team members, and got the right command.
The forking system is the way to do this. It isn't very practical to try and maintain binaries of each PR.
DMD is pretty friendly to build from scratch. On my machine:
time make debug
takes 26 seconds to build on an ancient Linux box.
|
January 18 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to RazvanN | On 1/17/24 15:26, RazvanN wrote:
> On Wednesday, 17 January 2024 at 14:19:37 UTC, ryuukk_ wrote:
>> On Wednesday, 17 January 2024 at 02:16:01 UTC, zjh wrote:
>>> On Tuesday, 16 January 2024 at 20:38:37 UTC, Walter Bright wrote:
>>>> https://github.com/dlang/dmd/pull/15715
>>>>
>>>> I was unconvincing in my arguments, there was too much acrimony, and its effects do not affect the rest of the language.
>>>
>>>
>>>
>>> In fact, two switches can also be provided for continuous feedback during use.
>>> We should also establish an `experimental mechanism` that allows for the revocation of the switch if it causes significant harm!
>>
>> I agree with that
>>
>> It should have been like other features, both under -preview switch, then a period of several months for testing, then a debate in forums about wich is better
>>
>> Do this with tuple, pattern matching, and tagged union, so people can test, give feedback, propose improvements without commitment for integration
>>
>>
>> I already use 2 preview switches in my project:
>>
>> -preview=rvaluerefparam
>> -preview=bitfields
>>
>>
>> I love rvaluerefparam, it should go core, but bitfields is imo bad, i'd prefer to be able to get bit specific integer type instead..
>>
>
> Please be careful with that switch as it has a lot of bugs (and as far as I remember it's not completely implemented). I have tried turning it on by default in the compiler and was not able to compile phobos (however, I do not remember what the problems were).
>
> RazvanN
>
>
Well, Phobos relies on rvalues not binding to ref parameters in order to check via `__traits(compiles, ...)` whether something is an lvalue.
|
January 18 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to zjh | On Wednesday, 17 January 2024 at 15:07:08 UTC, zjh wrote: >On Wednesday, 17 January 2024 at 14:19:37 UTC, ryuukk_ wrote: >I already use 2 preview switches in my project: -preview=rvaluerefparam I love rvaluerefparam, it should go core, but bitfields is imo bad, i'd prefer to be able to get bit specific integer type instead.. I personally have no need for string interpolation Yes, why don't I participate in these debates because I can't even Majority isn't always right. This might not end up well. Debate is good. Just have to be healthy. |
January 18 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Wednesday, 17 January 2024 at 20:42:24 UTC, Walter Bright wrote: >DMD is pretty friendly to build from scratch. On my machine: time make debug takes 26 seconds to build on an ancient Linux box. It doesn't work like this. The process of building DMD starts from going to https://github.com/dlang/dmd and then reading (or at least skimming through) a number of web pages and clicking through them to navigate to the right place with the appropriate build instructions:
This kinda violates the https://en.wikipedia.org/wiki/Three-click_rule, which isn't a gospel, but still has some merit. All of this together is surely doable, but takes way longer than 26 seconds and the CPU speed isn't the bottleneck. And I'm even not talking about building D compilers on unpopular marginal operating systems, such as Windows, which barely have any support at all: |
January 18 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to Siarhei Siamashka | On Thursday, 18 January 2024 at 09:29:03 UTC, Siarhei Siamashka wrote: >On Wednesday, 17 January 2024 at 20:42:24 UTC, Walter Bright wrote: >DMD is pretty friendly to build from scratch. On my machine: time make debug takes 26 seconds to build on an ancient Linux box. It doesn't work like this. The process of building DMD starts from going to https://github.com/dlang/dmd and then reading (or at least skimming through) a number of web pages and clicking through them to navigate to the right place with the appropriate build instructions:
This kinda violates the https://en.wikipedia.org/wiki/Three-click_rule, which isn't a gospel, but still has some merit. All of this together is surely doable, but takes way longer than 26 seconds and the CPU speed isn't the bottleneck. And I'm even not talking about building D compilers on unpopular marginal operating systems, such as Windows, which barely have any support at all: Funny thing is, DMD is super easy to build on Windows. You just have to somehow figure out to |
January 18 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Wednesday, 17 January 2024 at 20:42:24 UTC, Walter Bright wrote: >The forking system is the way to do this. It isn't very practical to try and maintain binaries of each PR. It's not necessary to maintain binaries of each PR. We are talking about potentially having pre-built compiler binaries for DIP1036e or for any other proposed controversial language features, which instigate a lot of debates. The point was made about the existence of a certain fraction of users, who have no skills or patience to build the patched compiler themselves. These people feel left out. Well, in a way that's their fault and nobody has any obligation to help them. |
January 18 Re: I approved DIP1036e | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dibyendu Majumdar | On Wednesday, 17 January 2024 at 10:58:44 UTC, Dibyendu Majumdar wrote:
> On Wednesday, 17 January 2024 at 10:54:07 UTC, claptrap wrote:
>> You are niave and misinformed, alot of people, even core devs are not happy with how things are managed.
>>
>> And I'm not attacking anyone, it's just debate and criticism.
>>
>
> Its people like you who are the problem.
>
> In all the discussions, Walter always argues technical points, he never abuses or name calls people or attacks them personally.
>
> It is the contributors job to convince not the other way round.
see, there's your problem. it's not the contributors job, they do this in their free time.
if you want contributions you simply cannot act like that.
|