Re: Database developer's gentle view on D.

[Jimmy Cao]

2012/1/1 Gour 

> On Sat, 31 Dec 2011 20:28:43 -0800
> bls  wrote:
>
> > A Database independent, ORM based library module is not even matter of
> > discussion. That's a  pity.
>
> That would be nice, indeed.
>
> > Well for us Windoze is the only interesting Desktop platform.
> > A _reasonable_ GUI is not available yet.(D-GUI looks pretty
> > good,though)
>
> What is D-GUI, gtkD or DWT?
>
>
dgui:

http://code.google.com/p/dgui/

GUI library for Windows.  Pretty easy to use.

-

gtkD and dwt2 are cross-platform GUI libraries for D.

http://www.dsource.org/projects/gtkd

https://bitbucket.org/torhus/dwt2

Re: Happy New Year in 2012....

[Caligo]

On Sat, Dec 31, 2011 at 11:34 PM, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
>
> to the entire D community!
>
> Andrei


I used GitStats to gather some statistics on DMD.  My favorites:

Age - 932 days, 598 active days (64.16%)
Total Files - 1_016
Total Lines of Code - 328_727 (525_735 added, 197_008 removed)
Total Commits - 2_876 (average 4.8 commits per active day, 3.1 per all days)
Authors - 30 (average 95.9 commits per author)
Busiest month in 2011 - July with over 450 commits
Compared to 2010, there were 4 times as many commits in 2011

Top 10 Authors:
Walter Bright1440 (50.07%)
Don Clugston541 (18.81%)
Brad Roberts402 (13.98%)
k-hara221 (7.68%)
Daniel Murphy70 (2.43%)
dawg63 (2.19%)
KennyTM~29 (1.01%)
Shahid19 (0.66%)
David Nadlinger19 (0.66%)
Michel Fortin17 (0.59%)


2012 is going to be an interesting year.

How mutable is immutable?

[Denis Shelomovskij]

So, I'm a function `f`, I have an `immutable(type)[]` argument and I 
want to store it for my friend `g` in an TLS variable `v`:

---
string v;
debug string sure;

void f(string s) { v = s; debug sure = s.idup; }
void g() { assert(v == sure); }
---
I also store a copy of `s` into `sure` for my friend to ensure immutable 
date hasn't been mutated.

Can my friend's assertion ever fail without breaking a type-system?
Sure. Just consider this:
---
void main() {
auto s = "abba".idup;
f(s);
delete s;
g();
}
---
Is it by-design? Looks like deleting immutable (and const because of 
implicit conversion) data should be prohibited.

OK. Let `delete` be fixed. Can we still fail?
---
void h() {
immutable(char)[4] s = "abba";
f(s);
}
void main() {
h();
g();
}
---
Damn! So, what can we do with it? Not sure, but I have a proposal.

Fix it in language:
* disallow `delete` of const/immutable data
* disallow immutable data on the stack

This makes data really immutable if I don't miss something. Anyway, I 
want `immutable` qualified data to be immutable without breaking a 
type-system (if one do it, its his own responsibility), so some changes 
should be made (IMHO).

Re: Database developer's gentle view on D.

[Gour]

On Sun, 1 Jan 2012 02:22:59 -0600
Jimmy Cao  wrote:

> GUI library for Windows.  Pretty easy to use.

Thank you, but not interesting for us looking for multi-platform
library.


Sincerely,
Gour


-- 
Those persons who execute their duties according to My injunctions 
and who follow this teaching faithfully, without envy, become free 
from the bondage of fruitive actions.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


signature.asc
Description: PGP signature

Re: string is rarely useful as a function argument

[a]

> Meh, I'd still prefer it be an array of UTF-8 code /points/ represented
> by an array of bytes (which are the UTF-8 code units).

By saying you want an array of code points you already define
representation. And if you want that there already is dchar[]. You probably
meant a range of code points represented by an array of code units. But
such a range can't have opIndex, since opIndex implies a constant time
operation.  If you want nth element of the range, you can use std.range.drop
or write your own nth() function.  

Re: Happy New Year in 2012....

[Joel Christensen]

Happy New Year - from New Zealand! :-D

Re: Happy New Year in 2012....

[kenji hara]

A happy new year!

from Japan

Kenji Hara

2012/1/1 Andrei Alexandrescu :
> to the entire D community!
>
> Andrei

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Tobias Pankrath]

Jonathan M Davis wrote:

> I think
> that on some level, the unit test framework in the language has failed if
> we have to add library solutions on top of it to get such basic
> functionality.

That's what we are saying: The unit test framework fails for us and a 
library solution is perfectly possible, even one that lets everyone use
the build in functionality if he wants.

You don't find it useful, but others do. I'd say: many others do. If 
something is considered useful by many it should have a place in the 
standard library. 

Re: Happy New Year in 2012....

[Denis Shelomovskij]

01.01.2012 8:34, Andrei Alexandrescu пишет:

to the entire D community!

Andrei


Happy new year from Russia!

It's OT. This post should be in D.announce NG titled:
"A year have rev. 2012 now. Everybody is switched to this revision 
automatically."

With the following text:
"Somebody is telling it's the final revision, but it's not true. 
Honestly, Humanity is still in pre-alpha state."

Re: A nice way to step into 2012

[Timon Gehr]

On 01/01/2012 08:17 AM, Don wrote:

On 31.12.2011 16:26, Timon Gehr wrote:

On 12/31/2011 12:13 PM, Don wrote:

On 31.12.2011 02:27, so wrote:

On Sat, 31 Dec 2011 02:40:24 +0200, Don  wrote:


I think: there are cases when named parameters are beneficial. There
are cases where they are detrimental.
Is it possible to get the first, without the second, and without much
complexity?


If we keep rules simple as possible i think it is possible.
For that we need our own rules i think, remembering all those rules
suggested here
i can understand why people have issues with them.


(I'm thinking of something like, a colon before the parameter name
means the name is part of the API).


This i don't like, we shouldn't change anything on API side.
All they need to know is that their parameter names (if they provid
one)
might be used in NPs.
Otherwise it would complicate both implementation and usability.


But it is IMPOSSIBLE to not provide them.


It is possible:

void foo(int, float, double, string);


Only if you create and hand-edit a .di file.
And that won't even work for templates.



void foo(T...)(T _);

Then you have to manually reproduce overloading rules inside the 
template body. But you are right. There is no satisfactory solution.




But then it is impossible to have an implementation around for CTFE.

Re: How mutable is immutable?

[Timon Gehr]

On 01/01/2012 10:40 AM, Denis Shelomovskij wrote:

So, I'm a function `f`, I have an `immutable(type)[]` argument and I
want to store it for my friend `g` in an TLS variable `v`:
---
string v;
debug string sure;

void f(string s) { v = s; debug sure = s.idup; }
void g() { assert(v == sure); }
---
I also store a copy of `s` into `sure` for my friend to ensure immutable
date hasn't been mutated.
Can my friend's assertion ever fail without breaking a type-system?
Sure. Just consider this:
---
void main() {
auto s = "abba".idup;
f(s);
delete s;
g();
}
---
Is it by-design? Looks like deleting immutable (and const because of
implicit conversion) data should be prohibited.
OK. Let `delete` be fixed. Can we still fail?
---
void h() {
immutable(char)[4] s = "abba";
f(s);
}
void main() {
h();
g();
}
---
Damn! So, what can we do with it? Not sure, but I have a proposal.

Fix it in language:
* disallow `delete` of const/immutable data
* disallow immutable data on the stack

This makes data really immutable if I don't miss something. Anyway, I
want `immutable` qualified data to be immutable without breaking a
type-system (if one do it, its his own responsibility), so some changes
should be made (IMHO).


You are using unsafe language features to break the type system. That is 
not the fault of the type system.


'@safe:' at the top of the program should stop both examples from 
working, it is a bug that it does not.

Re: string is rarely useful as a function argument

[Timon Gehr]

On 01/01/2012 05:53 AM, Chad J wrote:


If you haven't been educated about unicode or how D handles it, you
might write this:

char[] str;
... load str ...
for ( int i = 0; i<  str.length; i++ )
{
 font.render(str[i]); // Ewww.
 ...
}



That actually looks like a bug that might happen in real world code. 
What is the signature of font.render?

Re: string is rarely useful as a function argument

[Timon Gehr]

On 01/01/2012 08:10 AM, Don wrote:

On 31.12.2011 17:13, Timon Gehr wrote:

On 12/31/2011 01:15 PM, Don wrote:

On 31.12.2011 01:56, Timon Gehr wrote:

On 12/31/2011 01:12 AM, Andrei Alexandrescu wrote:

On 12/30/11 6:07 PM, Timon Gehr wrote:

alias std.string.representation raw;


I meant your implementation is incomplete.


It was more a sketch than an implementation. It is not even type safe
:o).



But the main point is that presence of representation/raw is not the
issue.
The availability of good-for-nothing .length and operator[] are
the issue. Putting in place the convention of using .raw is hardly
useful within the context.



D strings are arrays. An array without .length and operator[] is close
to being good for nothing. The language specification is quite clear
about the fact that e.g. char is not a character but an utf-8 code
unit.
Therefore char[] is an array of code units.


No, it isn't. That's the problem. char[] is not an array of char.
It has an additional invariant: it is a UTF8 string. If you randomly
change elements, the invariant is violated.


char[] is an array of char and the additional invariant is not enforced
by the language.


