Re: Moving to D

[Caligo]

On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
wrote:

>
> That's pretty much what I'm afraid of, losing my grip on how the whole
> thing works if there are multiple dmd committers.
>
> Perhaps using a modern SCM like Git might help?  Everyone could have (and
should have) commit rights, and they would send pull requests.  You or one
of the managers would then review the changes and pull and merge with the
main branch.  It works great; just checkout out Rubinius on Github to see
what I mean: https://github.com/evanphx/rubinius

Re: Moving to D

[bearophile]

Nick Sabalausky:

>Automatically accepting all submissions immediately into the main line with no 
>review isn't a good thing either.<

I agree with all you have said, I was not suggesting a wild west :-)

But maybe there are ways to improve the situation a little, I don't think the 
current situation is perfect. A better revision control system like Git or 
Mercury (they are not equal, but both are good enough) will be an improvement.

--

Caligo:

> Perhaps using a modern SCM like Git might help?  Everyone could have (and
> should have) commit rights, and they would send pull requests.  You or one
> of the managers would then review the changes and pull and merge with the
> main branch.  It works great; just checkout out Rubinius on Github to see
> what I mean: https://github.com/evanphx/rubinius

I agree. Such systems allow to find a middle point better than the current one 
between wild freedom and frozen proprietary control. Walter and few others are 
the only allowed to commit to the main trunk, so Walter has no risk in "losing 
grip on how the whole thing works", but freedom in submitting patches and 
creating branches allows people more experimentation, simpler review of patches 
and trunks, turning D/DMD in a more open source effort... So I suggest Walter 
to consider all this.

Bye,
bearophile

Re: std.unittests for (final?) review

[bearophile]

Andrei:

> One more thing. Since assert() is available and useful outside 
> unittests, I don't see a reason for which assertPred and friends should 
> only be available during unittesting. I can sure use them in regular code.

I guess assertPred creates statistics to be printed at the end of the 
unittests? I don't think mixing the two groups of things is good.

Bye,
bearophile

Re: std.unittests for (final?) review

[Nick Sabalausky]

