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: hacky way to get explicit default constructor on struct :P
On Saturday, October 28, 2017 16:59:03 LunaticWare via Digitalmars-d wrote: > Event if there is no default constructor on struct we can still > make one that work as well as if it were implemented, here is my > example n__n This idiom gets suggested from time to time, and I'm sure that it gets used some, but AFAIK, it's never really caught on much. I think that it's something that tends to look nice at first for someone looking for a default constructor but that ultimately, you're better off with other solutions. Using static opCall allows you to get MyType() to work, but given that it doesn't get used in a lot of the places a default constructor would need to be used, it's a lot more limited in usefuleness, and it could be argued that it would be less error-prone to just create a named factory function for this to make it more obvious that that's what's going on, given how normally MyType() and MyType.init would be identical, whereas they wouldn't be in a type with a static opCall. Certainly, if you're relying on MyType() to be called as the way that your struct is constructed, then you're just asking for trouble. This just gives a way to have a no-arg constructor when you're explicit about it. If you're truly looking for a default constructor, then you need to rethink how your code works. Also, this idiom doesn't work if you declare any constructors. In that case, you're forced to either declare static opCalls for every constructor you want, or you have to use a factory function for the no-arg constructor instead of a no-arg static opCall so that you can declare actual constructors for the other constructors. If you you declare both a static opCall with no parameters and a constructor, you get an error like this: q.d(3): Error: struct q.S static opCall is hidden by constructors and can never be called q.d(3):Please use a factory method instead, or replace all constructors with static opCall. - Jonathan M Davis
Re: Required Reading: "Functional Programming in C++"
On Saturday, October 28, 2017 21:51:50 Ola Fosheim Grøstad via Digitalmars-d wrote: > On Wednesday, 25 October 2017 at 22:19:21 UTC, Walter Bright > > wrote: > > for core D devs. Of course, this is much easier in D than in > > C++ because of D's const and pure attributes. > > Nah, the type system isn't critical for doing functional style > programming. People who want to do functional programming in C++ > has plenty of opportunities, and libraries to support it… The type system can help ensure the correctness of functional programming (e.g. pure helps ensure that you didn't accidentally do something involving global variables), but it's certainly not required to write in that style. And actually, most D code that's functional doesn't do much with either const or pure. Most of the functional code is range-based, which fundamentally falls apart with const - at most, const or immutable is used for the elements. And while pure is often involved, it's typically only by inference. So, in those cases, the only places that pure actually gets checked is in unittest blocks marked with pure or when you try to use a set of range-based operations inside of a function that you've marked as pure. And range-based operations that definitely aren't pure are done on a regular basis (e.g. any lazy ranges grabbing their elements from I/O). So, arguably, D is already showing how unnecessary const and pure are for functional programming. They can help, to be sure, but they aren't necessary. - Jonathan M Davis
Re: druntime unittest failing under wine
On Saturday, October 28, 2017 19:06:29 Dmitry Olshansky via Digitalmars-d wrote: > On Saturday, 28 October 2017 at 18:58:50 UTC, Andrei Alexandrescu > > wrote: > > I am using wine to build our Windows toolchain on Linux per > > https://wiki.dlang.org/Building_under_Posix. After building > > dmd, I tried to unittest druntime: > > > > wine make -f win32.mak > > > > and got this: > > > > core.exception.AssertError@src\core\sync\mutex.d(380): unittest > > failure > > > > Is this reproducible? Does anyone have an attack on this? > > Wine is not particularly stable emulation software when it comes > to testing Windows. > > I’d recommend using Windows evaluation for server in a virtual > machine. 180 days for free + prolongation. Depending on what you're doing, wine can work, but it's not trustworthy at all. I originally developed std.datetime's Windows implementation in wine and had to fix stuff later as a result, because wine didn't act the same way, and I'm fairly certain that the std.datetime unit tests will fail in wine right now because of some places where it doesn't match Windows. I definitely run some stuff using wine, but at this point, I'd never develop anything using wine. It's far too risky. IMHO, at best, it might make sense to develop something initially in wine and then go fix it up in Windows later, but if you accidentally depend on some buggy behavior in wine, you could end up wasting a lot of time trying to fix it in Windows. And assuming that something developed using wine will work in Windows is just asking to shoot yourself in the foot. I'm all for fixing issues we find where something works in Windows but not wine so long as the fix doesn't negatively affect running stuff in Windows, but in general, if something doesn't work in wine that worked in Windows, the wine guys have a bug. Granted, the wine guys have a really nasty job to do to get everything working, and they've arguably worked miracles to get where they are, but the end result still has lots of problems. Some stuff works well, and other stuff doesn't work at all - and most annoyingly, those two things could swap between two releases of wine. - Jonathan M Davis
Re: delete & its deprecation
On Friday, 27 October 2017 at 19:03:01 UTC, Jonathan M Davis wrote: On Friday, October 27, 2017 12:30:58 bauss via Digitalmars-d wrote: Are there any plans to completely remove the delete keyword so members of ex. a class can be called delete? Or is there still code within DMD or Phobos that uses it? It's been the plan for ages that delete was to be deprecated, but no one has ever bothered to do it. Part of the problem has been that while it was possible to construct a class into memory allocated with something other than new and than destroy it later, it was actually pretty difficult to get right. If it weren't for that, I probably would have pushed for its removal ages ago. However, now that we have std.experimental.allocator, things have changed a bit, and it should be far more reasonable to get rid of delete. But still, someone has to actually go and deprecate it, and I think that it's more or less been forgotten. Nothing in Phobos uses delete, and it looks like the only place that uses delete in druntime is some unit tests. I doubt that any of the core D developers have done anything with delete in years, which would be part of why it's easily forgotten. I know that I tend to forget that it's even part of the language. - Jonathan M Davis It certainly doesn't help when there are bugs regarding destroy function. -Alexander Heistermann
Re: Required Reading: "Functional Programming in C++"
On Wednesday, 25 October 2017 at 22:19:21 UTC, Walter Bright wrote: for core D devs. Of course, this is much easier in D than in C++ because of D's const and pure attributes. Nah, the type system isn't critical for doing functional style programming. People who want to do functional programming in C++ has plenty of opportunities, and libraries to support it… "Functional Programming in C++" by John Carmack 2012, and it doesn't really say anything, does it?
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: druntime unittest failing under wine
On Saturday, 28 October 2017 at 18:58:50 UTC, Andrei Alexandrescu wrote: I am using wine to build our Windows toolchain on Linux per https://wiki.dlang.org/Building_under_Posix. After building dmd, I tried to unittest druntime: wine make -f win32.mak and got this: core.exception.AssertError@src\core\sync\mutex.d(380): unittest failure Is this reproducible? Does anyone have an attack on this? Wine is not particularly stable emulation software when it comes to testing Windows. I’d recommend using Windows evaluation for server in a virtual machine. 180 days for free + prolongation. Thanks, Andrei
druntime unittest failing under wine
I am using wine to build our Windows toolchain on Linux per https://wiki.dlang.org/Building_under_Posix. After building dmd, I tried to unittest druntime: wine make -f win32.mak and got this: core.exception.AssertError@src\core\sync\mutex.d(380): unittest failure Is this reproducible? Does anyone have an attack on this? Thanks, Andrei
Re: D for microservices
On Saturday, 28 October 2017 at 14:55:25 UTC, aberba wrote: On Sunday, 22 October 2017 at 02:48:57 UTC, Joakim wrote: I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux: "For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)" https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550 It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet. Its the future. Highly doubt that. It really depend on the scale of your operations. Netflix, Google, Facebook, etc. all have open source tools around microservices. Its currently ruled by JavaScript > Go > Java. JavaScript being the leader. They have these in common: 1. Easy to deploy their code in docker containers including alpine Linux. Interestingly while Docker may seem all the rage in startups I find its use limited to test environments in the real world. Also Java fat jars were super easy to deploy ages before docker. They are also a great deal smaller. 2. They have APIs for major cloud services. Both official and third-party. 3. Good support for networking. HTTP, Websockets, IPC*, etc. Mostly HTTP. Honestly APIs these days can be written in anything that is able to put together a few HTTP responses. Unless you are doing serious work like: - DBs - Search engines - ML pipelines - Real-time event processing systems Any semimodern language/technology with a several hosts can manage to saturate 1Gbit link. Some take a certain amount of tuning others work out of the box. If you go for 40gbit/s it may be important to choose the right technology otherwise it’s all a matter of taste.
Re: Project Elvis
Wait? You are saying D does not support this yet? Wow :D. I have been using this so often in work (PHP) so I can beleive I have not miss this On Sat, Oct 28, 2017 at 2:39 PM, bauss via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote: > >> Walter and I decided to kick-off project Elvis for adding the homonym >> operator to D. >> >> [...] >> > > This is honestly going to be a great addition. >
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 ;-)
hacky way to get explicit default constructor on struct :P
Event if there is no default constructor on struct we can still
make one that work as well as if it were implemented, here is my
example n__n
--
import std.format;
import std.stdio;
struct Player
{
string name = "Baz";
float[2] position = [0, 0];
// Adding an explicit constructor to struct =)
// But we can't enforce it since this relies on it =(
static ref auto opCall(string name = "Bar", float x = 1,
float y = 1)
{
// Even if we give no argument opCall will still be
called ;)
writefln("Entering the explicit constructor as '%s'",
name);
// Taking advantage of the implicit constructor
Player self;
// Initializing all the members
self.name = name;
self.position[0] = x;
self.position[1] = y;
// Returning the reference of the object
return self;
}
string toString()
{
return format("Hello i am '%s' and at the coordinate x%s
/ y%s",
this.name, this.position[0], this.position[1]);
}
}
void main()
{
auto foo = Player("Foo", 2.7, 10.6);
auto bar = Player();
Player baz;
writefln("%s\n%s\n%s", foo, bar, baz);
}
// == RDMD OUTPUT ==
// Entering the explicit constructor as 'Foo'
// Entering the explicit constructor as 'Bar'
// Hello i am 'Foo' and at the coordinate x2.7 / y10.6
// Hello i am 'Bar' and at the coordinate x1 / y1
// Hello i am 'Baz' and at the coordinate x0 / y0
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: D for microservices
On Sunday, 22 October 2017 at 02:48:57 UTC, Joakim wrote: I just read the following two week-old comment on the ldc issue tracker, when someone tried to run D on Alpine linux: "For now everything works(?) but I think the process could be improved.. Would be really cool to have LDC easily building alpine containers + static D binaries for microservice and tooling development. I'm pretty tired of reading Go code :)" https://github.com/ldc-developers/ldc/issues/2341#issuecomment-334626550 It strikes me that microservices are a great way for new programming languages like D to get tried and gain some uptake, but that D might not be that easy to deploy to that scenario yet. Its the future. Netflix, Google, Facebook, etc. all have open source tools around microservices. Its currently ruled by JavaScript > Go > Java. JavaScript being the leader. They have these in common: 1. Easy to deploy their code in docker containers including alpine Linux. 2. They have APIs for major cloud services. Both official and third-party. 3. Good support for networking. HTTP, Websockets, IPC*, etc. Mostly HTTP. That's it. The major advantages besides the hype. Lets see about D based on these requirements. 1. Kind of. There are dmd-ldc-dub docker images on docker hub. One by sociomantic. None using Alpine Linux as base though. Most people prefer alpine cus its lightweight (not a requirement). 2. Nope. Official APIs comes when there's mass adoption for that language and has good ROI. No complete and production ready cloud services API that I know of. Seems D users in that area roll out something on their own for private use with features they need. But most cloud PaaS provide support for custom runtimes which D has one for Heroku. Major candidate is Google AppEngine. 3. Phobos doesn't have a D HTTP API. Its sad but we have "requests" at code.dlang.org which works. We have vibe.d for http servers (aka nodejs of D) and seems popular based on threads about it and downloads. So this is a question for those deploying microservices, as I'm not in that field, what can the D devs do to make it as easy as possible to get D microservices up and running, make some Docker and Alpine containers with ldc/dub/vibe.d preinstalled publicly available? What else, what kinds of libraries do you normally use? There several database APIs at cods.dlang.org. I don't know why some complain about no db APIs. This is a niche that D and all newer languages should target. How do we do it? Good question.
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: So why double to float conversion is implicit ?
On Sunday, 22 October 2017 at 14:59:41 UTC, Andrei Alexandrescu wrote: On 10/22/17 9:41 AM, User wrote: Is there a list of such quirks or gotchas in dlang? The ones I know of are 1. Implicit conversion from double to float 2. Integer division results in integer result truncation the fractional part. These are not gotchas, as TDPL explains. One unpleasant related gotcha is implicit conversions across signedness and comparison of integral types with different signedness. -- Andrei Shouldn't all these be documented?
Re: AWS SDK
On Wednesday, 18 October 2017 at 23:02:27 UTC, Stephan Dilly wrote: On 2017-10-18 22:25:23 +, ikod said: On Wednesday, 18 October 2017 at 20:51:48 UTC, Stephan Dilly wrote: On 2017-10-18 20:19:20 +, ikod said: [...] Are you going to take over the task? --Stephan I'd like, but It depends on the required time investment. I need some time to look at the docs etc... Regards, Igor Hi Igor, I started a little tool (POC) that can parse the API spec and creates types and the API interface only for now: https://github.com/Extrawurst/aws-sdk-dlang-gen Its a start, not tested and does not come with any dependency to vibe or what. AWS specific request signing also needs to be done on top of it. but using that tool the types can be automatically generated. --Stephan I'm really happy about this.
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: Project Elvis
On Saturday, 28 October 2017 at 11:38:52 UTC, Andrei Alexandrescu wrote: Walter and I decided to kick-off project Elvis for adding the homonym operator to D. [...] This is honestly going to be a great addition.
Project Elvis
Walter and I decided to kick-off project Elvis for adding the homonym operator to D. Razvan Nitu has already done a good part of the work: https://github.com/dlang/dmd/pull/7242 https://github.com/dlang/dlang.org/pull/1917 https://github.com/dlang/dlang.org/pull/1918 What's needed is a precise DIP that motivates the feature properly and provides a good proposal for it. I'm no fan of bureaucracy but we really need to be pedantic about introducing language features. Walter argued thusly in a PR, and I agree: "I'm concerned that the elvis operator is not well understood, and we shouldn't be designing it in the comments section here. A DIP needs to be written. Things like operator precedence, side effects, type resolution, comparison with the operator in other languages, grammar changes, lvalues, how it would appear in the generated .di file if it isn't its own operator, etc., should be addressed." A lowering looks like the straightforward approach, of the kind: expr1 ?: expr2 ==> (x => x ? x : expr2)(expr1) Who wants to join Razvan in Project Elvis? Thanks, Andrei
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. :)
