Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
On Thursday, 10 July 2014 at 18:27:52 UTC, Andrei Alexandrescu wrote: https://twitter.com/D_Programming/status/487301149645873152 https://www.facebook.com/dlang.org/posts/882371471776535 https://news.ycombinator.com/newest http://www.reddit.com/r/programming/comments/2acqfq/dconf_2014_day_2_talk_5_tooling_bringing/ Andrei http://youtu.be/Es8st0E5428
DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 07/11/2014 05:48 PM, Andrei Alexandrescu wrote: Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei Not on HN?
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On Friday, 11 July 2014 at 15:48:13 UTC, Andrei Alexandrescu wrote: Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei Words are not even enough to express how grateful I am to Iain for doing this. Most stuff works with D1 builds too and I have completely switched to git build of gdb at work after trying it for a moment - huge productivity gain!
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
On 7/11/2014 3:11 AM, Dicebot wrote: On Thursday, 10 July 2014 at 18:27:52 UTC, Andrei Alexandrescu wrote: https://twitter.com/D_Programming/status/487301149645873152 https://www.facebook.com/dlang.org/posts/882371471776535 https://news.ycombinator.com/newest http://www.reddit.com/r/programming/comments/2acqfq/dconf_2014_day_2_talk_5_tooling_bringing/ Andrei http://youtu.be/Es8st0E5428 The youtube link should go in the reddit posting, too!
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
On 7/11/2014 10:09 AM, Walter Bright wrote: On 7/11/2014 3:11 AM, Dicebot wrote: http://youtu.be/Es8st0E5428 The youtube link should go in the reddit posting, too! Ah, I see you did already. Thanks!
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
On 11 July 2014 16:48, Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Upvote!! http://www.reddit.com/r/programming/comments/2afm4x/dconf_2014_day_2_talk_6_debugging_in_d_by_iain/ https://www.facebook.com/dlang.org/posts/882826745064341 https://twitter.com/D_Programming/status/487623887187083264 Andrei Thanks for spelling my name right this year. :)
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
http://youtu.be/Es8st0E5428 Thx alot! Enables me to watch it easily on my tv :)
Re: DConf 2014 Day 2 Talk 6: Debugging in D by Iain Buclaw
http://youtu.be/n9RNxUQ0Cyk
Re: Dconf 2014 Day 2 Talk 5: Tooling: Bringing Developers and Development Together by Brad Roberts
On 2014-07-10 20:27, Andrei Alexandrescu wrote: https://twitter.com/D_Programming/status/487301149645873152 https://www.facebook.com/dlang.org/posts/882371471776535 https://news.ycombinator.com/newest http://www.reddit.com/r/programming/comments/2acqfq/dconf_2014_day_2_talk_5_tooling_bringing/ Why don't you upload to youtube directly? -- /Jacob Carlborg
DMD v2.066.0-b3
The v2.066.0-b3 binaries are now available. The review period for beta 3 will run until 0700 UTC ( PDT, 0300 EDT, 1600 JST) on 14 July 2014, at which time binaries for RC1 will be produced and released. Due diligence in identifying regressions as early as possible is requested and appreciated. Issue 13101, [1], is provided for identifying anyfixedregressions that needs to be picked and included in RC1. B3 binaries are located here: ALL ftp.digitalmars.com/dmd.2.066.0-b3.zip OSX ftp.digitalmars.com/dmd.2.066.0-b3.dmg ftp.digitalmars.com/dmd.2.066.0-b3.osx.zip FREEBSD ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-64.zip ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-32.zip LINUX ftp.digitalmars.com/dmd_2.066.0~b3-0_i386.deb ftp.digitalmars.com/dmd_2.066.0~b3-0_amd64.deb ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.i386.rpm ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.x86_64.rpm ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.i386.rpm ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.x86_64.rpm ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_i386.deb ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_amd64.deb WINDOWS ftp.digitalmars.com/dmd-2.066.0-b3.exe ftp.digitalmars.com/dmd.2.066.0-b3.windows.zip A maintenance release is scheduled for 2.065 on September 15. Request assistance in identifying non-breaking changes (fixes) for inclusion in 2.065.1 by 30 August. Issue 13036, [2], is opened for documenting/consolidating candidates for the point release. Enjoy, Andrew [1] [Cherry-pick v2.066.0-rc1]https://issues.dlang.org/show_bug.cgi?id=13101 [2] [Cherry-pick v2.065.1-b1]https://issues.dlang.org/show_bug.cgi?id=13036
Re: DMD v2.066.0-b3
For convenience, the list of unresolved issues marked as regressions: https://issues.dlang.org/buglist.cgi?bug_severity=regressionresolution=--- Seems like there is still quite a way to go until we can release RC1. David
Re: DMD v2.066.0-b3
Also available at downloads.dlang.org On 7/11/14, 5:00 PM, Andrew Edwards via Digitalmars-d-announce wrote: The v2.066.0-b3 binaries are now available. The review period for beta 3 will run until 0700 UTC ( PDT, 0300 EDT, 1600 JST) on 14 July 2014, at which time binaries for RC1 will be produced and released. Due diligence in identifying regressions as early as possible is requested and appreciated. Issue 13101, [1], is provided for identifying anyfixedregressions that needs to be picked and included in RC1. B3 binaries are located here: ALL ftp.digitalmars.com/dmd.2.066.0-b3.zip OSX ftp.digitalmars.com/dmd.2.066.0-b3.dmg ftp.digitalmars.com/dmd.2.066.0-b3.osx.zip FREEBSD ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-64.zip ftp.digitalmars.com/dmd.2.066.0-b3.freebsd-32.zip LINUX ftp.digitalmars.com/dmd_2.066.0~b3-0_i386.deb ftp.digitalmars.com/dmd_2.066.0~b3-0_amd64.deb ftp.digitalmars.com/dmd.2.066.0-b3.linux.zip ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.i386.rpm ftp.digitalmars.com/dmd-2.066.0~b3-0.openSUSE.x86_64.rpm ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.i386.rpm ftp.digitalmars.com/dmd-2.066.0~b3-0.fedora.x86_64.rpm ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_i386.deb ftp.digitalmars.com/libphobos2-66_2.066.0~b3-0_amd64.deb WINDOWS ftp.digitalmars.com/dmd-2.066.0-b3.exe ftp.digitalmars.com/dmd.2.066.0-b3.windows.zip A maintenance release is scheduled for 2.065 on September 15. Request assistance in identifying non-breaking changes (fixes) for inclusion in 2.065.1 by 30 August. Issue 13036, [2], is opened for documenting/consolidating candidates for the point release. Enjoy, Andrew [1] [Cherry-pick v2.066.0-rc1]https://issues.dlang.org/show_bug.cgi?id=13101 [2] [Cherry-pick v2.065.1-b1]https://issues.dlang.org/show_bug.cgi?id=13036
Re: Thread Attributes
On 10/07/14 20:12, Jonathan Marler wrote:
I had an idea this morning and wanted to post it to see what people think.
I know we have alot of attributes already but I'm wondering if people
think adding a thread attribute could be useful. Something that says a
variable or function or class/struct can only be accessed by code that
has been tagged with the same thread name. Something like this.
// This variable is allocated as a true shared global
// with a fixed location in memory since it can only
// be accessed by one thread.
@thread:main
int mainThreadGlobal;
@thread:main
int main(string[] args)
{
// Start the worker thread at some point
}
@thread:worker
void workerLoop()
{
// do some work , cannot access mainThreadGlobal
}
I'm not sure I understand but if the variable can only be accessed from
a single thread, why not make it thread local?
[SNIP]
So what do people think? Like I said I just thought of this and haven't
had time think about more corner cases so feel free to nit pick:)
BTW, both of these features sounds like a job for AST macros.
--
/Jacob Carlborg
Re: How can I dump an expression into log and execute it
Delorien:
I have a C macro, which takes an argument, log it and call a
function.
So, if I had a source code like this:
{
_logfx(x + 10);
}
the actual code would be
DebugLog(x + 10);
fx(x + 10);
Can I make similar tricks in the D language?
Is a syntax like this acceptable?
mixin(LogIt!(fn, q!{x + 10}));
Bye,
bearophile
Re: @nogc required on C API callbacks?
On 10/07/14 21:21, safety0ff wrote: This isn't a plain old C function, it's an asynchronous signal handler. I though the signal handler was just an example and this was a more general question. -- /Jacob Carlborg
Re: Thread-local GC?
On Thursday, 10 July 2014 at 03:21:03 UTC, Jonathan M Davis via Digitalmars-d wrote: ... So, if we can figure out how to do it, great, but the fact that D's a systems language has a tendancy to make some stuff like that not work as easily as would be nice. - Jonathan M Davis Sure, but maybe there is too much flexibility that isn't really needed, rather a more GC friendly one, which still allows for typical systems programming use cases. A good approach would be to do a bit of archeology and try to research how GC enabled systems programming languages like Cedar, Modula-3, Oberon derivatives and Sing# had their GCs implemented across the available compilers. And respective OS. To certain extent, they were good enough to produce workable desktop OS. -- Paulo
Re: Bottom line re GC in D
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote: + If not, can it be disabled entirely/completely? Adrian, Sorry for the late reply. You may be interested in this article on the wiki (http://wiki.dlang.org/Memory_Management). It talks about different methods one can use to avoid the GC. Additionally, I want to thank the original author of this (Please speak up, you deserve attribution). I found it quite informative when I first started with D, and will likely employ some of the techniques mentioned in my future work. Mike
Re: Proposal for design of 'scope' (Was: Re: Opportunities for D)
I'm bugging around with a similar proposal for a while, but quite fail to put the last pieces in place. It goes similar in On Thursday, 10 July 2014 at 17:04:24 UTC, H. S. Teoh via Digitalmars-d wrote: - For function parameters, this lifetime is the scope of the function body. Some kind of inout scope seem less limiting. The caller know the scope, the callee know that is is greater than itself. It is important as local variable in the outer scope of the function have more restricted scope and must not be assignable. Each parameter have a DIFFERENT lifetime, but it is impossible to tell which one is larger from the callee perspective. Thus you must have a more complex lifetime definition than grater/smaller lifetime. Yup, when you get into the details, quantum effects start to arise. - An unscoped variable is regarded to have infinite lifetime. So it is not unscoped, but I'm simply nitpicking on that one. - Since a scoped return type has its lifetime as part of its type, the type system ensures that scoped values never escape their lifetime. For example, if we are sneaky and return a pointer to an inner function, the type system will prevent leakage of the This get quite tricky to define when you can have both this and a context pointer. Once again, you get into a situation where you have 2 non sortable lifetime to handle. And worse, you'll be creating values out of that mess :) - Aggregates: - It's turtles all the way down: members of scoped aggregates also have scoped type, with lifetime inherited from the parent aggregate. In other words, the lifetime of the aggregate is transitive to the lifetime of its members. Yes rule for access is transitivity. But the rule to write is antitransitive. It gets tricky when you consider that a member variable may have to be able to extend the lifetime of one of its member. IE a member of lifetime B in a value of lifetime A sees it lifetime becoming max(A, B). Considering lifetime aren't always sortable (as show in 2 examples), this is tricky. This basically means that you have to define what happen for non sortable lifetime, and what happen for union/intersection of lifetime. As you see, I've banged my head quite a lot on that one. I'm fairly confident that this is solvable, but definitively require a lot of effort to iron out all the details. - Passing parameters: since unscoped values are regarded to have infinite lifetime, it's OK to pass unscoped values into scoped function parameters: it's a narrowing of lifetime of the original value, which is allowed. (What's not allowed is expanding the lifetime of a scoped value.) Get rid of the whole concept of unscopped, and you get rid of a whole class of redundant definition that needs to be done. I'm sure there are plenty of holes in this proposal, so destroy away. ;-) Need some more iron. But I'm happy to see that some people came up with proposal that are close to what I had in mind. The above mentioned detail may seems scary, but I'm confident these will only cause problems in a small variety of cases. An aspect of the proposal that isn't mentioned is postblit and destructions. scoping will need to redefine theses. Ultimately I love the idea and think D should go in that direction at some point. But now I'd prefers see things ironed out in general in D (@safe is a good example).
Re: @nogc
On 7/10/14, 10:07 PM, Philpax wrote: I've run into my own series of trials and tribulations with a @nogc main function (i.e. entire project is @nogc). While the idea and implementation is great, its interaction with druntime/Phobos is lacking. This isn't a complete list - it's only what I remember and can reproduce now: [snip] Please paste into one or more bug reports. Thanks! -- Andrei
Re: @nogc
On 7/10/14, 10:45 PM, Philpax wrote: I also have misgivings about this - while it's the easiest solution (as I noted in my previous post), it's also antithetical to @nogc. If one rips out the GC entirely, these exceptions end up leaking memory which is arguably an even bigger problem, especially on memory-constrained platforms. Yah, I'd be hoping that @nogc guarantees you can actually not link the gc. -- Andrei
Re: Proposal for design of 'scope' (Was: Re: Opportunities for D)
On Thursday, 10 July 2014 at 20:10:38 UTC, Marc Schütz wrote:
Instead of lifetime intersections with `` (I believe Timon
proposed that in the original thread), simply specify multiple
owners: `scope!(a, b)`. This works, because as far as I can
see there is no need for lifetime unions, only intersections.
There are unions.
class A {
scope!s1(A) a;
}
scope!s2(A) b;
b.a; // = this has union lifetime of s1 and s2.
Re: Proposal for design of 'scope' (Was: Re: Opportunities for D)
On 10/07/14 20:15, H. S. Teoh via Digitalmars-d wrote:
class C {}
C myFunc(C obj) {
obj.doSomething();
return obj; // will be rejected if parameters are scoped by
default
}
Hmm, why wouldn't that work? The scope where you called myFunc is
guaranteed to outlive myFunc.
--
/Jacob Carlborg
Re: Better AAs
On Friday, 11 July 2014 at 02:32:33 UTC, Tom Compton wrote: On Sunday, 6 July 2014 at 22:53:56 UTC, bearophile wrote: Rust has not done the significant D design mistake of putting the associative arrays inside the language/runtime, but D AAs are getting better. Can someone explain why having AA's builtin to the language is such a bad thing. I would have thought that it is a good thing because of greater efficiency. There are 3 thing that you don't want to know how they are done: sausages, law and D's AA.
Re: How can I dump an expression into log and execute it
On 11/07/14 03:35, Delorien wrote:
Hi,
I have a C macro, which takes an argument, log it and call a function.
So, if I had a source code like this:
{
_logfx(x + 10);
}
the actual code would be
DebugLog(x + 10);
fx(x + 10);
Can I make similar tricks in the D language?
No, I don't think so. Not without passing it as a string to begin with.
Or AST macros, which we don't have.
--
/Jacob Carlborg
Re: @nogc
Walter Bright:
I've thought of allowing throw new ..., and yours would be in
addition to that, in @nogc functions, but was waiting to see
how this would play out a bit first.
It's true that currently significant parts of Phobos can't be
@nogc, but the solution is not to turn @nogc into its opposite.
See:
https://d.puremagic.com/issues/show_bug.cgi?id=12768
With a comment by monarchdodra:
static err = new immutable(RangeError)();
I'm surprised this works. If the exception is Immutable,
then how can we chain it? If we catch Exception, then
we are making something immutable mutable. If we mutate
the exception, then not only do we break the type system,
but it also means the code isn't actually pure:
//
void foo() pure
{
static err = new immutable(RangeError)(error);
throw err;
}
void main()
{
try
foo();
catch(Error e)
{
e.msg = yo!;
}
foo(); //core.exception.RangeError@main.d(7): yo!
}
Bye,
bearophile
Re: Cool Stuff for D that we keep Secret
On 11/07/14 01:15, Nick Sabalausky wrote: I'm kinda jealous of those pro gamedevs with a dual-monitor, one of them being vertical, setup. I should do that. With one of those desks that can adjust to/from standing position. That'd be sweet :) I have a colleague that has five monitors (kind of). Three external monitors and two laptops. -- /Jacob Carlborg
Re: Cool Stuff for D that we keep Secret
On 11/07/14 01:15, Nick Sabalausky wrote: And then there's responsive which *claims* to be mobile-first design (which would be ok), but in actual practice it's really more like mobile-only design. Actually, there was a site here to check the time tables for the subway, buses and son on. They had a desktop version and a mobile version. I always used the mobile version on desktop. Because it didn't have all the crap the the desktop version had. It literally only had a logo and a form where I could enter where I would like to go and when. Unfortunately they then redesigned the website to only have a single one what work on all platforms :( On my phone I used an app instead. -- /Jacob Carlborg
Re: Cool Stuff for D that we keep Secret
On 11/07/14 00:24, H. S. Teoh via Digitalmars-d wrote: I used to love pdfs in blissfully ignorance... until I recently looked up the format. You wouldn't believe this, but did you know that it's actually possible to embed a *video* in a pdf file? Embed another pdf inside a pdf in a hierarchical substructure? Run arbitrary JS code from a pdf? (Which, btw, is *not* the official JS, but Adobe's own hackneyed version thereof.) If you were insane enough, I bet you could implement an OS inside a pdf file. Or an FPS. Why do you think there's so many PDF security holes ;) -- /Jacob Carlborg
Re: @nogc
On Friday, 11 July 2014 at 06:41:56 UTC, Andrei Alexandrescu wrote: On 7/10/14, 10:07 PM, Philpax wrote: I've run into my own series of trials and tribulations with a @nogc main function (i.e. entire project is @nogc). While the idea and implementation is great, its interaction with druntime/Phobos is lacking. This isn't a complete list - it's only what I remember and can reproduce now: [snip] Please paste into one or more bug reports. Thanks! -- Andrei Will do once I get back to work on that project and come up with test cases.
Re: @nogc
On Friday, 11 July 2014 at 02:32:00 UTC, Manu via Digitalmars-d wrote: I have this in my 'nothrow @nogc' function: assert(false, Message ~ details); It complains Error: cannot use operator ~ in @nogc function I've habitually used 'format' to prepare assert messages with variable content, which has a similar problem -- IIRC it conflicts with nothrow and I guess it too would conflict with @nogc.
Need Feedback for a new book - D Cookbook
Hi guys, I'm looking for some feedback on a recently published book on D programming language, namely, D Cookbook. Link to the book page: http://www.packtpub.com/discover-advantages-of-programming-in-d-cookbook/book If anybody is interested, please send a mail to me on pausha...@packtpub.com OR You can comment below this post stating your interest (for e.g., your email id and where would you like to share your feedback - Amazon, Goodreads, your own blog, etc.) I appreciate your help regarding this!
Re: @nogc
Joseph Rushton Wakeling: I've habitually used 'format' to prepare assert messages with variable content, which has a similar problem -- IIRC it conflicts with nothrow and I guess it too would conflict with @nogc. A solution is to add to Phobos a way to format to an output range, where the range you use a stack-allocated array of chars large enough to contain your formatted message. So on the whole it can be @nogc. Bye, bearophile
Re: Cool Stuff for D that we keep Secret
On 10 July 2014 23:24, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thu, Jul 10, 2014 at 10:13:14PM +, via Digitalmars-d wrote: On Thursday, 10 July 2014 at 22:03:31 UTC, Nick Sabalausky wrote: Am I the only one who thinks Responsive Web sites, with their characteristic Replace all meaningful information with wasted space, meaningless photos, and trite slogans in giant text, are an absolutely horrible design that do more to drive people away and trigger their this looks like an ad, I'll subconsciously ignore it instinct? I dislike 'em, but survive if it is limited to the frontpage. Meaning: I desperately look for a sensible link in the visual mess of non-information. I also get the idea that they probably don't really have anything to offer and hired an ad company with an incompetent web designer to do it who arrived at the design by buying a premade page from some other's company's catalogue, then replaced the photos and charged a fortune for it... OR worse: that they are using a PHP-based CMS. Then I start to feel sorry for them and put all my skepticism aside for the benefit of the doubt and hope that I at least find a sensible pdf-file in there somewhere. I used to love pdfs in blissfully ignorance... until I recently looked up the format. You wouldn't believe this, but did you know that it's actually possible to embed a *video* in a pdf file? Embed another pdf inside a pdf in a hierarchical substructure? Run arbitrary JS code from a pdf? (Which, btw, is *not* the official JS, but Adobe's own hackneyed version thereof.) If you were insane enough, I bet you could implement an OS inside a pdf file. Or an FPS. I wonder if you could embed this in a PDF http://bellard.org/jslinux/
Re: Fixed size array return
Dmitry Olshansky: IMO this is a good idea and it pretty much NRVO/RVO for structs extended to fixed-size arrays (which more or less a special kind of struct). Since C/C++ do not have fixed-size arrays passed by value I see no damage to ABI compatibility. OK, filed as: https://issues.dlang.org/show_bug.cgi?id=13093 We'll see if Walter likes it enough. Bye, bearophile
Re: @nogc
On Friday, 11 July 2014 at 07:45:24 UTC, bearophile wrote: Joseph Rushton Wakeling: I've habitually used 'format' to prepare assert messages with variable content, which has a similar problem -- IIRC it conflicts with nothrow and I guess it too would conflict with @nogc. A solution is to add to Phobos a way to format to an output range, where the range you use a stack-allocated array of chars large enough to contain your formatted message. So on the whole it can be @nogc. Bye, bearophile Although I think that is certainly something that would be helpful/necessary, it wouldn't solve the problem of printing out assert messages/exception messages. Basically, the only way I could think to do it is to make a special `NoGCException` that has a `detailMsg` function (taking a `sink`, of course) and your subclass of `NoGCException` would store all the info necessary to print out the error at the catch site and you'd just overload `detailMsg` to print it out properly. https://gist.github.com/Zshazz/47ed52c3246e5348062a That's an example. I store info at line 84 as a tuple in my `SpecialNoGCException`, and set the storage when I'm about to throw at line 202. My apologies for the poor code (I made that stuff as an experiment). It works, but pre-allocating the initial exception is still problematic, IMO. I'd really like a way of specifying that an exception was malloc'd and it's the catcher's job to free it. Obviously, I could just do it but it seems pretty unsafe and error-prone. *shrug*
Re: @nogc
On Friday, 11 July 2014 at 05:41:50 UTC, Manu via Digitalmars-d wrote: I've thought of allowing throw new ..., and yours would be in addition to that, in @nogc functions, but was waiting to see how this would play out a bit first. I should add, I'm not sure I see that my case should be 'in addition'. I think my case should precede since I don't think it's objectionable, but I'm really unsure I would get on board with 'throw new ...' in @nogc functions. It seems to defeat the purpose to me...? Why would you want to allow throwing 'new' exceptions? Would be great to be able to speficify a custom allocator to exceptions thrown, or at least have it malloc somehow.
Re: @nogc
On Friday, 11 July 2014 at 07:45:24 UTC, bearophile wrote: range, where the range you use a stack-allocated array of chars Actually, thinking about this more, it's possible if the array of chars is malloc'd instead and written to (of course, that's not `@noalloc`, but that's ok). It's just stack-allocated this way isn't possible since the exception can be thrown into a scope above your stack allocated chars.
Re: @nogc
A solution is to add to Phobos a way to format to an output range, where the range you use a stack-allocated array of chars large enough to contain your formatted message. So on the whole it can be @nogc. That function exists already, it just needs to become @nogc, I even filed a ER on this: https://d.puremagic.com/issues/show_bug.cgi?id=13055 Bye, bearophile
Re: @nogc
On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote: I've thought of allowing throw new ..., and yours would be in addition to that, in @nogc functions, but was waiting to see how this would play out a bit first. One can replace throwing of Error with printf + abort in @nogc blocks, similar to how assert(false) is reduced to HLT in release builds. Spec allows it. Throwing exceptions should still result in compile-time error though, it is one of primary use cases of @nogc.
Re: @nogc
On Friday, 11 July 2014 at 09:29:58 UTC, Dicebot wrote: On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote: I've thought of allowing throw new ..., and yours would be in addition to that, in @nogc functions, but was waiting to see how this would play out a bit first. One can replace throwing of Error with printf + abort in @nogc blocks, similar to how assert(false) is reduced to HLT in release builds. Spec allows it. Throwing exceptions should still result in compile-time error though, it is one of primary use cases of @nogc. *throwing _new_ exceptions
Re: Opportunities for D
On 10/07/2014 19:03, Walter Bright wrote: On 7/10/2014 9:00 AM, Nick Treleaven wrote: On 09/07/2014 20:55, Walter Bright wrote: Unique!(int*) u = new int; // must work That works, it's spelled: Unique!int u = new int; I'm unconfortable with that design, as T can't be a class ref or a dynamic array. It does currently work with class references, but not dynamic arrays: Unique!Object u = new Object; It could be adjusted so that all non-value types are treated likewise: Unique!(int[]) v = [1, 3, 2]; int* p = new int; Unique!(int*) u = p; // must fail The existing design actually allows that, but nulls p: [...] If there are aliases of p before u is constructed, then u is not the sole owner of the reference (mentioned in the docs): http://dlang.org/phobos-prerelease/std_typecons.html#.Unique Exactly. It is not checkable and not good enough. In that case we'd need to deprecate Unique.this(ref RefT p) then. Note that as of 2.066 the compiler tests for uniqueness of an expression by seeing if it can be implicitly cast to immutable. It may be possible to do that with Unique without needing compiler modifications. Current Unique has a non-ref constructor that only takes rvalues. Isn't that good enough to detect unique expressions? Also related is whether we use alias this to expose the resource (allowing mutation but not replacement) or if we use opDispatch. Currently, it uses opDot, which AFAICT is basically opDispatch. If we use alias this, that's a(nother) hole exposing non-unique access to the resource. The holes must be identified and closed. OK, opDispatch then. BTW, I'm amenable to adjusting the compiler to recognize Unique and help out as a last resort.
Re: Opportunities for D
On Thursday, 10 July 2014 at 22:50:51 UTC, Walter Bright wrote: On 7/10/2014 1:52 PM, bearophile wrote: Walter Bright: I can't imagine users going to the bother of typing all that, let alone what happens when they do it wrong. Most users don't really have a good handle on what the lifetimes of their data are, so how are they going to annotate it correctly? I suggest you to go in the Rust mailing list and ask this question again. Rust has very little experience in real projects. I know that people see all the hype about Rust and believe it has proved itself, but it hasn't. I've read other papers about annotations in Java and how people just refused to annotate their references. This might have something to do with both the mindset of Java (isn't the runtime supposed to take care of this sort of thing?) and the fact that Java is already monstrously verbose.
Re: Opportunities for D
On 10/07/14 22:31, Walter Bright wrote: I don't know the PR link nor do I know what pseudonym you use on github, so please help! I reiterate my complaint that people use virtual functions for their github handles. There's no reason to. Who knows that 9il is actually Ilya Yaroshenko? Took me 3 virtual function dispatches to find that out! Talking about Github pseudonyms. I think it's very confusing that Hara Kenji is using a different author for his commits than his Github pseudonym. He commits as k-hara, which doesn't exist on Github. But his Github pseudonym is 9rnsr. -- /Jacob Carlborg
Re: Opportunities for D
On Tuesday, 8 July 2014 at 23:43:47 UTC, Meta wrote: Is the code public already ? https://github.com/andralex/std_allocator Maybe Andrei should remove this outdated version to reduce confusion, if nobody uses it that is :) /Per
Re: FLOSS Weekly
On Tuesday, 18 March 2014 at 05:57:31 UTC, NVolcz wrote: Hi! This is mostly targeted to Walter and Andrei. I'm a big podcast/netcast listener, I can't live without it! One of the shows that I'm listening to and from work is FLOSS weekly with Randal L. Schwartz from the TWIT network. http://twit.tv/show/floss-weekly Other languages has been interview several times and I'm would very much like to see my favorite Dlang on the show as well. To get onto the schedule please email mer...@stonehenge.com. I agree, FLOSS Weekly is a brilliant way to reach new people. Like NVolcz suggest, Randall (the host) strongly prefers the project leaders to contact him directly, because that makes it much easier to organize a date. Although the list of upcoming guests looks long, Randall very much prioritizes project leaders that contact him directly. Cheers, Edwin
Lexical, Syntatic and Semantic Merge of D Source Code
Now that we have reasonable support for lexing and parsing D in D through Dscanner/libdparse/DCD I believe it would be worth the effort to try to implement D-specific merge algorithms that operate on either the - D token stream or - a D parse tree possibly making use of semantic information. This would also require functions that write them back to the original source representation, of course preserving whitespace indentations. A token-based merger would be quite easy to implement and will resolve conflicts where multiple symbol renamings have occurred on the same line. Something that current mainstream line-based algorithms cannot handle. This could be useful when test-merging Git branches on Github. It also could be that these algorithms will have things in common with DustMite's algorithms. What do you say, Cybershadow? I could help implementing these ideas when necessary. Have perhaps anybody already cooked up some D implementations of generic diff/merge algorithms? If not could anybody point out a good reference implementation in C/C++ to start with?
Re: Lexical, Syntatic and Semantic Merge of D Source Code
On Friday, 11 July 2014 at 13:58:53 UTC, Nordlöw wrote: Other languages already have this through proprietary software. See for example http://www.semanticmerge.com/
Re: Opportunities for D
On Thursday, 10 July 2014 at 21:46:50 UTC, Ola Fosheim Grøstad wrote: On Thursday, 10 July 2014 at 21:40:15 UTC, Sean Kelly wrote: :-) To compensate, I use the same virtual function literally everywhere. Same icon photo too. That's Go… And Go is awesome. I could change it to my face, but since that's on gravitar it would show up all over the place and I don't really want that.
Re: Cool Stuff for D that we keep Secret
On 7/10/14, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: The simplest thing do for each and every member of this community is to have accounts on all social news sites (twitter, facebook, reddit, hackernews) and discuss _there_ things instead of replying to announcements internally. We like talking here because it's a small but friendly group, and we all know each other to the extent that we can (most of the time) tell when someone is being sarcastic or is just having a bad day. It's like having dinner with the family vs having dinner with a bunch of strangers. Also, I'm tired of the constant what do you think about D vs Rust vs Go crap that is always asked on Reddit. The D forums kick ass, the people here are great.
Re: How can I dump an expression into log and execute it
On Fri, Jul 11, 2014 at 08:57:26AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 11/07/14 03:35, Delorien wrote:
Hi,
I have a C macro, which takes an argument, log it and call a
function. So, if I had a source code like this:
{
_logfx(x + 10);
}
the actual code would be
DebugLog(x + 10);
fx(x + 10);
Can I make similar tricks in the D language?
No, I don't think so. Not without passing it as a string to begin
with. Or AST macros, which we don't have.
[...]
Sure you can:
auto logAndCall(alias func, string expr)() {
DebugLog(expr);
return func(mixin(expr));
}
double myFunc(double arg) { ... }
auto result = logAndCall!(myFunc, q{1.0 + 2.0/4});
T
--
I've been around long enough to have seen an endless parade of magic new
techniques du jour, most of which purport to remove the necessity of thought
about your programming problem. In the end they wind up contributing one or
two pieces to the collective wisdom, and fade away in the rearview mirror. --
Walter Bright
Re: Better AAs
On Fri, Jul 11, 2014 at 02:32:31AM +, Tom Compton via Digitalmars-d wrote: On Sunday, 6 July 2014 at 22:53:56 UTC, bearophile wrote: Rust has not done the significant D design mistake of putting the associative arrays inside the language/runtime, but D AAs are getting better. Can someone explain why having AA's builtin to the language is such a bad thing. I would have thought that it is a good thing because of greater efficiency. IMO, it's not a bad thing to put AA's in a language in general. In fact, when I was first considering using D, having built-in AA's in the language was one of the big plusses for me. To this day, I still can't get over the fact that C++ didn't even have AA's in the standard until C++11, and the AA's in C++11 are so cumbersome to use that the last time I tried, I almost tore out all my hair. In contrast, D's AA's, for all their flaws, are at least *pleasant* to use without needing to reinvent your own hash functions for every single struct, every single time. However, due to historical reasons, the current *implementation* of AA's in D leaves a lot to be desired. That's rather disappointing, but I *will* say that for the most common, basic use cases of AA's, even the current AA's in D are actually quite useful, and quite handy for simple problems. We're all hoping the implementation could be improved, though, so that it would also work for the not-so-simple cases, and that some current nasty design-related bugs would finally be fixed. T -- Caffeine underflow. Brain dumped.
Re: Proposal for design of 'scope' (Was: Re: Opportunities for D)
On Fri, Jul 11, 2014 at 08:56:10AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 10/07/14 20:15, H. S. Teoh via Digitalmars-d wrote:
class C {}
C myFunc(C obj) {
obj.doSomething();
return obj; // will be rejected if parameters are scoped by
default
}
Hmm, why wouldn't that work? The scope where you called myFunc is
guaranteed to outlive myFunc.
[...]
Because the scope of the parameter 'obj' is defined to be the scope of
myFunc only, according to the current proposal.
T
--
What are you when you run out of Monet? Baroque.
Re: @nogc
On Fri, Jul 11, 2014 at 04:00:01AM +, Chris Cain via Digitalmars-d wrote: On Friday, 11 July 2014 at 03:45:17 UTC, Walter Bright wrote: I've thought of allowing throw new ..., and yours would be in addition to that, in @nogc functions, but was waiting to see how this would play out a bit first. Errors I agree with (basically, that's the end of your program, so violating @nogc is irrelevant in that case). throw new ... being allowed in general feels to me like it'll break the entire point of `@nogc` code for many people. `@nogc` was (or, at least I thought it was) designed to stop having people from having to read through implementations of everything their using to verify nothing is using the gc, which was error prone and time consuming. Allowing parts of libraries to throw/get caught somewhere inside of `@nogc` code makes it so you have to go back to manually verifying their not using exception handling somewhere. Sure, it reduces the potential footprint of such, but we're right back to the same old problem again that `@nogc` was supposed to solve. So for people saying Oh, I want to avoid the GC in D, they'll just complain about how `@nogc` still allows you to hit the GC unintentionally once they find out. Then we'll have requests for `@reallynogc` to be added. Wouldn't @reallynogc == @nogc + nothrow ? T -- The only difference between male factor and malefactor is just a little emptiness inside.
Re: Cool Stuff for D that we keep Secret
On Fri, Jul 11, 2014 at 04:17:16PM +0200, Andrej Mitrovic via Digitalmars-d wrote: On 7/10/14, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: The simplest thing do for each and every member of this community is to have accounts on all social news sites (twitter, facebook, reddit, hackernews) and discuss _there_ things instead of replying to announcements internally. We like talking here because it's a small but friendly group, and we all know each other to the extent that we can (most of the time) tell when someone is being sarcastic or is just having a bad day. It's like having dinner with the family vs having dinner with a bunch of strangers. Also, I'm tired of the constant what do you think about D vs Rust vs Go crap that is always asked on Reddit. The D forums kick ass, the people here are great. I agree. The sense of community in these forum is what draws me to participate; normally I don't like posting things online. Having said that, though, I do try to post things I find interesting on google+ every now and then. (Though in practice that turns out to be once every few months, which is probably too infrequent to be significant.) T -- There is no gravity. The earth sucks.
Review: std.logger
Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Code: https://github.com/D-Programming-Language/phobos/pull/1500 Documentation: http://burner.github.io/phobos/phobos-prerelease/std_logger_core.html http://burner.github.io/phobos/phobos-prerelease/std_logger_stdiologger.html http://burner.github.io/phobos/phobos-prerelease/std_logger_filelogger.html http://burner.github.io/phobos/phobos-prerelease/std_logger_multilogger.html http://burner.github.io/phobos/phobos-prerelease/std_logger_nulllogger.html http://burner.github.io/phobos/phobos-prerelease/std_logger_templatelogger.html DUB package: http://code.dlang.org/packages/logger Previous discussion thread: http://forum.dlang.org/post/mailman.313.1377180809.1719.digitalmar...@puremagic.com == Summary of changes since last discussion (by Robert): * logger is now a package of multiple files * a lot more documentation * log and logf now behave as their write and writef counterparts * for logging with an explicit LogLevel call logl loglf * for logging with an explicit condition call logc logcf * for logging with an explicit LogLevel and explicit condition call loglc loglcf * the log function with an explicit LogLevel like info, warning, ... can be extended into c, f or cf and therefore require a condition and/or are printf functions * unittest have been updated * dub package for easy testing == This is one of long sanding Phobos candidates Robert has put some great effort into. As far as I know it is already used in several D projects and it is a good moment to make it official. Review goals, as usual : verify that API is robust enough to build more complicated logging systems on top of it, verify Phobos style compatibility, check if provided documentation is complete and friendly enough. Base for review process is defined by http://wiki.dlang.org/Review/Process
Re: Review: std.logger
On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote: Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Is this for std.* or std.experimental.*? David
Re: Review: std.logger
As usual, this review round will last for 2 weeks unless someone asks for delay. Please share link to this thread via twitter, reddit, G+ and whatever else may be used out there.
Re: Cool Stuff for D that we keep Secret
On Thursday, 10 July 2014 at 23:15:41 UTC, Nick Sabalausky wrote: I'm fairly certain they don't. Heck, I can't even find a 5:4 anymore which at least isn't *as* bad as 16:9. Tolerable, at least. If you're willing to pay a bit more, you can get 16:10 which is...actually not that bad. I think it strikes a good balance. Better still, Google has some laptops with 3:2 screens that I'd love to have elsewhere. But as for *actual* 4:3, or even 5:4, I really do doubt they're still manufactured. I think there's still a few 5:4? But for the most part, no. A big part of the push comes back to marketing BS: Display sizes are measured by their diagonal, so you can advertise a 20 widescreen for more money, even though it cost less to make than a 19 at 4:3 or 5:4. And it's cinematic! orz I think the best bet for 4:3 is to just look for a used CRT. (Heck, at least they can display more than one resolution without looking bad.) I'm kinda jealous of those pro gamedevs with a dual-monitor, one of them being vertical, setup. I should do that. With one of those desks that can adjust to/from standing position. That'd be sweet :) If you want a seriously good CRT, you pretty much want a Trinitron. For PCs, my personal recommendation is the G-series. I had a G200 (17 flat tube) for about ten years and it could push 1600x1200 at 85Hz and even do 2560x1600 at 60Hz. If you're using old consoles, you can't go wrong with a PVM (it works pretty well with a supergun too, though it still can't do some of the wacky modes like what Gun Frontier and Metal Black use). (And it'd be *fantastic* for fans of vertical sh'mups!) Can confirm. ;) -Wyatt
Re: Opportunities for D
On Thursday, 10 July 2014 at 20:31:53 UTC, Walter Bright wrote: I reiterate my complaint that people use virtual functions for their github handles. There's no reason to. Who knows that 9il is actually Ilya Yaroshenko? Took me 3 virtual function dispatches to find that out! So, final by default in D? ;) -Wyatt
Re: Review: std.logger
On Friday, 11 July 2014 at 14:39:09 UTC, David Nadlinger wrote: On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote: Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Is this for std.* or std.experimental.*? David Deciding this is subject of this review/voting iteration too - it is mostly matter of API stability, how much of a trust reviewers are ready to put into existing API. Personally I believe that for something like logging library stabilization period of one release cycle in std.experimental is desirable because wider usage is very likely to result in breaking change suggestions.
Re: Review: std.logger
The API seems nice and simple while providing enough flexibility, and I think it would work quite well for my purposes. Some comments: API: Not clear what the difference between globalLogLevel and a log level on each individual logger is. Does the global one only affect the global logger? What happens if you change the globalLogLevel and the logLevel on the logger set as the global one? Documentation: Logger Constructor: The fatal handler will throw, and Error if a log call is made with a LogLevel LogLevel.fatal. - Should be will throw an error if. LogManager class: It also handels the defaultLogger which is used - Should be handles. LogManager class: also allows to retrieve Logger by there name - Should be their. LogManager class: The static LogManager handles the creation, and the release - The comma shouldn't be there. defaultLogger: that means it can be assigend - assigned defaultLogger: The Logger is returned as a reference that means it can be assigend, thus changing the defaultLogger. - Wording is a bit odd right now, perhaps something like The Logger is returned as a reference, meaning it can be assigned to change the defaultLogger..
Re: Review: std.logger
On Friday, 11 July 2014 at 14:38:19 UTC, Dicebot wrote: As usual, this review round will last for 2 weeks unless someone asks for delay. Please share link to this thread via twitter, reddit, G+ and whatever else may be used out there. On lines 606 and 729 in the comments: /** This class is the base of every logger. In order to create a new kind of logger a derivating class needs to implementation the method $(D writeLogMsg). */ I think deriving would be a better word to use.
API: string formatting / memory management
Am Fri, 11 Jul 2014 14:36:30 + schrieb Dicebot pub...@dicebot.lv: Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Code: https://github.com/D-Programming-Language/phobos/pull/1500 https://github.com/D-Programming-Language/phobos/pull/1500/files#diff-165d04f1fd1a1db2c37af18580f41fb4R421 The 'frontend' log methods call format and the pass the formatted string to the Logger implementations. I still wonder if we can do better, and if we need to modify the API for that. I've got three ideas: * Using some sort of static buffer in the log* functions. I don't like this that much cause it will limit the msg string length * Use malloc: This way no GC allocations, but still dynamic memory allocation which might not be necessary if you log e.g. to the console or a file. These two options have the benefit that the API can remain unchanged and they could be implemented after the review. The third option requires changes to the API. We overload -- writeLogMsg(ref LoggerPayload payload); with writeLogHeader(ref LoggerPayload header); -- And add another function: -- void put(/*scope*/ const(char)[] msg); -- writeLogHeader would receive all data as usual, except for the message string. Then after calling writeLogHeader, the (formatted) message string will be passed in any number of calls to put. I used put here to make this output-range compatible. This way it plugs directly into formattedWrite. An logger can still receive the complete string by appending the chunks received in put but we might need some 'finish' function to signal the end of the message. I guess not all loggers can fit into this interface, so we should try to make this optional. But simple loggers (file, console) which write the header first and the message last could work without any dynamic memory allocation. (formattedWrite probably uses an fixed-size buffer on the stack, but that's fine)
Using D
I have followed the recent discussions about D and I can see the usual pattern, to wit GC, Go (or whatever) is so much better, everyone blaming each other for not contributing, not being allowed to contribute blah. First of all, I am in no position to criticize anyone who is contributing to the language. I don't contribute, because I don't have the time to do so. Indeed I have huge, massive respect for everyone who contributes to D. The only thing I do is to actually use the language and tell everyone about it. I have developed a screen reader plug in in D (using C libraries) that was ridiculously easy to integrate on Windows as a DLL. I used vibe.d to create a lightning fast online version of the screen reader. Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. I compiled both applications with dmd (testing phase) not with ldc or gdc and they are very fast. Let's not forget that Go has millions and billions of dollars behind it and that it is inevitable that the whole internet will be full of zealots and professional posters who promote Go as th best thing ever. People. Sheep. Meehhh. Apart from the necessary discussions about language features / improvements we need to focus on the power of D. vibe.d is one example. I think the problem is that we don't bundle the various efforts that have been made independently well enough. Contribution to D is narrowly defined as contributing to the library / core of the language. There has been mention of integrating vibe.d's fibers into the library. Even if it won't happen, we should set up an infrastructure that facilitates the use of the various, as of now independent, components and point users to it. I have to say that a lot of good things have escaped me simply because nobody told me about them. It's often by accident that I find out about a great library or framework in D. Sometimes I have the feeling that we blow things out of proportion, because we walk right into the trap. The GC thing, although it is very important, is a good example. Let's not forget that zeolots and professional posters will always point out the flaws of D, and blow them out of proportion. D doesn't have xyz, so it's shit! Divide et impera (divide and rule). Let's first make a list of things that have been achieved with D and that are on a par with or even bettar than in other languages (C, C++, C#, Go, Rust ...). Then, let's bundle the efforts that have been made independently. We will soon have a powerful and impressive framework. And let's not forget, a language (be it a natural or a computer language) only lives and thrives, if people use it. My 2 cents. At your service.
Re: Using D
On 07/11/2014 05:30 PM, Chris wrote: (...) Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. (...) I agree with this. The bottlenecks i my applications are MySQL and Microsoft Office (Excel, Powerpoint, or even just plain COM). The same bottlenecks as I get when using C#. Of course, it depends a lot on what you do, but for my use (and yours, and probably many others), the GC performance is something you can probably safely ignore. A little anecdote.. I once got a 20% speed increase in Python by moving a variable instantiation outside a tight loop. i = 0 # loop here i = something rather than # loop here i = something The compiler wasn't smart enough to do this.
Re: Using D
On 07/11/2014 05:43 PM, simendsjo wrote: On 07/11/2014 05:30 PM, Chris wrote: (...) Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. (...) (...) Oh, and a little GC.disable()/GC.enable() goes a long way. Only had to do this a couple of times though.
Re: Cool Stuff for D that we keep Secret
On 7/11/14, 7:17 AM, Andrej Mitrovic via Digitalmars-d wrote: On 7/10/14, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: The simplest thing do for each and every member of this community is to have accounts on all social news sites (twitter, facebook, reddit, hackernews) and discuss _there_ things instead of replying to announcements internally. We like talking here because it's a small but friendly group, and we all know each other to the extent that we can (most of the time) tell when someone is being sarcastic or is just having a bad day. It's like having dinner with the family vs having dinner with a bunch of strangers. Also, I'm tired of the constant what do you think about D vs Rust vs Go crap that is always asked on Reddit. The D forums kick ass, the people here are great. It all depends on whether one's primary goal is to have a good time or push this language forward. -- Andrei
Re: Cool Stuff for D that we keep Secret
On Friday, 11 July 2014 at 14:17:27 UTC, Andrej Mitrovic via Digitalmars-d wrote: On 7/10/14, Andrei Alexandrescu via Digitalmars-d digitalmars-d@puremagic.com wrote: The simplest thing do for each and every member of this community is to have accounts on all social news sites (twitter, facebook, reddit, hackernews) and discuss _there_ things instead of replying to announcements internally. We like talking here because it's a small but friendly group, and we all know each other to the extent that we can (most of the time) tell when someone is being sarcastic or is just having a bad day. It's like having dinner with the family vs having dinner with a bunch of strangers. Also, I'm tired of the constant what do you think about D vs Rust vs Go crap that is always asked on Reddit. The D forums kick ass, the people here are great. I think the Rust vs Go vs D stuff isn't crap - it's important. People want to know why they should pick D over the other emerging languages, and what D offers in comparison. I think D would also gain a lot from a website redesign and more information about the tools available for D(e.g, DCD) without having to go digging for them. Just my 2 cents from someone who only dabbles in D.
Re: Lexical, Syntatic and Semantic Merge of D Source Code
On Friday, 11 July 2014 at 13:58:53 UTC, Nordlöw wrote: the effort to try to implement D-specific merge algorithms that Correction: If mean the effort to try to implement D-specific diff and merge algorithms .
Re: Cool Stuff for D that we keep Secret
On 7/11/14, 9:02 AM, Weasel wrote: I think the Rust vs Go vs D stuff isn't crap - it's important. People want to know why they should pick D over the other emerging languages, and what D offers in comparison. Yes. It is a duty of each member of our community to correct (m|d)isinformation if present, and to provide good information about the realities of D. -- Andrei
Re: Opportunities for D
On Fri, Jul 11, 2014 at 01:14:37AM +, Meta via Digitalmars-d wrote: On Friday, 11 July 2014 at 01:08:59 UTC, Andrei Alexandrescu wrote: On 7/10/14, 2:25 PM, Walter Bright wrote: On 7/10/2014 1:49 PM, Robert Schadek via Digitalmars-d wrote: https://github.com/D-Programming-Language/phobos/pull/1977 indexOfNeither I want to defer this to Andrei. Merged. -- Andrei For any other aspiring lieutenants out there, this[0] has been sitting around for 5 months now. [0]https://github.com/D-Programming-Language/phobos/pull/1965#issuecomment-40362545 Not that I'm a lieutenant or anything, but I did add some comments. T -- Some days you win; most days you lose.
Re: Using D
On Fri, 2014-07-11 at 15:30 +, Chris via Digitalmars-d wrote: […] Let's not forget that Go has millions and billions of dollars behind it and that it is inevitable that the whole internet will be full of zealots and professional posters who promote Go as th best thing ever. People. Sheep. Meehhh. (I think I detect unintended irony in this post :-) Go, via goroutines, promotes CSP as an approach to application parallelism and is therefore a Good Thing™. Don't underestimate the power of single threaded processes communicating using channels and no shared memory. It is true that any language has zealots, look at Fortran, Java, Python, D, but a language should not be judged solely by its zealotry level. Well except for JavaScript (aka ECMAScript) of course. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Review: std.logger
On Fri, Jul 11, 2014 at 02:59:43PM +, Dicebot via Digitalmars-d wrote: On Friday, 11 July 2014 at 14:39:09 UTC, David Nadlinger wrote: On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote: Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Is this for std.* or std.experimental.*? David Deciding this is subject of this review/voting iteration too - it is mostly matter of API stability, how much of a trust reviewers are ready to put into existing API. Personally I believe that for something like logging library stabilization period of one release cycle in std.experimental is desirable because wider usage is very likely to result in breaking change suggestions. I vote for std.experimental. We keep talking about it, but never do anything in that direction. Let's start. If it works out poorly, we can always scrap the idea later. But we'll never know if we never do it. (In contrast, putting it directly in std risks the necessity of breaking changes later, which is a Bad Thing. Putting it in std.experimental now does no harm whatsoever -- the worst that can happen is that it's delayed entering std. The best is that breaking changes will not annoy users. So we have nothing to lose.) T -- Computer Science is no more about computers than astronomy is about telescopes. -- E.W. Dijkstra
Re: Using D
On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote: […] A little anecdote.. I once got a 20% speed increase in Python by moving a variable instantiation outside a tight loop. i = 0 # loop here i = something rather than # loop here i = something This is interesting. I can believe there is some performance benefit, but I am not sure I believe 20% improvement. If you can send me the code you were using, I would like to do some benchmarking on this. The compiler wasn't smart enough to do this. The Python compiler cannot and will never be able to do any such thing. Indeed if it did any such thing, it would be an error since it significantly changes the semantics of the program. Thus not doing this is not the fault of the compiler. The fact that you were able to do this and it appeared to give you the same results just means that the change in program semantics did not affect your computation. Which is good, but not something the compiler could determine. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: How can I dump an expression into log and execute it
On 7/11/14, 11:14 AM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Jul 11, 2014 at 08:57:26AM +0200, Jacob Carlborg via Digitalmars-d
wrote:
On 11/07/14 03:35, Delorien wrote:
Hi,
I have a C macro, which takes an argument, log it and call a
function. So, if I had a source code like this:
{
_logfx(x + 10);
}
the actual code would be
DebugLog(x + 10);
fx(x + 10);
Can I make similar tricks in the D language?
No, I don't think so. Not without passing it as a string to begin
with. Or AST macros, which we don't have.
[...]
Sure you can:
auto logAndCall(alias func, string expr)() {
DebugLog(expr);
return func(mixin(expr));
}
double myFunc(double arg) { ... }
auto result = logAndCall!(myFunc, q{1.0 + 2.0/4});
T
But the OP wanted to write:
_logfx(x + 10)
Not:
logAndCall!(fx, q{x + 10})
Notice that the first one is much more readable, and also much easier to
use.
D lacks proper macros. In Crystal you can do it like this:
---
def debug_log(msg)
puts Debug: #{msg}
end
def fx(exp)
puts Exp is: #{exp}
end
macro logfx(exp)
debug_log({{exp.stringify}})
fx({{exp}})
end
logfx(1 + 2)
---
Output:
Debug: 1 + 2
Exp is: 3
I think D would be much easier to use if it had proper macros. No need
to mess around with q{...}, with string concatenations for generating
code (let the compiler do that) and also to make the code more readable
and easier to write.
Please, D designers, try looking at other languages to get some
inspiration. I read in Reddit that Walter said I didn't have time to
look at how Rust does things. Really? As a language designer I would
try to learn about every other possible language to get the best of all
of them in my language. Looking at only C++ is not very good.
But that's just my opinion. I'd like D to be easier to use. If one day I
have to use it in my workplace, better if it's good! :-)
Re: Using D
On 07/11/2014 06:28 PM, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-11 at 17:43 +0200, simendsjo via Digitalmars-d wrote: […] A little anecdote.. I once got a 20% speed increase in Python by moving a variable instantiation outside a tight loop. i = 0 # loop here i = something rather than # loop here i = something This is interesting. I can believe there is some performance benefit, but I am not sure I believe 20% improvement. If you can send me the code you were using, I would like to do some benchmarking on this. Yes, I was very perplexed when I was profiling and finally found the main offender. Unfortunately I don't have the code - it was a project done for a past employer back in 2006/2007 (Python 2.4 IIRC). The compiler wasn't smart enough to do this. The Python compiler cannot and will never be able to do any such thing. Indeed if it did any such thing, it would be an error since it significantly changes the semantics of the program. Thus not doing this is not the fault of the compiler. The fact that you were able to do this and it appeared to give you the same results just means that the change in program semantics did not affect your computation. Which is good, but not something the compiler could determine. I think of this as a fault in the compiler. It was quite obvious (to me) that nothing else relied on the value so the value didn't have to be created on each iteration.
Re: Using D
On Friday, 11 July 2014 at 16:22:27 UTC, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-11 at 15:30 +, Chris via Digitalmars-d wrote: […] Let's not forget that Go has millions and billions of dollars behind it and that it is inevitable that the whole internet will be full of zealots and professional posters who promote Go as th best thing ever. People. Sheep. Meehhh. (I think I detect unintended irony in this post :-) I get the point :-) Go, via goroutines, promotes CSP as an approach to application parallelism and is therefore a Good Thing™. Don't underestimate the power of single threaded processes communicating using channels and no shared memory. It is true that any language has zealots, look at Fortran, Java, Python, D, but a language should not be judged solely by its zealotry level. Well except for JavaScript (aka ECMAScript) of course. […] I remember Java used to be th best thing ever. After years of using it, however, I found out how restricted the language was / is. Still, it's been a success, because people believed all the propaganda. What matters to me is not so much the odd fancy feature, it's how well the language performs in general purpose programming. Go was designed for servers and thus will always have one up on D or any other language at that matter. But could I use Go for what I have used D? Not so sure about that. Also, like Java Go is a closed thing. D isn't. Once I read about D that it shows what can be done once you take a language out of the hands of a committee. Go, like Java, will finally end up in a cul de sac and will have a hard time trying to get out of it. Not because the language is inherently bad, because it's in the hand of a committee. Ideology kills a language. But it doesn't matter, because people will use Go or whatever anyway, will _have_ to use it. What I'm taking issue with is that everybody focuses on the flaws of D (every language has flaws), which often gives the impression that it's an unfinished, stay-away business. It's not. D can be used, and I've used it, for production code. It's more mature than D or Rust and it is superior to other languages like Java (no OO-ideology for example). Mind you, D is a hindsight language, which makes it wiser. Does it have flaws? Yes. I come across them sometimes. Is there a language without flaws? If there is, tell me about it. Talking about hindsight, I've tried many different languages, I like D because of what it has to offer for general purpose programming, it compiles natively, interfaces with C at no cost at all, it has strong modelling power, features that users require are added. I may sound like a zealot (see irony), but I'm not. I'm very pragmatic, D is a good tool and, being community driven, there is a real chance of making it a fantastic tool. Individual features are not everything.
Re: Opportunities for D
On 7/11/2014 4:44 AM, Nick Treleaven wrote: On 10/07/2014 19:03, Walter Bright wrote: On 7/10/2014 9:00 AM, Nick Treleaven wrote: On 09/07/2014 20:55, Walter Bright wrote: Unique!(int*) u = new int; // must work That works, it's spelled: Unique!int u = new int; I'm unconfortable with that design, as T can't be a class ref or a dynamic array. It does currently work with class references, but not dynamic arrays: Unique!Object u = new Object; It could be adjusted so that all non-value types are treated likewise: Unique!(int[]) v = [1, 3, 2]; int* p = new int; Unique!(int*) u = p; // must fail The existing design actually allows that, but nulls p: [...] If there are aliases of p before u is constructed, then u is not the sole owner of the reference (mentioned in the docs): http://dlang.org/phobos-prerelease/std_typecons.html#.Unique Exactly. It is not checkable and not good enough. In that case we'd need to deprecate Unique.this(ref RefT p) then. Note that as of 2.066 the compiler tests for uniqueness of an expression by seeing if it can be implicitly cast to immutable. It may be possible to do that with Unique without needing compiler modifications. Current Unique has a non-ref constructor that only takes rvalues. Isn't that good enough to detect unique expressions? No, see the examples I gave earlier.
Re: How can I dump an expression into log and execute it
Full macro system is not needed to implement it, just AST reflection can do the trick (and has better fit with existing features).
Re: Using D
On Friday, 11 July 2014 at 16:54:40 UTC, Chris wrote: On Friday, 11 July 2014 at 16:22:27 UTC, Russel Winder via Digitalmars-d wrote: On Fri, 2014-07-11 at 15:30 +, Chris via Digitalmars-d wrote: […] Let's not forget that Go has millions and billions of dollars behind it and that it is inevitable that the whole internet will be full of zealots and professional posters who promote Go as th best thing ever. People. Sheep. Meehhh. (I think I detect unintended irony in this post :-) I get the point :-) Go, via goroutines, promotes CSP as an approach to application parallelism and is therefore a Good Thing™. Don't underestimate the power of single threaded processes communicating using channels and no shared memory. It is true that any language has zealots, look at Fortran, Java, Python, D, but a language should not be judged solely by its zealotry level. Well except for JavaScript (aka ECMAScript) of course. […] I remember Java used to be th best thing ever. After years of using it, however, I found out how restricted the language was / is. Still, it's been a success, because people believed all the propaganda. What matters to me is not so much the odd fancy feature, it's how well the language performs in general purpose programming. Go was designed for servers and thus will always have one up on D or any other language at that matter. But could I use Go for what I have used D? Not so sure about that. Also, like Java Go is a closed thing. D isn't. Once I read about D that it shows what can be done once you take a language out of the hands of a committee. Go, like Java, will finally end up in a cul de sac and will have a hard time trying to get out of it. Not because the language is inherently bad, because it's in the hand of a committee. Ideology kills a language. But it doesn't matter, because people will use Go or whatever anyway, will _have_ to use it. What I'm taking issue with is that everybody focuses on the flaws of D (every language has flaws), which often gives the impression that it's an unfinished, stay-away business. It's not. D can be used, and I've used it, for production code. It's more mature than D or Rust and it is superior to other languages like Java (no OO-ideology for example). Mind you, D is a hindsight language, which makes it wiser. Does it have flaws? Yes. I come across them sometimes. Is there a language without flaws? If there is, tell me about it. Talking about hindsight, I've tried many different languages, I like D because of what it has to offer for general purpose programming, it compiles natively, interfaces with C at no cost at all, it has strong modelling power, features that users require are added. I may sound like a zealot (see irony), but I'm not. I'm very pragmatic, D is a good tool and, being community driven, there is a real chance of making it a fantastic tool. Individual features are not everything. It should read It's more mature than _Go_ or Rust, of course.
Re: Review: std.logger
Haven't had a chance to look closely at the new version yet, but looks pretty good. Couple initial comments: * Definite vote for std.experimental. Should get a bunch of folks to bang on it before the API has to be locked down. Having it as a dub package first has made it much easier to pick up and use, feel like this is a good path for all std packages to take - get it out there and iterate with user input before pulling in to std. * The 'Tracer' doesn't feel like it belongs here, and if I understand things correctly won't actually work properly anyway, so should probably be removed. * What others have said about string formatting. I poked around with this a bit before, but wasn't able to get a clean solution, should probably try again before complaining... On Fri, Jul 11, 2014 at 9:27 AM, H. S. Teoh via Digitalmars-d digitalmars-d@puremagic.com wrote: On Fri, Jul 11, 2014 at 02:59:43PM +, Dicebot via Digitalmars-d wrote: On Friday, 11 July 2014 at 14:39:09 UTC, David Nadlinger wrote: On Friday, 11 July 2014 at 14:36:34 UTC, Dicebot wrote: Round of a formal review before proceeding to voting. Subject for Phobos inclusion : http://wiki.dlang.org/Review/std.logger authored by Robert Schadek. Is this for std.* or std.experimental.*? David Deciding this is subject of this review/voting iteration too - it is mostly matter of API stability, how much of a trust reviewers are ready to put into existing API. Personally I believe that for something like logging library stabilization period of one release cycle in std.experimental is desirable because wider usage is very likely to result in breaking change suggestions. I vote for std.experimental. We keep talking about it, but never do anything in that direction. Let's start. If it works out poorly, we can always scrap the idea later. But we'll never know if we never do it. (In contrast, putting it directly in std risks the necessity of breaking changes later, which is a Bad Thing. Putting it in std.experimental now does no harm whatsoever -- the worst that can happen is that it's delayed entering std. The best is that breaking changes will not annoy users. So we have nothing to lose.) T -- Computer Science is no more about computers than astronomy is about telescopes. -- E.W. Dijkstra
Re: Thread Attributes
I'm not sure how AST macros would assist in thread safety the way that this feature would. Maybe you could elaborate? To explain a little more, when you put a @thread:name or @sync(object) attribute on something, the compiler will guarantee that no safe D code will ever use that code or data unless it is either on the given thread or can guarantee at compile time that it has synchronized on the given object. You mentioned making the variable thread local. So if I'm understanding, you're saying just make it a regular global variable. However, the point is that if you tell the compiler that it can only be accessed by a single thread then it doesn't need to be thread local. Real global variables are preferred over thread local for performance/memory reasons. Their address is known at compile time and you don't need to allocate a new instance for every thread. The only reason for thread local variables is to alleviate problems with multithreaded applications, but using an attribute like this would allow someone to have the benefit of a real global variable without exposing it to other threads fixing the synchronization issue. D has its own way of handling multithreaded applications but I still have applications that use the old idioms to get lightning performance and minimize memory usage. A feature like this could solve alot of problems the old idioms use. There are many times that I write a function and I have to make a mental note (or a comment) that this function should only ever be called by a certain thread. Or that this function should only be called by code that has locked on a certain object. It would be wonderful if the compiler could guarantee that for me.
Re: Using D
On Fri, Jul 11, 2014 at 03:30:15PM +, Chris via Digitalmars-d wrote: I have followed the recent discussions about D and I can see the usual pattern, to wit GC, Go (or whatever) is so much better, everyone blaming each other for not contributing, not being allowed to contribute blah. Well, this forum *is* for discussing ways of improving D, so it shouldn't be surprising that we constantly find things to nitpick about. :-) It doesn't mean at all that D is lousy or the community is bad, 'cos if it were so, we wouldn't even be here to begin with. We're here 'cos we care, and we complain 'cos we care enough to want things to improve. First of all, I am in no position to criticize anyone who is contributing to the language. I don't contribute, because I don't have the time to do so. Indeed I have huge, massive respect for everyone who contributes to D. The only thing I do is to actually use the language and tell everyone about it. I have developed a screen reader plug in in D (using C libraries) that was ridiculously easy to integrate on Windows as a DLL. I used vibe.d to create a lightning fast online version of the screen reader. Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. I compiled both applications with dmd (testing phase) not with ldc or gdc and they are very fast. I agree. I'm still convinced that GC phobia is blown out of proportion -- I used to be in that camp, so I totally sympathize with where they're coming from -- but as you say, only a small percentage of applications actually need to squeeze every last cycle out of the CPU such that the GC actually starts to make a significant difference in performance. Most applications work just fine with the GC, and in fact, I'd argue that they work *better* with the GC, because manual memory management is *hard* (just look at how many security exploits are caused by memory management mistakes) and tedious (look at how often the same memory bugs are repeated over and over). GC-supported code is cleaner to read, easier to write, and in many cases, the simpler design of the code reduces the likelihood of bugs and eliminates a whole class of bugs. Sure you pay for that by short pauses every now and then, but seriously, 90% of applications don't even *care* about such pauses. For applications with slightly higher performance demands, gdc -O3 (or whatever the LDC equivalent is) generally improves performance by about 20% or so above dmd. In my own compute-intensive projects, I have consistently noted about a 20-30% performance improvement when compiling with gdc, compared to dmd. That's pretty significant, because GC pauses are generally nowhere near that percentage, so just by recompiling with gdc already eliminates the perceived GC performance issue for 95% of applications. Besides, avoiding frequent small allocations also reduces most of the workload of the GC, so you can still get pretty far without totally turning it off. So it's really only the remaining 5% of applications that really, absolutely, *have* to go GC-less (or control it very tightly). They do happen to have supporters of the rather vocal kind, so we tend to hear from them a lot more, but that by no means is representative of the grand scheme of things as far as the GC is concerned! [...] Let's first make a list of things that have been achieved with D and that are on a par with or even bettar than in other languages (C, C++, C#, Go, Rust ...). I don't know C#, Go, or Rust, so I can't really say much on that front, but at least as far as C/C++ are concerned, D totally beats them flat in the following points IMO: - Metaprogramming. Templates in C++ scarred many for life. Templates in D are actually a pleasure to use. - CTFE. Coupled with metaprogramming, this is a total killer combination that I've yet to see another language beat. - Slices. Finally, a systems-level language whose string support isn't crippled (C), maimed (C++), or otherwise handicapped (Java). And this extends to arrays in general. While there *are* other language with nice string/array manipulation support, D is the only one I know of that does it without sacrificing performance. - Ranges. It can totally revolutionize the way you approach programming. And, with metaprogramming/CTFE, they can still perform as fast as non-range-based code. Total win! - Extended meaning of purity: IMO it's a total stroke of genius to define weak purity that allows you to implement pure functions (in the Haskell sense) using mutating primitives (loops and assignments, etc.). While the current compilers don't really do that much with this presently, there is a lot of potential here that may turn this into a killer feature. - Built-in unittests. Sounds trivial, but I can testify to its value in dramatically improving the quality of my code. I've worked with large C/C++
Re: Software Assurance Reference Dataset
On Monday, 30 June 2014 at 08:00:37 UTC, Ola Fosheim Grøstad wrote: On Thursday, 26 June 2014 at 09:35:20 UTC, Walter Bright wrote: Stack overflows are not safety problems when a guard page is used past the end of the stack. Then, overflow checking is done in hardware. Guard pages aren't currently used for fibers, so overflows are a real danger there. But a page is only 2K? So what happens if you skip more than 2K and never touch the guard page? Does D prove that the stack pointer is never moved more than 2K-1 without a read or write in that range? The compiler can ensure that you hit at least every 4k or so. It doesn't look like a very hard constraint to have a volatile load per untouched 4k of stack (which should be very rare).
array initializers
If you have immutable int[] arr = [0,1,0,3]; Couldn't the type of the literal be inferred as immutable? Then you could put the data into read-only memory, and maybe even elide the copy to the heap? The immutable arr type is even passed to ArrayLiteralExp::inferType but doesn't influence the literal type. But not sure what this is supposed to do.
Re: Thread-local GC?
On Friday, 11 July 2014 at 06:44:11 UTC, Paulo Pinto wrote: On Thursday, 10 July 2014 at 03:21:03 UTC, Jonathan M Davis via Digitalmars-d wrote: ... So, if we can figure out how to do it, great, but the fact that D's a systems language has a tendancy to make some stuff like that not work as easily as would be nice. - Jonathan M Davis Sure, but maybe there is too much flexibility that isn't really needed, rather a more GC friendly one, which still allows for typical systems programming use cases. A good approach would be to do a bit of archeology and try to research how GC enabled systems programming languages like Cedar, Modula-3, Oberon derivatives and Sing# had their GCs implemented across the available compilers. And respective OS. To certain extent, they were good enough to produce workable desktop OS. -- Paulo The action that cause trouble for the GC are already defined as undefined by spec and @system. For once, we did things right with the spec.
Re: array initializers
Trass3r: If you have immutable int[] arr = [0,1,0,3]; Couldn't the type of the literal be inferred as immutable? Then you could put the data into read-only memory, Did you mean this? immutable int[4] arr = [0, 1, 0, 3]; Bye, bearophile
Re: Using D
On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via Digitalmars-d wrote: On Fri, Jul 11, 2014 at 03:30:15PM +, Chris via Digitalmars-d wrote: I have followed the recent discussions about D and I can see the usual pattern, to wit GC, Go (or whatever) is so much better, everyone blaming each other for not contributing, not being allowed to contribute blah. Well, this forum *is* for discussing ways of improving D, so it shouldn't be surprising that we constantly find things to nitpick about. :-) It doesn't mean at all that D is lousy or the community is bad, 'cos if it were so, we wouldn't even be here to begin with. We're here 'cos we care, and we complain 'cos we care enough to want things to improve. First of all, I am in no position to criticize anyone who is contributing to the language. I don't contribute, because I don't have the time to do so. Indeed I have huge, massive respect for everyone who contributes to D. The only thing I do is to actually use the language and tell everyone about it. I have developed a screen reader plug in in D (using C libraries) that was ridiculously easy to integrate on Windows as a DLL. I used vibe.d to create a lightning fast online version of the screen reader. Believe me, D's supposed sluggishness as regards GC is not so important for most applications. I dare say 90% of all applications are fine with the current GC. I compiled both applications with dmd (testing phase) not with ldc or gdc and they are very fast. I agree. I'm still convinced that GC phobia is blown out of proportion -- I used to be in that camp, so I totally sympathize with where they're coming from -- but as you say, only a small percentage of applications actually need to squeeze every last cycle out of the CPU such that the GC actually starts to make a significant difference in performance. Most applications work just fine with the GC, and in fact, I'd argue that they work *better* with the GC, because manual memory management is *hard* (just look at how many security exploits are caused by memory management mistakes) and tedious (look at how often the same memory bugs are repeated over and over). GC-supported code is cleaner to read, easier to write, and in many cases, the simpler design of the code reduces the likelihood of bugs and eliminates a whole class of bugs. Sure you pay for that by short pauses every now and then, but seriously, 90% of applications don't even *care* about such pauses. For applications with slightly higher performance demands, gdc -O3 (or whatever the LDC equivalent is) generally improves performance by about 20% or so above dmd. In my own compute-intensive projects, I have consistently noted about a 20-30% performance improvement when compiling with gdc, compared to dmd. That's pretty significant, because GC pauses are generally nowhere near that percentage, so just by recompiling with gdc already eliminates the perceived GC performance issue for 95% of applications. Besides, avoiding frequent small allocations also reduces most of the workload of the GC, so you can still get pretty far without totally turning it off. So it's really only the remaining 5% of applications that really, absolutely, *have* to go GC-less (or control it very tightly). They do happen to have supporters of the rather vocal kind, so we tend to hear from them a lot more, but that by no means is representative of the grand scheme of things as far as the GC is concerned! [...] Let's first make a list of things that have been achieved with D and that are on a par with or even bettar than in other languages (C, C++, C#, Go, Rust ...). I don't know C#, Go, or Rust, so I can't really say much on that front, but at least as far as C/C++ are concerned, D totally beats them flat in the following points IMO: - Metaprogramming. Templates in C++ scarred many for life. Templates in D are actually a pleasure to use. - CTFE. Coupled with metaprogramming, this is a total killer combination that I've yet to see another language beat. - Slices. Finally, a systems-level language whose string support isn't crippled (C), maimed (C++), or otherwise handicapped (Java). And this extends to arrays in general. While there *are* other language with nice string/array manipulation support, D is the only one I know of that does it without sacrificing performance. - Ranges. It can totally revolutionize the way you approach programming. And, with metaprogramming/CTFE, they can still perform as fast as non-range-based code. Total win! - Extended meaning of purity: IMO it's a total stroke of genius to define weak purity that allows you to implement pure functions (in the Haskell sense) using mutating primitives (loops and assignments, etc.). While the current compilers don't really do that much with this presently, there is a lot of potential here that may turn this into a killer feature. - Built-in
Re: Using D
On Fri, Jul 11, 2014 at 04:54:39PM +, Chris via Digitalmars-d wrote:
[...]
I remember Java used to be th best thing ever. After years of
using it, however, I found out how restricted the language was / is.
Still, it's been a success, because people believed all the
propaganda. What matters to me is not so much the odd fancy feature,
it's how well the language performs in general purpose programming.
[...]
I remember how I was skeptical of Java from day 1. Call me a cynic, but
everytime I hear something being overhyped, I immediately assign
whatever it is being hyped about as a second class product, and regard
it with suspicion. Same goes with cloud computing, which, as Nick likes
to say, is just marketing propaganda for the internet.
When I finally got past the hype and tried out the language for myself,
I found the same thing you did: it's totally straitjacketed, and shoves
the OO idealogy down your throat even when it obviously doesn't fit. The
infamous long-winded class MyLousyApp { public static void main(blah
blah blah) ... } is a prime example of shoehorning something obviously
non-OO into an OO paradigm, just because we want to. Not to mention
Java's verbosity, which is only tolerable with IDE support -- total
fail, in my book. I mean, hello, we're talking about a *language*
intended for *humans* to communicate with the computer? If we need
*another* program to help us elucidate this communication, something's
gone very, very wrong with the language. A language that needs a machine
to help you write, is by definition a language for communication between
*machines*, not between humans and machines.
Then there's the lack of generics until the n'th revision, and when it
finally came, it was lackluster (google for issues caused by type
erasure in Java sometime). D totally beats Java in this area IMO.
That's not to say that Java, the language, (as opposed to the class
library or the marketing hype) isn't a pretty good language. In fact,
it's quite a beautiful language -- in the idealistic, ivory tower,
detached-from-real-life sense of being a perfect specimen suitable for a
museum piece. Its disconnect from the messy real world, unfortunately,
makes it rather painful to use in real-life. Well, except with the help
of automated tools like IDEs and what-not, which makes one wonder, if we
need a machine to help us communicate with a machine, why not just write
assembly language instead? But I digress. :-P
[...]
Mind you, D is a hindsight language, which makes it wiser. Does it
have flaws? Yes. I come across them sometimes. Is there a language
without flaws? If there is, tell me about it.
When I was still using C/C++ for my personal projects, the problems I
keep running into drove me to dream about what I'd like in an ideal
language. I tried writing my own, but didn't get very far -- not
everyone is a Walter Bright, after all. ;-) So I searched online instead
-- and found that D is the one language that's closest to my idea of
what an ideal language should be. There are some things about it that
aren't quite up to my ideals, but there are also many other areas where
it *exceeded* my ideals. So in spite of whatever warts or wrinkles D may
have, it's still the best language out there IMO.
I'm very pragmatic, D is a good tool and, being community driven,
there is a real chance of making it a fantastic tool. Individual
features are not everything.
Agreed, it's the synergy of multiple complementary features coming
together, that really makes the language shine. Templates + CTFE +
static if, is one example I can think of. Together, they make a total
killer combination in the world of metaprogramming IMO. I'm sure you can
think of several other synergistic combinations in D.
T
--
Claiming that your operating system is the best in the world because
more people use it is like saying McDonalds makes the best food in the
world. -- Carl B. Constantine
Older versions of dmd
So why isn't there a link to previous versions of dmd? I have a regression I need to test out but can't find 2.064!
Re: Using D
On Fri, Jul 11, 2014 at 05:39:30PM +, Chris via Digitalmars-d wrote:
[...]
Thanks. That's a nice list. This is what I was talking about, the
experience with D, what you can achieve with it and how it compares
with other languages. We need more of this. I have the feeling
sometimes that to an outsider D might look like an eternally
unfinished business. A nice playground for programmers, but not for
production, which is absolutely not true. The GC issue is sometimes
presented as the language will stand or fall with this. As you noted
and which is also my experience, the GC issue ain't that big. 90-95%
of all applications can live with it.
Oh, and how did I forget UFCS? I think some of us were a bit hesitant
about this at first, but coupled with ranges, it has opened up a whole
new way of writing (and thinking about) your program:
// UFCS FTW! ;-)
auto formatYear(int year, int monthsPerRow)
{
return datesInYear(year)
.byMonth()
.chunks(monthsPerRow)
.map!(row = row.formatMonths()
.array()
.pasteBlocks(colSpacing)
.join(\n))
.join(\n\n);
}
(Shamelessly quoted from my article:
http://wiki.dlang.org/Component_programming_with_ranges
;-))
T
--
Don't modify spaghetti code unless you can eat the consequences.
Re: array initializers
On Friday, 11 July 2014 at 17:25:47 UTC, Trass3r wrote: Couldn't the type of the literal be inferred as immutable? Then you could put the data into read-only memory, and maybe even elide the copy to the heap? By the way, LDC already does this today (even without optimizations turned on). David
Re: Using D
On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote: Let's not forget that zeolots and professional posters will always point out the flaws of D, and blow them out of proportion. D doesn't have xyz, so it's shit! Divide et impera (divide and rule). Lol, this one made me laugh. It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example. D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL... Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed.
Re: Older versions of dmd
On Fri, 11 Jul 2014 17:44:28 +, Frustrated wrote: So why isn't there a link to previous versions of dmd? I have a regression I need to test out but can't find 2.064! I'd recommend taking a look at digger (https://github.com/CyberShadow/ Digger). Not only can it automatically build old versions of D, it also has a bisect feature for bug hunting.
Re: Using D
On Friday, 11 July 2014 at 17:54:38 UTC, Israel Rodriguez wrote: Lol, this one made me laugh. It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example. D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL... Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed. Right not i use C# are my primary language where i can do everything and anything i need but thats only because the .NET framework provides nearly everything i need without the help of C/C++. The only thing i need is win32 APIs.
Re: Review: std.logger
Some logging backends (e.g. systemd journal) support structured logging. Should support for this be included (as a subclass, presumably)?
Re: Using D
On Friday, 11 July 2014 at 17:41:41 UTC, H. S. Teoh via Digitalmars-d wrote: [...] Mind you, D is a hindsight language, which makes it wiser. Does it have flaws? Yes. I come across them sometimes. Is there a language without flaws? If there is, tell me about it. When I was still using C/C++ for my personal projects, the problems I keep running into drove me to dream about what I'd like in an ideal language. I tried writing my own, but didn't get very far -- not everyone is a Walter Bright, after all. ;-) So I searched online instead -- and found that D is the one language that's closest to my idea of what an ideal language should be. There are some things about it that aren't quite up to my ideals, but there are also many other areas where it *exceeded* my ideals. So in spite of whatever warts or wrinkles D may have, it's still the best language out there IMO. I went down a similar path. Always frustrated with existing languages. Then I accidentally discovered D and I knew that was it! It killed so many birds with one stone. Unicode, C-interfaceable (if that's a word), native compilation to begin with, then I discovered all the nice features and I've become a better programmer simply by trying to understand D. It gives me more freedom to put human thought into a computer, to model our world in terms a computer can understand, and not the other way around. I still don't get why people who put up with other languages like Java and C++, and patiently wait years for simple improvements, say, when they see D, it doesn't have xyz*, it's shit! I just don't get it. *(usually GC or thread related)
Re: Older versions of dmd
On Friday, 11 July 2014 at 17:44:29 UTC, Frustrated wrote: So why isn't there a link to previous versions of dmd? I have a regression I need to test out but can't find 2.064! They're on the changelog page. Click the heading for the version you want.
Re: Using D
On Friday, 11 July 2014 at 17:54:38 UTC, Israel Rodriguez wrote: On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote: Let's not forget that zeolots and professional posters will always point out the flaws of D, and blow them out of proportion. D doesn't have xyz, so it's shit! Divide et impera (divide and rule). Lol, this one made me laugh. It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example. D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL... Why reinvent the wheel, when D can interface to the wheel. A lot of things are programmed in C/C++. Other languages use modules (Python, Java) to access existing C libraries. D can do it straight away. I cannot tell you how much it has helped me. I depend on C libraries not because I use D, but because the libraries are useful and well established / tested / sound. Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed.