"Jonathan M Davis"  wrote in message 
news:mailman.450.1294300236.4748.digitalmar...@puremagic.com...
> On Wednesday 05 January 2011 23:08:21 Nick Sabalausky wrote:
>> "Jonathan M Davis"  wrote in message
>> news:mailman.446.1294293885.4748.digitalmar...@puremagic.com...
>>
>> > What about something like a < b && c < d? If assertPred!() takes more
>> > than two parameters (as I would hope it would), then you could do
>> > something like
>> > assertPred!((a, b, c, d){return a < b && c < d;})(foo(), bar(), 
>> > hello(),
>> > world()) and it could not only tell you that the predicate failed, but 
>> > it
>> > could
>> > tell you that the values that it was given were 1, 5, 4, and 2. How 
>> > could
>> > assert(foo() < bar() && hello() < world()) do that? It has to know 
>> > where
>> > to stop
>> > the expressions evaluation to print it.
>>
>> How about this set of rules?:
>>
>> As the compler evaluates the assert's expression tree starting from the
>> root:
>>
>> 1. Literals DO NOT have their values printed.
>> 2. Built-in-operator expressions (arithmetic, parens, comparison, etc) DO
>> NOT have their values printed, but the compiler traverses their immediate
>> sub-expressions.
>> 3. Variables DO have their values printed.
>> 4. Things that take parameters (such as a function call or an eponymous
>> template instantiation) DO have their values printed, but the compiler 
>> does
>> *not* traverse the parameters (unless this is the root-level expression).
>
> I think that that you'd have to give some examples for it to be clear what
> exactly you mean, but it sounds like this would print a lot more values 
> than
> would be desirable in complex expressions. With assertPred, I could do 
> something
> like
>
> assertPred!"=="(foo(bar(g, none("abc")) * 2, hello(world(i)) + 2 * 
> func(funky(2
> + q)), 25)
>
> and get what the actual result was. e.g. "== failed: 14 != 25". I wouldn't 
> want
> all of those arguments printed. It's the final result that matters. If I
> understand what you're suggesting, a lot of those arguments would be 
> printed in
> your suggestion, which would be less than desirable, I think. Granted, 
> that
> particular example is quite ugly, but I'd like to be able to test 
> arbitrarily
> complex functions and still get a reasonably informative error when the 
> test
> fails.
>

Your example is missing a closing paren, I assume you meant:

assertPred!"=="(foo(bar(g, none("abc")) * 2, hello(world(i)) + 2 * 
func(funky(2 + q))), 25)

Ie, assertPred is given two run-time arguments, the first of which is a call 
to foo. And foo is given two arguments: "bar(...)*2" and 
"hello(...)+2*func(...)".

Under my suggestion, that example would be:

assert(foo(bar(g, none("abc")) * 2, hello(world(i)) + 2 * func(funky(2 + 
q))) == 25)

If that fails, it would first print something like:
file(line): Assert failed: foo(bar(g, none("abc")) * 2, hello(world(i)) 
+ 2 * func(funky(2 + q))) == 25

Then it would inspect the expression: The root-level expression is "stuff == 
25". The right-hand-side, 25, is a literal, so that's ignored (rule #1). The 
left-hand side is the expression "foo(param1, param2)", so it's value (14 in 
your example) gets displayed (rule #4):

   [foo(bar(g, none("abc")) * 2, hello(world(i)) + 2 * func(funky(2 + q)))]: 
14

Since foo is something that takes params (it's a function call) and it's not 
the root expression (the == is the root expression), foo's params are 
ignored (rule #4) and everything is now done.

Alternatively, the rules could be followed like this:

Start with the whole expression, but do not print anything yet. Look at the 
root expression: It's "stuff == 25". The 25 is a literal, so leave it as-is 
(essentially rule #1). The other side is a function call, so replace the 
expression "foo(...,...)" with it's value, 14 (essentially rule #4). Now 
there's no more subexpressions left to process, so display the 
newly-modified expression: 14 == 25

Under the other example you had:

assert(foo() < bar() && hello() < world())

The expression tree looks like this:

- Root: &&
- LHS of &&: <
- LHS of <: foo()
- RHS of <: bar()
- RHS of &&: <
- LHS of <: hello()
- RHS of <: world()

The root is &&, so we dive into it's operands (rule #2). Both of those are 
<, so we dive into their respective operands (rule #2). Now we have four 
things that take params (I'm conveniently ignoring the fact that the number 
of params they actually take just happens to be 0), so we either display or 
substitute-in their values and dive no further (rule #4), and get either:

Failed: foo() < bar() && hello() < world()
foo(): 4
bar(): 3
hello(): 2
world(): 1

Or just: 4 < 3 && 2 < 1

Note that due to the way rule #2 is written, if you replaced "foo()" with 
"f() + oo()", then you would get something like:

2 + 2 < 3 && 2 < 1

Which I don't think is too bad, particularly considering the expression it 
came from. And is is more information, whic

Re: Moving to D

[Nick Sabalausky]

"Caligo"  wrote in message 
news:mailman.451.1294306555.4748.digitalmar...@puremagic.com...
> On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
> wrote:
>
>>
>> That's pretty much what I'm afraid of, losing my grip on how the whole
>> thing works if there are multiple dmd committers.
>>
>> Perhaps using a modern SCM like Git might help?  Everyone could have (and
> should have) commit rights, and they would send pull requests.  You or one
> of the managers would then review the changes and pull and merge with the
> main branch.  It works great; just checkout out Rubinius on Github to see
> what I mean: https://github.com/evanphx/rubinius
>

I'm not sure I see how that's any different from everyone having "create and 
submit a patch" rights, and then having Walter or one of the managers review 
the changes and merge/patch with the main branch.

Re: Moving to D

[Jacob Carlborg]

On 2011-01-05 22:39, bearophile wrote:

Jacob Carlborg:


And sometimes Mac OS X is *slightly* ahead of the other OSes, Tango has
had support for dynamic libraries on Mac OS X using DMD for quite a
while now. For D2 a patch is just sitting there in bugzilla waiting for
the last part of it to be commited. I'm really pushing this because
people seem to forget this.


A quotation from here:
http://whatupdave.com/post/1170718843/leaving-net


Also stop using codeplex it’s not real open source! Real open source isn’t 
submitting a patch and waiting/hoping that one day it might be accepted and merged 
into the main line.<


Bye,
bearophile


So what are you saying here? That I should fork druntime and apply the 
patches myself? I already have too many projects to handle, I probably 
can't handle yet another one.


--
/Jacob Carlborg

Re: Moving to D

[Ulrik Mikaelsson]

2011/1/6 Nick Sabalausky :
> "Caligo"  wrote in message
> news:mailman.451.1294306555.4748.digitalmar...@puremagic.com...
>> Perhaps using a modern SCM like Git might help?  Everyone could have (and
>> should have) commit rights, and they would send pull requests.  You or one
>> of the managers would then review the changes and pull and merge with the
>> main branch.  It works great; just checkout out Rubinius on Github to see
>> what I mean: https://github.com/evanphx/rubinius
>
> I'm not sure I see how that's any different from everyone having "create and
> submit a patch" rights, and then having Walter or one of the managers review
> the changes and merge/patch with the main branch.

With the risk of starting yet another VCS-flamewar: It gives the
downstream developers an easier option to work on multiple patches in
patch-sets. Many non-trivial changes are too big to do in a single
step, but requires series of changes. Sure, the downstream hacker
could maintain import/conversion to VCS, but with added job, and when
Walter or someone else gets to review they are no longer
well-annotated patches.

It also facilitates a setup where Walter (BDFL? ;) starts to trust
some contributors (if he wants to) more than others, for them to work
on private branches and submit larger series of patches for each
release.

Especially, when you detect a showstopper bug that blocks your
progress, IMHO, it's easier using a DVCS to maintain a local patch for
the needed fix, until upstream includes it. I've often used that
strategy both in D-related and other projects just to remain sane and
work-around upstream bugs, I just usually have to jump through a some
hoops getting the source into DVCS in the first place.

I think it was on this list I saw the comparison of VCS:es to the
Blub-problem? http://en.wikipedia.org/wiki/Blub#Blub

Although, I don't think the current setup have any _serious_ problems,
I think there might be slight advantages to gain. OTOH, unless other
current key contributors wants to push it, it's probably not worth the
cost of change.

Re: Moving to D

[bearophile]

Jacob Carlborg:

> So what are you saying here? That I should fork druntime and apply the 
> patches myself? I already have too many projects to handle, I probably 
> can't handle yet another one.

See my more recent post for some answer. I think changing how DMD source code 
is managed (allowing people to create branches, etc) is not going to increase 
your work load. On the other hand it's going to make D more open source for 
people that like this and have some free time.

Bye,
bearophile

Re: Moving to D

[bearophile]

Walter Bright:

> I don't, either.

Then it's a very good moment for starting to seeing/understanding this and 
similar things!

Bye,
bearophile

Re: Moving to D

[Walter Bright]

Nick Sabalausky wrote:
"Caligo"  wrote in message 
news:mailman.451.1294306555.4748.digitalmar...@puremagic.com...

On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
wrote:


That's pretty much what I'm afraid of, losing my grip on how the whole
thing works if there are multiple dmd committers.

Perhaps using a modern SCM like Git might help?  Everyone could have (and

should have) commit rights, and they would send pull requests.  You or one
of the managers would then review the changes and pull and merge with the
main branch.  It works great; just checkout out Rubinius on Github to see
what I mean: https://github.com/evanphx/rubinius



I'm not sure I see how that's any different from everyone having "create and 
submit a patch" rights, and then having Walter or one of the managers review 
the changes and merge/patch with the main branch.


I don't, either.

Re: std.unittests for (final?) review

[Lutger Blijdestijn]

Michel Fortin wrote:

> I'm not sold on the concept. The whole point of this module seems to
> offer a way to replace the built-in assertion mechanism with a
> customized one, with the sole purpose of giving better error messages.
> So we're basically encouraging the use of:
> 
> assertPredicate!"a > b"(a, b, "message");
> 
> instead of:
> 
> assert(a > b, "message");
> 
> It looks like an uglification of the language to me.

As you said, it is all about the error messages, not replacing assert perse. 
So this comparison would be more fair, using the syntax suggested by Andrei:

assertPred!">"(a, b);

vs

assert(a > b, format("a > b failed: [%s] is not > [%s]", a, b) );

If you really want the error message, regular asserts are a bit uglier and 
duplicate code.

Cutting down on the characters further, 'expect' could be used instead of 
assertPred. Some unittest libraries also use this, but I can't remember 
which one. I think it then makes sense to unify everything:

expect!">"(a, b);
expect!Exception( { throw new Exception(""); } () );

Re: Moving to D

[Russel Winder]

On Thu, 2011-01-06 at 03:35 -0600, Caligo wrote:
[ . . . ]
> 
> Perhaps using a modern SCM like Git might help?  Everyone could have
> (and should have) commit rights, and they would send pull requests.
> You or one of the managers would then review the changes and pull and
> merge with the main branch.  It works great; just checkout out
> Rubinius on Github to see what I mean:
> https://github.com/evanphx/rubinius

Whilst I concur (massively) that Subversion is no longer the correct
tool for collaborative working, especially on FOSS projects, but also
for proprietary ones, I am not sure Git is the best choice of tool.
Whilst Git appears to have the zeitgeist, Mercurial and Bazaar are
actually much easier to work with.  Where Git has GitHub, Mercurial has
BitBucket, and Bazaar has Launchpad.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.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: Moving to D

[Russel Winder]

On Thu, 2011-01-06 at 03:10 -0800, Walter Bright wrote:
> Nick Sabalausky wrote:
> > "Caligo"  wrote in message 
> > news:mailman.451.1294306555.4748.digitalmar...@puremagic.com...
> >> On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
> >> wrote:
> >>
> >>> That's pretty much what I'm afraid of, losing my grip on how the whole
> >>> thing works if there are multiple dmd committers.
> >>>
> >>> Perhaps using a modern SCM like Git might help?  Everyone could have (and
> >> should have) commit rights, and they would send pull requests.  You or one
> >> of the managers would then review the changes and pull and merge with the
> >> main branch.  It works great; just checkout out Rubinius on Github to see
> >> what I mean: https://github.com/evanphx/rubinius
> >>
> > 
> > I'm not sure I see how that's any different from everyone having "create 
> > and 
> > submit a patch" rights, and then having Walter or one of the managers 
> > review 
> > the changes and merge/patch with the main branch.
> 
> I don't, either.

Pity, because using one of Mercurial, Bazaar or Git instead of
Subversion is likely the best and fastest way of getting more quality
contributions to review.  Although only anecdotal in every case where a
team has switched to DVCS from CVCS -- except in the case of closed
projects, obviously -- it has opened things up to far more people to
provide contributions.  Subversion is probably now the single biggest
barrier to getting input on system evolution.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.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: Moving to D

[Lutger Blijdestijn]

Nick Sabalausky wrote:

> "Caligo"  wrote in message
> news:mailman.451.1294306555.4748.digitalmar...@puremagic.com...
>> On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
>> wrote:
>>
>>>
>>> That's pretty much what I'm afraid of, losing my grip on how the whole
>>> thing works if there are multiple dmd committers.
>>>
>>> Perhaps using a modern SCM like Git might help?  Everyone could have
>>> (and
>> should have) commit rights, and they would send pull requests.  You or
>> one of the managers would then review the changes and pull and merge with
>> the
>> main branch.  It works great; just checkout out Rubinius on Github to see
>> what I mean: https://github.com/evanphx/rubinius
>>
> 
> I'm not sure I see how that's any different from everyone having "create
> and submit a patch" rights, and then having Walter or one of the managers
> review the changes and merge/patch with the main branch.

There isn't because it is basically the same workflow. The reason why people 
would prefer git style fork and merge over sending svn patches is because 
these tools do the same job much better. github increases the usability 
further and give you nice pr for free.

otoh I understand that it's not exactly attractive to invest time to replace 
something that also works right now.

Re: std.unittests for (final?) review

[Michel Fortin]

On 2011-01-06 01:36:32 -0500, Jonathan M Davis  said:


Okay. I thought this through a bit more, and I think that if the evaluation was
stopped when all that was left in the expression was boolean operators 
and their

operands, then that pretty much has to be what the programmer was trying to
print. That being the case, you could theoretically get assert to do it, but I
would expect that that would make assert awfully complicated. Done properly, it
would be fantastic, but since it can be done in a library with something like
assertPred!() much more easily, I wouldn't expect such an enhancement to assert
to be implemented any time soon.


Some people though const(Object)ref was impossible too.

I agree that assertPred!() is useful in the meanwhile.



A few of the things that I'm thinking of doing with assertPred!() have to be
special cased though in a way which wouldn't work with assert. For 
instance, I'm

thinking of doing something like assertPred!("opCmp", 0)(foo(), bar()), which
would do what assertOpCmp!() does now. As such, opCmp() isn't a predicate, if
you rewrote it to assert(foo().opCmp(bar()) == 0), even stopping 
evaluation when

all you have left is boolean operators and their operands wouldn't work, since
then you'd get something like 1 == 0 rather than (assuming that foo() and bar()
return something like BigInts which have the values "4" and "2" respectively)
something like "opCmp() == 0 failed: 4 > 2".


For these cases you might prefer a custom assertion function, such as 
assertOpCmp!(). I think it's important that assert be useful for the 
common case, it doesn't mean that more specialized solutions cannot be 
created for more specialized cases, such as this one.



Sure, you could make it so that assert could do that sort of thing too, 
but then

you're adding special cases and complicating assert even further, and it's also
much harder to add such cases, because then you're actually changing the
_language_ rather than the standard library, and every compiler would have to
follow suit.


It's a quality of implementation issue. What error message an assert 
gives is no more part of the language than what error message the 
compiler outputs when it encounters some incorrect code. The compiler 
could simply print "error" each time it encounters an error and it'd be 
compliant (even though that would be extremely annoying).


Beside, all the current working compilers share the same front end, so 
they'll all get this for free.


So I think it's worth it.



So, yes assert could theoretically be improved to do a lot more and do a lot
better, but it won't ever do as much as I could do with assertPred!(), and even
if assert _is_ improved as you suggest (which would certainly be cool), then
there's still some value in assertPred!().


There's an other issue that's bothering me with these assertion 
functions... with 'assert', assertions behaves differently depending on 
where you write them. In regular code, on failure it calls _d_assert*, 
in a unit test on failure it calls _d_unittest*, and in contracts for 
virtual function... well that case I don't understand it fully but it 
does something very special to implement contract inheritance.


What does assertPred do? It does "throw new AssertError(...)", 
irrespective of the context. I'm pretty sure that'll break contract 
inheritance if used inside a contract. To be truly a replacement for 
assert, assertPred would need to know in which context it is called and 
generate the appropriate code, although I somewhat doubt it is even 
possible to generate the right code for contracts without the compiler 
doing it.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: std.unittests for (final?) review

[Michel Fortin]

On 2011-01-06 06:45:41 -0500, Lutger Blijdestijn 
 said:



As you said, it is all about the error messages, not replacing assert perse.
So this comparison would be more fair, using the syntax suggested by Andrei:

assertPred!">"(a, b);

vs

assert(a > b, format("a > b failed: [%s] is not > [%s]", a, b) );

If you really want the error message, regular asserts are a bit uglier and
duplicate code.


The whole point of my proposal is to make the regular asserts print a 
message similar to yours *by default*, when you don't specify any 
message. This is possible because assert is not a function, it's a 
language construct handled by the compiler. The compiler has access to 
the whole expression tree, and it can rewrite the code to store 
intermediate results in variables it can later give to the assertion 
handler in case of failure.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: std.unittests for (final?) review

[Lutger Blijdestijn]

Michel Fortin wrote:

> On 2011-01-06 06:45:41 -0500, Lutger Blijdestijn
>  said:
> 
>> As you said, it is all about the error messages, not replacing assert
>> perse. So this comparison would be more fair, using the syntax suggested
>> by Andrei:
>> 
>> assertPred!">"(a, b);
>> 
>> vs
>> 
>> assert(a > b, format("a > b failed: [%s] is not > [%s]", a, b) );
>> 
>> If you really want the error message, regular asserts are a bit uglier
>> and duplicate code.
> 
> The whole point of my proposal is to make the regular asserts print a
> message similar to yours *by default*, when you don't specify any
> message. This is possible because assert is not a function, it's a
> language construct handled by the compiler. The compiler has access to
> the whole expression tree, and it can rewrite the code to store
> intermediate results in variables it can later give to the assertion
> handler in case of failure.
> 
> 

I understood, but was reacting to the proposition that assertPred is not an 
improvement over the current situation, isn't that what you were saying? 
Just being pragmatic, it's unlikely such big changes to assert are going to 
land in dmd anytime soon. But if they are, yeah that would be cool. 

Re: Dynamic D

[Adam Ruppe]

Robert Jacques wrote:
> I've been working on an update to both std.json and std.variant.

Yes, I remember looking at it before. Both look outstanding, but
I haven't actually used them yet so the improvements haven't quite
sunk into my brain.

I think the differentiating point here is mainly that I'm just playing
around, so the general quality will be lower, and I want to try to make
a weakly typed object work with the rest of D, just to see how far
that can be pushed.

Re: std.unittests for (final?) review

[Michel Fortin]

On 2011-01-06 08:44:33 -0500, Lutger Blijdestijn 
 said:



Michel Fortin wrote:


The whole point of my proposal is to make the regular asserts print a
message similar to yours *by default*, when you don't specify any
message. This is possible because assert is not a function, it's a
language construct handled by the compiler. The compiler has access to
the whole expression tree, and it can rewrite the code to store
intermediate results in variables it can later give to the assertion
handler in case of failure.


I understood, but was reacting to the proposition that assertPred is not an
improvement over the current situation, isn't that what you were saying?
Just being pragmatic, it's unlikely such big changes to assert are going to
land in dmd anytime soon. But if they are, yeah that would be cool.


assertPred is an improvement for error messages but it's not without a 
price. Basically you trade the very straightforward assertion syntax 
for a more verbose and less intuitive syntax. My argument is that this 
is an unnecessary tradeoff since we can just "fix" assert instead.


I think the consensus is that 'assert' can and should give us better 
error messages, but that assertPred is a good stopgap solution for most 
cases.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Moving to D

[Jacob Carlborg]

On 2011-01-06 07:28, Walter Bright wrote:

Nick Sabalausky wrote:

Automatically accepting all submissions immediately into the main line
with no review isn't a good thing either. In that article he's
complaining about MS, but MS is notorious for ignoring all non-MS
input, period. D's already light-years ahead of that. Since D's purely
volunteer effort, and with a lot of things to be done, sometimes
things *are* going to tale a while to get in. But there's just no way
around that without major risks to quality. And yea Walter could grant
main-line DMD commit access to others, but then we'd be left with a
situation where no single lead dev understands the whole program
inside and out - and when that happens to projects, that's inevitably
the point where it starts to go downhill.


That's pretty much what I'm afraid of, losing my grip on how the whole
thing works if there are multiple dmd committers.


That is very understandable.

Maybe we can have a look at the linux kernel development process: 
http://ldn.linuxfoundation.org/book/how-participate-linux-community


As how I understands it, Linus Torvalds day to day work on the linux 
kerenl mostly consist of merging changes made in developer branches into 
the main branch.



On the bright (!) side, Brad Roberts has gotten the test suite in shape
so that anyone developing a patch can run it through the full test
suite, which is a prerequisite to getting it folded in.


Has this been announced (somewhere else than the DMD mailing list)? 
Where can one get the test suite? It should be available and easy to 
find and with instructions how to run it. Somewhere on the Digitalmars 
site or/and perhaps released with the DMD source code?



In the last release, most of the patches in the changelog were done by
people other than myself, although yes, I vet and double check them all
before committing them.



--
/Jacob Carlborg

Re: std.unittests for (final?) review

[Andrei Alexandrescu]

On 1/5/11 8:54 PM, Ary Borenszweig wrote:

I prefer assert, assertFalse, assertEqual and assertNotEqual.

Compare this:
assertPredicate!"a<  b"(1 + 1, 3);

To this:
assert(1 + 1<  3)

Or to this:

assertLess(1 + 1, 3)

Ok, the first one is more generic. But so the error message for the assertion 
failure will be more generic, when you want exactly the opposite to happen.
Plus your brain has to think more to read it (starting from the point that it's 
longer).

assertPredicate!"<"(1 + 1, 3) reminds me of polish notation, which is very good 
for machines but not very good for humans.


One problem with using distinct names is the explosion thereof. Google 
unittests have EXPECT_EQ, EXPECT_NE, EXPECT_LT, EXPECT_GT, EXPECT_LE, 
EXPECT_GE, EXPECT_TRUE, EXPECT_FALSE and probably others. I was able to 
write these from memory because I used to know Fortran, which uses the 
same two-letter conventions for comparisons. At that point I think we 
can say, wait a minute, why not use the respective symbols which are 
impossible to forget?



Andrei

Re: std.unittests for (final?) review

[Andrei Alexandrescu]

On 1/5/11 9:35 PM, Michel Fortin wrote:

I'm not sold on the concept. The whole point of this module seems to
offer a way to replace the built-in assertion mechanism with a
customized one, with the sole purpose of giving better error messages.
So we're basically encouraging the use of:

assertPredicate!"a > b"(a, b, "message");

instead of:

assert(a > b, "message");

It looks like an uglification of the language to me.

I agree that getting better error messages is important (very important
in fact), but keeping the code clean is important too. If the built-in
assert doesn't give us good enough error messages, perhaps it's the
built-in assert that should be improved. The compiler could give the
values on both side of the operator to the assertion handler, which
would in turn print values and operator as part of the error message.

So to me this module is a temporary fix until the compiler is capable of
giving the necessary information to the assertion handler. I sure hope
it won't be needed for too long.

(Note: this criticism doesn't apply to those assertions dealing with
exceptions.)


I think this is a valid improvement that can be brought to the language, 
but we're at a point in D's history where we should ask ourselves how we 
can get stuff done in the existing language instead of how we can change 
the language to make stuff easier to get done.


Andrei

Re: Moving to D

[Don]

Walter Bright wrote:

Nick Sabalausky wrote:
"Caligo"  wrote in message 
news:mailman.451.1294306555.4748.digitalmar...@puremagic.com...

On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
wrote:


That's pretty much what I'm afraid of, losing my grip on how the whole
thing works if there are multiple dmd committers.

Perhaps using a modern SCM like Git might help?  Everyone could have 
(and
should have) commit rights, and they would send pull requests.  You 
or one
of the managers would then review the changes and pull and merge with 
the
main branch.  It works great; just checkout out Rubinius on Github to 
see

what I mean: https://github.com/evanphx/rubinius



I'm not sure I see how that's any different from everyone having 
"create and submit a patch" rights, and then having Walter or one of 
the managers review the changes and merge/patch with the main branch.


I don't, either.


There's no difference if you're only making one patch, but once you make 
more, there's a significant difference. I can generally manage to fix 
about five bugs at once, before they start to interfere with each other. 
After that, I have to wait for some of the bugs to be integrated into 
the trunk, or else start discarding changes from my working copy.


Occasionally I also use my own DMD local repository, but it doesn't work 
very well (gets out of sync with the trunk too easily, because SVN isn't 
 really set up for that development model).


I think that we should probably move to Mercurial eventually. I think 
there's potential for two benefits:

(1) quicker for you to merge changes in;
(2) increased collaboration between patchers.

But due to the pain in changing the developement model, I don't think 
it's a change we should make in the near term.

Re: Dynamic D

[Andrei Alexandrescu]

On 1/6/11 1:22 AM, Robert Jacques wrote:

On Mon, 03 Jan 2011 17:23:29 -0500, Adam Ruppe
 wrote:

Over the weekend, I attacked opDispatch again and found some old
Variant bugs were killed. I talked about that in the Who uses D
thread.

Today, I couldn't resist revisiting a dynamic kind of object, and
made some decent progress on it.

http://arsdnet.net/dcode/dynamic.d

(You can compile that; there's a main() at the bottom of that file)

It isn't quite done - still needs op overloading, and probably better
errors, but it basically works.

It works sort of like a Javascript object.


[snip]

I've been working on an update to both std.json and std.variant.
Previews of both are available here:
https://jshare.johnshopkins.edu/rjacque2/public_html/
though they are still works in progress. Two of the big enhancements
that you might be interested in are call support and opDispatch +
reflection + prototype structs. To paraphrase your example:

Variant v;
v.a( 10 );
assert(v.a == 10);
v.a( { writefln("hello, world"); } );
v.a.call; //To be replaced by opCall, once struct opCall is fixed (Bug
4053)
v.a( delegate void(string a, int x) { foreach(i;0..x) writeln(i+1,"
",a); } );
v.a("potatoes", 3);

I've also stubbed out a prototype style object, but I haven't really
tested it yet. Thoughts, comments and use/test cases are always welcomed.


I think this transgresses the charter of Variant. Variant is meant to 
hold an object of some _preexisting_ type, not to morph into anything. 
We should have three abstractions:


* Algebraic holds any of a closed set of types. It should define method 
calls like a.fun(args) if and only if all of its possible types support 
the call with compatible arguments and return types.


* Variant holds any of an unbounded set of types. Reflection may allow 
us to define v.fun(args) to look up the method name dynamically and 
issue a runtime error if it doesn't exist (sort of what happens now with 
operators).


* Dynamic is a malleable type that you get to add state and methods to, 
just like in Javascript.



Andrei

Re: std.unittests for (final?) review

[Michel Fortin]

On 2011-01-06 10:10:46 -0500, Andrei Alexandrescu 
 said:



On 1/5/11 9:35 PM, Michel Fortin wrote:

I'm not sold on the concept. The whole point of this module seems to
offer a way to replace the built-in assertion mechanism with a
customized one, with the sole purpose of giving better error messages.
So we're basically encouraging the use of:

assertPredicate!"a > b"(a, b, "message");

instead of:

assert(a > b, "message");

It looks like an uglification of the language to me.

I agree that getting better error messages is important (very important
in fact), but keeping the code clean is important too. If the built-in
assert doesn't give us good enough error messages, perhaps it's the
built-in assert that should be improved. The compiler could give the
values on both side of the operator to the assertion handler, which
would in turn print values and operator as part of the error message.

So to me this module is a temporary fix until the compiler is capable of
giving the necessary information to the assertion handler. I sure hope
it won't be needed for too long.

(Note: this criticism doesn't apply to those assertions dealing with
exceptions.)


I think this is a valid improvement that can be brought to the 
language, but we're at a point in D's history where we should ask 
ourselves how we can get stuff done in the existing language instead of 
how we can change the language to make stuff easier to get done.


It's not a language change. The language doesn't mandate any particular 
error message for assertions. It's a quality of implementation issue.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: std.unittests for (final?) review

[Andrei Alexandrescu]

On 1/6/11 3:57 AM, bearophile wrote:

Andrei:


One more thing. Since assert() is available and useful outside
unittests, I don't see a reason for which assertPred and friends should
only be available during unittesting. I can sure use them in regular code.


I guess assertPred creates statistics to be printed at the end of the 
unittests? I don't think mixing the two groups of things is good.


Oh, and if assertXxxx doesn't do what assert does (throw an error in 
case things go wrong) it should not be called such. Call it expectXxx.


Andrei

Re: std.unittests for (final?) review

[Andrei Alexandrescu]

On 1/6/11 3:57 AM, bearophile wrote:

Andrei:


One more thing. Since assert() is available and useful outside
unittests, I don't see a reason for which assertPred and friends should
only be available during unittesting. I can sure use them in regular code.


I guess assertPred creates statistics to be printed at the end of the 
unittests? I don't think mixing the two groups of things is good.


The printed stats could be wrapped in version(unittest).

Andrei

Re: Moving to D

[Andrei Alexandrescu]

On 1/6/11 9:18 AM, Don wrote:

Walter Bright wrote:

Nick Sabalausky wrote:

"Caligo"  wrote in message
news:mailman.451.1294306555.4748.digitalmar...@puremagic.com...

On Thu, Jan 6, 2011 at 12:28 AM, Walter Bright
wrote:


That's pretty much what I'm afraid of, losing my grip on how the whole
thing works if there are multiple dmd committers.

Perhaps using a modern SCM like Git might help? Everyone could have
(and

should have) commit rights, and they would send pull requests. You
or one
of the managers would then review the changes and pull and merge
with the
main branch. It works great; just checkout out Rubinius on Github to
see
what I mean: https://github.com/evanphx/rubinius



I'm not sure I see how that's any different from everyone having
"create and submit a patch" rights, and then having Walter or one of
the managers review the changes and merge/patch with the main branch.


I don't, either.


There's no difference if you're only making one patch, but once you make
more, there's a significant difference. I can generally manage to fix
about five bugs at once, before they start to interfere with each other.
After that, I have to wait for some of the bugs to be integrated into
the trunk, or else start discarding changes from my working copy.

Occasionally I also use my own DMD local repository, but it doesn't work
very well (gets out of sync with the trunk too easily, because SVN isn't
really set up for that development model).

I think that we should probably move to Mercurial eventually. I think
there's potential for two benefits:
(1) quicker for you to merge changes in;
(2) increased collaboration between patchers.

But due to the pain in changing the developement model, I don't think
it's a change we should make in the near term.


What are the advantages of Mercurial over git? (git does allow multiple 
branches.)


Andrei

Re: RFC: SI Units facility for Phobos

[Andrei Alexandrescu]

On 1/5/11 9:55 PM, BCS wrote:

After a little more thinking I'm wondering if I'm targeting a
different use case than other people are thinking about.

The case I'm designing for, is where you have a relatively small
number of inputs (that may be in a mishmash of units and systems), a
relatively large number of computations and a relatively small number
of outputs. The systems that Andrei is arguing for may be more
desirable if there are relatively less computation (thus less
internal rounding) or if all or most of the inputs are in a
consistent system of units (resulting in very few necessary
conversions).

I'm primarily interested in the first use case because it is the kind
of problem I have dealt with the most (particularly the mishmash of
units bit) and for that, the two proposals are almost equivalent from
a perf and accuracy standpoint because each should convert the inputs
to a consistent system, do all the math in it, and then convert to
the output units (I'm not even assuming the outputs form a consistent
system). The only difference is that the current arrangement picks
the consistent system for you where the alternative allows (and
forces) you to select it.


I think this all is sensible. What I like about Boost units is that they 
didn't define SI units; they defined a framework in which units can be 
defined (and indeed "si" is a sub-namespace inside units that has no 
special rights).


This review conclusion is a very good read:

http://lists.boost.org/boost-announce/2007/04/0126.php

I recommend to all to read the entire review thread to get an idea of 
the scope and sophistication of the Boost review process. It has 
tremendously increased the quality of Boost libraries. We need to get there.



Andrei

Re: std.unittests for (final?) review

[Jonathan M Davis]

On Thursday 06 January 2011 05:30:56 Michel Fortin wrote:
> There's an other issue that's bothering me with these assertion
> functions... with 'assert', assertions behaves differently depending on
> where you write them. In regular code, on failure it calls _d_assert*,
> in a unit test on failure it calls _d_unittest*, and in contracts for
> virtual function... well that case I don't understand it fully but it
> does something very special to implement contract inheritance.
> 
> What does assertPred do? It does "throw new AssertError(...)",
> irrespective of the context. I'm pretty sure that'll break contract
> inheritance if used inside a contract. To be truly a replacement for
> assert, assertPred would need to know in which context it is called and
> generate the appropriate code, although I somewhat doubt it is even
> possible to generate the right code for contracts without the compiler
> doing it.

I don't know anything about this. As far as I know, there's no difference 
between 
assert in unittest blocks and assert in contracts. That being said, you're 
probably more knowledgeable than I am about that.

I would have thought was that all it would take would be for the AssertError to 
be handled appropriately by whatever catches it. In the case of contracts, I 
would think that it's an issue of the right contract code being called in the 
right order, and that which contract threw the test would be irrelevant (the 
stack track would show where it was; all that matters from the runtime's 
perspective is that there _was_ an AssertError thrown and that execution is 
therefore going to be stopping).

As for unittest blocks, I thought that it caught the AssertError from the 
unittest block and dealt with it. If it does that, then I don't see why it 
would 
need a special version of assert. I know that it _used_ to be different, 
because 
Walter temporarily made it so that within unittest blocks assert set a flag 
saying that the test failed and printed the error rather than throwing an 
AssertError, but Andrei and others complained about that (both that assert 
would 
have different behavior in different places and that a unittest block would 
continue after a failure), and it was agreed that assert would throw an 
AssertError like it normally does.

So, I don't know if assert does something different depending on where it is 
called. The only special case for assert that I'm aware of is assert(0), which 
becomes the halt instruction with -release rather than going away. If there is 
a 
difference, then we probably need to understand what it is and what issues it 
could cause. Ideally, there wouldn't be any difference.

However, I _have_ been using these functions in unit tests, and they work fine 
there. So, as far as unit testing goes, they work. I have _not_ been using them 
in contracts. I created them specifically with unit testing in mind (and in 
fact, 
with the current code, the entire module is in a version(unittest) block). It 
sounds like there are some folks (including Andrei) who think that it should be 
useable in normal contracts just like assert is. That's simple to fix by 
removing 
the version(unittest) block, but I don't know if there are any issues with 
throwing an AssertError from a function called within a contract rather than 
asserting directly inside a contract. If there is, I would think that that's a 
more general problem. I've been doing that all the time with invariants (just 
not with any of my unit testing functions), and that's worked as far as I can 
tell, but I've been using structs primarily, which wouldn't have contract 
inheritance. So, I think that assert should _definitely_ work normally when 
called from a function called from a contract rather than when used directly in 
a contract, but I don't know that that never causes problems. We need someone 
who actually knows what assert does in each case to say whether there's an 
issue, I think.

- Jonathan M Davis

Re: Moving to D

[bioinfornatics]

i have used svn, cvs a little, mercurial and git and i prefer git for me is 
better way
Very powerfull for managing branch and do merge. Chery pick is too very 
powerfull.
And yes git allow multi branch

Templates vs CTFE

[Max Samukha]

Some of us who have the knack of writing metaprograms in D know that 
many algorithms can be implemented with both recursive templates and 
CTFE. A simple example is map:


Recursive template instantiation:

template staticMap(alias pred, A...)
{
static if (A.length)
alias TypeTuple!(pred!(A[0]), staticMap!(A[1..$])) staticMap;
}

CTFE:

template staticMap(alias pred, A)
{
mixin("alias TypeTuple!(" ~ _staticMap(A.length) ~ ") staticMap;");
}

private string _staticMap(size_t len)
{
string result;
if (len)
{
result ~= "pred!(A[0])";
for(size_t i = 1, i < len; ++i)
{
result ~= ", pred!(A[" ~ to!string(i) ~ "])";
}
}
return result;
}

It is not easy to decide which approach to implement in a library 
because both have drawbacks.


Can anybody give informed advice as to which one is preferable in 
practice? Or should a library provide both?

Re: Templates vs CTFE

[Max Samukha]

On 01/06/2011 07:49 PM, Max Samukha wrote:

template staticMap(alias pred, A...)
{
static if (A.length)
alias TypeTuple!(pred!(A[0]), staticMap!(A[1..$])) staticMap;
}



Should be:

template staticMap(alias pred, A...)
{
static if (A.length)
alias TypeTuple!(pred!(A[0]), staticMap!(A[1..$])) staticMap;
else
alias TypeTuple!() staticMap;
}

Re: Dynamic D

[Robert Jacques]

On Thu, 06 Jan 2011 10:35:07 -0500, Andrei Alexandrescu  
 wrote:

On 1/6/11 1:22 AM, Robert Jacques wrote:

On Mon, 03 Jan 2011 17:23:29 -0500, Adam Ruppe
 wrote:

Over the weekend, I attacked opDispatch again and found some old
Variant bugs were killed. I talked about that in the Who uses D
thread.

Today, I couldn't resist revisiting a dynamic kind of object, and
made some decent progress on it.

http://arsdnet.net/dcode/dynamic.d

(You can compile that; there's a main() at the bottom of that file)

It isn't quite done - still needs op overloading, and probably better
errors, but it basically works.

It works sort of like a Javascript object.


[snip]

I've been working on an update to both std.json and std.variant.
Previews of both are available here:
https://jshare.johnshopkins.edu/rjacque2/public_html/
though they are still works in progress. Two of the big enhancements
that you might be interested in are call support and opDispatch +
reflection + prototype structs. To paraphrase your example:

Variant v;
v.a( 10 );
assert(v.a == 10);
v.a( { writefln("hello, world"); } );
v.a.call; //To be replaced by opCall, once struct opCall is fixed (Bug
4053)
v.a( delegate void(string a, int x) { foreach(i;0..x) writeln(i+1,"
",a); } );
v.a("potatoes", 3);

I've also stubbed out a prototype style object, but I haven't really
tested it yet. Thoughts, comments and use/test cases are always  
welcomed.


I think this transgresses the charter of Variant. Variant is meant to  
hold an object of some _preexisting_ type, not to morph into anything.  
We should have three abstractions:


And Variant still only holds an object of some preexisting type. What you  
are seeing is simply syntactic sugar for a Variant of type  
Variant[string]. The above lowers down into:


Variant v;
Variant[string] __temp;
v = __temp;
v["a"] = 10;
assert(v["a"] == 10);
v["a"] = { writefln("hello, world"); };
v["a"].call();
v["a"] = delegate void(string a, int x) { foreach(i;0..x) writeln(i+1,"  
",a); };

v["a"].call("potatoes", 3);

The only morph happens because actually making the Variant default type be  
Variant[string], has some issues (GC interaction, hasValue,  
Variant[string].init isn't usable, etc). So I decided that if and only if  
you used an uninitialized Variant as a Variant[string], it would 'morph'  
to a Variant[string].


As for the v.a -> v["a"] syntactic sugar, I have found it very useful in  
the parsing/use of dynamically structured structs, including JSON.


* Algebraic holds any of a closed set of types. It should define method  
calls like a.fun(args) if and only if all of its possible types support  
the call with compatible arguments and return types.


I have considered this, but while this concept looks good on paper, in  
practice it cripples Algebraic. The issue is that the intersections of  
types tend to have no methods/operators in common. For example,  
Algebraic!(int,string) would have no methods nor operators defined.


* Variant holds any of an unbounded set of types. Reflection may allow  
us to define v.fun(args) to look up the method name dynamically and  
issue a runtime error if it doesn't exist (sort of what happens now with  
operators).


It's not 'may' anymore. Reflection _does_ allow me to define v.fun(args)  
to look up the method name dynamically and issue a runtime error if it  
doesn't exist. eg:


class Foo { real x = 5; }
auto foo = new Foo;
Variant a = foo;
assert(a.x == 5); // perform runtime reflection on 'a'  
implicitly

a.__reflect("x",Variant(10)); // or explicitly
assert(a.__reflect("x") == 10);   

* Dynamic is a malleable type that you get to add state and methods to,  
just like in Javascript.


And I have stubbed out a Prototype object for just this reason.

Re: Templates vs CTFE

[Robert Jacques]

On Thu, 06 Jan 2011 12:49:19 -0500, Max Samukha   
wrote:


Some of us who have the knack of writing metaprograms in D know that  
many algorithms can be implemented with both recursive templates and  
CTFE. A simple example is map:


Recursive template instantiation:

template staticMap(alias pred, A...)
{
 static if (A.length)
 alias TypeTuple!(pred!(A[0]), staticMap!(A[1..$])) staticMap;
}

CTFE:

template staticMap(alias pred, A)
{
 mixin("alias TypeTuple!(" ~ _staticMap(A.length) ~ ") staticMap;");
}

private string _staticMap(size_t len)
{
 string result;
 if (len)
 {
 result ~= "pred!(A[0])";
 for(size_t i = 1, i < len; ++i)
 {
 result ~= ", pred!(A[" ~ to!string(i) ~ "])";
 }
 }
 return result;
}

It is not easy to decide which approach to implement in a library  
because both have drawbacks.


Can anybody give informed advice as to which one is preferable in  
practice? Or should a library provide both?


CTFE is generally easier to write/understand and more generic than doing  
the same thing in templates. However, there are some serious flaws in how  
DMD currently handles CT strings (and arrays in general) which can lead  
extremely complex CTFE code to be incorrect, very slow to compile or crash  
DMD outright. For example, I initially implemented a compile-time  
reflection to runtime-time reflection system for an improved std.variant  
using CTFE, but had to switch to templates/conditional compilation  
instead.  (see https://jshare.johnshopkins.edu/rjacque2/public_html/) See  
bug 1382 (http://d.puremagic.com/issues/show_bug.cgi?id=1382).

Re: Dynamic D

[Andrei Alexandrescu]

On 1/6/11 11:52 AM, Robert Jacques wrote:

And Variant still only holds an object of some preexisting type. What
you are seeing is simply syntactic sugar for a Variant of type
Variant[string]. The above lowers down into:

Variant v;
Variant[string] __temp;
v = __temp;
v["a"] = 10;
assert(v["a"] == 10);
v["a"] = { writefln("hello, world"); };
v["a"].call();
v["a"] = delegate void(string a, int x) { foreach(i;0..x) writeln(i+1,"
",a); };
v["a"].call("potatoes", 3);

The only morph happens because actually making the Variant default type
be Variant[string], has some issues (GC interaction, hasValue,
Variant[string].init isn't usable, etc). So I decided that if and only
if you used an uninitialized Variant as a Variant[string], it would
'morph' to a Variant[string].


I think Variant should default to holding "void".


As for the v.a -> v["a"] syntactic sugar, I have found it very useful in
the parsing/use of dynamically structured structs, including JSON.


That's great, but (a) that's again outside what Variant is supposed to 
do, and (b) for JSON we're dealing with a closed hierarchy which 
suggests a different design.



* Algebraic holds any of a closed set of types. It should define
method calls like a.fun(args) if and only if all of its possible types
support the call with compatible arguments and return types.


I have considered this, but while this concept looks good on paper, in
practice it cripples Algebraic. The issue is that the intersections of
types tend to have no methods/operators in common. For example,
Algebraic!(int,string) would have no methods nor operators defined.


Algebraic with the fundamental JSON types is a great example because 
they all may share certain methods. Generally Algebraic with closed 
hierarchies (e.g. Visitor) are good candidates for the feature. Of 
course, if that feature affects other functionality we should avoid it. 
It's just "nice to have".



* Variant holds any of an unbounded set of types. Reflection may allow
us to define v.fun(args) to look up the method name dynamically and
issue a runtime error if it doesn't exist (sort of what happens now
with operators).


It's not 'may' anymore. Reflection _does_ allow me to define v.fun(args)
to look up the method name dynamically and issue a runtime error if it
doesn't exist. eg:

class Foo { real x = 5; }
auto foo = new Foo;
Variant a = foo;
assert(a.x == 5); // perform runtime reflection on 'a' implicitly
a.__reflect("x",Variant(10)); // or explicitly
assert(a.__reflect("x") == 10);


* Dynamic is a malleable type that you get to add state and methods
to, just like in Javascript.


And I have stubbed out a Prototype object for just this reason.


Great. Why not call it "Dynamic"?


Andrei

Re: Moving to D

[Jesse Phillips]

Walter Bright Wrote:

> > I'm not sure I see how that's any different from everyone having "create 
> > and 
> > submit a patch" rights, and then having Walter or one of the managers 
> > review 
> > the changes and merge/patch with the main branch.
> 
> I don't, either.

I actually founds some D repositories at github, not really up-to-date:

https://github.com/d-lang
https://github.com/braddr/dmd

Don't know who d-lang is, but they probably should have added some code. And it 
would be better if Walter was managing it...

There are many benefits to the coder for using a distributed CMS. And you can 
use git with SVN, but may run into other issues as pointed out by Don.

Now, if you add github or another social repository site, what you have is the 
ability for anyone to public display their patches, merge in other's patches, 
or demonstrate new features (tail const objects) which has a visible connection 
to the main branch.

Then on top of that patches are submitted as a pull request:

http://help.github.com/pull-requests/

Which provides review of the changes, public visibility into the current 
requests against the main branch.

The benefit to Walter or even the patch writer would not be great, but it 
provides a lot of visibility to the observer. And using this model still allows 
Walter control over every patch that comes into the main branch. But it will 
make it 20x easier for those that want to build their own to roll in all 
available patches. (aren't numbers with no data to back them great).

But the simplicity of branching for a distributed CMS definitely makes using 
them much nicer than SVN.

Re: Meaning of .clear() for containers

[Jérôme M. Berger]

Steven Schveighoffer wrote:
> I don't expect this to be a huge problem.  Will people who more likely
> destroy an object with:
> 
> clear(obj);
> 
> or
> 
> obj.clear();
> 
> ?  To me, the first looks like you are doing an operation to the object,
> where the second looks like you are having the object do an operation.
> 
> UFC is going to cause lots of these little corner cases.  Another I can
> think of is global properties.  with @property foo(int x), do you call
> this as foo = 1; or 1.foo?
> 
I believe this becomes a problem when you have *both* a free
standing function (to destroy the container) and a method (to empty
it). And yes, this will crop up a lot with UFC.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: Templates vs CTFE

[Jonathan M Davis]

On Thursday, January 06, 2011 09:49:19 Max Samukha wrote:
> Some of us who have the knack of writing metaprograms in D know that
> many algorithms can be implemented with both recursive templates and
> CTFE. A simple example is map:
> 
> Recursive template instantiation:
> 
> template staticMap(alias pred, A...)
> {
>  static if (A.length)
>  alias TypeTuple!(pred!(A[0]), staticMap!(A[1..$])) staticMap;
> }
> 
> CTFE:
> 
> template staticMap(alias pred, A)
> {
>  mixin("alias TypeTuple!(" ~ _staticMap(A.length) ~ ") staticMap;");
> }
> 
> private string _staticMap(size_t len)
> {
>  string result;
>  if (len)
>  {
>  result ~= "pred!(A[0])";
>  for(size_t i = 1, i < len; ++i)
>  {
>  result ~= ", pred!(A[" ~ to!string(i) ~ "])";
>  }
>  }
>  return result;
> }
> 
> It is not easy to decide which approach to implement in a library
> because both have drawbacks.
> 
> Can anybody give informed advice as to which one is preferable in
> practice? Or should a library provide both?

I suppose that in theory, I would say to use templates for things that really 
are intended to always be used at compile time and CTFE for functions which 
would make sense both for compile time and runtime. But whether that's actually 
the best practice (particularly given the current state of dmd and CTFE), I 
don't know.

Personally, I think what generally happens in that when I'm trying to do 
something which needs to be done at compile time, I use CTFE if a function 
already exists which will do what I want, and I use a template if it doesn't. 
Or 
if it's something that I know that I need to be used both at compile time and 
runtime, then I make it a function for use with CTFE. I think that in at least 
one case, I've created a template for use at compile time and a function for 
use 
at runtime so that I could have additional checks or different behavior at 
runtime (I think that I had it throw an exception at runtime, which you can't 
do 
at compile time), but that's not the norm.

I don't know. I've rarely sat down and tried to decide whether something should 
be a template or a CTFE-able function. I think that it most cases I've either 
been creating a function for runtime and possible used it also at compile time, 
or I've needed something at compile time, so I've created a template.

- Jonathan M Davis

Re: Meaning of .clear() for containers

[Jonathan M Davis]

On Thursday, January 06, 2011 10:47:11 Jérôme M. Berger wrote:
> Steven Schveighoffer wrote:
> > I don't expect this to be a huge problem.  Will people who more likely
> > destroy an object with:
> > 
> > clear(obj);
> > 
> > or
> > 
> > obj.clear();
> > 
> > ?  To me, the first looks like you are doing an operation to the object,
> > where the second looks like you are having the object do an operation.
> > 
> > UFC is going to cause lots of these little corner cases.  Another I can
> > think of is global properties.  with @property foo(int x), do you call
> > this as foo = 1; or 1.foo?
> 
>   I believe this becomes a problem when you have *both* a free
> standing function (to destroy the container) and a method (to empty
> it). And yes, this will crop up a lot with UFC.

Yes. It would almost certainly have to make it so that the compiler used a 
member function when there was a choice between a member function and a free-
standing function and overloading does not make it clear which to use. 
Unfortunately, that would mean that which function would be called could change 
when a member function was added or removed, but I don't see any way around 
that. Still, much as clear is a good name for both the free-standing function 
and the member function. Perhaps one of them should be changed, regardless of 
the state of UFC.

In theory, we're going to get UFC at some point, but this sort of issue may 
make 
it unreasonable to implement. We'll just have to wait and see until it's 
actually implemented, I suppose.

- Jonathan M Davis

Re: Moving to D

[Jesse Phillips]

Russel Winder Wrote:

> Whilst I concur (massively) that Subversion is no longer the correct
> tool for collaborative working, especially on FOSS projects, but also
> for proprietary ones, I am not sure Git is the best choice of tool.
> Whilst Git appears to have the zeitgeist, Mercurial and Bazaar are
> actually much easier to work with.  Where Git has GitHub, Mercurial has
> BitBucket, and Bazaar has Launchpad.

First I think one must be convinced to move. Then that using a social site adds 
even more. Then we can discuss which one to use.

My personal choice is git because I don't use the others. And this was a great 
read:

http://progit.org/book/

Re: Moving to D

[Jérôme M. Berger]

Andrei Alexandrescu wrote:
> What are the advantages of Mercurial over git? (git does allow multiple
> branches.)
> 

Here's a comparison. Although I am partial to Mercurial, I have
tried to be fair. Some of the points are in favor of Mercurial, some
in favor of Git, and some are simply differences I noted (six of
one, half a dozen of the other):
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=91657

An extra point I did not raise at the time: Git is deliberately
engineered to be as different from CVS/SVN as possible (quoting
Wikipedia: "Take CVS as an example of what /not/ to do; if in doubt,
make the exact opposite decision"). IMO this makes it a poor choice
when migrating from SVN. Mercurial (or Bazaar) would be much more
comfortable.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: std.unittests for (final?) review

[Michel Fortin]

On 2011-01-06 11:34:48 -0500, Jonathan M Davis  said:


On Thursday 06 January 2011 05:30:56 Michel Fortin wrote:

There's an other issue that's bothering me with these assertion
functions... with 'assert', assertions behaves differently depending on
where you write them. In regular code, on failure it calls _d_assert*,
in a unit test on failure it calls _d_unittest*, and in contracts for
virtual function... well that case I don't understand it fully but it
does something very special to implement contract inheritance.

What does assertPred do? It does "throw new AssertError(...)",
irrespective of the context. I'm pretty sure that'll break contract
inheritance if used inside a contract. To be truly a replacement for
assert, assertPred would need to know in which context it is called and
generate the appropriate code, although I somewhat doubt it is even
possible to generate the right code for contracts without the compiler
doing it.


I don't know anything about this. As far as I know, there's no 
difference between

assert in unittest blocks and assert in contracts. That being said, you're
probably more knowledgeable than I am about that.

I would have thought was that all it would take would be for the AssertError to
be handled appropriately by whatever catches it. In the case of contracts, I
would think that it's an issue of the right contract code being called in the
right order, and that which contract threw the test would be irrelevant (the
stack track would show where it was; all that matters from the runtime's
perspective is that there _was_ an AssertError thrown and that execution is
therefore going to be stopping).


The thing is that for 'in' contracts you need to have *one* contract 
work in the inheritance chain. So if a contract fails it should just 
check the inherited contract, and if it fails it continues like that. 
If all the inherited contract fails then only then you must throw. I'm 
not sure exactly how DMD generates the code, but I'm pretty sure it 
doesn't throw then catch then throw then catch until it reaches the 
last inherited contract (that'd be unacceptably slow), so if you do 
throw in the contract then you're probably breaking how it works.


That said, I'm pretty sure this only apply to 'in' contracts. Other 
contracts don't exhibit this all-must-fail-to-fail behaviour.


Here's a test case:

class A {
// accepts i == 0
void fun(int i)
in { assert(i == 0); }
body {}
}
class B : A {
// accepts i == 0 || i == 1
override void fun(int i)
in { assert(i == 1); }
body {}
}

B b = new B;
b.fun(1);
b.fun(0);
b.fun(-1); // only this one breaks the contract



As for unittest blocks, I thought that it caught the AssertError from the
unittest block and dealt with it. If it does that, then I don't see why 
it would
need a special version of assert. I know that it _used_ to be 
different, because

Walter temporarily made it so that within unittest blocks assert set a flag
saying that the test failed and printed the error rather than throwing an
AssertError, but Andrei and others complained about that (both that 
assert would

have different behavior in different places and that a unittest block would
continue after a failure), and it was agreed that assert would throw an
AssertError like it normally does.


The code it generates is different: it calls different assertion 
failure handler in the runtime (_d_assert and derivatives vs. 
_d_unittest and derivatives). But druntime was later changed so that 
both handlers do the same thing (except for different default error 
messages). As long as druntime makes them do the same thing, there 
won't be a problem.


Should there be a difference between the two? This difference could be 
used to distinguish failed tests from failed assertions in function the 
test is calling, but I'm not too sure how useful that'd be.




So, I don't know if assert does something different depending on where it is
called. The only special case for assert that I'm aware of is assert(0), which
becomes the halt instruction with -release rather than going away. If 
there is a

difference, then we probably need to understand what it is and what issues it
could cause. Ideally, there wouldn't be any difference.


assert(0) is one special case, assert(object) is another -- it calls 
the object's invariant. The rest is undocumented as far as I know.




However, I _have_ been using these functions in unit tests, and they work fine
there. So, as far as unit testing goes, they work. I have _not_ been using them
in contracts. I created them specifically with unit testing in mind 
(and in fact,

with the current code, the entire module is in a version(unittest) block). It
sounds like there are some folks (including Andrei) who think that it should be
useable in normal contracts just lik

Re: Templates vs CTFE

[Robert Clipsham]

On 06/01/11 17:49, Max Samukha wrote:

Some of us who have the knack of writing metaprograms in D know that
many algorithms can be implemented with both recursive templates and
CTFE. A simple example is map:

Recursive template instantiation:

template staticMap(alias pred, A...)
{
static if (A.length)
alias TypeTuple!(pred!(A[0]), staticMap!(A[1..$])) staticMap;
}

CTFE:

template staticMap(alias pred, A)
{
mixin("alias TypeTuple!(" ~ _staticMap(A.length) ~ ") staticMap;");
}

private string _staticMap(size_t len)
{
string result;
if (len)
{
result ~= "pred!(A[0])";
for(size_t i = 1, i < len; ++i)
{
result ~= ", pred!(A[" ~ to!string(i) ~ "])";
}
}
return result;
}

It is not easy to decide which approach to implement in a library
because both have drawbacks.

Can anybody give informed advice as to which one is preferable in
practice? Or should a library provide both?


Put each of those implementations in its own file, then call it several 
times. Look at the binary size for each implementation, also run 
`strings ctfeTest` if you're on a *nix. This should give you your answer :)


--
Robert
http://octarineparrot.com/

Patterns of Bugs

[Walter Bright]

http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html

(dedicated to bearophile!)

Anyone want to post it on reddit?

Re: Moving to D

[Walter Bright]

Russel Winder wrote:

Pity, because using one of Mercurial, Bazaar or Git instead of
Subversion is likely the best and fastest way of getting more quality
contributions to review.  Although only anecdotal in every case where a
team has switched to DVCS from CVCS -- except in the case of closed
projects, obviously -- it has opened things up to far more people to
provide contributions.  Subversion is probably now the single biggest
barrier to getting input on system evolution.



A couple months back, I did propose moving to git on the dmd internals mailing 
list, and nobody was interested.


One thing I like a lot about svn is this:

http://www.dsource.org/projects/dmd/changeset/291

where the web view will highlight the revision's changes. Does git or mercurial 
do that? The other thing I like a lot about gif is it sends out emails for each 
checkin.


One thing I would dearly like is to be able to merge branches using meld.

http://meld.sourceforge.net/

Re: Immutable nested functions

[Tomek Sowiński]

Tomek Sowiński napisał:

> [snip]

Two days, no answer. I was told that silence means agreement on this NG but 
this is extreme ;-)

Seriously, what did I do wrong? Too long/boring post?

-- 
Tomek

Re: Moving to D

[Walter Bright]

Jacob Carlborg wrote:
Has this been announced (somewhere else than the DMD mailing list)? 
Where can one get the test suite? It should be available and easy to 
find and with instructions how to run it. Somewhere on the Digitalmars 
site or/and perhaps released with the DMD source code?


It's part of dmd on svn:

http://www.dsource.org/projects/dmd/browser/trunk/test

DVCS (was Re: Moving to D)

[Jesse Phillips]

Walter Bright Wrote:

> Russel Winder wrote:
> > Pity, because using one of Mercurial, Bazaar or Git instead of
> > Subversion is likely the best and fastest way of getting more quality
> > contributions to review.  Although only anecdotal in every case where a
> > team has switched to DVCS from CVCS -- except in the case of closed
> > projects, obviously -- it has opened things up to far more people to
> > provide contributions.  Subversion is probably now the single biggest
> > barrier to getting input on system evolution.
> 
> 
> A couple months back, I did propose moving to git on the dmd internals 
> mailing 
> list, and nobody was interested.
> 
> One thing I like a lot about svn is this:
> 
> http://www.dsource.org/projects/dmd/changeset/291

You mean this: 
https://github.com/braddr/dmd/commit/f1fde96227394f926da5841db4f0f4c608b2e7b2

> 
> where the web view will highlight the revision's changes. Does git or 
> mercurial 
> do that? The other thing I like a lot about gif is it sends out emails for 
> each 
> checkin.
> 
> One thing I would dearly like is to be able to merge branches using meld.
> 
> http://meld.sourceforge.net/

Git does not have its own merge tool. You are free to use meld. Though there is 
gitmerge which can run meld as the merge tool.

Re: Patterns of Bugs

[BlazingWhitester]

On 2011-01-06 21:38:38 +0200, Walter Bright said:


http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html

(dedicated to bearophile!)

Anyone want to post it on reddit?


http://www.reddit.com/r/programming/comments/exfnb/patterns_of_bugs/

done!

Re: Moving to D

[Daniel Gibson]

Am 06.01.2011 20:46, schrieb Walter Bright:

Russel Winder wrote:

Pity, because using one of Mercurial, Bazaar or Git instead of
Subversion is likely the best and fastest way of getting more quality
contributions to review. Although only anecdotal in every case where a
team has switched to DVCS from CVCS -- except in the case of closed
projects, obviously -- it has opened things up to far more people to
provide contributions. Subversion is probably now the single biggest
barrier to getting input on system evolution.



A couple months back, I did propose moving to git on the dmd internals mailing
list, and nobody was interested.

One thing I like a lot about svn is this:

http://www.dsource.org/projects/dmd/changeset/291

where the web view will highlight the revision's changes. Does git or mercurial
do that? The other thing I like a lot about gif is it sends out emails for each
checkin.



It's not SVN but trac doing this.
And trac's mercurial plugin seems to support that as well: 
http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets


Bitbucket also supports that kind of view, see for example: 
https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c


The GitPlugin should support that as well, if I interpret the feature list 
correctly: http://trac-hacks.org/wiki/GitPlugin


Dsource seems to support both git and mercurial, but I don't know which projects 
use them, else I'd them as examples to see how those trac plugins work in real life.


Cheers,
- Daniel

Re: DVCS (was Re: Moving to D)

[Jesse Phillips]

Jesse Phillips Wrote:

> > where the web view will highlight the revision's changes. Does git or 
> > mercurial 
> > do that? The other thing I like a lot about gif is it sends out emails for 
> > each 
> > checkin.
> > 
> > One thing I would dearly like is to be able to merge branches using meld.
> > 
> > http://meld.sourceforge.net/
> 
> Git does not have its own merge tool. You are free to use meld. Though there 
> is gitmerge which can run meld as the merge tool.

Just realized you probably meant more than just resolving conflicts. And what 
you might be interested in git cherry picking. I haven't done it myself and 
don't know if meld could be used for it.

Re: DVCS (was Re: Moving to D)

[Michel Fortin]

On 2011-01-06 15:01:18 -0500, Jesse Phillips  said:


Walter Bright Wrote:


A couple months back, I did propose moving to git on the dmd internals mailing
list, and nobody was interested.


I probably wasn't on the list at the time. I'm certainly interested, 
it'd certainly make it easier for me, as I'm using git locally to 
access that repo.



One thing I like a lot about svn is this:

http://www.dsource.org/projects/dmd/changeset/291


You mean this: 
https://github.com/braddr/dmd/commit/f1fde96227394f926da5841db4f0f4c608b2e7b2


That's 


only if you're hosted on github. If you install on your own server, git 
comes with a web interface that looks like this (pointing to a specific 
diff):



Also 

when I want an overview with git I just type gitk on the command line 
to bring a window where I can browser the graph of forks, merges and 
commits and see the diff for each commit. Here's what gitk looks like:





where the web view will highlight the revision's changes. Does git or mercurial
do that? The other thing I like a lot about gif is it sends out emails for each
checkin.

One thing I would dearly like is to be able to merge branches using meld.

http://meld.sourceforge.net/


Git does not have its own merge tool. You are free to use meld. Though 
there is gitmerge which can run meld as the merge tool.


Looks like meld itself used git as it's repository. I'd be surprised if 
it doesn't work with git. :-)



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Patterns of Bugs

[Nick Sabalausky]

"Walter Bright"  wrote in message 
news:ig55s4$1uc...@digitalmars.com...
> http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html
>
> (dedicated to bearophile!)
>
> Anyone want to post it on reddit?

I noticed that C-style octal literals were conspicuously absent from the 
examples ;)

Great article, though. Having been in D-land for so long, and being a 
long-time hardcore fan of the classic book "Writing Solid Code", the 
principles seem fairly obvious to me. But it's definitely something to pass 
along to other people.

Re: Patterns of Bugs

[Robert Clipsham]

On 06/01/11 19:38, Walter Bright wrote:

http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html

(dedicated to bearophile!)

Anyone want to post it on reddit?


"It's too bad there doesn't seem to be an online repository of them. 
They would make for great research material for programming language 
designers. Every one you can design out of existence will incrementally 
improve the productivity of programmers."


Perhaps someone here would like to volunteer for this? I guess some kind 
of moderated bugzilla would do the trick, it'd be awesome to have some 
table of languages and how many of the types bugs they prevent/kind of 
prevent as well.


If no one else volunteers I guess I could hack something crude together, 
it would still need people to volunteer bugs for it, as well as 
sources/proof for each bug (links to changesets/projects that have 
encountered this issue etc).


--
Robert
http://octarineparrot.com/

Re: Moving to D

[Robert Clipsham]

On 06/01/11 19:46, Walter Bright wrote:

One thing I like a lot about svn is this:

http://www.dsource.org/projects/dmd/changeset/291


That's Trac, not SVN doing it - all other version control systems do a 
similar thing.



where the web view will highlight the revision's changes. Does git or
mercurial do that? The other thing I like a lot about gif is it sends
out emails for each checkin.


This is easily doable with both mercurial and git. If you use a tool 
like bitbucket or github (which I *highly* recommend you do, opens up a 
huge community to you, I know of several cases where projects have been 
discovered through them and gained contributors etc).



One thing I would dearly like is to be able to merge branches using meld.

http://meld.sourceforge.net/


There's guides for doing this in both mercurial and git, you generally 
just run one command one time and forget about it, any time you do 
git/hg merge it will then automatically use meld or any other tool you 
discover.


--
Robert
http://octarineparrot.com/

Re: Patterns of Bugs

[Walter Bright]

Nick Sabalausky wrote:
I noticed that C-style octal literals were conspicuously absent from the 
examples ;)


Everyone has their favorite pattern. I could literally list thousands of them.


Great article, though. Having been in D-land for so long, and being a 
long-time hardcore fan of the classic book "Writing Solid Code", the 
principles seem fairly obvious to me. But it's definitely something to pass 
along to other people.


I think it's obvious, too, but it ain't. Just work on a car for a while, and 
you'll see!

Re: Patterns of Bugs

[Guilherme Vieira]

On Thu, Jan 6, 2011 at 6:25 PM, Robert Clipsham
wrote:

> On 06/01/11 19:38, Walter Bright wrote:
>
>> http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html
>>
>> (dedicated to bearophile!)
>>
>> Anyone want to post it on reddit?
>>
>
> "It's too bad there doesn't seem to be an online repository of them. They
> would make for great research material for programming language designers.
> Every one you can design out of existence will incrementally improve the
> productivity of programmers."
>
> Perhaps someone here would like to volunteer for this? I guess some kind of
> moderated bugzilla would do the trick, it'd be awesome to have some table of
> languages and how many of the types bugs they prevent/kind of prevent as
> well.
>
> If no one else volunteers I guess I could hack something crude together, it
> would still need people to volunteer bugs for it, as well as sources/proof
> for each bug (links to changesets/projects that have encountered this issue
> etc).
>
> --
> Robert
> http://octarineparrot.com/
>

I loved the idea, but I personally dislike Bugzilla and I wonder if it would
work for something like that. Anyway a voting system would be mandatory.

In any case, isn't there something like this already?

-- 
Atenciosamente / Sincerely,
Guilherme ("n2liquid") Vieira

Re: DVCS (was Re: Moving to D)

[Walter Bright]

Jesse Phillips wrote:

Walter Bright Wrote:

One thing I like a lot about svn is this:

http://www.dsource.org/projects/dmd/changeset/291


You mean this:
https://github.com/braddr/dmd/commit/f1fde96227394f926da5841db4f0f4c608b2e7b2


Yes, exactly. Good.



One thing I would dearly like is to be able to merge branches using meld.

http://meld.sourceforge.net/


Git does not have its own merge tool. You are free to use meld. Though there
is gitmerge which can run meld as the merge tool.

Re: DVCS (was Re: Moving to D)

[Walter Bright]

Michel Fortin wrote:
On 2011-01-06 15:01:18 -0500, Jesse Phillips 
 said:



Walter Bright Wrote:

A couple months back, I did propose moving to git on the dmd 
internals mailing

list, and nobody was interested.


I probably wasn't on the list at the time. I'm certainly interested, 
it'd certainly make it easier for me, as I'm using git locally to access 
that repo.



One thing I like a lot about svn is this:

http://www.dsource.org/projects/dmd/changeset/291


You mean this: 
https://github.com/braddr/dmd/commit/f1fde96227394f926da5841db4f0f4c608b2e7b2 



That's


only if you're hosted on github. If you install on your own server, git 
comes with a web interface that looks like this (pointing to a specific 
diff):
 


Eh, that's inferior. The svn will will highlight what part of a line is 
different, rather than just the whole line.



Looks like meld itself used git as it's repository. I'd be surprised if 
it doesn't work with git. :-)


I use git for other projects, and meld doesn't work with it.

Re: std.unittests for (final?) review

[Tomek Sowiński]

Andrei Alexandrescu napisał:

> * Remove assertCmp and fold it into assertPredicate. With trivial 
> metaprogramming you can distinguish an operator from an actual expression.
> 
> assertPredicate!"<"(1 + 1, 2.1);

If it's trivial, put it into binaryFun, so that everyone else can reap rewards:

sort!">"(range);
auto sum = reduce!"+"(range);

As for operator-only unaryFuns, don't; they bring more confusion than benefit.

-- 
Tomek

Re: Patterns of Bugs

[bearophile]

Walter:

> http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html
> (dedicated to bearophile!)

Thank you Walter :-)
The article is simple but nice. Few comments:


> The possible mechanic's mistake is designed out of the system.

In the first books written by Donald Norman there are many examples of wrong 
design, "foolproof" design, etc:
http://en.wikipedia.org/wiki/Donald_Norman


> (!E && !E->fld)
> is a nonsense expression, and what was probably meant was:
> (!E || !E->fld)
> 
> What's the process fix for this bug pattern?

Even the correct version is not nice code :-)


>In the D programming language, we didn't wish to mess with the operator 
>precedences in order to avoid behavior that would be surprising to experienced 
>programmers.<

Experienced _C_ programmers (as you written below) :-)


> A common pattern is the classic fencepost bug:
> int A[10];
> for (int i = 0; i <= 10; i++)
> ... = A[i];


This little C99 program:

#include 
int main() {
int A[10] = {0,1,2,3,4,5,6,7,8,9};
int total = 0;
for (int i = 0; i <= 10; i++)
  total += A[i]; // line 6
printf("%d\n", total);
return 0;
}


The good Gimpel lint catches the bug statically:

diy.c  6  Warning 661:  Possible access of out-of-bounds pointer (1 beyond end 
of data) by operator '[' [Reference: file diy.c: lines 5, 6]

It's able to catch more complex situations too (but not all situations).

Bye,
bearophile

Re: Patterns of Bugs

[Jesse Phillips]

Guilherme Vieira Wrote:

> On Thu, Jan 6, 2011 at 6:25 PM, Robert Clipsham
> wrote:
>
> > If no one else volunteers I guess I could hack something crude together, it
> > would still need people to volunteer bugs for it, as well as sources/proof
> > for each bug (links to changesets/projects that have encountered this issue
> > etc).
> >
> > I loved the idea, but I personally dislike Bugzilla and I wonder if it would
> work for something like that. Anyway a voting system would be mandatory.
> 
> In any case, isn't there something like this already?

I don't see much benefit in building a "crude" prototype for such a system. If 
it is going to be done the person should really run with the idea; research 
what tools are out their for managing a system and doing what it takes to make 
a usable, friendly, and meaningful implementation.

Modifications to analysis tools could be made which would crawl public 
repositories looking for known patterns (not to claim it is a bug), similar to 
Ohloh and its crawling tools.

Re: Patterns of Bugs

[Daniel Gibson]

Am 06.01.2011 21:37, schrieb Guilherme Vieira:

On Thu, Jan 6, 2011 at 6:25 PM, Robert Clipsham mailto:rob...@octarineparrot.com>> wrote:

On 06/01/11 19:38, Walter Bright wrote:

http://www.drdobbs.com/blog/archives/2011/01/patterns_of_bug.html

(dedicated to bearophile!)

Anyone want to post it on reddit?


"It's too bad there doesn't seem to be an online repository of them. They
would make for great research material for programming language designers.
Every one you can design out of existence will incrementally improve the
productivity of programmers."

Perhaps someone here would like to volunteer for this? I guess some kind of
moderated bugzilla would do the trick, it'd be awesome to have some table of
languages and how many of the types bugs they prevent/kind of prevent as 
well.

If no one else volunteers I guess I could hack something crude together, it
would still need people to volunteer bugs for it, as well as sources/proof
for each bug (links to changesets/projects that have encountered this issue
etc).

--
Robert
http://octarineparrot.com/


I loved the idea, but I personally dislike Bugzilla and I wonder if it would
work for something like that. Anyway a voting system would be mandatory.

In any case, isn't there something like this already?



I don't think Bugzilla would be appropriate, because such a repository should 
collect bugs from many different projects.

Something that allows to sort the bugs into categories etc is needed IMHO.
So you'd have rough categories of bugs, sub-(sub-sub-)categories of that and at 
some point links to the actual bugs in the respective bugtrackers of the 
monitored projects.


Of course support for that in various bugtrackers would be great, so the 
bugfixer could just select the appropriate (sub)category of the bug and it would 
automatically be submitted to the repository.


Cheers,
- Daniel

Re: DVCS (was Re: Moving to D)

[Jesse Phillips]

Walter Bright Wrote:

> Eh, that's inferior. The svn will will highlight what part of a line is 
> different, rather than just the whole line.
 
As others have mentioned, it really isn't the CVS, I don't think the default 
SVN web server does the highlighting you want, it might not even do any 
highlighting. Trac should be able to provide the same functionality as found on 
github, though github will provide a lot more then just highlighting.

> > Looks like meld itself used git as it's repository. I'd be surprised if 
> > it doesn't work with git. :-)
> 
> I use git for other projects, and meld doesn't work with it.

Found these links:

http://www.muhuk.com/2008/11/adding-git-support-to-meld/
http://nathanhoad.net/how-to-meld-for-git-diffs-in-ubuntu-hardy

So maybe that is what's missing.

Re: Deprecate ReturnStatements?

[Stewart Gordon]

On 02/01/2011 13:01, Manfred_Nowak wrote:

Walter Bright wrote:

writing generic code so that the same code can be generated for void
and non-void return values.

   http://d.puremagic.com/issues/show_bug.cgi?id=5399 (cited 01/02/11)

The docs include:
| Expressions that have no effect, like (x + x), are illegal in
| expression statements. If such an expression is needed, casting it to
| void will make it legal.
   http://www.digitalmars.com/d/2.0/statement.html#ExpressionStatement
| If the Expression has no side effects, and the return type is void,
| then it is illegal.
   http://www.digitalmars.com/d/2.0/statement.html#ReturnStatement
   ( both cited 01/02/11)

Walters remark suggests that the dysmorphism between returnStatement and
expressionStatement is based on arbitrariness: generating an expression
by generic code must still take into account, whether the genrated
expression will be used for an expressionStatement or a returnStatement.

This is because casting to void will not legalize an expression without
side effects for a returnStatement, but for an expressionStatement only.


Then why not fix ReturnStatement so that

return cast(void) Expression ;

is always legal in a void-returning function?

Perhaps the way to do it is to define that the semantic analyser always 
deems cast(void) Expression to have a side effect.



To make this homomorphic it might be adequate to view returning as an
attribute of an expressionStatement:

   `(void).return;' instead of `return;'   whithin `void f(){}'
   `(1).return;'instead of `return 1;' whithin `int f(){}'



I don't really like this - it seems unnatural.  return is a control flow 
statement.  Properties of objects, by their nature, don't control the 
flow of the calling function (throwing exceptions aside).


Stewart.

Re: Moving to D

[Daniel Gibson]

Am 06.01.2011 23:26, schrieb Nick Sabalausky:

"Daniel Gibson"  wrote in message
news:ig57ar$1gn...@digitalmars.com...

Am 06.01.2011 20:46, schrieb Walter Bright:

Russel Winder wrote:

Pity, because using one of Mercurial, Bazaar or Git instead of
Subversion is likely the best and fastest way of getting more quality
contributions to review. Although only anecdotal in every case where a
team has switched to DVCS from CVCS -- except in the case of closed
projects, obviously -- it has opened things up to far more people to
provide contributions. Subversion is probably now the single biggest
barrier to getting input on system evolution.



A couple months back, I did propose moving to git on the dmd internals
mailing
list, and nobody was interested.

One thing I like a lot about svn is this:

http://www.dsource.org/projects/dmd/changeset/291

where the web view will highlight the revision's changes. Does git or
mercurial
do that? The other thing I like a lot about gif is it sends out emails
for each
checkin.



It's not SVN but trac doing this.
And trac's mercurial plugin seems to support that as well:
http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets

Bitbucket also supports that kind of view, see for example:
https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c

The GitPlugin should support that as well, if I interpret the feature list
correctly: http://trac-hacks.org/wiki/GitPlugin

Dsource seems to support both git and mercurial, but I don't know which
projects use them, else I'd them as examples to see how those trac plugins
work in real life.



DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd



http://www.dsource.org/projects/ddmd/changeset?new=rt%40185%3A13cf8da225ce&old=rt%40183%3A190ba98276b3
"Trac detected an internal error:"
looks like dsource uses an old/broken version of the mercurial plugin.
But normally it *should* work, I think.

Re: Moving to D

[Nick Sabalausky]

"Daniel Gibson"  wrote in message 
news:ig57ar$1gn...@digitalmars.com...
> Am 06.01.2011 20:46, schrieb Walter Bright:
>> Russel Winder wrote:
>>> Pity, because using one of Mercurial, Bazaar or Git instead of
>>> Subversion is likely the best and fastest way of getting more quality
>>> contributions to review. Although only anecdotal in every case where a
>>> team has switched to DVCS from CVCS -- except in the case of closed
>>> projects, obviously -- it has opened things up to far more people to
>>> provide contributions. Subversion is probably now the single biggest
>>> barrier to getting input on system evolution.
>>
>>
>> A couple months back, I did propose moving to git on the dmd internals 
>> mailing
>> list, and nobody was interested.
>>
>> One thing I like a lot about svn is this:
>>
>> http://www.dsource.org/projects/dmd/changeset/291
>>
>> where the web view will highlight the revision's changes. Does git or 
>> mercurial
>> do that? The other thing I like a lot about gif is it sends out emails 
>> for each
>> checkin.
>
>
> It's not SVN but trac doing this.
> And trac's mercurial plugin seems to support that as well: 
> http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets
>
> Bitbucket also supports that kind of view, see for example: 
> https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c
>
> The GitPlugin should support that as well, if I interpret the feature list 
> correctly: http://trac-hacks.org/wiki/GitPlugin
>
> Dsource seems to support both git and mercurial, but I don't know which 
> projects use them, else I'd them as examples to see how those trac plugins 
> work in real life.
>

DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd

Re: Moving to D

[Vladimir Panteleev]

On Thu, 06 Jan 2011 21:46:47 +0200, Walter Bright  
 wrote:


A couple months back, I did propose moving to git on the dmd internals  
mailing list, and nobody was interested.


Walter, if you do make the move to git (or in generally switch DVCSes),  
please make it so that the backend is not in the same repository in the  
frontend. Since the backend has severe redistribution restrictions, the  
compiler repository can't be simply forked and published.


FWIW I'm quite in favor of a switch to git (even better if you choose  
GitHub, as was discussed in another thread). I had to go through great  
lengths to set up a private git mirror of the dmd repository, as dsource  
kept dropping my git-svnimport connections, and it took forever.


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: Moving to D

[Lutger Blijdestijn]

Daniel Gibson wrote:

> Am 06.01.2011 23:26, schrieb Nick Sabalausky:
>> "Daniel Gibson"  wrote in message
>> news:ig57ar$1gn...@digitalmars.com...
>>> Am 06.01.2011 20:46, schrieb Walter Bright:
 Russel Winder wrote:
> Pity, because using one of Mercurial, Bazaar or Git instead of
> Subversion is likely the best and fastest way of getting more quality
> contributions to review. Although only anecdotal in every case where a
> team has switched to DVCS from CVCS -- except in the case of closed
> projects, obviously -- it has opened things up to far more people to
> provide contributions. Subversion is probably now the single biggest
> barrier to getting input on system evolution.


 A couple months back, I did propose moving to git on the dmd internals
 mailing
 list, and nobody was interested.

 One thing I like a lot about svn is this:

 http://www.dsource.org/projects/dmd/changeset/291

 where the web view will highlight the revision's changes. Does git or
 mercurial
 do that? The other thing I like a lot about gif is it sends out emails
 for each
 checkin.
>>>
>>>
>>> It's not SVN but trac doing this.
>>> And trac's mercurial plugin seems to support that as well:
>>> http://trac.edgewall.org/wiki/TracMercurial#MercurialChangesets
>>>
>>> Bitbucket also supports that kind of view, see for example:
>>> https://bitbucket.org/goshawk/gdc/changeset/44b6978e5f6c
>>>
>>> The GitPlugin should support that as well, if I interpret the feature
>>> list correctly: http://trac-hacks.org/wiki/GitPlugin
>>>
>>> Dsource seems to support both git and mercurial, but I don't know which
>>> projects use them, else I'd them as examples to see how those trac
>>> plugins work in real life.
>>>
>>
>> DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd
>>
> 
> 
http://www.dsource.org/projects/ddmd/changeset?new=rt%40185%3A13cf8da225ce&old=rt%40183%3A190ba98276b3
> "Trac detected an internal error:"
> looks like dsource uses an old/broken version of the mercurial plugin.
> But normally it *should* work, I think.

This works: http://www.dsource.org/projects/ddmd/changeset/183:190ba98276b3

Re: Moving to D

[Nick Sabalausky]

"Robert Clipsham"  wrote in message 
news:ig58tk$24b...@digitalmars.com...
> On 06/01/11 19:46, Walter Bright wrote:
>> One thing I like a lot about svn is this:
>>
>> http://www.dsource.org/projects/dmd/changeset/291
>
> That's Trac, not SVN doing it - all other version control systems do a 
> similar thing.
>
>> where the web view will highlight the revision's changes. Does git or
>> mercurial do that? The other thing I like a lot about gif is it sends
>> out emails for each checkin.
>
> This is easily doable with both mercurial and git. If you use a tool like 
> bitbucket or github (which I *highly* recommend you do, opens up a huge 
> community to you, I know of several cases where projects have been 
> discovered through them and gained contributors etc).
>

I would STRONGLY recommend against using any site that requires a valid 
non-mailinator email address just to do basic things like post a bug report. 
I'm not sure exactly which ones are and aren't like that, but many free 
project hosting sites are like that and it's an absolutely inexcusable 
barrier.

And of course everyone knows how I'd feel about any site that required JS 
for anything that obviously didn't need JS. ;)

One other random thought: I'd really hate to use a system that didn't have 
short sequential changeset identifiers. I think Hg does have that, although 
I don't think all Hg interfaces actually use it, just some.

Re: std.unittests for (final?) review

[Andrei Alexandrescu]

On 1/6/11 2:59 PM, Tomek Sowiński wrote:

Andrei Alexandrescu napisał:


* Remove assertCmp and fold it into assertPredicate. With trivial
metaprogramming you can distinguish an operator from an actual expression.

assertPredicate!"<"(1 + 1, 2.1);


If it's trivial, put it into binaryFun, so that everyone else can reap rewards:

sort!">"(range);
auto sum = reduce!"+"(range);


Yah, I've been thinking of it.


As for operator-only unaryFuns, don't; they bring more confusion than benefit.


Agreed.

Andrei

Re: Moving to D

[Andrei Alexandrescu]

On 1/6/11 4:26 PM, Nick Sabalausky wrote:

DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd


The ready availability of Mercurial on dsource.org plus Don's 
inclination to use Mercurial just tipped the scale for me. We should do 
all we can to make Don's and other developers' life easier, and being 
able to work on multiple fixes at a time is huge.


We should create a new Mercurial repository. I suggest we call it 
digitalmars because the current "phobos" svn repo contains a lot of 
stuff that's not phobos-related.



Andrei

Re: Deprecate ReturnStatements?

[Andrei Alexandrescu]

On 1/6/11 4:29 PM, Stewart Gordon wrote:

On 02/01/2011 13:01, Manfred_Nowak wrote:

Walter Bright wrote:

writing generic code so that the same code can be generated for void
and non-void return values.

http://d.puremagic.com/issues/show_bug.cgi?id=5399 (cited 01/02/11)

The docs include:
| Expressions that have no effect, like (x + x), are illegal in
| expression statements. If such an expression is needed, casting it to
| void will make it legal.
http://www.digitalmars.com/d/2.0/statement.html#ExpressionStatement
| If the Expression has no side effects, and the return type is void,
| then it is illegal.
http://www.digitalmars.com/d/2.0/statement.html#ReturnStatement
( both cited 01/02/11)

Walters remark suggests that the dysmorphism between returnStatement and
expressionStatement is based on arbitrariness: generating an expression
by generic code must still take into account, whether the genrated
expression will be used for an expressionStatement or a returnStatement.

This is because casting to void will not legalize an expression without
side effects for a returnStatement, but for an expressionStatement only.


Then why not fix ReturnStatement so that

return cast(void) Expression ;

is always legal in a void-returning function?

Perhaps the way to do it is to define that the semantic analyser always
deems cast(void) Expression to have a side effect.


To make this homomorphic it might be adequate to view returning as an
attribute of an expressionStatement:

`(void).return;' instead of `return;' whithin `void f(){}'
`(1).return;' instead of `return 1;' whithin `int f(){}'



I don't really like this - it seems unnatural. return is a control flow
statement. Properties of objects, by their nature, don't control the
flow of the calling function (throwing exceptions aside).

Stewart.


Guys, this is getting really bizarre. We now have syntax proposals for 
fixing... what problem? Walter, please drop that feature and let's move 
on. Again, you can take my word that such a feature offers nothing to 
generic and generative programming.


Andrei

Re: Moving to D

[Brad Roberts]

On Thu, 6 Jan 2011, Andrei Alexandrescu wrote:

> On 1/6/11 4:26 PM, Nick Sabalausky wrote:
> > DDMD uses Mercurial on DSource: http://www.dsource.org/projects/ddmd
> 
> The ready availability of Mercurial on dsource.org plus Don's inclination to
> use Mercurial just tipped the scale for me. We should do all we can to make
> Don's and other developers' life easier, and being able to work on multiple
> fixes at a time is huge.
> 
> We should create a new Mercurial repository. I suggest we call it digitalmars
> because the current "phobos" svn repo contains a lot of stuff that's not
> phobos-related.
> 
> 
> Andrei

Personally, I'd prefer to git over mecurial, which dsource also supports.  
But, really, I'd prefer github over dsource (sorry, BradA) for stability 
and just generally much more usable site.

My general problem with the switch to a different SCM of any sort:

  1) the history of the current source is a mess.
 a) lack of tags for releases
 b) logical merges have all been done as individual commits

  2) walter's workflow meaning that he'll won't use the scm merge
 facilities.  He manually merges everything.

None of this is really a problem, it just becomes a lot more visible when 
using a system that encourages keeping a very clean history and the use of 
branches and merging.

My 2 cents,
Brad

Re: Moving to D

[Eric Poggel]

On 1/6/2011 3:03 PM, Daniel Gibson wrote:

Dsource seems to support both git and mercurial, but I don't know which
projects use them, else I'd them as examples to see how those trac
plugins work in real life.


I stumbpled across this url the other day:  http://hg.dsource.org/ 
Seems to list mercurial projects.  I couldn't find a similar one for git.

Re: Moving to D

[Andrej Mitrovic]

I've ever only used hg (mercurial), but only for some private
repositories. I'll say one thing: it's pretty damn fast considering it
requires Python to work. Also, Joel's tutorial that introduced me to
hg was short and and to the point: http://hginit.com/

Re: Deprecate ReturnStatements?

[bearophile]

Andrei Alexandrescu:

> Walter, please drop that feature and let's move 
> on. Again, you can take my word that such a feature offers nothing to 
> generic and generative programming.

Thank you Andrei :-)

Bye,
bearophile

Re: Moving to D

[bearophile]

Andrei:

> The ready availability of Mercurial on dsource.org plus Don's 
> inclination to use Mercurial just tipped the scale for me. We should do 
> all we can to make Don's and other developers' life easier, and being 
> able to work on multiple fixes at a time is huge.

Probably both Mercurial and Git are a little improvement over the current 
situation.
It's also a way to improve D image, making it look a little more open source. I 
hope a fat "Fork me!" button will be visible on a web page :-)

Bye,
bearophile

Re: Moving to D

[Vladimir Panteleev]

On Fri, 07 Jan 2011 01:03:42 +0200, Brad Roberts  
 wrote:



  2) walter's workflow meaning that he'll won't use the scm merge
 facilities.  He manually merges everything.


Not sure about Hg, but in Git you can solve this by simply manually  
specifying the two parent commits. Git doesn't care how you merged the two  
branches. In fact, you can even do this locally by using grafts.


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: Moving to D

[David Nadlinger]

On 1/6/11 8:19 PM, "Jérôme M. Berger" wrote:

Here's a comparison. Although I am partial to Mercurial, I have
tried to be fair.


Jérôme, I'm usually not the one arguing ad hominem, but are you sure 
that you really tried to be fair? If you want to make subjective 
statements about Mercurial, that you personally like it better because 
of this and that reason, that's fine, but please don't try to make it 
look like an objective comparison. A fair part of the arguments you made 
in the linked post are objectively wrong, which is understandable if 
you're mainly a Mercurial user – but please don't make it look like you 
had done more in-depth research regarding both to other people…


For example, you dwelt on being able to »hg pull help« being an 
advantage over Git – where the equivalent command reads »git pull 
--help«. Are you serious?! By the way, at least for Mercurial 1.6, you 
need to pass »--help« as a »proper« argument using two dashes as well, 
your command does not work (anymore).



An extra point I did not raise at the time: Git is deliberately
engineered to be as different from CVS/SVN as possible (quoting
Wikipedia: "Take CVS as an example of what /not/ to do; if in doubt,
make the exact opposite decision").


You missed the »… quote Torvalds, speaking somewhat tongue-in-cheek« 
part – in the talk the quote is from, Linus Torvalds was making the 
point that centralized SCMs just can't keep up with distributed 
concepts, and as you probably know, he really likes to polarize. In the 
same talk, he also mentioned Mercurial being very similar to Git – does 
that make it an unfavorable switch as well in your eyes? I hope not…


David

Re: Moving to D

[David Nadlinger]

On 1/6/11 11:47 PM, Andrei Alexandrescu wrote:

Mercurial on dsource.org …


Personally, I'd really like to persuade Walter, you, and whoever else 
actually decides this to consider hosting the main repository at an 
external place like GitHub or Mercurial, because DSource has been having 
some real troubles with stability, although it got slightly better again 
recently. The problem is somewhat alleviated when using a DVCS, but 
having availabilities the main source repositories is not quite the best 
form of advertisement for a language.


Additionally, the UI of GitHub supports the scenario where only a few 
people (or Walter alone) actually have commit/push access to the main 
repository really well through cheap forks which stay logically 
connected to he main repository and merge requests. The ability to make 
comments on specific (lines in) commits, also in combination with pull 
requests, is awesome as well.


I would also like to suggest Git over Mercurial, though this is mostly 
personal preference – it is used more widely, it has GitHub and 
Gitorious (I'm having a hard time finding Bitbucket comparable 
personally), it's proven to work well in settings where the main tree is 
managed by a single person (->Linux), it tries not artificially 
restricting you as much as possible (something I imagine Walter might 
like), … – but again, it's probably a matter of taste, I don't want to 
start a flamewar here.


The most important thing to me is, however, that I'd really like to see 
a general shift in the way D development is done towards more 
contributor-friendliness. I can only bow to Walter as a very capable and 
experienced compiler writer, but as it was discussed several times here 
on the list as well, in my opinion D has reached a point where it 
desperately needs to win new contributors to the whole ecosystem. There 
is a reason why other open source projects encourage you to write 
helpful commit messages, and yet we don't even have tags for releases 
(!) in the DMD repository.


I didn't intend to offend anybody at all, but I'd really hate to see D2 
failing to »take off« for reasons like this…


David

Re: Moving to D

[Vladimir Panteleev]

On Thu, 06 Jan 2011 17:42:29 +0200, Andrei Alexandrescu  
 wrote:


What are the advantages of Mercurial over git? (git does allow multiple  
branches.)


We've had a discussion in #d (IRC), and the general consensus there seems  
to be strongly in favor of Git/GitHub. For completeness (there's been a  
discussion before) here are my arguments:


1) Git has the largest user base - more people will be able to get started  
hacking on the source immediately.
(GitHub compared to DSource below, some of these also apply to Gitorious,  
Bitbucket, Launchpad)
2) One-click forking - you can easily publish improvements that are easily  
discoverable to people interested in the project. (This practically  
guarantees that an open-source project will never hit a dead end, as long  
as some people are interested in it - both occasional patches and  
maintained forks are easily discoverable.)
3) UI for pull requests (requests to merge changes in a forked repository  
upstream), with comments.
4) Inline comments (you can comment on a specific line in a commit/patch).  
This integrates very nicely with 3) for great code review capabilities.
5) (Unique to GitHub) The network graph allows visualizing all commits in  
all forks of the project.
6) GitHub is run by a commercial company, and the same infrastructure is  
used for hosting commercial projects. Therefore, you can expect better  
uptime and support.
GitHub has integrated wiki, issues and downloads (all optional). One thing  
GitHub doesn't have that DSource has is forums.
I think there is no "shame" in leaving DSource for DigitalMars projects,  
many large open-source projects use GitHub (see GitHub's front page).


Some existing D projects on GitHub: https://github.com/languages/D

I think Jérôme's observations of Git performance are specific to Windows.  
Git is expected to be slower on Windows, since it runs on top of  
cygwin/msys.
Here's a study on the Git wiki:  
https://git.wiki.kernel.org/index.php/GitBenchmarks


Google has done a study of Git vs. Mercurial in 2008:
http://code.google.com/p/support/wiki/DVCSAnalysis
The main disadvantage they found in Git (poor performance over HTTP)  
doesn't apply to us, and I believe it was addressed in recent versions  
anyway.


Disclaimer: I use Git, and avoid Mercurial if I can mainly because I don't  
want to learn another VCS. Nevertheless, I tried to be objective above.
As I mentioned on IRC, I strongly believe this must be a fully-informed  
decision, since changing VCSes again is unrealistic once it's done.


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: Moving to D

[Travis Boucher]

On 01/06/11 17:55, Vladimir Panteleev wrote:


Disclaimer: I use Git, and avoid Mercurial if I can mainly because I
don't want to learn another VCS. Nevertheless, I tried to be objective
above.
As I mentioned on IRC, I strongly believe this must be a fully-informed
decision, since changing VCSes again is unrealistic once it's done.



Recently I have been using mercurial (bitbucket).  I have used git 
previously, and subversion alot.


The question I think is less of git vs. mercurial and more of 
(git|mercurial) vs. (subversion) and even more (github|bitbucket) vs. 
dsource.


I like dsource alot, however it doesn't compare feature wise to github & 
bitbucket.  The only argument feature wise is forums, and in reality we 
already have many places to offer/get support for D and D projects other 
than the dsource forums (newsgroups & irc for example).


Another big issue I have with dsource is that its hard to find active 
projects and projects that have been dead (sometimes for 5+ years).


The 'social coding' networks allow projects to be easily revived in the 
case they do die.


Personally I don't care which is used (git|mercurial, github|bitbucket), 
as long as we find a better way of managing the code, and a nice way of 
doing experimental things and having a workflow to have those 
experimental things pulled into the official code bases.


dsource has served us well, and could still be a useful tool (maybe have 
it index D stuff from (github|bitbucket)?), but its time to start using 
some of the other, better, tools out there.

Re: Moving to D

[Nick Sabalausky]

"David Nadlinger"  wrote in message 
news:ig5n74$2vu...@digitalmars.com...
> On 1/6/11 11:47 PM, Andrei Alexandrescu wrote:
>> Mercurial on dsource.org .
>
> Personally, I'd really like to persuade Walter, you, and whoever else 
> actually decides this to consider hosting the main repository at an 
> external place like GitHub or Mercurial, because DSource has been having 
> some real troubles with stability, although it got slightly better again 
> recently. The problem is somewhat alleviated when using a DVCS, but having 
> availabilities the main source repositories is not quite the best form of 
> advertisement for a language.
>
> Additionally, the UI of GitHub supports the scenario where only a few 
> people (or Walter alone) actually have commit/push access to the main 
> repository really well through cheap forks which stay logically connected 
> to he main repository and merge requests. The ability to make comments on 
> specific (lines in) commits, also in combination with pull requests, is 
> awesome as well.
>
> I would also like to suggest Git over Mercurial, though this is mostly 
> personal preference - it is used more widely, it has GitHub and Gitorious 
> (I'm having a hard time finding Bitbucket comparable personally), it's 
> proven to work well in settings where the main tree is managed by a single 
> person (->Linux), it tries not artificially restricting you as much as 
> possible (something I imagine Walter might like), . - but again, it's 
> probably a matter of taste, I don't want to start a flamewar here.
>

I've never used github, but I have used bitbucket and I truly, truly hate 
it. Horribly implemented site and an honest pain in the ass to use.

Re: Moving to D

[Michel Fortin]

On 2011-01-06 19:55:10 -0500, "Vladimir Panteleev" 
 said:


2) One-click forking - you can easily publish improvements that are 
easily  discoverable to people interested in the project. (This 
practically  guarantees that an open-source project will never hit a 
dead end, as long  as some people are interested in it - both 
occasional patches and  maintained forks are easily discoverable.)


Easy forking is nice, but it could be a problem in our case. The 
license for the backend is not open-source enough for someone to 
republish it (in a separate own repo) without Walter's permission.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Moving to D

[Nick Sabalausky]

"Vladimir Panteleev"  wrote in message 
news:op.vowx58gqtuz...@cybershadow.mshome.net...
>
> Git is expected to be slower on Windows, since it runs on top of 
> cygwin/msys.

I'd consider running under MSYS to be a *major* disadvantage. MSYS is barely 
usable garbage (and cygwin is just plain worthless). 

Re: Moving to D

[Vladimir Panteleev]

On Fri, 07 Jan 2011 03:17:50 +0200, Michel Fortin  
 wrote:


Easy forking is nice, but it could be a problem in our case. The license  
for the backend is not open-source enough for someone to republish it  
(in a separate own repo) without Walter's permission.


I suggested elsewhere in this thread that the two must be separated first.  
I think it must be done anyway when moving to a DVCS, regardless of the  
specific one or which hosting site we'd use.


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: Moving to D

[Vladimir Panteleev]

On Fri, 07 Jan 2011 03:30:16 +0200, Nick Sabalausky  wrote:

I'd consider running under MSYS to be a *major* disadvantage. MSYS is  
barely

usable garbage (and cygwin is just plain worthless).


Why? MSysGit works great here! I have absolutely no issues with it. It  
doesn't pollute PATH, either, because by default only one directory with  
git/gitk is added to PATH. MSysGit can even integrate with PuTTYLink and  
use your PuTTY SSH sessions (but you can of course also use MSys'  
OpenSSH). Git GUI and Gitk even run better on Windows in my experience  
(something weird about Tcl/Tk on Ubuntu).


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: Moving to D

[Travis Boucher]

On 01/06/11 18:30, Vladimir Panteleev wrote:

On Fri, 07 Jan 2011 03:17:50 +0200, Michel Fortin
 wrote:


Easy forking is nice, but it could be a problem in our case. The
license for the backend is not open-source enough for someone to
republish it (in a separate own repo) without Walter's permission.


I suggested elsewhere in this thread that the two must be separated
first. I think it must be done anyway when moving to a DVCS, regardless
of the specific one or which hosting site we'd use.



I agree, separating out the proprietary stuff has other interesting 
possibilities such as a D front end written in D and integration with 
IDEs and analysis tools.


Of course all of this is possible now, but it'd make merging front end 
updates so much nicer.

Re: Moving to D

[Michel Fortin]

On 2011-01-06 20:30:53 -0500, "Vladimir Panteleev" 
 said:


On Fri, 07 Jan 2011 03:17:50 +0200, Michel Fortin  
 wrote:


Easy forking is nice, but it could be a problem in our case. The 
license  for the backend is not open-source enough for someone to 
republish it  (in a separate own repo) without Walter's permission.


I suggested elsewhere in this thread that the two must be separated 
first.  I think it must be done anyway when moving to a DVCS, 
regardless of the  specific one or which hosting site we'd use.


Which means that we need another solution for the backend, and if that 
solution isn't too worthless it could be used to host the other parts 
too and keep them together.


That said, wherever the repositories are kept, nothing prevents them 
from being automatically mirrored on github (or anywhere else) by 
simply adding a post-update hook in the main repository.


--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: Moving to D

[David Nadlinger]

On 1/7/11 2:43 AM, Michel Fortin wrote:

Which means that we need another solution for the backend, and if that
solution isn't too worthless it could be used to host the other parts
too and keep them together.


Just to be sure: You did mean »together« as in »separate repositories on 
the same hosting platform«, right?


I don't even think we necessarily can't use GitHub or the likes for the 
backend, we'd just need permission from Walter to redistribute the 
sources through that repository, right? It's been quite some time since 
I had a look at the backend license though…


David

Re: Moving to D

[Andrej Mitrovic]

I don't think git really needs MSYS? I mean I've just installed git
again and it does have it's own executable runnable from the console.

It seems to have a gui as well, runnable with "git gui". Pretty cool.
And you can create an icon shotcut to the repo. Sweet.

I'd vote for either the two, although I have to say I do like github a
lot. I didn't know it supported wiki pages though, I haven't seen
anyone use those on a project.

Re: Moving to D

[Vladimir Panteleev]

On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic  
 wrote:



I don't think git really needs MSYS? I mean I've just installed git
again and it does have it's own executable runnable from the console.


MSysGit comes with its own copy of MSys. It's pretty transparent to the  
user, though.


--
Best regards,
 Vladimirmailto:vladi...@thecybershadow.net

Re: Moving to D

[Caligo]

On Thu, Jan 6, 2011 at 5:50 AM, Russel Winder  wrote:

> Whilst I concur (massively) that Subversion is no longer the correct
> tool for collaborative working, especially on FOSS projects, but also
> for proprietary ones, I am not sure Git is the best choice of tool.
> Whilst Git appears to have the zeitgeist, Mercurial and Bazaar are
> actually much easier to work with.  Where Git has GitHub, Mercurial has
> BitBucket, and Bazaar has Launchpad.
>
> --
> Russel.
>
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net 
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>

BitBucket has copied almost everything from Github, and I don't understand
how they've never been sued.

http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html

Github team has been the innovator here, and they never stop improving the
site with new features and bug fixes.  It would be nice to support their
work by using Github.

There is also Gitorious.  It only offers free hosting and it is more team
orientated than Github, but Github has recently added the "Organization"
feature.   The interesting thing about Gitorious is that you can run it on
your own server.  I don't think you can do that with Github.

One cool thing about Github that I like is gist: https://gist.github.com/
It's a pastebin, but it uses Git and supports D syntax.  People are always
sharing snippets on these newsgroups, and it would have been nice if they
were gists.

I've never used Bazaar, so no comment on that.  But, between Git and
Mercurial, I vote for Git.

Re: Moving to D

[Andrej Mitrovic]

On 1/7/11, Vladimir Panteleev  wrote:
> On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic
>  wrote:
>
>> I don't think git really needs MSYS? I mean I've just installed git
>> again and it does have it's own executable runnable from the console.
>
> MSysGit comes with its own copy of MSys. It's pretty transparent to the
> user, though.

Aye, but I didn't download that one, I got the one on the top here:
https://code.google.com/p/msysgit/downloads/list?can=3

And if I put git.exe in it's own directory the only .dll it complains
about is libiconv2.dll (well that, and some missing templates). Using
these two alone seems to work fine.

Re: Moving to D

[Daniel Gibson]

Am 07.01.2011 03:20, schrieb Caligo:



On Thu, Jan 6, 2011 at 5:50 AM, Russel Winder mailto:rus...@russel.org.uk>> wrote:

Whilst I concur (massively) that Subversion is no longer the correct
tool for collaborative working, especially on FOSS projects, but also
for proprietary ones, I am not sure Git is the best choice of tool.
Whilst Git appears to have the zeitgeist, Mercurial and Bazaar are
actually much easier to work with.  Where Git has GitHub, Mercurial has
BitBucket, and Bazaar has Launchpad.

--
Russel.

=
Dr Russel Winder  t: +44 20 7585 2200   voip:
sip:russel.win...@ekiga.net 
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk

London SW11 1EN, UK   w: www.russel.org.uk 
  skype: russel_winder


BitBucket has copied almost everything from Github, and I don't understand how
they've never been sued.

http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html



Yeah, see also: http://schacon.github.com/bitbucket.html by the same author

When this rant was new I read a page that listed where Github stole their ideas 
and designs (Sourceforce for example), but I can't find it anymore.

This rant was bullshit, as even the author seems to have accepted.

I don't understand why people still mirror and link this crap.

Re: Moving to D

[Nick Sabalausky]

"Vladimir Panteleev"  wrote in message 
news:op.vow11fqdtuz...@cybershadow.mshome.net...
> On Fri, 07 Jan 2011 04:09:04 +0200, Andrej Mitrovic 
>  wrote:
>
>> I don't think git really needs MSYS? I mean I've just installed git
>> again and it does have it's own executable runnable from the console.
>
> MSysGit comes with its own copy of MSys. It's pretty transparent to the 
> user, though.
>

That might not be too bad then if it's all packaged well. The main problem 
with MSYS/MinGW is just getting the damn thing downloaded, installed and 
running properly. Do you need to actually use the MSYS/MinGW command-line, 
or is that all hidden away and totally behind-the-scenes?

Re: Moving to D

[Caligo]

On Thu, Jan 6, 2011 at 8:47 PM, Daniel Gibson  wrote:

>
> Yeah, see also: http://schacon.github.com/bitbucket.html by the same
> author
>
> When this rant was new I read a page that listed where Github stole their
> ideas and designs (Sourceforce for example), but I can't find it anymore.
> This rant was bullshit, as even the author seems to have accepted.
>
> I don't understand why people still mirror and link this crap.
>

hmmm...Interesting!  I did not know that, and thanks for the share.  There
is even a discussion about it on reddit where the author apologizes.  I
don't understand why he would do such a thing.

Re: Moving to D

[Nick Sabalausky]

"Caligo"  wrote in message 
news:mailman.461.1294366839.4748.digitalmar...@puremagic.com...
>
> BitBucket has copied almost everything from Github, and I don't understand
> how they've never been sued.
>
> http://dev.pocoo.org/~blackbird/github-vs-bitbucket/bitbucket.html
>

That page looks like the VCS equivalent of taking pictures of sandwiches 
from two different restaurants and then bitching "Oh my god! What a blatant 
copy! Look, they both have meat, lettuce and condiments between slices of 
bread! And they BOTH have the lettuce on top of the meat! What a pathetic 
case of plagiarism!" Bah.