No, it isn't an ordinary array. For example with concatenation. char[] ~
int will never create an invalid string.


Yes it will.

void main() {
char[] x;
writeln(x~255);
}


You can end up with multiple chars being appended, even from a single append. 
foreach is different,
too. They are a bit magical.


Fair enough, but type conversion rules are a bit magical in general.

void main() {
auto a = cast(short[])[1,2,3];
auto b = [1,2,3];
auto c = cast(short[])b;
assert(a!=c);
}


There's quite a lot of code in the compiler to make sure that strings
remain valid.



At the same time, there are many language features that allow to create 
invalid strings.


auto a = "\377\252\314";
auto b = x"FF AA CC";
auto c = import("binary");


The additional invariant is not enforced in the case of slicing; that's
the point.

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Jacob Carlborg]

On 2011-12-31 21:56, Jonathan M Davis wrote:

On Saturday, December 31, 2011 16:06:49 Jacob Carlborg wrote:

BTW, what would be so wrong if the unit tests for the standard library
displayed a nice report when finished?


My primary issue here is that I don't think that we should be adding stuff to
Phobos which is essentially a new unit test framework on top of the built in
one. If 3rd party stuff wants to do that. Fine. But the standard library should
use the standard facilities. If the standard facilities aren't sufficient, then
they should be improved.


First, that's how programming works. You build new abstractions on top 
of existing ones. Second, I would called the built in support for unit 
testing in D a "unit test framework". If add a unit test framework to 
Phobos it would be standard facilities and it wouldn't be a problem.



As for a "nice report," I don't see anything wrong with just using the stack
traces (which include the file, line number, and error message of the assertion
failure). That's all the information that's needed. Anything else is
superfluous IMHO. Now, if there were something nicer that could be generally
agreed upon and added to druntime such that the standard unit test facilities
used it, then fine. I don't see any point to it, but at least in that case, the
standard library is still using the standard unit test framework. What I
really don't want to see is Phobos essentially building a new unit test
framework on top of the existing one. Any issues that need to be addressed
with the unit test framework for the standard library should be addressed in
the standard framework. Any additional framework stuff should be left to 3rd
parties.

- Jonathan M Davis


What's wrong with being able to run the unit tests from your editor, 
have the unit test framework output HTML (or similar), displayed in your 
editor and then you can click on links in the stack trace to get to the 
source code. If you don't see why that's useful that we can just end 
this discussion now.


--
/Jacob Carlborg

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Jacob Carlborg]

On 2011-12-31 21:57, Jonathan M Davis wrote:

On Saturday, December 31, 2011 15:48:16 Jacob Carlborg wrote:

Yes but what happens when there are many failed tests, i.e. may
AssertErrors that have been thrown? It will just print all after each
other and you have to count them yourself if you want to know how many
failed tests there are?


What does the number of failures really matter? You just need to know which
ones failed and where. The AssertErrors give you that.

- Jonathan M Davis


It can be nice for statistics. And again, how will it be displayed, just 
all AssertErrors after each other?


--
/Jacob Carlborg

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Jacob Carlborg]

On 2011-12-31 22:01, Jonathan M Davis wrote:

On Saturday, December 31, 2011 16:04:12 Jacob Carlborg wrote:

It would be possible to implement named unit tests only in library code.
It would not have as nice syntax as if it was implemented in the
language but still possible.

In Ruby on Rails I run single unit tests all the time. Why would I run
all the unit tests, which can take five minutes, when I just can run one
unit test and it takes just one second?

When your doing test/behavior driven development (T/BDD) it's certainly
nice to be able to run single unit tests, because you run it all the time.


Yes. I agree that it would be nice, but for it to be done at all cleanly, the
language, compiler, and druntime need to be improved to make it possible.
However, at least syntactically, such changes should be completely backwards
compatible, so they can be added at a future date. Regardless, I don't think
that it's a problem that Phobos should be trying to solve.

- Jonathan M Davis


Ok, if you would rather have all this in the language I would say no do 
that. But I know other people in the community that usually prefer to do 
a library solution if possible.


--
/Jacob Carlborg

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Jacob Carlborg]

On 2012-01-01 01:57, Andrew Wiley wrote:

On Sat, Dec 31, 2011 at 2:56 PM, Jonathan M Davis  wrote:

On Saturday, December 31, 2011 16:06:49 Jacob Carlborg wrote:

On 2011-12-31 11:37, Jonathan M Davis wrote:

On Saturday, December 31, 2011 11:05:58 Tobias Pankrath wrote:

I think that the AssertError's message (which includes the file and
line number of the failure) and its stack trace are plenty. It's
exactly what you need and nothing else.

- Jonathan M Davis


I want to have such a summary.


I don't see any reason to put that in the standard library. There's
nothing wrong with 3rd party solutions which give additional
functionality, but D's unit test framework is designed to be
minimilistic, and I don't think that adding anything beyond what it
does now in terms of summary makes any sense. The only major issue in
that regard IMHO is the fact that no further unittest blocks within a
module are run after one fails. Even if it did, I still don't think
that a fancier summary would be worth having - especially in the
standard library.


BTW, what would be so wrong if the unit tests for the standard library
displayed a nice report when finished?


My primary issue here is that I don't think that we should be adding stuff to
Phobos which is essentially a new unit test framework on top of the built in
one. If 3rd party stuff wants to do that. Fine. But the standard library should
use the standard facilities. If the standard facilities aren't sufficient, then
they should be improved.


The counterargument is that the language doesn't really provide a
framework - it actually provides anonymous parameterless global
functions that will be run before main is invoked if code is compiled
with -unittest. That isn't considered a framework in any language I've
ever used, but it adds just enough functionality to allow a
well-integrated fully-featured library solution. Would making such a
library solution part of the standard library really be a problem?
I'm mostly ambivalent on this issue because I haven't had time to look
closely at the proposed framework, but your argument seems to be that
all unittesting functionality needs to be built into the language. I
don't think that should be necessary or required.



As for a "nice report," I don't see anything wrong with just using the stack
traces (which include the file, line number, and error message of the assertion
failure). That's all the information that's needed. Anything else is
superfluous IMHO. Now, if there were something nicer that could be generally
agreed upon and added to druntime such that the standard unit test facilities
used it, then fine. I don't see any point to it, but at least in that case, the
standard library is still using the standard unit test framework. What I
really don't want to see is Phobos essentially building a new unit test
framework on top of the existing one. Any issues that need to be addressed
with the unit test framework for the standard library should be addressed in
the standard framework. Any additional framework stuff should be left to 3rd
parties.


As I said above, I wouldn't consider what we have to be a framework,
but it's definitely enough to build an excellent library solution on
top of.
As for a report, the problem is that an assertion error isn't what you
want when you're running, say, a continuous integration server (or,
say, a pull request tester). What you really want is a detailed
explanation of what unittests broke, what the tests were testing, and
how the result differed from what was expected. You want to be able to
have a reasonable idea of what went wrong *without* having to look at
someone else's code and figure out exactly what they're testing every
time.


Exactly, I agree.

--
/Jacob Carlborg

Re: Array allocation on struct initialization

[Peter Alexander]

On 29/12/11 5:13 PM, Benjamin Thaut wrote:

I'm currently trying to make a nongc safe version of the d-runtime and
stumbeled on my favorite WTF moment so far:

The following programm:

struct MemoryBlockInfo
{
size_t size;
long[10] backtrace;
int backtraceSize;

this(size_t size)
{
this.size = size;
}
}

int main(string[] argv)
{
MemoryBlockInfo info;
info = MemoryBlockInfo.init;
}

This produces the following disassembly:
0040385A mov dword ptr [info],eax
0040385D push 0Ah
0040385F mov ecx,offset TypeInfo_G10l@__init (41E260h)
00403864 push ecx
00403865 call rt@lifetime@_d_arrayliteralTX (404664h)
0040386A mov dword ptr [_TMP0],eax
0040386D mov dword ptr [eax],0
00403873 mov dword ptr [eax+4],0
0040387A mov dword ptr [eax+8],0
00403881 mov dword ptr [eax+0Ch],0
00403888 mov dword ptr [eax+10h],0
0040388F mov dword ptr [eax+14h],0
00403896 mov dword ptr [eax+18h],0
0040389D mov dword ptr [eax+1Ch],0
004038A4 mov dword ptr [eax+20h],0
004038AB mov dword ptr [eax+24h],0
004038B2 mov dword ptr [eax+28h],0

Why in hell is there a call to rt.lieftime._d_arrayliteralTX ???
I always thought that the init data is some global immutable data block
that never changes thorughout the program execution, so why does it need
to be copied? With behaviour like this it is pretty much impossible to
make a nongc safe version of D at all.

Is this a compiler bug or intended behaviour?


Seems like a bug (or at least a misfeature).

If you do this instead:

MemoryBlockInfo info;
MemoryBlockInfo infoInit;
info = infoInit;

Then you don't get the array literal memory allocation i.e. it only 
happens when assigning to T.init explicitly.

Re: Happy New Year in 2012....

[Steve Teale]

On Sat, 31 Dec 2011 23:34:29 -0600, Andrei Alexandrescu wrote:

> to the entire D community!
> 
> Andrei

And from Tanzania - D community come and visit ;=)

Re: Database developer's gentle view on D.

[Steve Teale]

On Sat, 31 Dec 2011 20:28:43 -0800, bls wrote:

