Re: D 2.066 is out. Enjoy!
On 20/08/14 03:41, Andrew Edwards wrote: That was my doing... I am preparing myself for the next go around. The actual branch will be created on Sunday (24 Aug) for a Monday (0900 PDT) announcement. The beta cycle will run eight weeks following that. On the fourth week (22 Sept) I will transition from beta to RC. Betas will be release 5 days apart. RCs will be released 3 days apart. If no regression is fixed during that beta/RC window, the window will be extended an additional 3/5 days (as appropriate) until either fixes are received or the review period ends: at which time the final release is prepared and published. The only thing that will extend the review period is if a regression exiting at the time RC1 is released remains open at the end of the 8 weeks. At that time an additional week will be added to the release cycle to address those specific issues. If they cannot be addressed during that additional week, the cycle will be terminated and the final release published. All regressions not addressed in the main release will be addressed in point releases. Point releases will be published in 2 week increments following the final release (as warranted). I we're letting regressions through in the main release I'm wondering how likely they are to be fixed later. Starting with 2.066, releases will be maintained for 1 year. Meaning, point releases will be published biweekly (as warranted) for 1 year after a major release. The only changes that will be pushed during point releases are known regressions and ICE. To pull this off, I absolutely need the community's assistance. Issues must clearly indicate which version affected by a particular regression. A volunteer to help me track and categorize ice and regressions would do wonders. Also, I need access to publish and upload to the s3 server. I cannot wait around on for files to be synched across servers or web pages to be updated with one word changes before I can take the next step, it is extremely time consuming and deteriorates productivity. Note: there will normally be a 4 week break between release cycles. When a cycle is extended, the break will be reduced to 3 weeks. This particular cycle will start early because 2.066 ended 5 weeks after the planned release date. All this should be written down somewhere in the wiki. -- /Jacob Carlborg
Re: Fix #2529: explicit protection package #3651
On Tuesday, 19 August 2014 at 17:11:19 UTC, Dicebot wrote:
Any specific ideas? I can't imagine any clean solution - and
proposed language extensions fits naturally into existing
system without introducing any new concepts. It is also
somewhat frequently asked about in NG.
---
module std.internal.mod1;
package(std) void foo() {}
module std.mod2;
import std.internal.mod2;
void bar() { foo(); }
---
Isn't it equivalent to
---
module std.internal_mod1;
package void foo() {}
module std.mod2;
import std.internal_mod1;
void bar() { foo(); }
---
Re: Fix #2529: explicit protection package #3651
On Wed, 20 Aug 2014 07:25:43 + Kagamin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: but it requires to dump all 'subpackages' into one flat directory and with ugly names. proposed extension will not break any existing code, yet will allow much nicer hierarchy. signature.asc Description: PGP signature
Re: D 2.066 is out. Enjoy!
On 20 August 2014 02:41, Andrew Edwards via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 8/19/14, 1:26 PM, Andrei Alexandrescu wrote: On 8/18/14, 5:23 PM, Nick Sabalausky wrote: On 8/18/2014 7:14 PM, Dicebot wrote: I also propose to start 2.067 beta branch right now and declare it yet another bug-fixing release. Seconded. Well that's what happened - someone started 2.067. What's the advantage of doing this? Now we need to worry about master and 2.067 instead of just master. -- Andrei That was my doing... I am preparing myself for the next go around. The actual branch will be created on Sunday (24 Aug) for a Monday (0900 PDT) announcement. The beta cycle will run eight weeks following that. On the fourth week (22 Sept) I will transition from beta to RC. Hurrah! Iain
Re: Dutyl - a Vim plugin for running D tools
On Tuesday, 19 August 2014 at 19:03:45 UTC, Idan Arye wrote: Anyways, version 1.0.1 is out with many bugfixes and speedups - including a fix for this problem. I can confirm it works under windows now! Very good job, and thank you for your efforts :)
Re: D 2.066 is out. Enjoy!
thank you general for your selfish and user considered release. the lieutenants probably feel kind of really taken care of - as well as D users. how do you test and release at facebook. i am a user that considers to leave after many years. i am starting to dislike the language, as it is getting blown up and the the syntax getting ever weirder, less mainstream and a support for windows that really sucks. good luck in the future for all you guys On Tuesday, 19 August 2014 at 22:27:28 UTC, Andrei Alexandrescu wrote: On 8/19/14, 3:09 PM, Dicebot wrote: On Tuesday, 19 August 2014 at 21:13:53 UTC, Andrei Alexandrescu wrote: Walter, now that release is out can you please state your opinion about https://github.com/D-Programming-Language/dmd/pull/3651 ? It is blocking Phobos module split and decoupling. LGTM. Any opposition to merging? -- Andrei Walter seems to be the only one :) http://forum.dlang.org/post/lt00a9$2uoe$1...@digitalmars.com I think it would be great to motivate the change properly. -- Andrei
Re: D 2.066 is out. Enjoy!
On Monday, 18 August 2014 at 23:07:27 UTC, ketmar via Digitalmars-d-announce wrote: i myself using dmd-git-head and heavily ;-) patched gdc, but when i tried to convince my co-workers to use D, they looked at the page with releases first. not feature list or some comparisons. neither to buglist. as this is relatively young language, it must have frequent releases with bugfixes and new features! they tolerate some regressions in some releases, but they want to see that releases. don't ask me why they thinking like this. i don't know. but it's the fact. Can't it be addressed by publishing release schedule, like llvm does it, to indicate the work is going on?
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 07:47:36 UTC, ketmar via Digitalmars-d-announce wrote: but it requires to dump all 'subpackages' into one flat directory and with ugly names. Huh? If std.datetime and std.regex are subpackages of `std` package, it usually means, they should reside in `std` directory, no? And how explicit package protection can change that?
Re: D 2.066 is out. Enjoy!
On Wed, 20 Aug 2014 09:19:37 + Kagamin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Can't it be addressed by publishing release schedule, like llvm does it, to indicate the work is going on? hm. sounds reasonable. ;-) signature.asc Description: PGP signature
Re: D 2.066 is out. Enjoy!
On Wed, 20 Aug 2014 09:15:53 + disapointed user via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: support for windows that really sucks. that is 'cause windows really sucks. good luck in the future for all you guys you too. signature.asc Description: PGP signature
Re: Fix #2529: explicit protection package #3651
On Wed, 20 Aug 2014 09:26:36 + Kagamin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Huh? If std.datetime and std.regex are subpackages of `std` package, it usually means, they should reside in `std` directory, no? And how explicit package protection can change that? imagine mybiglib, mybiglib.internal, mybiglib.other, and each of them not single module, but package itself. so we have module mybiglib.other.thingy which wants to use functions from module mybiglib.internal.wisdom, which is part of mybiglib.internal package. signature.asc Description: PGP signature
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 09:26:37 UTC, Kagamin wrote: On Wednesday, 20 August 2014 at 07:47:36 UTC, ketmar via Digitalmars-d-announce wrote: but it requires to dump all 'subpackages' into one flat directory and with ugly names. Huh? If std.datetime and std.regex are subpackages of `std` package, it usually means, they should reside in `std` directory, no? And how explicit package protection can change that? Your proposal makes such module layout illegal: std.package1.module1 std.package1.module2 std.package1.subpackage.module1 std.package1.subpackage.module2 (can't have symbols in subpackage that are also available to package1 but not whole std / public, must have `subpackage_module1` instead, `package_1_subpackage_module1` if it must be available for whole std) It severely limits expressive power of package system for code organization and encourages flat hierarchies with minimal nesting. It also looks ugly - anyone seeing module name with package name mangled in it will feel that there is something wrong with the language if it needs to resort to such hacks.
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 13:05:54 UTC, Dicebot wrote: Your proposal makes such module layout illegal: std.package1.module1 std.package1.module2 std.package1.subpackage.module1 std.package1.subpackage.module2 (can't have symbols in subpackage that are also available to package1 but not whole std / public, must have `subpackage_module1` instead, `package_1_subpackage_module1` if it must be available for whole std) If some utility is internal to std.package1 an used in the entire std.package1, shouldn't it sit in std.package1? Why push it to subpackage? std.package1.module1 std.package1.module2 std.package1.internal - package1's internals go here std.package1.subpackage.module1 std.package1.subpackage.module2
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 09:40:37 UTC, ketmar via Digitalmars-d-announce wrote: imagine mybiglib, mybiglib.internal, mybiglib.other, and each of them not single module, but package itself. so we have module mybiglib.other.thingy which wants to use functions from module mybiglib.internal.wisdom, which is part of mybiglib.internal package. Do we need a hierarchy of internals, is the problem this big? Why mybiglib.wisdom is not good?
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 14:25:59 UTC, Kagamin wrote: If some utility is internal to std.package1 an used in the entire std.package1, shouldn't it sit in std.package1? Why push it to subpackage? std.package1.module1 std.package1.module2 std.package1.internal - package1's internals go here std.package1.subpackage.module1 std.package1.subpackage.module2 It may semantically belong to subpackage but still needs to be available to package1, something not uncommon in templated code (subpackage is generic implementation, package1 is specialization that still needs access to non-public functions). Also you seem to imply that internal is always small tightly coupled module which is hardly true for any higher level functionality. So in practice it will be more like this: std.package1.module1 std.package1.module2 std.package1.internal1 std.package1.internal2 ... std.package1.internal20 Not really encouraging.. What you propose is effectively prohibiting to use packages to organize your code and requiring to design your module hierarchy based on desired protection relations, not other way around. I think it is conceptually wrong approach and unnecessarily restrictive compared to overall D design principles (no single true way of doing things)
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 14:33:53 UTC, Kagamin wrote: On Wednesday, 20 August 2014 at 09:40:37 UTC, ketmar via Digitalmars-d-announce wrote: imagine mybiglib, mybiglib.internal, mybiglib.other, and each of them not single module, but package itself. so we have module mybiglib.other.thingy which wants to use functions from module mybiglib.internal.wisdom, which is part of mybiglib.internal package. Do we need a hierarchy of internals, is the problem this big? Why mybiglib.wisdom is not good? As I see on the realistic example of datetime, which is BIG, we only need to split it into a flat set of files without an overly deep package hierarchy.
Re: Fix #2529: explicit protection package #3651
On Wed, Aug 20, 2014 at 4:33 PM, Kagamin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Do we need a hierarchy of internals, is the problem this big? Why mybiglib.wisdom is not good? It gets really unwieldy when you want to put a whole bunch of things into one project and give control of different packages to different teams. Yes you could use multiple libraries in a lot of cases but if you're wanting it in a single setup / package (like phobos), especially one that is internal to another package you need sub-packages. Examples that would use this are: - kitchen sink libraries like phobos - frameworks such as vibe.d - libraries with lots of internal code such as Ogre3d if it were made in D Well that seems to be good reasons to me.
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 14:36:59 UTC, Kagamin wrote: As I see on the realistic example of datetime, which is BIG, we only need to split it into a flat set of files without an overly deep package hierarchy. We _may_ split it into flat set files (solving only part of the problem) but it is desirable to have a deeper package hierarchy. Package hierarchy is not just an encapsulation tool, it is also a great way to simplify navigation and finding needed modules - something that Phobos is current terrible at exactly because of flat hierarchies.
Re: Fix #2529: explicit protection package #3651
On Wed, 20 Aug 2014 14:33:52 + Kagamin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Do we need a hierarchy of internals, is the problem this big? Why mybiglib.wisdom is not good? ah, why we need such things as subdirectories at all? CP/M was fine without concept of subdirectories! signature.asc Description: PGP signature
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 14:35:31 UTC, Dicebot wrote: It may semantically belong to subpackage but still needs to be available to package1, something not uncommon in templated code (subpackage is generic implementation, package1 is specialization that still needs access to non-public functions). If generic implementation is designed to be customized, it probably means, it should be widely available for customization, like xml document and base64 encoder. Also it's probably a logical error if base type is less visible than the derived type. What you propose is effectively prohibiting to use packages to organize your code and requiring to design your module hierarchy based on desired protection relations, not other way around. I think it is conceptually wrong approach and unnecessarily restrictive compared to overall D design principles (no single true way of doing things) It's ok for packages to exchange public interface, but internals? If a subpackage has internals, they are for its usage, and consumable functionality should be provided through public interface.
Re: D 2.066 is out. Enjoy!
too bad that i wasted my time for such a long time. i post a link to that thread with your answer to everywhere i can, so that others won't waste their time too. anyway good luck in the future for you linux guys. On Wednesday, 20 August 2014 at 09:37:24 UTC, ketmar via Digitalmars-d-announce wrote: On Wed, 20 Aug 2014 09:15:53 + disapointed user via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: support for windows that really sucks. that is 'cause windows really sucks. good luck in the future for all you guys you too.
Re: D 2.066 is out. Enjoy!
On Wednesday, 20 August 2014 at 09:15:54 UTC, disapointed user wrote: thank you general for your selfish and user considered release. the lieutenants probably feel kind of really taken care of - as well as D users. how do you test and release at facebook. i am a user that considers to leave after many years. i am starting to dislike the language, as it is getting blown up and the the syntax getting ever weirder, less mainstream and a support for windows that really sucks. good luck in the future for all you guys Anything specific you have problems with? Syntax changes aren't all that common these days (*dodges rock thrown by Brian Schott*) and Windows support is pretty solid. What I consider to be the last remaining large piece, 32-bit COFF support, was just merged.
Re: D 2.066 is out. Enjoy!
On 8/19/14, 7:28 PM, Brad Anderson wrote: On Tuesday, 19 August 2014 at 11:12:25 UTC, Andrew Edwards wrote: [...] In essence, it was always this big, just you never saw it because it got downloaded during the installation process. It was also significantly bigger before because the download it did was the 30MB dmd zip that contained files for all platform, not just Windows. The installer is LZMA compressed too so it's even smaller than the dmd windows-only zip (16MB). Because of this, download size is now 1/3rd what it was and installation size dropped from 176 MB to just 71 MB. Glad to finally see that one taken care of! -- Andrei
Re: D 2.066 is out. Enjoy!
On 8/19/14, 5:14 PM, Andrew Edwards wrote: Actually you can believe it. I am the one that called for the release and it pay ZERO attention to those two languages with the mild exception that when I have time I crack open a Java book to try to learn a little programming. Yah, to amend my previous post: the release time was chosen by Andrew and the announcement time was chosen by me. Apparently neither of us knew about the other language announcements :o). -- Andrei
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 15:13:06 UTC, Kagamin wrote: On Wednesday, 20 August 2014 at 14:35:31 UTC, Dicebot wrote: It may semantically belong to subpackage but still needs to be available to package1, something not uncommon in templated code (subpackage is generic implementation, package1 is specialization that still needs access to non-public functions). If generic implementation is designed to be customized, it probably means, it should be widely available for customization, like xml document and base64 encoder. Also it's probably a logical error if base type is less visible than the derived type. This is just your design preference and hardly a good one size fits them all decision. I also don't speak about inheritance but about composition - customization may be implemented via unsafe field exposure and unsuitable for general public usage but useful for simplifying internal implementation maintenance. We should not force users into single good package structure based on certain design beliefs. What you propose is effectively prohibiting to use packages to organize your code and requiring to design your module hierarchy based on desired protection relations, not other way around. I think it is conceptually wrong approach and unnecessarily restrictive compared to overall D design principles (no single true way of doing things) It's ok for packages to exchange public interface, but internals? If a subpackage has internals, they are for its usage, and consumable functionality should be provided through public interface. Same here. As library size grows you completely lose the distinction between public and internal, certain parts of the library may become hidden from other parts and public but available for others. It is pretty much a necessity to keep up with maintenance when there is a large team working on it simultaneously. Right now people mostly rely on convention, I have seem quite some comments like should have been private but needs to be accessed from module X, don't ever touch it (public-but-undocumented functions of Phobos sometimes fall into the same category). Telling people that they design applications in a wrong way and need to change their habits is a good approach to alienate them against the language.
Re: D 2.066 is out. Enjoy!
On 8/20/14, 2:15 AM, disapointed user wrote: thank you general for your selfish and user considered release. the lieutenants probably feel kind of really taken care of - as well as D users. how do you test and release at facebook. i am a user that considers to leave after many years. i am starting to dislike the language, as it is getting blown up and the the syntax getting ever weirder, less mainstream and a support for windows that really sucks. good luck in the future for all you guys What is it that we could help with? -- Andrei
Re: Fix #2529: explicit protection package #3651
On 8/20/14, 7:49 AM, ketmar via Digitalmars-d-announce wrote: On Wed, 20 Aug 2014 14:33:52 + Kagamin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Do we need a hierarchy of internals, is the problem this big? Why mybiglib.wisdom is not good? ah, why we need such things as subdirectories at all? CP/M was fine without concept of subdirectories! No need to demean the question. It is valid. -- Andrei
Re: D 2.066 is out. Enjoy!
On 8/19/14, 4:38 PM, safety0ff wrote: I find it hard to believe that it is just a coincidence that a surprise release occurred on the same day as Java 9 and C++14 announcements. For my part I had no idea, and the exact announcement time was solely up to me. -- Andrei
Re: D 2.066 is out. Enjoy!
On 8/19/14, 6:41 PM, Andrew Edwards wrote: On 8/19/14, 1:26 PM, Andrei Alexandrescu wrote: On 8/18/14, 5:23 PM, Nick Sabalausky wrote: On 8/18/2014 7:14 PM, Dicebot wrote: I also propose to start 2.067 beta branch right now and declare it yet another bug-fixing release. Seconded. Well that's what happened - someone started 2.067. What's the advantage of doing this? Now we need to worry about master and 2.067 instead of just master. -- Andrei That was my doing... I am preparing myself for the next go around. The actual branch will be created on Sunday (24 Aug) for a Monday (0900 PDT) announcement. The beta cycle will run eight weeks following that. On the fourth week (22 Sept) I will transition from beta to RC. [snip] Love the systematic approach. Thanks! -- Andrei
Re: Fix #2529: explicit protection package #3651
On Wednesday, 20 August 2014 at 17:19:58 UTC, Andrei Alexandrescu wrote: On 8/20/14, 7:49 AM, ketmar via Digitalmars-d-announce wrote: On Wed, 20 Aug 2014 14:33:52 + Kagamin via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Do we need a hierarchy of internals, is the problem this big? Why mybiglib.wisdom is not good? ah, why we need such things as subdirectories at all? CP/M was fine without concept of subdirectories! No need to demean the question. It is valid. -- Andrei Originally flat Phobos hierarchy was considered good enough. Now we can see that such approach doesn't scale well - features are often missed because of non-intuitive module placement, compile times suffer because of many cross-module dependencies (flat hierarchy encourages big modules). Is there any reason to think that same logic applied to sub-packages will scale any better as Phobos size grows? I doubt so. In fact I feel it is already beyond the size where it is convenient and only reason why even smaller deeply nested modules are not an option is exactly because it is too hard to keep both existing protection attribute relation and provide easy to navigate hierarchy at the same time. The fact that some of people who have actually tried to use package.d support this language change is pretty good anecdotal evidence that there is a problem to be solved.
Re: Fix #2529: explicit protection package #3651
module foo.bar.one; module foo.bar.internals; // package-protected utilities module foo.bar.subpkg.two; module foo.bar.subpkg.internals; // package-protected utilities Current situation: module 'one' cannot access the 'bar.subpkg' utilities, and module 'two' cannot access the 'bar' utilities. This is needlessly limiting, forcing design choices that should not be dictated by the ability/inability to separate public and private API. It also precludes many valid and good uses of nested package.d modules. I really don't see any equally strong counter-argument. But then, I've wanted this exact fix for literally years now. It also is not limited to internal utility modules. It can be useful for systems that select at compile time from one of a number of system-specific implementations of a given interface/api. It can be useful for granting privileged access to certain api's and/or resources to specific module(s). An example being: grant access to unsafe but versitile data manipulators solely to the subpackage containing the loaders. Currently, there is no absolutely enforceable way of doing such things; so one ends up falling back on convention... and conventions, sadly, never hold in the real world for long.
D for the Win
stumbled on this blog post: http://tomerfiliba.com/blog/dlang/ looked like something worth posting to r/programming, so I did
Re: D for the Win
Dlang Dlang Über Alles as a German, O_O
Re: D for the Win
Ha, that opDollar thing in the HTML generator is the nastiest D hack I've seen :-P
Re: D for the Win
On 8/20/2014 2:21 PM, Andrei wrote: stumbled on this blog post: http://tomerfiliba.com/blog/dlang/ looked like something worth posting to r/programming, so I did http://www.reddit.com/r/programming/comments/2e49tm/d_for_the_win/
Re: D for the Win
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 :-)
Re: D for the Win
Andrei:
http://tomerfiliba.com/blog/dlang/
struct PascalString {
Field!ubyte length;
Also see if UDAs plus compile-time introspection is helpful.
auto stream = cast(ubyte[])\x05hello.dup;
Perhaps this is enough, and avoids one allocation:
immutable stream = \x05hello.representation;
Bye,
bearophile
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 :-) 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. I was actually worried if the author is German. He's not, thankfully. He's from Israel. From a German author that would be an embracement of fascism. Coming from an Israeli, I don't really know where to put it, probably completely benign.
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 Wednesday, 20 August 2014 at 22:00:58 UTC, eles wrote: 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... :( I don't know, but I am keeping an eye on bitc: http://www.coyotos.org/pipermail/bitc-dev/ I like how Shapiro discuss the various issues.
Re: D for the Win
Am 21.08.2014 00:02, schrieb anonymous: 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. I was actually worried if the author is German. He's not, thankfully. He's from Israel. From a German author that would be an embracement of fascism. Coming from an Israeli, I don't really know where to put it, probably completely benign. As a Portuguese living in Germany, I would say not everyone knows that outside Germany. Specially the younger generations, they just use it because it sounds cool. -- Paulo
Re: D 2.066 is out. Enjoy!
On Wednesday, 20 August 2014 at 22:00:58 UTC, eles wrote: 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... :( D has set a new standard for me. No CTFE, no thanks.
Re: D 2.066 is out. Enjoy!
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. signature.asc Description: PGP signature
Re: D 2.066 is out. Enjoy!
On Wed, 20 Aug 2014 22:00:57 + eles via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: 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... :( language without CTFE is soo unpleasant to use after D. i'm programmed in various lisps and schemes and was very glad to find the C-like language with metaprogramming abilities. and I WANT AST MACROS! ;-) no, i don't want to write code to *support* AST macros, i want to write code that *uses* AST macros. ;-) signature.asc Description: PGP signature
Re: Fix #2529: explicit protection package #3651
On Wed, 20 Aug 2014 10:19:59 -0700 Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: No need to demean the question. It is valid. -- Andrei sorry, i don't mean to insult anyone, just trying to make people see analogies. hierarchies are everywhere, it's convient way to store alot of things. modules itself is a great example of hierarchies -- we can dump all source code in one file instead of using modules. i.e. file system hierarchy is handy what there are many files. module hierarchy is handy when there are many modules in library. the ability to have fine-grained visibility control in module hierarchy is handy. this was written numerous times in this thread, yet he continues to ask the same question again and again as if he just don't bother to read any answers. that's why i asked about subdirs. signature.asc Description: PGP signature
Re: D for the Win
On Wed, 20 Aug 2014 22:02:31 + anonymous via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: From a German author that would be an embracement of fascism. i always wonder how good people at finding various offences and fascims everywhere. i bet that such people are glad to censor Hašek's The Good Soldier Švejk, 'cause Hašek makes fun of the great human tragedy: the war! signature.asc Description: PGP signature
Re: D for the Win
On Thu, 21 Aug 2014 00:57:27 +0200 Paulo Pinto via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Specially the younger generations, they just use it because it sounds cool. and fun. they don't fear that old dead dog anymore, they making fun of it. signature.asc Description: PGP signature
New Project: D language support for SonarQube
SonarQube is an open platform to manage code quality.[1] I've started writing a plugin for Sonar that allows it to display code quality metrics for D. So far it just supports tracking static analysis warnings from D Scanner, though adding other metrics like line of code count and unit test coverage should be fairly simple. It's available here[2]. [1] http://www.sonarqube.org/ [2] https://github.com/economicmodeling/sonar-d-plugin
