On Saturday, 15 September 2018 at 23:50:43 UTC, Josphe Brigmo wrote:
> [...]

D is generally described as a system programming language. There is value in favoring a simple and obvious implementation ("do what I say") over going out of one's way to make usage simpler ("do what I mean"). The tradeoff is performance and complexity. Performance is generally an important factor for users of system programming languages, and complexity is a source of unforeseen problems in non-trivial use cases.

Consider, for example, how integers are treated in D and Python. D's integers are fixed-length and roll over on overflow. Python integers are bigints, which makes them slower, but can handle numbers of any size.

From your posts, it sounds like you're looking for a programming language closer to Python than to D.

On Saturday, September 15, 2018 5:47:08 PM MDT tide via Digitalmars-d wrote:
> On Saturday, 15 September 2018 at 18:33:52 UTC, bachmeier wrote:
> > On Saturday, 15 September 2018 at 13:54:45 UTC, tide wrote:
> >> On Friday, 14 September 2018 at 19:17:58 UTC, bachmeier wrote:
> >>> On Friday, 14 September 2018 at 19:06:14 UTC, Josphe Brigmo
> >>>
> >>> wrote:
> >>>> For very long file names it is broke and every command fails. These paths are not all that long but over 256 limit. (For windows)
> >>>
> >>> Please file a bug report with reproducible examples if you believe it's a bug.
> >>
> >> I feel people need to stop saying this.
> >
> > That's how things are done in this project (and most projects). Anyone not liking that is out of luck. I don't use any open source projects that use vague posts to a forum to report bugs.
>
> That's how they are, but if you are going to say silly things. At least take the initiative on yourself to go see if the bug already exists. Odds are it has probably already been reported, someone making a forums post about it is just able the next step after the bug report has been sitting in the queue for 4+ years.
>
> The problem isn't reporting the bug, it's that for D, no one is managing bugzilla. It seems to be the conclusion was reached that this is not a bug and won't be fixed. That could have been done a long time ago and closed the bug. Or at least I think Jonathan is part of the Dlang organization. Not sure, hard to tell who is and isn't on these boards.

The issue was reported in bugzilla quite some time ago.

https://issues.dlang.org/show_bug.cgi?id=8967

However, while Walter's response on it basically indicates that we should just close it as "won't fix," we never actually did - which is something that probably happens too often. There was further discussion in there that never went anywhere. What we should probably do is ensure that the std.file documentation is clear about the issue and count that as the fix. Either way, I think that it's pretty clear that the documentation needs to be improved.

As for figuring out who is "officially" part of the dlang org (or at least has the rights to merge PRs from at least one dlang repo), you can look here

https://github.com/orgs/dlang/people

though it's possible to hide your membership, so while I see 59 members when I look at it while signed in, if I look at it while not signed in, I see only 40.

- Jonathan M Davis

On Sunday, 16 September 2018 at 00:14:12 UTC, Jonathan M Davis wrote:
> As for figuring out who is "officially" part of the dlang org (or at least has the rights to merge PRs from at least one dlang repo), you can look here
>
> https://github.com/orgs/dlang/people
>
> though it's possible to hide your membership, so while I see 59 members when I look at it while signed in, if I look at it while not signed in, I see only 40.

I think it's worth clarifying: Only Walter and Andrei have the final say on things. Everyone else is a contributor (with a small few financially rewarded for their work). So, the above list of people isn't a good metric for much other than knowing who can merge your PR.

On Saturday, 15 September 2018 at 18:21:43 UTC, Josphe Brigmo wrote:
> On Saturday, 15 September 2018 at 13:37:29 UTC, Vladimir Panteleev wrote:
>> Can you list some programming languages that achieve this task in a way you approve of?
>
> Plenty, pick just about any one. C#, Haskell, javascript, lua, python, perl, C++(yes, c++, we are not talking about language features but usability). The simple fact is that C++ can be used to do anything almost 100% correct while D can fail. D is only a better language, not a better compiler(except it's speed).

See you are just talking out of your ass right now. I just tried C++, it doesn't work. You can't use std::fstream with a path that is larger than 260. I also moved an executable to that large path. And guess what I couldn't even get Windows to run it. Not through powershell nor explorer. I can't even run applications like "ls" with powershell. Let alone "cd" into the folder. oddly enough the only thing that came close was git bash, which gave me an error message. While powerhshell just said couldn't find path.

```
Error: Current working directory has a path longer than allowed for a
Win32 working directory.
Can't start native Windows application from here.
```

I don't know how you can complain about D when Windows is so fundamentally broken for large files path, that even it's set of tools don't support it.

Another one, Python: https://docs.python.org/3/using/windows.html#removing-the-max-path-limitation