> Not yet available. In case that Steve Teale (and he did a dammed
> good Job, as well as Piotr) will add std.database this will not change
> the situation significantly. 'Cause std.database will contain just
> rudimentary DB support..  A Database independent, ORM based library
> module is not even matter of discussion. That's a  pity.
> 
> 
Bjoern,

Even being retired does not mean there's nothing else to do but D library 
components. I didn't get back to you yet because I'm busy making 
furniture for our expanding little enterprise here, and because of the 
holidays, and because I need to lose a few kilos off the belly that 
magically appeared while I was doing nothing but sit in front of a 
keyboard.

Also I'd say for rudimentary I'd want to say basic. There's a slight 
difference.

I'll be back.

Steve

But don't put the database stuff

Re: string is rarely useful as a function argument

[Chad J]

On 01/01/2012 07:59 AM, Timon Gehr wrote:
> On 01/01/2012 05:53 AM, Chad J wrote:
>>
>> If you haven't been educated about unicode or how D handles it, you
>> might write this:
>>
>> char[] str;
>> ... load str ...
>> for ( int i = 0; i<  str.length; i++ )
>> {
>>  font.render(str[i]); // Ewww.
>>  ...
>> }
>>
> 
> That actually looks like a bug that might happen in real world code.
> What is the signature of font.render?

In my mind it's defined something like this:

class Font
{
 ...

/** Render the given code point at
the current (x,y) cursor position. */
void render( dchar c )
{
...
}
}

(Of course I don't know minute details like where the "cursor position"
comes from, but I figure it doesn't matter.)

I probably wrote some code like that loop a very long time ago, but I
probably don't have that code around anymore, or at least not easily
findable.

Re: string is rarely useful as a function argument

[Timon Gehr]

On 01/01/2012 04:13 PM, Chad J wrote:

On 01/01/2012 07:59 AM, Timon Gehr wrote:

On 01/01/2012 05:53 AM, Chad J wrote:


If you haven't been educated about unicode or how D handles it, you
might write this:

char[] str;
... load str ...
for ( int i = 0; i<   str.length; i++ )
{
  font.render(str[i]); // Ewww.
  ...
}



That actually looks like a bug that might happen in real world code.
What is the signature of font.render?


In my mind it's defined something like this:

class Font
{
  ...

 /** Render the given code point at
 the current (x,y) cursor position. */
 void render( dchar c )
 {
 ...
 }
}

(Of course I don't know minute details like where the "cursor position"
comes from, but I figure it doesn't matter.)

I probably wrote some code like that loop a very long time ago, but I
probably don't have that code around anymore, or at least not easily
findable.


I think the main issue here is that char implicitly converts to dchar: 
This is an implicit reinterpret-cast that is nonsensical if the 
character is outside the ascii-range.

Re: A nice way to step into 2012

[Don]

On 31.12.2011 16:58, Timon Gehr wrote:

On 12/31/2011 12:51 PM, Don wrote:

On 2011-12-27 23:27, Timon Gehr wrote:

In case the function is used for code generation, it can get
rid of one level of indentation.
string generate(string x) => mixin(X!q{
@(x) = 2;
});


That just makes it look even more like Perl. The return statement is
not the problem.


The indentation is the problem. If you don't like @(x) = 2; then that is
an unrelated issue.


It's related. That example is polishing a turd.
BTW the bit I don't like isn't the @(x) -- that's the best bit! It's the 
"mixin(", the "q{", and the "})".





My intention is that it would be used with short expressions. Such
monster expressions as in your example are rare in real world code.

That's my point.


On the contrary. The longer the expression, the less it buys you in
readability/the less typing it saves.


The BEST CASE is that you save 6 characters, on


This is the worst case, if it is applicable. The best case is saving an
unbounded amount of characters.


How ??? Each instance of => saves you 6 characters, right?


We should probably stop that discussion soon, because there is no
objective readability measure and therefore it is unlikely that one of
us will change his opinion.


Before the introduction of =>, I never heard anyone mention about the 
"problem" you're fixing. It seems to be a solution in search of problem. 
You can objectively search the newsgroup.



Anyway, it certainly improves language uniformity. Is there any case to
be made against generalizing => ?


Yeah.
(1) *Everything* comes at a cost. It needs to provide a genuine benefit.
More importantly:
(2) I do not agree at all that it improves language uniformity. The fact 
that you have to provide a name when declaring a function means it's not 
the same situation at all.
A function literal is an expression. A function is a declaration. The 
contexts when you use them are completely different. And the grammer is 
different.


It means almost-identical function definitions have completely different 
syntax. This reduces uniformity, and reduces readability.

Re: Removing the Lock for Small GC Allocations: Clarification of GC Design?

[Alex Rønne Petersen]

On 31-12-2011 23:28, dsimcha wrote:

I have a plan to avoid the GC lock for most small (<1 page) GC
allocations. I hope to have a pull request within a week or two, in time
for the next release. There's one detail I need clarified by Sean,
Walter or someone who designed the D GC.

Currently small allocations are handled by popping a block off a free
list, if a block is available. I plan to make each page owned by a
single thread, and make the free lists thread-local. The array of free
lists (one for each power of two size) is stored in the Gcx struct. The
easiest way to make this array thread-local is to move it out of the Gcx
struct and make it global. Is there any reason why >1 instance of Gcx
would exist (maybe as an implementation detail of shared libraries,
etc.)? If not, what's to point of having the Gcx struct instead of just
making its variables global?


AFAIK dynamic libraries don't have the same GC instance running as an 
executable that links to it. Don't quote me on this, though.


- Alex

Re: Happy New Year in 2012....

[Don]

On 01.01.2012 09:40, Caligo wrote:



On Sat, Dec 31, 2011 at 11:34 PM, Andrei Alexandrescu
mailto:seewebsiteforem...@erdani.org>>
wrote:
 >
 > to the entire D community!
 >
 > Andrei


I used GitStats to gather some statistics on DMD.  My favorites:

Age - 932 days, 598 active days (64.16%)
Total Files - 1_016
Total Lines of Code - 328_727 (525_735 added, 197_008 removed)
Total Commits - 2_876 (average 4.8 commits per active day, 3.1 per all days)
Authors - 30 (average 95.9 commits per author)
Busiest month in 2011 - July with over 450 commits
Compared to 2010, there were 4 times as many commits in 2011

Top 10 Authors:
Walter Bright1440 (50.07%)
Don Clugston541 (18.81%)
Brad Roberts402 (13.98%)
k-hara221 (7.68%)
Daniel Murphy70 (2.43%)
dawg63 (2.19%)
KennyTM~29 (1.01%)
Shahid19 (0.66%)
David Nadlinger19 (0.66%)
Michel Fortin17 (0.59%)


Just one or two more merged pull requests would have pushed Walter below 
50%.

Awesome.


2012 is going to be an interesting year.

Re: compiling dmd

[Don]

On 31.12.2011 15:55, Marco Leise wrote:

Am 29.12.2011, 09:16 Uhr, schrieb Don :


On 28.12.2011 13:14, Timon Gehr wrote:

On 12/28/2011 10:53 AM, Peter Alexander wrote:

On 27/12/11 8:40 PM, Andrei Alexandrescu wrote:

On 12/27/11 2:38 PM, Walter Bright wrote:

On 12/27/2011 12:28 PM, Andrei Alexandrescu wrote:

One good realization to make is how less efficient that makes
you. You
got used
to that overhead so plentily, you consider it now par for the
course.


What takes time is running the unittests, not compiling dmd.


Then _that_ is what you consider par for the course! :o)

Andrei


Has anyone looked into what causes the unittests to take so long? I
find
it hard to believe that they need to take as long as they do.


They have to be run for many different combinations of compiler flags
iirc.

AFAIK there has never been a failure which wasn't with one of:
(no flags)
-O -release -inline
-g -O -release -inline

But why do the Phobos unit tests take so long? They used to take a
matter of seconds, now they take forever.

On D1, they still take only about 10 seconds. On D2 they are now
longer than the compiler tests with the minimal flag options.


2.055 hat problems with -O -release -inline -noboundscheck (three of
those anyway, including noboundscheck)


Ah, yes. -release used to include -noboundscheck. Thanks.
The list should be
(no flags)
-O -release -inline -noboundscheck
-g -O -release -inline -noboundscheck

Re: A nice way to step into 2012

[Timon Gehr]

On 01/01/2012 04:39 PM, Don wrote:

On 31.12.2011 16:58, Timon Gehr wrote:

On 12/31/2011 12:51 PM, Don wrote:

On 2011-12-27 23:27, Timon Gehr wrote:

In case the function is used for code generation, it can get
rid of one level of indentation.
string generate(string x) => mixin(X!q{
@(x) = 2;
});


That just makes it look even more like Perl. The return statement is
not the problem.


The indentation is the problem. If you don't like @(x) = 2; then that is
an unrelated issue.


It's related. That example is polishing a turd.


I disagree.


BTW the bit I don't like isn't the @(x) -- that's the best bit! It's the
"mixin(", the "q{", and the "})".



That does not commonly appear in Perl code ;). Anyway, your argument 
against => is that you don't like creative use of the language to be 
supported?






My intention is that it would be used with short expressions. Such
monster expressions as in your example are rare in real world code.

That's my point.


On the contrary. The longer the expression, the less it buys you in
readability/the less typing it saves.


The BEST CASE is that you save 6 characters, on


This is the worst case, if it is applicable. The best case is saving an
unbounded amount of characters.


How ??? Each instance of => saves you 6 characters, right?


auto x() => q{
// 1st line
// 2nd line
// 3rd line
// ...
// nth line
};




