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
