Re: Decimal Numbers
Am 07.07.2014 23:15, schrieb Paul D Anderson: On Monday, 7 July 2014 at 03:26:54 UTC, Poyeyo wrote: Can you add a dub.json and submit it to the dub registry? etcimon generated a dub.json file which I've merged into github. Thanks. However, I am unable to register the package because it requires a version number, which I don't know how to add. I've used git tag and edited dub.selections.json, but neither seems to be the answer. Can someone enlighten me? Paul git tag v0.9.0 git push --tags should do the trick (as well as any other version instead of 0.9.0, of course).
Re: DMD 2.066.0-b1
On Saturday, 5 July 2014 at 09:44:44 UTC, Andrew Edwards wrote: All binaries are now posted. Following the updated links: ALL ftp://ftp.digitalmars.com/dmd.2.066.0-b1.zip OSX ftp://ftp.digitalmars.com/dmd.2.066.0-b1.osx.zip ftp://ftp.digitalmars.com/dmd.2.066.0-b1.dmg FREEBSD ftp://ftp.digitalmars.com/dmd.2.066.0-b1.freebsd-32.zip ftp://ftp.digitalmars.com/dmd.2.066.0-b1.freebsd-64.zip LINUX ftp://ftp.digitalmars.com/dmd.2.066.0-b1.linux.zip ftp://ftp.digitalmars.com/dmd_2.066.0~b1-0_amd64.deb ftp://ftp.digitalmars.com/dmd_2.066.0~b1-0_i386.deb ftp://ftp.digitalmars.com/libphobos2-66_2.066.0~b1-0_amd64.deb ftp://ftp.digitalmars.com/libphobos2-66_2.066.0~b1-0_i386.deb ftp://ftp.digitalmars.com/dmd-2.066.0~b1-0.fedora.i386.rpm ftp://ftp.digitalmars.com/dmd-2.066.0~b1-0.fedora.x86_64.rpm ftp://ftp.digitalmars.com/dmd-2.066.0~b1-0.openSUSE.i386.rpm ftp://ftp.digitalmars.com/dmd-2.066.0~b1-0.openSUSE.x86_64.rpm WINDOWS ftp://ftp.digitalmars.com/dmd.2.066.0-b1.windows.zip ftp://ftp.digitalmars.com/dmd-2.066.0-b1.exe Very Good. Thank You. ^_^
Re: Decimal Numbers
On Monday, 7 July 2014 at 21:15:33 UTC, Paul D Anderson wrote: On Monday, 7 July 2014 at 03:26:54 UTC, Poyeyo wrote: Can you add a dub.json and submit it to the dub registry? etcimon generated a dub.json file which I've merged into github. Thanks. However, I am unable to register the package because it requires a version number, which I don't know how to add. I've used git tag and edited dub.selections.json, but neither seems to be the answer. Can someone enlighten me? Paul If you want to do this in github just click the releases tab on your repo and create a new release with the tag and name formatted as a SemVer[1] tag. [1]: http://semver.org/
DMD v2.066.0-b2
The v2.066.0-b2 binaries are now available. The review period will run until 0700 UTC ( PDT) 14 July 2014. Your assistance in identifying and reporting bugs are greatly appreciated. Binaries are located here: ALL ftp://ftp.digitalmars.com/dmd.2.066.0-b2.zip OSX ftp://ftp.digitalmars.com/dmd.2.066.0-b2.dmg ftp://ftp.digitalmars.com/dmd.2.066.0-b2.osx.zip FREEBSD ftp://ftp.digitalmars.com/dmd.2.066.0-b2.freebsd-32.zip ftp://ftp.digitalmars.com/dmd.2.066.0-b2.freebsd-64.zip LINUX ftp://ftp.digitalmars.com/dmd_2.066.0~b2-0_i386.deb ftp://ftp.digitalmars.com/dmd_2.066.0~b2-0_amd64.deb ftp://ftp.digitalmars.com/dmd.2.066.0-b2.linux.zip ftp://ftp.digitalmars.com/dmd-2.066.0~b2-0.openSUSE.i386.rpm ftp://ftp.digitalmars.com/dmd-2.066.0~b2-0.openSUSE.x86_64.rpm ftp://ftp.digitalmars.com/dmd-2.066.0~b2-0.fedora.i386.rpm ftp://ftp.digitalmars.com/dmd-2.066.0~b2-0.fedora.x86_64.rpm ftp://ftp.digitalmars.com/libphobos2-66_2.066.0~b2-0_i386.deb ftp://ftp.digitalmars.com/libphobos2-66_2.066.0~b2-0_amd64.deb WINDOWS ftp://ftp.digitalmars.com/dmd.2.066.0-b2.windows.zip ftp://ftp.digitalmars.com/dmd-2.066.0-b2.exe Request assistance in identifying non-breaking changes (fixes) for inclusion in the 2.065.1 point release. I need assistance with this because I do not have the expertise to determine what goes into the point release. If nothing is identified, I will abandon the idea of providing point releases. A issues ([1] [2]) have been created for identifying commits that require cherry picking for inclusion in future beta/release candidates. Commits not identified will not be picked. Enjoy, Andrew [1] [Cherry-pick v2.066.0-b3]https://issues.dlang.org/show_bug.cgi?id=13072 https://issues.dlang.org/show_bug.cgi?id=13035 [2] [Cherry-pick v2.065.1-b1]https://issues.dlang.org/show_bug.cgi?id=13036
Re: DMD v2.066.0-b2
The download links are broken. They should have prefix http:// instead of ftp://.
Re: DMD v2.066.0-b2
On Tuesday, 8 July 2014 at 13:48:45 UTC, kdmult wrote: The download links are broken. They should have prefix http:// instead of ftp://. Hmm... they work for me.
Re: Smile, you're on Wired
The reddit response is really positive too it looks like, cool.
Re: DMD v2.066.0-b2
On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote: If nothing is identified, I will abandon the idea of providing point releases. Managing multiple Alpha or Beta builds with a1, a2 .. or b1, b2 etc look good. Adding another point-number to the 2.066 like 2.066.1 is a needless confusion, unless you have already released 2.066 and coming up with an intermediate release before 2.067
Re: DMD v2.066.0-b2
On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote: The v2.066.0-b2 binaries are now available. The review period will run until 0700 UTC ( PDT) 14 July 2014. Your assistance in identifying and reporting bugs are greatly appreciated. Link to this post on dlang.org main page is broken.
Re: Smile, you're on Wired
Awesome! Look at the 90% of upvotes and people all asking constuctive and fun questions :-) On Tuesday, 8 July 2014 at 14:29:31 UTC, Adam D. Ruppe wrote: The reddit response is really positive too it looks like, cool.
Bindings to clFFT (OpenCL fft library)
Just a heads-up for anyone using/wanting to use OpenCL in D: clFFT [1] is amd's open source fft library for OpenCL, part of clMathLibraries. I needed it for a project so I ported the header, here it is: https://github.com/John-Colvin/clFFT-D http://code.dlang.org/packages/clfft I left the original comments in the file for reference. The original documentation can be found at http://clmathlibraries.github.io/clFFT/ I don't anticipate bugs relating to the port specifically as very little was changed, but please let me know if you do have any problems. [1] https://github.com/clMathLibraries/clFFT
Re: Smile, you're on Wired
On Tuesday, 8 July 2014 at 14:29:31 UTC, Adam D. Ruppe wrote: The reddit response is really positive too it looks like, cool. That is as exciting as the article itself!
Re: Smile, you're on Wired
On 8 July 2014 15:29, Adam D. Ruppe via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: The reddit response is really positive too it looks like, cool. Just goes to show that when it comes from a source that people may consider trustworthy, they genuinely take notice and listen. :)
DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson
https://news.ycombinator.com/newest (please find and vote quickly) https://twitter.com/D_Programming/status/486540487080554496 https://www.facebook.com/dlang.org/posts/881134858566863 http://www.reddit.com/r/programming/comments/2a5ia9/dconf_2014_day_2_talk_3_designing_an_aurora_a/ Andrei
@nogc and NSAutoPool-style regions.
Seems to me that most of the utility beyond maintaining graph
like structures can be covered by making the compiler aware of
region allocator semantics. Assuming that the use of GC is
constrained locally and does not consume too much space. I think
it would work out ok for loading of smaller files etc with the
following kind of semantics:
Something_ptr someglobalvar;
process(A a) {
int x;
@regionalloc(1024,256) { // 1 MiB default size, 256KiB
increments
auto y = new ...; // gc new() is hijacked by @regionalloc
// assignments must be restricted so that new() ptrs and y ptrs
// are not assigned to memory that can escape the @regionalloc
// and no writes to global ptrs of region allocated objects
allowed
auto ptr = compute_with_constrained_gc_semantics(a,y)
someglobalvar = make_malloc_copy(ptr); // optimization: remove
temporary
x = obtain_some_value(ptr);
}
// region is dead here, including y and ptr objects
}
The real challenge is in putting the right constraints on the
@regionalloc block, but I guess weakly pure functions are kind of
close in their constraints. So it should be possible?
The goal would be to be able to link to libraries that aren't
@nogc aware without having the GC runtime available. For loading,
initialization etc.
Re: @nogc and NSAutoPool-style regions.
Wrong forum :-(
Re: Smile, you're on Wired
On Tuesday, 8 July 2014 at 15:44:26 UTC, Iain Buclaw via Digitalmars-d-announce wrote: On 8 July 2014 15:29, Adam D. Ruppe via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: The reddit response is really positive too it looks like, cool. Just goes to show that when it comes from a source that people may consider trustworthy, they genuinely take notice and listen. :) +1
Re: DMD v2.066.0-b2
Also the link on main page is broken. 2014-07-08 18:10 GMT+04:00 via Digitalmars-d-announce digitalmars-d-announce@puremagic.com: On Tuesday, 8 July 2014 at 13:48:45 UTC, kdmult wrote: The download links are broken. They should have prefix http:// instead of ftp://. Hmm... they work for me.
Re: Smile, you're on Wired
On Tuesday, 8 July 2014 at 15:44:26 UTC, Iain Buclaw via Digitalmars-d-announce wrote: On 8 July 2014 15:29, Adam D. Ruppe via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: The reddit response is really positive too it looks like, cool. Just goes to show that when it comes from a source that people may consider trustworthy, they genuinely take notice and listen. :) Also note the huge amount of Facebook shares : near 10'000 now ! Usually, a trending article on wired does not exceed a few hundred.
Re: DUB Bash Completion
El 07/07/14 12:58, Sönke Ludwig via Digitalmars-d-announce ha escrit: Very nice, I'll try this out this later. If you don't mind, we should put this into the DUB main repository and also get in touch with the package maintainers to include it in the standard distribution. I'm agree. I'll include it on deb packages as sun as it is in dub repository. Regards, -- Jordi Sayol
Re: DMD v2.066.0-b2
On 7/8/14, 11:16 PM, NCrashed . via Digitalmars-d-announce wrote: Also the link on main page is broken. https://issues.dlang.org/show_bug.cgi?id=13080
Re: DMD v2.066.0-b2
On 7/8/14, 11:47 PM, NCrashed wrote: On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote: The v2.066.0-b2 binaries are now available. The review period will run until 0700 UTC ( PDT) 14 July 2014. Your assistance in identifying and reporting bugs are greatly appreciated. Link to this post on dlang.org main page is broken. https://issues.dlang.org/show_bug.cgi?id=13080
Re: DMD v2.066.0-b2
On 7/8/14, 11:39 PM, John wrote: On Tuesday, 8 July 2014 at 10:38:52 UTC, Andrew Edwards wrote: If nothing is identified, I will abandon the idea of providing point releases. Managing multiple Alpha or Beta builds with a1, a2 .. or b1, b2 etc look good. Adding another point-number to the 2.066 like 2.066.1 is a needless confusion, unless you have already released 2.066 and coming up with an intermediate release before 2.067 Note that the maintenance/point release refers specifically to 2.065.1. 2.065 was released in February and there is nothing that says you cannot continue maintaining it after we've released 2.066.
Re: Decimal Numbers
On Tuesday, 8 July 2014 at 08:15:28 UTC, Sönke Ludwig wrote: Am 07.07.2014 23:15, schrieb Paul D Anderson: On Monday, 7 July 2014 at 03:26:54 UTC, Poyeyo wrote: Can you add a dub.json and submit it to the dub registry? etcimon generated a dub.json file which I've merged into github. Thanks. However, I am unable to register the package because it requires a version number, which I don't know how to add. I've used git tag and edited dub.selections.json, but neither seems to be the answer. Can someone enlighten me? Paul git tag v0.9.0 git push --tags should do the trick (as well as any other version instead of 0.9.0, of course). Thanks. That did it.
Re: DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson
On Tuesday, 8 July 2014 at 16:03:36 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2a5ia9/dconf_2014_day_2_talk_3_designing_an_aurora_a/ Very intriguing. First question for Andrew Wilson i reckon :) Is the Immutable Scene Object (ISO) supposed to be an exact copy (same type and same contents) of the User Scene Object (USO) especially with regards to the Model-View-Controller pattern: https://en.wikipedia.org/wiki/Model-View-Controller I'm asking because I first thought that - USO typically maps to the Model (data) and the - ISO typically maps to the View (visual representation)
Tornado pool-Work in progress template streaming library
link: https://github.com/Superstar64/tornado-pool This is a heavy work in progress streaming library, i'm not even sure if some parts of it compile. check out tpool/samples.d
Re: DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson
On Tuesday, 8 July 2014 at 16:03:36 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2a5ia9/dconf_2014_day_2_talk_3_designing_an_aurora_a/ Great talk but I have some reservations about the design. What I am most concerned about is the design of the immediate mode layer. I was one of the few who initially pushed for the immediate mode but I think you missed the point. There are several points that I want to address so I will go through them one at a time. Also I apologize for the wall of text. *Scene Graph Personally I find it odd that the immediate mode knows anything about a scene graph at all. Scene Graphs are not an end all be all, they do not make everything simpler to deal with. It is one way to solve the problem but not always the best. D is supposed to be multi paradigm, locking the users into a scene graph design is against that goal. I personally think that the immediate mode should be designed for performance and the less performant but 'simpler' modes should be built on top of it. *Performance vs Simplicity I know that you have stated quite clearly that you do not believe performance should be a main goal of Aurora, you have stated that simplicity is a more important goal. I propose that there is NO reason at all that Aurora can't have both in the same way that D itself has both. I think it is just a matter of properly defining the goals of each layer. The retained mode should be designed with simplicity in mind whilst still trying to be performant where possible. On the other hand, the immediate mode should be designed with performance in mind whilst still trying to be simple where possible. The simple mode(s?) should be build on top of the single performance mode. *Design Modern graphics hardware has a very well defined interface and all modern graphics api's are all converging on matching the hardware as close as possible. Modern graphics is done by sending buffers of data to the card and having programmable shaders to operate on the data, period. I believe that the immediate mode layer should match this as close a possible. If that involves having some DSL for shaders that gets translated into all the other various shader languages then so be it, the differences between them is minimal. If the DSL was a subset of D then all the better. *2D vs 3D I think the difference you are making between 2D and 3D is largely artificial. In modern graphics api's the difference between 2D and 3D is merely a matrix multiply. If the immediate mode was designed how I suggest above, then 2D vs 3D is a non issue. *Games D is already appealing to game developers and with the work on @nogc and andrei's work with allocators, it is becoming even more appealing. The outcome of Aurora could land D a VERY strong spot in games that would secure it a very good future. But only if it is done right. I think there is a certain level of responsibility in the way Aurora gets designed that needs to be taken into account. I know that most of my points are not in line with what you said Aurora would and wouldn't be. I just don't think there is any reason Aurora couldn't achieve the above points whilst still maintaining it's goal of simplicity. Also, I am willing to help, I just don't really know what needs working on. I have a lot of experience with openGL on windows writing high performance graphics.
Re: DConf 2014 Day 2 Talk 3: Designing an Aurora: A Glimpse at the Graphical Future of D by Adam Wilson
On Wednesday, 9 July 2014 at 04:26:55 UTC, Tofu Ninja wrote: Modern graphics hardware has a very well defined interface and all modern graphics api's are all converging on matching the hardware as close as possible. Modern graphics is done by sending buffers of data to the card and having programmable shaders to operate on the data, period. That's true, but OpenGL is being left behind now that there is a push to match the low level of how GPU drivers work. Apple's Metal is oriented towards the tiled PowerVR and scenegraphs, probably also with some expectations of supporting the upcoming raytracing accelerators. AMD is in talks with Intel (rumour) with the intent of cooperating on Mantle. Direct-X is going lower level… So, there is really no stability in the API at the lower level. But yes, OpenGL is not particularly suitable for rendering a scene graph without an optimizing engine to reduce context switches. largely artificial. In modern graphics api's the difference between 2D and 3D is merely a matrix multiply. If the immediate mode was designed how I suggest above, then 2D vs 3D is a non issue. Actually, modern 2D APIs like Apple's Quartz are backend independent and render to PDF. Native PDF support is important if you want to have an advantage in the web space and in the application space in general. There is almost no chance anyone wanting to do 3D would use something like Aurora… If you can handle 3D math you also can do OpenGL, Mantle, Metal? But then again, the official status for Aurora is kind of unclear.
Re: Upgrading a codebase from 2.065 to 2.066
On 2 July 2014 23:41, David Nadlinger via Digitalmars-d digitalmars-d@puremagic.com wrote: On Wednesday, 2 July 2014 at 22:34:36 UTC, Brian Schott wrote: 4. isNaN is now a template. It should really be a normal function with float/double/real overloads instead of a template. That being said, OTOH an uint argument would still lead to an ambiguity error. I had thought about this initially when I wrote it, but then I came to the conclusion that calling this on anything but an float would be wrong. Iain
Re: Upgrading a codebase from 2.065 to 2.066
On 2 July 2014 23:34, Brian Schott via Digitalmars-d digitalmars-d@puremagic.com wrote: 4. isNaN is now a template. This broke some templated code that would (depending on template instantiations) rely on uint being converted to real. The new isFloatingPoint template constraint kept this from compiling. I ended up placing a static if around our call to isNaN to work around this. Maybe it would be useful to add a template specialization for isNaN that checks isNumeric !isFloatingPoint and always returns false. I would ask why are you passing integers to isNaN. And I would also give you some heads up on other stuff... https://github.com/D-Programming-Language/phobos/pull/2305
Re: Upgrading a codebase from 2.065 to 2.066
On Tuesday, 8 July 2014 at 06:02:51 UTC, Iain Buclaw via Digitalmars-d wrote: I would ask why are you passing integers to isNaN. We passed T to isNaN, and sometimes T was uint.
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote: + Has the GC been dropped? Nope, still there and probably always will be. I think I read on the forums that people are working on a better/more precise GC though. From what I understand the current one could stand a lot of improvement. + If not, can it be disabled entirely/completely? It can be, but you would also lose some features, though I'm not entirely sure which things exactly. I remember that slices was one thing you would no longer have if you disable the GC, but I can't think of any others. The GC isn't really something you would need to disable though. I have never had any issues with it, and unless you're doing something that might have it run a lot, it shouldn't affect you in any way.
Re: Upgrading a codebase from 2.065 to 2.066
On 8 July 2014 07:08, Brian Schott via Digitalmars-d digitalmars-d@puremagic.com wrote: On Tuesday, 8 July 2014 at 06:02:51 UTC, Iain Buclaw via Digitalmars-d wrote: I would ask why are you passing integers to isNaN. We passed T to isNaN, and sometimes T was uint. Happy now? :o) https://github.com/D-Programming-Language/phobos/pull/2311
Re: std.math performance (SSE vs. real)
On Friday, 4 July 2014 at 17:05:16 UTC, Walter Bright wrote: On 7/4/2014 3:38 AM, Don wrote: What is the longest type supported by the native hardware? I don't know what that means, and I don't think it even makes sense. Most of the time, it is quite clear. For example, Sparc has 128-bit quads, but they only have partial support. Effectively. they are emulated. Why on earth would you want to use an emulated type on some machines, but not on others? Emulation is not native support. I think the only difference it makes is performance. But there is not very much difference in performance between double-double, and implementations using microcode. Eg PowerPC double-doubles operations require fewer clock cycles than x87 operations on 286. Perhaps the intention was the largest precision you can get for free, without sacrificing speed then that's not clearly defined. On x86-32, that was indeed 80 bits. But on other systems it doesn't have an obvious answer. On x86-64 it's not that simple. Nor on PPC or Sparc. Yes, there is some degree of subjectivity on some platforms. I don't see a good reason for hamstringing the compiler dev with legalese for Platform X with legalese that isn't quite the right thing to do for X. I agree. But I think we can achieve the same outcome while providing more semantic guarantees to the programmer. I think the intention of the spec is clear, and the compiler implementor can be relied on to exercise good judgement. The problem is that the developer cannot write code without knowing the semantics. For example, one of the original motivations for having 80-bit floats on the x87 was that for many functions, they give you correctly-rounded results for 'double' precision. If you don't have 80-bit reals, then you need to use far more complicated algorithms. If your code needs to work on a system with only 64 bit reals, then you have to do the hard work. Something I've come to realize, was that William Kahan's work was done in a world before generic programming. He had constraints that we don't have. Our metaprogramming system gives us great tools to get the highest accuracy and performance out of any processor. We can easily cope with the messy reality of real-world systems, we don't need to follow Java in pretending they are all the same. This is something we're good at! A 'real' type that has system-dependent semantics is a poor-man's generics. Take a look at std.math, and see all the instances of 'static if (real.mant_dig == '. Pretty clearly, 'real' is acting as if it were a template parameter. And my experience is that any code which doesn't treat 'real' as a template parameter, is probably incorrect. I think we should acknowledge this.
Re: Redesign of dlang.org
On Thursday, 3 July 2014 at 17:38:22 UTC, w0rp wrote: On Thursday, 3 July 2014 at 13:16:34 UTC, Chris wrote: [I haven't had time to follow the entire thread, but] I like the design, it's a good starting point. Especially the integration of the logo. Nice and clean. (The current logo is just too bulky and clumsy, imo*) However, my experience tells me that we should wait with redesigning it until the technical issues/problems have been solved, e.g. the migration to vibe.d, which I'm in favor of (I've had good experiences with vibe.d so far), and the doc generation issue etc etc. Once that is out of the way, we can think about new designs. I've been focusing on getting a working site with vibe.d. Integrating the ddox document generator is a high priority for me right now, especially since I've finished a lot of work for formatting the changelog pages. Yours is very nice and modern. However, we also have to take mobile devices (tablets, smartphones) into account and see how we can adapt to these (different layouts or one for all?). I used the Bootstrap framework, which I have also used in my day job. Bootstrap makes producing a responsive design pretty easy. I've been periodically testing pages on smaller screens. Firefox's 'reponsive design mode' helps a lot with this. Another issue is that we don't have to jump on any bandwagon (every time the fashion changes), we can roll our own design, one that fits the community's and the language's needs, regardless of what is trendy or modern at any given time (don't imitate, innovate!). There are many different designs you could produce. Many design choices are subjective, though not all of them. I think my goals for the work I've been doing are as follows. * Improve site navigation. * Improve display across different devices. * Improve the quality of text to make it easier to read. * Make it easier for newcomers to edit, to encourage contribution. * Run it all with D to tick a official D site made in D checkbox. There are others, but those are the important ones. Very good. That would improve the page a lot. The code block at the top of the page, I think we don't really need that for mobile devices with small screens. Takes up too much space. Maybe we could just hide it and have a button or so that says show code. I'd also recommend a page with simple recipes how to open a file etc. In this way newbies wouldn't have to go through the library reference for simple tasks. I'd love to use something like Powered by D for my own programs written in D.
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote: + Has the GC been dropped? No, and no matter what exactly will be done, it surely will always stay at least as an option, and most probably will be enabled by default. + If not, can it be disabled entirely/completely? This is already possible for a long time. Normally it's only called when the memory allocator runs out of free memory, i.e. only on allocation, and you can call `GC.disable` to disable it completely. For the upcoming release 2.066 (currently in beta), there will be a function attribute `@nogc` which makes the compiler error out if a function allocates GC memory (either directly, or by calling other non-@nogc functions). Parts of the standard library have already been marked as @nogc, so they can be used inside such functions, though this is still ongoing work. Other parts have been changed to avoid allocations, at least where possible. There are now also some alternatives to functions that return allocated data to accept a sink delegate instead, so that the caller can decides whether they want to allocate, and how. D has always greatly impressed me, but I need a systems language without garbage collection; has D become that now? Well, yes and no, see above ;-) I guess more work in this direction will be enabled once we have `std.allocator`, which Andrei Alexandrescu is working on currently. There might also be other changes necessary, some kind of ownership tracking / borrowing for example, to make this safe. (Manual memory management without help from the language can easily lead to all kinds of bugs.)
Re: Bottom line re GC in D
Marc Schütz: There might also be other changes necessary, some kind of ownership tracking / borrowing for example, to make this safe. (Manual memory management without help from the language can easily lead to all kinds of bugs.) In the end Bartoz could be right. Bye, bearophile
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote: Hi all, I know there's been quite some discussion about the GC in D, but I've been busy doing other things and haven't been following that closely. So I'd appreciate it if someone could fill me in about proceedings/decisions in this regard... + Has the GC been dropped? + If not, can it be disabled entirely/completely? D has always greatly impressed me, but I need a systems language without garbage collection; has D become that now? Thanks in advance for any responses. Adrian. - No, D is a fully garbage collected language. - No, it can't be disabled if you want to keep using impressive features of the language. Long story short, if you prefer to manage your own god-damn memory manually, D isn't the way to go. No sir, you are stuck with an inefficient GC. They've been improving the GC for years, but it's still not good enough. I suggest Rust, or something like that.
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote: - No, it can't be disabled if you want to keep using impressive features of the language. What do CTFE, mixins, Ds powerful template mechanism, immutable + slices, sane operator overloading, opDispatch, alias this and UFCS, RAII + scope statements to do with the GC? Long story short, if you prefer to manage your own god-damn memory manually, D isn't the way to go. No sir, you are stuck with an inefficient GC. They've been improving the GC for years, but it's still not good enough. How does the quality of the GC even matter if you're not going to use it?
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 10:07:18 UTC, Tobias Pankrath wrote: On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote: - No, it can't be disabled if you want to keep using impressive features of the language. What do CTFE, mixins, Ds powerful template mechanism, immutable + slices, sane operator overloading, opDispatch, alias this and UFCS, RAII + scope statements to do with the GC? Long story short, if you prefer to manage your own god-damn memory manually, D isn't the way to go. No sir, you are stuck with an inefficient GC. They've been improving the GC for years, but it's still not good enough. How does the quality of the GC even matter if you're not going to use it? - You can't use slices. You can't make use of most of the Standard Library functionality. - It matters, because you can't manually manage life-time of the objects. See, you have to keep a reference to a C-String that you send to a C function, otherwise GC will eat it up, because it can't know better than you, yet tries to do your job. GC will always stand in the way, and if you want to turn it off, as I stated above, D becomes a less useful language.
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 10:25:17 UTC, Oluca wrote: - You can't use slices. You can't make use of most of the Standard Library functionality. You just cannot append to them. - It matters, because you can't manually manage life-time of the objects. See, you have to keep a reference to a C-String that you send to a C function, otherwise GC will eat it up, because it can't know better than you, yet tries to do your job. GC will always stand in the way, and if you want to turn it off, as I stated above, D becomes a less useful language. It's still very useful, as I stated above.
Re: Upgrading a codebase from 2.065 to 2.066
On Tuesday, 8 July 2014 at 06:08:58 UTC, Brian Schott wrote:
On Tuesday, 8 July 2014 at 06:02:51 UTC, Iain Buclaw via
Digitalmars-d wrote:
I would ask why are you passing integers to isNaN.
We passed T to isNaN, and sometimes T was uint.
I would like to have a NaN in any type and be able to call isNaN
for any (numeric) type. In fact I work with the following:
/// add a property to numeric types that can be used as return
value if a result is out of bounds
template @property T invalid(T) @primitive if(isNumeric!T)
{
static if(isFloat!T)
return T.init;
else static if(isSigned!T)
return T.min;
else // unsigned
return T.max;
}
/// returns the save (not invalid) minimum value for the given
type
template @property T smin(T) @primitive if(isNumeric!T)
{
static if(isIntegral!T isSigned!T)
return T.min+1;
else
return T.min;
}
/// returns the save (not invalid) maximum value for the given
type
template @property T smax(T) @primitive if(isNumeric!T)
{
static if(isUnsigned!T)
return T.max-1u;
else
return T.max;
}
/// take any NaN as invalid floatingpoint value,
/// T.max as invalid value of unsigned types and
/// T.min as invalid value of signed types
bool isInvalid(T)(const(T) x) @primitive if(isNumeric!T)
{
static if(isFloat!T)
return isNaN(x);
else static if(isSigned!T)
return x == T.min;
else // unsigned
return x == T.max;
}
(btw: @primitive is my internal shorthand for pure @safe @nogc
@nothrow)
because it allows to define save functions like e.g. a save
downcast:
/// returns T.invalid if x is outside the target type range
T limit(T, U)(const(U) x) @primitive if(isNumeric!T
isNumeric!U)
{
static if(Unqual!T == Unqual!U) // nop
return x;
else static if(isFloat!T)
return cast(T)x; // let D handle this internally
else static if(isFloat!U)
return (isNaN(x) || x = cast(U)T.min-1.0f || x =
cast(U)T.max+1.0f) ? T.invalid : cast(T)x;
else static if(isSigned!T)
{
static if(T.sizeof U.sizeof) // nothing to limit
return cast(T)x;
else static if(isUnsigned!U) // limit one direction
return (x T.max) ? T.invalid : cast(T)x;
else // limit both directions
return (x T.min || x T.max) ? T.invalid : cast(T)x;
}
else // unsigned result
{
static if(isSigned!U) // prohibit negative values
if(x 0) return T.invalid;
static if(T.sizeof = U.sizeof) // no further limit
return cast(T)x;
else // prohibit also big positive values
return (x T.max) ? T.invalid : cast(T)x;
}
}
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer have
if you disable the GC, but I can't think of any others.
You can definitely use slices without the GC and they are still
awesome without the GC.
What you cannot do is create them with `new` or call the builtin
~ or ~= (concatenate and append respectively) operators on
slices. Slice literals may also cause allocations, but not always:
enum ctA = [3, 4];
void main() @nogc //@nogc is transitive, marking main as @nogc
//enforces no GC activity in the entire program.
{
//these statements are all guaranteed not to GC-allocate
int[2] a = [1, 2];
assert(a[0] == 1 a[1] == 2);
a = ctA;
assert(a[0] == 3 a[1] == 4);
assert(a == [3,4]);
import core.stdc.stdlib;
auto data = cast(int*)calloc(100_000, int.sizeof);
auto callocedSlice = data[0 .. 100_000];
auto subSlice = callocedSlice[40 .. $ - 600];
//these cause GC allocation and as such
//will not compile in an @nogc function.
//int[] s0 = [1, 2];
//auto s1 = [3,4];
}
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 10:25:17 UTC, Oluca wrote: On Tuesday, 8 July 2014 at 10:07:18 UTC, Tobias Pankrath wrote: On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote: - No, it can't be disabled if you want to keep using impressive features of the language. What do CTFE, mixins, Ds powerful template mechanism, immutable + slices, sane operator overloading, opDispatch, alias this and UFCS, RAII + scope statements to do with the GC? Long story short, if you prefer to manage your own god-damn memory manually, D isn't the way to go. No sir, you are stuck with an inefficient GC. They've been improving the GC for years, but it's still not good enough. How does the quality of the GC even matter if you're not going to use it? - You can't use slices. See my other post. This is not true. They aren't quite as powerful or convenient without the GC, but you definitely can use them.
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer have
if you disable the GC, but I can't think of any others.
You can definitely use slices without the GC and they are still
awesome without the GC.
What you cannot do is create them with `new` or call the
builtin ~ or ~= (concatenate and append respectively) operators
on slices. Slice literals may also cause allocations, but not
always:
enum ctA = [3, 4];
void main() @nogc //@nogc is transitive, marking main as @nogc
//enforces no GC activity in the entire
program.
{
//these statements are all guaranteed not to GC-allocate
int[2] a = [1, 2];
assert(a[0] == 1 a[1] == 2);
a = ctA;
assert(a[0] == 3 a[1] == 4);
assert(a == [3,4]);
import core.stdc.stdlib;
auto data = cast(int*)calloc(100_000, int.sizeof);
auto callocedSlice = data[0 .. 100_000];
auto subSlice = callocedSlice[40 .. $ - 600];
//these cause GC allocation and as such
//will not compile in an @nogc function.
//int[] s0 = [1, 2];
//auto s1 = [3,4];
}
I should also include this example:
int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the stack
auto s = a[]; //a normal slice, backed by stack memory*
auto s1 = a[3 .. 5]; //ditto
Re: Bottom line re GC in D
int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the stack auto s = a[]; //a normal slice, backed by stack memory* auto s1 = a[3 .. 5]; //ditto I see. Thanks for the examples. What about strings? Do they depend on GC? They are just slices / arrays.
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 11:26:55 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer have
if you disable the GC, but I can't think of any others.
You can definitely use slices without the GC and they are
still awesome without the GC.
What you cannot do is create them with `new` or call the
builtin ~ or ~= (concatenate and append respectively)
operators on slices. Slice literals may also cause
allocations, but not always:
enum ctA = [3, 4];
void main() @nogc //@nogc is transitive, marking main as @nogc
//enforces no GC activity in the entire
program.
{
//these statements are all guaranteed not to GC-allocate
int[2] a = [1, 2];
assert(a[0] == 1 a[1] == 2);
a = ctA;
assert(a[0] == 3 a[1] == 4);
assert(a == [3,4]);
import core.stdc.stdlib;
auto data = cast(int*)calloc(100_000, int.sizeof);
auto callocedSlice = data[0 .. 100_000];
auto subSlice = callocedSlice[40 .. $ - 600];
//these cause GC allocation and as such
//will not compile in an @nogc function.
//int[] s0 = [1, 2];
//auto s1 = [3,4];
}
I should also include this example:
int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the
stack
auto s = a[]; //a normal slice, backed by stack memory*
auto s1 = a[3 .. 5]; //ditto
I see. Thanks for the examples. What about strings? Do they
depend on GC?
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 11:31:49 UTC, Oluca wrote:
On Tuesday, 8 July 2014 at 11:26:55 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer
have if you disable the GC, but I can't think of any others.
You can definitely use slices without the GC and they are
still awesome without the GC.
What you cannot do is create them with `new` or call the
builtin ~ or ~= (concatenate and append respectively)
operators on slices. Slice literals may also cause
allocations, but not always:
enum ctA = [3, 4];
void main() @nogc //@nogc is transitive, marking main as @nogc
//enforces no GC activity in the entire
program.
{
//these statements are all guaranteed not to GC-allocate
int[2] a = [1, 2];
assert(a[0] == 1 a[1] == 2);
a = ctA;
assert(a[0] == 3 a[1] == 4);
assert(a == [3,4]);
import core.stdc.stdlib;
auto data = cast(int*)calloc(100_000, int.sizeof);
auto callocedSlice = data[0 .. 100_000];
auto subSlice = callocedSlice[40 .. $ - 600];
//these cause GC allocation and as such
//will not compile in an @nogc function.
//int[] s0 = [1, 2];
//auto s1 = [3,4];
}
I should also include this example:
int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the
stack
auto s = a[]; //a normal slice, backed by stack memory*
auto s1 = a[3 .. 5]; //ditto
I see. Thanks for the examples. What about strings? Do they
depend on GC?
`string` is just an alias to `immutable(char)[]` so the situation
is (almost) the same*.
Be aware that the compiler will happily let you pass immutable
data to another thread and will assume that it will always be
available and never change (GCs are really useful :p ). Using
immutable data that has been freed (e.g. by exiting the stack it
was allocate on, or calling free on a malloced array) will cause
all sorts of madness, quite possibly worse than in the
non-immutable case. The compiler can make a lot of assumptions
about the immutable memory that it cannot about mutable, which
will all be broken if you free that memory while still holding
references to it elsewhere.
TLDR: beware immutability and non-GC memory. Extra care is
needed. I would either use const(char)[] for my strings or be
very wary of impure functions that might store a reference.
*make sure you've got the length right, unicode means a single
visual character may be bigger than one char. See here:
import std.exception : assumeUnique;
alias stackString(size_t len) = immutable(char)[len];
enum stackString(string s) = cast(immutable(char)[s.length])s;
void main() @nogc
{
stackString!5 str0 = hello; //ASCII, length is easy to see
auto str1 = stackString!héllo͂; //UTF-8, best to let the
compiler
//work out the length for you
}
There was talk of something like immutable(char)[$] = héllo͂;
working, but I don't know where that went.
OT: Analog Mars? ;-)
http://mars-lang.appspot.com/
Re: Languages for servers (Go, D, and more)
On Tuesday, 8 July 2014 at 02:31:50 UTC, Átila Neves wrote: On Monday, 7 July 2014 at 18:15:32 UTC, Sean Kelly wrote: With asynchronous event-driven code (ie. server code), I don't see any way to avoid all use of new / delete. std::make_unique and std::make_shared are what you're supposed to use. The new and delete operators are (usually) for library writers. Even before C++11, using delete was frowned upon but necessary with containers of pointers due to std::auto_ptr not helping. Well, that and the lack of move semantics. But you're ultimately passing something as a void* to a library call and receiving it later as the context for a callback. That value has to live on the heap.
Re: Languages for servers (Go, D, and more)
On Tuesday, 8 July 2014 at 14:24:10 UTC, Sean Kelly wrote: But you're ultimately passing something as a void* to a library call and receiving it later as the context for a callback. That value has to live on the heap. Well to be fair, you could make the context an index into an array.
Re: Languages for servers (Go, D, and more)
On Tuesday, 8 July 2014 at 14:24:10 UTC, Sean Kelly wrote: On Tuesday, 8 July 2014 at 02:31:50 UTC, Átila Neves wrote: On Monday, 7 July 2014 at 18:15:32 UTC, Sean Kelly wrote: With asynchronous event-driven code (ie. server code), I don't see any way to avoid all use of new / delete. std::make_unique and std::make_shared are what you're supposed to use. The new and delete operators are (usually) for library writers. Even before C++11, using delete was frowned upon but necessary with containers of pointers due to std::auto_ptr not helping. Well, that and the lack of move semantics. But you're ultimately passing something as a void* to a library call and receiving it later as the context for a callback. That value has to live on the heap. The point isn't that nothing lives on the heap in modern C++. It's that whatever does is wrapped in a class that manages the lifetime of the allocated memory for you. Atila
Re: Thanks for the bounty!
On Friday, 4 July 2014 at 20:31:20 UTC, Walter Bright wrote: On 7/4/2014 5:49 AM, Andrej Mitrovic via Digitalmars-d wrote: Now *that* I definitely cannot work on. It's a complete conflict of interest due to our two companies. :) Dang, we can't afford any mutiny on the bounty! I just have to say, it's messages like this that keep me reading this newsgroup! :)
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 12:24:32 UTC, John Colvin wrote: There was talk of something like immutable(char)[$] = héllo͂; working, but I don't know where that went. https://github.com/D-Programming-Language/dmd/pull/3615
Re: Thanks for the bounty!
On Tuesday, 8 July 2014 at 15:57:40 UTC, David Gileadi wrote: On Friday, 4 July 2014 at 20:31:20 UTC, Walter Bright wrote: On 7/4/2014 5:49 AM, Andrej Mitrovic via Digitalmars-d wrote: Now *that* I definitely cannot work on. It's a complete conflict of interest due to our two companies. :) Dang, we can't afford any mutiny on the bounty! I just have to say, it's messages like this that keep me reading this newsgroup! :) Hah, I didn't get the joke until you said something.
@nogc and NSAutoReleasePool-style regions.
Seems to me that most of the utility beyond maintaining graph
like structures can be covered by making the compiler aware of
region allocator semantics. Assuming that the use of GC is
constrained locally and does not consume too much space. I think
it would work out ok for loading of smaller files etc with the
following kind of semantics:
Something_ptr someglobalvar;
process(A a) {
int x;
@regionalloc(1024,256) { // 1 MiB default size, 256KiB
increments
auto y = new ...; // gc new() is hijacked by @regionalloc
// assignments must be restricted so that new() ptrs and y ptrs
// are not assigned to memory that can escape the @regionalloc
// and no writes to global ptrs of region allocated objects
allowed
auto ptr = compute_with_constrained_gc_semantics(a,y)
someglobalvar = make_malloc_copy(ptr); // optimization: remove
temporary
x = obtain_some_value(ptr);
}
// region is dead here, including y and ptr objects
}
The real challenge is in putting the right constraints on the
@regionalloc block, but I guess weakly pure functions are kind of
close in their constraints. So it should be possible?
The goal would be to be able to link to libraries that aren't
@nogc aware without having the GC runtime available. For loading,
initialization etc.
Re: Bottom line re GC in D
Meta: https://github.com/D-Programming-Language/dmd/pull/3615 D is in beta release, so that pull request has to wait for 2.067+. Bye, bearophile
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 16:55:54 UTC, bearophile wrote: D is in beta release, so that pull request has to wait for 2.067+. We use release branches now. There is no reason for development activity to decline during the beta period – other than people being busy with addressing beta tester feedback and fixing regressions, of course. David
Re: nothrow function callbacks in extern(C) code - solution
Am Thu, 19 Jun 2014 12:59:00 -0700 schrieb Walter Bright newshou...@digitalmars.com: With nothrow and @nogc annotations, we've been motivated to add these annotations to C system API functions, because obviously such functions aren't going to throw D exceptions or call the D garbage collector. But this exposed a problem - functions like C's qsort() take a pointer to a callback function. The callback function, being supplied by the D programmer, may throw and may call the garbage collector. By requiring the callback function to be also nothrow @nogc, this is an unreasonable requirement besides breaking most existing D code that uses qsort(). This problem applies as well to the Windows APIs and the Posix APIs with callbacks. I just stumbled upon this thread now... In general you cannot throw exceptions unless you know how the call stack outside of your language's barrier is constructed. What I mean is that while DMD on 64-bit Linux uses frame pointers that druntime uses to unwind, GCC omits them. So druntime bails out once it reaches the C part of the call stack. That makes for two options: 1) D callbacks passed to other languages must not throw, like Andrei proposes if I understood that right. 2) Druntime must adapt to the system's C compiler's ABI. (by the use of libunwind) -- Marco
For the adventurous: News from the LDC/Linux front
Hi all,
I am excited to share news about two changes that recently made
their way into the development version of LDC, changes that might
be interesting for many of you Linux users out there.
The first is that LDC now supports linker-level dead code
elimination on Linux. If you happen to be familiar with the
-f{function,data}-sections/--gc-sections options of the GNU
toolchain, their equivalent is now enabled by default. For a set
of small-ish programs that make use of different parts of Phobos,
I've seen executable size improvements of close to 4x (!) in my
tests. However, as --gc-sections is known to occasionally cause
trouble with third-party code that relies on specific linker
behavior, this optimization can be disabled with a new LDC
switch, -disable-linker-strip-dead.
And secondly, proper support for building druntime/Phobos as
shared libraries and loading D shared objects dynamically has now
arrived in LDC! As you might be aware, Martin Nowak has spent a
considerable amount of effort on adding runtime loading
capabilities to DMD and druntime during the last year or so. LDC
now offers the same level of functionality, to a good part based
on Martin's solid work. To build a copy of LDC with
druntime/Phobos as a shared library, which is also required for
proper runtime loading, simply pass -DBUILD_SHARED_LIBS=ON to
CMake. Oh, and for now this is Linux-only too, sorry.
Even though I am currently not aware of any remaining issues,
there are likely a few rough edges still. To be able to
confidently ship these features as part of the next release, we'd
very much appreciate early feedback. Just grab LDC from Git
master and let us know how things went over on digitalmars.D.ldc.
If you run into a specific bug, you can also directly open a
ticket at https://github.com/ldc-developers/ldc/issues.
Cheers,
David
Re: Languages for servers (Go, D, and more)
On Tuesday, 8 July 2014 at 15:23:30 UTC, Atila Neves wrote: On Tuesday, 8 July 2014 at 14:24:10 UTC, Sean Kelly wrote: On Tuesday, 8 July 2014 at 02:31:50 UTC, Átila Neves wrote: On Monday, 7 July 2014 at 18:15:32 UTC, Sean Kelly wrote: With asynchronous event-driven code (ie. server code), I don't see any way to avoid all use of new / delete. std::make_unique and std::make_shared are what you're supposed to use. The new and delete operators are (usually) for library writers. Even before C++11, using delete was frowned upon but necessary with containers of pointers due to std::auto_ptr not helping. Well, that and the lack of move semantics. But you're ultimately passing something as a void* to a library call and receiving it later as the context for a callback. That value has to live on the heap. The point isn't that nothing lives on the heap in modern C++. It's that whatever does is wrapped in a class that manages the lifetime of the allocated memory for you. Well sure, but you can't use a class instance living on the stack as the context for a callback. At that point, whatever smart pointer you're using has to be discarded. This is actually why I find little use for std::shared_ptr--it has unique() and get() but no release() (which makes me wonder why they even bothered to offer unique()). It's kind of sad that the intended goal of not using raw pointers is actually forcing me to use raw pointers. In practice, I either use auto_ptr (now unique_ptr) for exception safety and release when passing to a function with a callback (in keeping with modern C++ idioms), or in containers and such I use my own shared_ptr that provides a release() function which fails if unique() is false.
Re: Languages for servers (Go, D, and more)
On Tuesday, 8 July 2014 at 17:55:15 UTC, Sean Kelly wrote: Well sure, but you can't use a class instance living on the stack as the context for a callback. At that point, whatever smart pointer you're using has to be discarded. This is actually why I find little use for std::shared_ptr--it has unique() and get() but no release() (which makes me wonder why they even bothered to offer unique()). It's kind of sad that the intended goal of not using raw pointers is actually forcing me to use raw pointers. In practice, I either use auto_ptr (now unique_ptr) for exception safety and release when passing to a function with a callback (in keeping with modern C++ idioms), or in containers and such I use my own shared_ptr that provides a release() function which fails if unique() is false. Maybe I'm misunderstanding but why not just use reset()?
Re: nothrow function callbacks in extern(C) code - solution
On Tuesday, 8 July 2014 at 17:16:27 UTC, Marco Leise wrote: 2) Druntime must adapt to the system's C compiler's ABI. (by the use of libunwind) Yes, longjmp() could happen in a callback and may be expected to unwind the stack (depending on the dev environment).
Re: Languages for servers (Go, D, and more)
On Tuesday, 8 July 2014 at 18:04:14 UTC, Brad Anderson wrote: Maybe I'm misunderstanding but why not just use reset()? reset deletes the currently referenced object.
Re: Languages for servers (Go, D, and more)
On Tuesday, 8 July 2014 at 18:23:41 UTC, Sean Kelly wrote: On Tuesday, 8 July 2014 at 18:04:14 UTC, Brad Anderson wrote: Maybe I'm misunderstanding but why not just use reset()? reset deletes the currently referenced object. Oh, I see what you were going for now.
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 17:54:48 UTC, David Nadlinger wrote: I am excited to share news about two changes that recently made their way into the development version of LDC, changes that might be interesting for many of you Linux users out there. Sounds great -- congratulations to all the LDC team! I'll try and get this installed and see how it goes.
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 17:54:48 UTC, David Nadlinger wrote:
The first is that LDC now supports linker-level dead code
elimination on Linux. If you happen to be familiar with the
-f{function,data}-sections/--gc-sections options of the GNU
toolchain, their equivalent is now enabled by default. For a
set of small-ish programs that make use of different parts of
Phobos, I've seen executable size improvements of close to 4x
(!) in my tests.
Matches my experience trying things just now -- 612 KB vs 3.2 MB
for one example on my system (the hap.random benchmark
executable), 453 KB vs 2.3 MB for another.
No linking problems so far, but then, I haven't exactly tried to
stretch things ;-)
Now to try out the shared library support ...
Re: Redesign of dlang.org
On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote: […] Powered by Martian Technology @SarcasticRover is telling us Do not come to Mars. Perhaps its commentary need censoring ;-) He also get angry when you mention that using the imperial system is idiotic.
Re: @nogc and NSAutoReleasePool-style regions.
A custom allocator can also be specified. The nice thing is, that
this doesn't even need new syntax:
process(A a) {
int x;
{
MyCustomAllocator alloc;
GC.pushAllocator(alloc);
scope(exit) GC.popAllocator();
auto y = new ...;
// alloc's destructor is called, which calls destructors
of
// allocated objects
}
}
But as you already noted, there needs to be a mechanism to
restrict escaping of pointers. Do you have some concrete idea how
that could be solved? A more or less straight-forward way would
be to encode the ownership/lifetime information somewhere in the
types of the pointers (similar to how we use const and the like
today). But this cannot be done, because it could not apply to
external (non-template) functions.
Re: For the adventurous: News from the LDC/Linux front
On 7/8/2014 1:39 PM, Walter Bright wrote: This is all great news, congratulations! On the gc-sections front, Martin had gotten it to work for DMD on Linux but then had to back it out because it failed with the ld.gold linker. If it works for ldc with ld.gold, can you please help explain what went wrong for dmd? https://github.com/D-Programming-Language/dmd/pull/3715
critique of vibe.d
There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful: has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried. If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding. Andrei
Re: For the adventurous: News from the LDC/Linux front
This is all great news, congratulations! On the gc-sections front, Martin had gotten it to work for DMD on Linux but then had to back it out because it failed with the ld.gold linker. If it works for ldc with ld.gold, can you please help explain what went wrong for dmd?
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 17:54:48 UTC, David Nadlinger wrote: And secondly, proper support for building druntime/Phobos as shared libraries and loading D shared objects dynamically has now arrived in LDC! As you might be aware, Martin Nowak has spent a considerable amount of effort on adding runtime loading capabilities to DMD and druntime during the last year or so. LDC now offers the same level of functionality, to a good part based on Martin's solid work. To build a copy of LDC with druntime/Phobos as a shared library, which is also required for proper runtime loading, simply pass -DBUILD_SHARED_LIBS=ON to CMake. Oh, and for now this is Linux-only too, sorry. Tried building hap.random's benchmarknew with the shared-library build of ldc, and got this error when I tried to run the resulting executable: Fatal Error while loading '/opt/ldc/lib/libphobos2-ldc.so.65': The module 'std.range' is already defined in './benchmarknew'.
Re: Redesign of dlang.org
On 8 July 2014 21:20, deadalnix via Digitalmars-d digitalmars-d@puremagic.com wrote: On Friday, 4 July 2014 at 07:39:51 UTC, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-04 at 07:46 +0100, Iain Buclaw via Digitalmars-d wrote: […] Powered by Martian Technology @SarcasticRover is telling us Do not come to Mars. Perhaps its commentary need censoring ;-) He also get angry when you mention that using the imperial system is idiotic. But the imperial system *isn't* idiotic. :o) And everyone should drive on the left.
Re: @nogc and NSAutoReleasePool-style regions.
On Tuesday, 8 July 2014 at 20:38:59 UTC, Marc Schütz wrote: But as you already noted, there needs to be a mechanism to restrict escaping of pointers. Yes, there ought to be, at least for @safe code. Do you have some concrete idea how that could be solved? For my use, yes. Since I am considering a D-version for game server development that does whole program analysis and might put additional restrictions on the language. I'd like to restrict the language to the extent that I can generate C code for portability (server/client code sharing)… However, it should be possible with more local annotations too, but maybe the existing ones that D provides are too weak or too strong? One needs to prevent escaping, that means: 1. prevent writing through global variables (but allow reading values, but not reading references for writing?) 2. prevent establishing new global contexts (threads and fibers) 3. putting limitations on the in-parameters to functions called within the region-allocator block so they don't allow writing to global contexts 4. ??? Sounds a lot like pure, but not quite matching up? A more or less straight-forward way would be to encode the ownership/lifetime information somewhere in the types of the pointers (similar to how we use const and the like today). But this cannot be done, because it could not apply to external (non-template) functions. It would be nice if it could fit into the current infrastructure… but all suggestions are interesting. I think it could be a nice way to get gc level convinience during spin up of a server when you have plenty of memory available (you can afford to be wasteful before you load in the main data).
Opportunities for D
Distilling the discussions about D that are elsewhere than this forum, some consistent themes emerge which we need to address to broaden the appeal of D. All of them require some organization and focussed effort to complete. There's been enough jawboning about them. I figure all of them can be smartly blown to smithereens if we just line up 3 or 4 cannons on each. 1. Ref Counting I believe that ARC is a pipe dream for D, as we've discussed extensively here. But a ref counted object should work, and would be very attractive, much like C++'s shared_ptrT. 2. Unique References unique_ptrT is another big success for C++. 2.066 has already made big strides in inferring uniqueness of expressions, but it doesn't go so far as creating a Unique!T type. 3. 'ref' means 'borrowed', to use Rust's terminology We're almost there with this. This means better escape analysis, too. 4. Eliminating gratuitous use of GC in Phobos This means allocations that are not transmitted back to the user. Here's an example of such: https://github.com/D-Programming-Language/phobos/pull/2014 5. Precise and Concurrent GC There's been a lot of work on this, but I don't know where we stand on it. 6. Pushing decisions about storage allocation upwards out of Phobos By having functions write to OutputRanges instead of to GC allocated buffers, the user can decide how to allocate the storage. 7. D-Routines - goroutines for D Goroutines are the killer feature of Go for a number of sensible people. We pretty much have this already with fibers, but what is lacking is a scheduler, which will take some effort, and a Channel type, which should be easy. 8. NotNull!T type For those that want a non-nullable reference type. This should be doable as a library type.
DIP65: Fixing Exception Handling Syntax
http://wiki.dlang.org/DIP65 tldr: There are parser and specification bugs and I want to fix them. It will break some poorly-written code, but I think I can automate the upgrade process.
Re: critique of vibe.d
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding. Google App Engine is opening up for managed servers using new tech. I know Dart is coming to the managed servers soon. Of course, this is still in limited preview and not for production, but having D on App Engine would be interesting for many reasons. https://developers.google.com/appengine/docs/managed-vms/ Google Compute Engine is also an option. Building libraries to access the regular cloud services such as Google Cloud Storage and Cloud SQL (replicated MySQL) is not too hard. https://developers.google.com/compute/ https://developers.google.com/cloud-sql/ https://developers.google.com/storage/ It would also be an opportunity to test the abstraction levels of the current standard library…
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 20:39:34 UTC, Walter Bright wrote: This is all great news, congratulations! Thanks. There was quite a bit of staring at obscure backtraces and object file dumps involved. The most persistent issue was what revealed itself to be a nasty race condition in core.thread.Fiber due to the way GCC and LLVM implement the ELF general-dynamic TLS model only after I had spent almost two days looking for it in the wrong place (quite fittingly, this now is issue #666 on our GitHub tracker). Strangely enough, I really enjoy these kinds of challenges from time to time, though. On the gc-sections front, Martin had gotten it to work for DMD on Linux but then had to back it out because it failed with the ld.gold linker. If it works for ldc with ld.gold, can you please help explain what went wrong for dmd? As far as I can tell at this point, LDC works equally well with both ld.bfd and ld.gold. Martin and I were discussing some of the specifics at the main --gc-sections ticket already [1], but it boils down to the fact that I chose to implement the ModuleInfo reference pinning in a much less beautiful, but more commonplace way. Specifically, I didn't even try to utilize R_arch_NONE relocations to fake the section dependencies, as this would have required dropping down to the machine code emission layer of LLVM. Sticking with a solution that is representable in LLVM IR meant that we can continue to use the LLVM-provided command line tools when investigating issues in the optimization/machine code generation pipeline. As a side-effect, there isn't anything special about the emitted code, making it less much probable to hit a weird edge case in one of the linkers. The current solution is ugly, though, and leads to some tens of bytes of extra junk per module linked, so we might eventually replace it with something more sophisticated. David [1] https://issues.dlang.org/show_bug.cgi?id=879
Re: Redesign of dlang.org
On 08/07/2014 10:01 PM, Iain Buclaw via Digitalmars-d wrote: But the imperial system *isn't* idiotic. :o) 14 lbs is a stone? apart from that its fine ^^ And everyone should drive on the left. I drive in the middle, it works fine until I meet other road users. A...
Re: Opportunities for D
Walter Bright: but it doesn't go so far as creating a Unique!T type. What about the already present std.typecons.Unique? In your list I'd like to add another point: 9. Built-in tuples usable in all the most important situations (with a syntax that doesn't kill possible future improvements of the switch statement to perform basic pattern matching on structs that have an optional method named unapply). Bye, bearophile
Re: Opportunities for D
Walter Bright: 3. 'ref' means 'borrowed', to use Rust's terminology We're almost there with this. This means better escape analysis, too. Is scope still left for future usage, or used for a different purpose, or deprecated? Bye, bearophile
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 20:43:19 UTC, Joseph Rushton Wakeling wrote: Tried building hap.random's benchmarknew with the shared-library build of ldc, and got this error when I tried to run the resulting executable: Fatal Error while loading '/opt/ldc/lib/libphobos2-ldc.so.65': The module 'std.range' is already defined in './benchmarknew'. As strange as it might sound, I'm actually rather relieved that you ran into this issue. I previously thought Martin's collision detection code was at fault (see https://github.com/D-Programming-Language/druntime/pull/791#issuecomment-48090942), but suddenly couldn't reproduce the issue any longer. I'll look into it. Oh, and it seems like you might be able to work around it for now by (ironically, given Martin's experiences) using ld.gold instead of ld.bfd. David
Re: Opportunities for D
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: Distilling the discussions about D that are elsewhere than this forum, some consistent themes emerge which we need to address to broaden the appeal of D. All of them require some organization and focussed effort to complete. There's been enough jawboning about them. I figure all of them can be smartly blown to smithereens if we just line up 3 or 4 cannons on each. 1. Ref Counting I believe that ARC is a pipe dream for D, as we've discussed extensively here. But a ref counted object should work, and would be very attractive, much like C++'s shared_ptrT. 2. Unique References unique_ptrT is another big success for C++. 2.066 has already made big strides in inferring uniqueness of expressions, but it doesn't go so far as creating a Unique!T type. 3. 'ref' means 'borrowed', to use Rust's terminology We're almost there with this. This means better escape analysis, too. 4. Eliminating gratuitous use of GC in Phobos This means allocations that are not transmitted back to the user. Here's an example of such: https://github.com/D-Programming-Language/phobos/pull/2014 5. Precise and Concurrent GC There's been a lot of work on this, but I don't know where we stand on it. 6. Pushing decisions about storage allocation upwards out of Phobos By having functions write to OutputRanges instead of to GC allocated buffers, the user can decide how to allocate the storage. 7. D-Routines - goroutines for D Goroutines are the killer feature of Go for a number of sensible people. We pretty much have this already with fibers, but what is lacking is a scheduler, which will take some effort, and a Channel type, which should be easy. 8. NotNull!T type For those that want a non-nullable reference type. This should be doable as a library type. All of this would be great, especially 1 and 2. unique_ptrT is helpful in 90% of the time. shared_ptrT is necessary in may be another 9%. Memory pool is helpful in another cases. And only in 0.1% case GC is really needed. :) So how about memory pool for D ? It there already one ? What about the already present std.typecons.Unique? Unfortunately there are a lot of /+Doesn't work yet+/ comments in std.typecons.Unique code.
Re: Opportunities for D
Remo: unique_ptrT is helpful in 90% of the time. shared_ptrT is necessary in may be another 9%. Memory pool is helpful in another cases. And only in 0.1% case GC is really needed. :) Are you forgetting the RefCount? But I use D because it has a GC and it doesn't look like C++, I am not writing device drivers or an operating system, I am OK with a language less efficient than C++ if it gives easier to write code, more compact code, less noisy code, much less bug-prone code. In C++11 you have over-engineered lambdas because there is no GC, D GC rely on the GC and sometimes allocate on the heap. I don't want the very bad syntax and semancits of C++ lambdas in D. Closures and lambdas are quite common in the D code I write. How do you concatenate built-in arrays without GC? And so on... So how about memory pool for D ? It there already one ? Andrei is working a lot on them. They look very good. Bye, bearophile
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 22:44:30 UTC, David Nadlinger wrote: As strange as it might sound, I'm actually rather relieved that you ran into this issue. I previously thought Martin's collision detection code was at fault (see https://github.com/D-Programming-Language/druntime/pull/791#issuecomment-48090942), but suddenly couldn't reproduce the issue any longer. I'll look into it. Thanks -- let me know if there's anything you'd like me to test. Oh, and it seems like you might be able to work around it for now by (ironically, given Martin's experiences) using ld.gold instead of ld.bfd. Well, personally I don't have any need for a workaround (it's no problem to keep using static libraries for the moment). But I'm very happy to keep trying stuff out in the process of resolving this issue.
Re: Opportunities for D
On Tuesday, 8 July 2014 at 22:56:56 UTC, bearophile wrote: Remo: unique_ptrT is helpful in 90% of the time. shared_ptrT is necessary in may be another 9%. Memory pool is helpful in another cases. And only in 0.1% case GC is really needed. :) Are you forgetting the RefCount? shared_ptrT uses reference counting. http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/shared_ptr.htm But I use D because it has a GC and it doesn't look like C++, I am not writing device drivers or an operating system, I am OK with a language less efficient than C++ if it gives easier to write code, more compact code, less noisy code, much less bug-prone code. I do not saying that GC is always bad. The future C++ standard will get GC too. It is strange but some peoples (not C++ programmers) think that D looks too much like C++ and this is bad :) For this is advantage that D looks a bit like C++ and can interact/work with C/C++ ! I like a lot of D features. Templates for example are probably easier to write in D as in C++, but I still do not have problems with them in both languages. So if I want to write a simple tool then I would use D2 instate of C++. But everything (like a 3D Renderer) that need to be as fast as possible can still only be written in C++. In C++11 you have over-engineered lambdas because there is no GC, D GC rely on the GC and sometimes allocate on the heap. I don't want the very bad syntax and semancits of C++ lambdas in D. Closures and lambdas are quite common in the D code I write. Well yes may be the lambdas syntax in C++ is not the best but it is still great addition to the language. How do you concatenate built-in arrays without GC? And so on... The same way one do this in C++ ? Copy second array at the end of the first one. If there is not enough free space in the fist array (a) then. Allocate new array bigger as size of (a+b) and copy array (a) and (b) to the new memory, then free old memory. This work reasonable well for std::vectorT . And how this will be done with GC ? So how about memory pool for D ? It there already one ? Andrei is working a lot on them. They look very good. Is the code public already ? Bye, bearophile
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 22:44:30 UTC, David Nadlinger wrote: On Tuesday, 8 July 2014 at 20:43:19 UTC, Joseph Rushton Wakeling wrote: Tried building hap.random's benchmarknew with the shared-library build of ldc, and got this error when I tried to run the resulting executable: Fatal Error while loading '/opt/ldc/lib/libphobos2-ldc.so.65': The module 'std.range' is already defined in './benchmarknew'. […] In an unexpected turn of events, it seems like you can also avoid this problem with ld.bfd by simply building with -disable-linker-strip-dead. This isn't supposed to happen. Under any circumstances. At all. Running the program in a debugger, it seems like the __bss_start/_end symbols are off, just as I encountered previously. In fact, they apparently point to an address range that isn't mapped into the process at all! I couldn't track down why this is happening yet. Here is something odd I noticed about the bfd-linked binary, though: --- $ readelf --dyn-syms benchmarknew.bfd Symbol table '.dynsym' contains 407 entries: Num:Value Size TypeBind Vis Ndx Name 0: 0 NOTYPE LOCAL DEFAULT UND 1: 0065c518 0 NOTYPE LOCAL DEFAULT 29 _edata 2: 0065d228 0 NOTYPE LOCAL DEFAULT 30 _end 3: 0065c518 0 NOTYPE LOCAL DEFAULT 30 __bss_start […] --- The __bss_start/_end symbols have somehow turned LOCAL, whereas they should be globally visible to override the ones defined in libdruntime.so. I suspect that this is involved in the nonsensical values of 0x50b4d8/0x50b728 I get inside druntime. Note also that the offset between these two addresses is also not remotely correct. David
Re: For the adventurous: News from the LDC/Linux front
On Tuesday, 8 July 2014 at 23:23:40 UTC, David Nadlinger wrote: The __bss_start/_end symbols have somehow turned LOCAL, whereas they should be globally visible to override the ones defined in libdruntime.so. Sorry for the monologue, but this might be related: https://sourceware.org/bugzilla/show_bug.cgi?id=13683 David
Re: Opportunities for D
On Tuesday, 8 July 2014 at 23:18:53 UTC, Remo wrote: So how about memory pool for D ? It there already one ? Andrei is working a lot on them. They look very good. Is the code public already ? https://github.com/andralex/std_allocator
Re: Opportunities for D
On Tuesday, 8 July 2014 at 23:43:47 UTC, Meta wrote: https://github.com/andralex/std_allocator This is much more recent: https://github.com/andralex/phobos/blob/allocator/std/allocator.d
Re: Opportunities for D
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: 8. NotNull!T type For those that want a non-nullable reference type. This should be doable as a library type. I remember Andrei seemed pretty gung-ho about mitigating nullable references in the language[0] (he made a thread about it, but I can't find it). Have you two spoken further about that option? I believe in his thread he said he wanted to introduce a compiler switch for it. [0]: http://forum.dlang.org/post/lcjg43$2vq1$1...@digitalmars.com
Re: Opportunities for D
On Tuesday, 8 July 2014 at 22:21:43 UTC, bearophile wrote: Walter Bright: but it doesn't go so far as creating a Unique!T type. What about the already present std.typecons.Unique? In your list I'd like to add another point: 9. Built-in tuples usable in all the most important situations (with a syntax that doesn't kill possible future improvements of the switch statement to perform basic pattern matching on structs that have an optional method named unapply). Bye, bearophile What if we had an opDestructure or opMatch or something like that? It could return a tuple and be auto-implemented by the compiler for simple structs/classes. Then users could precisely control how their type can be destructured.
Re: Opportunities for D
On Wednesday, 9 July 2014 at 00:25:55 UTC, Meta wrote: On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: 8. NotNull!T type For those that want a non-nullable reference type. This should be doable as a library type. I remember Andrei seemed pretty gung-ho about mitigating nullable references in the language[0] (he made a thread about it, but I can't find it). Have you two spoken further about that option? I believe in his thread he said he wanted to introduce a compiler switch for it. [0]: http://forum.dlang.org/post/lcjg43$2vq1$1...@digitalmars.com Also, a lot of people seem to be complaining lately (or at DConf, at least) about debugging mixins, template expansions, template constraints?, etc. ...And I was going to mention the proposed __ctfeWriteln, but it seems that it's already in Druntime. When did that happen?
Re: Opportunities for D
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: 1. Ref Counting I believe that ARC is a pipe dream for D, as we've discussed extensively here. But a ref counted object should work, and would be very attractive, much like C++'s shared_ptrT. How does this differ from std.typecons.RefCounted?
Re: critique of vibe.d
Vibe.d is more like a base library for async I/O, networking and concurrency, a full stack WEB framework should be built on top of it which focus on application development and ease of use for newcomers. Sonke has said that too. Vibe.d should focus on performance, networking, and other lowerlevel stuff that D should be really good at. Sonke is already too busy doing his gorgeous work on vibe.d and dub. I think that is what the guy on reddit was complaining, he thought vibe.d should contain everything from a web framework, but didn't find them, thus getting the impression that vibe.d was not complete. Actually vibe.d is just an edge of a triangle in web frameworks. We are lacking the other two pieces. We need a MVC or whatever framework on top of it. Compared to Java world, there is [Netty](http://netty.io) the networking library and Web frameworks like playframework, vert.x built on top of it. Currently the only work that is active IFAIK is Rikki's [CMSED](https://github.com/rikkimax/Cmsed), which needs more love. In [playframework](http://playframework.org), incoming request are send to a cluster of actions in a [Akka](http://akka.io) cluster for computing business logic. The trio (play, netty akka) has shown to be very good combination for a web stack. We have actor models in std.concurrency but only with thread granularity, vibe.d has got a fiber based concurrency model which I think could go in to the standard library, or make its own library. That front needs more manpower. Again, rikki has initiated a port from akka -- [dakka](https://github.com/rikkimax/dakka). I think it is a right way to go. On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful: has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried. If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding. Andrei
Re: critique of vibe.d
On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful: has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried. If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding. I use vibe.d and I have no idea what that commenter was on about. Andrei
Re: critique of vibe.d
Also, in playframework, vert.x and nodejs, they all have a plugin/module system, that people could easily compose plugins to make a website. (I call it plugin because that is what play used to call it, now they all call it a module but that name will easily conflict with D's sourcecode modules). This is a critical mechanism that actually allured developers to contribute to the eco-system. Plugins are like dub packages in a way, but not exactly. Dub packages are an encapsulation of build packages, which is similar to Java's maven packages. But plugins are components of the web framework, built on top of build packages, but has more application related meaning. So both play and vert.x have separated plugin(in vert.x is called a module) concept from maven package. Vibe.d could have this plugin mechanizem, but Sonke said that it should be the responsibility of a framework on top of it (meaning in that framework, vibe.d would just be a plugin to the framework that web developers would choose to server http requests). For example, if one designed a user/password plugin, with database access logic (in source folder), login page templates (in view folder) and static js/image/css (in public folder), and this plugin is used, then all resources are treated just as they are manually put into respective folders. While dub packages usually only deals with D code. You can see playframework's plugin registery here: http://www.playframework.com/documentation/2.3.x/Modules vert.x module's document here: http://vertx.io/mods_manual.html, vert.x has a more complicated module design (which not only is a way to group functionalities, but also a deployment node). its registery here: http://modulereg.vertx.io/ On Wednesday, 9 July 2014 at 01:09:10 UTC, Puming wrote: Vibe.d is more like a base library for async I/O, networking and concurrency, a full stack WEB framework should be built on top of it which focus on application development and ease of use for newcomers. Sonke has said that too. Vibe.d should focus on performance, networking, and other lowerlevel stuff that D should be really good at. Sonke is already too busy doing his gorgeous work on vibe.d and dub. I think that is what the guy on reddit was complaining, he thought vibe.d should contain everything from a web framework, but didn't find them, thus getting the impression that vibe.d was not complete. Actually vibe.d is just an edge of a triangle in web frameworks. We are lacking the other two pieces. We need a MVC or whatever framework on top of it. Compared to Java world, there is [Netty](http://netty.io) the networking library and Web frameworks like playframework, vert.x built on top of it. Currently the only work that is active IFAIK is Rikki's [CMSED](https://github.com/rikkimax/Cmsed), which needs more love. In [playframework](http://playframework.org), incoming request are send to a cluster of actions in a [Akka](http://akka.io) cluster for computing business logic. The trio (play, netty akka) has shown to be very good combination for a web stack. We have actor models in std.concurrency but only with thread granularity, vibe.d has got a fiber based concurrency model which I think could go in to the standard library, or make its own library. That front needs more manpower. Again, rikki has initiated a port from akka -- [dakka](https://github.com/rikkimax/dakka). I think it is a right way to go. On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful: has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried. If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding. Andrei
Re: critique of vibe.d
On Wednesday, 9 July 2014 at 01:13:39 UTC, Nick Sabalausky wrote: On Tuesday, 8 July 2014 at 20:39:23 UTC, Andrei Alexandrescu wrote: There's been some discussion about vibe.d recently on reddit (e.g. http://www.reddit.com/r/programming/comments/2a20h5/wired_magazine_discovers_d/cir9443) and I was wondering to what extent that's meaningful: has anyone ever tied a real webservice to vibe.d? I actually tried. its nowhere near complete in any sense. you simply cannot compare it with go's standard http lib, sorry, I tried. If there's sheer work needed for completing vibe.d, I think it would be great if the domain-savvy part of the community would rally around it. Serving dlang.org and dconf.org off of vibe.d would be awesome dogfooding. I use vibe.d and I have no idea what that commenter was on about. That commenter is probably a web developer that wants all batteries included. Andrei
Re: Opportunities for D
On Tuesday, 8 July 2014 at 21:22:31 UTC, Walter Bright wrote: 7. D-Routines - goroutines for D Goroutines are the killer feature of Go for a number of sensible people. We pretty much have this already with fibers, but what is lacking is a scheduler, which will take some effort, and a Channel type, which should be easy. vibe.d has something similar, which could go into the standard library IMHO: https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/core/concurrency.d