We should probably stop that discussion soon, because there is no
objective readability measure and therefore it is unlikely that one of
us will change his opinion.


Before the introduction of =>, I never heard anyone mention about the
"problem" you're fixing.


There does not need to be a problem to perform further improvements. 
Before the introduction of => there also was no precedent of being able 
to replace {return exp;} by => exp in the language.



It seems to be a solution in search of problem.
You can objectively search the newsgroup.


Before the introduction of =>, there was no uniformity problem. I am 
sure this will be brought up again at some point in the future.





Anyway, it certainly improves language uniformity. Is there any case to
be made against generalizing => ?


Yeah.
(1) *Everything* comes at a cost. It needs to provide a genuine benefit.


It requires some trivial parser changes. And I think it does provide a 
genuine benefit.



More importantly:
(2) I do not agree at all that it improves language uniformity. The fact
that you have to provide a name when declaring a function means it's not
the same situation at all.
A function literal is an expression. A function is a declaration.


A function literal is the conflation of a function declaration and a 
symbol lookup. It is both a declaration and an expression.



The contexts when you use them are completely different.


No. Every function literal can be replaced by a function definition and 
a symbol lookup. And every function definition can be replaced by a 
function literal.




And the grammer is different.


That is the point. The grammar should be the same, as it was before the 
introduction of =>.



   (int x){return x&1;}
   (int x) => x&1;
int foo(int x){return x&1;}
int foo(int x) => x&1;




It means almost-identical function definitions have completely different
syntax. This reduces uniformity, and reduces readability.


The same argument could be made against introducing => delegate syntax. 
I don't think it is a valid point.

Re: Database developer's gentle view on D.

[Adam D. Ruppe]

On Sunday, 1 January 2012 at 04:28:45 UTC, bls wrote:
WEB Development is for sure doable in D, reusable Frameworks 
are nevertheless AFAIK not available.


What kind of features did you have in mind for this?

Re: string is rarely useful as a function argument

[Chad J]

On 01/01/2012 10:39 AM, Timon Gehr wrote:
> On 01/01/2012 04:13 PM, Chad J wrote:
>> On 01/01/2012 07:59 AM, Timon Gehr wrote:
>>> On 01/01/2012 05:53 AM, Chad J wrote:

 If you haven't been educated about unicode or how D handles it, you
 might write this:

 char[] str;
 ... load str ...
 for ( int i = 0; i<   str.length; i++ )
 {
   font.render(str[i]); // Ewww.
   ...
 }

>>>
>>> That actually looks like a bug that might happen in real world code.
>>> What is the signature of font.render?
>>
>> In my mind it's defined something like this:
>>
>> class Font
>> {
>>   ...
>>
>>  /** Render the given code point at
>>  the current (x,y) cursor position. */
>>  void render( dchar c )
>>  {
>>  ...
>>  }
>> }
>>
>> (Of course I don't know minute details like where the "cursor position"
>> comes from, but I figure it doesn't matter.)
>>
>> I probably wrote some code like that loop a very long time ago, but I
>> probably don't have that code around anymore, or at least not easily
>> findable.
> 
> I think the main issue here is that char implicitly converts to dchar:
> This is an implicit reinterpret-cast that is nonsensical if the
> character is outside the ascii-range.

I agree.

Perhaps the compiler should insert a check on the 8th bit in cases like
these?

I suppose it's possible someone could declare a bunch of individual
char's and then start manipulating code units that way, and such an 8th
bit check could thwart those manipulations, but I would also counter
that such low manipulations should be done on ubyte's instead.

I don't know how much this would help though.  Seems like too little,
too late.

The bigger problem is that a char is being taken from a char[] and
thereby loses its context as (potentially) being part of a larger
codepoint.

Re: string is rarely useful as a function argument

[Timon Gehr]

On 01/01/2012 08:01 PM, Chad J wrote:

On 01/01/2012 10:39 AM, Timon Gehr wrote:

On 01/01/2012 04:13 PM, Chad J wrote:

On 01/01/2012 07:59 AM, Timon Gehr wrote:

On 01/01/2012 05:53 AM, Chad J wrote:


If you haven't been educated about unicode or how D handles it, you
might write this:

char[] str;
... load str ...
for ( int i = 0; i dchar should just require an explicit 
cast. The runtime check is better left to std.conv.to;




The bigger problem is that a char is being taken from a char[] and
thereby loses its context as (potentially) being part of a larger
codepoint.


If it is part of a larger code point, then it has its highest bit set. 
Any individual char that has its highest bit set does not carry a 
character on its own. If it is not set, then it is a single ASCII character.

Re: Removing the Lock for Small GC Allocations: Clarification of GC Design?

[Martin Nowak]

On Sat, 31 Dec 2011 23:28:09 +0100, dsimcha  wrote:

I have a plan to avoid the GC lock for most small (<1 page) GC  
allocations.  I hope to have a pull request within a week or two, in  
time for the next release.  There's one detail I need clarified by Sean,  
Walter or someone who designed the D GC.


Currently small allocations are handled by popping a block off a free  
list, if a block is available.  I plan to make each page owned by a  
single thread, and make the free lists thread-local.  The array of free  
lists (one for each power of two size) is stored in the Gcx struct.  The  
easiest way to make this array thread-local is to move it out of the Gcx  
struct and make it global.  Is there any reason why >1 instance of Gcx  
would exist (maybe as an implementation detail of shared libraries,  
etc.)?  If not, what's to point of having the Gcx struct instead of just  
making its variables global?


Not for shared libraries.
You should probably wrap multiple TLS variables in a struct and put only
a reference into TLS to reduce the expense of thread local access.

A small style tip

[Mail Mantis]

Just a small tip for those people, who use following code style:

if( cond ) {
  body
} else {
  body
}

I've found it very convenient to "attach" unittest block to my function
declatarions in a same way:

private int find_pos_divisor( int first, int second ) {
int temp;
while( second ) {
temp = second;
second = first % second;
first = temp;
}
return abs( first );
} unittest {
assert( find_pos_divisor ( 10, 20 ) == 10 );
assert( find_pos_divisor ( 10, 0 ) == 10 );
assert( find_pos_divisor ( 9, 6 ) == 3 );
assert( find_pos_divisor ( 10, 3 ) == 1 );
}

Looks as a natural extension to the declaration, and helps to keep all
related code in one place. Did anyone found out any more convenient
D-specific conventions?

Re: string is rarely useful as a function argument

[deadalnix]

Le 31/12/2011 19:13, Timon Gehr a écrit :

On 12/31/2011 06:32 PM, Chad J wrote:

On 12/30/2011 05:27 PM, Timon Gehr wrote:

On 12/30/2011 10:36 PM, deadalnix wrote:


The #1 quality of a programmer is to act like he/she is a morron.
Because sometime we all are morrons.


The #1 quality of a programmer is to write correct code. If he/she acts
as if he/she is a moron, he/she will write code that acts like a moron.
Simple as that.


Programs worth writing are complex enough that there is no way any of us
can write them perfectly correct code on first draft. There is always
going to be some polishing, and maybe even /a lot/ of polishing, and
perhaps some complete tear downs and rebuilds from time to time. "Build
one to throw away; you will anyways." If you tell me that you can
always write correct code the first time and you never need to go back
and fix anything when you do testing (you do test right?) then I will
have a hard time taking you seriously.


Testing is the main part of my development. Furthermore, I use
assertions all over the place.



Well, if you write correct code, you don't need assertion. They will 
always be true because your code is correct. Stop wasting your time with 
that. Remeber the #1 quality of a programmer : write correct code.


See how stupid this becomes ?

Re: string is rarely useful as a function argument

[Timon Gehr]

On 01/01/2012 11:36 PM, deadalnix wrote:

Le 31/12/2011 19:13, Timon Gehr a écrit :

On 12/31/2011 06:32 PM, Chad J wrote:

On 12/30/2011 05:27 PM, Timon Gehr wrote:

On 12/30/2011 10:36 PM, deadalnix wrote:


The #1 quality of a programmer is to act like he/she is a morron.
Because sometime we all are morrons.


The #1 quality of a programmer is to write correct code. If he/she acts
as if he/she is a moron, he/she will write code that acts like a moron.
Simple as that.


Programs worth writing are complex enough that there is no way any of us
can write them perfectly correct code on first draft. There is always
going to be some polishing, and maybe even /a lot/ of polishing, and
perhaps some complete tear downs and rebuilds from time to time. "Build
one to throw away; you will anyways." If you tell me that you can
always write correct code the first time and you never need to go back
and fix anything when you do testing (you do test right?) then I will
have a hard time taking you seriously.


Testing is the main part of my development. Furthermore, I use
assertions all over the place.



Well, if you write correct code, you don't need assertion. They will
always be true because your code is correct. Stop wasting your time with
that. Remeber the #1 quality of a programmer : write correct code.

See how stupid this becomes ?


You miss the point. Testing and assertions are part of how I write 
correct code.

Re: A small style tip

[David]

Am 01.01.2012 23:16, schrieb Mail Mantis:

Just a small tip for those people, who use following code style:

if( cond ) {
   body
} else {
   body
}

I've found it very convenient to "attach" unittest block to my function
declatarions in a same way:

private int find_pos_divisor( int first, int second ) {
 int temp;
 while( second ) {
 temp = second;
 second = first % second;
 first = temp;
 }
 return abs( first );
} unittest {
 assert( find_pos_divisor ( 10, 20 ) == 10 );
 assert( find_pos_divisor ( 10, 0 ) == 10 );
 assert( find_pos_divisor ( 9, 6 ) == 3 );
 assert( find_pos_divisor ( 10, 3 ) == 1 );
}

Looks as a natural extension to the declaration, and helps to keep all
related code in one place. Did anyone found out any more convenient
D-specific conventions?

Nice, I like it

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Jonathan M Davis]

On Sunday, January 01, 2012 15:35:00 Jacob Carlborg wrote:
> Ok, if you would rather have all this in the language I would say no do
> that. But I know other people in the community that usually prefer to do
> a library solution if possible.

If all we're talking about is named unit tests and running all of the unittest 
blocks within a module even if one fails, those aren't huge changes to the 
language. Both have been discussed before, and the only reason that the latter 
hasn't been implemented yet is that it requires changes to the compiler. So, I 
don't see any reason to make those a library solution. If we're talking 
something massively more complicated than that, then yes, a library solution 
starts making more sense. I also think that it then doesn't necessarily make 
sense to put it in the standard library.

If the issue is how the tests print out on failure, that could probably be 
done in the language as well, depending on what you were talking about 
changing. If you want to do something massively complicated, however, then 
you'd probably have to come up with a library solution, but again, I see no 
reason to have it in the standard library if you're doing anything fancy with 
how the test failures print out.

- Jonathan M Davis

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Jonathan M Davis]