It does not support long paths, you have to use \\?\ or enable it with the registry (only on newer Windows 10 versions).

If you are going to make claims -- Do Your Research.

On Saturday, September 15, 2018 6:28:20 PM MDT Vladimir Panteleev via Digitalmars-d wrote:
> On Sunday, 16 September 2018 at 00:14:12 UTC, Jonathan M Davis
>
> wrote:
> > As for figuring out who is "officially" part of the dlang org (or at least has the rights to merge PRs from at least one dlang repo), you can look here
> >
> > https://github.com/orgs/dlang/people
> >
> > though it's possible to hide your membership, so while I see 59 members when I look at it while signed in, if I look at it while not signed in, I see only 40.
>
> I think it's worth clarifying: Only Walter and Andrei have the final say on things. Everyone else is a contributor (with a small few financially rewarded for their work). So, the above list of people isn't a good metric for much other than knowing who can merge your PR.

Yeah, the list is mostly of folks who have contributed significantly enough to have been given merge permissions at some point. Some of us may have some influence based on how long we've been with the project and the level of knowledge and expertise that we've shown in the process, but as far as deciding the direction of the project or anything like that, it's all Walter and Andrei. The primary influence that any of us have is simply by the work we contribute via PRs and the feedback we give when reviewing PRs. It's not like there's a hierarchy of authority or anything like that. For the most part, the only authority that Walter and Andrei have given others is the authority to merge PRs.

- Jonathan M Davis

On Sunday, 16 September 2018 at 00:53:45 UTC, Jonathan M Davis wrote:
> On Saturday, September 15, 2018 6:28:20 PM MDT Vladimir Panteleev via Digitalmars-d wrote:
>> On Sunday, 16 September 2018 at 00:14:12 UTC, Jonathan M Davis
>>
>> wrote:
>> > As for figuring out who is "officially" part of the dlang org (or at least has the rights to merge PRs from at least one dlang repo), you can look here
>> >
>> > https://github.com/orgs/dlang/people
>> >
>> > though it's possible to hide your membership, so while I see 59 members when I look at it while signed in, if I look at it while not signed in, I see only 40.
>>
>> I think it's worth clarifying: Only Walter and Andrei have the final say on things. Everyone else is a contributor (with a small few financially rewarded for their work). So, the above list of people isn't a good metric for much other than knowing who can merge your PR.
>
> Yeah, the list is mostly of folks who have contributed significantly enough to have been given merge permissions at some point. Some of us may have some influence based on how long we've been with the project and the level of knowledge and expertise that we've shown in the process, but as far as deciding the direction of the project or anything like that, it's all Walter and Andrei. The primary influence that any of us have is simply by the work we contribute via PRs and the feedback we give when reviewing PRs. It's not like there's a hierarchy of authority or anything like that. For the most part, the only authority that Walter and Andrei have given others is the authority to merge PRs.
>
> - Jonathan M Davis

I guess that's why Bugzilla is a complete disaster. No one, at all, is maintaining it. As there are only 2 people that can really maintain it, and I don't see either of them commenting on bugs to provide direction, at least very often.

On Saturday, September 15, 2018 7:19:46 PM MDT tide via Digitalmars-d wrote:
> On Sunday, 16 September 2018 at 00:53:45 UTC, Jonathan M Davis
>
> wrote:
> > On Saturday, September 15, 2018 6:28:20 PM MDT Vladimir
> >
> > Panteleev via Digitalmars-d wrote:
> >> On Sunday, 16 September 2018 at 00:14:12 UTC, Jonathan M Davis
> >>
> >> wrote:
> >> > As for figuring out who is "officially" part of the dlang org (or at least has the rights to merge PRs from at least one dlang repo), you can look here
> >> >
> >> > https://github.com/orgs/dlang/people
> >> >
> >> > though it's possible to hide your membership, so while I see 59 members when I look at it while signed in, if I look at it while not signed in, I see only 40.
> >>
> >> I think it's worth clarifying: Only Walter and Andrei have the final say on things. Everyone else is a contributor (with a small few financially rewarded for their work). So, the above list of people isn't a good metric for much other than knowing who can merge your PR.
> >
> > Yeah, the list is mostly of folks who have contributed significantly enough to have been given merge permissions at some point. Some of us may have some influence based on how long we've been with the project and the level of knowledge and expertise that we've shown in the process, but as far as deciding the direction of the project or anything like that, it's all Walter and Andrei. The primary influence that any of us have is simply by the work we contribute via PRs and the feedback we give when reviewing PRs. It's not like there's a hierarchy of authority or anything like that. For the most part, the only authority that Walter and Andrei have given others is the authority to merge PRs.
>
> I guess that's why Bugzilla is a complete disaster. No one, at all, is maintaining it. As there are only 2 people that can really maintain it, and I don't see either of them commenting on bugs to provide direction, at least very often.

