headers
bearophile | 22 May 2013 23:11
Picon

From CppNow 2013

Among the CppNow 2013 slide packs I have found two interesting 
things:

https://github.com/boostcon/cppnow_presentations_2013

----------------------

One is from "Concepts Lite: Constraining Templates with 
Predicates" by Andrew Suttoon, Bjarne Stroustrup et al:

https://github.com/boostcon/cppnow_presentations_2013/blob/master/thu/concepts-lite.pdf?raw=true

This is a D version of C++13 code that uses Concepts Lite:

void sort(C)(C cont) if (SortableContainer!C) {}

They suggest to allow a syntax like this, usable when the 
template constraint has only one argument:

void sort(SortableContainer cont) {}

It's handy especially for lambdas:

(Regular x) => x == y;

If you have two or more types, they must be the same (if you 
don't want this, you have to use the normal longer syntax):

void foo(isRandomAccessRange a,
          isRandomAccessRange b) {
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brad Anderson | 22 May 2013 22:07
Gravatar

Re: std.uni vs std.unicode and beyond?

On Wednesday, 22 May 2013 at 17:31:17 UTC, Jonathan M Davis wrote:
> Of course we can provide a migration path, but you're still 
> talking about
> breaking code, and I don't think that std.uni is a bad enough 
> name to merit
> that.

More specifically, what I'm wondering is whether or not it's 
considered a breaking change if your code still compiles and 
works exactly as it did before except for perhaps a deprecation 
warning during the build?

I could be misunderstanding what the proposed public import 
solution would accomplish but it sounded like std.uni could be 
upgraded with Dmitry's improvements while getting a new module 
name that is easier for newcomers to find.  It sounded like 
win-win to me.
Permalink | Reply | 1 comment |
headers
Jacob Carlborg | 22 May 2013 20:51

Re: new DIP41: dmd/rdmd command line overhaul.

On 2013-05-22 20:14, Jonathan M Davis wrote:

> This is how every command line tool should do it, and it's semi-standard, but
> unfortunately not all programs follow it (compilers in particular seem to do a
> bad job of it). On a related note, one of my pet peeves is the fact that
> std.getopt doesn't do bundling by default, as that's another thing that's
> semi-standard. Most *nix apps actually get this right (particularly if they're
> not ancient - the only ones seem more likely to have screwy rules about the
> order of flags and how many dashes you use and whatnot), but dmd doesn't follow
> the proper flag rules at all (probably because it's primary maintainer is
> primarily a Windows guy).

Yeah, I don't know what's up with compilers. GCC, Clang and DMD all use 
a non-standard flag format. Although Clang follows GCC with many flags 
to be compatible.

--

-- 
/Jacob Carlborg
Permalink | Reply | 0 comments |
headers
Jacob Carlborg | 22 May 2013 20:46

Re: new DIP41: dmd/rdmd command line overhaul.

On 2013-05-22 20:26, Jonathan M Davis wrote:

> And continuing to tweak APIs and the like for minor improvements won't help
> with that. Yes, it's still the case that too much breaks from release to
> release, but I believe that that's mostly an issue of compiler regressions at
> this point, and those only get caught if enough people try the beta (which is
> why some have been pushing for Walter to announce the beta in D.announce
> rather than just in the beta list, which he's done this time around). Even if
> the situation isn't yet where we want it to be, it _is_ improving, and we want
> to make sure that the decisions that we make encourage stability so that we
> _will_ be considered stable in the near future.

I have not so much problem with the breaking in it self. It's rather 
that there are several people here pretending D is stable.

--

-- 
/Jacob Carlborg
Permalink | Reply | 1 comment |
headers
Nick Sabalausky | 22 May 2013 19:19

Re: External lib unittests: they're killin me!

On Wed, 22 May 2013 10:06:46 -0700
Timothee Cour <thelastmammoth <at> gmail.com> wrote:

> it's only module level granularity.
> 
> I agree that a library solution is the way to go, however there needs
> to be a way to have finer granularity, ie being able to call
> individual unittests. I gave the reasons in the 2nd post in this
> thread. Syntax would be: unittest(test_fun){...}
> having a short syntax such as this will make people use it.
> 
> digressing, I wish there would be a simple non-anonymous way to vote
> for such features, to see whether most people agree/disagree. It's
> easier than voting by email, which invariably gets lost in
> digressions (as I'm doing here).
> 

Bugzilla has a voting system <http://d.puremagic.com/issues/>. Every
user has up to 10 votes to place on whatever tickets they want.
Permalink | Reply | 1 comment |
headers
dennis luehring | 22 May 2013 16:04
Picon

http://dlang.org/changelog.html

first the normal page appears, then after some ms a page refresh occurse 
(which adds the "Run" feature) - but i only get syntax errors from Run
Permalink | Reply | 0 comments |
headers
Regan Heath | 22 May 2013 11:09
Picon
Gravatar

Re: std.uni vs std.unicode and beyond?

On Tue, 21 May 2013 19:04:25 +0100, Simen Kjaeraas  
<simen.kjaras <at> gmail.com> wrote:

> On 2013-05-21, 16:02, Regan Heath wrote:
>
>> On Tue, 21 May 2013 14:20:50 +0100, Dmitry Olshansky  
>> <dmitry.olsh <at> gmail.com> wrote:
>>> 21-May-2013 17:03, Regan Heath пишет:
>>> [snip]
>> [snip]
> [snip]
>>>> Meaning if we can make an incremental change for the better
>>>
>>> For better how? The endless churn in my opinion is not worth the  
>>> incremental change for better. You also would have to argue for every  
>>> single change with folks pushing whichever way they feel like to (not  
>>> talking about uni). This is a proverbial "design by committee".
>>
>> Another generalisation.  No-one is suggesting we start renaming modules  
>> just because user X wants to.  All I suggested is that if we get a  
>> chance to do so at the same time as another breaking change to the same  
>> module, we should - provided the benefit of the rename is clear.
>
> I believe his point was rather that this time around we get std.unicode.
> Next module is std.encoding.ascii, and then comes std.text.ebcdic.
>
> I'm all for calling it *.unicode instead of *.uni - that part is only
> logical. However, there should be a roadmap as to whether * should be
> std, std.encoding, or whatever.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dicebot | 22 May 2013 11:12
Picon
Gravatar

What has happened to "-vgc" pull request?

subj

I remember seeing one in dmd pull request list but can't find it 
now.
Permalink | Reply | 3 comments |
headers
Dicebot | 22 May 2013 10:25
Picon
Gravatar

Re: new DIP41: dmd/rdmd command line overhaul.

Except D is nowhere close to stable, it only pretends to. Every 
single release breaks the code. Every. Usual attitude "well, it 
is a breaking change and a lot of users will be screwed, but it 
is a bug fix, so we are all right?". No, you are not. I can't 
imagine where such definition of "breaking" came from, it is 
literally single most disastrous thing in D development process.

And I have proposed various ways to address it properly via 
release process numerous times. Every single topic was ignored 
both by Andrei and Walter. Because, yeah, it isn't real problem, 
is it?

On Tuesday, 21 May 2013 at 21:11:36 UTC, Jonathan M Davis wrote:
> We need to be willing to make breaking changes when we actually 
> need to make
> them and avoid them when we don't. We're past the point when we 
> can tweak
> everything to improve it. There are too many people using D now 
> and too many
> of them wanting stability for us to continue to make minor 
> tweaks. Breaking
> changes need to provide real value. Unfortunately, in some 
> cases, that means
> being stuck with some things that are less than ideal, but if 
> we're forever
> tweaking everything to improve it, we'll never be stable enough 
> for people to
> be able to depend on us for real work.
(Continue reading)

Permalink | Reply | 10 comments |
headers
IgorStepanov | 22 May 2013 10:05
Picon

C++ parser

Is there someone free C++ parser? I want to create simple util to 
converting C++ headers to D like htod, but I want, if it 
possible, to dont write C++ parser. Any ideas?
Permalink | Reply | 14 comments |
headers
Jacob Carlborg | 22 May 2013 08:44

Re: Ideal D GUI Toolkit

On 2013-05-22 07:00, Peter Williams wrote:

> My experience (with PyGTK) is that GUI building tools actually make the
> task harder not easier (once you become familiar with the API).  Of
> course, things may have changed since I last used such a tool but I
> doubt it.

Then you obviously haven't used Interface Builder/Xcode on Mac OS X. 
It's a great tool for window building.

> Having said that I have to admit that I've implemented my own "list/tree
> specification" mechanism for that particular job because it made it
> easier to find where to make changes.  In my defence, last time I used
> one of the GUI building tools it contained no support for building lists
> and trees so making my own made sense.

If the tool didn't support trees you obviously used a bad tool. In Xcode 
you can drag in a standard view, then change the implementation class. 
This allows you to add your custom views to the window using the GUI 
builder. It used to have plugins for this but they were removed in Xcode 4.

--

-- 
/Jacob Carlborg
Permalink | Reply | 2 comments |

Gmane