On Sunday, January 01, 2012 15:32:34 Jacob Carlborg wrote:
> On 2011-12-31 21:57, Jonathan M Davis wrote:
> > On Saturday, December 31, 2011 15:48:16 Jacob Carlborg wrote:
> >> Yes but what happens when there are many failed tests, i.e. may
> >> AssertErrors that have been thrown? It will just print all after each
> >> other and you have to count them yourself if you want to know how many
> >> failed tests there are?
> > 
> > What does the number of failures really matter? You just need to know
> > which ones failed and where. The AssertErrors give you that.
> > 
> > - Jonathan M Davis
> 
> It can be nice for statistics. And again, how will it be displayed, just
> all AssertErrors after each other?

Yes.

- Jonathan M Davis

Re: string is rarely useful as a function argument

[Chad J]

On 01/01/2012 02:25 PM, Timon Gehr wrote:
> On 01/01/2012 08:01 PM, Chad J wrote:
>> On 01/01/2012 10:39 AM, Timon Gehr wrote:
>>> On 01/01/2012 04:13 PM, Chad J wrote:
 On 01/01/2012 07:59 AM, Timon Gehr wrote:
> On 01/01/2012 05:53 AM, Chad J wrote:
>>
>> If you haven't been educated about unicode or how D handles it, you
>> might write this:
>>
>> char[] str;
>> ... load str ...
>> for ( int i = 0; i> {
>>font.render(str[i]); // Ewww.
>>...
>> }
>>
>
> That actually looks like a bug that might happen in real world code.
> What is the signature of font.render?

 In my mind it's defined something like this:

 class Font
 {
...

   /** Render the given code point at
   the current (x,y) cursor position. */
   void render( dchar c )
   {
   ...
   }
 }

 (Of course I don't know minute details like where the "cursor position"
 comes from, but I figure it doesn't matter.)

 I probably wrote some code like that loop a very long time ago, but I
 probably don't have that code around anymore, or at least not easily
 findable.
>>>
>>> I think the main issue here is that char implicitly converts to dchar:
>>> This is an implicit reinterpret-cast that is nonsensical if the
>>> character is outside the ascii-range.
>>
>> I agree.
>>
>> Perhaps the compiler should insert a check on the 8th bit in cases like
>> these?
>>
>> I suppose it's possible someone could declare a bunch of individual
>> char's and then start manipulating code units that way, and such an 8th
>> bit check could thwart those manipulations, but I would also counter
>> that such low manipulations should be done on ubyte's instead.
>>
>> I don't know how much this would help though.  Seems like too little,
>> too late.
> 
> I think the conversion char -> dchar should just require an explicit
> cast. The runtime check is better left to std.conv.to;
> 

What of valid transfers of ASCII characters into dchar?

Normally this is a widening operation, so I can see how it is permissible.

>>
>> The bigger problem is that a char is being taken from a char[] and
>> thereby loses its context as (potentially) being part of a larger
>> codepoint.
> 
> If it is part of a larger code point, then it has its highest bit set.
> Any individual char that has its highest bit set does not carry a
> character on its own. If it is not set, then it is a single ASCII
> character.

See above.


I think that assigning from a char[i] to another char[j] is probably
safe.  Similarly for slicing.  These calculations tend to occur, I
suspect, when the text is well-anchored.  I believe your balanced
parentheses example falls into this category:
(repasted for reader convenience)

void main(){
string s = readln();
int nest = 0;
foreach(x;s){ // iterates by code unit
if(x=='(') nest++;
else if(x==')' && --nest<0) goto unbalanced;
}
if(!nest){
writeln("balanced parentheses");
return;
}
unbalanced:
writeln("unbalanced parentheses");
}

With these observations in hand, I would consider the safety of
operations to go like this:

char[i] = char[j];   // (Reasonably) Safe
char[i1..i2] = char[j1..j2]; // (Reasonably) Safe
char = char; // Safe
dchar = char // Safe.  Widening.
char = char[i];  // Not safe.  Should error.
dchar = char[i]; // Not safe.  Should error. (Corollary)
dchar = dchar[i];// Safe.
char = char[i1..i2]; // Nonsensical; already an error.

Re: A small style tip

[bearophile]

Mail Mantis:

> private int find_pos_divisor( int first, int second ) {
> int temp;
> while( second ) {
> temp = second;
> second = first % second;
> first = temp;
> }
> return abs( first );
> } unittest {
> assert( find_pos_divisor ( 10, 20 ) == 10 );
> assert( find_pos_divisor ( 10, 0 ) == 10 );
> assert( find_pos_divisor ( 9, 6 ) == 3 );
> assert( find_pos_divisor ( 10, 3 ) == 1 );
> }

It's an interesting idea, I will try it.

Bye,
bearophile

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Jonathan M Davis]

On Sunday, January 01, 2012 15:31:18 Jacob Carlborg wrote:
> What's wrong with being able to run the unit tests from your editor,
> have the unit test framework output HTML (or similar), displayed in your
> editor and then you can click on links in the stack trace to get to the
> source code. If you don't see why that's useful that we can just end
> this discussion now.

If you want fancier unit test facilities in your own code. Fine. I just don't 
think that they should be in the standard library. I think that on the whole, 
D's built-in unit test framework works fine as it is (barring a few tweaks such 
as making it so that all unittest blocks within a module run), and that 
further additions are a needless complication to the standard unit testing 
facilities and better left to 3rd party solutions where you can do whatever 
you want with them.

- Jonathan M Davis

Re: A small style tip

[Jonathan M Davis]

On Monday, January 02, 2012 00:16:18 Mail Mantis wrote:
> Just a small tip for those people, who use following code style:
> 
> if( cond ) {
>   body
> } else {
>   body
> }
> 
> I've found it very convenient to "attach" unittest block to my function
> declatarions in a same way:
> 
> private int find_pos_divisor( int first, int second ) {
> int temp;
> while( second ) {
> temp = second;
> second = first % second;
> first = temp;
> }
> return abs( first );
> } unittest {
> assert( find_pos_divisor ( 10, 20 ) == 10 );
> assert( find_pos_divisor ( 10, 0 ) == 10 );
> assert( find_pos_divisor ( 9, 6 ) == 3 );
> assert( find_pos_divisor ( 10, 3 ) == 1 );
> }
> 
> Looks as a natural extension to the declaration, and helps to keep all
> related code in one place. Did anyone found out any more convenient
> D-specific conventions?

And I find that style to be seriously harming readability (braces should always 
be on their own line IMHO), but I guess that if you like it, it makes sense.

- Jonathan M Davis

Re: string is rarely useful as a function argument

[Timon Gehr]

On 01/02/2012 12:16 AM, Chad J wrote:

On 01/01/2012 02:25 PM, Timon Gehr wrote:

On 01/01/2012 08:01 PM, Chad J wrote:

On 01/01/2012 10:39 AM, Timon Gehr wrote:

On 01/01/2012 04:13 PM, Chad J wrote:

On 01/01/2012 07:59 AM, Timon Gehr wrote:

On 01/01/2012 05:53 AM, Chad J wrote:


If you haven't been educated about unicode or how D handles it, you
might write this:

char[] str;
... load str ...
for ( int i = 0; i< str.length; i++ )
{
font.render(str[i]); // Ewww.
...
}



That actually looks like a bug that might happen in real world code.
What is the signature of font.render?


In my mind it's defined something like this:

class Font
{
...

   /** Render the given code point at
   the current (x,y) cursor position. */
   void render( dchar c )
   {
   ...
   }
}

