On Saturday, 15 September 2018 at 13:54:45 UTC, tide wrote:
> I feel people need to stop saying this. It feels like people are just being told to say this if there is a bug. There is a larger issue, Bugzilla doesn't and isn't working. Someone will probably throw up some stats about how many bugs are filed and how many are resolved. Those exist because someone working on Dlang comes across a bug that affects them, creates a patch for it first, then goes and creates a bugzilla entry and marks it resolved. Issues are rarely resolved by anyone other than the person that created the bug report to begin with. Or issues created by a team member is resolved by another team member.

- A reproducible test case removes any room for miscommunication, ensures that a fix will fix the problem the submitter is having, and saves time for the developer working on fixing the bug.

- Not filing a bug will essentially guarantee that it's not fixed.

- Sometimes, people do look at random bugs and fix them. Regressions especially are tracked closely.

- Having an issue provides a central place to discuss the bug and link to it.

I have some experience working with and curating D's Bugzilla (see e.g. https://github.com/CyberShadow/DBugTests), so I think the above are authoritatively true.

On Saturday, 15 September 2018 at 13:23:34 UTC, Rubn wrote:
> On Saturday, 15 September 2018 at 12:59:25 UTC, Josphe Brigmo wrote:
>> This is the typical mindset with D. There are all these "minor" problems that people(the D community pretends are all that big a deal but when you couple all these problems together it results in a very unpleasant programming experience(out of all the languages I've programmed in D is about the worse in this regard).
>
> You keep saying you regret using D, well let's go to C++ then. How are you going to solve this problem with C++?
>
> It's a problem that can be worked around, if you are using the latest version of Windows it can be fixed by simply setting a registry entry. Then **all** your applications on your system will work with long file names.

Actually, I'd use C#, as it is a well thought out language that is consistent in nature and runtime.

But, the damn problem, which you seem to not understand, is that once one chooses D to do something in and puts in time, then only do they find out how poor it works and then the choice is made to continue using it hoping for the best or start over from scratch.

The problem is that I'm an optimist at heart but every time that is tested with D. It works for something amazingly well, for other things amazingly poor.

But with peoples attitudes like yours it seems this will always be the case for D. It would be nice if people did what was required to make D as great as it could be rather than having the attitude "If you don't like it leave".

Usually when someone comes in to bitch about a problem with D(which is usually legit), there is a wall of "it's not our problem" attitudes.

On Saturday, 15 September 2018 at 13:37:29 UTC, Vladimir Panteleev wrote:
> On Saturday, 15 September 2018 at 12:59:25 UTC, Josphe Brigmo wrote:
>> The libraries are already copying the user's string and adding the 0 termination prior to calling the windows api, so it seems to me to be a reasonable place to make other modifications if they are needed to accomplish the intended operation.
>
> That only works for absolute paths.

And that is all I'm using...

>> Yet it is somehow my fault for not reading the source of phobos to make sure it is using unicode api? Which it is and it's still failing!
>
> Right. The problem is on the OS side.
>
>> again, this is why I generally end up regretting using D.
>
> 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).

You know, there is so many problems with D but you do not care to see them.

Take the way the library is designed. strip? trim is the standard. Then you get things like exists. Instead of fileExists or dirExists. Not all that bad though, but what about slurp and others that are just odd and for people that are not professional D programmers requires one to look up the name of what they are trying to do.

I don't know how many times I have typed in a name of a function that is "standard" only to find out that is not what D used but some odd ball name... or worse, it differs by a character or two.

You can pretend all you want about how great D is, but D is not great, it is just great at some things. That goes for all languages, but at least some languages let you enjoy the experience.

With D, it seems the hard core users seem not to care about the experience or think it's great because they don't know how much better it can be.


>
>> This is the typical mindset with D. There are all these "minor" problems that people(the D community pretends are all that big a deal but when you couple all these problems together it results in a very unpleasant programming experience(out of all the languages I've programmed in D is about the worse in this regard).
>
> Please drop this tone, it will make you no allies.

I'm not here to make allies. Truth is not subjective and it doesn't depend on how many friends you have that believe in the same BS.

and the biggest problem is that I don't see any motivation in the D community to make things better. Anyone with the abilities to make it better in the right way simply does not care about having a proper plan to get D to where it needs to be. Hence, it gives me no hope that D will ever reach a status of usability that it should have. What's the point of all the fancy meta language capabilities if ultimately they are ineffective due to the ecosystem of D sucking?

What I have learned from D:

1. It has an amazing meta programming language. Of course most functional languages have even better but D allows systems programming and is also fast.

2. I am the most unproductive in D. While I can write meta code that does things 10x easier, it takes me 10x longer to code, debug, and revision... not because the meta programming is difficult but because the errors are pathetic(most of the time a huge amount of noise is created in the errors making me sift through a bunch of junk just to figure out what is going on) and usually not even related to the real problem. Just miss a semicolon and your program can explode with errors having nothing to do with that.

3. No one seems to care about fixing these deficits of D but only on making it more "attractive" on paper.

4. One can't expect a program to work properly, EVER! In other languages, when I write something, debug it, and test it, I am sure that it will generally work fine after and not have to worry in any way shape or form... and when it does break, it is usually obvious and easy to fix.

Be it some flaw in the language(such as what I have experienced with the paths and other things) or updating compilers or library features and it breaking something, etc.

All these problems, which are well known, and I'd bet you that D has the most forum posts of problems dealing with these types of things than any other language, are rarely addressed.

I mean, look at bugzillia... how many bugs have 5+ years and no one has done a damn thing? And these bugs being critical in many cases.

Again, this is the whole attitude "It's not our problem"...

Of course, once one of the hardcore D guys run in to the bug after actually doing some real programing of real applications, they might have to fix it and then it will get fixed.

It's not that D is terrible, it's that it's not great and it has the potential to be great but either no one realizes it or gives a shit. All you guys put in your life energy in to making D what it is but won't put in the energy to strengthen the weaknesses.

When you get tired of D, say like Dicebot, you'll leave and some other *idiot* will come along and have the same attitude and the process repeats. This is why it's called "kicking the can down the road" and why I used the term idiot(not meaning a lack of intelligence but a lack of foresight).


And this is why after 10+ years of D not really much has changed(even though a lot has changed). After another 20 years, same thing. A lot will change, but the same all problems(the weaknesses) will exist.

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.

On Saturday, 15 September 2018 at 18:33:36 UTC, Josphe Brigmo wrote:
> and the biggest problem is that I don't see any motivation in the D community to make things better.

This is an open source project. If you're hoping that you can report that something doesn't work the way you want it to and a manager will assign a couple developers to fix it to do what you want, D is not for you.

That's reality even if you (and the many other new users posting these things) don't like reality. If you've got a million dollars to donate, that can be changed.

On Saturday, September 15, 2018 6:54:50 AM MDT Josphe Brigmo via Digitalmars-d wrote:
> On Saturday, 15 September 2018 at 12:38:41 UTC, Adam D. Ruppe
>
> wrote:
> > On Saturday, 15 September 2018 at 10:57:56 UTC, Josphe Brigmo
> >
> > wrote:
> >> Phobos *NEEDS* to be modified to work with these newer OS's.
> >
> > You need to look at the source code before posting. The code for remove is literally
> >
> > DeleteFileW(name);
> >
> > it is a one-line wrapper, and obviously uses the unicode version.
> >
> > https://github.com/dlang/phobos/blob/master/std/file.d#L1047
>
> It doesn't matter, the fact is that something in phobos is broke. Do you really expect me to do all the work? The fact that using executeShell or "\\?\" solves 90% of the problems(maybe all of them) proves that phobos is not up to par.

Using std.file should be on par with using the Windows API from C or C++. It doesn't try to fix the arguably broken behavior of the Windows API with regards to long paths but requires that the programmer deal with them just like they would in C/C++. The main differences are that the std.file functions in question use D strings rather than C strings, and they translate them to the UTF-16 C strings for you rather than requiring you to do it. But they don't do anything like add "\\?\" for you any more than the Windows API itself does that.

If you consider that to be broken, then sorry. For better or worse, it was decided that it was better to let the programmer deal with those intricacies rather than trying to tweak the input to make it work based on the idea that that could have undesirable consequences in some circumstances. On some level, that does suck, but the Windows API does not make it easy to make this work like it would on a *nix system without introducing subtle bugs.

If you find that the std.file functions don't work whereas using the same input to the Windows API functions in C/C++ would have, then there's a bug in the D code, and it needs to be fixed, but if it acts the same as the C/C++ code, then it's working as intended.

- Jonathan M Davis

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.

On Saturday, 15 September 2018 at 23:06:57 UTC, Jonathan M Davis wrote:
> On Saturday, September 15, 2018 6:54:50 AM MDT Josphe Brigmo via Digitalmars-d wrote:
>> On Saturday, 15 September 2018 at 12:38:41 UTC, Adam D. Ruppe
>>
>> wrote:
>> > On Saturday, 15 September 2018 at 10:57:56 UTC, Josphe Brigmo
>> >
>> > wrote:
>> >> Phobos *NEEDS* to be modified to work with these newer OS's.
>> >
>> > You need to look at the source code before posting. The code for remove is literally
>> >
>> > DeleteFileW(name);
>> >
>> > it is a one-line wrapper, and obviously uses the unicode version.
>> >
>> > https://github.com/dlang/phobos/blob/master/std/file.d#L1047
>>
>> It doesn't matter, the fact is that something in phobos is broke. Do you really expect me to do all the work? The fact that using executeShell or "\\?\" solves 90% of the problems(maybe all of them) proves that phobos is not up to par.
>
> Using std.file should be on par with using the Windows API from C or C++. It doesn't try to fix the arguably broken behavior of the Windows API with regards to long paths but requires that the programmer deal with them just like they would in C/C++. The main differences are that the std.file functions in question use D strings rather than C strings, and they translate them to the UTF-16 C strings for you rather than requiring you to do it. But they don't do anything like add "\\?\" for you any more than the Windows API itself does that.
>
> If you consider that to be broken, then sorry. For better or worse, it was decided that it was better to let the programmer deal with those intricacies rather than trying to tweak the input to make it work based on the idea that that could have undesirable consequences in some circumstances. On some level, that does suck, but the Windows API does not make it easy to make this work like it would on a *nix system without introducing subtle bugs.

Do you not realize how moronic that is though?  You are expecting each user to know the correct behavior and to compensate for it. With that approach all you are doing is creating a whole mess of problems.

See, there is only one phobos but many users of phobos. You are expecting every single user to deal with it instead of dealing with it in one place.

Your reason is because "It's a problem with windows".

Both are "We'll just kick the can down the road cause the other guy kicked it to us".

Now, this is great if you want repeat customers and don't care about their sanity but terrible to make progress.

> If you find that the std.file functions don't work whereas using the same input to the Windows API functions in C/C++ would have, then there's a bug in the D code, and it needs to be fixed, but if it acts the same as the C/C++ code, then it's working as intended.
>

And that is precisely the problem. For some reason you don't get that because it is broke in windows, and you following windows, you are just perpetuating the "brokeness".  This is why D sucks the way it does, because of these types of mentalities of "It's not our problem".

You basically expect the customers, before eating to wash the dishes, cook the meal, set the table, etc. All you do is provide the food, and not all that great food... and when they are done you expect them to wash the dishes against, clean up their mess, and pay the bill.

I'm sure you'll never realize how wrong your mentality is, but at least you could do everyone a favor and think about what you are actually saying. Your logic might have a valid reason, but it is not producing the results that make the world a better place.

D won't ever get any traction with the wrong mentalities and I don't even know how it has made it this far.

Trust me, if you expect the user to know everything and also solve all the problems over and over and over and over, you will have very few users.

But, keep on doing what your doing, it's worked so well, we will see how far it gets D.

If D is as perfect as you think it is, why isn't everyone jumping on board? I know, you have answers for that one too!

On Saturday, 15 September 2018 at 18:21:43 UTC, Josphe Brigmo 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).

I had a quick look at the implementations of some of the languages you mentioned. They use the C API or use the Windows API without the UNC prefix.

You are lying.