Pretty much everything done around here is done by volunteers. There are contributors who sometimes go through bugzilla to update or close bugs, and there are contributors who go looking through bugzilla for bugs to fix, but there is no one whose job it is to manage the list of bugs. I don't know of any open source project that works that way. Usually, at most, you end up with bugs being automatically assigned to people based on what they're for.

- Jonathan M Davis

On Sunday, 16 September 2018 at 01:19:46 UTC, tide wrote:
> I guess that's why Bugzilla is a complete disaster. No one, at all, is maintaining it. As there are only 2 people that can really maintain it, and I don't see either of them commenting on bugs to provide direction, at least very often.

Well, I think that's looking at the situation from the wrong angle.

Most of D's code was written by volunteer contributors, and usually the code's author ends up maintaining that code, at least for a while. So, when you find a bug in some part of D and can't fix it yourself, looking at who wrote or last maintained the relevant code and pinging them would be the first step.

There are some things we can improve, like upgrading the platform or improving the categorization so people can receive notifications when someone files a bug in a Phobos module they care about. I've been slowly working on that front (https://github.com/CyberShadow/bugzilla-meta), but it doesn't change the underlying facts that bugs are most likely to be fixed by people who work on the code, not Andrei or Walter or any one person "in charge" of Bugzilla.

On Sunday, 16 September 2018 at 01:33:52 UTC, Vladimir Panteleev wrote:
> On Sunday, 16 September 2018 at 01:19:46 UTC, tide wrote:
>> I guess that's why Bugzilla is a complete disaster. No one, at all, is maintaining it. As there are only 2 people that can really maintain it, and I don't see either of them commenting on bugs to provide direction, at least very often.
>
> Well, I think that's looking at the situation from the wrong angle.
>
> Most of D's code was written by volunteer contributors, and usually the code's author ends up maintaining that code, at least for a while. So, when you find a bug in some part of D and can't fix it yourself, looking at who wrote or last maintained the relevant code and pinging them would be the first step.
>
> There are some things we can improve, like upgrading the platform or improving the categorization so people can receive notifications when someone files a bug in a Phobos module they care about. I've been slowly working on that front (https://github.com/CyberShadow/bugzilla-meta), but it doesn't change the underlying facts that bugs are most likely to be fixed by people who work on the code, not Andrei or Walter or any one person "in charge" of Bugzilla.

There are a lot of issues that aren't simple bugs that just anyone can fix. They are issues that are locked behind management. One's that are 4 years old for example, they are probably some bug locked behind management. That's why they get so old. From the comments it is not clear that a pull request wouldn't be accepted to fix the issue. Personally I think phobos should not exception for long file names.

Walters concern is that the path will change unexpected for the user. Where does that matter for something like rmDir ? The user passes a long path, and rmDir swallows it, never to be seen again by the user. What does it matter if the path gets corrected if it is too long?

As for any stored path, they can remain the same, as in DirEntry. The length of the path is what determines if it needs to use the special syntax or not. The user won't see any difference at all. From what I saw C# supports long names after a certain .net version, you might be able to see how they implemented it there. Parts of it are open source iirc.

Anyways there's only so many issues one person can chase to hell for someone as stubborn as ./.

On Sunday, 16 September 2018 at 02:58:30 UTC, tide wrote:
> There are a lot of issues that aren't simple bugs that just anyone can fix. They are issues that are locked behind management. One's that are 4 years old for example, they are probably some bug locked behind management. That's why they get so old. From the comments it is not clear that a pull request wouldn't be accepted to fix the issue. Personally I think phobos should not exception for long file names.

Nothing is "locked behind management". If you feel that some issue important to you is stalled, you can create a forum thread, or email Walter/Andrei to ask for a resolution.

> Walters concern is that the path will change unexpected for the user. Where does that matter for something like rmDir ? The user passes a long path, and rmDir swallows it, never to be seen again by the user. What does it matter if the path gets corrected if it is too long?

It's more than that.

The path needs to be normalized, which means that \.\ and \..\ fragments need to be removed away first. Depending on your interpretation of symlinks/junctions/etc., "foo/bar/../" might mean something else than "foo/" if "bar" is a reparse point.

The path also needs to be absolute, so it has to be expanded to a full path before it can be prefixed with the UNC prefix. Given how the current directory is state tied to the process (not thread), you get bonus race condition issues. There's also issues like the current directory object being renamed/moved; then a relative path will no longer correspond to what the program thinks the absolute paths is.

All things considered, this goes well into the territory of "not D's problem". My personal recommendation: if you care about long path names, use an operating system which implements them right.