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 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 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 > 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" : > 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 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 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 worke
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 uni
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.
Re: Need Feedback for a new book - "D Cookbook"
Hi Paushali I'm interested in reviewing the book, you can contact me at alynch4...@gmail.com. I'd put the review on Amazon.
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.
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
Mistype at std.logger.core.Tracer: "Tracer generates trace calls
to the passed logger wenn the Tracer struc" wenn should be "when".
The API is well done. The only thing I want to have in the
package is a delayed logger: delayed logger wraps another logger,
accumulates messages and writes to inner logger by explicit call.
That is useful while testing. Major part of diagnostic
information is needed only when test is failed:
```
unittest
{
auto logger = new DelayedLogger(myCustomLogger);
scope(failure) logger.flush;
// some activity that can throw
}
```
Re: Older versions of dmd
On Friday, 11 July 2014 at 18:14:24 UTC, Nick Sabalausky wrote: 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. But it doesn't lead to a download of the compiler(binaries for windows).
Re: Using D
I forgot to mention that the fact that D implements the Thompson algorithm for regular expressions made me smile. All other languages insist on inefficient algorithms.
Re: Using D
On Friday, 11 July 2014 at 18:13:52 UTC, Chris wrote: 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. This is true, but theoretically i feel this is wrong because its like putting training wheels on your bike. Know what i mean? Anyways thats just how "Feel" but maybe youre right, in that, maybe that isnt the right way to go...
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 uni
Re: array initializers
By the way, LDC already does this today (even without optimizations turned on). My ldc doesn't. I had to cast(immutable) to actually get it to put the data as a constant. And even then it's still copied to the GC heap.
Re: Older versions of dmd
On Fri, Jul 11, 2014 at 05:51:05PM +, Justin Whear via Digitalmars-d wrote: > 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. Whoa. This must be another one of those well-guarded secrets about D. Why isn't it on a prominent page on dlang.org??! I don't know how many times I got frustrated trying to narrow down a dmd bug, because git bisect in dmd alone can only go back so far, before phobos/druntime stop compiling, which throws off the whole process. T -- This sentence is false.
Re: Thread Attributes
On 07/10/2014 08:12 PM, Jonathan Marler wrote: So what do people think? How do you make sure there is at most one thread of each kind?
Re: Older versions of dmd
On 07/11/2014 08:45 PM, H. S. Teoh via Digitalmars-d wrote: > On Fri, Jul 11, 2014 at 05:51:05PM +, Justin Whear via Digitalmars-d > wrote: >> 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. > > Whoa. This must be another one of those well-guarded secrets about D. > Why isn't it on a prominent page on dlang.org??! I don't know how many > times I got frustrated trying to narrow down a dmd bug, because git > bisect in dmd alone can only go back so far, before phobos/druntime stop > compiling, which throws off the whole process. > > > T > Here's the well-kept secret: http://dconf.org/2014/talks/panteleev.html The best thing is that there's no video links, so it's really a secret! A bit googe-fu leads you here: https://www.youtube.com/watch?v=5iXRFlKvEY0
Re: Using D
On Friday, 11 July 2014 at 15:42:04 UTC, 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. (...) 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. Ah, but that's because you're comparing it to C#, not languages that don't use GC. The big problem for D is that the market for programming languages has bifurcated since D was created, with the performant native-compiled languages like C/C++/Obj-C on one side and the much larger market for easier to use but much less performant, what used to be called "scripting," languages like ruby/python/java on the other. Trying to be a better C++, by borrowing some ease of use features like GC or reflection from the scripting languages, leaves D stuck in the middle right now, neither here nor there. Who still uses native-compiled languages? Performance-sensitive games, server applications that squeeze out performance, like number-crunching or search engines, and desktop apps that need the performance, that's about it. Everything else has either gone to the web with a scripting language backend or mobile. I hear that even enterprise LOB desktop apps are mostly written in Java/C# these days, because they just don't need the speed of a native language and can crank the code out quicker that way. However, mobile could be D's saving grace, as native development is back on iOS and even Android is moving to Ahead-Of-Time compiling with the next release. Too bad D doesn't work on mobile, even though some of us are working on getting it there. D should focus on the native end of the market, by trying to be the easier way to get most of the performance. You're not going to get the scripting guys now, because native is just too hard for them. If D can assert itself in that smaller niche of native languages, it might have enough juice to go after the other end later. I don't think either happens without a commercial implementation, community development doesn't cut it. Linux didn't take off till long after it got commercial vendors on board, the same will be true here. I don't mean to be pessimistic about D's goal of being usable by all, from scripting to systems, as D may actually be good enough to get there one day. I just think you're not going to get there without focusing on taking over a niche at a time, particularly the niche best suited to D right now, mobile.
Re: Review: std.logger
Some static analysis warnings: std/logger/core.d(808:18)[warn]: Parameter cond is never used std/logger/core.d(1069:10)[warn]: Variable ll is never used std/logger/core.d(1106:14)[warn]: Variable tracer is never used std/logger/core.d(1161:9)[warn]: Variable nLineNumber is never used std/logger/core.d(1263:12)[warn]: Variable name is never used std/logger/core.d(1300:12)[warn]: Variable name is never used std/logger/core.d(1323:10)[warn]: Variable readLine is never used Several of the functions in the API are missing "Params:" sections.
Re: array initializers
On Friday, 11 July 2014 at 18:36:14 UTC, Trass3r wrote:
By the way, LDC already does this today (even without
optimizations turned on).
My ldc doesn't.
What LDC version are you on?
With Git master, this
---
auto foo() {
immutable int[] arr = [0, 1, 0, 3];
return arr;
}
---
produces (with optimizations on, but just for brevity)
---
define { i64, i32* } @_D4test3fooFZyAi() #0 {
ret { i64, i32* } { i64 4, i32* getelementptr inbounds ([4 x
i32]* @.immutablearray, i32 0, i32 0) }
}
---
Cheers,
David
Re: Using D
On 7/11/2014 1:40 PM, H. S. Teoh via Digitalmars-d wrote:
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.
I tend to be like that even for non-computer stuff too, viewing
whatever's popular with skepticism. Once in a while it'll backfire and
keep me away from something I later realize is actually pretty decent,
but I've found *usually* it serves me well. But then, my tastes tend to
be uncommon *anyway*, so maybe that's why it works for me ;)
Same goes with cloud computing, which, as Nick likes
to say, is just marketing propaganda for "the internet".
Yes!!
"Cloud" drives me crazy more than any other word! It's the hipster word
for "Internet", and it's EVERYWHERE.
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.
While I agree with all of that, there are two things I've always had to
give Java credit for: It's classes and module system are what originally
taught me that C/C++ aren't ideal and...umm...have some notable downsides...
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.
Yea, that's one of the things that drew me to D. It came around saying
(quite literally) "pragmatic language design" at exactly the time I was
noticing how much of a pain ideology-driven and minimalist languages can be.
Re: Using D
On Fri, Jul 11, 2014 at 03:08:39PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
> On 7/11/2014 1:40 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
> >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.
>
> Yea, that's one of the things that drew me to D. It came around saying
> (quite literally) "pragmatic language design" at exactly the time I
> was noticing how much of a pain ideology-driven and minimalist
> languages can be.
If you really wanna go minimalist, there's BF... :-P
On the other extreme of pragmatism, Larry Wall claims that the reason
Perl is useful is because it's a mess, which maps well to the problem
space, which is also a mess, which we call reality. :-P I *will* say
that at one point I was quite enamored of Perl, but nowadays I think it
goes a little *too* far in the pragmatism, and as a result is rather
messy to work with.
One of the big advantages of D was that it's so easy to use when what
you need is something simple, so I've been writing quite a lot of little
script-like helper programs nowadays in D where in the past I would have
used Perl. Unlike Perl, though, D also scales up nicely when what was
initially a simple problem grows into a more complex problem. In Perl,
there's this threshold of complexity below which it's pretty comfortable
to use, but once you pass that point, the seams start to burst and the
potholes start to appear, a common sign of which is the appearance of
deeply-nested data structures that leads to riddle-like code such as:
${a{b}{c}}->{$d->{e}}->{f} = ${g[h]{i}->{j}}->{k}[l]->{m};
along with the programming-by-convention that comes along with it.
Abstractions in Perl tend to be quite leaky, which is OK with write-once
throwaway-after scripts, but as the complexity of the program increases,
it becomes a source of frustration and hiding places for bugs.
In D, you simply leave the original script-like core as-is, then bring
in the proverbial big guns on top of it to deal with the growing
complexity, and the miracle is that the result is all nicely integrated
and water-tight. It's quite unlike any other programming language that
I've used before, in this respect.
T
--
Talk is cheap. Whining is actually free. -- Lars Wirzenius
Re: Opportunities for D
On Thursday, 10 July 2014 at 22:53:18 UTC, Walter Bright wrote: On 7/10/2014 1:57 PM, "Marc Schütz" " wrote: That leaves relatively few cases Right, and do those cases actually matter? Besides what I mentioned there is also slicing and ranges (not only of arrays). These are more likely to be implemented as templates, though. I'm a big believe in attribute inference, because explicit attributes are generally a failure with users. The average end user probably doesn't need to use explicit annotations a lot, but they need to be there for library authors. I don't think it's possible to avoid annotations completely but still get the same functionality just by inferring them internally, if that is what you're aiming at...
Re: Older versions of dmd
On 7/11/14, 11:22 AM, Frustrated via Digitalmars-d wrote: On Friday, 11 July 2014 at 18:14:24 UTC, Nick Sabalausky wrote: 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. But it doesn't lead to a download of the compiler(binaries for windows). Either http://ftp.digitalmars.com or http://downloads.dlang.org both contain all the releases. Some of the very earliest no longer exist, but every single 1.x and 2.x are there.
Re: Using D
On 7/11/2014 10:54 AM, 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. Speaking of inventing reasons to not use D, years ago the reason was "D has only one implementation, so it's too risky to use." Lately, the reason is "D has 3 implementations, so it's too risky to use, there should be only one". We have to be careful to filter out real reasons from people just pulling our chains.
Re: Using D
Thanks for posting this. You're right that it is easy to lose perspective. I agree that the GC phobia is way, WAY, overblown for practical programming. For example, Warp uses the GC, but only for things like initialization, where perf doesn't matter, and for permanent data structures. It doesn't use it on the fast path, and so Warp keeps the convenience and safety of GC without the perf hit. This was not hard to do. I understand that Sociomantic does something similar to good effect. GC phobia is a convenient excuse for people to not use D, people who may have different actual reasons that they don't express for various reasons or may not even realize. For example, in the 80's, a friend of mine talked with a C++ programmer who fervently and passionately argued that compiler speed was the most important attribute. My friend says no, compile speed is at the bottom of the list of what the programmer care about. Shocked, the programmer asked WTF was he talking about? My friend said "You use Microsoft C++, which is the slowest compiler by a factor of 4. What you actually care about is branding, not speed." And the programmer eventually admitted he was right. But we still need an answer to the people who believe that GC is the touch of death, that the GC is a troll hiding under a bridge that will pop out at any moment and destroy their program.
Re: Using D
This is an awesome list, it's almost exactly what I would have written!
Re: Cool Stuff for D that we keep Secret
On Thu, Jul 10, 2014 at 05:52:57PM -0400, Nick Sabalausky via Digitalmars-d wrote: > On 7/10/2014 4:01 AM, Jacob Carlborg wrote: [...] > >Is it only me that feels like ddoc doesn't scale for designing web > >sites. > > > > Not just you, I've been kind of avoiding it. I like that it *exists* > as a built-in, and it's certainly better than those XML "comments" > that C# uses, but it still has poor readability (and writeability) > *within* the source, plus it's really just too "dumb": Purely > zero-semantics macro-like text substitution just isn't good enough. > Realistically, you just end up needing to post-process its results if > you don't want to feel like you've got your hands tied behind your > back. In which case, why even bother using it at all? > > I've always wanted something in D that's more like Natural Docs: > http://www.naturaldocs.org/documenting.html > > Macroed comments are just an overengineered mess compared to that. Hmm. In terms of input syntax, I quite like Natural Docs. But it only supports HTML output currently. :-( While ddoc as a macro system is quite nice, for documentation generation I personally prefer something that understands the semantics of the documentation better. The current way of generating indices and cheat sheets at the top of Phobos module docs, for example, is extremely ugly because it's manual. Ideally, a doc generator system should automate these sorts of things by allowing, say, a generic $(tableofcontents) directive that does the Right Thing(tm). It also should support moving things around (e.g., sort function docs by name, split them up into separate pages, etc.), without requiring external postprocessing tools to achieve. At the end of the day, the ideal seems to be something akin to Knuth's literate programming: you work on a single source, and the codegen extracts the code parts of it and feeds it to the compiler (possibly reordering pieces of the code), and the docgen extracts the doc parts of it (possibly moving them around) and assembles them into a nicely-formatted document. Retaining semantic information on the docs is important, since the docgen may need to consult this info to make decisions about where to put things -- currently ddoc is incapable of this and thus can only generate docs in source order. Retaining semantic structure also allows clean multiplexing into different output formats. While ddoc does allow this to a limited extent, it requires a lot of manual intervention (introduce intermediate layers of macros to serve as abstractions over different output formats) and unnatural ways of writing the input. As a simple example, in LaTeX "Mr. Doe" should be written as "Mr.\ Doe" to get the correct spacing, but in HTML it's "Mr. Doe". You'd have to write "Mr.$(NBSP)Doe" in order to target both HTML and LaTeX, which makes the source quite unreadable. T -- It always amuses me that Windows has a Safe Mode during bootup. Does that mean that Windows is normally unsafe?
Re: Using D
On Friday, 11 July 2014 at 19:00:30 UTC, Joakim wrote: On Friday, 11 July 2014 at 15:42:04 UTC, 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. (...) 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. Ah, but that's because you're comparing it to C#, not languages that don't use GC. The big problem for D is that the market for programming languages has bifurcated since D was created, with the performant native-compiled languages like C/C++/Obj-C on one side and the much larger market for easier to use but much less performant, what used to be called "scripting," languages like ruby/python/java on the other. Trying to be a better C++, by borrowing some ease of use features like GC or reflection from the scripting languages, leaves D stuck in the middle right now, neither here nor there. Who still uses native-compiled languages? Performance-sensitive games, server applications that squeeze out performance, like number-crunching or search engines, and desktop apps that need the performance, that's about it. Everything else has either gone to the web with a scripting language backend or mobile. I hear that even enterprise LOB desktop apps are mostly written in Java/C# these days, because they just don't need the speed of a native language and can crank the code out quicker that way. However, mobile could be D's saving grace, as native development is back on iOS and even Android is moving to Ahead-Of-Time compiling with the next release. Too bad D doesn't work on mobile, even though some of us are working on getting it there. I agree. This is a big pain for me too. D should focus on the native end of the market, by trying to be the easier way to get most of the performance. You're not going to get the scripting guys now, because native is just too hard for them. If D can assert itself in that smaller niche of native languages, it might have enough juice to go after the other end later. I don't think either happens without a commercial implementation, community development doesn't cut it. Linux didn't take off till long after it got commercial vendors on board, the same will be true here. I don't mean to be pessimistic about D's goal of being usable by all, from scripting to systems, as D may actually be good enough to get there one day. I just think you're not going to get there without focusing on taking over a niche at a time, particularly the niche best suited to D right now, mobile. A niche for a general purpose language?