(Of course I don't know minute details like where the "cursor position"
comes from, but I figure it doesn't matter.)

I probably wrote some code like that loop a very long time ago, but I
probably don't have that code around anymore, or at least not easily
findable.


I think the main issue here is that char implicitly converts to dchar:
This is an implicit reinterpret-cast that is nonsensical if the
character is outside the ascii-range.


I agree.

Perhaps the compiler should insert a check on the 8th bit in cases like
these?

I suppose it's possible someone could declare a bunch of individual
char's and then start manipulating code units that way, and such an 8th
bit check could thwart those manipulations, but I would also counter
that such low manipulations should be done on ubyte's instead.

I don't know how much this would help though.  Seems like too little,
too late.


I think the conversion char ->  dchar should just require an explicit
cast. The runtime check is better left to std.conv.to;



What of valid transfers of ASCII characters into dchar?

Normally this is a widening operation, so I can see how it is permissible.



The bigger problem is that a char is being taken from a char[] and
thereby loses its context as (potentially) being part of a larger
codepoint.


If it is part of a larger code point, then it has its highest bit set.
Any individual char that has its highest bit set does not carry a
character on its own. If it is not set, then it is a single ASCII
character.


See above.


I think that assigning from a char[i] to another char[j] is probably
safe.  Similarly for slicing.  These calculations tend to occur, I
suspect, when the text is well-anchored.  I believe your balanced
parentheses example falls into this category:
(repasted for reader convenience)

void main(){
 string s = readln();
 int nest = 0;
 foreach(x;s){ // iterates by code unit
 if(x=='(') nest++;
 else if(x==')'&&  --nest<0) goto unbalanced;
 }
 if(!nest){
 writeln("balanced parentheses");
 return;
 }
unbalanced:
 writeln("unbalanced parentheses");
}

With these observations in hand, I would consider the safety of
operations to go like this:

char[i] = char[j];   // (Reasonably) Safe
char[i1..i2] = char[j1..j2]; // (Reasonably) Safe
char = char; // Safe
dchar = char // Safe.  Widening.
char = char[i];  // Not safe.  Should error.
dchar = char[i]; // Not safe.  Should error. (Corollary)
dchar = dchar[i];// Safe.
char = char[i1..i2]; // Nonsensical; already an error.


That is an interesting point of view. Your proposal would therefore be 
to constrain char to the ASCII range except if it is embedded in an 
array? It would break the balanced parentheses example.

Re: A small style tip

[Mail Mantis]

2012/1/2 Jonathan M Davis 

>
> And I find that style to be seriously harming readability (braces should
> always
> be on their own line IMHO), but I guess that if you like it, it makes
> sense.
>
> - Jonathan M Davis
>

I understand your point, but don't share it - since tabulation outlines the
code structure pretty well, I suppose it's only a matter of personal
preference.

Re: dmd and C++11

[Sean Cavanaugh]

On 12/29/2011 10:16 AM, Trass3r wrote:

On Thursday, 29 December 2011 at 16:00:47 UTC, Vladimir Panteleev wrote:

On Thursday, 29 December 2011 at 15:58:55 UTC, Trass3r wrote:

What's the stance on using C++11 features in the dmd source code in
the future?


Well, how many C++11 features does DMC support?


*sigh*
Totally forgot about that. Can't we finally get rid of that crappy
toolchain :'(
btw, wasn't there a patch to make dmd compile with VisualStudio cl?


Visual Studio support of C++11 is pretty weak (or maybe more accurately 
'spotty') in VS2010, and this will be virtually unchanged in the next 
version.  On the plus side what is there (rvalue references, auto) is 
nice to have.  On the downside what is missing is really sad (varaidic 
templates, range for, the full set of C++11 type traits, the new unicode 
string types and literals, initializer lists, and a few others I can't 
remember easily)

Re: dmd and C++11

[Mail Mantis]

2012/1/2 Sean Cavanaugh 

> On 12/29/2011 10:16 AM, Trass3r wrote:
>
>> On Thursday, 29 December 2011 at 16:00:47 UTC, Vladimir Panteleev wrote:
>>
>>> On Thursday, 29 December 2011 at 15:58:55 UTC, Trass3r wrote:
>>>
 What's the stance on using C++11 features in the dmd source code in
 the future?

>>>
>>> Well, how many C++11 features does DMC support?
>>>
>>
>> *sigh*
>> Totally forgot about that. Can't we finally get rid of that crappy
>> toolchain :'(
>> btw, wasn't there a patch to make dmd compile with VisualStudio cl?
>>
>
> Visual Studio support of C++11 is pretty weak (or maybe more accurately
> 'spotty') in VS2010, and this will be virtually unchanged in the next
> version.  On the plus side what is there (rvalue references, auto) is nice
> to have.  On the downside what is missing is really sad (varaidic
> templates, range for, the full set of C++11 type traits, the new unicode
> string types and literals, initializer lists, and a few others I can't
> remember easily)
>
> One of the reasons I've switched to g++ lately. As for D - it already
natively supports many C++11 features(or vise-versa), but I wonder if the
user-defined literals will ever make into it.

Re: dmd and C++11

[Walter Bright]

On 1/1/2012 4:30 PM, Mail Mantis wrote:

As for D - it already natively
supports many C++11 features(or vise-versa), but I wonder if the user-defined
literals will ever make into it.


With CTFE D has far better than user defined literals.

Re: dmd and C++11

[Mail Mantis]

2012/1/2 Walter Bright 

> On 1/1/2012 4:30 PM, Mail Mantis wrote:
>
>> As for D - it already natively
>> supports many C++11 features(or vise-versa), but I wonder if the
>> user-defined
>> literals will ever make into it.
>>
>
> With CTFE D has far better than user defined literals.
>

If I undestood you correctly...
Potentially, yes, But, from syntactical point of view, is there any
predefined mean to make something like "a = 2_x + 3_y * 180_deg"
expression? I'm asking because the "mixin( foo( import(  )))" are a bit
too unfriendly in terms of error reports they yield. If there are better
ways of doing so, I'd definitely want to know it.

Re: A small style tip

[Jonathan M Davis]

On Monday, January 02, 2012 01:40:30 Mail Mantis wrote:
> 2012/1/2 Jonathan M Davis 
> 
> > And I find that style to be seriously harming readability (braces should
> > always
> > be on their own line IMHO), but I guess that if you like it, it makes
> > sense.
> > 
> > - Jonathan M Davis
> 
> I understand your point, but don't share it - since tabulation outlines the
> code structure pretty well, I suppose it's only a matter of personal
> preference.

The placement of braces is very much a matter of personal preference.

- Jonathan M Davis

Re: string is rarely useful as a function argument

[Chad J]

On 01/01/2012 06:36 PM, Timon Gehr wrote:
> On 01/02/2012 12:16 AM, Chad J wrote:
>> On 01/01/2012 02:25 PM, Timon Gehr wrote:
>>> On 01/01/2012 08:01 PM, Chad J wrote:
 On 01/01/2012 10:39 AM, Timon Gehr wrote:
> On 01/01/2012 04:13 PM, Chad J wrote:
>> On 01/01/2012 07:59 AM, Timon Gehr wrote:
>>> On 01/01/2012 05:53 AM, Chad J wrote:

 If you haven't been educated about unicode or how D handles it, you
 might write this:

 char[] str;
 ... load str ...
 for ( int i = 0; i< str.length; i++ )
 {
 font.render(str[i]); // Ewww.
 ...
 }

>>>
>>> That actually looks like a bug that might happen in real world code.
>>> What is the signature of font.render?
>>
>> In my mind it's defined something like this:
>>
>> class Font
>> {
>> ...
>>
>>/** Render the given code point at
>>the current (x,y) cursor position. */
>>void render( dchar c )
>>{
>>...
>>}
>> }
>>
>> (Of course I don't know minute details like where the "cursor
>> position"
>> comes from, but I figure it doesn't matter.)
>>
>> I probably wrote some code like that loop a very long time ago, but I
>> probably don't have that code around anymore, or at least not easily
>> findable.
>
> I think the main issue here is that char implicitly converts to dchar:
> This is an implicit reinterpret-cast that is nonsensical if the
> character is outside the ascii-range.

 I agree.

 Perhaps the compiler should insert a check on the 8th bit in cases like
 these?

 I suppose it's possible someone could declare a bunch of individual
 char's and then start manipulating code units that way, and such an 8th
 bit check could thwart those manipulations, but I would also counter
 that such low manipulations should be done on ubyte's instead.

 I don't know how much this would help though.  Seems like too little,
 too late.
>>>
>>> I think the conversion char ->  dchar should just require an explicit
>>> cast. The runtime check is better left to std.conv.to;
>>>
>>
>> What of valid transfers of ASCII characters into dchar?
>>
>> Normally this is a widening operation, so I can see how it is
>> permissible.
>>

 The bigger problem is that a char is being taken from a char[] and
 thereby loses its context as (potentially) being part of a larger
 codepoint.
>>>
>>> If it is part of a larger code point, then it has its highest bit set.
>>> Any individual char that has its highest bit set does not carry a
>>> character on its own. If it is not set, then it is a single ASCII
>>> character.
>>
>> See above.
>>
>>
>> I think that assigning from a char[i] to another char[j] is probably
>> safe.  Similarly for slicing.  These calculations tend to occur, I
>> suspect, when the text is well-anchored.  I believe your balanced
>> parentheses example falls into this category:
>> (repasted for reader convenience)
>>
>> void main(){
>>  string s = readln();
>>  int nest = 0;
>>  foreach(x;s){ // iterates by code unit
>>  if(x=='(') nest++;
>>  else if(x==')'&&  --nest<0) goto unbalanced;
>>  }
>>  if(!nest){
>>  writeln("balanced parentheses");
>>  return;
>>  }
>> unbalanced:
>>  writeln("unbalanced parentheses");
>> }
>>
>> With these observations in hand, I would consider the safety of
>> operations to go like this:
>>
>> char[i] = char[j];   // (Reasonably) Safe
>> char[i1..i2] = char[j1..j2]; // (Reasonably) Safe
>> char = char; // Safe
>> dchar = char // Safe.  Widening.
>> char = char[i];  // Not safe.  Should error.
>> dchar = char[i]; // Not safe.  Should error. (Corollary)
>> dchar = dchar[i];// Safe.
>> char = char[i1..i2]; // Nonsensical; already an error.
> 
> That is an interesting point of view. Your proposal would therefore be
> to constrain char to the ASCII range except if it is embedded in an
> array? It would break the balanced parentheses example.

I just ran the example and wow, x didn't type-infer to dchar like I
expected it to.  I thought the comment might be wrong, but no, it is
correct, x type-infers to char.

I expected it to behave more like the old days before type inference
showed up everywhere:

void main(){
 string s = readln();
 int nest = 0;
 foreach(dchar x;s){ // iterates by code POINT; notice the dchar.
 if(x=='(') nest++;
 else if(x==')'&&  --nest<0) goto unbalanced;
 }
 if(!nest){
 writeln("balanced parentheses");
 return;
 }
unbalanced:
 writeln("unbalanced parentheses");
}

This version wouldn't be broken.  If the type inference changed, the
other version wouldn't be broken either

Re: dmd and C++11

[Adam D. Ruppe]

On Monday, 2 January 2012 at 01:14:43 UTC, Mail Mantis wrote:

If I undestood you correctly...
Potentially, yes, But, from syntactical point of view, is there 
any [...]


http://drdobbs.com/blogs/tools/229401068

In std.conv, the octal template is one example:

int a = octal!755;

Another thing I like doing is using simple structs.
For instance:

struct Html { string src; }

Usage:

Html myhtml = Html("some text");



Which is really easy too.

Can anyone reproduce this?

[Timon Gehr]

On my machine, the following program causes an access violation in 
druntime instead of throwing an AssertError.


module test;
void foo(int x){assert(x);}
void main(){foo(0);}

dmd -run test
-- killed by signal 11


Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu 
11.10 64 bit)?

Can anyone reproduce this?

Re: Can anyone reproduce this?

[Caligo]

On Sun, Jan 1, 2012 at 7:51 PM, Timon Gehr  wrote:

> On my machine, the following program causes an access violation in
> druntime instead of throwing an AssertError.
>
> module test;
> void foo(int x){assert(x);}
> void main(){foo(0);}
>
> dmd -run test
> -- killed by signal 11
>
>
> Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu 11.10
> 64 bit)?
> Can anyone reproduce this?
>

