Re: Martin Nowak is our new release czar
On Thursday, 5 February 2015 at 03:33:40 UTC, Manu wrote: On 5 February 2015 at 10:07, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Please throw your hat in the air with me to hail the new czar! :o) Huzzah! Or should I say... Huczar! Vive le Dzar!
Re: This Week in D: Issue #4
On Wednesday, 4 February 2015 at 14:14:27 UTC, Adam D. Ruppe wrote: On Wednesday, 4 February 2015 at 13:50:54 UTC, wobbles wrote: the vet was able to treat it and it looks like she'll make a full recovery over the next month as she puts the weight back on. Wow. She is a fighter. Glad to hear that everything is OK now.
Re: This Week in D: Issue #4
On Tuesday, 3 February 2015 at 05:53:30 UTC, Jeremy DeHaan wrote: On Monday, 2 February 2015 at 04:57:10 UTC, Adam D. Ruppe wrote: I've never liked the phrasing about destructors. Yes, they are not guaranteed to run, but isn't that only during run time? They are going to be called at the application exit to ensure everything is cleaned up. I would rather go with the term finalizers for those in D. A maybe useful link that quite clearly defines some concepts: http://sanjaysainitech.blogspot.com/2007/06/difference-between-destructor-dispose.html
Re: This Week in D: Issue #4
On Tuesday, 3 February 2015 at 09:08:07 UTC, eles wrote: On Tuesday, 3 February 2015 at 05:53:30 UTC, Jeremy DeHaan wrote: On Monday, 2 February 2015 at 04:57:10 UTC, Adam D. Ruppe wrote: A maybe useful link that quite clearly defines some concepts: http://sanjaysainitech.blogspot.com/2007/06/difference-between-destructor-dispose.html And this: http://stackoverflow.com/a/8299222/1284631
Re: My D Cookbook on sale: $5 ebook from the publisher
On Sunday, 28 December 2014 at 21:59:17 UTC, Mathias LANG wrote: On Sunday, 28 December 2014 at 21:13:50 UTC, Adam D. Ruppe wrote: I just noticed they temporarily reduced the price of my book: Nice ! Time to finally get mine :) One more client here :)
Re: [OT?] C compiler written form scratch in D
On Tuesday, 9 December 2014 at 10:54:22 UTC, Robert M. Münch wrote: On 2014-12-09 00:45:41 +, deadalnix said: On Monday, 8 December 2014 at 15:44:55 UTC, Stefan Koch wrote: Any link? I tried to google it but it's such a generic word etc. no luck. http://linux.die.net/man/1/cat It was a joke. Could also say notepad on Windows.
Re: forum.dlang.org is now using DCaptcha
On Thursday, 4 December 2014 at 08:20:27 UTC, Kagamin wrote: On Thursday, 4 December 2014 at 02:29:39 UTC, Faux Amis wrote: tries to differentiate between human wanting to learn D and one not wanting. the latter is just a myth...
Re: Mono-D v2.5 - dub buildTypes
On Thursday, 16 October 2014 at 23:32:22 UTC, Alexander Bothe wrote: Cheers thanks to everyone, Alex What a hardwork are you doing, Alex! Kudos!
Re: D2 port of Sociomantic CDGC available for early experiments
On Wednesday, 8 October 2014 at 00:18:16 UTC, Walter Bright wrote: On 10/7/2014 3:27 PM, Leandro Lucarella wrote: Walter Bright, el 7 de October a las 13:06 me escribiste: On 10/6/2014 9:51 AM, Dicebot wrote: That's a good idea, but I hate environment variables affecting all D executables. They always wind up being inadvertently LD_LIBRARY_PATH ?
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Sunday, 5 October 2014 at 21:53:08 UTC, eles wrote: On Sunday, 5 October 2014 at 21:13:01 UTC, Kagamin wrote: On Friday, 3 October 2014 at 11:25:59 UTC, eles wrote: it) and a new-comer on the scene is Tranglu, that I just *Tanglu http://www.tanglu.org/en/
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Thursday, 2 October 2014 at 11:12:12 UTC, Kagamin wrote: On Thursday, 2 October 2014 at 07:43:54 UTC, eles wrote: update-manager -d It works. Does it perform package upgrade? The comments are rather scary: --- Hi, I have installed Linux mint 15 with Mint4Win as Dual boot with Windows 7. Then upgraded it to Mint 16 and it was running fine. But when I upgrade to Mint 17 (Qiana), after restarting the partition loop0 (or loopback0 or something like that) fails to load. It shows an error like, Press I to ignore, S to skip or M for manual recovery. Hi, A bit of news here, as just updated my knoledge about Linux Mint Linux Mint Debian Edition. In short, from this discussion and its comments: http://segfault.linuxmint.com/2014/08/upcoming-lmde-2-to-be-named-betsy/ Linux Mint Debian abandons its (semi-)rolling model and will basically become just a kind of Ubuntu, but based on Debian Stable (Ubuntu, AFAIK, is based on Debian Unstable). The will require full-upgrades every 2 years, but the upgrades shall be smooth (no reinstall required). For two years, you will not need to do such upgrade, just the basic security upgrades and some updates (mainly browser and email clients). Linux Mint, starting from version 17, marks a departure from previous releases (this is why you migh have encountered difficulties in upgrading) by keeping the same code base (Ubuntu 14.04 LTS) for the next 5 years. So, during this time, it will basically be a rolling-distribution, as some software will get updated just as regular (security fixes etc.) happens. Probably, after those 5 years, they will change the code base to the next Ubuntu LTS, which will start a new 5-years long upgrade. One piece of advice: Debian Testing might seem (by the name) more secure than Debian Unstable. The truth is that the latter is more up-to-date and receives security fixes first (they are entering the Debian Unstable first, then they are pre-validated before going in Debian Testing). More, Debian Unstable is not as unstable as its name might tell but, yes, it requires you messing sometimes (read: maybe once every three months) with the apt-get and vim. But is not such a big deal.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Sunday, 5 October 2014 at 21:13:01 UTC, Kagamin wrote: On Friday, 3 October 2014 at 11:25:59 UTC, eles wrote: Debian and Debian-based asks you to confirm file overwrite (usually, the diff is displayed too). Isn't it the same package manager? It should be able to do the same on mint. Or may be fstab can be copied somewhere and then back at some point? It should be the same, but I am never sure about the homegrown patches that the Mint team applies (for example, they applied that patch that presents update packs). Truly rolling or only security updates? Actually, a kind of releases, every 6 months, but that only comes down to updating the Mint plug-ins and a selected handful of programs (probably, browser, update manager and e-mail clients). There is no much difference wrt a rolling release, because the code base does not change. Basically, the releases will be nothing else that some glorified update packs, so basically the same that LMDE does today. Call it a semi-rolling. At least this is my understanding of it. Well, I'm ok with a fresh install. My advice is to wait a bit for the new LMDE to get out. Installing LMDE now as the current model approaches its end of life is not the best, since mostly sure, you'll have to do it again since they change the code base (from testing to stable). But can it run under the target linux itself? Or rather what to run from the disk? Since mint4win installation is a virtual disk, I'm not sure the installer will find it gracefully, they're usually partition-oriented. Not sure if this eliminates problem with fstab though. Sorry, I have no direct experience with Mint directly, I extrapolate my understanding of other distribution to it, from the comments. Could not answer to those questions as they require first-hand experience. Anyway, if you feel a bit adventurous, the current LMDE model is somewhat continued by a distribution called SolidXK (google it) and a new-comer on the scene is Tranglu, that I just installed in a VM and which looks very promising (a mix of Debian Stable, Testing and Unstable, release-style, but hopefully with undisruptive upgrades).
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Friday, 3 October 2014 at 07:16:14 UTC, Kagamin wrote: On Thursday, 2 October 2014 at 12:44:08 UTC, eles wrote: I doubt. At least, not easily. However, installing LMDE should be a one-time process (it's a rolling distribution). Do rolling distributions guarantee to not overwrite fstab? How mint package update differs from a rolling distro package update? Debian and Debian-based asks you to confirm file overwrite (usually, the diff is displayed too).
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Friday, 3 October 2014 at 17:20:11 UTC, Brad Roberts via Digitalmars-d-announce wrote: On 10/3/2014 3:25 AM, David Nadlinger via Digitalmars-d-announce wrote: On Friday, 3 October 2014 at 07:16:14 UTC, Kagamin wrote: On Thursday, 2 October 2014 at 12:44:08 UTC, eles wrote: My oldest system at this point is about 8 years old and has been ubuntu since it was born and still is. It's current and has rolled through every intervening version quite easily Yes. Ubuntu was not perfectly upgrading at its beginnings, but with years that passed they became better and better at this.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Thursday, 2 October 2014 at 11:12:12 UTC, Kagamin wrote: On Thursday, 2 October 2014 at 07:43:54 UTC, eles wrote: update-manager -d It works. Does it perform package upgrade? The comments are rather scary: --- Hi, I have installed Linux mint 15 with Mint4Win as Dual boot with Windows 7. Then upgraded it to Mint 16 and it was running fine. But when I upgrade to Mint 17 (Qiana), after restarting the partition loop0 (or loopback0 or something like that) fails to load. It shows an error like, Press I to ignore, S to skip or M for manual recovery. Please tell me a way to fix this. Or let me know if it is not possible. --- Looks like my case. Are fstab and mtab replaced during upgrade? You should drop Mint, they have a quite disruptive policy, but they are kinda unique in the Linux world. Better choice in the Mint world would be LMDE: http://www.linuxmint.com/download_lmde.php You simply made the wrong choice in the beginning.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Thursday, 2 October 2014 at 12:06:16 UTC, Kagamin wrote: On Thursday, 2 October 2014 at 11:40:31 UTC, eles wrote: Well, it looked popular and easy. Sorry. It's just that everything that glitters... Can I upgrade my mint to lmde? I doubt. At least, not easily. However, installing LMDE should be a one-time process (it's a rolling distribution). Alternatives are: Arch Linux, Debian Testing and a couple of others. Anyway, most of the release-based distribution (Mint is a special case) support upgrading, even if not rolling distributions (for example, Ubuntu). I have not much experience with Mint (none, in fact), but even in the case of a full and disruptive upgrade they should preserve your settings and documents. However, I disclaim responsibility as I don't know how it works.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Wednesday, 1 October 2014 at 13:41:43 UTC, JN wrote: On Wednesday, 1 October 2014 at 05:09:45 UTC, Nick Sabalausky wrote: I find it ironic that it's another big global security hole about which Windows users don't even have to be concerned about. That's of course very true, since Windows runs on no serious servers.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Wednesday, 1 October 2014 at 14:44:06 UTC, Kagamin wrote: On Wednesday, 1 October 2014 at 05:09:45 UTC, Nick Sabalausky wrote: Does it affect dash? No. It is a bashism, ie an extension specific to Bash. Busybox users are not concerned neither. A pity, on windows one can roll new software versions as long as they are maintained. It depends on the software (many abandoned Windows XP while still officially supported) and you shall not ask about the quality of this software neither. Is not the same effort that goes into legacy versions that it goes into newer versions. BTW updating software on Windows is the PITAst of all ever (except maybe some medieval tortures). You have to install software manually, software after software. The first thing that I love in Linux is the centralized update.
Re: [OT Security PSA] Shellshock: Update your bash, now!
On Wednesday, 1 October 2014 at 16:57:07 UTC, Kagamin wrote: On Wednesday, 1 October 2014 at 15:45:26 UTC, eles wrote: Repositories of the not latest version of the OS. Because only latest version receives development. That is, if the OS doesn't have rolling updates. What is the difference wrt Microsoft phasing out a Windows version? Except tha upgrading from Windows to Windows is such a PITA that even the Brazen Bull seems to be just a nice couch.
Re: 438-byte Hello, world Win32 EXE in D
On Monday, 8 September 2014 at 07:01:19 UTC, Andrej Mitrovic via Digitalmars-d-announce wrote: On 9/7/14, Vladimir Panteleev via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: I guess this is great news for virus writers. :P A std.virus or core.virus module? ;;) Nothing sweeter than having it as a standard...
Re: DVM - D Version Manager 0.4.3
On Tuesday, 2 September 2014 at 20:05:21 UTC, eles wrote: On Tuesday, 2 September 2014 at 19:46:32 UTC, Jacob Carlborg wrote: That would indeed make install even easier. And, especially, updates.
Re: core.stdcpp
On Saturday, 30 August 2014 at 00:01:50 UTC, Mike wrote: On Friday, 29 August 2014 at 16:54:18 UTC, Sean Kelly wrote: On Wednesday, 27 August 2014 at 09:43:03 UTC, Mike wrote: On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: I'm judging by both the responses in this thread and the lack of responses in this thread that there isn't support, so I'm fine to go my own way with my ideas if that's what's preferred. Actuall, I am very much in favor of this, but I admit we are a bit in minority. I fel it is not because people ara gainst it, but because they feel is not very important. Plus, they have the impression that this will involve renaming modules and will need modifying curent source code. It is not about that. Names could remain just as they are, it is only about isolating that part of druntime that is really critical to run the language. As you defined very well, that part that corresponds to java.lang. There is one thing that bothers me, still, and I did not find the appropriate solution to it: if the language defines threads and garbage collector, I agree the mechanism for those should go in the runtime, but what to do with the function required to handle those? For example, creating a thread is done with a function (not with a keyword!) and the same goes for the GC.disable(), for example. So, this will kinda break the runtime means no imports mantra. Or, otherwise, how to do it? C++ fully accepted its dependency on stdlib when they wen with Threads, isn't? I find it uneasy that one accesses the runtime through import. Why we should need that? In C you never import/include something for the runtime, nor you have control over it from inside the program. It is through compiler params.
Re: Blog post on hidden treasure in the D standard library.
On Saturday, 30 August 2014 at 11:27:13 UTC, Jonathan M Davis wrote: On Sat, 30 Aug 2014 10:44:18 + safety0ff via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Saturday, 30 August 2014 at 07:59:16 UTC, Gary Willoughby wrote: There is no question that failing to capitalize the letter i when it's used as a pronoun is bad English, and there's no way that anyone fluent Actually, IIRC (not native English speaker here), it was once told me that the symbol for I (first person) is a different one, something like a half of circle, but in print we use I for convenience, as it is pronounced the same and it is the most similar too. But, that teacher of mine, in handwriting, always depicted the I like a kind of ].
Eclipse D Development Tools (DDT) plug-in version 0.10.2 released
This release is really amazing. Among the main changes: - Updated to CDT 8.4, thus fully compatible with Eclipse Luna release series and takes many advantages of it (for example, added Dynamic printf action to DDT editor ruler) - Very much improved integration with DUB, allowing code navigation through all files of the DUB project - Compatible with Arch Linux packages for DMD/GDC/LDC - Mouse hovering over an auto keyword will show the resolved type - Many bug fixes Highly recommended for Eclipse IDE users as DDT comes on par with CDT. My honest impression: it was good until now, but from now on it just entered the excellence period. Project page: https://code.google.com/p/ddt Full changelog: https://github.com/bruno-medeiros/DDT/releases/latest Installation instructions: https://github.com/bruno-medeiros/DDT/blob/latest/documentation/Installation.md#installation Eclipse install update site: http://updates.ddt.googlecode.com/git Congratulations to Bruno Medeiros for his most excellent work!
Re: Programming in D book, User Defined Attributes (UDA) chapter
On Thursday, 28 August 2014 at 21:07:00 UTC, Olivier Henley wrote: Super! Huge thx for all the nice work btw. Questions: 1. Does the book have been entirely translated then..? Here, the answer is Yes Ali's work is impressive.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 07:52:18 UTC, Daniel Murphy wrote: eles wrote in message news:ybcxmuwwpsiyupwer...@forum.dlang.org... Requiring full c/OS bindings in druntime is so useful, and it costs us so little. But the request is simply to split the current druntime in a language-runtime and a phobos-runtime. The namespace and so on might even remain the same and the existing code would run unmodified. What is really important is that a clear separation exists between the two *inside* the implementation. The users of D are not concerned about that, the compiler designers are. Have, as now, the language-runtime + the phobos-runtime calles as druntime. Why does bother you a re-modularization of druntime? Besides a warm fuzzy feeling, not requiring them seems to only benefit D implementations for theoretical platforms that probably don't exist. One such platform exists and is the embedded system, others are the linux kernel and the like, and even others are writing D compiler back-ends and, yes, druntimes (well, exactly the part that it is called phobos-runtime above). If you make porting harder, then you can safely bet that those ports won't ever exist. But is this truly what we want?
Re: core.stdcpp
On Wednesday, 27 August 2014 at 06:50:19 UTC, Walter Bright wrote: On 8/26/2014 5:32 PM, Mike wrote: Moving it back in an endless search for taxonomical perfection Well, keeping things in limbo for such many years (@property, anyone?) is not going to help neither. I agree it is a fine balance between changing for better consistency and conserve for compatibility. Still, some changes are small and would solve problems for the many years to come. I still cannot forget that decision to keep the flawed std.uni name instead of a std.unicode name. It wasn't even costly. But, well... And one day from now you will write The paradox is that at one moment we decided to keep the std.uni name because of taxonomical compatibility etc. etc. etc.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 06:12:54 UTC, Mike wrote: On Tuesday, 26 August 2014 at 05:03:01 UTC, Daniel Murphy wrote: Mike wrote in message news:sdrjfagsayomsngme...@forum.dlang.org... line between the language and the platform. Make it a more of a language, and less of a framework. Apparently, all things have this tendency to get bloated. One of the main reasons for C's still unbelievable success is its slimness.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 07:56:45 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 26 August 2014 at 07:06:57 UTC, eles wrote: convenient inlining and operator overloading. So people use it For me, what it would be really nice to have in C from C++ would be templates. And from D, that scope(). I bet D would have been slimmer if it had been part of a OS project, but my gut feeling is that it is more work to slim down D than C++. I think D would greatly benefit from a high level IR that various D dialects could compile to. Then analyse the high level IR to determine what the runtime requirements are. The problem with starting designing (and implementing) frameworks instead of languages is that you have to keep up with everything and to never cease expanding. New needs will appear, new paradigms (platforms, distributed systems and so on) and you will have to play the game. It is OK to provide extensive standard library, but not put too much into the language (and, for me, the druntime shall be seen as part of the language, not of the framework). But, still. Even Java and C# have a separation between the language and the framework, more than, for example, Go has.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 15:30:35 UTC, Mike wrote: On Tuesday, 26 August 2014 at 14:48:48 UTC, Andrei Alexandrescu wrote: On 8/26/14, 3:06 AM, Mike wrote: The same goes for core.stdc and core.sys.linux and friends, as these are not part of D's language implementation. Am I correct to define the language as: begin file--- //no imports here //any code here - ? If you import, then is the library.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 18:13:01 UTC, eles wrote: On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote: On 8/26/2014 8:30 AM, Mike wrote: wow. I remember the hot debate about the name o the standard library back then. well, namesace name
Re: core.stdcpp
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote: On 8/26/2014 8:30 AM, Mike wrote: Regardless of where stdcpp goes, one issue is that the stuff in it goes into the namespace std, which conflicts with Phobos' std higher level package name. wow. I remember the hot debate about the name o the standard library back then. Remember proposition dsl (D standard library) anyone? and your (sad) comment: Nobody likes phobos :)
Re: core.stdcpp
On Tuesday, 26 August 2014 at 17:09:58 UTC, Walter Bright wrote: On 8/26/2014 8:30 AM, Mike wrote: There's never going to be a clear distinction between druntime and phobos. The original reason for the split anyway was druntime would be a Well, in C there is and I like that distinction: the runtime handles everything that doesn't need a #include, and that is: - formatting and passing the arguments to main() - replacing some constants (IIRC) at runtime, especially those with sizeof(array) While the distinction between druntime and phobos is one thing (and you are right that it was about Tango vs Phobos, because otherwise Tango was reimplementing those parts in a Phobos-incompatible ways, which prevented programs to use both), now the discussion is more about (c-like) runtime vs (c-like) standard library.
Re: core.stdcpp
On Tuesday, 26 August 2014 at 18:33:07 UTC, Daniel Murphy wrote: Mike wrote in message news:bkkdiikafdsraqssj...@forum.dlang.org... I really don't see a practical problem with having them in druntime, only a philosophical one. It give the impression that D requires the C standard library, the C++ standard library, and an full-featured desktop OS in order to function. If I create a port without core.stdc, it can be argued that my port is incomplete. Well I argue that my port is a complete implementation of the language and core.stdc is not part of the D language. What platform supports threads and GC but doesn't have a C lib available? I certainly would argue that this hypothetical port is incomplete, not because druntime including bindings to libc declares it part of the language, but because I can't see a good reason not to include them. Then they can be put in their own library instead of phobos. Yes, they could. IMO the downsides of having to maintain a third library outweighs the 'correctness' advantage, or even having a different root package for this stuff. And there is no way it's ever going to change at this point. That's even better as far as I'm concerned. GTKD isn't part of phobos or druntime. I don't see libc as being any different (in principle) than GTKD. Druntime doesn't use GTK, so it is different. The inclusion of C/OS bindings is historical, and not worth changing. and they are used in druntime internally. For a practical implementation, those ports that have a libc can make use of it, but it should be internal, and isolated from the language implementation and the other ports, as is the spirit of 11666. There is no point as the bindings are already in druntime and there is very little chance that is going to change. But you could take it a step further for the principled approach. Implement those few features of libc that are needed by the druntime in D, and earn some bragging rights. You could, but it has very little practical value. I personally wouldn't waste my time bragging to someone who thinks druntime depending on libc is an argument against D. Why create DDMD? We already have an implementation in C++, right. What a waste of time... (of course I'm being facetious. Forgive me, but I think it's a great example of why we should do something in D even though a C/C++ implementation exists. No offense intended) It's possible you missed the point of DDMD. DMD is an actively developed codebase which can benefit from many of the features D offers. Well, that was my motivation anyway. I know other people got excited by the idea for other reasons. There is no practical advantage (to the project) from converting a fully debugged, optimized application or library to another language, unless the language barrier is preventing interop. A libc written in D would not give us anything of practical value. That's exactly my point. The debate that ensued with 11666 had nothing to do with the spirit of 11666. If those OS bindings weren't in druntime, 11666 would already be implemented without controversy. And we'd likely already have a few more ports of D to other platforms. The 11666 debate belongs in a std.linux debate or a liblinux debate or some other OS API port debate. No, the exact same thing would have happened if they were in a different package/repository. A different root package would not change the contributors or contribution process. Publicly exposing core.stdc and the OS bindings in druntime is getting in the way of bringing D to more platforms, and the 11666 debate demonstrates that. This is just nonsense. Changing the root package changes nothing. Or those features in libc could be implemented in D, removing the artificial dependency on libc. Re-implementing debugged and optimized code is a waste of time. Only the *port* should have bindings to libc. The language implementation should not. Again those bindings should be encapsulated in the port, not publicly exposed as part of the D language. 1) Being part of druntime does not automatically mean something HAS to be available on every platform. eg the windows bindings are not available on non-windows 2) I don't see any point in not exposing the c lib from druntime, nor do I see any platform where that would be a problem that does not have much more serious issues with hosting D. * It conflates the language with the platform. druntime should be solely the implementation of the language, not an OS API. I disagree, having the OS API in druntime is great and not a problem. * It conflates the implementation of the language with bindings for external libraries. C interop is part of D. Low level (direct) access to operating system APIs is part of D. Exposing them is useful. Again, druntime is the language implementation, not an application programming framework. By this logic the C lib header
Re: core.stdcpp
On Tuesday, 26 August 2014 at 19:22:22 UTC, Daniel Murphy wrote: eles wrote in message news:qrfucjdbmydvoqgey...@forum.dlang.org... Apart from the fact that it's too late to change of course. Well, that separation is just a detail of the implementation, not of the specification. You could simply say that phobos has several namespaces: std, etc, core. Druntime and phobos both had c/OS bindings at some point (core.stdc + std.c) but duplication is bad, so they were/are being moved into druntime. The question of dupplication may be addressed now better, since the newly fixed bug about hierarchical packaging. In druntime you have the true, hidden runtime code (startup, profiler, coverage, unittesting, AAs), plus core language stuff (GC, Thread (+core.time)). _only that_ should be the runtime. And the sole part that one needs to port in order to claim having a full port of the D language (that is, the compiler). These are the tires of the cars, the things that touch the ground. Everything else is optional. (Pirelli had a nice advertisemnt with this line) And, to go further, only c/OS bindings required for this are to be embedded at this level. Phobos is supposed to be 100% optional, although it isn't, quite. If you don't want to use phobos, for example if you are automatically porting a large C++ application, it's nice to simply ban phobos and have that clear distinction. Phobos shall be 100% optional, otherwise you don't have a language, but a framework. This is the separation line: the runtime is a must for the language, the standard library is not. If in doubt wether one piece belongs, cut here.
Re: core.stdcpp
On Wednesday, 27 August 2014 at 00:32:20 UTC, Mike wrote: On Tuesday, 26 August 2014 at 18:28:38 UTC, Andrei Alexandrescu wrote: No. We currently have std.c and core.stdc. Let's not even say this is confusing.
Re: D for the Win
On Wednesday, 20 August 2014 at 21:43:26 UTC, Walter Bright wrote: On 8/20/2014 2:33 PM, anonymous wrote: Dlang Dlang Über Alles as a German, O_O I'm not surprised that the German programming community has taken to D. After all, German cars all have those D stickers on them :-) French must be such great fans of functional programming, on the other hand. F# anyone?
Re: D 2.066 is out. Enjoy!
On Thursday, 21 August 2014 at 01:30:52 UTC, ketmar via Digitalmars-d-announce wrote: On Wed, 20 Aug 2014 10:18:09 -0700 Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: What is it that we could help with? -- Andrei he's drama queen, he doesn't need any help, only attention. Just let's try to be less harsher. Even if that's true, being harsh would be of no good for that person and for us neither.
Re: D for the Win
On Wednesday, 20 August 2014 at 22:02:31 UTC, anonymous wrote: On Wednesday, 20 August 2014 at 21:43:26 UTC, Walter Bright wrote: On 8/20/2014 2:33 PM, anonymous wrote: Dlang Dlang Über Alles as a German, O_O I'm not surprised that the German programming community has taken to D. After all, German cars all have those D stickers on them :-) No, no, Dlang Dlang Über Alles is a take on Deutschland Deutschland über alles (Germany Germany over everything), the first verse of the national anthem as sung in Nazi times. While I agree with the historical significance, there are some things to be straighten: 1) the song was used even before: it was the national anthem of the Weimar republic, the one that Nazi toppled 2) today, it's third stanza (the first one begins with DDuA) is still the official anthem of Deutschland 3) there is no official interdiction of the first two stanzas, except that they are not really protected by the German law punishing offenses to the national symbols of Germany
Re: D 2.066 is out. Enjoy!
On Wednesday, 20 August 2014 at 09:15:54 UTC, disapointed user wrote: the the syntax getting ever weirder, less mainstream and a While I agree with some of your remarks (particularily, the fact that it becomes too scripting language) ... where to go? I don't like Go (syntax, mainly). The sole contender in the C++-like family, for systems programming, would be Vala, but since they dropped the posix profile... :(
Re: D 2.066 is out. Enjoy!
On Monday, 18 August 2014 at 19:23:14 UTC, Dicebot wrote: I don't know if we can do anything better about it. 2.067
Re: Digger can now build D versions from the future
On Tuesday, 1 April 2014 at 07:01:20 UTC, Vladimir Panteleev wrote: Although this might sound like an impossible feat which would violate causality, recent advancements in D-wave quantum tunnelling have made this possible and safe (mostly), and I've put together a simple implementation. I would like to confirm the feature, it works on my machine, too. May I suggest a name change in order to mark such breakthrough? I suggest Shovel, which is far more romantic than Digger. BTW, does it support the soon-to-come git SHA-512 hashes? This would guarantee compatibility with future version of git, too.
Re: DUB 0.9.21 beta 3
On Monday, 27 January 2014 at 12:38:06 UTC, Sönke Ludwig wrote: Am 27.01.2014 13:14, schrieb Sönke Ludwig: - Use the closest matching import folder to infer the module name instead of the first match (i.e. ./libev instead of . in this case). Implemented: https://github.com/rejectedsoftware/dub/commit/5d0867fef7c6415e300c6ce214aa5790d0a2ca93 Would it be reasonable to add dub edit to automatically edit the package/dub.json file?
Re: Dmitry Olshansky is now a github committer
On Thursday, 23 January 2014 at 17:38:04 UTC, Andrei Alexandrescu wrote: Congratulations to Dmitry! (His github ID is blackwhale.) Congrats to Dmitry!
Re: dmd 2.065 beta 1
On Tuesday, 21 January 2014 at 00:30:30 UTC, bearophile wrote: Andrew Edwards: When submitting bug reports associated with this review, ensure they are earmarked [REG2.065-b1] or [BUG2.065-b1] for easy identification, retrieval and merger. So far I am not finding many bugs in this. But when is the work on 2.066 going to start? There are many patches. And what's the focus (if it has one) of D 2.066? I suggest to warn/deprecate all that should be deprecated (built-in sort, old operator overloading, etc), and introduce some of the little breaking complex numbers -property
Re: EMSI is hiring a D developer
On Monday, 16 December 2013 at 10:24:33 UTC, John Colvin wrote: On Monday, 16 December 2013 at 02:04:56 UTC, Justin Whear wrote: On Sunday, 15 December 2013 at 23:54:12 UTC, Brian Schott wrote: On Sunday, 15 December 2013 at 23:34:55 UTC, eles wrote: In British English, the Russian Moscow is pronounced Moss-coe. The Russians themselves call it Москва, pronounced Moskva. *pronounced Maskvà
Re: EMSI is hiring a D developer
On Monday, 16 December 2013 at 11:52:16 UTC, John Colvin wrote: On Monday, 16 December 2013 at 11:18:49 UTC, eles wrote: On Monday, 16 December 2013 at 10:24:33 UTC, John Colvin wrote: On Monday, 16 December 2013 at 02:04:56 UTC, Justin Whear wrote: On Sunday, 15 December 2013 at 23:54:12 UTC, Brian Schott wrote: On Sunday, 15 December 2013 at 23:34:55 UTC, eles wrote: o. ɐ is equivalent to an english short 'u'. The best way to properly pronounce it is to get the Russian citizenship. :P
Re: EMSI is hiring a D developer
On Saturday, 14 December 2013 at 01:42:09 UTC, Justin Whear wrote: On Saturday, 14 December 2013 at 01:29:08 UTC, Adam D. Ruppe wrote: On Saturday, 14 December 2013 at 01:25:09 UTC, Justin Whear wrote: this position will be working primarily with me, so I can answer any specific questions for the curious. Does it offer remote (work from home)? Meeting together regularly and physically is part of our company culture, so no, you'd have to move here. Moscow, Idaho Err... Is that in Russia or in the USA? :D
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote: eles: Speaking about that, why DMD's source files are written in C++ but bear extension .c? You seem to appreciate for yourselves a freedom that he denies to others. Thank you for bringing that good example. Forbidding arbitrary extensions for D code, and enforcing a common standard name helps avoid mistakes like those .c extensions in the C++ sources, that numerous persons keep criticizing. The advantages of a standard suffix for D code are way larger than the disadvantages. A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth Well, then God created humans...
Re: Start of dmd 2.064 beta program
On Tuesday, 10 December 2013 at 09:44:38 UTC, Frustrated wrote: On Thursday, 31 October 2013 at 15:39:27 UTC, eles wrote: On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring wrote: Am 31.10.2013 16:22, schrieb eles: On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring Why not simply rename .d to . then compile, rename back using a script? It might add a few extra seconds for very large projects but otherwise insignificant and should work most of the time. Basically you'll use the script or wrapper app instead of whatever compile you are using. You are overreacting to a maybe bad joke, but I must say that I really love the solution you propose. Is even better than the one with hardlinks. The only thing that I don't have yet is a third hand to keep the window open while my fifth foot is doing some tricks with the a crow's nest. This would be quite a workable workaround, don't you think?
Re: Build Master: Progress toward 2.065
On Tuesday, 10 December 2013 at 13:01:50 UTC, Dicebot wrote: On Tuesday, 10 December 2013 at 12:57:10 UTC, Andrew Edwards wrote: cherry-picking is discouraged in that scenario as it will complicate merging 2.065 branch back into master after release. rebase sounds like best fit. Or just dropping and start again. For a first try is OK to do several trials until the things get on track.
Re: DConf 2014 Call for Submissions is now open
On Friday, 6 December 2013 at 10:09:47 UTC, Jacob Carlborg wrote: On 2013-12-06 09:35, Mike Parker wrote: I never said how big they are :) http://resources2.news.com.au/images/2010/09/12/1225919/806894-largest-glass-of-beer.jpg http://3.bp.blogspot.com/-XZwz2Zhbprk/TiGeoXHygxI/Hb8/GWyQhp0Stzc/s640/World%25E2%2580%2599s+Largest+Beer+Can.jpg
Re: DDT 0.9.0 released - GDB debugging integration
On Tuesday, 19 November 2013 at 13:15:43 UTC, Bruno Medeiros wrote: On 18/11/2013 15:32, ilya-stromberg wrote: On Monday, 18 November 2013 at 15:28:36 UTC, Jacek Furmankiewicz wrote: Quick question: with the current version is it possible to use it with a dub project at all (maybe via a manual project setup)? I was trying to manually set it up, pointing sources as the source folder and trying to get the ~/.dub/packages into the list of libraries, but it did not seem to like it... Yes, manual setup is possible, but you must use absolute path without `~`. Exactly, although you can use some Eclipse resource variables in the path of linked folders. why this? https://github.com/bruno-medeiros/DDT/commit/b7a57f9e0d7915734ba6b175acfc1fd53a7a92f4
Re: DDT 0.9.0 released - GDB debugging integration
On Monday, 2 December 2013 at 15:55:22 UTC, Bruno Medeiros wrote: On 02/12/2013 10:35, eles wrote: On Tuesday, 19 November 2013 at 13:15:43 UTC, Bruno Medeiros wrote: On 18/11/2013 15:32, ilya-stromberg wrote: On Monday, 18 November 2013 at 15:28:36 UTC, Jacek Furmankiewicz wrote: The commit it reverted was not meant to go to master, but to a branch. The idea is that master is to be kept potentially shipable at all times, and dub support is not ready (nor was it disabled in the original commit, which is another way that it could be allowed to be commited to master). Uf! I thought that you dropped the idea of dub support. Glad to hear that you did not.
Re: Facebook puts bounties on bugs in the D programming language implementation
On Monday, 18 November 2013 at 01:49:57 UTC, Andrei Alexandrescu wrote: On 11/17/13 9:38 AM, John J wrote: On 11/15/2013 12:51 PM, Andrei Alexandrescu wrote: I see D is a language with C-like syntax and static typing. It pragmatically combines efficiency, control, and modeling power, with safety and programmer productivity. Probably added Short it to D is better than better C++/Java/C#. Combined. :P
Re: dmd 2.064 release candidate 1
On Monday, 4 November 2013 at 08:35:26 UTC, Jacob Carlborg wrote: On 2013-11-04 09:03, Walter Bright wrote: http://ftp.digitalmars.com/dmd.2.064.zip http://ftp.digitalmars.com/dmd.2.064.dmg http://ftp.digitalmars.com/dmd_2.064-0_amd64.deb http://ftp.digitalmars.com/dmd-2.064-0.fedora.i386.rpm http://ftp.digitalmars.com/dmd-2.064-0.fedora.x86_64.rpm http://ftp.digitalmars.com/dmd_2.064-0_i386.deb http://ftp.digitalmars.com/dmd-2.064-0-i386.pkg.tar.xz http://ftp.digitalmars.com/dmd-2.064-0.openSUSE.i386.rpm http://ftp.digitalmars.com/dmd-2.064-0.openSUSE.x86_64.rpm http://ftp.digitalmars.com/dmd-2.064-0-x86_64.pkg.tar.xz Another 5 months waiting? http://d.puremagic.com/issues/show_bug.cgi?id=11365
Re: dmd 2.064 release candidate 1
On Monday, 4 November 2013 at 13:09:10 UTC, Leandro Lucarella wrote: eles, el 4 de November a las 09:37 me escribiste: On Monday, 4 November 2013 at 08:35:26 UTC, Jacob Carlborg wrote: On 2013-11-04 09:03, Walter Bright wrote: Is sad Yes , but it makes sense, this is a new feature that wasn't even merged or properly tested yet Just to note that this looks quite promising: http://d.puremagic.com/test-results/pull-history.ghtml?projectid=1repoid=1pullid=2700 (True, tests are not designed for this kind of change...) , so it shouldn't be included at a beta stage. Let's just hope next release won't take that long. Well, I hope. Also for various other compilers using the fronted, smaller gap between releases would make their maintainers' lives easier. A 2-month gap between releases?
Re: Start of dmd 2.064 beta program
On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote: On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: http://d.puremagic.com/issues/show_bug.cgi?id=11365 Thank you for considering it. I am amazed how such a simple issue is provoking unbelievable philosophic discussion attempting to find the best way to bite your own tail while running circles around a tree.
Re: Start of dmd 2.064 beta program
On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote: On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: Thank you for considering it. I cannot comment on the bugzilla, but frankly I do not like those comments at all. Why cannot I name my scripts like: script.no1 script.no2 script.no3 ? Must always use script_no1 or script_no1.d? What is this conservationism? You have a very nice way to cut a programmer's arms and legs and then yell at him why he does not run or swim faster. Just let the poor guy name the scripts how he really likes it. Speaking about that, why DMD's source files are written in C++ but bear extension .c? You seem to appreciate for yourselves a freedom that he denies to others.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:16:22 UTC, eles wrote: On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote: On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: You seem to appreciate for yourselves a freedom that he denies to others. And +1 for Leandro. The day that D was declared to serve some useful purpose is the day when D gave up the right to be just a toy. Hey! I work in production! Somebody hears that?
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote: eles: Thank you for bringing that good example. Forbidding arbitrary extensions for D code, and enforcing a common standard name helps avoid mistakes like those .c extensions in the C++ sources, that numerous persons keep criticizing. The advantages of a standard suffix for D code are way larger than the disadvantages. In projects, not in scripts. C/C++ not used for scripts.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:16:22 UTC, eles wrote: On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote: On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: Thank you for considering it. I cannot comment on the bugzilla, but frankly I do not like those comments at all. Why cannot I name my scripts like: script.no1 script.no2 script.no3 ? Must always use script_no1 or script_no1.d? And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. I am bitter about this.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote: eles: Bye, bearophile Well, then allow just extension .d or NO EXTENSION, but consider files named like: script.no1 script.julia script.no5 just as being standard names without any extension (you may see for yourself that there is no extension since they lack the final .d). D is a wonderful language for which creators try hard to make the worst of tools.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious better try to find a more experienced, serious Boss Do you offer yourself for his job? Maybe because I don't want to have a code base written in several languages? And seriously, about your former argument about the importance of the extension in being serious or not: accepting arbitrary extension was the reason for C++ doom? Seriously, I never hear somebody citing that the purpose why D exists is to correct the C++... file extension problem. I hear about a lot other reasons, but not this one.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious i don't get it You never wrote git extension scripts, isn't? Then write and you will get it.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious - maybe, maybe not - but not because of your stupid file extension comments It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me. question: why are you using D if OH, I forgot to add: I HAAATE PYTHON. I do not care if it works. Assembler works! I hate it! I like D (the language, not the compiler ;). I *want* to use D. Why don't *you* use ASM? Go and write in machine code! IT WORKS!
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: Finally, you've said a few times that D has crappy tooling. I am not sure how this file naming stuff has anything to do with that (other than superficial ways). Go to that bug report, read the very first message that Walter used to open the bug report, see about yourself, then come back here and tell me that the .d thing does not matter. It is the *very* reason for this debate. As to quote Walter's own understanding of the problem (unfortunately, the solution he proposed is bad): Thanks for the clear explanation. It makes a lot of sense.. Now, if you disagree with that, you disagree with Walter.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:57:43 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh eles, seeing your post above, I guess my use of Python to justify my answer turns out to a bad choice on my part :o) That's true. I hate using it, especially because I am still force to use it when writing tests because of its py.test module. I simply don't like it. I want pointers in my code.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring wrote: 3. My boss is right: is just a toy pretending to be serious better try to find a more experienced, serious Boss Do you offer yourself for his job? why should i? Then don't tell me what I should feel to do about my job. 'Cause you don't deserve other answer than why should I?
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 14:45:46 UTC, Dicebot wrote: File content should have nothing to do with extension, it is as good part of name as any other. Adding any extra meaning to it is just some DOS legacy. When I first came to Linux I was wondering how the OS knows it should execute some file that wasn't bearing the .exe/.com extensions. And who tells the OS this is an executable file? How could Linux know it without the .exe or .com at the end? Well, I was DOSwashed.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring i don't see any chance/strategy to get D in your current development - so if you don't want to code Python (I WANT pointers) anymore - try to find a job where you can write C/C++ or D - or else your need (and real hard interest to get your Boss in the Boart) for D seems to be not big enough - i would quit my job very fast if someone forces me to write Python code most of the time - thats all Frankly, just stop advising me to take a new job. It is the kind of advice that I really find intrusive and unbearable. I do critical software and is 90% C. Is for embedded devices that are great chances that you already used. I use Python for py.test because it is the company policy and tradition, but I am not forced to like Python. Let's keep the discussion in the terms of languages, not personal problems. I would never allow myself to tell you what you should do with your car, house, job or life. BTW, my boss is very kind and nice, but he is concerned about how the tools would increase productivity. It is he who is responsible for the budget in front of, guess it, his boss. Otherwise, no, I would simply quit D instead of my job. And this neither, I don't want to do it. Please, stop advising me in matters that I consider should remain of my personal competence.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh Really, I can see why you want the suggested change, I am just surprised at the level of importance you seem to be ascribing to it. Maybe because it is a real problem? Usually, those who take such matters lightly never really encounter them. And it is easy to give advice about somebody's else teeth ache. You know, the usual: c'mon, you scream too hard, it *cannot* hurt that much. Well, this is true, it does not hurt anyone, except the one who really has his teeth broken. But the others are quite insensitive to it. That's the story about the .d suffix.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: Furthermore, reading the Bugzilla entry, it seems there as many who support your idea as those who disagree. If you are sick about to die in an hospital, would you like the medical treatment for you to be established through a majority vote involving the whole city population, or on the professional doctors that *really know* what your health problem is about? Just ask the question: how many of you expressing advice did you really encounter this problem and felt about it? It is so easy to offer advice about things that do not really hurt you, but only others.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring wrote: Am 31.10.2013 16:22, schrieb eles: On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring wrote: Am 31.10.2013 16:01, schrieb eles: On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring wrote: Am 31.10.2013 15:45, schrieb eles: On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring wrote: Am 31.10.2013 15:29, schrieb eles: On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring no problem :) so tell the story what would happen if D scripts will be without .d? is your Boss then more interested or can you introduce D-scripts then silently - what would happen? He won't really care as long as I don't ask him to modify his scripts to update the names of those used by me. The latter are already hard-coded in his and others. Yes, this has a solution: use of hardlinks (of identical-content, different name files). I already explained and acknowledged that in the very first post. But is cumbersome and unpleasant and bad for backup-ing.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: I could also argue that this issue is a with git requiring a 'git-' suffix on its scripts without providing users with some means of overriding the file naming convention (maybe this is already possible, I have only minimal git experience)! BTW, git is not requiring a git- suffix, but a git-prefix. It does not matter for git what the git-name here script extension (or name) use. It matters to the one typing git commands, because he has to type: git name here in order for git to invoke git-name here behind. I really don't feel like git is doing anything bad here or it should change. It matters, however, if one is allowed to type: git tellmethelotterynumbers instead of being forced to type git tellmethelotterynumbers.d You see, the latter version will give you the numbers spelled as: 16.d, 32.d, 18.d, 5.d, 11.d and 22.d Or, it happens, the state lottery won't deny you the prize because, guess, the real numbers that were extracted were 16, 32, 18, 5, 11 and 22.
Re: Start of dmd 2.064 beta program
On Thursday, 31 October 2013 at 16:12:44 UTC, eles wrote: On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh wrote: On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote: On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh wrote: Or, it happens, the state lottery won't deny you the prize *will :P
Re: dmd 2.064 beta 4
On Monday, 28 October 2013 at 10:13:22 UTC, Manu wrote: On 28 October 2013 17:29, Walter Bright newshou...@digitalmars.com wrote: On 10/27/2013 10:09 PM, Manu wrote: Refer to Don's talk. Removing hacks in build scripts (or any code) is usually met with rejoice :) While we are at it: std.complex vs complex literals?
Re: dmd 2.064 beta 4
On Monday, 28 October 2013 at 17:16:42 UTC, Walter Bright wrote: On 10/28/2013 9:56 AM, Iain Buclaw wrote: On 28 October 2013 14:36, eles e...@eles.com wrote: Also, asking for such changes really doesn't belong in the beta thread. Yes, sorry about that. Anyway, the bikeshed is still out there for painting.
Re: Start of dmd 2.064 beta program
On Friday, 25 October 2013 at 20:24:48 UTC, Walter Bright wrote: On 10/25/2013 6:15 AM, eles wrote: Breaking peoples' build scripts and makefiles is not nice :-) On the same grounds, you could recommend them dmc. Provide, at least, a flag that passes the file without name change, for example: dmd -ntest will really pass test file and not test.d. Why working so hard to do a good language if you work even harder to provide the worst of tooling?
Re: Start of dmd 2.064 beta program
On Friday, 25 October 2013 at 15:57:27 UTC, Namespace wrote: On Friday, 25 October 2013 at 13:24:12 UTC, eles wrote: On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright When was decided to add this? I would love it, but I cannot remember that this was decided. Well, like many other ideas of its kind, Walter expressed sympathy for it, then fall into oblivion... Unfortunately, D puts a lot of effort in doing great things, but all the nice nuts and bolts that would make our life easire and require no more than one LOC change in dmd's source tend to be forgotten. Somebody complained about lack of vision in D development. Don't be upset on me, but I really feel the same. People come, tried to do things... and left.
Re: Start of dmd 2.064 beta program
On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: I'm curious why naming the file test.d is an issue? Case: This forces scrpts to bear the .d extension. For example, if you write a script on Linux named git-test and you put at the top: #!rdmd rdmd will pass its name to dmd, and dmd will try to compile... git-test.d, which does not exist. Now, you have either to rename the git-test into git-test.d, or to create a hardlink named git-test.d that points towards git-test so that dmd finally gets satisfied its .d hungriness. The solution with the hardlink carries the well-known burdness of redundancy, let's not even say its idiot and makes back-up-ing a mess. OTOH, renaming the original script into git-test.d has the undesirable effect wrt to git software. git uses some nice convention that you can extend its command list by writing your own git-command1, git-command2 scripts and they are invoked automatically by git when you type: git command1 (this will invoke git-command1) etc. The problem with being forced to rename git-command1 into git-command1.d is that, afterwards, you have to type the following command for git: git command1.d (in order to have the git-command1.d invoked, as git-command1 simply does not exist or, if it would exist, dmd would be blind about it). SO, you cannot type git command1 and to have a git-command1 script invoked, because git won't search for git-command1.d, while dmd won't compile git-command1. So you need both git-command1 and git-command1.d doing the same thing, just to be able to type git command1 (not even say that this allows you to invoke, also git comman1.d, which is ugly and undesired redundancy). Now, immagine yourself having to type: git checkout.d . git commit.d git log.d instead of git checkout . git commit git log and tell me that .d is not an issue. Please have a look at the original thread that I linked and you'll see the problem. What use for scripting in D if I am unable to do some simple scripts because of the compiler?
Re: Start of dmd 2.064 beta program
On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote: On 10/26/2013 2:02 AM, eles wrote: On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote: On 10/26/2013 12:42 AM, eles wrote: http://d.puremagic.com/issues/show_bug.cgi?id=11365 Thank you for considering it.
Re: Start of dmd 2.064 beta program
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: It is a specific reason why this is kept?: http://forum.dlang.org/thread/ohduisigpwdiqhpde...@forum.dlang.org#post-btwbpwgluzyxmhphwebp:40forum.dlang.org
Re: Start of dmd 2.064 beta program
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote: http://ftp.digitalmars.com/dmd2beta.zip Current list of regressions: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED And the famous int[$] x = [1,2,3]; to declare static arrays and force the compiler to compute the length?
Re: Mono-D v0.5.4.5 - More dub support
On Wednesday, 23 October 2013 at 10:18:41 UTC, Misu wrote: Thank you. I really enjoy using D with Xamarin ! Also for Android/iOS? Could you post some short howto leading to a toy app? Thanks
Re: Start of dmd 2.064 beta program
On Friday, 18 October 2013 at 06:36:43 UTC, Jacob Carlborg wrote: On 2013-10-17 22:35, Andrej Mitrovic wrote: - Walter is still not tagging the beta releases by the file name (it's always dmd2beta.zip). I've complained about this several times and IIRC someone else did as well at dconf (maybe I'm remembering wrong though). They should at least be named as dmd2_064_beta1.zip, dmd2_064_beta2.zip. And all of them should always be available for download (including visibility on the download page), so people who do not use Git or build manually from master can quicky check whether a regression was introduced in a specific beta version. Please make it dmd.2_064_beta1.zip and dmd.2_064_beta2.zip instead. This will automatically make it compatible with DVM. The important thing here is dmd.whatever. IIRC, Walter wanted that file to always be named dmd.zip or dmd2.zip or whatever, in order to allow a permanent download link, while guaranteeing the file to be the latest version of the tool. In this case, I think the best compromise is simply to have the latest version download-able either as dmd2.zip and as dmd2.version.zip.
Re: GHC 2013 in Paris
On Thursday, 8 August 2013 at 19:25:45 UTC, Iain Buclaw wrote: On Monday, 22 July 2013 at 00:16:13 UTC, bioinfornatics wrote: I'm speaking on the 24th in the afternoon, so I guess you get what you wished for. :) I'll be there just in time for Hurd, and stay until the end of the day. Looking forward.
Re: GHC 2013 in Paris
On Tuesday, 16 July 2013 at 11:02:10 UTC, Iain Buclaw wrote: Hi, I have been scheduled in to do a talk about GDC at GHC 2013 next month in Paris. If anyone can make it down, would be great to see some D faces around. http://www.gnu.org/ghm/2013/paris/ Hi, Do you know if you will speak on Friday 23, or on Saturday 24? Thanks.
Re: Announcing bottom-up-build - a build system for C/C++/D
On Monday, 1 July 2013 at 03:26:22 UTC, Graham St Jack wrote: On Thu, 27 Jun 2013 22:49:41 +, Graham St Jack wrote: Fixed the problem, and also: * split bub.d up into several smaller files, * added a Makefile to bootstrap the building of bub, and * added a bub.cfg and Bubfile as a trivial example of how to use bub. Please add an install: target to the Makefile. Thank you.
Re: Announcing bottom-up-build - a build system for C/C++/D
On Thursday, 27 June 2013 at 05:44:16 UTC, Rob T wrote: One issue I immediately ran into, is when I run bub incorrectly it hangs after writing the bail message to console. ctrl-c does not kill it, and I have to run a process kill commandto terminate. CTRL-Z works for me. I think it expects input.
Re: Announcing bottom-up-build - a build system for C/C++/D
On Thursday, 27 June 2013 at 07:32:32 UTC, eles wrote: CTRL-Z works for me. I think it expects input. Ignore it. It just suspends it.
Re: DConf 2013 Closing Keynote: Quo Vadis by Andrei Alexandrescu
On Tuesday, 25 June 2013 at 08:21:38 UTC, Mike Parker wrote: On Tuesday, 25 June 2013 at 05:57:30 UTC, Peter Williams wrote: D Season of Code! Then we don't have to restrict ourselves to one time of the year. D Seasons of Code! Why to restrict to a single season? Let's code all the year long! :)
Re: [Phoronix] D Language Still Showing Promise, Advancements
On Friday, 21 June 2013 at 13:16:07 UTC, Paulo Pinto wrote:
On Friday, 21 June 2013 at 12:01:31 UTC, Dicebot wrote:
On Friday, 21 June 2013 at 11:13:49 UTC, Paulo Pinto wrote:
This is why Microsoft killed C in their tooling. Unless they
change their mind, C++ will be the lowest you can get in a few
Visual Studio interactions.
As long as you still can wrap everything in extern C {} for
mangling purposes and that you have all those standard C
headers... it is C++ only by the name.
Re: [Phoronix] D Language Still Showing Promise, Advancements
On Friday, 21 June 2013 at 14:16:44 UTC, Paulo Pinto wrote: On Friday, 21 June 2013 at 13:52:58 UTC, eles wrote: On Friday, 21 June 2013 at 13:16:07 UTC, Paulo Pinto wrote: On Friday, 21 June 2013 at 12:01:31 UTC, Dicebot wrote: On Friday, 21 June 2013 at 11:13:49 UTC, Paulo Pinto wrote: As anecdote, back when MS-DOS 5 was the latest version of OMG, did those days really exist? I only knew 6.22...
Re: Vote started for std.uni
On Tuesday, 21 May 2013 at 01:25:54 UTC, deadalnix wrote: On Monday, 20 May 2013 at 17:19:34 UTC, Dmitry Olshansky wrote: 20-May-2013 12:15, deadalnix пишет: uni can be unicode, but also unique, union, unit, uniform, unix, unijambist, whatever. I support renaming to std.unicode; In the long run, std.uni is just unexpressive.
Re: D 2.062 release
On Monday, 18 February 2013 at 01:31:47 UTC, Mike Parker wrote: On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: I've lost the motivation to even look at the changelog now. +1
Re: DIP22 : Private symbol visibility
On Monday, 28 January 2013 at 17:05:38 UTC, Dicebot wrote: http://wiki.dlang.org/DIP22 Error on that page (for C++): public Default one, if you can see symbol - you can access it That is true only for structs. For classes, private is the default. See also this: http://stackoverflow.com/questions/1247745/default-visibility-of-c-class-struct-members
Re: D 1.076 and 2.061 release
On Friday, 4 January 2013 at 06:08:02 UTC, Leandro Lucarella wrote: Walter Bright, el 3 de January a las 19:18 me escribiste: On 1/3/2013 12:27 PM, Leandro Lucarella wrote: BTW, Changelogs looks extremely naked now, I think release Bugzilla is for internal development, not to inform people about new features. I couldn't agree more. As the documentation is also a *developement task*, Bugzilla could still be used as a tool for improving the documentation development. However, let's not mistake the tool for the outcome. Pushing it to the extreme, one could simply fill to the user the compiler, instead the documentation for the compiled language: you'll read the source code and you'll be able to figure out what it compiles and what it does not.
Re: D 1.076 and 2.061 release
On Friday, 4 January 2013 at 06:24:37 UTC, Walter Bright wrote: On 1/3/2013 9:54 PM, Jonathan M Davis wrote: And here's the list: http://d.puremagic.com/issues/buglist.cgi?chfieldto=2012-12-31query_format=advancedchfield=resolutionchfieldfrom=2012-08-02chfieldvalue=FIXEDbug_severity=enhancementbug_status=RESOLVEDversion=D2version=D1%20%26%20D2resolution=FIXEDproduct=D Two concrete examples: http://d.puremagic.com/issues/show_bug.cgi?id=5992 is described in the list as: Phobos Win64 - D2 ; At least, change its title to something more human, like Win64 alpha has been released with working Phobos. (yes, that's exactly Don's comment, but at the end of the discussion). http://d.puremagic.com/issues/show_bug.cgi?id=5269 is described as: version(assert). Only if you read the discussion you understand that version(unittest) that allows setup code for assertions to run when assertions are enabled and be compiled out when assertions are disabled was implemented. It is very different thing to see version(assert) and reading a meaningful description of it...
