Re: Note from a donor
On Friday, 17 November 2017 at 23:31:07 UTC, David Nadlinger wrote: On Friday, 17 November 2017 at 02:01:41 UTC, solidstate1991 wrote: It's filled with Assembly code, and otherwise not very readable. Would need a lot of work, I don't think it would worth it. Let's hope that MS will allow us to distribute a linker alongside DMD. The more promising avenue would probably be to distribute LLD with DMD. This still leaves the system library licensing to deal with, but if I remember correctly, one of the usual suspects (Rainer? Vladimir?) was working on generating them from MinGW headers. — David You still need C startup code.
Re: Note from a donor
On Friday, 17 November 2017 at 23:35:49 UTC, MrSmith wrote: On Friday, 17 November 2017 at 23:31:07 UTC, David Nadlinger wrote: The more promising avenue would probably be to distribute LLD with DMD. This still leaves the system library licensing to deal with, but if I remember correctly, one of the usual suspects (Rainer? Vladimir?) was working on generating them from MinGW headers. — David Btw, what about LIBC from DMC, is it open source now too? Can we use it with DMD? No, but there is some talk of doing something about it in a more recent thread: http://forum.dlang.org/post/ovj98g$26r9$1...@digitalmars.com
Re: Note from a donor
On Friday, 17 November 2017 at 23:31:07 UTC, David Nadlinger wrote: The more promising avenue would probably be to distribute LLD with DMD. This still leaves the system library licensing to deal with, but if I remember correctly, one of the usual suspects (Rainer? Vladimir?) was working on generating them from MinGW headers. — David Btw, what about LIBC from DMC, is it open source now too? Can we use it with DMD?
Re: Note from a donor
On Friday, 17 November 2017 at 23:31:07 UTC, David Nadlinger wrote: The more promising avenue would probably be to distribute LLD This still leaves the system library licensing to deal with, but if I remember correctly, one of the usual suspects (Rainer? Vladimir?) was working on generating them from MinGW headers. Most of the core.sys.windows package is now based on the win32 package from the bindings project. The license header of the D files used from there claim that they were placed in the public domain, and I believe they were originally translated from the MinGW headers.
Re: Note from a donor
On Friday, 17 November 2017 at 02:01:41 UTC, solidstate1991 wrote: It's filled with Assembly code, and otherwise not very readable. Would need a lot of work, I don't think it would worth it. Let's hope that MS will allow us to distribute a linker alongside DMD. The more promising avenue would probably be to distribute LLD with DMD. This still leaves the system library licensing to deal with, but if I remember correctly, one of the usual suspects (Rainer? Vladimir?) was working on generating them from MinGW headers. — David
Re: Note from a donor
On Wednesday, 15 November 2017 at 04:34:09 UTC, Walter Bright wrote: On 11/14/2017 7:15 PM, solidstate1991 wrote: Walter Bright: What's the licensing state of DMC and OPTLINK? Boost Can it made open-source? Yes. If yes, we should patch in a COFF32/64 support, maybe even port it to D for easier development. I can spend some of my time working on the DLL support if needed. You're welcome to do it, it's something I've been meaning to do anyway. Optlink will never support MsCoff, you'll realize that when you look at the source :-( It's filled with Assembly code, and otherwise not very readable. Would need a lot of work, I don't think it would worth it. Let's hope that MS will allow us to distribute a linker alongside DMD.
Re: Note from a donor
On Sunday, 5 November 2017 at 14:19:11 UTC, MrSmith wrote: On Saturday, 4 November 2017 at 08:16:16 UTC, Joakim wrote: I was intrigued by someone saying in this thread that Go supports Win64 COFF out of the box, so I just tried it out in wine and indeed it works with their hello world example. Running "go build -x" shows that they ship a link.exe for Win64 with their Win64 zip, guess it's the Mingw one? Does Go need WinSDK though? It looks like integration with lld was fixed in ldc 1.5 release.
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: * better dll support for Windows. Andrei This should be better sent to Walter rather then here.
Re: Note from a donor
On Sunday, 5 November 2017 at 14:19:11 UTC, MrSmith wrote: On Saturday, 4 November 2017 at 08:16:16 UTC, Joakim wrote: I was intrigued by someone saying in this thread that Go supports Win64 COFF out of the box, so I just tried it out in wine and indeed it works with their hello world example. Running "go build -x" shows that they ship a link.exe for Win64 with their Win64 zip, guess it's the Mingw one? Does Go need WinSDK though? Not for the hello world sample I tried in wine, maybe you need to get some libraries for other stuff, dunno.
Re: Note from a donor
On Saturday, 4 November 2017 at 08:16:16 UTC, Joakim wrote: I was intrigued by someone saying in this thread that Go supports Win64 COFF out of the box, so I just tried it out in wine and indeed it works with their hello world example. Running "go build -x" shows that they ship a link.exe for Win64 with their Win64 zip, guess it's the Mingw one? Does Go need WinSDK though?
Re: Note from a donor
On Saturday, 4 November 2017 at 02:33:35 UTC, Computermatronic wrote: On Friday, 3 November 2017 at 18:26:54 UTC, Joakim wrote: On Friday, 3 November 2017 at 18:08:54 UTC, 12345swordy wrote: On Friday, 3 November 2017 at 17:25:26 UTC, Joakim wrote: Most programmers will one day be coding on mobile devices, though I admit I'm in a small, early-adopting minority now: http://bergie.iki.fi/blog/six-weeks-working-android/ A blog post is not evidence that the majority of programmers will be coding on mobile devices. Yes, but it is evidence of what I said, that "I'm in a small, early-adopting minority now." I don't know how you expect evidence for something that _will_ happen, it's a prediction I'm making, though based on current, rising trends like all those in this feed: https://mobile.twitter.com/termux Can we please get back on topic please? Yes, it is as simple as changing the topic up top back to the original, like I have now and you didn't, and discussing something else. You don't have to read messages that were marked as OT, like mine were, nobody's making you. Whether or not windows is 'dying' is irrelevant, since it is not going to die out as a development platform for at least the next 5 years. I, like many other windows users, want to be able to compile 64bit binaries in windows, without having to download and install the bloated and time consuming to download and install Visual Studio. I do most of my programming in Sublime Text, and frequently re-install windows. This may not be the case for many windows users of D, but clearly many windows users of D would like to be able to compile x64 out of the box. I was intrigued by someone saying in this thread that Go supports Win64 COFF out of the box, so I just tried it out in wine and indeed it works with their hello world example. Running "go build -x" shows that they ship a link.exe for Win64 with their Win64 zip, guess it's the Mingw one? If you want something similar for the D compiler packages for Win64, I suggest you file a bugzilla issue, as that's where the core team and other D devs look for stuff to do: https://issues.dlang.org The more info you have about the linker Go is using, the better. Best if you just submit a pull request for dmd or its installer, making it use this other linker so that VS is not needed: https://github.com/dlang/dmd/pulls https://github.com/dlang/installer/pulls D is a community effort, pitch in to make the things you want happen.
Re: Note from a donor
On Wednesday, November 01, 2017 05:36:21 Dmitry Olshansky via Digitalmars-d wrote: > On Wednesday, 1 November 2017 at 03:55:14 UTC, Jonathan M Davis > > But the fact remains that plenty of applications need 64-bit or > > would benefit from 64-bit, and plenty of applications need > > access to COFF libraries, and in those cases, you can't do > > things the easy way on Windows. > > Like dmd itself! Yeah, given the situation with CTFE, it's kind of atrocious that we don't distribute dmd as a 64-bit binary at least as an option. - Jonathan M Davis
Re: Note from a donor
On Tuesday, 31 October 2017 at 21:21:46 UTC, Adam D. Ruppe wrote: On Tuesday, 31 October 2017 at 06:33:02 UTC, Dmitry Olshansky wrote: I can live without hot water in my house, would I? So sad but true... my water heater went down today :( Ouch, that analogy got out of hand quick) Basement flooded and it is blinking out a bad vapor sensor error code. Sorry to hear that. Client applications probably do not care much. Servers and cluster software can use more RAM and take advantage of huge address space in many interesting ways. Yeah, I know. And if you're writing that kind of software, installing Visual Studio isn't a big deal. But my point is that the kind of typical hobby stuff and a huge (HUGE) subset of other work too functions perfectly well with 32 bit, yes, even with optlink. You can do web applications, desktop applications, games, all kinds of things with the out-of-the-box dmd install and nobody will be the wiser of 32 vs 64 bit unless someone makes a specific stink over it. Sure. Even Chrome snd its ilk were 32-bit for super long time. I think 64-bit consumed even more ram and that postponed the switch :)
Re: Note from a donor
On Wednesday, 1 November 2017 at 03:55:14 UTC, Jonathan M Davis wrote: On Tuesday, October 31, 2017 06:33:02 Dmitry Olshansky via Digitalmars-d wrote: On Tuesday, 31 October 2017 at 01:25:31 UTC, Adam D Ruppe wrote: > A 32 bit program can do most the same stuff. Client applications probably do not care much. Servers and cluster software can use more RAM and take advantage of huge address space in many interesting ways. Wait, people run Windows on servers? No one could be that crazy, could they? ;) You are seriously underestimating Windows Server. Yeah it has gui and remote desktop, but it ticks in at what ~200 mb of ram. Microsoft IIS is still top server on the web. Also if you didn’t noticed in recent years MS did quite a few breakthroughs on performance e.g. user-mode scheduling and RIO sockets. I think that Adam has a valid point that there _are_ plenty of applications that can function just fine as 32-bit, and given how much easier it is to build for 32-bit on Windows with D, if you don't need to interact with any 3rd party libraries built with MS' compiler, then simply using the default 32-bit dmd stuff on Windows could be just fine. That is ok. But the fact remains that plenty of applications need 64-bit or would benefit from 64-bit, and plenty of applications need access to COFF libraries, and in those cases, you can't do things the easy way on Windows. Like dmd itself!
Re: Note from a donor
On Wednesday, 1 November 2017 at 03:55:14 UTC, Jonathan M Davis wrote: I think that Adam has a valid point that there _are_ plenty of applications that can function just fine as 32-bit, and given how much easier it is to build for 32-bit on Windows with D, if you don't need to interact with any 3rd party libraries built with MS' compiler, then simply using the default 32-bit dmd stuff on Windows could be just fine. Yes. I agree. The point was valid, and it was not a point many would have dared argued .. so good on him ;-) But progress is needed too.. 64bit is to 32bit, was D is to C. A new world of possibilites await
Re: Note from a donor
On Tuesday, October 31, 2017 06:33:02 Dmitry Olshansky via Digitalmars-d wrote: > On Tuesday, 31 October 2017 at 01:25:31 UTC, Adam D Ruppe wrote: > > A 32 bit program can do most the same stuff. > > Client applications probably do not care much. Servers and > cluster software can use more RAM and take advantage of huge > address space in many interesting ways. Wait, people run Windows on servers? No one could be that crazy, could they? ;) I think that Adam has a valid point that there _are_ plenty of applications that can function just fine as 32-bit, and given how much easier it is to build for 32-bit on Windows with D, if you don't need to interact with any 3rd party libraries built with MS' compiler, then simply using the default 32-bit dmd stuff on Windows could be just fine. But the fact remains that plenty of applications need 64-bit or would benefit from 64-bit, and plenty of applications need access to COFF libraries, and in those cases, you can't do things the easy way on Windows. So, for some stuff, having dmd as it is now with 32-bit works just fine, but for other stuff, it doesn't cut it at all. It really depends on what you're trying to do. Either way, it's unfortunate that we have to jump through as many hoops as we do in order to interact with the default C/C++ stuff on Windows. Hopefully, we'll be able to improve that over time though - and we already have. Once upon a time, we didn't have an installer on Windows (let alone one that tried to help you with VS), and we couldn't build COFF stuff with dmd at all. - Jonathan M Davis
Re: Note from a donor
On Wednesday, 1 November 2017 at 01:48:13 UTC, codephantom wrote: Anyway...when you going to give us another surmon? This is WAY off topic so i'ma just leave it at this post (you can email me if you want to go further) but I kinda doubt I'll go to a DConf in Berlin. It is a pain for me. Maybe I'll do it... but don't count on it. Was Andrei the last angel to come visit Walter? No, of course not! Scott Meyers also had to come down to restore the C++hood keys.
Re: Note from a donor
On Tuesday, 31 October 2017 at 21:21:46 UTC, Adam D. Ruppe wrote: But my point is that the kind of typical hobby stuff and a huge (HUGE) subset of other work too functions perfectly well with 32 bit, yes, even with optlink. You can do web applications, desktop applications, games, all kinds of things with the out-of-the-box dmd install and nobody will be the wiser of 32 vs 64 bit unless someone makes a specific stink over it. My 'hobby stuff' involves pushing things to their limit..and beyond... ;-) Just now, on my 24GB mem desktop, I could malloc 21GB of contiguous memory! If I use -m32, that reduces to 1GB. Anyway...when you going to give us another surmon? Was Andrei the last angel to come visit Walter?
Re: Note from a donor
On Tuesday, 31 October 2017 at 06:33:02 UTC, Dmitry Olshansky wrote: I can live without hot water in my house, would I? So sad but true... my water heater went down today :( Basement flooded and it is blinking out a bad vapor sensor error code. Client applications probably do not care much. Servers and cluster software can use more RAM and take advantage of huge address space in many interesting ways. Yeah, I know. And if you're writing that kind of software, installing Visual Studio isn't a big deal. But my point is that the kind of typical hobby stuff and a huge (HUGE) subset of other work too functions perfectly well with 32 bit, yes, even with optlink. You can do web applications, desktop applications, games, all kinds of things with the out-of-the-box dmd install and nobody will be the wiser of 32 vs 64 bit unless someone makes a specific stink over it.
Re: Note from a donor
On 10/30/2017 09:25 PM, Adam D Ruppe wrote: There are advantages to 64 bit, but you can live without them. A 32 bit program can do most the same stuff. The differences in performance are large and growing, however. -- Andrei
Re: Note from a donor
On Tuesday, 31 October 2017 at 01:25:31 UTC, Adam D Ruppe wrote: That doesn't really matter. If you're IMPLEMENTING the database, sure it can help (but is still not *necessary*), but if you're just playing with it, let the database engine handle that and just query the bits you are actually interested in. People have been working with huge, HUGE databases in 32 bit programs for years. It's like clanging rocks together to get fire. It can be done, just expensive and doesn't scale when logic becomes complex.
Re: Note from a donor
On Monday, 30 October 2017 at 14:46:30 UTC, Adam D. Ruppe wrote: On Monday, 30 October 2017 at 10:53:33 UTC, Kagamin wrote: Because native. The processor natively supports all 32 bit code when running in 64 bit more. It just works as far as native hardware goes. For processor it's a whole compatibility mode of operation. It's fairly deeply integrated, but still... You also need your library dependencies installed too, and indeed on Linux that might be an extra install (just like any other dependencies...), but on Windows, the 32 bit core libs are always installed and with D, you don't really use other stuff anyway. For OS it's a whole emulated subsystem with separate collection of compiled code installed and loaded into RAM. On my system it's 1.36gb, 7000 files. On Windows it depends on installation too whether 32 bit subsystem is installed. Also if the code can work on linux 64 bit, there's little reason to stretch it to 32 bit. If you're playing around... really no reason not to just use the 32 bit one. 64 bit system is free from some legacy stuff too, it's just better. So it's better to play with 64 bit than with 32 bit. For example remember the whole OMF deal.
Re: Note from a donor
On Tuesday, 31 October 2017 at 01:25:31 UTC, Adam D Ruppe wrote: On Tuesday, 31 October 2017 at 01:00:29 UTC, codephantom wrote: If you play with large databases, containing a lot data, then 64-bit memory addressing will give you access to more memory. That doesn't really matter. If you're IMPLEMENTING the database, sure it can help (but is still not *necessary*), Kinda important, say your server is 128Gb (bugger sizes are quite typical these days). but if you're just playing with it, let the database engine handle that and just query the bits you are actually interested in. People have been working with huge, HUGE databases in 32 bit programs for years. Ah ye, we can do the same in 16 bits with ample 640k bytes. Just window your dataset in 64k at a time, trivial. There are advantages in bigger size of virtual address space even if you use tiny fraction of physical memory. There are advantages to 64 bit, but you can live without them. I can live without hot water in my house, would I? A 32 bit program can do most the same stuff. Client applications probably do not care much. Servers and cluster software can use more RAM and take advantage of huge address space in many interesting ways.
Re: Note from a donor
On Tuesday, 31 October 2017 at 01:00:29 UTC, codephantom wrote: If you play with large databases, containing a lot data, then 64-bit memory addressing will give you access to more memory. That doesn't really matter. If you're IMPLEMENTING the database, sure it can help (but is still not *necessary*), but if you're just playing with it, let the database engine handle that and just query the bits you are actually interested in. People have been working with huge, HUGE databases in 32 bit programs for years. And more memory means faster operations. Not necessarily. There are advantages to 64 bit, but you can live without them. A 32 bit program can do most the same stuff.
Re: Note from a donor
On Monday, 30 October 2017 at 14:46:30 UTC, Adam D. Ruppe wrote: If you're playing around... really no reason not to just use the 32 bit one. Really depends what you're playing with. If you play with large databases, containing a lot data, then 64-bit memory addressing will give you access to more memory. And more memory means faster operations.
Re: Note from a donor
On Monday, 30 October 2017 at 10:53:33 UTC, Kagamin wrote: Because native. The processor natively supports all 32 bit code when running in 64 bit more. It just works as far as native hardware goes. You also need your library dependencies installed too, and indeed on Linux that might be an extra install (just like any other dependencies...), but on Windows, the 32 bit core libs are always installed and with D, you don't really use other stuff anyway. D on Windows 32 bit just works and generates an exe that just works on basically any Windows box from the last 15 years and will likely continue to just work for AT LEAST the next 5, probably more. If you're playing around... really no reason not to just use the 32 bit one.
Re: Note from a donor
On Monday, 30 October 2017 at 11:18:39 UTC, Basile B. wrote: Ha i thought the same but... Yes it has one. The first 32 bit application will pull it as a dependency. Same can be done for JVM. Just setup the 32 bit version of the devel libraries BTW why are those even needed? Doesn't ld link against so directly?
Re: Note from a donor
On Monday, 30 October 2017 at 10:53:33 UTC, Kagamin wrote: On Saturday, 28 October 2017 at 15:42:00 UTC, Adam D. Ruppe wrote: Why do you want 64 bit? I very rarely do 64 bit builds on Windows (mostly just to make sure my crap actually works) since there's not actually that many advantages to it anyway! Because native. I believe Linux doesn't have 32-bit subsystem Ha i thought the same but... Yes it has one. Just setup the 32 bit version of the devel libraries (likely not necessary for phobos) and you can compile & link with -m32.
Re: Note from a donor
On Saturday, 28 October 2017 at 15:42:00 UTC, Adam D. Ruppe wrote: Why do you want 64 bit? I very rarely do 64 bit builds on Windows (mostly just to make sure my crap actually works) since there's not actually that many advantages to it anyway! Because native. I believe Linux doesn't have 32-bit subsystem installed by default, Windows started to do it too.
Re: Note from a donor
On Saturday, 28 October 2017 at 16:23:13 UTC, Adam D. Ruppe wrote: 64 bit is an added hassle, but an unnecessary one for most uses anyway. Today I thought I might install DMD on Windows XP 64bit (the intel one)... just to see if I can compile D with -m64. Well, with the Windows7 SDK and DMD installed, -m64 worked just fine. So D continues to surprise me, and now even supports (seems to anyway) a platform that everyone gave up on a long time ago .. isn't that great! 64bit D ... on Windows XP...
Re: Note from a donor
On 10/29/2017 1:03 PM, Benjamin Thaut wrote: Unfortunately I currenlty don't have a lot of spare time to spend on open source projets. I will however have some more time in December. My current plan is to revive DIP 45 and my dll implementation and give it some finishing touches as discussed with Walter at DConf 2017. Looking forward to it!
Re: Note from a donor
On Sunday, 29 October 2017 at 20:58:45 UTC, 12345swordy wrote: What makes you think that windows is a "dying platform"!? There is no evidence to suggest this. Windows dying? Perhaps not. But the dominance of Windows is *certainly* under threat. The clear evidence for that, is the strategies MS is putting in place to go cross-platform, and, increasingly, open-source. Good on em' for adapating... D is focused on its cross-platform capabilites, which wil be really important for its future too... So the evidence is in. Windows is becoming less dominant...and there's no reason to believe that won't continue to be the case... btw. No mobile device will replace my desktop pc ... Like the pharaohs..I want access to my desktop pc in the after life too..so it will be buried with me ;-)
Re: Note from a donor
On Sunday, 29 October 2017 at 16:25:35 UTC, Jonathan M Davis wrote: While complaining about what Microsoft is doing with VS may be justified, it doesn't really help anything. I think that we'd all be better off if we just let this topic die. Not to push the point too much...but I found this interesting phrase, from Google's 'ten things we know to be true' "Ultimately, our constant dissatisfaction with the way things are becomes the driving force behind everything we do." https://www.google.com/about/philosophy.html
Re: Note from a donor
On Sunday, 29 October 2017 at 16:14:11 UTC, 12345swordy wrote: Hell, I even recall that gdb needs python for some strange reason, in my linux machines. I don't know WHY it requires it, but I wouldn't jump to conclusions and think it as "unnecessary-dependencies" simply because I don't understand the rational behind it. Here is an interesting paper, that explores the dependencies between modules in some open source kernels (linux vs BSD). The paper found the linux kernel (compared to the BSD kernels) had far too much dependency between modules, because linux uses far too many global variables, and so too many modules are tightly coupled by mean of them sharing those global variables. They argued that such common coupling (module dependencies) have a deleterious effect on maintainability, and that such common coupling increases exponentially with each subsequent release, further reducing maintainability. The key take away point of course, is that software development really needs to be on guard against the problems associated with modular dependencies. It's one of the reasons functional programming is becoming increasingly important (and useful). There is no reason why the principle should not also apply to the distribution of software. https://dl.acm.org/citation.cfm?id=1150566.1150571
Re: Note from a donor
On Sunday, 29 October 2017 at 16:14:11 UTC, 12345swordy wrote: How exactly do you know this? You never justify it! We are living in an age where we have terabytes harddrives! Hell, I even recall that gdb needs python for some strange reason, in my linux machines. I don't know WHY it requires it, but I wouldn't jump to conclusions and think it as "unnecessary-dependencies" simply because I don't understand the rational behind it. I believe that complexity and unnecessary dependencies on components and other teams, is the biggest problem/challenge facing modern software development. It lead to software that is intolerant to change. And it's the primary reason why the Cylons, when they arrive, will defeat us ;-) The D language is so refreshing...that I'd hate to see it get caught up in that mess of complexity. We should all really be on guard against it.
Re: Note from a donor
On Sunday, 29 October 2017 at 16:25:35 UTC, Jonathan M Davis wrote: While complaining about what Microsoft is doing with VS may be justified, it doesn't really help anything. I think that we'd all be better off if we just let this topic die. - Jonathan M Davis That attitude would have you instantly evicted from my team ;-) It's precisely because of the 'complaining' that Microsoft is changing its ways'. Complain even 'louder'...that's my advice. -- The only real problem with Windows, is that you can't fork it --
Re: Note from a donor
On Sunday, 29 October 2017 at 18:52:06 UTC, Joakim wrote: On Sunday, 29 October 2017 at 10:21:22 UTC, Patrick Schluter wrote: To conclude: if D wants to cater to that crowd, it will have to bite the bullet and make the Windows experience even smoother than it is now. You won't overcome Windows dev's Stockholm syndrome otherwise and Windows devs, should also peg down a little bit and learn that MS's way of doing things is far from being ideal (bloat, loss of control, changing specs every 3 years, programmed obsolescence (Active-X anyone?)). Or better yet, don't bother with a dying platform full of whiny devs who are helpless without an IDE. One of D's strengths is that it isn't architected for IDE-driven development and the oft-resulting verbosity, that's a market D should probably just leave alone. Instead, focus on the current major platform which lets you use almost any toolchain you want: http://forum.dlang.org/thread/xgiwhblmkvcgnsktj...@forum.dlang.org Of course, it is admirable what Rainer and others do to maintain VisualD and other D tools for the Windows platform. I just don't see it mattering much in the next decade. What makes you think that windows is a "dying platform"!? There is no evidence to suggest this.
Re: Note from a donor
On Tuesday, 24 October 2017 at 21:11:38 UTC, solidstate1991 wrote: DIP45 has the solution (make export an attribute), it needs to be updated for the new DIP format from what I heard. It needs to be pushed, as Windows still the most popular OS on the consumer side of things, then we can have Phobos and DRuntime as DLLs without using experimental versions of DMD. I have some plans with the better DLL support, such as the possibility of a D based Python (for better class interoperability with D), or even using a modified set of D for scripting (eg. SafeD only). Unfortunately I currenlty don't have a lot of spare time to spend on open source projets. I will however have some more time in December. My current plan is to revive DIP 45 and my dll implementation and give it some finishing touches as discussed with Walter at DConf 2017.
Re: Note from a donor
On Sunday, 29 October 2017 at 10:21:22 UTC, Patrick Schluter wrote: To conclude: if D wants to cater to that crowd, it will have to bite the bullet and make the Windows experience even smoother than it is now. You won't overcome Windows dev's Stockholm syndrome otherwise and Windows devs, should also peg down a little bit and learn that MS's way of doing things is far from being ideal (bloat, loss of control, changing specs every 3 years, programmed obsolescence (Active-X anyone?)). Or better yet, don't bother with a dying platform full of whiny devs who are helpless without an IDE. One of D's strengths is that it isn't architected for IDE-driven development and the oft-resulting verbosity, that's a market D should probably just leave alone. Instead, focus on the current major platform which lets you use almost any toolchain you want: http://forum.dlang.org/thread/xgiwhblmkvcgnsktj...@forum.dlang.org Of course, it is admirable what Rainer and others do to maintain VisualD and other D tools for the Windows platform. I just don't see it mattering much in the next decade.
Re: Note from a donor
On Sunday, October 29, 2017 16:14:11 12345swordy via Digitalmars-d wrote: > On Sunday, 29 October 2017 at 02:39:21 UTC, codephantom wrote: > > On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote: > > > > What I am, is: > > > > anti-bloat > > anti-too-many-unecessary-dependencies > > anti > > you-have-no-choice-but-to-download-GB's-stuff-you-really-don't-need > > How exactly do you know this? You never justify it! We are living > in an age where we have terabytes harddrives! Hell, I even recall > that gdb needs python for some strange reason, in my linux > machines. I don't know WHY it requires it, but I wouldn't jump to > conclusions and think it as "unnecessary-dependencies" simply > because I don't understand the rational behind it. Really, it doesn't matter. Yes, it would be great if VS didn't take up as much space as it does. It would be great if Microsoft released stuff with the idea that the core compiler command-line tools were what mattered, and the IDE was just an add-on for those who care. I'm sure that we could all come up with reasons to complain about what Microsoft is doing - _lots_ of geeks love to complain about Microsoft. What matters is that D needs to be able to link and interoperate with C/C++ code generated by Microsoft's compiler, because that's the primary compiler for Windows systems and what most everyone is using if they're developing on Windows. If we can do that in a way that minimizes what needs to be downloaded, then great. If we can't, then well, that sucks, but that's life. While complaining about what Microsoft is doing with VS may be justified, it doesn't really help anything. I think that we'd all be better off if we just let this topic die. - Jonathan M Davis
Re: Note from a donor
On Sunday, 29 October 2017 at 02:39:21 UTC, codephantom wrote: On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote: What I am, is: anti-bloat anti-too-many-unecessary-dependencies anti you-have-no-choice-but-to-download-GB's-stuff-you-really-don't-need How exactly do you know this? You never justify it! We are living in an age where we have terabytes harddrives! Hell, I even recall that gdb needs python for some strange reason, in my linux machines. I don't know WHY it requires it, but I wouldn't jump to conclusions and think it as "unnecessary-dependencies" simply because I don't understand the rational behind it.
Re: Note from a donor
On Sunday, 29 October 2017 at 10:21:22 UTC, Patrick Schluter wrote: Just a little answer so that you see that you're not alone with your concerns. I think you're absolutely right and that your experiment was nicely done and clear from the beginning what it was about. Reading is a skill that some people seem to have problems with. Thanks for the support ;-) btw. I was just experimenting with the Windows 7 SDK iso (a 570MB download) https://www.microsoft.com/en-au/download/details.aspx?id=8442 From that ISO, I only need to install two components: - Header and Libraries (only the x64 ones are needed) (~180MB) - Visual C++ Compilers (~637MB) The total disk space needed to install those 2 components is 810MB. Then I can compile D using -m64 However DMD won't pick up the SDK during install, so I had to change these two settings in the sc.ini: VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ WindowsSdkDir=C:\Program Files\Microsoft SDKs\Windows\v7.1\ To my surprise (not really knowing what I was doing), it all worked (so far), and apart from downloading the iso, you don't need to be connected to the internet during the install of the SDK... The SDK requires you have .NET 4 installed first though, otherwise it won't let you install the Visual C++ Compilers. btw. The min size if you use the VS 2017 build tools was 3.5GB installed. So I have saved myself several gb of download, and several gb of disk space...just by using the Windows 7 SDK instead.
Re: Note from a donor
On Sunday, 29 October 2017 at 03:46:35 UTC, codephantom wrote: On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote: It seems to me that you have a major case of anti-windows bias here, as I never have any issues on my main windows machine. Actually, it's the very opposite...I'm strongly arguing 'for' D on Windows. (otherwise I wouldn't have wasted my time with this). If you're ok with having VS, then that is not too much of pain to install..I get it. But if you don't want VS, then it really is a pain. You have to work out what is the min required componentsall by yourself - like i had to do. That really was a pain! I want D on Windows (64bit included), and I want it to be a better experience than what I had...that's been the whole point of my involvement in the discussion. In essence, I'm an advocate for D on Windows ;-) (but to do that, without being forced to advocate for VS as well..is kinda challenging..it seems) It's D I'm interested in. Not VS. Just a little answer so that you see that you're not alone with your concerns. I think you're absolutely right and that your experiment was nicely done and clear from the beginning what it was about. Reading is a skill that some people seem to have problems with. To my experience now. I finally managed to install VS2017 by doing essentially the sleep during download thing to get the offline installer. My Internet is not especially bad but not good either (5 Mb down, 1 Mb up ADSL with very fluctuating latencies) and the download took also several hours. For 1.6 GB it's really slow. It has probably more to do with the Microsoft download code than anything else (as the discussions in the link someone provided tend to show). The good thing is that it is now possible to install VS2017 on a relatively small system partition, a thing that I didn't manage to do with VS2013 and VS2015. The DMD installer also had no problem to install the Visual-D plug-in and I managed to build my project in 32 and 64 bit. This said, it's the whole VS experience that I'm really annoyed with. MS goes really out of its way to make the whole IDE as magical as possible, i.e. everything is set so that the gritty reality of code generation is hidden from the developer. The more it goes, the less obvious it gets to install unconventional things in the environment. Even simple stuff can become a real pain. For instance, I like to have visible white spaces when editing code (yeah, I hate tabs in program code). In all editors and IDE I have tried yet, it was easy to set, when not in an appearance toolbar, it's somewhere in "view" or "edit" menu. In VS, it was a chore to find and I had to customize a tool bar using 5 deep dialog box galore. Annoying. I can understand how and why MS do it that way. When you work a little bit longer with it, it is really sleek and nicely integrated in the system. The thing is, it that it removes the perspective of what really happens when building a program (object files, libs, linking etc.) and that's the reason why we get so regularely the complaints about the "Windows experience sucking": MS has nurtured a generation of devs who have no clue what building an app entails. To conclude: if D wants to cater to that crowd, it will have to bite the bullet and make the Windows experience even smoother than it is now. You won't overcome Windows dev's Stockholm syndrome otherwise and Windows devs, should also peg down a little bit and learn that MS's way of doing things is far from being ideal (bloat, loss of control, changing specs every 3 years, programmed obsolescence (Active-X anyone?)).
Re: Note from a donor
On Wednesday, 25 October 2017 at 22:46:27 UTC, Adam Wilson wrote: On 10/25/17 11:23, H. S. Teoh wrote: On Wed, Oct 25, 2017 at 08:17:21AM -0600, Jonathan M Davis via Digitalmars-d wrote: [...] [...] Yeah. There have been timing attacks against otherwise-secure crypto algorithms that allow extraction of the decryption key. And other side-channel attacks along the lines of CRIME or BREACH. Even CPU instruction timing attacks have been discovered that can leak which path a branch in a crypto algorithm took, which in turn can reveal information about the decryption key. And voltage variations to deduce which bit(s) are 1's and which are 0's. Many of these remain theoretical attacks, but the point is that these weaknesses can come from things you wouldn't even know existed in your code. Crypto code must be subject to a LOT of scrutiny before it can be trusted. And not just cursory scrutiny like we do with the PR queue on github; we're talking about possibly instruction-by-instruction scrutiny of the kind that can discover vulnerabilities to timing or voltage. I would not be comfortable entrusting any important data to D crypto algorithms if they have not been thoroughly reviewed. T 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. Period. Everything else is a good way to run afoul of a security audit, and potentially expose yourself. Phobos could forward to these system provided API's like .NET does and provide an idiomatic D interface, but Phobos itself should absolutely and 110% stay out of the crypto implementation business. I think you made a very good point, it was also mentioned by someone else in this thread. Phobos could provide a crypto interface with implementions for SChannel, mbedtls, openssl. On Windows SChannel would be used as default implementation and on the other operation systems either openssl or mbedtls. This would be very convenient and we would avoid opening the Pandora box. I will close my issue and create a new one with the request for a crypto interface in Phobos. Kind regards Andre
Re: Note from a donor
On Sunday, 29 October 2017 at 03:46:35 UTC, codephantom wrote: It's D I'm interested in. Not VS. btw. since this thread has gone way off topic... I'd suggest this one instead: https://forum.dlang.org/thread/xwuxfcdaqkcealxzg...@forum.dlang.org
Re: Note from a donor
On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote: It seems to me that you have a major case of anti-windows bias here, as I never have any issues on my main windows machine. Actually, it's the very opposite...I'm strongly arguing 'for' D on Windows. (otherwise I wouldn't have wasted my time with this). If you're ok with having VS, then that is not too much of pain to install..I get it. But if you don't want VS, then it really is a pain. You have to work out what is the min required componentsall by yourself - like i had to do. That really was a pain! I want D on Windows (64bit included), and I want it to be a better experience than what I had...that's been the whole point of my involvement in the discussion. In essence, I'm an advocate for D on Windows ;-) (but to do that, without being forced to advocate for VS as well..is kinda challenging..it seems) It's D I'm interested in. Not VS.
Re: Note from a donor
On Saturday, 28 October 2017 at 07:39:21 UTC, codephantom wrote: It's the *minimum* 'selection set' you'll need (with regards to the Visual Studio Build Tools 2017) in order to get DMD to sucessfully compile a 64bit exe (-m64) Now to be fair, this is assuming you **don't** want and **don't** have VS installed, but just want the necessary 'build tools' so that DMD can build a *64bit* binary on Windows - (in total about 3.5GB). Code tools Static analysis tools Compilers, build tools, and runtimes VC++ 2017 v141 toolset (x86,x64) SDK's, libraries and frameworks Windows 10 SDK (10.0.16299.0) for Desktop C++ [x86 and x64] Windows 10 SDK (10.0.16299.0) for UWP: C#, VB, JS Windows 10 SDK (10.0.16299.0) for UWP: C++ I need to correct my statement above (it was late at night ;-) The actual download size was 977MB The installed size was 3.5GB
Re: Note from a donor
On Sunday, 29 October 2017 at 02:09:31 UTC, 12345swordy wrote: It seems to me that you have a major case of anti-windows bias here, as I never have any issues on my main windows machine. Well, throughout this discussion, I have documented *my* experience (not yours) of getting 64bit D on a fresh install of Windows 7. That was my only objective. I'm really not anti-windows. Windows XP is still one of favourite all time os's! I'm not anti-microsoft either...they have some good stuff too I wish they'd get .NET core working on FreeBSD properly though...as I like playing with C# too... What I am, is: anti-bloat anti-too-many-unecessary-dependencies anti you-have-no-choice-but-to-download-GB's-stuff-you-really-don't-need This is not specific to Windows by the looks of the discussion. Apple has similar demands of you apparently (with Xcode). I think it can and should be done better...that's the point I'm really trying to get (push) across. I'm shocked that so many seem to disagree. The modularisation of the VS install process helps a little (if you can get your head around how it works)...but there are still too many dependencies...and the whole experience should be streamlined a lot more... Many developers these days learn to program in these bloated IDE's..and they are used to it..I get that. I learnt to program in C, using vi ;-) I guess different experiences lead to different expectations.
Re: Note from a donor
On Sunday, 29 October 2017 at 01:43:46 UTC, codephantom wrote: On Sunday, 29 October 2017 at 01:07:17 UTC, Jerry wrote: So why do you care about something that doesn't even affect you? Well, if you had been following the discussion, instead of just trying to troll, then you would know that I was essentially doing an experiment. AIM: If I was using Windows, and wanted to compile 64bit D code, but did *NOT* want to install VS, then what would be the minimum components required (of VS's build tools). The outcome, **for me**, of that experiment, was a whole day wasted - mostly waiting for GB's of build tools to download. Not to mention the service packs, updates and .NET framework installation. Then there's getting your head around the various licence agreements, and alos trying to understand what these new processes running on my system are doing..and why are they talking to servers on the internet. Coming from a non-windows C background ... the whole thing was a little daunting. I guess if you're used to all the bloat that comes with Windows...(as you seem to be) or have to use it for practical reasons then nothing about my little experiment would surprise you.. So I'm executing my right to free speech, and I'm saying that I don't like it, and I wish it was better. Is that so bad? It seems to me that you have a major case of anti-windows bias here, as I never have any issues on my main windows machine.
Re: Note from a donor
On Sunday, 29 October 2017 at 01:43:46 UTC, codephantom wrote: So I'm executing my right to free speech, and I'm saying that I don't like it, and I wish it was better. Is that so bad? You are doing more than saying you don't like it. You are requesting and advocating for the removal of a feature that has no reason to be removed. I never said you couldn't say you don't like it, you are free and welcome to do so. I never even said you can't request for a feature to be removed. I'm simply making the counter argument for why it shouldn't be, and I'm free to do that as you are free to make horrible requests. Anyways you keep trying to change your argument and make it appear as something else. Your free speech was never in jeopardy from the beginning, I never told you couldn't say anything. It's clear where this is going and it's clear you have no intentions of actually making any attempt to justify your request as it is unjustifiable. Good day.
Re: Note from a donor
On 10/28/17 12:46, Jerry wrote: On Saturday, 28 October 2017 at 15:36:38 UTC, codephantom wrote: But if you really are missing my point..then let me state it more clearly... (1) I don't like waiting 4 hours to download gigabytes of crap I don't actually want, but somehow need (if I want to compile 64bit D that is). Start the download when you go to sleep, when you wake up it will be finished. I did this as a kid when I had internet that was probably even slower than yours right now. It'll be like those 4 hours never even happened. (2)I like to have choice. A fast internet might help with (1). (2) seems out of reach (and that's why I dont' and won't be using D on Windows ;-) It's probably why you shouldn't be on Windows to begin with.. (being a recreational programmer, I have that luxury..I understand that others do not, but that's no reason for 'some' to dismiss my concerns as irrelevant. They're relavent to me, and that's all that matters ;-) Talk about being narcissistic ;) Hey Jerry, I appreciate what you're trying to accomplish .. but uh ... don't feed that trolls. ;) -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Note from a donor
On Sunday, 29 October 2017 at 01:07:17 UTC, Jerry wrote: So why do you care about something that doesn't even affect you? Well, if you had been following the discussion, instead of just trying to troll, then you would know that I was essentially doing an experiment. AIM: If I was using Windows, and wanted to compile 64bit D code, but did *NOT* want to install VS, then what would be the minimum components required (of VS's build tools). The outcome, **for me**, of that experiment, was a whole day wasted - mostly waiting for GB's of build tools to download. Not to mention the service packs, updates and .NET framework installation. Then there's getting your head around the various licence agreements, and alos trying to understand what these new processes running on my system are doing..and why are they talking to servers on the internet. Coming from a non-windows C background ... the whole thing was a little daunting. I guess if you're used to all the bloat that comes with Windows...(as you seem to be) or have to use it for practical reasons then nothing about my little experiment would surprise you.. So I'm executing my right to free speech, and I'm saying that I don't like it, and I wish it was better. Is that so bad?
Re: Note from a donor
On Sunday, 29 October 2017 at 00:45:08 UTC, codephantom wrote: On Saturday, 28 October 2017 at 19:46:00 UTC, Jerry wrote: Start the download when you go to sleep, when you wake up it will be finished. I did this as a kid when I had internet that was probably even slower than yours right now. It'll be like those 4 hours never even happened. That's greate advice Jerry. Perhaps that should go up on the wiki... "NOTE: If you're using Windows, and you want to use the -m64 mode to compile D into 64bit code, you will need to download several GB's of other stuff...and if you have slow internet connection...then just start it when you go to sleep..and when you wake up it will be finished. It'll be like those 4 hours never even happened." Most developers don't have shitty internet though, the one's that do don't go whining about it trying to use something "better", where better is just a substitute for smaller package size. Visual Studio is probably the most reliable and stable toolchain on Windows, the only thing anyone (ehm you) has to say bad about it is it's download size. I'd say that's better damn near the best D can do if the only thing someone has to complain about it is the download size.
Re: Note from a donor
On Sunday, 29 October 2017 at 00:17:10 UTC, codephantom wrote: On Saturday, 28 October 2017 at 19:46:00 UTC, Jerry wrote: It's probably why you shouldn't be on Windows to begin with.. I'm not. I'm on FreeBSD. So why do you care about something that doesn't even affect you? Talk about being narcissistic ;) I wasn't talking about narcissism, I was talking about trolling. Narcissism was not correlated with trolling enjoyment in that study I mentioned. It is when someone is only thinking about themselves, such as yourself and wanting D to not use tools that you aren't even complaining about being good enough. You are just complaining about it cause it's a large download size. I find people always refer to people as trolls instead of creating a counterpoint to their argument. It's a lot easier to just label someone a troll and ignore their arguments than building a case for a baseless request.
Re: Note from a donor
On Saturday, 28 October 2017 at 19:46:00 UTC, Jerry wrote: Start the download when you go to sleep, when you wake up it will be finished. I did this as a kid when I had internet that was probably even slower than yours right now. It'll be like those 4 hours never even happened. That's greate advice Jerry. Perhaps that should go up on the wiki... "NOTE: If you're using Windows, and you want to use the -m64 mode to compile D into 64bit code, you will need to download several GB's of other stuff...and if you have slow internet connection...then just start it when you go to sleep..and when you wake up it will be finished. It'll be like those 4 hours never even happened."
Re: Note from a donor
On Saturday, 28 October 2017 at 19:46:00 UTC, Jerry wrote: It's probably why you shouldn't be on Windows to begin with.. I'm not. I'm on FreeBSD. Talk about being narcissistic ;) I wasn't talking about narcissism, I was talking about trolling. Narcissism was not correlated with trolling enjoyment in that study I mentioned. If you want a debate. Fine. If you want to troll...go elsewhere.
Re: Note from a donor
On Saturday, 28 October 2017 at 15:36:38 UTC, codephantom wrote: But if you really are missing my point..then let me state it more clearly... (1) I don't like waiting 4 hours to download gigabytes of crap I don't actually want, but somehow need (if I want to compile 64bit D that is). Start the download when you go to sleep, when you wake up it will be finished. I did this as a kid when I had internet that was probably even slower than yours right now. It'll be like those 4 hours never even happened. (2)I like to have choice. A fast internet might help with (1). (2) seems out of reach (and that's why I dont' and won't be using D on Windows ;-) It's probably why you shouldn't be on Windows to begin with.. (being a recreational programmer, I have that luxury..I understand that others do not, but that's no reason for 'some' to dismiss my concerns as irrelevant. They're relavent to me, and that's all that matters ;-) Talk about being narcissistic ;)
Re: Note from a donor
On Saturday, 28 October 2017 at 14:43:38 UTC, codephantom wrote: I explicitly mentioned that I did ***NOT*** want VS installed. So? If you don't want to use it, then don't use D, or don't use Windows. There's simple solution to your problem. Rust requires VS, you can't build on Windows without it. It's not that big of a deal to require. If you don't want to use it, then go ahead, D is open source see how easy it is to replace with something else. The majority of time spent was downloading the damn thing! Again with the size issue, 3.5 GB isn't that big of a file. Start the download and go do something, time management is a skill. You don't have to sit there and watch it download, even if you have shitty internet.
Re: Note from a donor
On Saturday, 28 October 2017 at 16:23:13 UTC, Adam D. Ruppe wrote: The beauty of it is they work basically the same. Especially on Windows, where 32 bit programs just work on almost any installation, 32 or 64 bit. yes. i have dmd on one of my old laptops (it runs XP 32bit) ...works just fine. No VS crap needed. The whole o/s takes up only 2.5GB (about 2GB less than just the VS2017 build tools). Some where along the line, software development took a course for the worst...now we have bloated software with an increadible amount of dependencies on this and thatit's just getting crazy IMHO. too big and too slow.. that's why the dinosaurs never survived ;-)
Re: Note from a donor
On Saturday, 28 October 2017 at 15:20:05 UTC, Mengu wrote: my code that worked amazing on linux and mac os x failed miserably on freebsd which is my server os whenever and wherever possible. i did not have the luxury of days to fix stuff so i simply switched to debian. Would be interested to know what that code was doing...to make it fail. FreeBSD is certainly increasing it's share in the server market .. particulary for large enterprisesmost vm cloud providers now proivde them toowhich I never expected a decade ago( I think the change to the GPL a decade ago, caused many to consider alteratives to Linux..of which there a very few)... and if D takes off too(as I think it will over the coming years, not just because of the language, but because of its licence too)... then much greater attention will have to be given to D, in the FreeBSD environment. Till then...we have what we have... ..and for me..it's pretty good...so far ;-) Make sure you're on 11.x - x64 though...
Re: Note from a donor
On Saturday, 28 October 2017 at 16:03:15 UTC, codephantom wrote: I like seeing how code works in different environments. The beauty of it is they work basically the same. Especially on Windows, where 32 bit programs just work on almost any installation, 32 or 64 bit. The DMar's C compiler is 2MB (no... I got the right...MB not GB..) Yes, I have been using it for a long time. And it just works with dmd 32 bit! 64 bit is an added hassle, but an unnecessary one for most uses anyway.
Re: Note from a donor
On Saturday, 28 October 2017 at 15:42:00 UTC, Adam D. Ruppe wrote: Why do you want 64 bit? I very rarely do 64 bit builds on Windows (mostly just to make sure my crap actually works) since there's not actually that many advantages to it anyway! I'm more of an experimenter than a programmer. I like seeing how code works in different environments. I have several 16-bit computers at home too...but no D for them ;-( I'm used to writing code in plain text editor (the plainer the better).. and I doing everything else at a shell prompt. It just how I like to 'play'. Perhaps that why I just see VS as a big scary monster that wants to eat up all my computer resources ;-) The DMar's C compiler is 2MB (no... I got the right...MB not GB..) ..think about it...
Re: Note from a donor
On Saturday, 28 October 2017 at 15:36:38 UTC, codephantom wrote: (if I want to compile 64bit D that is). (being a recreational programmer Why do you want 64 bit? I very rarely do 64 bit builds on Windows (mostly just to make sure my crap actually works) since there's not actually that many advantages to it anyway!
Re: Note from a donor
On Saturday, 28 October 2017 at 15:18:07 UTC, Mengu wrote: with mac os x, we have to download gbs of command line tools library before getting started with any development. if we want to build anything for ios or mac we have to download 5gb xcode. with a fast internet, you get that in a matter of minutes. i don't believe that should be a show stopper or maybe i am missing your point. Yeah..sadly, we don't have fast internet here in Australia. 1GB takes about an hour (presuming house mate not online ;-) And I have a typically average connection. Just the build tools alone (without the VS IDE and stuff), took almost 4 hours for me to download. And all I wanted to do, was compile some D code into a 64bit binary. If I were on a mobile wireless internet connection, my next bill would send me into bankruptcy! (lucky I'm on landline connection). I guess if it took seconds, I'd have a bit less to complain about ;-) But if you really are missing my point..then let me state it more clearly... (1) I don't like waiting 4 hours to download gigabytes of crap I don't actually want, but somehow need (if I want to compile 64bit D that is). (2)I like to have choice. A fast internet might help with (1). (2) seems out of reach (and that's why I dont' and won't be using D on Windows ;-) (being a recreational programmer, I have that luxury..I understand that others do not, but that's no reason for 'some' to dismiss my concerns as irrelevant. They're relavent to me, and that's all that matters ;-)
Re: Note from a donor
On Saturday, 28 October 2017 at 02:50:39 UTC, codephantom 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. my code that worked amazing on linux and mac os x failed miserably on freebsd which is my server os whenever and wherever possible. i did not have the luxury of days to fix stuff so i simply switched to debian.
Re: Note from a donor
On Saturday, 28 October 2017 at 14:43:38 UTC, codephantom wrote: On Saturday, 28 October 2017 at 14:00:14 UTC, Jerry wrote: On Saturday, 28 October 2017 at 07:39:21 UTC, codephantom wrote: btw. (and I do realise we've gone way of the topic of this original thread)...but... if it interests anyone, this is the outcome of yesterday, where I wasted my whole day trying to get DMD to compile a 64bit .exe on a fresh install of Windows 7. Your own incompetence isn't reason enough for everyone else to suffer. I've never had a problem installing Visual Studio, or getting D to work with it. Nice one Jerry. You're so eager to have a go at me, that you completely missed the point. I explicitly mentioned that I did ***NOT*** want VS installed. All I wanted, was to build a 64bit D binary, and wanted to know what was the minimum components I had to install in order to be able to do that. I had just wanted VS. I would have just installed that. The majority of time spent was downloading the damn thing! Go trawl somewhere else! but what if that is how you can build 64 bit binary? with mac os x, we have to download gbs of command line tools library before getting started with any development. if we want to build anything for ios or mac we have to download 5gb xcode. with a fast internet, you get that in a matter of minutes. i don't believe that should be a show stopper or maybe i am missing your point.
Re: Note from a donor
On Saturday, 28 October 2017 at 14:50:25 UTC, codephantom wrote: I think I meant troll, not trawl ;-) btw... A scientific research paper, titled 'Trolls just want to have fun' found that: - Sadism and Machiavellianism were unique predictors of trolling enjoyment.. - Found clear evidence that sadists tend to troll because they enjoy it.. http://www.sciencedirect.com/science/article/pii/S0191886914000324
Re: Note from a donor
On Saturday, 28 October 2017 at 14:43:38 UTC, codephantom wrote: Nice one Jerry. Go trawl somewhere else! I think I meant troll, not trawl ;-)
Re: Note from a donor
On Saturday, 28 October 2017 at 14:00:14 UTC, Jerry wrote: On Saturday, 28 October 2017 at 07:39:21 UTC, codephantom wrote: btw. (and I do realise we've gone way of the topic of this original thread)...but... if it interests anyone, this is the outcome of yesterday, where I wasted my whole day trying to get DMD to compile a 64bit .exe on a fresh install of Windows 7. Your own incompetence isn't reason enough for everyone else to suffer. I've never had a problem installing Visual Studio, or getting D to work with it. Nice one Jerry. You're so eager to have a go at me, that you completely missed the point. I explicitly mentioned that I did ***NOT*** want VS installed. All I wanted, was to build a 64bit D binary, and wanted to know what was the minimum components I had to install in order to be able to do that. I had just wanted VS. I would have just installed that. The majority of time spent was downloading the damn thing! Go trawl somewhere else!
Re: Note from a donor
On Saturday, 28 October 2017 at 07:39:21 UTC, codephantom wrote: btw. (and I do realise we've gone way of the topic of this original thread)...but... if it interests anyone, this is the outcome of yesterday, where I wasted my whole day trying to get DMD to compile a 64bit .exe on a fresh install of Windows 7. Your own incompetence isn't reason enough for everyone else to suffer. I've never had a problem installing Visual Studio, or getting D to work with it.
Re: Note from a donor
On Saturday, 28 October 2017 at 00:05:53 UTC, codephantom wrote: 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? There is an afterlife with god. There is nothingness after death. Which is the worse mentality? Yet why is it that the more educated someone is, the more likely they are to be atheist?
Re: Note from a donor
On Saturday, 28 October 2017 at 00:05:53 UTC, codephantom wrote: Rubbish! And get you facts straight! Where did I advocate from the removal of the ability for D to generate 64-bit binaries? So you are saying to not use the platform's tools to generate binaries. That's like saying not to the use linux's tools to generate binaries on that platform and instead D should build it's own tools in order to be able to. D has a small enough community as it is, it isn't capable of developing such tools. You are advocating for the removal of the only way to currently genreate 64-bit binaries in D. The only other solution is mingw, and honestly those tools aren't nearly as polished as one run by a company with almost limitless resources. If you don't want to deal with Visual Studio, I'll deal you one better, why are you bothering to deal with Windows at all? If you don't like Microsoft so much just switch to Linux, there your problem is solved. You can't even install Visual Studio on Linux. 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). It's really not that difficult, you install it and it pretty much just works. The only problem case is if you install D before you install Visual Studio. Wow 3.5 GB, that's so much! If only there were TB HDDs at an affordable price, oh god why does it have to be so big to install! Anyways maybe I just don't see it as a problem cause I have to download much much bigger files. Good thing you don't play games cause they are getting into the 80 GB range nowadays. 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? Your on the Windows platform, not support Windows tools is annoying and you aren't going to find better tools. If you don't like the way Microsoft does business, you have 2 other platforms you can go to. Buy a Mac or boot up Linux. Just stop making Windows a worse platform by suggesting to drop support for the official development tools. There is no "better way". Every other way is going to be worse cause Windows doesn't have as big of a community dabbling in building tools like GCC and Clang for Windows. Why? Cause there's Visual Studio. Like I said, ideals are nice and all but people still need to get shit done. That's what your argument boils down to, the ideal of finding a better way than what is currently available. The problem is you aren't even suggestion a better way, you are just trying to sell it on the false belief that there is something better. But there isn't. This is worse than religion.. Why don't you like VS, cause they changed something? Rofl, whenever there is change people hate it. Cause people don't like change, for the only reason that they don't want to learn something new. I don't know how many times I teach someone a hotkey that's way better than their current method and they just keep going with their horribly slow method cause that's what they know. And download size? I could say why are you even on Windows, Linux is like 20 GB smaller download size and takes up less HDD space than Windows. So why the hell are you even on Windows? Oh yah once you install it you don't have to worry about it for years on end. You want to drop support for VS cause of something you spend once doing and then pretty much never have to do again for years to come. Please no, just switch to Linux and let the people that actually need to use the Windows platform, use it effectively.
Re: Note from a donor
On Saturday, 28 October 2017 at 09:20:40 UTC, MrSmith wrote: error: test.obj: The file was not recognized as a valid object file Ah, forgot to pass -m64 to dmd
Re: Note from a donor
On 2017-10-28 08:11, Brad Roberts wrote: The issues weren't compiling dmd but passing the full test suite. Both are required. Yes, I've run the test suite as well, DMD, druntime and Phobos. -- /Jacob Carlborg
Re: Note from a donor
On Friday, 27 October 2017 at 16:05:10 UTC, Kagamin wrote: With this the only missing piece will be the C startup code (mainCRTStartup in crtexe.c), though not sure where it's compiled. How do I get lld-link to link .obj files? Clang itself emits .o files, and those link successfully. For .obj files ./lld-link test.obj error: test.obj: The file was not recognized as a valid object file
Re: Note from a donor
On Thursday, 26 October 2017 at 20:44:49 UTC, Adam Wilson wrote: The XCode installer DMG is 5GB, before unpacking. And unlike VS17, I can't pick and choose. :) btw. (and I do realise we've gone way of the topic of this original thread)...but... if it interests anyone, this is the outcome of yesterday, where I wasted my whole day trying to get DMD to compile a 64bit .exe on a fresh install of Windows 7. (and ..I had to muck around with service packs, and .NET frameworks and stuff before hand too). It's the *minimum* 'selection set' you'll need (with regards to the Visual Studio Build Tools 2017) in order to get DMD to sucessfully compile a 64bit exe (-m64) Now to be fair, this is assuming you **don't** want and **don't** have VS installed, but just want the necessary 'build tools' so that DMD can build a *64bit* binary on Windows - (in total about 3.5GB). Code tools Static analysis tools Compilers, build tools, and runtimes VC++ 2017 v141 toolset (x86,x64) SDK's, libraries and frameworks Windows 10 SDK (10.0.16299.0) for Desktop C++ [x86 and x64] Windows 10 SDK (10.0.16299.0) for UWP: C#, VB, JS Windows 10 SDK (10.0.16299.0) for UWP: C++
Re: Note from a donor
On Saturday, October 28, 2017 07:12:13 Paulo Pinto via Digitalmars-d wrote: > Visual Studio 2017 has native support for cmake as project format. > > It is also the new official format for Android NDK development. > > So we are quite ok with using cmake. :) That definitely sounds like an improvement. The place I was working at before is still on VS 2010. :| - Jonathan M Davis
Re: Note from a donor
On Saturday, 28 October 2017 at 03:00:16 UTC, Jonathan M Davis wrote: 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 Visual Studio 2017 has native support for cmake as project format. It is also the new official format for Android NDK development. So we are quite ok with using cmake. :)
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: 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.
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: 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_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.
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.
