Re: Note from a donor
On 10/27/2017 1:06 AM, Jacob Carlborg via Digitalmars-d wrote: On 2017-10-27 04:34, Brad Roberts wrote: Actually, one of the 3 macos boxes is using stock xcode tooling these days. I specifically went that direction when setting up a new system that replaced one that died on me (well, it boots but if I actually _use_ it it crashes, sigh). So, but on the older osx releases (not positive the exact versions off the top of my head) there were issues that forced us back to an old gcc version rather than the default clang compiler. I haven't been using GCC in years and I never had any problems with compiling DMD using Clang. The issues weren't compiling dmd but passing the full test suite. Both are required.
Re: Note from a donor
On Saturday, 28 October 2017 at 01:42:52 UTC, evilrat wrote: At a minimum you'd better try WinSDK first, there should be all necessary tools. After all it is system's development kit, not some fancy junk. The Windows SDK hasn't included compilers since Windows 7. Visual C++ is available as a NuGet package, which is just a .zip file. The 2017 version is ~650MB: https://www.nuget.org/packages/VisualCppTools.Community.VS2017Layout/ Unfortunately, it doesn't include the SDK headers or libs. Bob
Re: Note from a donor
On Saturday, October 28, 2017 03:45:02 evilrat via Digitalmars-d wrote: > On Saturday, 28 October 2017 at 03:00:16 UTC, Jonathan M Davis > > wrote: > > ... I rewrote our build stuff so that it was all generated with > > cmake. Then editing the build was the same on both platforms, > > and building was _almost_ the same. I didn't even need to open > > up VS anymore - for configuration or for building. It was > > glorious. > > > > I expect that it's the sort of thing that would annoy many > > Windows devs though, because the fact that the VS files were > > generated meant that you couldn't make changes in VS and have > > it stick (which from my perspective was great, but for a > > hardcore Windows person, probably not so much). > > Never heard of anyone who is annoyed by cmake/vs combo. Quite the > opposite, there is an issue with "true" hardcore Linux devs who > cannot into cmake. They stuck with autotools, which is not an > option on Windows. This especially true for any C projects, and > also the fact that we stuck with C89 on Windows. And another side > of the problem is commercial middleware carp which distributed as > VS projects only and only supports some "ancient" VS version, > though I can't remember such examples. The problem would be Windows devs who wanted to change any settings inside of VS. I don't think that it would have even worked to retain the file that's specific to the user, since it sits next to the normal VS project files, which were in a directory that would be deleted whenever a full rebuild was done. So, as long as you didn't need to configure any aspect of VS where the settings were saved in a file in that directory, you'd be fine, but something like your local debug settings for the project would probably be lost on a regular basis. So, while someone who's more of a Linux dev is likely to be very much in favor of using cmake to control everything, a hardcore Windows dev who uses VS on a regular basis might not view it the same way. Personally, I think that most anyone dealing with VS would be better off using cmake to generate its project files than using VS to control that stuff (it is _so_ easy to do stuff like make it so that the debug and release builds are not in sync if you're configuring VS directly), but I wouldn't have dared to suggest it at my last job, which was a Windows-only shop. The folks there were too Windows-centric and too set in their ways for that to have gone over well at all, even though it likely would have fixed a number of our build-related problems. - Jonathan M Davis
Re: Note from a donor
On Saturday, 28 October 2017 at 03:00:16 UTC, Jonathan M Davis wrote: ... I rewrote our build stuff so that it was all generated with cmake. Then editing the build was the same on both platforms, and building was _almost_ the same. I didn't even need to open up VS anymore - for configuration or for building. It was glorious. I expect that it's the sort of thing that would annoy many Windows devs though, because the fact that the VS files were generated meant that you couldn't make changes in VS and have it stick (which from my perspective was great, but for a hardcore Windows person, probably not so much). Never heard of anyone who is annoyed by cmake/vs combo. Quite the opposite, there is an issue with "true" hardcore Linux devs who cannot into cmake. They stuck with autotools, which is not an option on Windows. This especially true for any C projects, and also the fact that we stuck with C89 on Windows. And another side of the problem is commercial middleware carp which distributed as VS projects only and only supports some "ancient" VS version, though I can't remember such examples.
Re: Note from a donor
On Saturday, October 28, 2017 02:50:39 codephantom via Digitalmars-d wrote: > On Saturday, 28 October 2017 at 01:08:57 UTC, Mengu wrote: > > looks like d has a long way to go on freebsd as well. > > I've had no issues with D in FreeBSD at all... > > ...and it's been a really smooth transition to D...so far... > > I have D, Postgresql, and static C/C++ bindings working just > fine...and that's really all I need..for now. > > btw. The FreeBSD platform isn't even mentioned here: > > https://insights.stackoverflow.com/survey/2017#technology-platforms > > So I'm just glad it works at all..otherwise I'd have to choose > between not using D, or using another platform...and neither > choice is appealing. FreeBSD generally works well, but it hasn't generally been handled quite as well as Linux - in part because of the auto-tester, and in part because a lot fewer people around here use FreeBSD. I've sometimes had problems, because the autotester currently uses FreeBSD 8.4 (IIRC), and so breakage on recent versions of FreeBSD aren't always caught (though we're working towards getting the autotesters updated - there are a few tests that currently fail with newer versions of FreeBSD but not many). 32-bit in particular has more problems, since I think that most of us who do use FreeBSD are running the 64-bit version, so some of the problems weren't caught until Brad tried to upgrade the auto-tester. Things are made worse for me by the fact that I run TrueOS, which is essentially a vetted snapshot of the development version of FreeBSD, so things break from time to time. At the moment, I'm hoping that https://issues.dlang.org/show_bug.cgi?id=17596 gets sorted out before December, since the next update for the TrueOS stable branch is coming out then, and I expect that it will have the inode64 changes, which breaks dmd and pretty much any D program that deals with files. However, anyone running FreeBSD 11.x is in for a much smoother ride, and the fact that a few of us use TrueOS or FreeBSD CURRENT allows such problems to be caught before it becomes a problem for the release versions of FreeBSD. Getting the auto-tester updated will definitely help though. - Jonathan M Davis
Re: Note from a donor
On Saturday, October 28, 2017 02:48:00 evilrat via Digitalmars-d wrote: > On Saturday, 28 October 2017 at 02:30:50 UTC, codephantom wrote: > > On Saturday, 28 October 2017 at 01:42:52 UTC, evilrat wrote: > >> Since you already on that wave, can you test Windows SDK > >> installation and make DMD's sc.ini use the SDK? > > > > nope. not me. I've had enough ;-) > > > > I use FreeBSD. > > > > I just wanted so see what effort I had to undertake to compile > > D into a 64bit binary on Windows - presuming I didn't want > > visual studio too... > > > > Needless to say...I'm not impressed. And I'll leave it at that. > > No problem. Actually there is a recent post in blog about D and > VS where WinSDK is mentioned, might be interested to read - > https://dlang.org/blog/2017/10/25/dmd-windows-and-c/ > > > Some clarifications - VS projects(at least MS one's, i.e. C++ and > C#) are just xml 'build scripts' for msbuild.exe, which itself > don't have the knowledge about project or how to build them, it > is plugins that provides such knowledge to it. So in this sense > VS project properties editor is just a nice UI for editing build > scripts. And when one hit the build button in VS it is just > invokes msbuild with that script(project file). That's why we > have WinSDK, MSBuild tools, and VS as separate downloads, and VS > includes the former two. > More or less like that. This might be helpful for some users. At a previous job where we had both Linux and Windows builds of our libraries (though applications themselves tended to be single platform), I got so sick of dealing with VS and the builds not being consistent across platforms (since Linux used Makefiles, and those obviously had to be edited separately from the VS stuff) that I rewrote our build stuff so that it was all generated with cmake. Then editing the build was the same on both platforms, and building was _almost_ the same. I didn't even need to open up VS anymore - for configuration or for building. It was glorious. I expect that it's the sort of thing that would annoy many Windows devs though, because the fact that the VS files were generated meant that you couldn't make changes in VS and have it stick (which from my perspective was great, but for a hardcore Windows person, probably not so much). - Jonathan M Davis
Re: Note from a donor
On Saturday, 28 October 2017 at 01:08:57 UTC, Mengu wrote: looks like d has a long way to go on freebsd as well. I've had no issues with D in FreeBSD at all... ...and it's been a really smooth transition to D...so far... I have D, Postgresql, and static C/C++ bindings working just fine...and that's really all I need..for now. btw. The FreeBSD platform isn't even mentioned here: https://insights.stackoverflow.com/survey/2017#technology-platforms So I'm just glad it works at all..otherwise I'd have to choose between not using D, or using another platform...and neither choice is appealing.
Re: Note from a donor
On Saturday, 28 October 2017 at 02:30:50 UTC, codephantom wrote: On Saturday, 28 October 2017 at 01:42:52 UTC, evilrat wrote: Since you already on that wave, can you test Windows SDK installation and make DMD's sc.ini use the SDK? nope. not me. I've had enough ;-) I use FreeBSD. I just wanted so see what effort I had to undertake to compile D into a 64bit binary on Windows - presuming I didn't want visual studio too... Needless to say...I'm not impressed. And I'll leave it at that. No problem. Actually there is a recent post in blog about D and VS where WinSDK is mentioned, might be interested to read - https://dlang.org/blog/2017/10/25/dmd-windows-and-c/ Some clarifications - VS projects(at least MS one's, i.e. C++ and C#) are just xml 'build scripts' for msbuild.exe, which itself don't have the knowledge about project or how to build them, it is plugins that provides such knowledge to it. So in this sense VS project properties editor is just a nice UI for editing build scripts. And when one hit the build button in VS it is just invokes msbuild with that script(project file). That's why we have WinSDK, MSBuild tools, and VS as separate downloads, and VS includes the former two. More or less like that. This might be helpful for some users.
Re: Note from a donor
On Saturday, 28 October 2017 at 01:42:52 UTC, evilrat wrote: Since you already on that wave, can you test Windows SDK installation and make DMD's sc.ini use the SDK? nope. not me. I've had enough ;-) I use FreeBSD. I just wanted so see what effort I had to undertake to compile D into a 64bit binary on Windows - presuming I didn't want visual studio too... Needless to say...I'm not impressed. And I'll leave it at that.
Re: What is wrong with core.stdc.signal ?
angel wrote: Core.stdc.signal.signal() requires that a signal handler function is "nothrow @nogc @system". These attributes impose quite a limitation - one cannot even print which signal was accepted. 'cause you CANNOT print in signal handler. you can do almost *nothing* in signal handler besides setting some variable. please, read the OS manuals about signals.
Re: Note from a donor
On Saturday, 28 October 2017 at 00:05:53 UTC, codephantom wrote: At a minimum, I had to download 3.5GB of VS build tools just so I could compile a 64 bit D program (and it took me almost a whole day to work out the correct process). At a minimum you'd better try WinSDK first, there should be all necessary tools. After all it is system's development kit, not some fancy junk. Is that a problem of D or VS? Is is it problem that D should accept, and just impose on it's users? VS is standard for C++ on Windows. Period. Not much to discuss here. Why we need MS native tools? Because D offers C++ FFI. See the connection? But who said that we compile/link using VS itself? And again, DMD installer offers to install whole VS most likely because on Windows there is not that much experienced devs in the team. So this probably overlooked. Also this is why there are some *core* features that never(or almost never) worked on Windows but works for ages on linux, such as "DLL support" or my favorite "type information across DLL/process boundaries"... Since you already on that wave, can you test Windows SDK installation and make DMD's sc.ini use the SDK?
Re: Note from a donor
On Friday, 27 October 2017 at 11:25:13 UTC, codephantom wrote: On Friday, 27 October 2017 at 05:20:05 UTC, codephantom wrote: That's it! I've had enough! 4 hours wasted! ok... I must have done something wrong.. But still, I started testing this whole process at 12:04pm today. It's now 10:23PM All I can say, it thank god I used FreeBSD ;-) pkg install ldc (a few seconds later, I can start compiling 64bit D code). looks like d has a long way to go on freebsd as well.
Re: Note from a donor
On Friday, 27 October 2017 at 19:44:49 UTC, Jerry wrote: This mentality is why D is pretty awful on Windows. Have read of this... then you will understand things better: https://dlang.org/blog/2017/10/25/dmd-windows-and-c/
Re: Note from a donor
On Friday, 27 October 2017 at 19:44:49 UTC, Jerry wrote: On Friday, 27 October 2017 at 13:15:38 UTC, codephantom wrote: The less the D language partakes in that stuff up.. the better D will be for it. This mentality is why D is pretty awful on Windows. It's bad enough that DMD doesn't release a 64-bit version on Windows but now you are advocating for the removal of the ability for it to generate 64-bit binaries as well! Yah that won't bring you 10 steps back. Ideals are nice and all, but some people still need to get shit done. This sort of mentality is hurting D, not helping it. Rubbish! And get you facts straight! Where did I advocate from the removal of the ability for D to generate 64-bit binaries? 64bit D on Windows, is a problem because of Windows. The fact that D cannot disentangle itself from the monstrosity known as Visual Studio, is a problem of Visual Studio. If you really want to get work done, then try wasting 10 hours of your time, trying to work out how to install VS, and all stuff that it depends on - you are even forced to upgrade your operating system too! At a minimum, I had to download 3.5GB of VS build tools just so I could compile a 64 bit D program (and it took me almost a whole day to work out the correct process). Is that a problem of D or VS? Is is it problem that D should accept, and just impose on it's users? Or should D find a better way? Which is the worse mentality? And VS destroys competition and imposes considerable and unacceptable requirements on its users. That is the only mentality you should be questioning.
What is wrong with core.stdc.signal ?
Core.stdc.signal.signal() requires that a signal handler function is "nothrow @nogc @system". These attributes impose quite a limitation - one cannot even print which signal was accepted. While if one imports this same function via "extern (C)" path, he can freely throw and allocate memory in the signal handler. And this actually makes sense, as the handler function is called on top of the stack of where the code was running when the signal popped in, so it's like calling a function. Why the limitation if it works ?
Re: Note from a donor
On Friday, 27 October 2017 at 13:15:38 UTC, codephantom wrote: The less the D language partakes in that stuff up.. the better D will be for it. This mentality is why D is pretty awful on Windows. It's bad enough that DMD doesn't release a 64-bit version on Windows but now you are advocating for the removal of the ability for it to generate 64-bit binaries as well! Yah that won't bring you 10 steps back. Ideals are nice and all, but some people still need to get shit done. This sort of mentality is hurting D, not helping it.
Re: Note from a donor
On Friday, October 27, 2017 09:46:21 Kagamin via Digitalmars-d wrote: > On Friday, 27 October 2017 at 01:40:07 UTC, Jonathan M Davis > > wrote: > > The problem is that to reasonably interact with the rest of the > > Windows C/C++ ecosystem, you're pretty much stuck using > > Microsoft's linker. If we can get that without pulling in all > > of VS, all the better, but without the linker, we can't link > > with most existing C/C++ code, which is a big problem. > > How so? curl is an import library for libcurl.dll, mingw handles > import libraries just fine, same for zlib and mxWidgets. But most > of the time you only need to link phobos and some code from dub > and that's all. I don't know anything about import libraries, but we need to be able to link against any C/C++ libraries that someone is doing with VS. If mingw can do that, then it could be an option, though a lot more Windows devs are going to have VS than mingw, and it's my understanding that you have to pull in a fair bit of stuff for mingw (though presumably, it's not as big as VS), so I don't know how much of an improvement that would be. But the key thing here is that it needs to be easy and straightforward to link against the C/C++ libraries that are generally available for Windows and which folks are writing for their own projects, and that means being compatible with Microsoft and its linker. - Jonathan M Davis
Re: delete & its deprecation
On Friday, October 27, 2017 12:30:58 bauss via Digitalmars-d wrote: > Are there any plans to completely remove the delete keyword so > members of ex. a class can be called delete? Or is there still > code within DMD or Phobos that uses it? It's been the plan for ages that delete was to be deprecated, but no one has ever bothered to do it. Part of the problem has been that while it was possible to construct a class into memory allocated with something other than new and than destroy it later, it was actually pretty difficult to get right. If it weren't for that, I probably would have pushed for its removal ages ago. However, now that we have std.experimental.allocator, things have changed a bit, and it should be far more reasonable to get rid of delete. But still, someone has to actually go and deprecate it, and I think that it's more or less been forgotten. Nothing in Phobos uses delete, and it looks like the only place that uses delete in druntime is some unit tests. I doubt that any of the core D developers have done anything with delete in years, which would be part of why it's easily forgotten. I know that I tend to forget that it's even part of the language. - Jonathan M Davis
Re: Note from a donor
On Fri, Oct 27, 2017 at 05:35:17PM +, Kagamin via Digitalmars-d wrote: > On Wednesday, 25 October 2017 at 14:17:21 UTC, Jonathan M Davis wrote: > > The point still stands though that you have to be _very_ careful > > when implementing anything security related, and it's shockingly > > easy to do something that actually leaks information even if it's > > not outright buggy (e.g. the timing of the code indicates something > > about success or failure to an observer) > > Fun read: http://cr.yp.to/papers.html#cachetiming - a cache timing > attack on AES recovering full key. This flaw was accounted for in > Salsa and Chacha design. Yes, and this is exactly why I would not trust any D crypto implementation that hasn't been vetted by crypto experts. Nobody would think of such weaknesses when they're writing the code, unless they were already aware of such issues beforehand -- and I doubt many of us here would even be aware of half of the issues crypto implementors must work with on a regular basis. If even the openSSL folk didn't manage to avoid this exploit, we non-crypto people wouldn't even stand a chance. Of course, the larger picture is that crypto algorithms are only a small (albeit critical) part of a larger cryptosystem, and oftentimes the weaknesses come not from the algorithm itself but from issues affecting the other parts of the cryptosystem. You can have the best, most unbreakable crypto (or whatever else) algorithm in your hand, but if you use it incorrectly or just carelessly, you'd still get exploited, and all that crypto strength would be for nought. T -- Insanity is doing the same thing over and over again and expecting different results.
Re: Note from a donor
On Wednesday, 25 October 2017 at 14:17:21 UTC, Jonathan M Davis wrote: The point still stands though that you have to be _very_ careful when implementing anything security related, and it's shockingly easy to do something that actually leaks information even if it's not outright buggy (e.g. the timing of the code indicates something about success or failure to an observer) Fun read: http://cr.yp.to/papers.html#cachetiming - a cache timing attack on AES recovering full key. This flaw was accounted for in Salsa and Chacha design.
Re: Note from a donor
On Friday, 27 October 2017 at 16:05:10 UTC, Kagamin wrote: (mainCRTStartup in crtexe.c) Or crt0.c
Re: Note from a donor
On Friday, 27 October 2017 at 14:20:04 UTC, MrSmith wrote: On Friday, 27 October 2017 at 09:56:25 UTC, Kagamin wrote: MinGW compiles import libraries from text .def files that are lists of exported symbols: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib64/ I will test dmd + lld + use .def files instead of .lib files With this the only missing piece will be the C startup code (mainCRTStartup in crtexe.c), though not sure where it's compiled.
Re: Note from a donor
On Friday, 27 October 2017 at 09:56:25 UTC, Kagamin wrote: MinGW compiles import libraries from text .def files that are lists of exported symbols: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib64/ I will test dmd + lld + use .def files instead of .lib files
Re: Note from a donor
On Friday, 27 October 2017 at 12:19:59 UTC, jmh530 wrote: It's in the install wiki Personally, VS is such a pain in the $$@#$# that I would remove any reference of it from the installer. i.e rather than the installer offering to install VS2013, just have the installer display a shortcut to the wiki, if the installer can't find vs. don't offer to install it..you'll almost certainly ruins the clients computer with all the various dependencies and crap that vs requires Let the wiki take care of it all. But gee...what a mess MS have made with VS...have a look at all these people complaining https://visualstudio.uservoice.com/forums/121579-visual-studio-ide/suggestions/17541385-please-make-iso-files-for-visual-studio-2017?page=1&per_page=20 I don't think trying to dominate the world of software development..with a single app...was a very good strategy. They've stuffed up big time! The less the D language partakes in that stuff up.. the better D will be for it.
delete & its deprecation
Are there any plans to completely remove the delete keyword so members of ex. a class can be called delete? Or is there still code within DMD or Phobos that uses it?
Re: Named arguments
On Friday, 27 October 2017 at 06:45:03 UTC, Jacob Carlborg wrote:
On 2017-10-25 16:58, jmh530 wrote:
You're passing the function arguments as template parameters.
Usually you want them to be able to be passed at run-time.
No problem:
$ cat main.d
import std.stdio;
void foo(args...)()
{
writeln(args);
}
void main(string[] args)
{
foo!(args);
}
$ dmd main.d
$ ./main foo bar
["./main", "foo", "bar"]
Color me surprised. Even the below compiles and runs without error
import std.stdio;
void foo(args...)()
{
writeln(args);
}
void main()
{
int x1 = 1;
int x2 = x1 + 1;
foo!(x1, x2);
}
Re: Note from a donor
On Friday, 27 October 2017 at 11:47:11 UTC, Andrei Alexandrescu wrote: On 10/27/17 3:46 AM, Jacob Carlborg wrote: I'm not saying Windows is special. I tried to use DMD and Visual Studio together, it didn't work that well. I did not use the DMD installation, I already had DMD installed (using DVM). I did not know the exact paths/environment variables to use for DMD to find the Visual Studio tool chain. I also recall finding it very difficult to find the download for the SDK, it was not included in the Visual Studio installation I used. This kind of stuff would need to be carefully written down with an eye for improving the experience. Any volunteers? Please help, thanks! -- Andrei It's in the install wiki https://wiki.dlang.org/Installing_DMD the problem (that I mentioned above) is that you have to know where to go to find it. It needs more prominence on the dlang site.
Re: Note from a donor
On 10/27/17 3:46 AM, Jacob Carlborg wrote: I'm not saying Windows is special. I tried to use DMD and Visual Studio together, it didn't work that well. I did not use the DMD installation, I already had DMD installed (using DVM). I did not know the exact paths/environment variables to use for DMD to find the Visual Studio tool chain. I also recall finding it very difficult to find the download for the SDK, it was not included in the Visual Studio installation I used. This kind of stuff would need to be carefully written down with an eye for improving the experience. Any volunteers? Please help, thanks! -- Andrei
Re: Note from a donor
On Friday, 27 October 2017 at 05:20:05 UTC, codephantom wrote: That's it! I've had enough! 4 hours wasted! ok... I must have done something wrong.. If I create an offline installation of the VS2017 buildtools, and then install the default 'Visual C++ build tools' selection, and then after that's installed, I install dmd (dmd-2.076.1.exe), then I can straight away compile D code with the -m64 option. But still, I started testing this whole process at 12:04pm today. It's now 10:23PM All I can say, it thank god I used FreeBSD ;-) pkg install ldc (a few seconds later, I can start compiling 64bit D code).
Re: Adding syntacti sugar for simple "readonly" attribute ?
On 2017-10-27 11:06, bauss wrote: Ahh yeah, that's true. I wasn't thinking that far I think head const [1] is what he's looking for. Similar to "final" in Java. [1] https://dlang.org/const-faq.html#head-const -- /Jacob Carlborg
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
On 2017-10-27 11:06, Kagamin wrote: Instance methods require this be passed by reference, which requires storage fiddling on the caller side. It's likely to disappear after inlining, but still. Ah, right. -- /Jacob Carlborg
Re: Note from a donor
On Thursday, 26 October 2017 at 21:38:25 UTC, MrSmith wrote: Would it be possible to create import libs that for all winapi/crt libs, and redistribute them? Will such libs be legal to redist? We have the tools (DMD/LLD), but the dependency on winsdk and VS libs is still there, unfortunatelly. MinGW compiles import libraries from text .def files that are lists of exported symbols: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-crt/lib64/
Re: Note from a donor
On Friday, 27 October 2017 at 01:40:07 UTC, Jonathan M Davis wrote: The problem is that to reasonably interact with the rest of the Windows C/C++ ecosystem, you're pretty much stuck using Microsoft's linker. If we can get that without pulling in all of VS, all the better, but without the linker, we can't link with most existing C/C++ code, which is a big problem. How so? curl is an import library for libcurl.dll, mingw handles import libraries just fine, same for zlib and mxWidgets. But most of the time you only need to link phobos and some code from dub and that's all.
Re: D for microservices
On 10/27/17 00:18, Jacob Carlborg wrote: On 2017-10-26 12:25, Adam Wilson wrote: My apologies, something rather the other direction. Instead of forcing compat with vibe.d, going to vibe.d and say: "here is our standard event-loop, it has everything you need, you'll need to use it for all the other goodness to work". I know others can make good arguments about why the vibe event-loop is insufficient, and I'll let them make them. My concern is not about the event loop, it's about asynchronous IO. vibe.d needs to use asynchronous IO and I assume that's regardless what kind of event loop implementation is used. Does all the existing database drivers that you want to use support asynchronous IO? PgSQL/MySQL/MSSQL all do, I think that covers about 90% of usage. IIRC Oracle does as well. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Note from a donor
On my Arch linux, it is really easy to install D. pacaur -Sy dlang // install dmd, ldc, and some other d tools pacaur -Sy visual-studio-code // install visual studio code, then I just install plugins from vscode So I can't see how this could be easier On Fri, Oct 27, 2017 at 11:09 AM, Bo via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Friday, 27 October 2017 at 05:20:05 UTC, codephantom wrote: > >> That's it! >> >> I've had enough! >> >> 4 hours wasted! >> > > Please try getting some editors going for D on Windows like Visual Studio > Code or Atom. That time wasted will skyrocket even more when you run into > one of the many issues. > > Linux installation is not much better. > > Brew ... took a hour to install but only had dmd not dub for some reason. > > The install script on the website: > > curl -fsS https://dlang.org/install.sh | bash -s dmd > > Well, that forces people to use: > > source ~/dlang/dmd-2.076.1/activate > > Each time they want to work with D. And it does not play nice with WSL > because it never gets loaded so trying to access dmd from outside the WSL > does not work. > > Download the Ubuntu/Debian deb file ... well, you better have google near > you. How hard is it to have "sudo dpkg -i DEB_PACKAGE" as a instruction > clearly on the website instead of only the deb file link... :) > > Or write in clear way simply: > > wget http://downloads.dlang.org/releases/2.x/2.076.1/dmd_2.076.1- > 0_amd64.deb > sudo dpkg -i dmd_2.076.1-0_amd64.deb >
Re: Note from a donor
On Friday, 27 October 2017 at 05:20:05 UTC, codephantom wrote: That's it! I've had enough! 4 hours wasted! Please try getting some editors going for D on Windows like Visual Studio Code or Atom. That time wasted will skyrocket even more when you run into one of the many issues. Linux installation is not much better. Brew ... took a hour to install but only had dmd not dub for some reason. The install script on the website: curl -fsS https://dlang.org/install.sh | bash -s dmd Well, that forces people to use: source ~/dlang/dmd-2.076.1/activate Each time they want to work with D. And it does not play nice with WSL because it never gets loaded so trying to access dmd from outside the WSL does not work. Download the Ubuntu/Debian deb file ... well, you better have google near you. How hard is it to have "sudo dpkg -i DEB_PACKAGE" as a instruction clearly on the website instead of only the deb file link... :) Or write in clear way simply: wget http://downloads.dlang.org/releases/2.x/2.076.1/dmd_2.076.1-0_amd64.deb sudo dpkg -i dmd_2.076.1-0_amd64.deb
Re: Adding syntacti sugar for simple "readonly" attribute ?
On Friday, 27 October 2017 at 06:49:47 UTC, Jacob Carlborg wrote:
On 2017-10-27 01:04, bauss wrote:
The first example would not equal the second, because you
could set bar from anywhere within the module.
Immutable will already do your behavior.
class Foo
{
immutable string bar;
this(string baz)
{
bar = baz;
}
}
That only works for primitive types. For anything else (like a
class or struct) you won't be able to modify the internal
state. While with the with the initial example you can.
Ahh yeah, that's true. I wasn't thinking that far
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
On Friday, 27 October 2017 at 07:36:45 UTC, Jacob Carlborg wrote: On 2017-10-26 12:42, Kagamin wrote: You mean non-member functions are preferred? I encountered this more from performance point: especially in case of small structures like Point it would be more beneficial to pass them by value than by reference, which can be achieved by extension methods, but then you need to import the respective module to have those extension methods available. Adding methods to a struct will not increase its size. Instance methods require this be passed by reference, which requires storage fiddling on the caller side. It's likely to disappear after inlining, but still.
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
On Thursday, 26 October 2017 at 23:29:24 UTC, Walter Bright wrote: The point is that functions that do not need access to private fields should NOT be part of the class. Most of the discussion here is based on the idea that those functions should still be semantically part of the class, even if not physically. That idea should be revisited. Why should they be semantically part of the class? Because it's functionality of the class. If it's not available, it will be reimplemented and duplicated. C++ doesn't have such problem, because in a way all imports are public there so you have no chance to separate a function from type.
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
On Thursday, 26 October 2017 at 12:19:33 UTC, Steven
Schveighoffer wrote:
D's lookup rules fail miserably when it comes to templates:
mod1.d:
auto callFoo(T)(T t)
{
return t.foo;
}
mod2.d:
struct S
{
int x;
}
int foo(S s) { return s.x * 5; }
void main()
{
auto s = S(1);
assert(s.foo == 5);
assert(s.callFoo == 5); // can't compile
}
Would be nice to have a way around this. Not sure what it would
look like.
Assuming you don't want to change the original struct, this can
be worked around by making a wrapper type using alias this. I
think that's logical because you have to be explicit about which
foreign functions you want the imported algorithm to see. There
would be a function hijacking problem otherwise.
What is the catch here, is that alias this won't solve cases
where the free function takes a reference to the wrapped type or
returns it.
Re: Note from a donor
On Tuesday, 24 October 2017 at 13:20:10 UTC, Andrei Alexandrescu wrote: A person who donated to the Foundation made a small wish list known. Allow me to relay it: * RSA Digital Signature Validation in Phobos * std.decimal in Phobos * better dll support for Windows. Andrei std.decimal has been on the review list for quite some time: https://wiki.dlang.org/Review_Queue
Re: Note from a donor
On 2017-10-26 00:46, Adam Wilson wrote: I am one-hundred-ten percent in agreement with Mr. Teoh here. Even .NET Framework and Core forward to the highly vetted system crypto API's (SChannel on Windows and OpenSSL on Linux/macOS). If you need RSA crypto in D, pull in OpenSSL. I think we should go with what the system provides. Apple abandoned OpenSSL years ago. It's still shipping with the operating system but if you're using Apple's APIs you're not using OpenSSL, as far as I know. Several BSD variants and Alpine Linux [1] are using LibreSSL, a fork of OpenSSL. Blindly going with only OpenSSL is not a good idea. [1] https://en.wikipedia.org/wiki/LibreSSL#Adoption -- /Jacob Carlborg
Re: Note from a donor
On 2017-10-27 04:34, Brad Roberts wrote: Actually, one of the 3 macos boxes is using stock xcode tooling these days. I specifically went that direction when setting up a new system that replaced one that died on me (well, it boots but if I actually _use_ it it crashes, sigh). So, but on the older osx releases (not positive the exact versions off the top of my head) there were issues that forced us back to an old gcc version rather than the default clang compiler. I haven't been using GCC in years and I never had any problems with compiling DMD using Clang. -- /Jacob Carlborg
Re: So why double to float conversion is implicit ?
On Tuesday, 24 October 2017 at 15:29:38 UTC, Basile B. wrote:
On Saturday, 21 October 2017 at 20:17:12 UTC, NX wrote:
I was working on some sort of math library for use in
graphical computing and I wrote something like this:
const float PiOver2 = (atan(1.0) * 4) / 2;
Interestingly enough, I realized that atan() returns double
(in this case) but wait, it's assigned to a float variable!
Compiler didn't even emit warnings, let alone errors.
I see no reason as to why would this be legal in this century,
especially in D.
So can someone tell me what's the argument against this?
Why type conversions differ between integral and floating
types?
Why can't I assign a long to an int but it's fine when
assigning double to float?
I think this is a serious topic and needs clarification.
I think that the rationale for allowing that is that you can
feed the FPU with high precision values to get a better
internal accuracy (temp values stored in ST0-ST7). At the end,
even if there's a truncation the result is more accurate that
if you would have feed the FPU with parameters of the same size
as the result.
I'm currently using the compiler version that includes the
warning:
https://github.com/dlang/dmd/pull/7240
and discovered that it's actually not only a problem of
truncation.
For
```
float foo(float f)
{
f *= 0.5;
return f;
}
```
DMD generates
```
push rbp
mov rbp, rsp
cvtss2sd xmm1, xmm0 ; promotion
movsd xmm2, qword ptr []
mulsd xmm1, xmm2
cvtsd2ss xmm0, xmm1 ; truncation
pop rbp
ret
```
as you can see, the parameter is promoted to double because of
the constant and then the result is converted back to single. The
two instructions obviously disappear when the constant get the
float suffix, and the compiler warning helped you to save a few
cycles.
Re: Note from a donor
On 2017-10-26 13:32, Andrei Alexandrescu wrote: A wizard-style installation with links to things and a good flow might help a lot here. Is that possible? -- Andrei Xcode can only, officially, be obtained from the Mac App Store or Apple's developer web site, which a (free) account is required to be able to access. I guess it's possible to link to the Mac App Store Xcode page, but I don't think it's possible to automatically download Xcode. Then the user usually need to install the Xcode command line tools as well. -- /Jacob Carlborg
Re: Note from a donor
On 2017-10-26 12:16, Adam Wilson wrote: How many though? It's not like I've been counting, but more than one. Also, we have to do it for macOS, why is Windows special? The macOS setup was just as hard. Download two large packages (XCode+Cmd tools), install, and done. I'm not saying Windows is special. I tried to use DMD and Visual Studio together, it didn't work that well. I did not use the DMD installation, I already had DMD installed (using DVM). I did not know the exact paths/environment variables to use for DMD to find the Visual Studio tool chain. I also recall finding it very difficult to find the download for the SDK, it was not included in the Visual Studio installation I used. I did not have these problems on macOS, but perhaps that's just me, I'm not a Windows developer. -- /Jacob Carlborg
Re: Required Reading: "How Non-Member Functions Improve Encapsulation"
On 2017-10-26 12:42, Kagamin wrote: You mean non-member functions are preferred? I encountered this more from performance point: especially in case of small structures like Point it would be more beneficial to pass them by value than by reference, which can be achieved by extension methods, but then you need to import the respective module to have those extension methods available. Adding methods to a struct will not increase its size. -- /Jacob Carlborg
Re: D for microservices
On 2017-10-26 12:25, Adam Wilson wrote: My apologies, something rather the other direction. Instead of forcing compat with vibe.d, going to vibe.d and say: "here is our standard event-loop, it has everything you need, you'll need to use it for all the other goodness to work". I know others can make good arguments about why the vibe event-loop is insufficient, and I'll let them make them. My concern is not about the event loop, it's about asynchronous IO. vibe.d needs to use asynchronous IO and I assume that's regardless what kind of event loop implementation is used. Does all the existing database drivers that you want to use support asynchronous IO? -- /Jacob Carlborg