mine throws an AssertError.

DMD 2.057, Ubuntu 11.10 64bit

Re: Can anyone reproduce this?

[Joshua Reusch]

Am 02.01.2012 02:51, schrieb Timon Gehr:

On my machine, the following program causes an access violation in
druntime instead of throwing an AssertError.

module test;
void foo(int x){assert(x);}
void main(){foo(0);}

dmd -run test
-- killed by signal 11


Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu
11.10 64 bit)?
Can anyone reproduce this?


Seems like an 64 bit error. On my Ubuntu 11.10 machine (32bit) with the 
same dmd version, it "works" as expected.

Re: Can anyone reproduce this?

[Joshua Reusch]

Am 02.01.2012 03:07, schrieb Joshua Reusch:

Am 02.01.2012 02:51, schrieb Timon Gehr:

On my machine, the following program causes an access violation in
druntime instead of throwing an AssertError.

module test;
void foo(int x){assert(x);}
void main(){foo(0);}

dmd -run test
-- killed by signal 11


Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu
11.10 64 bit)?
Can anyone reproduce this?


Seems like an 64 bit error. On my Ubuntu 11.10 machine (32bit) with the
same dmd version, it "works" as expected.


Ok, after Caligo: no 64 bit error ...

Re: Can anyone reproduce this?

[Caligo]

On Sun, Jan 1, 2012 at 8:07 PM, Joshua Reusch  wrote:

> Am 02.01.2012 02:51, schrieb Timon Gehr:
>
>  On my machine, the following program causes an access violation in
>> druntime instead of throwing an AssertError.
>>
>> module test;
>> void foo(int x){assert(x);}
>> void main(){foo(0);}
>>
>> dmd -run test
>> -- killed by signal 11
>>
>>
>> Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu
>> 11.10 64 bit)?
>> Can anyone reproduce this?
>>
>
> Seems like an 64 bit error. On my Ubuntu 11.10 machine (32bit) with the
> same dmd version, it "works" as expected.
>

I have the same exact setup as the OP, and mine works as expected, too.
 Doesn't seem like a 64-bit issue.

Re: Can anyone reproduce this?

[Timon Gehr]

On 01/02/2012 03:02 AM, Caligo wrote:



On Sun, Jan 1, 2012 at 7:51 PM, Timon Gehr mailto:timon.g...@gmx.ch>> wrote:

On my machine, the following program causes an access violation in
druntime instead of throwing an AssertError.

module test;
void foo(int x){assert(x);}
void main(){foo(0);}

dmd -run test
-- killed by signal 11


Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu
11.10 64 bit)?
Can anyone reproduce this?


mine throws an AssertError.

DMD 2.057, Ubuntu 11.10 64bit


Ok, thank you.

I wonder what might cause this...

I have the same issue with the following program with the -m32 flag. 
With -m64 it terminates normally instead of throwing.

void main(){throw new Throwable("moo");}

Re: Can anyone reproduce this?

[Matej Nanut]

On 2 January 2012 02:51, Timon Gehr  wrote:

> Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu 11.10
> 64 bit)?
> Can anyone reproduce this?
>

I get an assert error. Using DMD 2.057 and Arch Linux, but on 32 bit. So I
assume that might be it?

Re: Can anyone reproduce this?

[Martin Nowak]

On Mon, 02 Jan 2012 03:23:00 +0100, Timon Gehr  wrote:


On 01/02/2012 03:02 AM, Caligo wrote:



On Sun, Jan 1, 2012 at 7:51 PM, Timon Gehr mailto:timon.g...@gmx.ch>> wrote:

On my machine, the following program causes an access violation in
druntime instead of throwing an AssertError.

module test;
void foo(int x){assert(x);}
void main(){foo(0);}

dmd -run test
-- killed by signal 11


Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu
11.10 64 bit)?
Can anyone reproduce this?


mine throws an AssertError.

DMD 2.057, Ubuntu 11.10 64bit


Ok, thank you.

I wonder what might cause this...

I have the same issue with the following program with the -m32 flag.  
With -m64 it terminates normally instead of throwing.

void main(){throw new Throwable("moo");}


The latter might be related to
http://d.puremagic.com/issues/show_bug.cgi?id=7076.

Re: A small style tip

[Derek]

On Mon, 02 Jan 2012 12:20:36 +1100, Jonathan M Davis   
wrote:




The placement of braces is very much a matter of personal preference.


I suspect that any given piece of source code is read far more often by  
people that didn't write it. So personal code writing preferences can  
affect the future maintainability of code.


--
Derek Parnell
Melbourne, Australia

Re: Can anyone reproduce this?

[Derek]

On Mon, 02 Jan 2012 12:51:20 +1100, Timon Gehr  wrote:

On my machine, the following program causes an access violation in  
druntime instead of throwing an AssertError.


module test;
void foo(int x){assert(x);}
void main(){foo(0);}

dmd -run test
-- killed by signal 11


Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu  
11.10 64 bit)?

Can anyone reproduce this?



Yes I can 


On my machine, the following program causes an access violation in
druntime instead of throwing an AssertError.

module test;
void foo(int x){assert(x);}
void main(){foo(0);}

dmd -run test
-- killed by signal 11


Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu
11.10 64 bit)?
Can anyone reproduce this?


--
Derek Parnell
Melbourne, Australia

Re: Can anyone reproduce this?

[Derek]

On Mon, 02 Jan 2012 14:36:37 +1100, Derek  wrote:

Can anyone reproduce this?



May I did have one too many beers today ...


--
Derek Parnell
Melbourne, Australia

Re: Can anyone reproduce this?

[Timon Gehr]

On 01/02/2012 04:36 AM, Martin Nowak wrote:

On Mon, 02 Jan 2012 03:23:00 +0100, Timon Gehr  wrote:


On 01/02/2012 03:02 AM, Caligo wrote:



On Sun, Jan 1, 2012 at 7:51 PM, Timon Gehr mailto:timon.g...@gmx.ch>> wrote:

On my machine, the following program causes an access violation in
druntime instead of throwing an AssertError.

module test;
void foo(int x){assert(x);}
void main(){foo(0);}

dmd -run test
-- killed by signal 11


Is this a regression or a problem with my setup (DMD 2.057 on Ubuntu
11.10 64 bit)?
Can anyone reproduce this?


mine throws an AssertError.

DMD 2.057, Ubuntu 11.10 64bit


Ok, thank you.

I wonder what might cause this...

I have the same issue with the following program with the -m32 flag.
With -m64 it terminates normally instead of throwing.
void main(){throw new Throwable("moo");}


The latter might be related to
http://d.puremagic.com/issues/show_bug.cgi?id=7076.


Thanks, that helped me track down and solve the problem. It was caused 
by wrong linker flags. (I forgot to remove -L--gc-sections from dmd.conf 
after some testing and did not get any assertion failures since then.)

Re: Bugs marked with [tdpl]

[kenji hara]

