Re: D Binding to GUI libraries [was Interesting Observation from JAXLondon]
On Saturday, 20 October 2018 at 09:25:58 UTC, Russel Winder wrote: On Sat, 2018-10-20 at 08:52 +, Gregor Mückl via Digitalmars-d wrote: […] I periodically look at how I can make use of D for small projects. Most often, I shy away because I want to build a GUI and none of the libraries that I can find look mature and well maintained enough to put my faith in. For C++ there's Qt, which is *phenomenally* good (despite some warts), but there's been at least half a dozen attempts at creating D bindings for that, all in various states of completion/negligence. GtkD works very well for me. But I guess GTK+ has a reputation of not working on Windows and macOS. Once a reputation is established it is nigh on impossible to refute. Last time I tried to use GTK on windows I had to build i from source myself, from the looks of it that hasn't changed. It has a huge dependency list, and some of those dependencies have their own dependencies. They all have to be built their own different way on Windows. It's a pain in the ass to do, i tried and didn't bother after trying to compile cairo or whatever. Kind of odd they don't have any sort of build script, I guess they just use Mingw which not very many people use. It may work on Windows, but the amount of effort to set it up is not worth it at all. The developers of the library obviously don't care enough either to try to reduce that barrier. Why not provide a built shared library? Something tells me they haven't even bothered to compile it with MSVC themselves. Their guide to build with MSVC links to a 3+ year old Gnome article where someone not even affiliated with GTK wrote a powershell script to build it with MSVC. The other links to an article that is still using VS 2010 and 2008 for the build. I mean it *may* work, but that isn't the problem if the developers completely lack support for the platform. I can download Qt with prebuilt libraries and it works out of the box with MSVC. There's an obvious difference between the two developers support. As someone else said GTK look like ass on Windows, Qt is really the only crossplatform GUI API written in a native-compile-able language out there that gets most things right.
Re: DMD Linker Issue on Windows
On Thursday, 18 October 2018 at 16:21:00 UTC, Kai wrote: On Thursday, 18 October 2018 at 07:51:07 UTC, Andre Pany wrote: On Thursday, 18 October 2018 at 00:24:29 UTC, Kai wrote: On Wednesday, 17 October 2018 at 17:44:34 UTC, Adam D. Ruppe wrote: [...] Hmm - wish it was so. When architecture not specified, the linker crashes. When it's given, this happens (seems to be a vibe issue?): [...] As far as I can see, there are some Windows libraries missing. These libraries are part of the Windows sdk (You can use the vs build tools installer). Maybe we can include at least the libraries needed for vibe.d into the dmd Windows package? Kind regards Andre I have multiple incarnations of both libs on my machine. I copied the latest version of each into my the lib folder of the DMD install path and it still fails with neither of them being found. What am I doing wrong? Where do they need to go? Thanks for any help once more... Who knows what path it is using for libs, I don't know if it does for lld-link and the config file was removed almost entirely. It determines these things on it's own and I'm not sure if there is any way to display what it is actually using without looking through the source. Try using the "-v" argument with DMD and look for the command it uses to run the linker. There might be a parameter passed for library paths there. Those two files were removed since VS 2015 I think, so odds are that's why it can't find it. If it is using a newer VS install path.
Re: automatically closing stale pull requests
On Tuesday, 16 October 2018 at 22:18:13 UTC, Walter Bright wrote: On 10/16/2018 1:16 PM, notna wrote: [...] We're not going to automatically close stale pull requests, nor are we going to arbitrarily close old unfixed bug reports. Agreed, then there won't be those 5+ year old reports we can point to when an issue gets posted about on the forums and someone tells them to file a bug report.
Re: A Friendly Challenge for D
On Wednesday, 10 October 2018 at 16:15:56 UTC, Jabari Zakiya wrote: I would like to include in my paper a good comparison of various implementations in different compiled languages (C/C++, D, Nim, etc) to show how it performs with each. If you want help with your paper, possibly some kind of decent financial incentive would be appropriate. If the algorithm benefits from more threads than finding or creating an implementation that runs on a GPU would probably be the true performance test. CPUs have like 4-8 cores in the mainstream? A GPU has hundreds, though with some limitations.
Re: Just found this debugger...
On Wednesday, 3 October 2018 at 13:20:03 UTC, JN wrote: On Wednesday, 3 October 2018 at 03:25:04 UTC, solidstate1991 wrote: Then I had a thought: Is there anything usable on the market besides these? It may not be enough for your needs, but VSCode C++ debugger somewhat works for D. I can't set breakpoints, but stepping through code works and watches also work for most simple types. Enable the setting in your user/workspace: // Allow setting breakpoints in any file. "debug.allowBreakpointsEverywhere": true,
Re: Copy Constructor DIP and implementation
On Monday, 17 September 2018 at 19:10:27 UTC, Jonathan M Davis
wrote:
Basically, @implicit is being proposed out of fear that
someone, somewhere wrote a constructor that had what would be a
copy constructor if D had them instead of postblit constructors
and that that code would break with the DIP. Does anyone expect
that such a constructor would be intended as anything other
than a copy constructor (albeit one that has to be called
explicitly)? And does anyone really think that such
constructors are at all common, given that the correct way to
handle the problem in D right now is the postblit constructor?
We're talking about introducing an attribute that should be
unnecessary, which will be annoying to use, and which will be
error-prone given the bugs that you'll get if you forget to
mark your copy constructor with it. And it's all to avoid
breaking a theoretical piece of code that I would think that we
could all agree is extremely rare if it exists in any real D
code base at all. Simply using a transitional compiler switch
like we have with other DIPs would make _way_ more sense than
burdening the language with an unnecessary attribute that's
just going to make it easier to write buggy code. This is
clearly a case of making the language worse long term in order
to avoid a theoretical problem in the short term.
- Jonathan M Davis
From what I've read, the copy constructor can be used with
different types:
struct B
{
}
struct A
{
@implicit this(ref B b)
{
}
}
B foo();
A a;
a = foo(); // ok because of @implicit
a = A(foo()); // ok without @implicit
That's why it exists, otherwise I wouldn't want two types to be
implicitly convertible unless i explicitly tell it to be implicit.
Re: phobo's std.file is completely broke!
On Sunday, 16 September 2018 at 22:40:45 UTC, Vladimir Panteleev
wrote:
On Sunday, 16 September 2018 at 16:17:21 UTC, tide wrote:
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.
Funny the other guy was saying to create a bugzilla issue.
Do that *first*.
That's already been done.
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.
All these issues yet for some reason this function was
included in the lot:
https://dlang.org/phobos/std_path.html#absolutePath
[...]
This issue exists anyways, you'd only expand the path when it
need to be used. If the file changes within milliseconds, I
don't see that happening often and if it does there's a flaw
in your design that'd happen even if the path didn't have to
be constructed first.
You've missed the point. Complexity breeds bugs and unexpected
behavior. The expectation is that D's function to delete a file
should do little else than call the OS function.
If *YOU* are OK with the consequences of complexity, implement
this in YOUR code, but do not enforce it upon others.
version(Windows)
{
if(path.length >= MAX_PATH)
{
// throw Exception(...) // effectively what happens now
// do workaround for
}
}
The complexity would only exist for those that need it. It'd be
the difference between their code not working and code working.
I'm sure people would rather their code work than not work in
this case.
So you pass a valid path (selected by a user through a UI) to
rmDir, and it doesn't remove the directory. You think this is
acceptable behavior?
It is absolutely not acceptable behavior. Complain to
Microsoft. The OS should not allow users to create or select
paths that programs cannot operate on without jumping through
crazy hoops.
Not that crazy, you can get the actual absolutePath with one of
the OS functions. It isn't that difficult of a workaround.
Re: phobo's std.file is completely broke!
On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev wrote: 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. Well my mistake, seems absolutePath is just named incorrectly and should be more accurately named concatenatePath.
Re: phobo's std.file is completely broke!
On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev wrote: 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. I'd agree with you that it isn't **Phobos** problem, but since most of the functions there aren't @system nor @nogc, I do believe it is. And if you want @system and @nogc with no safety you can go look into core.stdc for that.
Re: phobo's std.file is completely broke!
On Sunday, 16 September 2018 at 03:19:12 UTC, Vladimir Panteleev wrote: 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. Funny the other guy was saying to create a bugzilla issue. 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. All these issues yet for some reason this function was included in the lot: https://dlang.org/phobos/std_path.html#absolutePath 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. This issue exists anyways, you'd only expand the path when it need to be used. If the file changes within milliseconds, I don't see that happening often and if it does there's a flaw in your design that'd happen even if the path didn't have to be constructed first. 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. So you pass a valid path (selected by a user through a UI) to rmDir, and it doesn't remove the directory. You think this is acceptable behavior?
Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 15:56:25 UTC, Neia Neutuladh wrote: Better network connectivity and cloud-based gaming would erode another segment of powerful personal computers. I wish companies actually cared for providing better networks. But the truth is they are fine charging for their overpriced internet packages as it stands. They don't get anything out of providing better internet for cheaper. The output of throughput you would need for something like 4k gaming or 144hz. I don't ever see (at least america's) internet structure supporting that in 30 years.
Re: Mobile is the new PC and AArch64 is the new x64
That is, it is not just the performance that affects the sales of phones. There's a lot of factors that lead to there being new phones sales. Know someone that's gone through 3 phones in comparison to just the one I have. Treadmills eat phones for breakfast.
Re: Mobile is the new PC and AArch64 is the new x64
On Sunday, 16 September 2018 at 15:11:42 UTC, Joakim wrote: I say that almost 30% drop in PC sales over the last 7 years is mostly due to the rise of mobile. I think a large part of it is that PCs got fast enough for most people about 7-10 years ago. So it was a combination of mobile, and people no longer needing to get newer faster machines. The upgrade cycle moved from "I need a newer faster computer" to "I'll wait till my current system is worn out". (For a lot of people anyway) Sure, that's part of it, but that suggests that once smartphones reach that performance threshold, they will replace PCs altogether. I think we've reached that threshold now. I feel only looking at sales stats is irrelevant. I know people that have lost their phone and just bought a new phone. They get stolen a lot more easily. If your screen breaks you are better off buying a new phone as the cost of replacing the screen is going to be almost as much as a new one. Someone I know had to fight his boss to repair his phone cause he didn't want a brand new iPhone, he still has an Android device and they switched to Apple a while back. Note, it still costed more to buy the new phone than repair his old one. Computers last much longer, I've had the one I have right now for 8 years. It runs everything I need it to. Faster than a smartphone or tablet, or even most newer laptops still. There's no reason to buy a new one, not that I would buy a prebuilt one anyways. Which I'm pretty sure are what those sales represent. Can't really count a CPU sale as a "PC" sale as it might just be someone upgrading from their old PC.
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 ./.
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: 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: 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 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 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: Mobile is the new PC and AArch64 is the new x64
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.
Re: #dbugfix 17508 - optlink 8.00.17 crash at EIP=0040F60A
On Sunday, 9 September 2018 at 11:52:31 UTC, Bastiaan Veelo wrote: My entry for the #dbugfix campaign[1]: https://issues.dlang.org/show_bug.cgi?id=17508 This makes building ddox / scod documentation impossible on Windows. Reporting date: 2017-06-15 There exists a similar optlink issue (duplicate?) also in linking vibe.d, reported 2015-10-17: https://issues.dlang.org/show_bug.cgi?id=15213 [1] https://forum.dlang.org/post/ojxxjixcxnztmssky...@forum.dlang.org I'd file the bug with DUB that you are forced to use optlink even when specified not to. That's more likely to be fixed than a bug in Optlink, as it is programmed in assembly. Any bug found in optlink, a limitation is usually just added into DMD for it instead of fixing the bug in Optlink. https://github.com/dlang/dub/issues
Re: Debugging mixins - we need to do something
On Sunday, 9 September 2018 at 00:58:15 UTC, Nicholas Wilson wrote: Obligatory "Bugzilla issue?". Obligatory "it already exists and has exited for X amount of years" (4 in this case). https://issues.dlang.org/show_bug.cgi?id=12790 As with most issues in bugzilla, no one has so much as made a comment on it or any other kind of activity. Oh another one from 2008, 10 years ago. https://issues.dlang.org/show_bug.cgi?id=1870 At least this one has someone adding to the issue, is Bill Baxter still around? Then 6 years later, someone says they want the feature and 2 years after that the guy that made the other issue adds a comment. Followed by 4 years of nothing. This just about describes Dlang's bug tracking as accurately as it gets.
Re: Source changes should include date of change
On Saturday, 8 September 2018 at 11:29:15 UTC, Josphe Brigmo wrote: On Saturday, 8 September 2018 at 07:08:46 UTC, Colin wrote: On Saturday, 8 September 2018 at 06:59:28 UTC, Josphe Brigmo wrote: Having source code that doesn't show changes with dates is pretty useless for diagnostics. I realize that git has the changes but the source code should. If some code is added or changed it is very simple to add the date of change in a comment. // Date: Date1, Date2, Date3, Anything below a was changed at those dates. Why not also add a link to the git hub patch or bugzilla or whatever? Git is the tool that's used to manage changes, including viewing the changes. A lot of dev time has gone into it and it works really well. Some ad hoc comment system in source code to point out changes will never be as good. Just Use Git! Um, I didn't say don't use Git! Your illogic is that you believe that one can have only one or the other when one can have both. Hence, you are excluding a completely valid addition. You think it is an alternative. You are wrong. Please think about the question before you answer next time so that you don't get in the habit of doing it. No one said that Git couldn't be used and telling me to use it is very arrogant of yourself. The fact of the matter is that dates in source code will help when git is not available and one only has the source code. Dates won't help, if you have a comment with a date that states everything under it was modified at that date. What happens when there's a split of 3-4 lines between modifications? Just how many of these comments are there going to be? This will be unusable, adds very little useful information, won't work for past changes overwritten changes and deletions. Just use git, that's what it is designed to do without polluting source code with useless comments. If you have the source code, there's no reason you won't have the git repo as well. It can all be stored and used locally on your own machine.
Re: extern(C++, ns) is wrong
On Wednesday, 5 September 2018 at 00:35:50 UTC, Manu wrote: On Tue, 4 Sep 2018 at 17:30, tide via Digitalmars-d wrote: On Tuesday, 4 September 2018 at 23:32:31 UTC, Walter Bright wrote: > On 9/4/2018 3:33 PM, Manu wrote: >> file1.d >> - >> module bliz.ecs.component_access; >> import bliz.ecs.table; >> import bliz.ecs.types; >> extern(C++, bliz): >> // things... >> >> Error: >> project\ecs\include\d2\bliz\ecs\component_access.d(7): >> Error: >> namespace `bliz.ecs.component_access.bliz` conflicts with >> import >> `bliz.ecs.component_access.bliz` at >> project\ecs\include\d2\bliz\ecs\component_access.d(3) >> >> file2.d >> - >> module bliz.ecs.table; >> import bliz.ecs.types; >> extern(C++, bliz): >> // things... >> >> Error: project\ecs\include\d2\bliz\ecs\table.d(11): Error: >> namespace >> `bliz.ecs.table.bliz` conflicts with import >> `bliz.ecs.table.bliz` at >> project\ecs\include\d2\bliz\ecs\table.d(5) > > I can't help because the examples are incomplete. There is > no line 5 in table.d, nor a line 7 in component_access.d The > error messages are not generated from the code posted. That's all you need really, any symbol you add will cause the error. extern(C++, bliz): created a symbol "bliz", you can't import a package from "bliz" cause then there's a symbol clash. I thought you implemented extern(C++) ... And yes, the example is actually complete. Again, but I'll simplify the filenames: ns/bar.d - module ns.bar; import ns.baz; extern(C++, ns): ns/baz.d - module ns.baz; import ns.bar; extern(C++, ns): dmd ns/bar.d ns/baz.d Judging by the name of the modules are you working on an Entity Component System for D :o ?
Re: extern(C++, ns) is wrong
On Tuesday, 4 September 2018 at 23:32:31 UTC, Walter Bright wrote: On 9/4/2018 3:33 PM, Manu wrote: file1.d - module bliz.ecs.component_access; import bliz.ecs.table; import bliz.ecs.types; extern(C++, bliz): // things... Error: project\ecs\include\d2\bliz\ecs\component_access.d(7): Error: namespace `bliz.ecs.component_access.bliz` conflicts with import `bliz.ecs.component_access.bliz` at project\ecs\include\d2\bliz\ecs\component_access.d(3) file2.d - module bliz.ecs.table; import bliz.ecs.types; extern(C++, bliz): // things... Error: project\ecs\include\d2\bliz\ecs\table.d(11): Error: namespace `bliz.ecs.table.bliz` conflicts with import `bliz.ecs.table.bliz` at project\ecs\include\d2\bliz\ecs\table.d(5) I can't help because the examples are incomplete. There is no line 5 in table.d, nor a line 7 in component_access.d The error messages are not generated from the code posted. That's all you need really, any symbol you add will cause the error. extern(C++, bliz): created a symbol "bliz", you can't import a package from "bliz" cause then there's a symbol clash. I thought you implemented extern(C++) ...
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Tuesday, 4 September 2018 at 21:36:16 UTC, Walter Bright wrote: On 9/1/2018 4:12 AM, Chris wrote: Hope is usually the last thing to die. But one has to be wise enough to see that sometimes there is nothing one can do. As things are now, for me personally D is no longer an option, because of simple basic things, like autodecode, a flaw that will be there forever, poor support for industry technologies (Android, iOS) and the constant "threat" of code breakage. The D language developers don't seem to understand the importance of these trivial matters. I'm not just opinionating, by now I have no other _choice_ but to look for alternatives - and I do feel a little bit sad. Android, iOS - Contribute to help make it better. It would help if the main official compiler supported those operating systems. That would mean adding ARM support to DMD. Or a much simpler solution, use an existing backend that has ARM support built in to it and is maintained by a much larger established group of individuals. Say like how some languages, like Rust, do.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 20:48:27 UTC, Walter Bright wrote: On 9/1/2018 5:25 AM, tide wrote: and that all bugs can be solved with asserts I never said that, not even close. Are you in large implying it. But I will maintain that DVD players still hanging on a scratched DVD after 20 years of development means there's some cowboy engineering going on, and an obvious lack of concern about that from the manufacturer. Yes why wouldn't a company want to fix a "feature" where by, if you have a scratch on a DVD you have to go buy another one in order to play it. It's obviously not that big of a deal breaker, even for you, considering you are still buying them 20 years on.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 13:21:27 UTC, Jonathan M Davis wrote: On Saturday, September 1, 2018 6:37:13 AM MDT tide via Digitalmars-d wrote: On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: > On 8/31/2018 7:28 PM, tide wrote: >> I'm just wondering but how would you code an assert to >> ensure the variable for a title bar is the correct color? >> Just how many asserts are you going to have in your >> real-time game that can be expected to run at 144+ fps ? > > Experience will guide you on where to put the asserts. > > But really, just apply common sense. It's not just for > software. If you're a physicist, and your calculations come > up with a negative mass, you screwed up. If you're a > mechanical engineer, and calculate a force of billion pounds > from dropping a piano, you screwed up. If you're an > accountant, and calculate that you owe a million dollars in > taxes on a thousand dollars of income, you screwed up. If > you build a diagnostic X-ray machine, and the control > software computes a lethal dose to administer, you screwed > up. > > Apply common sense and assert on unreasonable results, > because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with. I don't think that H. S. Teoh's point was so much that you should be asserting anything about the colors in the graphics but rather that problems in the graphics could be a sign of a deeper, more critical problem and that as such the fact that there are graphical glitches is not necessary innocuous. However, presumably, if you're going to put assertions in that code, you'd assert things about the actual logic that seems critical and not anything about the colors or whatnot - though if the graphical problems would be a sign of a deeper problem, then the assertions could then prevent the graphical problems, since the program would be killed before they happened due to the assertions about the core logic failing. - Jonathan M Davis Any graphic problems are going to stem probably more from shaders and interaction with the GPU than any sort of logic code. Not that you can really use asserts to ensure you are making calls to something like Vulkan correctly. There are validation layers for that, which are more helpful than assert would ever be. They still have a cost, as an example my engine runs at 60+ FPS on my crappy phone without the validation layers. But with them enabled I get roughly less than half that 10-15 fps, depending on where I'm looking. So using them in production code isn't exactly possible. What he was talking about was basically that, he was saying how it could be used to identify possible memory corruption, which is completely absurd. That's just stretching it's use case so thin.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 13:03:50 UTC, rikki cattermole wrote: On 02/09/2018 12:57 AM, tide wrote: On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote: On 02/09/2018 12:37 AM, tide wrote: On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with. If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color. But that isn't something I'd go test... Too much system-y stuff that can modify it. And you're putting that into production code? Cause that's the entire point of this topic :). like Walter has been arguing, are better left untested in production. That's not what Walter has been arguing.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 12:49:12 UTC, rikki cattermole wrote: On 02/09/2018 12:37 AM, tide wrote: On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with. If you have the ability to screenshot a window like I do, oh one simple method call is all that required with a simple index to get the color. But that isn't something I'd go test... Too much system-y stuff that can modify it. And you're putting that into production code? Cause that's the entire point of this topic :).
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 08:18:03 UTC, Walter Bright wrote: On 8/31/2018 7:28 PM, tide wrote: I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ? Experience will guide you on where to put the asserts. But really, just apply common sense. It's not just for software. If you're a physicist, and your calculations come up with a negative mass, you screwed up. If you're a mechanical engineer, and calculate a force of billion pounds from dropping a piano, you screwed up. If you're an accountant, and calculate that you owe a million dollars in taxes on a thousand dollars of income, you screwed up. If you build a diagnostic X-ray machine, and the control software computes a lethal dose to administer, you screwed up. Apply common sense and assert on unreasonable results, because your code is broken. That's what he, and apparently you don't get. How are you going to use an assert to check that the color of a title bar is valid? Try and implement that assert, and let me know what you come up with.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 08:05:58 UTC, Walter Bright wrote: On 8/31/2018 5:47 PM, tide wrote: I've already read them before. Why don't you explain what is wrong with it rather than posting articles. Because the articles explain the issues at length. Explaining why your proposal is deeply flawed was the entire purpose I wrote them. I didn't write a proposal. I was explaining a flaw in your proposal. You are just taking one line comments without even thinking about the context. We can start with the observation that a fly-by-wire is not a fundamentally different system than a fully powered hydraulic system or even a pilot muscle cable system, when we're talking about safety principles. It is vastly different, do you know what fly by wire is? It means the computer is taking input digitally and applying the commands from the digital input into actual output. If the system controlling that just stops working, how do you expect the pilot to fly the plane? While all they are doing is moving a digital sensor that is doing nothing because the system that reads it input hit an assert. There's nothing magic about software. It's just more complicated (a fact that makes it even MORE important to adhere to sound principles, not throw them out the window). I didn't say to throw them the door, I'm saying there's a lot of different ways to do things. And using asserts isn't the one ring to rule all safety measures. There are different methods, and depending on the application, as with anything, has it's pros and cons where a different method will be more suitable.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 07:59:27 UTC, Walter Bright wrote: On 8/31/2018 5:40 PM, tide wrote: On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries. Doesn't matter. It's clear that DVD player software is written by cowboy programmers who likely believe that it's fine to continue running a program after it has entered an invalid state, presumably to avoid annoying customers. Newer DVD/Bluray players have an ethernet port on the back. I'd never connect such a P.O.S. malware incubator to my LAN. It does matter, I've programmed on embedded systems where the filename length was limited to 10 or so characters. There were all kinds of restrictions, how do you know when you have to power cycle that isn't an assert being hit and having the powercycle is the result of a hardware limitation that these "cowboy programmers" had no control over ? You are making a lot of wild assumptions to try and prove a point, and that all bugs can be solved with asserts (which they can't). Hey guys race conditions aren't a problem, just use an assert, mission fucking accomplished.
Re: This thread on Hacker News terrifies me
On Saturday, 1 September 2018 at 05:53:12 UTC, rikki cattermole wrote: On 01/09/2018 12:40 PM, tide wrote: On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries. And yet they manage to run a JVM with Java on it. Not the one's Walter is talking about. I rarely have to power cycle any smart device, even my phone which is running so much shit on it.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 22:05:18 UTC, H. S. Teoh wrote: On Fri, Aug 31, 2018 at 09:40:50PM +, tide via Digitalmars-d wrote: On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote: [...] > Furthermore, how often have we cursed about games that hung > up with a blackscreen and didn't let us close them by any > mean other than logging off? If they just crashed, we'd not > have run into such problems. That's assuming an assert catches every error. Not all bugs are going to be caught by an assert. I don't think I've ever had a game hung up in a black screen and not be able to close it. I have, and that's only one of the better possible scenarios. I've had games get into a bad state, which becomes obvious as visual glitches, and then proceed to silently and subtly corrupt the save file so that on next startup all progress is lost. Had the darned thing aborted at the first visual glitch or unexpected internal state, instead of blindly barging on pretending that visual glitches are not a real problem, the save file might have still been salvageable. (Yes, visual glitches, in and of themselves, aren't a big deal. Most people may not even notice them. But when they happen unexpectedly, they can be a symptom of a deeper, far more serious problem. Just like an assert detecting that some variable isn't the expected value. Maybe the variable isn't even anything important; maybe it just controls the color of the title bar or something equally irrelevant. But it could be a sign that there's been a memory corruption. It could be a sign that the program is in the middle of being exploited by a security hack. The unexpected value in the variable isn't merely an irrelevant thing that we can safely ignore; it could be circumstantial evidence of something far more serious. Continuing to barrel forward in spite of clear evidence pointing to a problem is utterly foolish.) T I'm just wondering but how would you code an assert to ensure the variable for a title bar is the correct color? Just how many asserts are you going to have in your real-time game that can be expected to run at 144+ fps ?
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 22:27:47 UTC, Walter Bright wrote: On 8/31/2018 2:21 PM, tide wrote: On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote: "Stopping all executing may not be the correct 'safe state' for an airplane though!" Depends on the aircraft and how it is implemented. If you have a plane that is fly by wire, and you stop all executing then even the pilot no longer has control of the plane anymore, which would be very bad. I can't even read the rest of posting after this. Please read the following articles, then come back. Assertions in Production Code https://www.digitalmars.com/articles/b14.html Safe Systems from Unreliable Parts https://www.digitalmars.com/articles/b39.html Designing Safe Software Systems Part 2 https://www.digitalmars.com/articles/b40.html I've already read them before. Why don't you explain what is wrong with it rather than posting articles. You are just taking one line comments without even thinking about the context.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 22:42:39 UTC, Walter Bright wrote: On 8/31/2018 2:40 PM, tide wrote: I don't think I've ever had a **game** hung up in a black screen and not be able to close it. I've had that problem with every **DVD player** I've had in the last 20 years. Power cycling is the only fix. Two very different things, odds are your DVD players code aren't even written with a complete C compiler or libraries.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 21:31:02 UTC, 0xEAB wrote: On Friday, 31 August 2018 at 21:21:16 UTC, tide wrote: Depends on the software being developed, for a game? Stopping at every assert would be madness. Let a lone having an over ubundance of asserts. Can't even imagine how many asserts there would be in for something like a matrix multiplication. If one is aware that something is asserting quite often, why don't they just fix the bug that causes that assertion to fail? The asserts being there still cause slow downs in things that would otherwise not be slow. Like how D does assert checks for indices. Furthermore, how often have we cursed about games that hung up with a blackscreen and didn't let us close them by any mean other than logging off? If they just crashed, we'd not have run into such problems. That's assuming an assert catches every error. Not all bugs are going to be caught by an assert. I don't think I've ever had a game hung up in a black screen and not be able to close it.
Re: This thread on Hacker News terrifies me
On Friday, 31 August 2018 at 19:50:20 UTC, Walter Bright wrote: https://news.ycombinator.com/item?id=17880722 Typical comments: "Stopping all executing may not be the correct 'safe state' for an airplane though!" Depends on the aircraft and how it is implemented. If you have a plane that is fly by wire, and you stop all executing then even the pilot no longer has control of the plane anymore, which would be very bad. "One faction believed you should never intentionally crash the app" "One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble." And on and on. It's unbelievable. The conventional wisdom in software for how to deal with programming bugs simply does not exist. Depends on the software being developed, for a game? Stopping at every assert would be madness. Let a lone having an over ubundance of asserts. Can't even imagine how many asserts there would be in for something like a matrix multiplication. An operation that would otherwise be branchless having numerous branches for all the index checks that would be done. Twice per scalar value access. And so on and so on. Here's the same topic on Reddit with the same awful ideas: https://www.reddit.com/r/programming/comments/9bl72d/assertions_in_production_code/ No wonder that DVD players still hang when you insert a DVD with a scratch on it, and I've had a lot of DVD and Bluray players over the last 20 years. No wonder that malware is everywhere. TIL people still use DVD players all the while my desktops and laptops from the last 7+ years have not even had an optical drive.
Re: Engine of forum
On Friday, 24 August 2018 at 01:43:54 UTC, Walter Bright wrote: Nearly 20 years of the D forum consumes 2,800,000 4K blocks, or somewhat over a gigabyte. Not bad. Using years is about a pointless as using lines of code to evaluate a project. There's some sites that have received more throughput of users and their activity in one year than this site has seen in 20.
Re: Engine of forum
On Friday, 24 August 2018 at 01:43:54 UTC, Walter Bright wrote: On 8/21/2018 2:41 PM, tide wrote: What about if you accidentially press a button that posts the comment? That's really up to your NNTP client's design, which we didn't implement. There are lots of NNTP clients to choose from. Don't use a NNTP client, I prefer to just use a browser. Why can't syntax formatting be implemented, does anyone disagree that is a useless feature? It's a useless feature. Formatting is needed for longer form text, which is not really appropriate for the forum. Forum posts should be short and to the point - posting an article or manifesto should be posted separately, with a link to it in the forum. Also, there is no need to post pictures, emoji, banners, or other cruft one sees in other forums. Especially pictures, as those eat up server space and bandwith at a terrifying rate. Nearly 20 years of the D forum consumes 2,800,000 4K blocks, or somewhat over a gigabyte. Not bad. So you've never posted a snippet of code on here? I honestly doubt that. Syntax formatting is useful even if you only post 2 lines of code. No wonder these boards are the way they are with opinions like that.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Wednesday, 29 August 2018 at 17:15:15 UTC, H. S. Teoh wrote: Besides, this is missing the point. What I meant was that if const could be arbitrarily overridden anywhere down the call chain, then the compiler could no longer feasibly verify that a particular piece of code doesn't violate const. The code could be calling a function for which the compiler has no source code, and who knows what that function might do. It could override const and modify the data willy-nilly, and if the const reference is pointing to an immutable object, you're in UB land. Not allowing const to be overridden (without the user deliberately treading into UB land by casting it away) allows the compiler to statically check that the code doesn't actually modify a const object. You appear to be thinking I was making a statement about verifying program correctness in general, which is taking what I said out of context. T You keep saying that, it has to be machine verifiable, but honestly I don't see the benefit to being machine verifiable. As in the case it can't verify the object doesn't change in scope at all, it can only verify that the code in scope doesn't modify it. I'd rather have C++ const and be useful than avoiding const almost completely.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Tuesday, 28 August 2018 at 20:32:29 UTC, H. S. Teoh wrote: On Tue, Aug 28, 2018 at 07:39:20PM +, tide via Digitalmars-d wrote: On Tuesday, 28 August 2018 at 17:02:46 UTC, H. S. Teoh wrote: > On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via > Digitalmars-d wrote: [...] > > There are still valid use cases where const should be > > "broken". One of them is mutex (another one caching). I > > have very little experiance in multi-threaded programming, > > but what do you think about "mutable" members, despite the > > object is const? > > The problem with compromising const is that it would > invalidate any guarantees const may have provided. Const in > D is not the same as const in languages like C++; const in D > means *physical* const, as in, the data might reside in ROM > where it's physically impossible to modify. Allowing the > user to bypass this means UB if the data exists in ROM. I feel that such a narrow use case, wouldn't you just use something like immutable instead. The problem is that immutable implicitly converts to const. Basically, const means "I guarantee I will never modify this data (though someone else might", and immutable means "nobody will ever modify this data". You cannot allow const to mutate without risking breakage with immutable. If the original data came from a mutable reference, you can probably get away with casting const away. But if it came from an immutable object, casting const away is UB. Allowing const to be "sometimes" modified is also UB. > Plus, the whole point of const in D is that it is > machine-verifiable, i.e., the compiler checks that the code > does not break const in any way and therefore you are > guaranteed (barring compiler bugs) that the data does not > change. If const were not machine-verifiable, it would be > nothing more than programming by convention, since it would > guarantee nothing. Allowing const to be "broken" somewhere > would mean it's no longer machine-verifiable (you need a > human to verify whether the semantics are still correct). This is still not true, it is not machine verifiable as it is. It can be bypassed quite easily, as a const object can be assigned from an non-const one. There's no way to offer that guarantee. You misunderstand. Const means "this code cannot modify this object no matter what". It does not guarantee somebody else can't modify it (you want immutable for that). Both mutable and immutable implicitly convert to const, therefore it is imperative that code that handles const never modifies the data, because you don't know the provenance of the data: it could have come from an immutable object. Allowing const to "sometimes" modify stuff will violate immutable and cause UB. Whether a piece of code modifies the data is certainly machine-verifiable -- but only if there are no backdoors to const. If there are, then the compiler cannot feasibly verify const, since it would need to transitively examine all code called by the code in question, but the source code may not be always available. Even if the data came from a mutable object, it does not make it any less machine-verifiable, since what we're verifying is "this code does not modify this data", not "this data never changes". For the latter, immutable provides that guarantee, not const. It is possible, for example, to obtain a const reference to a mutable object, and have one thread modify the object (via the mutable reference) while another thread reads it (via the const reference). You cannot guarantee that the data itself won't change, but you *can* guarantee that the code holding the const reference (without access to the mutable reference) isn't the one making the changes. T Point being, there is a huge difference between what you were saying, and what you are saying now. "This data never changes" is a much better guarantee and check than "this code does not modify this data". You use const to make sure the data doesn't change, if you can't guarantee it doesn't change from any other code then I wouldn't say it is machine-verifiable. So we would need another qualifier "tantamount" to be implemented then it seems.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Tuesday, 28 August 2018 at 17:02:46 UTC, H. S. Teoh wrote:
On Tue, Aug 28, 2018 at 08:18:57AM +, Eugene Wissner via
Digitalmars-d wrote: [...]
There are still valid use cases where const should be
"broken". One of them is mutex (another one caching). I have
very little experiance in multi-threaded programming, but what
do you think about "mutable" members, despite the object is
const?
The problem with compromising const is that it would invalidate
any guarantees const may have provided. Const in D is not the
same as const in languages like C++; const in D means
*physical* const, as in, the data might reside in ROM where
it's physically impossible to modify. Allowing the user to
bypass this means UB if the data exists in ROM.
I feel that such a narrow use case, wouldn't you just use
something like immutable instead.
Plus, the whole point of const in D is that it is
machine-verifiable, i.e., the compiler checks that the code
does not break const in any way and therefore you are
guaranteed (barring compiler bugs) that the data does not
change. If const were not machine-verifiable, it would be
nothing more than programming by convention, since it would
guarantee nothing. Allowing const to be "broken" somewhere
would mean it's no longer machine-verifiable (you need a human
to verify whether the semantics are still correct).
This is still not true, it is not machine verifiable as it is. It
can be bypassed quite easily, as a const object can be assigned
from an non-const one. There's no way to offer that guarantee.
import std.format : format;
struct Type
{
int value;
}
void test(const ref Type type, int* ptr)
{
int first = type.value;
*ptr = first + 1;
assert(type.value == first, format!"%d != %d"(type.value,
first));
}
void main()
{
Type type = Type(10);
test(type, );
}
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Tuesday, 28 August 2018 at 01:11:14 UTC, Walter Bright wrote: On 8/27/2018 10:08 AM, H. S. Teoh wrote: Const in D makes sense as-is. Though, granted, its infectiousness means its scope is actually very narrow, and as a result, we ironically can't use it in very many places, and so its touted benefits only rarely apply. :-( Which also means that it's taking up a lot of language design real estate with not many benefits to show for it. D const is of great utility if you're interested in functional programming. Using it has forced me to rethink how I separate tasks into functions, and the result is for the better. I agree that D const has little utility if you try to program in C++ style. It doesn't play well with templates or any of the like either, so even if you try to do template programming it is just better to not use it. I'm curious as to what an example of this D const for functional programming would look like.
Re: Distribute debug information so I can get informative stack traces?
On Monday, 27 August 2018 at 22:37:53 UTC, spikespaz wrote: I am compiling my project's executables with `-g`, so it outputs `pdb` files. I read that this is necessary to get a useful stack trace. When a user reports an issue, my program gives them a link where the issue body is pre-filled with the crash exception information. Example: https://github.com/spikespaz/search-deflector/issues/10 For some reason though, their reports don't have all of the call stack information that I see when I crash during development. How can I make my program give verbose stack traces like Python, so I can determine what the issue is when users report problems? Phobos isn't built with debug info. You'd have to build it yourself with the debug info and link to that instead.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Sunday, 26 August 2018 at 23:39:32 UTC, Manu wrote: You should try using VisualD to debug DMD some time. You'll quickly discover edge cases trying to evaluate all the relevant state while stepping around. C++ RTTI is a problem (can't identify derived type in debugger), globals are a problem, TLS is a problem. The minor edge cases emerge frequently enough that they convey a sense of immaturity. I'll start taking note everything I encounter a minor debugging issue. It's not just VisualD, the debug info DMD produces just doesn't include things like global variables for some reason. I use VS Code to debug, I get around it by using -gc (which is now deprecated) and adding the variable to the watch list with the full name. It's a pain in the ass though.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Saturday, 25 August 2018 at 01:43:19 UTC, Walter Bright wrote:
On 8/24/2018 4:22 PM, tide wrote:
struct SomeStruct
{
void foo() {
// use SomeStruct
}
}
void broken()
{
void function() foo =
foo(); // runtime error, isn't actually safe uses wrong
calling convention as well
}
Not really lack of feature so much as there exists broken
code. This has been valid code for god knows how long. At some
point it was usable in @safe, but it looks you can't take an
address of a member function without "this" as well in safe
anymore.
That's because it isn't safe. But being able to take the
address is important for system work.
Which is my point. Why did you link that article then? It's not
safe due to the inherent flaw of D. It shouldn't return a
function() type. This is invalid code just outright, the type
system could easily be used to prevent this kind of mistake. But
instead it relies on the user knowing about the bug in D. Hell
like someone else mentioned, if it returned a delegate that would
make more sense. But it doesn't for whatever reason. There's a
lot of little things like this in D, and from your response you
obviously don't give a flying shit about fixing it as you don't
even see it as a problem. Just disable it in @safe and anyone
that needs to write in @system will have to deal with insanity
instead of having something reasonable.
Re: Embrace the from template?
On Friday, 24 August 2018 at 06:41:35 UTC, Jonathan Marler wrote: Ever since I read https://dlang.org/blog/2017/02/13/a-new-import-idiom/ I've very much enjoyed using the new `from` template. It unlocks new idioms in D and have been so useful that I thought it might be a good addition to the core language. I've found that having it in a different place in each project and always having to remember to import it makes it much less ubiquitous for me. One idea is we could add this template to `object.d`. This would allow it to be used from any module that uses druntime without having to import it first. The template itself is also very friendly to "bloat" because it only has a single input parameter which is just a string, extremely easy to memoize. Also, unless it is instantiated, adding it to object.d will have virtually no overhead (just a few AST nodes which would dwarfed by what's already in object.d). It would also be very easy to add, a single PR with 4 lines of code to druntime and we're done. Of course, if we don't want to encourage use of the `from` template then this is not what we'd want. Does anyone have any data/experience with from? All I know is my own usage so feel free to chime in with yours. What uses does this actually have, I only see one example from the article and it is an oversimplistic example that effectively translates to either phobos being used or not being used. All the extra bloat this template would add to the already bloated if constraints is not welcome at all. The potential small benefit this might add isn't worth the unreadable mess it will turn code into.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 22:42:19 UTC, Walter Bright wrote:
On 8/24/2018 12:42 PM, tide wrote:
Some problems require new features like how taking the address
of a member function without an object returns a function
pointer, but requires a delegate where C++ has member function
pointers, D just has broken unusable code. Or old features
that were implemented poorly (C++ mangling for example).
How to do member function pointers in D:
https://www.digitalmars.com/articles/b68.html
struct SomeStruct
{
void foo() {
// use SomeStruct
}
}
void broken()
{
void function() foo =
foo(); // runtime error, isn't actually safe uses wrong
calling convention as well
}
Not really lack of feature so much as there exists broken code.
This has been valid code for god knows how long. At some point it
was usable in @safe, but it looks you can't take an address of a
member function without "this" as well in safe anymore.
Re: Dicebot on leaving D: It is anarchy driven development in all its glory.
On Friday, 24 August 2018 at 19:26:40 UTC, Walter Bright wrote: On 8/24/2018 6:04 AM, Chris wrote: For about a year I've had the feeling that D is moving too fast and going nowhere at the same time. D has to slow down and get stable. D is past the experimental stage. Too many people use it for real world programming and programmers value and _need_ both stability and consistency. Every programmer who says this also demands new (and breaking) features. Some problems require new features like how taking the address of a member function without an object returns a function pointer, but requires a delegate where C++ has member function pointers, D just has broken unusable code. Or old features that were implemented poorly (C++ mangling for example).
Re: Engine of forum
On Wednesday, 22 August 2018 at 23:53:46 UTC, H. S. Teoh wrote: On Wed, Aug 22, 2018 at 04:24:17PM -0700, Walter Bright via Digitalmars-d wrote: On 8/22/2018 10:28 AM, H. S. Teoh wrote: > I don't argue against the usefulness of the features that > github provides, but I'm also wary of the fact that it's > basically a walled garden -- there's no simple way I know of > to extract data like pull requests, comments, > cross-references, etc.. I mean, it's *possible* to write a > web crawler that does just that, but such functionality is > second-class, and one might argue, that it is possible at > all is merely a happy accident, since github's very design > seems to be geared at drawing people to centralize > everything on github. It's not quite at the point of vendor > lock-in, but it's certainly uncomfortably close, in my view. As for github comments, they get echoed to me as emails. So I have an email archive of them. That's good to know. Still, an export function that will give you your data in some computer-parseable format would have been nice. T They have an API for taht, and it looks like people have made programs to create backups of it with the api. https://developer.github.com/v3/ https://hackage.haskell.org/package/github-backup
Re: Engine of forum
On Tuesday, 21 August 2018 at 21:33:13 UTC, Patrick Schluter wrote: On Tuesday, 21 August 2018 at 06:53:18 UTC, Daniel N wrote: On Tuesday, 21 August 2018 at 03:42:21 UTC, Ali wrote: Many of those new comers who ask about the forum software .. they never stick, they dont complain, or question, or try to change for the better, they simply leave I think this is the best forum I have ever used, it's a big contributing factor to that I post here! I don't post every month praising the forum, I'm silently happy. But if we changed I would likely complain every month. Second that. The 2 big things this forum frontend has, is forcing to snip quotes (go look on realworldtech to see whole threads of quote galore of 400 lines where the answer is just one word) and speed. The thing that comments cannot be edited is also an advantage. This forces to put a little be more thought in them. What about if you accidentially press a button that posts the comment? Why can't syntax formatting be implemented, does anyone disagree that is a useless feature?
Re: Engine of forum
On Sunday, 19 August 2018 at 11:11:56 UTC, rikki cattermole wrote: It has been designed to be very fast (quite a notable feature). That's probably why it's down all the time :P.
Re: @nogc with opApply
On Saturday, 11 August 2018 at 10:00:34 UTC, Alex wrote:
Hi all,
maybe I misunderstand something but having this:
´´´
import std.experimental.all;
static assert(isIterable!S);
void main()
{
S s;
s.each!(el => el.writeln);
}
struct S
{
private Nullable!uint member = 0;
Nullable!uint front() @nogc { return member; }
//void popFront(){} // not implementable.
//bool empty(){} // not implementable
Nullable!uint successor(uint current) @nogc { return
Nullable!uint.init; }
/**
the opApply method grants the correct foreach behavior
*/
int opApply(scope int delegate(ref uint) /*@nogc*/
operations) //@nogc
{
int result;
for(auto leading = front; !leading.isNull; leading =
successor(leading.get))
{
result = operations(leading.get);
if(result)
{
break;
}
}
return result;
}
}
´´´
Everything works fine, before I try to use the opApply function
inside a @nogc function.
If I do, compiler complains, that opApply is not marked as
@nogc. Ok.
If I try to mark opApply @nogc, I would have to mark operations
delegate also as @nogc, but I can't do this, as I do not know a
priori, how it will be used.
Now, as I learned at some point, a possibility would be, to
templatify the function, as the compiler can then derive, if
@nogc apply or not.
But if I write
´´´
int opApply()(...){...}
´´´
Then the static assert from above refuses to compile.
So... how to solve this case?
There's no way to solve it, just don't use @nogc is the easiest
workaround. It wasn't thought out when it was added and these are
one of the cases where it doesn't work. Having functions
automatically declare themselves @nogc if they don't use the gc
would solve part of the problem. Which is how templates work.
https://dlang.org/library/std/traits/is_iterable.html
If you see how isIterable is defined you'll see that it requires
opApply be able to provide the element type automatically. That
is "foreach" doesn't define a type and it is automatically
deduced. The compiler can't deduce the argument type because the
function is a template.
foreach(t ; S.init) // Error: cannot infer type for `foreach`
variable `t`, perhaps set it explicitly
{
}
Re: Could you anybody using DerelictSDL2 on Android?
On Saturday, 11 August 2018 at 14:44:49 UTC, zhani wrote: On Saturday, 11 August 2018 at 14:03:21 UTC, tide wrote: On Tuesday, 7 August 2018 at 12:05:33 UTC, zhani wrote: howdy :-) can anybody use sdl2 on android? first, i got a ldc2 for android. i just followed here on windows: https://wiki.dlang.org/Build_D_for_Android#Windows so i could compile a sieve.d but didnt run it on android yet. then next? wut can i try for using DerelictSDL2 on android? and this guide didn't use dub. how can i intergradted with ldc2 for android? pls be advised me. regards, You can use SDL2 for Android, you don't need DerelictSDL2 either. You just need a way to call the SDL2 functions, which you can do by creating bindings for them with "extern(C)". Which is my preference over Derelict, as it is simpler and makes things easier to use (for me). Otherwise you are probably going to run into a lot of issues as no one is really testing LDC2 for android. The people that are testing it aren't testing it the traditional way you build an app with the Android SDK. Oh, could you tell me more about it? what's different about "extern(C)" and "DerelictSDL2"? i known, a DerelictSDL2 is a binding library for D and that's support "Dynamic" and "Static". need a help and more info! have you got some work(eg. source, project) about it? otherwise, can you tell me any link about it ? extern(C) is a feature, Derelict are libraries. https://dlang.org/spec/interfaceToC.html You can use Derelict "static" to the same effect I think, but they way they achieve it doesn't play well with auto completion and such.
Re: Could you anybody using DerelictSDL2 on Android?
On Tuesday, 7 August 2018 at 12:05:33 UTC, zhani wrote: howdy :-) can anybody use sdl2 on android? first, i got a ldc2 for android. i just followed here on windows: https://wiki.dlang.org/Build_D_for_Android#Windows so i could compile a sieve.d but didnt run it on android yet. then next? wut can i try for using DerelictSDL2 on android? and this guide didn't use dub. how can i intergradted with ldc2 for android? pls be advised me. regards, You can use SDL2 for Android, you don't need DerelictSDL2 either. You just need a way to call the SDL2 functions, which you can do by creating bindings for them with "extern(C)". Which is my preference over Derelict, as it is simpler and makes things easier to use (for me). Otherwise you are probably going to run into a lot of issues as no one is really testing LDC2 for android. The people that are testing it aren't testing it the traditional way you build an app with the Android SDK.
Re: Give DLS a try
On Thursday, 9 August 2018 at 13:02:47 UTC, Laurent Tréguier
wrote:
On Thursday, 9 August 2018 at 12:42:45 UTC, Domain wrote:
I just give it a try in visual studio code, but I got errors:
[Error - 20:39:54] Starting client failed
Error: Unsupported server configuration {
"command": ""
}
at _getServerWorkingDir.then.serverWorkingDir
(C:\Users\Domain-Work\.vscode\extensions\laurenttreguier.vscode-dls-1.6.3\node_modules\vscode-languageclient\lib\main.js:356:35)
at
Now that looks exactly like the bug I thought I had gotten rid
of...
The bug was that on Windows, the bootstrap program could exit
before the symbolic link to dls.exe was created, so the
extension was left without anything to launch.
Does it continue like this after reloading VSCode's window ?
Creating symlinks requires admin rights on Windows. In order to
do that I'm launching a powershell command to bring up the User
Account Control popup.
I'm no Windows expert, so on some machines it could fail due to
some strict policy about powershell execution, or simply not
having the possibility to gain admin rights.
I was thinking about working around that problem in the next
version; requiring admin rights for something like this is
obviously not really optimal.
Yah that's what I was getting. You should possibly find another
way other than symbolic links. I don't think you'll get access to
admin rights unless you restart VS Code with them.
Re: Give DLS a try
On Wednesday, 8 August 2018 at 07:57:49 UTC, Laurent Tréguier wrote: On Wednesday, 8 August 2018 at 07:25:57 UTC, Tab wrote: I find DLS to be very stable Ironically, as the developer of DLS, I'm not sure if it should be considered as stable. I've had quite a number of crashes myself, sometimes even seemingly right at startup :/ Although the latest version does fix a crash that was happening during garbage collection, so now it might be more stable. (Fun fact: since garbage collection always happens at least when the program exits, it was technically crashing 100% of the time before) I created a long list of features I'd like to see in D IDE. Hopefully some of them is being worked on. I have some things to fix first, but they will be worked on at some point; finding all references to a symbol especially is something that interests me. Code-d overcomplicates things I find though. I can't even build it, there's so many dependencies attached to it that it isn't worth looking through to even find which one is causing the build issue. Let alone there's a restriction that it can only build 32-bit. Also can't be built with LDC2 cause of the dependencies is trying to build a 64-bit binary even though the arch is set to 32-bit. It's a mess. DLS took no time at all to build, nice and simple. Just one thing is installing the extension didn't create that symbolic link for me. And the plugin just silently passes an empty path if it can't find DLS. https://github.com/LaurentTreguier/vscode-dls/blob/master/src/extension.ts#L20
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 6 August 2018 at 20:35:37 UTC, Walter Bright wrote: On 8/6/2018 11:26 AM, tide wrote: What's your crossplatform workaround if I have a namespace named "version" or "package" ? See my reply to Rick Cattermole. https://digitalmars.com/d/archives/digitalmars/D/Is_there_any_good_reason_why_C_namespaces_are_closed_in_D_317277.html#N317507 But that's not currently implemented is it? Your proposed solution adds an exception to the rule that just increases complexity of the language. No where else does "__" remove itself from the name it is used with. With the syntax extern(C++, "...") it is more easily understood, no crazy exceptions need to be made. You also didn't mention your reasoning behind not including a way to use const pointers to mutable data. That's a longstanding issue and has nothing to do with namespaces. That's just a deflection, we are talking about C++ name mangling, not namespaces. How do you mangle const pointers to mutable data in D to be able to call C++ ? You don't need to implement the feature, you just need a way to create the C++ mangle, which there is none. The only way is to change C++ code, like you said, telling people to rewrite their code is never, ever going to work.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 5 August 2018 at 23:28:06 UTC, Walter Bright wrote:
On 8/4/2018 12:45 AM, Manu wrote:
[...]
I get it, Manu, you don't find my arguments compelling. You've
put these forth before, and I could repeat myself rebutting
each. I expect we're at a dead end with that.
But the fact remains, I've shown both you and Atila how to make
things work for you, in a hygienic manner, with the language as
it is now. For you, it's adding an alias declaration. For
Atila, it's a couple lines of boilerplate dpp can add, without
disrupting dpp's internal design.
What's your crossplatform workaround if I have a namespace named
"version" or "package" ?
extern(C++, version) // error
{
void foo();
}
extern(C++, package) // error
{
void bar();
}
You also didn't mention your reasoning behind not including a way
to use const pointers to mutable data. The only workaround that
exists currently is to rewrite C++ code, which you stated wasn't
a valid solution you considered for extern(C++).
I understand you don't want to type in the alias declaration.
May I suggest using Atila's dpp? Then you won't have to even
look at the output. I also expect that your use cases can help
make dpp better, and that would be good for all of us.
---
P.S. I have no experience with dpp and how it is used. But my
experience with translators is that nobody expects to nor wants
to look at its output. They just want it to work. And it seems
a fact of life that the output of machine translation resists
being purty, because what's purty in A never looks purty in B.
How can you suggest DPP then go on to say you've never even used
it or know how it is even used?
Re: DMD installation prompts "Windows protected your PC"
On Monday, 6 August 2018 at 14:13:02 UTC, Timoses wrote: Thanks Windows, not! Since our department switched to Windows 10 I'm now unable to install DMD. To make it even worse, there's no way I see to install a virtual machine any more (VirtualBox or VMWare) since they collide with Hyper-V. I've disabled Hyper-V, but it seems there can be a lot of things using it around one's back anyway. So... No more D programming for me it seems. Very sad. Of course there might be ways around it such as including the IT department. However, I use D for such niche use cases that I believe its unlikely to succeed. Any bright minds have better ideas? You can upload the files that get installed somewhere, I don't think the installer does anything other than setup the sc.ini file which seems to have become rather basic.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Friday, 3 August 2018 at 21:20:37 UTC, Walter Bright wrote: If we want to support interfacing with C++, we have to support badly written C++, because that is the NORMAL case. Telling them their code is and that they should rewrite it in order to work with D is never, ever going to work. On another note, why aren't const pointers to mutable data supported then? Anytime I need to write a wrapper for a function that has a parameter "T* const" I have to rewrite the C++ code cause there's no cross-platform way to mangle and call that function from D. Does this mean you are for const pointers in D now or is trying to make D into C++ unreasonable now ?
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Saturday, 4 August 2018 at 01:45:44 UTC, Laeeth Isharc wrote: On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote: The difference is they would have to rework their existing code. If you are writing D source code bindings for your code, then you are essentially writing new code. You don't have to worry about backwards compatibility. Why would you write bindings if the computer can do it for you, better, faster and consistently? With the current tools the ones that generate D files to be used aren't very good. They evaluate Macros based on the current implementation, so if there's a define MACHINE_X86 or MACHINE_x64, those macro and #if's will be evaluated based on the current system running the tool instead of generating equivalent version() statements. That's the idea behind DPP. You can just #include C headers and they will be translated before compile time. This is very helpful with projects like HDF5 that consider it acceptable in a minor release to replace a function with a macro. Wrappers are a bit different. In time C++ will follow. I wouldn't call that the same thing as what generally defines a wrapper. It's a different concept that does the work at compiler time. If I remember correctly Clang has something similar, where two languages can call each other once they have been compiled to Clang's intermediate format. Or at least it was something that was being worked on a while ago, never used it though. Not only that, who do you think even writes bindings for libraries? Most bindings are done by the community for libraries to other languages. How many companies do you know have bindings for their C/C++ libraries for D, that maintains them? We do for a few things - for other peoples' libraries not our own. But it would be better not to have to write bindings at all. It would be, but I don't think it'll ever be 100% and will require manual intervention. damn hell no. That's what modules are for. So why are you trying to implement namespaces in D under the guise of C++ name mangling. I don't think either Manu or Atila want to be able to sneak in namespaces by the backdoor. They just want to be able easily to control namespace mangling of C++ linkage symbols. Never said they did, but that's what Walter and the current implementation seem to indicate. I'd rather just have extern(C++) be what extern(C++) and extern(D) do, just change the name mangling, not try to emulate some features of namespaces like it currently does. What extern(C++) should be used for is allowing you to call C++ code from D, not to be able to format C++ code into D. The only problem you have with breaking code up into multiple files is that it isn't 1:1. That's not a technical problem, it's a problem of conflicting personal opinion. If it's not 1:1, who cares? If some some odd reason you have two namespaces in one file in C++, odds are they are probably separated in that one file anyway. If not and for some reason the the code has multiple namespace definitions smashed together into one file, flip-floping between namespaces. That's not D's problem to fix the project's poor organization method. For automatically translated bindings I think that the request is not unreasonable because there's considerable value in being able to just #include C++ headers as you can already with C headers and just call the C++ code from D. D doesn't have libraries? Well it's got 1500 on code.dlang.org plus C and C++ libraries. What is it you think is missing? That's a good retort! I understand from Atila present choice just makes it a lot more complicated, not impossible. The only person I've seen that wants this is Walter. I haven't seen anyone else show interest in wanting a 1:1 correlation. It's unreasonable, D isn't C++ nor should it be trying to strive to be C++. Where are const pointers? Where are default constructors for structs that make structs not POD anymore, that changes the calling convention used in C++ (on Windows at least).
Re: Adding more projects to the Project Tester
On Friday, 6 July 2018 at 03:19:44 UTC, Seb wrote: So learning from the recent Vibe.d regression fiasco (we temporarily disabled a subconfiguration in Vibe.d and promptly got a regression in 2.081), I think we should try to add more projects to the Project Tester. The current list is here: https://github.com/dlang/ci/blob/master/vars/runPipeline.groovy#L443 Any suggestions? Why should I add my project to the Project Tester? -- Once a project is added to the Project Tester, DMD can't regress on it anymore as for every PR at dmd, druntime, phobos, tools and dub the testsuite of the added projects are run. How does the Project Tester work? - - By default, it will run the same commands as Travis would do. Although, if necessary, custom commands can be used too. - It will checkout the latest, stable git tag Requirements - moderately popular or was prone to regressions in the past - rather easy to build (i.e. you don't need to download and recompile clang) - no flaky testsuite (random errors in the testsuite due to network connectivity shouldn't happen. Though there's `DETERMINISTIC_HINT=1` set, s.t. you could disable such parts of your testsuite) - reachable author or development (if there's ever a case where we need to push changes via a trivial PR to the repo, it shouldn't sit in the queue for weeks) Include Windows as part of the testing done.
