Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 01:03:27 UTC, Dave Jones wrote: On Saturday, 15 September 2018 at 15:25:55 UTC, Joakim wrote: On Friday, 14 September 2018 at 09:23:24 UTC, Dave Jones wrote: On Thursday, 13 September 2018 at 22:56:31 UTC, Joakim wrote: On Thursday, 13 September 2018 at 22:41:08 UTC, Nick And people don't use PCs for such things? ;) Sure, but they use them for a bunch of other stuff too. My point was that mobile growth has been in the "such things" but barely made a dent in the other stuff. So when you see 30% pc screen time and 70% mobile, its not a 70% drop in actual time spent in front of a PC. It's more a massive growth in time on mobile doing mostly banal pointless crap. Sure, mobile has grown the market for digital entertainment and communication much more than taking away the time spent doing work on a PC, at least so far. I know a lot of people who did, which explains the 28% drop in PC sales since they peaked in 2011, the year after the iPad came out. Many of those people who used to buy PCs have switched to tablets and other mobile devices. Yet PC sales are up this year, mobile is down, and tablet sales have fallen for 3 years in a row. Eh, these are all mostly mature markets now, so slight quarterly dips or gains don't matter much anymore. What does it matter that PC sales were up 2-3% last quarter when 7 times as many smartphones and mobile devices were sold in that same quarter? More like when computers first started replacing typewriters, I'm sure many laughed at that possibility back then too. :) Im not laughing at the idea of mobile eating into desktop PC share. What Im saying is that it hasnt done so as much as you think. I say that almost 30% drop in PC sales over the last 7 years is mostly due to the rise of mobile. Not sure what you mean by "it hasnt done so as much as you think." You may argue that most using PCs aren't using them for entertainment, but this drop suggests that at least 30% of them were and have now moved to mobile. And just because there's been a trend for 5 or 6 years doesnt mean it will continue so inevitably. Sure, but these trends almost never reverse. ;) I actually think most people would prefer a separate desktop and mobile device, whether that desktop is just the size of pack of cigarettes, or a big box with 5 fans in it. Why? Given how price-sensitive the vast majority of the computing-buying public is- that excludes the Apple sheeple who actually seem to get a hard-on from rising iPhone prices, all the better for them to show how much money they've lucked into by brandishing their "gold" iPhone ;) - I don't see most willing to spend twice on two devices, that could be replaced by just one. Until recently, they didn't have a choice, as you couldn't use your mobile device as a desktop, but the just-released devices I linked in the first post in this thread are starting to change that. You've probably heard of the possibly apocryphal story of how Blackberry and Nokia engineers disassembled the first iPhone and dismissed it because it only got a day of battery life, while their devices lasted much longer. They thought the mainstream market would care about such battery life as much as their early adopters, but they were wrong. But here's a better story for this occasion, Ken Olsen, the head of DEC who built the minicomputers on which Walter got his start, is supposed to have disassembled the first IBM PC and this was his reaction: "Ken Olsen bought one of the first IBM PCs and disassembled it on a table in Olsen’s office. 'He was amazed at the crappy power supply,' Avram said, 'that it was so puny. Olsen thought that if IBM used such poor engineering then Digital didn’t have anything to worry about.' Clearly Olsen was wrong." https://www.cringely.com/2011/02/09/ken-olsen-and-post-industrial-computing/ You're making the same mistake as him. It _doesn't matter_ what people first use the new tool for, what matters is what it _can_ be used for, particularly over time. That time is now, as top and mid-range smartphone chips now rival mid-to low-end PC CPUs, which is the majority of the market. The x86/x64 PC's days are numbered, just as it once killed off the minicomputer decades ago. Yes you can bring up examples of people who made mistakes predicting the future but that works both ways. You're just as guilty of seeing a two points and drawing a straight line though them. Except none of these examples or my own prediction are based on simple extrapolation between data points. Rather, we're analyzing the underlying technical details and capabilities and coming to different conclusions about whether the status quo is likely to remain. So I don't think any of us are "guilty" of your charge.
Re: array to string functional?
Can you post a complete, runnable example that illustrates your problem? Strange as it is, now it works here too... - I don't know, what went wrong yesterday. Thanks anyway. :-)
Re: int/longRe: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Sunday, 16 September 2018 at 01:47:33 UTC, Mike Franklin wrote: On Friday, 14 September 2018 at 23:08:34 UTC, Nicholas Wilson The only thing I think is missing is a flag to accelerate the process s.t. the examples f(E.a); f(E.b); g(a - b); can be made to call their int/long overloads straight away. But otherwise, er, no. A resounding yes with a small request to make the transition faster! I'm not too keen on adding a compiler flag, because then I have to worry about deprecating the compiler flag. I don't know if the bugs that this DIP fixes are serious enough to justify it. I'd be happy to add it if others are willing to voice their support for it, demonstrating sufficient demand. Or, I suppose I could add it as an option for Walter and Andrei to approve or reject on judgement day. Mike Its more about dealing with the deprecation warning. With the current specification I can tell the compiler I want the old behaviour with a cast. I should be able to tell the compiler that "Yes, I wan't this new behaviour. Please don't warn me about it.", once I have verified that my code is correct under the new behaviour. Without it, I get a (possibly quite a lot of) deprecation warnings and I have to insert a cast to the corresponding type, e.g. f(cast(int)E.a)/g(cast(long)(a - b)), to verify the behaviour under the new system and silence the deprecation warning (absolutely necessary if using `-de`). Then I have to delete them after stage 2, but what if I want to support older compilers? Well then I have to wait until they are sufficiently old enough.
Re: phobo's std.file is completely broke!
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.
[Issue 19194] version for `-mscrtlib` specification
https://issues.dlang.org/show_bug.cgi?id=19194 --- Comment #4 from Manu --- A different way: https://github.com/dlang/dmd/pull/8701 --
[Issue 19249] New: Trying to build DMD for windows with LDC fails
https://issues.dlang.org/show_bug.cgi?id=19249 Issue ID: 19249 Summary: Trying to build DMD for windows with LDC fails Product: D Version: D2 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: turkey...@gmail.com Trying to build DMD for windows using LDC: Build 32bit: 1>..\dmd\root\longdouble.d(164): error : static assert: "usupported type" 1>..\dmd\constfold.d(1123):instantiated from here: `opCast!(__c_long)` Build 64bit: 1>..\dmd\backend\cod4.d(291): Deprecation: integral promotion not done for `~modregrm(0u, 7u, 0u)`, use '-transition=intpromote' switch or `~cast(int)(modregrm(0u, 7u, 0u))` 1>..\dmd\backend\cod4.d(48): error : Global variable type does not match previous declaration with same mangled name: `?dblreg@@3PAIB` 1>..\dmd\backend\cod4.d(48):Previous IR type: [4 x i32] 1>..\dmd\backend\cod4.d(48):New IR type: [4 x i32] --
Re: phobo's std.file is completely broke!
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 ./.
[Issue 10560] Enum typed as int with value equal to 0 or 1 prefer bool over int overload
https://issues.dlang.org/show_bug.cgi?id=10560 Mike Franklin changed: What|Removed |Added Keywords||pull CC||slavo5...@yahoo.com --- Comment #3 from Mike Franklin --- A DIP has been submitted to address this issue: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1015.md A PR implementing the DIP can be found at https://github.com/dlang/dmd/pull/7310 --
[Issue 9999] Integer literal 0 and 1 should prefer integer type in overload resolution
https://issues.dlang.org/show_bug.cgi?id= --- Comment #16 from Mike Franklin --- A DIP has been submitted to address this issue: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1015.md A PR implementing the DIP can be found at https://github.com/dlang/dmd/pull/7310 --
Re: A Brief Intro to the SAoC Projects
On Saturday, 15 September 2018 at 07:47:46 UTC, Mike Parker wrote: I've posted to the blog a brief introduction to the projects that were selected for the Symmetry Autumn of Code. As the event goes on, I hope to provide more details about the projects and the individuals working on them. The blog: https://dlang.org/blog/2018/09/15/symmetry-autumn-of-code-is-underway/ Reddit: https://www.reddit.com/r/d_language/comments/9fzrqd/symmetry_autumn_of_code_is_underway/? Proggit post, I think they'll be interested in knowing what was chosen too: https://www.reddit.com/r/programming/comments/9g2ifo/symmetry_autumn_of_code_is_underway_the_d_blog/
Re: int/longRe: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Friday, 14 September 2018 at 23:08:34 UTC, Nicholas Wilson wrote: On Friday, 14 September 2018 at 13:41:40 UTC, Mike Parker wrote: DIP 1015, "Deprecation and removal of implicit conversion from integer and character literals to bool", is now ready for Final Review. This is a last chance for community feedback before the DIP is handed off to Walter and Andrei for the Formal Assessment. Please read the procedures document for details on what is expected in this review stage: https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review The current revision of the DIP for this review is located here: https://github.com/dlang/DIPs/blob/299f81c2352fae4c7fa097de71308d773dcd9d01/DIPs/DIP1015.md In it you'll find a link to and summary of the previous review round. This round of review will continue until 11:59 pm ET on September 28 unless I call it off before then. Thanks in advance for your participation. Small typo under Breaking Changes and Deprecations "4. After the time period specified in step 4 has elapsed, stage 2 can be merged." should be "4. After the time period specified in step _3_ has elapsed, stage 2 can be merged." Thanks! https://github.com/dlang/DIPs/pull/134/files The only thing I think is missing is a flag to accelerate the process s.t. the examples f(E.a); f(E.b); g(a - b); can be made to call their int/long overloads straight away. But otherwise, er, no. A resounding yes with a small request to make the transition faster! I'm not too keen on adding a compiler flag, because then I have to worry about deprecating the compiler flag. I don't know if the bugs that this DIP fixes are serious enough to justify it. I'd be happy to add it if others are willing to voice their support for it, demonstrating sufficient demand. Or, I suppose I could add it as an option for Walter and Andrei to approve or reject on judgement day. Mike
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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
Re: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Saturday, 15 September 2018 at 20:07:06 UTC, Steven
Schveighoffer wrote:
Looks pretty good to me. The only question I have is on this
part:
enum YesNo : bool { no, yes } // Existing implementation: OK
// After stage 1: Deprecation
warning
// After stage 2: Error
// Remedy: `enum YesNo : bool {
no = false, yes = true }`
Why is this necessary? I can't see how there are integer
literals being used here, or how implicitly going from `false`
to `true` in the 2 items being enumerated is going to be
confusing.
You're right, I just tested the implementation, and this is not
necessary. I'll remove it. Thanks!
Mike
Re: phobo's std.file is completely broke!
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.
Re: Mobile is the new PC and AArch64 is the new x64
On Saturday, 15 September 2018 at 15:25:55 UTC, Joakim wrote: On Friday, 14 September 2018 at 09:23:24 UTC, Dave Jones wrote: On Thursday, 13 September 2018 at 22:56:31 UTC, Joakim wrote: On Thursday, 13 September 2018 at 22:41:08 UTC, Nick And people don't use PCs for such things? ;) Sure, but they use them for a bunch of other stuff too. My point was that mobile growth has been in the "such things" but barely made a dent in the other stuff. So when you see 30% pc screen time and 70% mobile, its not a 70% drop in actual time spent in front of a PC. It's more a massive growth in time on mobile doing mostly banal pointless crap. I know a lot of people who did, which explains the 28% drop in PC sales since they peaked in 2011, the year after the iPad came out. Many of those people who used to buy PCs have switched to tablets and other mobile devices. Yet PC sales are up this year, mobile is down, and tablet sales have fallen for 3 years in a row. More like when computers first started replacing typewriters, I'm sure many laughed at that possibility back then too. :) Im not laughing at the idea of mobile eating into desktop PC share. What Im saying is that it hasnt done so as much as you think. And just because there's been a trend for 5 or 6 years doesnt mean it will continue so inevitably. I actually think most people would prefer a separate desktop and mobile device, whether that desktop is just the size of pack of cigarettes, or a big box with 5 fans in it. You've probably heard of the possibly apocryphal story of how Blackberry and Nokia engineers disassembled the first iPhone and dismissed it because it only got a day of battery life, while their devices lasted much longer. They thought the mainstream market would care about such battery life as much as their early adopters, but they were wrong. But here's a better story for this occasion, Ken Olsen, the head of DEC who built the minicomputers on which Walter got his start, is supposed to have disassembled the first IBM PC and this was his reaction: "Ken Olsen bought one of the first IBM PCs and disassembled it on a table in Olsen’s office. 'He was amazed at the crappy power supply,' Avram said, 'that it was so puny. Olsen thought that if IBM used such poor engineering then Digital didn’t have anything to worry about.' Clearly Olsen was wrong." https://www.cringely.com/2011/02/09/ken-olsen-and-post-industrial-computing/ You're making the same mistake as him. It _doesn't matter_ what people first use the new tool for, what matters is what it _can_ be used for, particularly over time. That time is now, as top and mid-range smartphone chips now rival mid-to low-end PC CPUs, which is the majority of the market. The x86/x64 PC's days are numbered, just as it once killed off the minicomputer decades ago. Yes you can bring up examples of people who made mistakes predicting the future but that works both ways. You're just as guilty of seeing a two points and drawing a straight line though them.
Re: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On Saturday, September 15, 2018 2:07:06 PM MDT Steven Schveighoffer via
Digitalmars-d wrote:
> On 9/14/18 6:41 AM, Mike Parker wrote:
> > DIP 1015, "Deprecation and removal of implicit conversion from integer
> > and character literals to bool", is now ready for Final Review. This is
> > a last chance for community feedback before the DIP is handed off to
> > Walter and Andrei for the Formal Assessment. Please read the procedures
> > document for details on what is expected in this review stage:
> >
> > https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
> >
> > The current revision of the DIP for this review is located here:
> >
> > https://github.com/dlang/DIPs/blob/299f81c2352fae4c7fa097de71308d773dcd9
> > d01/DIPs/DIP1015.md
> >
> >
> > In it you'll find a link to and summary of the previous review round.
> > This round of review will continue until 11:59 pm ET on September 28
> > unless I call it off before then.
> >
> > Thanks in advance for your participation.
>
> Looks pretty good to me. The only question I have is on this part:
>
> enum YesNo : bool { no, yes } // Existing implementation: OK
>// After stage 1: Deprecation warning
>// After stage 2: Error
>// Remedy: `enum YesNo : bool { no =
> false, yes = true }`
>
> Why is this necessary? I can't see how there are integer literals being
> used here, or how implicitly going from `false` to `true` in the 2 items
> being enumerated is going to be confusing.
It would be a serious problem for enums of type bool to change like, and
there should be no need for it.
- Jonathan M Davis
Re: phobo's std.file is completely broke!
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
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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.
Re: x64 Privileged instruction
On Saturday, 15 September 2018 at 18:05:58 UTC, Josphe Brigmo wrote: I have always gotten these types of errors on x64 and, it may be my machine, it has happened with many dmd versions, visual D and visual studio... Oh, you mean the message that appears in Visual Studio, not stderr. Exception handling in Win64 is very different than on Win32, so that's probably it. Visual Studio probably doesn't know how to extract the error message from a D exception in Win64. If you run the D program without a debugger attached, you should see the exception message on stderr (or a MessageBox, if you're building a GUI executable).
Re: phobo's std.file is completely broke!
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
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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!
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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
Getting started with separate compilation
My project [1] has enough language coverage to expose two issues that break compilation. 1. Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen(); https://issues.dlang.org/show_bug.cgi?id=18026 2. -allinst gives undefined reference linker errors; https://issues.dlang.org/show_bug.cgi?id=19123 It's also of a size large enough that the memory needed to compile makes CircleCI kill the process. Locally I generally need to close my browsers to be able to build. I'd throw money at all these three problems if I knew it would help. #dbugfix :c Everything speaks for abandoning dub and moving ahead with something with which I can separately compile parts of the program for less memory, and use -allinst on key files to avoid issue 1 without triggering issue 2. --build-mode=singleFile exists, but I don't see anything in dub that would let me apply -allinst on a per-file basis. Are there any guides on where to get started with this? Any protips? Can dub still be used to some extent? [1]: https://github.com/zorael/kameloso
Re: D is dead
On 8/22/2018 10:37 PM, Shachar Shemesh wrote: Let's start with this one: https://issues.dlang.org/show_bug.cgi?id=14246#c6 https://github.com/dlang/dmd/pull/8697
Re: array to string functional?
On Saturday, 15 September 2018 at 20:04:36 UTC, berni wrote:
Anotherone I'm not getting to work: From some output with
newlines I want to discard all lines, that start with a # and
select part of the other lines with a regex. (I know the regex
r".*" is quite useless, but it will be replaced by something
more usefull.)
I tried the following, but non worked:
output.split("\n").filter!(a=>a.length>0 &&
a[0]!='#').matchFirst(r".*");
output.split("\n").filter!(a=>a.length>0 &&
a[0]!='#').array.matchFirst(r".*");
output.split("\n").filter!(a=>a.length>0 &&
a[0]!='#').array.map!(matchFirst(r".*"));
output.split("\n").filter!(a=>a.length>0 &&
a[0]!='#').array.map!(a=>matchFirst(a,r".*"));
Any ideas?
Your last example works for me: https://run.dlang.io/is/F5n3mk
Can you post a complete, runnable example that illustrates your
problem?
Re: More fun with autodecoding
On Saturday, September 15, 2018 9:31:00 AM MDT Steven Schveighoffer via Digitalmars-d wrote: > On 9/13/18 3:53 PM, H. S. Teoh wrote: > > On Thu, Sep 13, 2018 at 06:32:54PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: > >> On 09/11/2018 09:06 AM, Steven Schveighoffer wrote: > >>> Then I found the true culprit was isForwardRange!R. This led me to > >>> requestion my sanity, and finally realized I forgot the empty > >>> function. > >> > >> This is one reason template-based interfaces like ranges should be > >> required to declare themselves as deliberately implementing said > >> interface. Sure, we can tell people they should always `static > >> assert(isForwardRage!MyType)`, but that's coding by convention and > >> clearly isn't always going to happen. > > No, please don't. I've used C# and Swift, and this sucks compared to > duck typing. > > > Yeah, I find myself writing `static assert(isInputRange!MyType)` all the > > time these days, because you just never can be too sure you didn't screw > > up and cause things to mysteriously fail, even though they shouldn't. > > > > Although I used to be a supporter of free-form sig constraints (and > > still am to some extent) and a hater of Concepts like in C++, more and > > more I'm beginning to realize the wisdom of Concepts rather than > > free-for-all ducktyping. It's one of those things that work well in > > small programs and fast, one-shot projects, but don't generalize so well > > as you scale up to larger and larger projects. > > The problem I had was that it wasn't clear to me which constraint was > failing. My bias brought me to "it must be autodecoding again!". But > objectively, I should have examined all the constraints to see what was > wrong. All C++ concepts seem to do (haven't used them) is help identify > easier which requirements are failing. > > We can fix all these problems by simply identifying the constraint > clauses that fail. By color coding the error message identifying which > ones are true and which are false, we can pinpoint the error without > changing the language. > > Once you fix the issue, it doesn't error any more, so the idea of duck > typing and constraints is sound, it's just difficult to diagnose. The other two things that come to mind are that 1. Design by Introspection is pretty much the opposite of Concepts, and while I'm not convinced that DbI is a great idea in general, there clearly are cases where it makes a lot of sense (e.g. allocators), and it's something that Andrei wants to push (whereas unless something has changed, he's very much against Concepts). Adding any sort of Concepts feature to D would be very much at odds with DbI. And honestly, in general, I don't think that it's at all necessary. As you point out, it's really the error reporting that's the problem. Aside from that, template constraints tend to work quite well. 2. Improving the error reporting for constraints improves templates in general and not just those that use traits like isInputRange. While we do create traits for the really common stuff, there's plenty of code that is going to do stuff like is(typeof(...)), because it's a one-off thing, and it would be overkill to create a trait for it. So, improving the error reporting would ultimately be very useful in general, whereas trying to do something with Concepts would only help with part of the problem. And of course, there's always going with Atila's approach of providing a separate template that goes with the trait and tells you which piece fails for a particular template argument (though that obviously doesn't scale). Overall though, I don't think that there's really any disagreement that it would be very desirable to get the compiler to provide better information about which parts of a template constraint are true and which are false. The problem is really that someone needs to come up with a scheme to do so that will work reasonably well and then implement it, and no on has done that yet. - Jonathan M Davis
Re: Pass 'this' as reference
On Saturday, September 15, 2018 11:44:05 AM MDT Jan via Digitalmars-d-learn
wrote:
> On Thursday, 13 September 2018 at 11:08:30 UTC, Jonathan M Davis
>
> wrote:
> > [...]
>
> Thanks for clarifying Jonathan :)
> But aren't the variables considered rvalues then?
No. variables are _always_ lvalues. An lvalue is an object which is
addressable and which can therefore be assigned a value (ignoring issues of
constness). The name comes from the fact that lvalues are allowed on the
left-hand side of an assignment operation, whereas rvalues are only allowed
on the right. e.g.
int i;
int* p;
are both lvalues. They have addresses and can be assigned to.
i = 42;
p =
auto p2 =
On the other hand, the return value of
int foo(string s);
is an rvalue. How it's actually stored is compiler-defined; you can't take
its address, and you can't assign to it.
foo("bar") = 42; // illegal
auto p = ("bar"); // illegal
On the other hand,
ref int foo(string s);
returns by ref, so it's returning an lvalue. Its address can be taken, and
it can be assigned a value.
foo("bar") = 42; // legal
auto p = ("bar"); // legal
Because a pointer or reference points to a specific address, even if the
pointer itself is an rvalue, what it points to is almost always an lvalue,
(the main case where it isn't an lvalue would be something like a function
pointer, since you can take a function's address, but you can't assign to
it). So, something like
int* foo(string s);
*foo("bar") = 42;
compiles. However, ultimately, you can't know whether a particular value is
an lvalue or rvalue without context. A variable is always an lvalue, whereas
a return value usually isn't - but it can be if it's returned by ref. And a
variable and return value could both be the same type - int, int*, string,
etc. So, the type itself doesn't tell you whether something is an lvalue or
rvalue. It's how it's stored that tells you.
Ultimately though, if you want to know whether something is an lvalue or
rvalue, consider whether it's something that can go on the left-hand side of
an assignment operation (ignoring its constness), or whether it can only go
on the right-hand side.
https://msdn.microsoft.com/en-us/library/f90831hc.aspx
https://stackoverflow.com/questions/17357888/exact-difference-between-rvalue-and-lvalue
https://www.quora.com/What-is-lvalue-and-rvalue-in-C
- Jonathan M Davis
Re: DIP 1015--removal of integer & character literal conversion to bool--Final Review
On 9/14/18 6:41 AM, Mike Parker wrote:
DIP 1015, "Deprecation and removal of implicit conversion from integer
and character literals to bool", is now ready for Final Review. This is
a last chance for community feedback before the DIP is handed off to
Walter and Andrei for the Formal Assessment. Please read the procedures
document for details on what is expected in this review stage:
https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review
The current revision of the DIP for this review is located here:
https://github.com/dlang/DIPs/blob/299f81c2352fae4c7fa097de71308d773dcd9d01/DIPs/DIP1015.md
In it you'll find a link to and summary of the previous review round.
This round of review will continue until 11:59 pm ET on September 28
unless I call it off before then.
Thanks in advance for your participation.
Looks pretty good to me. The only question I have is on this part:
enum YesNo : bool { no, yes } // Existing implementation: OK
// After stage 1: Deprecation warning
// After stage 2: Error
// Remedy: `enum YesNo : bool { no =
false, yes = true }`
Why is this necessary? I can't see how there are integer literals being
used here, or how implicitly going from `false` to `true` in the 2 items
being enumerated is going to be confusing.
-Steve
Re: array to string functional?
Anotherone I'm not getting to work: From some output with
newlines I want to discard all lines, that start with a # and
select part of the other lines with a regex. (I know the regex
r".*" is quite useless, but it will be replaced by something more
usefull.)
I tried the following, but non worked:
output.split("\n").filter!(a=>a.length>0 &&
a[0]!='#').matchFirst(r".*");
output.split("\n").filter!(a=>a.length>0 &&
a[0]!='#').array.matchFirst(r".*");
output.split("\n").filter!(a=>a.length>0 &&
a[0]!='#').array.map!(matchFirst(r".*"));
output.split("\n").filter!(a=>a.length>0 &&
a[0]!='#').array.map!(a=>matchFirst(a,r".*"));
Any ideas?
Re: More fun with autodecoding
On 9/15/18 12:04 PM, Neia Neutuladh wrote: On Saturday, 15 September 2018 at 15:31:00 UTC, Steven Schveighoffer wrote: The problem I had was that it wasn't clear to me which constraint was failing. My bias brought me to "it must be autodecoding again!". But objectively, I should have examined all the constraints to see what was wrong. All C++ concepts seem to do (haven't used them) is help identify easier which requirements are failing. They also make it so your automated documentation can post a link to something that describes the type in more cases. std.algorithm would still be relatively horked, but a lot of functions could be declared as yielding, for instance, ForwardRange!(ElementType!(TRange)). True, we currently rely on convention there. But this really is simply documentation at a different (admittedly more verified) level. We can fix all these problems by simply identifying the constraint clauses that fail. By color coding the error message identifying which ones are true and which are false, we can pinpoint the error without changing the language. I wish. I had a look at std.algorithm.searching.canFind as the first thing I thought to check. Its constraints are of the form: bool canFind(Range)(Range haystack) if (is(typeof(find!pred(haystack The compiler can helpfully point out that the specific constraint that failed was is(...), which does absolutely no good in trying to track down the problem. is(typeof(...)) constraints might be useless here, but we have started to move away from such things in general (see for instance isInputRange and friends). But there could actually be a solution -- just recursively play out the items at compile time (probably with the verbose switch) to see what underlying cause there is. Other than that, you can then write find(myrange) and see what comes up. In my case even, the problem was hasSlicing, which itself is a complicated template, and wouldn't have helped me diagnose the real problem. A recursive display of what things failed would help, but even if I could trigger a way to diagnose hasSlicing, instead of copying all the constraints locally, it's still a much better situation. I'm really thinking of exploring how this could play out, just toying with the compiler to do this would give me experience in how the thing works. -Steve
Re: Proposal: __not(keyword)
On 9/14/18 11:06 AM, Adam D. Ruppe wrote:
It also affects attrs brought through definitions though:
shared class foo {
int a; // automatically shared cuz of the above line of code
__not(shared) int b; // no longer shared
}
Aside from Jonathan's point, which I agree with, that the cost(bool)
mechanism would be preferable in generic code (think not just negating
existing attributes, but determining how to forward them), the above is
different then just negation.
Making something unshared *inside* something that is shared breaks
transitivity, and IMO the above simply would be the same as not having
any attribute there.
In other words, I would expect:
shared foo f;
static assert(is(typeof(f.b)) == shared(int));
I'm not sure how the current behavior works, but definitely wanted to
clarify that we can't change something like that without a major
language upheaval.
-Steve
Re: dealing with very long paths and names
On Saturday, September 15, 2018 8:45:55 AM MDT Vladimir Panteleev via Digitalmars-d-learn wrote: > On Friday, 14 September 2018 at 21:16:31 UTC, Jonathan M Davis > > wrote: > > Yeah, though if you write cross-platform applications or > > libraries (and ideally, most applications and libraries would > > be platform-agnostic), you can't necessarily avoid all of the > > Windows insanity, even if you yourself use a platform without > > those problems. > > Linux generally allows you to go ahead and use the filesystem as > a database, and this works pretty well in a lot of cases. > Filesystem performance is much better, and so are the limitations > - not just the path length as discussed in this thread, but also > the range of valid characters (anything except / and NUL is > fine). Plus, depending on your choice of filesystem, you get > bonus features like snapshots, incremental backups, and > deduplication. It's a boon for prototyping (or Linux-only > software). Oh, I don't disagree. I think that in general it makes _way_ more sense to use a *nix system for development (or most anything else) even if the software can run on multiple platforms. And actually, the primary reason that I use the OS I do (FreeBSD) is because of the filesystem (it has first class ZFS support unlike Linux). However, I'm a strong believer that in general, software should be cross-platform if it reasonably can be. That's usually the worst when folks use all kinds of Windows-specific stuff when they don't need to, but sometimes, Linux-isms do creep into code unnecessarily. Either way, while I've occasionally found something that Windows did better than *nix, far more often, it's shocking how bad their APIs are. And in this particular case, there really isn't a great solution. Trying to hide the Windows limitations by translating longer paths so that the Windows API is risky business, but leaving it up to the programmer to run into it and then scream in frustration like the OP is isn't great either. And of course, even if they outright fixed the problem in Windows tomorrow, it would probably be over a decade before you could rely on it given how long people use older versions of Windows. - Jonathan M Davis
Re: Mobile is the new PC and AArch64 is the new x64
On Friday, 14 September 2018 at 09:23:24 UTC, Dave Jones wrote: On Thursday, 13 September 2018 at 22:56:31 UTC, Joakim wrote: On Thursday, 13 September 2018 at 22:41:08 UTC, Nick Sabalausky (Abscissa) wrote: On 09/10/2018 11:13 PM, tide wrote: On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: That's why PC sales keep dropping while mobile sales are now 6-7X that per year: This shouldn't be misunderstood as such, which I think you as misunderstanding it. The reason mobile sales are so high is because of planned obsolescence and the walled garden that these devices are built around. I've gone through maybe 3-4 phones in the time that I've had my Desktop, and I use my desktop every single day. I don't need to buy a new one cause it runs perfectly fine, there aren't operating system updates that purposely cause the CPU to run slower to "save battery life" when a new device and OS come out. That's not to say it isn't insignificant but the sales numbers are exacerbated. Right. Basically, "sales stats" should never be misconstrued as "usage stats". The usage stats are similarly overwhelming, two-thirds of digital time is spent on mobile, more for the young: Yeah but 90% of the time people spend on mobile is just dicking about. Sending IMs, facebook, point and click games. And thats a huge part of the usage stats, people can now spend more time online wasting time in more situations than ever before. PCs are generally seen a tool to accomplish tasks, for word processing or a high end gaming thing, audio / video editing, mobile is more entertainment. Not many people are doing what you are by using your mobile as a desktop. I'm not saying that makes mobile worthless, what I'm saying is that your hypothesis is like saying TV has taken over from typewriters. Do you realize most Chromebooks use ARM and have recently recorded more sales/usage that Windows in some cases? I several enterprises are adopting use of tablet for on-the-go tasks and administrative work (especially when combined with the mini-keyboards). Things are really shifting to ARM. Another is some that looks exactly like tablets and either run android or chrome OS. See this slick Pixelbook from Google: https://store.google.com/us/product/google_pixelbook
Re: More fun with autodecoding
On Saturday, 15 September 2018 at 15:31:00 UTC, Steven Schveighoffer wrote: The problem I had was that it wasn't clear to me which constraint was failing. My bias brought me to "it must be autodecoding again!". But objectively, I should have examined all the constraints to see what was wrong. All C++ concepts seem to do (haven't used them) is help identify easier which requirements are failing. They also make it so your automated documentation can post a link to something that describes the type in more cases. std.algorithm would still be relatively horked, but a lot of functions could be declared as yielding, for instance, ForwardRange!(ElementType!(TRange)). We can fix all these problems by simply identifying the constraint clauses that fail. By color coding the error message identifying which ones are true and which are false, we can pinpoint the error without changing the language. I wish. I had a look at std.algorithm.searching.canFind as the first thing I thought to check. Its constraints are of the form: bool canFind(Range)(Range haystack) if (is(typeof(find!pred(haystack The compiler can helpfully point out that the specific constraint that failed was is(...), which does absolutely no good in trying to track down the problem.
Re: [OT] My State is Illegally Preventing Me From Voting In The Upcoming 2018 US Elections
Don't worry, your vote actually does not matter either way, so no reason to get upset. Voting is simply a census count to find out how many people still believe that voting still works. If you have 50M eligible voters and 25 million vote, it means you have about 50% of those that believe the government and politics is working as it should. This is a win for the government. They know when it drops too low that they better go to plan B.
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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.
Re: x64 Privileged instruction
On Saturday, 15 September 2018 at 14:57:20 UTC, Vladimir Panteleev wrote: On Thursday, 13 September 2018 at 05:50:53 UTC, Josphe Brigmo wrote: Privileged instruction Lots of code. I pretty much always get this error. Something must have gone really wrong to get this error. Most likely, the CPU instruction pointer ended up in a memory area without any code in it. Windows exception handling is tricky (see Don/Walter's recent discussion), but basic cases should be well-covered by the compiler/runtime test suite. So, I suspect one of the following happened: - Your program is exhibiting an edge case and uncovering a bug not covered by the test case. If this is the case, please reduce your program to a minimal, self-contained example, and file a bug report. - There is a bug in your program that is causing its memory to be corrupted. Using @safe can help narrow it down (https://dlang.org/spec/memory-safe-d.html). - There is something specific to your machine that causes the problem to occur there, but not on the test runners. This could happen e.g. due to software which alter behavior of other programs (like through DLL injection), or using a specific Windows version. You can eliminate this possibility by running the DMD test suite. When I run the code in x86 the error is from a throw and is a first chance exception and the error message is shown as normal. In x64, no changes to source, it is a privileged instruction error. I have always gotten these types of errors on x64 and, it may be my machine, it has happened with many dmd versions, visual D and visual studio... I doubt it is my machine and it seems to be completely dmdx64's fault. Basically I just program in x86 most of the time and compile for x64 because of things like this.
Re: Pass 'this' as reference
On Thursday, 13 September 2018 at 11:08:30 UTC, Jonathan M Davis wrote: [...] Thanks for clarifying Jonathan :) But aren't the variables considered rvalues then?
Re: array to string functional?
On Saturday, 15 September 2018 at 05:39:48 UTC, berni wrote: Oh, thanks. What I didn't know about was join. Now I wonder how I could have found out about it, without asking here? Even yet I know it's name I cannot find it, nighter in the language documentation nor in the library documentation. Probably the easiest way to find something in the documentation is to use the unofficial mirror at http://dpldocs.info/. Type "join" into the search box there, and you'll get `std.array.join` (the function I used) as the first result.
Re: Proposal: __not(keyword)
On Friday, 14 September 2018 at 18:13:49 UTC, Eugene Wissner wrote: Makes the code unreadable. It is the foo: that causes this, not the __not... For @nogc, pure and so forth there were imho a better proposal with a boolean value: @gc(true), @gc(false), pure(true), pure(false) etc. It is also consistent with the existing UDA syntax. Yes, I still actually prefer that proposal, but it has been around for a long time and still isn't here. I want something, ANYTHING to unset these things. I don't care which proposal or which syntax, I just want it to be possible.
Re: [OT] My State is Illegally Preventing Me From Voting In The Upcoming 2018 US Elections
On 9/9/18 2:34 AM, Nick Sabalausky (Abscissa) wrote: [snip] I personally think you are overreacting. Have you voted before? If so, just go to the place you did before. It's all I ever do. If you haven't, and go to the wrong place, I'm sure they will help you find the right place. In my state (MA), it's usually a school. We have signs up in our town weeks before the election reminding of the upcoming vote, and where it is. I seriously doubt that the ONLY way people can figure out their polling place is via the Internet. Especially if said Internet site is implemented by the government, which invariably will have stupid problems. And if there is some grand conspiracy to prevent people from voting by not letting them know their polling place, it's a pretty poorly designed scheme. Just ask your neighbor where to vote, I'm sure you'll figure it out. I recently tried to pay a traffic ticket online (first I've had in like 15 years), and there was a requirement to put in a code that the officer wrote down. The field was a drop-down and DIDN'T contain the code that the officer wrote. I called them, and they confirmed the code the officer wrote was correct. I tried editing the web page to include the code and submit, and it still failed. I ended up having to mail it in. -Steve
Re: More fun with autodecoding
On 9/13/18 3:53 PM, H. S. Teoh wrote: On Thu, Sep 13, 2018 at 06:32:54PM -0400, Nick Sabalausky (Abscissa) via Digitalmars-d wrote: On 09/11/2018 09:06 AM, Steven Schveighoffer wrote: Then I found the true culprit was isForwardRange!R. This led me to requestion my sanity, and finally realized I forgot the empty function. This is one reason template-based interfaces like ranges should be required to declare themselves as deliberately implementing said interface. Sure, we can tell people they should always `static assert(isForwardRage!MyType)`, but that's coding by convention and clearly isn't always going to happen. No, please don't. I've used C# and Swift, and this sucks compared to duck typing. Yeah, I find myself writing `static assert(isInputRange!MyType)` all the time these days, because you just never can be too sure you didn't screw up and cause things to mysteriously fail, even though they shouldn't. Although I used to be a supporter of free-form sig constraints (and still am to some extent) and a hater of Concepts like in C++, more and more I'm beginning to realize the wisdom of Concepts rather than free-for-all ducktyping. It's one of those things that work well in small programs and fast, one-shot projects, but don't generalize so well as you scale up to larger and larger projects. The problem I had was that it wasn't clear to me which constraint was failing. My bias brought me to "it must be autodecoding again!". But objectively, I should have examined all the constraints to see what was wrong. All C++ concepts seem to do (haven't used them) is help identify easier which requirements are failing. We can fix all these problems by simply identifying the constraint clauses that fail. By color coding the error message identifying which ones are true and which are false, we can pinpoint the error without changing the language. Once you fix the issue, it doesn't error any more, so the idea of duck typing and constraints is sound, it's just difficult to diagnose. -Steve
Re: Mobile is the new PC and AArch64 is the new x64
On Friday, 14 September 2018 at 09:23:24 UTC, Dave Jones wrote: On Thursday, 13 September 2018 at 22:56:31 UTC, Joakim wrote: On Thursday, 13 September 2018 at 22:41:08 UTC, Nick Sabalausky (Abscissa) wrote: On 09/10/2018 11:13 PM, tide wrote: On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: That's why PC sales keep dropping while mobile sales are now 6-7X that per year: This shouldn't be misunderstood as such, which I think you as misunderstanding it. The reason mobile sales are so high is because of planned obsolescence and the walled garden that these devices are built around. I've gone through maybe 3-4 phones in the time that I've had my Desktop, and I use my desktop every single day. I don't need to buy a new one cause it runs perfectly fine, there aren't operating system updates that purposely cause the CPU to run slower to "save battery life" when a new device and OS come out. That's not to say it isn't insignificant but the sales numbers are exacerbated. Right. Basically, "sales stats" should never be misconstrued as "usage stats". The usage stats are similarly overwhelming, two-thirds of digital time is spent on mobile, more for the young: Yeah but 90% of the time people spend on mobile is just dicking about. Sending IMs, facebook, point and click games. And thats a huge part of the usage stats, people can now spend more time online wasting time in more situations than ever before. And people don't use PCs for such things? ;) I know a lot of people who did, which explains the 28% drop in PC sales since they peaked in 2011, the year after the iPad came out. Many of those people who used to buy PCs have switched to tablets and other mobile devices. PCs are generally seen a tool to accomplish tasks, for word processing or a high end gaming thing, audio / video editing, mobile is more entertainment. Not many people are doing what you are by using your mobile as a desktop. I'm not saying that makes mobile worthless, what I'm saying is that your hypothesis is like saying TV has taken over from typewriters. More like when computers first started replacing typewriters, I'm sure many laughed at that possibility back then too. :) You've probably heard of the possibly apocryphal story of how Blackberry and Nokia engineers disassembled the first iPhone and dismissed it because it only got a day of battery life, while their devices lasted much longer. They thought the mainstream market would care about such battery life as much as their early adopters, but they were wrong. But here's a better story for this occasion, Ken Olsen, the head of DEC who built the minicomputers on which Walter got his start, is supposed to have disassembled the first IBM PC and this was his reaction: "Ken Olsen bought one of the first IBM PCs and disassembled it on a table in Olsen’s office. 'He was amazed at the crappy power supply,' Avram said, 'that it was so puny. Olsen thought that if IBM used such poor engineering then Digital didn’t have anything to worry about.' Clearly Olsen was wrong." https://www.cringely.com/2011/02/09/ken-olsen-and-post-industrial-computing/ You're making the same mistake as him. It _doesn't matter_ what people first use the new tool for, what matters is what it _can_ be used for, particularly over time. That time is now, as top and mid-range smartphone chips now rival mid-to low-end PC CPUs, which is the majority of the market. The x86/x64 PC's days are numbered, just as it once killed off the minicomputer decades ago.
Re: x64 Privileged instruction
On Thursday, 13 September 2018 at 05:50:53 UTC, Josphe Brigmo wrote: Privileged instruction Lots of code. I pretty much always get this error. Something must have gone really wrong to get this error. Most likely, the CPU instruction pointer ended up in a memory area without any code in it. Windows exception handling is tricky (see Don/Walter's recent discussion), but basic cases should be well-covered by the compiler/runtime test suite. So, I suspect one of the following happened: - Your program is exhibiting an edge case and uncovering a bug not covered by the test case. If this is the case, please reduce your program to a minimal, self-contained example, and file a bug report. - There is a bug in your program that is causing its memory to be corrupted. Using @safe can help narrow it down (https://dlang.org/spec/memory-safe-d.html). - There is something specific to your machine that causes the problem to occur there, but not on the test runners. This could happen e.g. due to software which alter behavior of other programs (like through DLL injection), or using a specific Windows version. You can eliminate this possibility by running the DMD test suite.
Re: dealing with very long paths and names
On Friday, 14 September 2018 at 21:16:31 UTC, Jonathan M Davis wrote: Yeah, though if you write cross-platform applications or libraries (and ideally, most applications and libraries would be platform-agnostic), you can't necessarily avoid all of the Windows insanity, even if you yourself use a platform without those problems. Linux generally allows you to go ahead and use the filesystem as a database, and this works pretty well in a lot of cases. Filesystem performance is much better, and so are the limitations - not just the path length as discussed in this thread, but also the range of valid characters (anything except / and NUL is fine). Plus, depending on your choice of filesystem, you get bonus features like snapshots, incremental backups, and deduplication. It's a boon for prototyping (or Linux-only software).
Re: Variadic template with template arguments in pairs
On Wednesday, 12 September 2018 at 21:33:17 UTC, Paul Backus
wrote:
Another alternative is to write the function recursively:
void doByPair(T, Rest...)(string desc, T* valuePtr, Rest rest)
{
writefln("%s %s: %s", T.stringof, desc, *valuePtr);
if (rest.length) doByPair(rest);
}
Rest... is genius, I don't know why it never struck me before.
My current solution doesn't support having chunks of varying
sizes (ideally it would take 2 *or* 3), but the current use case
is okay with just pairs for now. I imagine I could keep the same
signature and just access a third argument with rest[0] and
recursing on rest[1..$].
Many thanks!
Re: Why the hell do exceptions give error in the library rather than the user code?
On Friday, 14 September 2018 at 14:34:36 UTC, Josphe Brigmo wrote: Why the hell do exceptions give error in the library rather than the user code? D exceptions can provide context in two ways: - Stack trace, for which you need to compile with debug symbols enabled (-g). - A file name and line number, which can be passed as parameters, and usually have the default value of the `new FileException` expression's location. What you're seeing is the second. As you've observed, it is mainly designed to provide context when exceptions are thrown in user code, especially when debug information is not available. Although it's possible to capture the file/line in library functions and pass them down to exception objects, it is impractical to do it for every library function. The stack trace needs to be used in such cases. Still, some functions dealing with error handling do this, e.g. std.exception.enforce. In the future, please post questions about learning or using D in the "learn" group: https://forum.dlang.org/group/learn
Re: Why the hell do exceptions give error in the library rather than the user code?
On Friday, 14 September 2018 at 16:40:01 UTC, Josphe Brigmo wrote: This is the only kind of error I get Compile with -g.
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
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. To add to that, a lot of the issues that get posted on the forum already have bug reports, and those reports have been there for *years*.
Re: phobo's std.file is completely broke!
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. 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.
Re: phobo's std.file is completely broke!
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. 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? 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.
Re: phobo's std.file is completely broke!
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.
Re: phobo's std.file is completely broke!
For example, https://issues.dlang.org/show_bug.cgi?id=8967 ` Jay Norwood 2014-03-18 18:01:59 UTC More surprising is attempting to remove a long directory path and having an exception occur. 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. ` Which is almost 5 years old and exactly the same problem I'm having... 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! and, of course, no followup on that bug has been done... again, this is why I generally end up regretting using D. I thought it would be easier to write a small utility in a few hours and it's turned in to a few days. Any other sane language and I would have been done with 1/10th of the frustration and I'd actually have working code(which I still don't) because rmdir is till failing for some reason. 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).
Re: phobo's std.file is completely broke!
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. It's simple as that. just because it uses unicode does not mean squat if it doesn't work. The docs from microsoft said that the unicode functions are suppose to not have the limitation, but that doesn't mean that using them is the only fix. The fact is, I write a directory parser and it failed, then I spend the next day trying to get something relatively easy to be fixed that should already have been fixed. I'm also not the only one with the problem. Maybe you should spend some time on windows and using std.file with long paths. I bet you have actually never done it so you are obviously to the problems. There may be "simple" fixes, but the fact is that something is wrong or else my code would work(you can blame me all you want but the facts are the facts and the code only breaks on long file names). https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation It is a bit more complicated than just saying that phobos is doing it's job. Of course, it could be some windows issue but given that https://issues.dlang.org/show_bug.cgi?id=8967 The point is that these things should be thoroughly tested before blaming the end user. Whatever is going on, it should. File IO is very basic and common and for code to break silently or in ways that does not make sense is bad, regardless of if I existed in this universe or not. How hard is it for phobos to detect long files and absolute files and such and prepend if necessary?
Re: Why do some attributes have an @ symbol and others don't?
On Saturday, 15 September 2018 at 12:40:07 UTC, Gary Willoughby wrote: Is it just a legacy thing? Yeah, basically the ones that date back to before the @ thing don't have it, and the ones after it do.
Why do some attributes have an @ symbol and others don't?
Why do some attributes have an @ symbol and others don't? I thought it might be because some are used as keywords for other things but then 'pure' doesn't follow that rule. Any ideas? Is it just a legacy thing?
Re: phobo's std.file is completely broke!
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
Re: phobo's std.file is completely broke!
On Saturday, 15 September 2018 at 10:57:56 UTC, Josphe Brigmo wrote: All ansi api calls are limited by MAX_PATH. The way to fix it is to use the wide api calls which are not limited or to use other tricks. Phobos *NEEDS* to be modified to work with these newer OS's. Phobos already uses the wide APIs where it can. Sometimes it uses the C APIs, though, for C compatibility. One example of this is std.stdio.File, which is based on C FILE*. We can change std.file to use Windows APIs on Windows, no problem. That also will help with Unicode compatibility. However, as far as I can see, this has already been done for the cases you're having problems with (remove, and dirEntries which doesn't even have a C API). So, it looks like all you need to do is prepend \\?\ to your paths. If it still doesn't work, the problem is with Windows. (Well, the problem was with Windows to begin with...)
Re: phobo's std.file is completely broke!
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) The problem this causes can be disastrous. If some check fails and runs code that isn't mean to run if the file exists, it could destroy data. I replaced many of the std.file functions with executeShell(...) and using command line functions and they work. But then my code was still failing and it was because exist was returning false even though the file exists. I'm sure this is not a big deal to some... If you are on Windows 10 version 1607 or later, there's a registry key you can set so that the default behavior of the Win32 API allows long file path names. But yah, the problem is Windows, its horrible file system and structure thereof. You'd have faced this problem using any other language like C or C++ included. HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD)
Re: phobo's std.file is completely broke!
On Saturday, 15 September 2018 at 10:48:10 UTC, Vladimir
Panteleev wrote:
On Friday, 14 September 2018 at 19:42:39 UTC, Josphe Brigmo
wrote:
"It doesn't matter. When I compile a program or DLL in C/C++
and many other languages, I use the Windows headers. These
headers define MAX_PATH to 260.
So the program will have the limit set by compile time, no
matter what you do in the OS later on. There is no advantage
with this setting for now, except that you now *may* pass long
paths to API functions w/o the infamous \\?\ prefix, but you
have no guarantee for it.
So to make this have the advantage that some people think it
will provide, we'd need:
wait until the Windows headers (in Visual Studio, or the
DDK, or the Platform SDK or whatever) is properly updated,
i.e. the runtime libs may take advantage of it
wait until MS forces this setting to be enabled all the
time, otherwise it's useless when it stays optional
not checking any more for the target OS in the
application, assuming Win 10 with the mentioned update
The latter will only be the case when an app can't target an
Windows version below 10. So all in all it will take years
until we get the advantage for standalone applications, and
for TC these things don't matter for now anyway.
"
enum size_t MAX_PATH = 260;
MAX_PATH only applies to static arrays (usually on the stack),
i.e. code which does this:
void doSomething()
{
char fileName[MAX_PATH];
...
SomeWindowsAPI(fileName);
}
D almost never does this - instead, it uses dynamically sized
buffers which fit the entire file name. The only times MAX_PATH
is used in Phobos is:
- thisExePath (return path to current .exe file)
- tempDir (return path to temporary directory)
Obviously neither of these is related to the problems you're
seeing.
You are missing the point, MAX_PATH is more than just phobos.
It's built in to the windows design. Windows enforces it.
All ansi api calls are limited by MAX_PATH.
The way to fix it is to use the wide api calls which are not
limited or to use other tricks.
Phobos *NEEDS* to be modified to work with these newer OS's.
You wouldn't like it if phobos limit something that it didn't
need that you would use, would you?
File operations are so common that this stuff is relevant to all
that use windows(and some that don't).
Re: phobo's std.file is completely broke!
On Friday, 14 September 2018 at 19:42:39 UTC, Josphe Brigmo wrote:
"It doesn't matter. When I compile a program or DLL in C/C++
and many other languages, I use the Windows headers. These
headers define MAX_PATH to 260.
So the program will have the limit set by compile time, no
matter what you do in the OS later on. There is no advantage
with this setting for now, except that you now *may* pass long
paths to API functions w/o the infamous \\?\ prefix, but you
have no guarantee for it.
So to make this have the advantage that some people think it
will provide, we'd need:
wait until the Windows headers (in Visual Studio, or the
DDK, or the Platform SDK or whatever) is properly updated, i.e.
the runtime libs may take advantage of it
wait until MS forces this setting to be enabled all the
time, otherwise it's useless when it stays optional
not checking any more for the target OS in the application,
assuming Win 10 with the mentioned update
The latter will only be the case when an app can't target an
Windows version below 10. So all in all it will take years
until we get the advantage for standalone applications, and for
TC these things don't matter for now anyway.
"
enum size_t MAX_PATH = 260;
MAX_PATH only applies to static arrays (usually on the stack),
i.e. code which does this:
void doSomething()
{
char fileName[MAX_PATH];
...
SomeWindowsAPI(fileName);
}
D almost never does this - instead, it uses dynamically sized
buffers which fit the entire file name. The only times MAX_PATH
is used in Phobos is:
- thisExePath (return path to current .exe file)
- tempDir (return path to temporary directory)
Obviously neither of these is related to the problems you're
seeing.
[Issue 19248] Wrong mangle for C++ const STL classes/structs
https://issues.dlang.org/show_bug.cgi?id=19248 --- Comment #2 from Илья Ярошенко --- related bug https://issues.dlang.org/show_bug.cgi?id=18957 --
Re: phobo's std.file is completely broke!
On Saturday, 15 September 2018 at 10:05:26 UTC, Josphe Brigmo wrote: Yes, I did that and it worked for some(most) things it seems but rmdir, for example, seems to fail. If the file path is passed verbatim to the OS API, and it still doesn't work, then the problem is with the OS or the API, not D. Also, windows 10 does not have this problem What do you mean by "windows 10"? Do you mean Explorer, the default file manager? Some reasons why it might work whereas the API doesn't: - It's using workarounds, like the \\?\ prefix, or moving/renaming the object to a shorter name before deleting it. - It's using a newer API, like WinRT (introduced in Windows 8). - It's using a secret Microsoft API. If it did I wouldn't have had this problem and wasted a day of my life trying to figure out what is going on(I didn't design my program around having to hack such things, I just assumed they would work, because, after all, they should, right?). I, too, spent a LOT of time fighting the Windows filesystem APIs. See e.g. * https://dump.thecybershadow.net/d78d9911adc16ec749914b6923759454/longpathdelete.d (that also sets ownership/ACLs via external processes, as the C API is unreasonably complicated). The problem is 100% due to Windows. It was one of the big reasons why I moved to Linux for software development. Such problems do not exist there.
[Issue 18957] extern(C++) doesn't mangle 'std' correctly on posix systems
https://issues.dlang.org/show_bug.cgi?id=18957
--- Comment #4 from Илья Ярошенко ---
(In reply to Manu from comment #0)
> extern (C++, std)
> {
> struct test {}
> }
> extern (C++) void test(ref const(std.test) t) {}
>
> Expect: _Z4testRKNSt4testE
> Actual: _Z4testRKN3std4testE
Actual should be something like _Z4testRKSt4test
--
[Issue 19248] Wrong mangle for C++ const STL classes/structs
https://issues.dlang.org/show_bug.cgi?id=19248 Илья Ярошенко changed: What|Removed |Added Severity|blocker |regression --
[Issue 18957] extern(C++) doesn't mangle 'std' correctly on posix systems
https://issues.dlang.org/show_bug.cgi?id=18957 Илья Ярошенко changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ilyayaroshe...@gmail.com Resolution|FIXED |--- --- Comment #3 from Илья Ярошенко --- see description in https://issues.dlang.org/show_bug.cgi?id=19248 --
Re: remove file access denied(remove broke)
On Saturday, 15 September 2018 at 06:13:29 UTC, bauss wrote:
On Friday, 14 September 2018 at 16:55:21 UTC, Josphe Brigmo
wrote:
On Friday, 14 September 2018 at 15:21:21 UTC, H. S. Teoh wrote:
[...]
It woudln't help. I'm dealing with over a million files and
you'd need those files too.
But basically all I have done is created a new rename function:
void removeFile(string fn)
{
if (!isDir(fn))
{
// remove(fn)
setAttributes(fn, 0x80);
auto ls = executeShell(`del /F /Q "`~fn~`"`);
if (ls.status != 0) throw new Exception("Cannot delete file
`"~fn~"`!");
}
}
And this works and functions appropriately.
The other code is basically just recursively going through the
directory as standard practice using dirEntries and deleting
certain files(it's a little more complex since there is some
logic on the file name, but nothing touches the file except
delete).
Went ahead and did the following in case anyone comes across
your issue in the future:
https://github.com/dlang/phobos/pull/6707
That way the documentation will at least be clear about it.
Thanks. The problem ultimately is MAX_PATH.
Seems that phobo's does not detect windows 10 nor use unicode for
such things as it should which would not break simple code(one
expects file routines to be well used and the bugs fixed). Seems
not to many people use D for windows with long paths and files
and hence D for windows.
The fix is relatively simple ("prepend \\?\ or use the wide
functions).
Re: phobo's std.file is completely broke!
On Saturday, 15 September 2018 at 09:47:25 UTC, WebFreak001 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) The problem this causes can be disastrous. If some check fails and runs code that isn't mean to run if the file exists, it could destroy data. I replaced many of the std.file functions with executeShell(...) and using command line functions and they work. But then my code was still failing and it was because exist was returning false even though the file exists. I'm sure this is not a big deal to some... this is an issue with the Win32 API having that 260 character limit. To work around it, you can use the special path syntax Microsoft allows you to do, which will pass the string you provide directly to the Filesystem instead of parsing it, effectively raising your limit to whatever the Filesystem limits to. See also their official site on this: https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation C:/Some/Very/Long/Path.txt should then become \\?\C:\Some\Very\Long\Path.txt converting / to \ is important because according to the docs windows doesn't do it with the \\?\ prefix. You also have to normalize the path beforehand (i.e. remove ..\ and .\ because they would be treated as actual folder names) To change a server path such as \\share\public you change it to \\?\UNC\share\public There are also some other useful things in there you might want to look at too like the special files such as COM1 Yes, I did that and it worked for some(most) things it seems but rmdir, for example, seems to fail. Also, windows 10 does not have this problem nor does unicode so maybe phobos needs to automatically do everything? If it did I wouldn't have had this problem and wasted a day of my life trying to figure out what is going on(I didn't design my program around having to hack such things, I just assumed they would work, because, after all, they should, right?). I then used execute shell and had to work around that but still had problems because I didn't think dirEntries would be failing. Basically every file function will fail in some odd way(depending on it's use) leaving one to deal with a whole complex of "bugs" when there is really a common bug. rmdir, now is failing but this may be some other bug introduced by me in trying to fix other bugs.
[Issue 19248] Wrong mangle for C++ const STL classes/structs
https://issues.dlang.org/show_bug.cgi?id=19248 --- Comment #1 from Илья Ярошенко --- https://github.com/dlang/dmd/pull/8700 --
Re: phobo's std.file is completely broke!
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) The problem this causes can be disastrous. If some check fails and runs code that isn't mean to run if the file exists, it could destroy data. I replaced many of the std.file functions with executeShell(...) and using command line functions and they work. But then my code was still failing and it was because exist was returning false even though the file exists. I'm sure this is not a big deal to some... this is an issue with the Win32 API having that 260 character limit. To work around it, you can use the special path syntax Microsoft allows you to do, which will pass the string you provide directly to the Filesystem instead of parsing it, effectively raising your limit to whatever the Filesystem limits to. See also their official site on this: https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation C:/Some/Very/Long/Path.txt should then become \\?\C:\Some\Very\Long\Path.txt converting / to \ is important because according to the docs windows doesn't do it with the \\?\ prefix. You also have to normalize the path beforehand (i.e. remove ..\ and .\ because they would be treated as actual folder names) To change a server path such as \\share\public you change it to \\?\UNC\share\public There are also some other useful things in there you might want to look at too like the special files such as COM1
Re: D kernel for Jupyter notebook
On Saturday, 15 September 2018 at 08:12:37 UTC, Peter Alexander wrote: On Sunday, 19 August 2018 at 23:49:21 UTC, Nicholas Wilson wrote: On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote: [...] Note that the D repl will only work on platforms where drepl works i.e. platform with shared library support. It will _build_ on OSX due to https://github.com/kaleidicassociates/jupyterd/blob/master/source/jupyterd/kernel.d#L393 but it won't work. The drepl README on github says it works for OSX. Is that not correct? "Works on any OS with full shared library support by DMD (currently linux, OSX, and FreeBSD)." https://github.com/dlang/druntime/blob/master/src/rt/sections_elf_shared.d#L534 vs. https://github.com/dlang/druntime/blob/master/src/rt/sections_osx_x86_64.d ^F rt_loadLibrary Not found. As a result it fails to link. Probably not hard to fix, though.
[Issue 19248] Wrong mangle for C++ const STL classes/structs
https://issues.dlang.org/show_bug.cgi?id=19248 Илья Ярошенко changed: What|Removed |Added Keywords||C++ --
[Issue 19248] New: Wrong mangle for C++ const STL classes/structs
https://issues.dlang.org/show_bug.cgi?id=19248
Issue ID: 19248
Summary: Wrong mangle for C++ const STL classes/structs
Product: D
Version: D2
Hardware: All
OS: Linux
Status: NEW
Severity: blocker
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: ilyayaroshe...@gmail.com
C++
namespace std
{
class vector
{
};
}
void bar(std::vector& a)
{
}
void foo(const std::vector& a)
{
}
_Z3barRSt6vector:
rep ret
_Z3fooRKSt6vector:
rep ret
D
extern(C++, std)
{
extern(C++, class) struct vector
{
}
}
extern(C++):
void bar(ref std.vector)
{
}
void foo(ref const std.vector)
{
}
_Z3barRSt6vector: // OK
ret
_Z3fooRKNSt6vectorE: // Wrong STD shortcuts
ret
--
Re: D kernel for Jupyter notebook
On Sunday, 19 August 2018 at 23:49:21 UTC, Nicholas Wilson wrote: On Sunday, 19 August 2018 at 20:33:45 UTC, Laeeth Isharc wrote: [...] Note that the D repl will only work on platforms where drepl works i.e. platform with shared library support. It will _build_ on OSX due to https://github.com/kaleidicassociates/jupyterd/blob/master/source/jupyterd/kernel.d#L393 but it won't work. The drepl README on github says it works for OSX. Is that not correct? "Works on any OS with full shared library support by DMD (currently linux, OSX, and FreeBSD)."
A Brief Intro to the SAoC Projects
I've posted to the blog a brief introduction to the projects that were selected for the Symmetry Autumn of Code. As the event goes on, I hope to provide more details about the projects and the individuals working on them. The blog: https://dlang.org/blog/2018/09/15/symmetry-autumn-of-code-is-underway/ Reddit: https://www.reddit.com/r/d_language/comments/9fzrqd/symmetry_autumn_of_code_is_underway/?
Re: array to string functional?
On Saturday, 15 September 2018 at 06:16:59 UTC, bauss wrote:
On Friday, 14 September 2018 at 20:43:45 UTC, SrMordred wrote:
What you want is std.range.chunks
auto a = [1,0,1,1,1,0,1,0,1,1,1,1,0];
a.map!(to!string)
.join("")
.chunks(4)
.map!(to!string) //don´t know why the chunks are not
already strings at this point ;/
.writeln;
They're not strings, because they're now 4 ranges of integers.
Then you map each of those 4 integer ranges into 4 strings.
Oh wait I didn't see your first map!(to!string)
I take back what I just said.
Re: array to string functional?
On Friday, 14 September 2018 at 20:43:45 UTC, SrMordred wrote:
What you want is std.range.chunks
auto a = [1,0,1,1,1,0,1,0,1,1,1,1,0];
a.map!(to!string)
.join("")
.chunks(4)
.map!(to!string) //don´t know why the chunks are not
already strings at this point ;/
.writeln;
They're not strings, because they're now 4 ranges of integers.
Then you map each of those 4 integer ranges into 4 strings.
Re: remove file access denied(remove broke)
On Friday, 14 September 2018 at 16:55:21 UTC, Josphe Brigmo wrote:
On Friday, 14 September 2018 at 15:21:21 UTC, H. S. Teoh wrote:
[...]
It woudln't help. I'm dealing with over a million files and
you'd need those files too.
But basically all I have done is created a new rename function:
void removeFile(string fn)
{
if (!isDir(fn))
{
// remove(fn)
setAttributes(fn, 0x80);
auto ls = executeShell(`del /F /Q "`~fn~`"`);
if (ls.status != 0) throw new Exception("Cannot delete file
`"~fn~"`!");
}
}
And this works and functions appropriately.
The other code is basically just recursively going through the
directory as standard practice using dirEntries and deleting
certain files(it's a little more complex since there is some
logic on the file name, but nothing touches the file except
delete).
Went ahead and did the following in case anyone comes across your
issue in the future:
https://github.com/dlang/phobos/pull/6707
That way the documentation will at least be clear about it.