Progress status at the end of 2011.
Issue 3235 - [tdpl] Function literals must be deduced as "function" or
"delegate"Issue 5605 - [tdpl] foreach with ranges doesn't support
opSlice()Issue 6714 - [tdpl] Type inference for parameters of function
and delegate literalsIssue 7133 - [tdpl] There should be no empty
statement    RESOLVED FIXED!
Issue 1528 - [tdpl] overloading template and non-template
functionsIssue 2972 - [tdpl] Can't overload non-templated function
against templateIssue 4573 - [tdpl] Specialized functions conflict
with generic function    They are duplications each other
Issue 7131 - [tdpl] Hijacking detected where it doesn't exist    This
is a bit related to above three.    The problem is that the template
function overloadings does not calculate 'overload set'.
Issue 3382 - [tdpl] Implement uniform function call syntaxIssue 3836 -
[tdpl] obligatory override attributeIssue 4596 - [tdpl] Rebinding
*this* in class method compilesIssue 4675 - [tdpl] Eponymous Template
should hide internal names    Patches already posted, but not yet
merged.
Issue 4101 - [tdpl] DMD doesn't give error when goto skips
initializationIssue 4595 - [tdpl] Accessing non-static member of a
null reference compiles    Static analysis features.
Issue 4542 - [tdpl] TDPL NVI example results in linker errorIssue 6176
- [tdpl] Cannot use string variables in case expressions    Still
discussed in bugzilla?
Issue 7135 - [tdpl] Multiple delegate-related issues (literal syntax,
@system deduction)    TDPL code problem? (IMHO)
Issue 4423 - [tdpl] enums of struct typesIssue 4523 - [tdpl] .remove
method for Associative Arrays returns void in all casesIssue 4576 -
[tdpl] 0/1 argument calls to overloaded function is allowed in
presence of variadic functionIssue 6083 - [tdpl] There can be only one
alias this.Issue 7132 - [tdpl] Exponential operator ^^ for integrals
does not compile without any import    ...
Kenji Hara
2011/12/23 Andrei Alexandrescu :
> I've recently finished marking all sample code in TDPL that won't currently
> work. See
>
> http://goo.gl/9sSXP
>
> I've also added a few invisible samples - code that is not present in the
> text, but is implied to work by statements made in the text. I plan to add
> more of those. Essentially almost every paragraph in TDPL should be followed
> by an invisible snippet confirming the claims made. That way, TDPL and D
> would keep unity.
>
> I'll add more such invisible snippets over the winter break. I suggest the
> dmd developers to focus on the bug reports marked with [tdpl] in title.
>
>
> Thanks,
>
> Andrei

Re: Bugs marked with [tdpl]

[kenji hara]

Progress status at the end of 2011.

Issue 3235 - [tdpl] Function literals must be deduced as "function" or
"delegate"Issue 5605 - [tdpl] foreach with ranges doesn't support
opSlice()
Issue 6714 - [tdpl] Type inference for parameters of function and
delegate literals
Issue 7133 - [tdpl] There should be no empty statement
    RESOLVED FIXED!
Issue 1528 - [tdpl] overloading template and non-template functions
Issue 2972 - [tdpl] Can't overload non-templated function against template
Issue 4573 - [tdpl] Specialized functions conflict with generic function
    They are duplications each other

Issue 7131 - [tdpl] Hijacking detected where it doesn't exist
    This is a bit related to above three.
    The problem is that the template function overloadings does not
calculate 'overload set'.

Issue 3382 - [tdpl] Implement uniform function call syntax
Issue 3836 - [tdpl] obligatory override attribute
Issue 4596 - [tdpl] Rebinding *this* in class method compiles
Issue 4675 - [tdpl] Eponymous Template should hide internal names
    Patches already posted, but not yet merged.
Issue 4101 - [tdpl] DMD doesn't give error when goto skips initialization
Issue 4595 - [tdpl] Accessing non-static member of a null reference compiles
    Static analysis features.
Issue 4542 - [tdpl] TDPL NVI example results in linker error
Issue 6176 - [tdpl] Cannot use string variables in case expressions
    Still discussed in bugzilla?
Issue 7135 - [tdpl] Multiple delegate-related issues (literal syntax,
@system deduction)
    TDPL code problem? (IMHO)
Issue 4423 - [tdpl] enums of struct types
Issue 4523 - [tdpl] .remove method for Associative Arrays returns void
in all cases
Issue 4576 - [tdpl] 0/1 argument calls to overloaded function is
allowed in presence of variadic function
Issue 6083 - [tdpl] There can be only one alias this.
Issue 7132 - [tdpl] Exponential operator ^^ for integrals does not
compile without any import
    ...

Kenji Hara


2011/12/23 Andrei Alexandrescu :
> I've recently finished marking all sample code in TDPL that won't currently
> work. See
>
> http://goo.gl/9sSXP
>
> I've also added a few invisible samples - code that is not present in the
> text, but is implied to work by statements made in the text. I plan to add
> more of those. Essentially almost every paragraph in TDPL should be followed
> by an invisible snippet confirming the claims made. That way, TDPL and D
> would keep unity.
>
> I'll add more such invisible snippets over the winter break. I suggest the
> dmd developers to focus on the bug reports marked with [tdpl] in title.
>
>
> Thanks,
>
> Andrei

Better distinguishing reference and value in the syntax?

[Gou Lingfeng]

D's definitions of "is" and "==" have so much redundency. That might
indicate some flaw. If references and values (for classes and arrays)
could be clearly distinguished in the syntax, the "is" operator is not
necessary at all.

A related thing is element-wise operation. Consider
string[] a;
string[] b;
string[] c;
...
c[1..3]=a[1..3]~b[1..3];

and,

int[] a;
int[] b;
int[] c;
...
c[1..3]=a[1..3]+b[1..3];

The two pieces are very much similar, and I expect similar results. But
D doesn't provide element-wise concatenation, because it's not clear in
the syntax whether a[1..3] is a reference (for simple array
concatenation) or a value (for element-wise concatenation).

Re: A small style tip

[F i L]

On Sunday, 1 January 2012 at 22:18:05 UTC, Mail Mantis wrote:

Just a small tip for those people, who use following code style:

if( cond ) {
body
} else {
body
}

I've found it very convenient to "attach" unittest block to my 
function

declatarions in a same way:

private int find_pos_divisor( int first, int second ) {
  int temp;
  while( second ) {
  temp = second;
  second = first % second;
  first = temp;
  }
  return abs( first );
} unittest {
  assert( find_pos_divisor ( 10, 20 ) == 10 );
  assert( find_pos_divisor ( 10, 0 ) == 10 );
  assert( find_pos_divisor ( 9, 6 ) == 3 );
  assert( find_pos_divisor ( 10, 3 ) == 1 );
}

Looks as a natural extension to the declaration, and helps to 
keep all
related code in one place. Did anyone found out any more 
convenient

D-specific conventions?


I've been playing with different style options, especially with 
function contracts. Traditionally, I've used a new line per 
bracket (at least for types and methods) but I've been playing 
around with putting them after the definition. I've found 
readability makes a huge difference that way if your variable 
definition (auto, int, string, etc) are colored different than 
keywords (if, static, public, etc).


class Person
{
   string name;

   void coolName(string name) in {
   assert(name != "F i L");
   } body {
   this.name = name;
   }
}

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Jacob Carlborg]

On 2012-01-02 00:28, Jonathan M Davis wrote:

On Sunday, January 01, 2012 15:31:18 Jacob Carlborg wrote:

What's wrong with being able to run the unit tests from your editor,
have the unit test framework output HTML (or similar), displayed in your
editor and then you can click on links in the stack trace to get to the
source code. If you don't see why that's useful that we can just end
this discussion now.


If you want fancier unit test facilities in your own code. Fine. I just don't
think that they should be in the standard library. I think that on the whole,
D's built-in unit test framework works fine as it is (barring a few tweaks such
as making it so that all unittest blocks within a module run), and that
further additions are a needless complication to the standard unit testing
facilities and better left to 3rd party solutions where you can do whatever
you want with them.

- Jonathan M Davis


I'm ending the discussion here.

--
/Jacob Carlborg

Re: CURL Wrapper: Congratulations Next up: std.serialize

[Jacob Carlborg]

On 2012-01-02 00:14, Jonathan M Davis wrote:

On Sunday, January 01, 2012 15:35:00 Jacob Carlborg wrote:

Ok, if you would rather have all this in the language I would say no do
that. But I know other people in the community that usually prefer to do
a library solution if possible.


If all we're talking about is named unit tests and running all of the unittest
blocks within a module even if one fails, those aren't huge changes to the
language. Both have been discussed before, and the only reason that the latter
hasn't been implemented yet is that it requires changes to the compiler. So, I
don't see any reason to make those a library solution. If we're talking
something massively more complicated than that, then yes, a library solution
starts making more sense. I also think that it then doesn't necessarily make
sense to put it in the standard library.

If the issue is how the tests print out on failure, that could probably be
done in the language as well, depending on what you were talking about
changing. If you want to do something massively complicated, however, then
you'd probably have to come up with a library solution, but again, I see no
reason to have it in the standard library if you're doing anything fancy with
how the test failures print out.

- Jonathan M Davis


I see it as three things I want done.

* Named unit tests
* Continue to run unit tests after a failed one
* A nice report at the end, preferably configurable

It would be nice if the first two were implemented in the language. If 
the third one is implemented in the runtime it could perhaps be 
configurable. One implements an interface, or similar, and can output 
the unit test report how he/she wants.


--
/Jacob Carlborg