from:"foobar"

Re: this is almost a workaround for the lack of named parameters

2013-03-25 Thread foobar


On Saturday, 23 March 2013 at 15:00:13 UTC, bearophile wrote:

foobar:

Code that needs named parameters to be more readable is poorly 
designed code in the first place.


Have you used a language where the usage of named arguments is 
idiomatic, like Python, Scala or Ada? They are sometimes useful 
even for well designed code, like functions with two arguments.


Bye,
bearophile


idiomatic is a relative term, tightly coupled to a specific 
language. Idiomatic D code for example is very different from 
idiomatic Haskell code.
Idiomatic Python style in D would be very unidiomatic D code and 
vise versa. Each language has its own conventions, styles, set of 
distinct features, etc, etc and trying to use language A style 
while coding in language B is like trying to fit a square peg 
in a round hole.
For instance, I would NOT use smalltalk naming conventions while 
writing say Java code. Both have very good and very consistent 
styles that are tightly coupled with their respective syntaxes 
and are very unsuitable to use in the other language.


In short, if you want to discuss python features, style or 
specific math plotting libraries, please post to the python 
mailing list, not D's NG.

Re: this is almost a workaround for the lack of named parameters

2013-03-25 Thread foobar


On Saturday, 23 March 2013 at 15:59:12 UTC, Jacob Carlborg wrote:

On 2013-03-23 16:55, John Colvin wrote:


A simple example is matplotlib.pyplot.plot

There are so many possible flags and parameters that can be 
passed in
order to get the exact behaviour you want, but commonly you'll 
only want
a few set for each call. You don't want to have to set all the 
other
preceding parameters, you just want to go e.g. plot(data, 
linewidth=5)


I've heard it was a big boost for C# when it got support for 
default arguments and named parameters. It made it a lot easier 
to integrate with COM.


AFAIK, this is only relevant or useful for COM (i.e. to support 
legacy, not really OO code) and is not supported (compile error?) 
for regular C# code as it is *not idiomatic C#* style (and is not 
OO).

Re: this is almost a workaround for the lack of named parameters

2013-03-25 Thread foobar


On Monday, 25 March 2013 at 13:02:49 UTC, bearophile wrote:

foobar:

idiomatic is a relative term, tightly coupled to a specific 
language. Idiomatic D code for example is very different from 
idiomatic Haskell code.
Idiomatic Python style in D would be very unidiomatic D code 
and vise versa. Each language has its own conventions, styles, 
set of distinct features, etc, etc and trying to use language 
A style while coding in language B is like trying to fit a 
square peg in a round hole.
For instance, I would NOT use smalltalk naming conventions 
while writing say Java code. Both have very good and very 
consistent styles that are tightly coupled with their 
respective syntaxes and are very unsuitable to use in the 
other language.


In short, if you want to discuss python features, style or 
specific math plotting libraries, please post to the python 
mailing list, not D's NG.


Imperative/OOP languages are not totally different from each 
other, both Python and D derive strongly from C that comes 
partially from Algol, and D copies several things from Python 
(string functions, part of the module system, part of the range 
design comes from itertools, and so on). So comparing languages 
and their features is very useful.


If you have not used named arguments in languages that 
idiomatically use them, then it's not easy for you to see how 
and why they are sometimes useful and good.


In Python function arguments don't have a type, so named 
arguments are more useful than in D. But from my experience in 
Python, I believe D could enjoy named arguments.


Bye,
bearophile


C is a HORRIBLE language regarding naming conventions and is a 
*very poor choice* to learn from in this regard. Python sets very 
high expectations regarding beautiful code and IMHO fails 
miserably (more so because of the starting higher expectations).
I admit to being spoiled by actually beautifully designed 
languages that are far superior in that respect. I suggest to 
learn Smalltalk for a language that emphasizes code readability 
decades before Python became cool.
I find Ruby which is based on Smalltalk's semantics and spirit to 
be more elegant and less pretentious compared to Python.

Re: this is almost a workaround for the lack of named parameters

2013-03-23 Thread foobar


On Friday, 22 March 2013 at 21:41:46 UTC, John Colvin wrote:

On Friday, 22 March 2013 at 21:29:46 UTC, foobar wrote:

On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:

On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:


WTF? What do kwargs have to do with programming? Sounds more 
like a half-Klingon  half-Ferengi species to me.


kwargs = keyword arguments

It's a common naming convention in python, as exemplified in 
matplotlib.


That was meant more as a rhetorical question rather than a 
real one.
Yes, I guessed the meaning by the surrounding context but 
nevertheless it was a major WAT while skimming the post. Also, 
Who the fuck cares whats common in Python? I was reading and 
replying on the *D* NG, was I not?


Kwarg seems a reasonable name, consistent with a pre-existing 
convention. Please suggest a better alternative if you have 
one. I must admit I'm bemused by your level of aggression over 
what appears to be a trivial matter.


Your read it wrong. Not aggression but rather annoyment.
Also, code readability is NOT a trivial matter and people who 
think that it is should have their keyboard chopped off.


IMHO, I think the entire feature is a code smell and glad D does 
not support it. Code that needs named parameters to be more 
readable is poorly designed code in the first place.

Re: this is almost a workaround for the lack of named parameters

2013-03-22 Thread foobar


On Friday, 22 March 2013 at 10:17:02 UTC, J wrote:
With credit for inspiration to David Medlock in this post-- 
http://forum.dlang.org/thread/d9lnrr$26q3$1...@digitaldaemon.com 
...


// Tongue firmly in cheek, I'd like to introduce
// the NAPAPISS principle: (with apologies to SFINAE and RAII)

// NAPAPISS = NAmed Parameters Are simply Passed in a Struct, 
Silly.


// Yes, indeed, maybe this is what happens after drinking too 
much of
// the fine wine products from the Napa valley... you start 
having

// wild flights of fancy of how D might surprisingly soon have
// named parameters


import std.stdio;
import std.c.stdlib;

void main(string[] arg) {

// this works today: but with the drawback that the
// named params must be known at compile time...

// Here is a named param call,
// as compact as I could get it (see struct below for 
actual definition).


auto a = myfunc!q{ z= 2; x = -123; y = 200 }(0)(); // calls 
opCall

writeln(a=, a); // prints a=yo, as returned from opCall



// And here's the runtime version, unfortunately you have to
// pre-declare g because otherwise it won't survive the 
scope, and
// the return value from myfunc.opCall would become 
inaccessible.

string g;
with(myfunc!()(0)) {
  x=rand() % 40;
  y=x/2;
  z=y/2;
  g = call(); // as a side effect, prints 'X 7, Y 3, Z 
1'

 }
 writeln(g=, g); // prints g=yo, as returned from opCall


/*
// The bright future: this demonstrates that
// it would be fairly trivial to make some kind of 
annotation

// like @kwarg or whaterver, to indicate that a function
// was using this calling convention:
@kwarg string f(int a, string b) { body; }

// so that @kwarg function definitions are lowered to:
struct f_kw {
  int a;
  string b;
  string f() { body; }
}

// and calls to @kwarg functions are transformed
// from this:
auto r = f(a=5, b=good);

// into this:
f_kw tmp34;
tmp34.a = 5;
tmp34.b = good;
auto r = tmp34.f();

// the benefit: named parameters can be used in a natural 
way,

// and they need be known only at runtime.
*/
}

// how the 'works today' above examples were implemented:
struct myfunc(string init_string=)
{
   // named keyword or named parameters
   // --the call arguments and their defaults
   int x=0;
   int y=0;
   int z=0;

   this(int) {}
   string opCall() {
 mixin(init_string ~ ;);
 writefln(X %s, Y %s, Z %s, x, y, z );
 return yo;
   }
   alias opCall call;
}


On Friday, 22 March 2013 at 09:18:33 UTC, J wrote:


The bigger point here is more profound: it is trivial to 
implement named parameters using structs + trivial lowerings, 
and this is no way conflicts with function overloading.


D deserves to have named parameters to functions -- it makes 
for much more legible code, and obviates the need for slow 
builder patterns.  Readable and speedable. It's win-win.


WTF? What do kwargs have to do with programming? Sounds more like 
a half-Klingon  half-Ferengi species to me.

Re: this is almost a workaround for the lack of named parameters

2013-03-22 Thread foobar


On Friday, 22 March 2013 at 21:10:27 UTC, John Colvin wrote:

On Friday, 22 March 2013 at 20:04:14 UTC, foobar wrote:


WTF? What do kwargs have to do with programming? Sounds more 
like a half-Klingon  half-Ferengi species to me.


kwargs = keyword arguments

It's a common naming convention in python, as exemplified in 
matplotlib.


That was meant more as a rhetorical question rather than a real 
one.
Yes, I guessed the meaning by the surrounding context but 
nevertheless it was a major WAT while skimming the post. Also, 
Who the fuck cares whats common in Python? I was reading and 
replying on the *D* NG, was I not?

Re: Are there any default dmd optimizations

2013-02-28 Thread foobar

On Wednesday, 27 February 2013 at 21:57:06 UTC, Andrei 
Alexandrescu wrote:

On 2/27/13 3:16 PM, Jacob Carlborg wrote:

On 2013-02-27 14:29, Andrei Alexandrescu wrote:

Four years ago I would've entirely agreed. But right now it's 
an odd
comment to make seeing as we're discussing all major 
decisions in this

group and we're switching full-bore to DIPs.


The alias this syntax the foobar mentioned was removed under 
the radar

and only discussed in a pull request.


I agree we were sloppy on that. Kenji was feeling strong about 
and Walter and I didn't have particular objections, so we gave 
him green light. In the process we neglected backward 
compatibility.


Andrei


At a bare minimum, there should be a well defined place to notify 
*users* (NOT DMD contributers) about language changes *ahead of 
time*. If such place is not defined, than people do not know 
where to look for that info if that is even available at all. 
This at least will remove the element of surprise.


For D to be really open as it claims to be, there should be 
additional guidelines about the decision making process itself. 
This should be made accessible for *users* (D programmers). I 
need not be a core DMD contributer, nor should I need to know C++ 
or DMD's internals, Nor should I need to browse among hundreds of 
bugs on bugzilla or pull requests on github (both can be labeled 
very poorly) to discern out of that sea of information what are 
the *few* visible changes to the language and core library APIs.

Re: Are there any default dmd optimizations

2013-02-27 Thread foobar

On Tuesday, 26 February 2013 at 23:37:57 UTC, Andrei Alexandrescu 
wrote:

snip


Agreed, but it does happen often that a language feature is 
later superseded by a generalization thereof.


Andrei


I agree that this does happen. The question is how the language 
evolve with that in mind. Do we choose to preserve *all* previous 
semantics? Do we have a proper deprecation process? etc, etc..
I think that unfortunately, the D design process is not adequate 
as of yet - there is no proper deprecation process which causes 
things like a sudden death for previously valid syntax (alias 
syntax) instead of gradually deprecate it with proper 
announcements *everywhere* (website, NG, ..) on the one hand and 
keeping redundant special cases in the language and refusing to 
change semantics (AAs) to allow for an easier path forward, on 
the other hand.


So I think we agree on the spirit of things but the problems I'm 
voicing are about the details or lack thereof. Where are the 
guidelines describing all these issues? How to address required 
semantic changes in the language? how to address syntax changes? 
how to remove previously failed features or no longer needed 
ones? What constitutes a feature that should be completely 
removed and what should only be put on permanent deprecation 
status? How all those things interact?
If we still (after a decade!) decide these based on c++ common 
wisdom only than I think something is really broken here. 
Previously valid D syntax is easily broken without much regard 
yet we are still stuck on the comma backwards compatibility to C. 
We ignore all other languages that programmers migrate from to D 
and ignore their common wisdom and experience. Isn't it time for 
D to become its own language instead of a leech on C++ idioms?

Re: Are there any default dmd optimizations

2013-02-27 Thread foobar

On Wednesday, 27 February 2013 at 00:01:31 UTC, Andrei 
Alexandrescu wrote:


I understand how you see it, and honestly could see it from a 
mile. When a post (a) cherry-picks all negatives and (b) has a 
final tone that mentions no possible solution - it's a foregone 
conclusion that no amount of explaining, amending, arguing, 
etc. will improve the poster's outlook.


I could say e.g. Well I think things have changed, and look 
we've turned the bug trend curve (http://goo.gl/kf4ZC) which is 
unprecedented, fixed some incomplete features, break new 
records on bug fixes with each release, and have a big 
conference coming. - to which I have no doubt it's possible to 
concoct a negative answer.


So I understand you have a negative outlook on D. That's 
entirely fine, as is mentioning it on the forum. The only thing 
I'd like you to understand and appreciate is that we who work 
on D are doing our best to find solutions to the various 
problems in front of us, and in quite a literal sense we don't 
know how to do any better. The constructive thing I'm getting 
out of this is that we could use some more radicalization - try 
things that push stronger against our comfort zone. I have a 
few in mind but it's too early to discuss them publicly.



Andrei


Let me emphasize again, I did *not* intend to discuss the 
specific features, Walter brought that topic up. I intended to 
point out the lack of good general guidelines for the D design 
process. And i did actually mention one (partial) solution. I 
mean no disrespect to the hard work of the contributers and did 
not wish to discourage them, just to prevent wasted effort due to 
lack of proper guidelines.
The other criticism I have is exactly the last paragraph above. 
Rust is designed in the open and so I can read the weekly minutes 
and get the bigger picture of the design process, what are the 
different proposed alternatives, what are the considerations and 
trade-offs, etc. In D on the other hand, it's all closed. D 
claims that it is an open source project but all the major design 
decisions happen personally between you and Walter and this is 
worse than big company languages that at least publish some 
articles online.

Re: Are there any default dmd optimizations

2013-02-26 Thread foobar


On Monday, 25 February 2013 at 22:26:33 UTC, Walter Bright wrote:

On 2/25/2013 2:00 PM, foobar wrote:
On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright 
wrote:
By baking one scheme into the language, people will rarely 
feel a need to
reinvent the wheel, and will go on to more productive uses of 
their time.
This is a fallacy caused by the culture of c++ programmers - 
there is exactly

*zero* benefit in baking this into the language.


On the contrary, I think it has turned out rather well. Another 
success story of baking certain things into the language is 
Ddoc. Unittest is a third. They've been big wins for D.


None of those strictly has to be in the language - they can be 
done by convention and 3rd party tools. Nevertheless, 
convenience, standardization and mechanical enforcement of a 
convention seem to work better than applying religious zeal to 
enforce a convention.




DDoc isn't part of the language but rather part of the compiler, 
nevertheless it has its downsides. Being part of the compiler 
means that the compiler needs to be changed to address those and 
it isn't even written in D! The end result is all sort of 
additional auxiliary D utilities to post-process this in order to 
address some of those issues. Hence, A prime example of the 
failure that I'm talking about.


unittest is worse, it is indeed part of the language so now the 
_language grammar_ needs to be changed to fix the problems with 
it, such as not having test names. A far better solution 
practiced in all other major languages is to use annotations and 
in fact, there probably already are similar D frameworks, thus 
exhibiting the same problem of multiple conflicting 
implementations you wished to avoid.


Additional such problems - the AA issue which has been going own 
for years now. The endless discussions regarding tuples.
It seems that D strives to bloat the language with needless 
features that really should have been standardized in the library 
and on the other hand tries to put in the library things that 
really ought to be built into the language to benefit from proper 
integration and syntax.


The latest case was the huge properties debate and its offshoots 
regarding ref semantics which I didn't even bother participate 
in. Bartosz developed an ownership system for D to address all 
the safety issues raised by ref *years ago* and it was rejected 
due to complexity. Now, Andrei tries to achieve similar safety 
guaranties by giving ref the semantics of borrowed pointers. It 
all seems to me like trying to build an airplane without wings 
cause they are too complex. Rust on the other hand already 
integrated an ownership system and is already far ahead of D's 
design. D had talked about macros *years ago* and rust already 
implemented them.




All of this is to say, that instead of trying to fix the c++ 
culture in D, we

should try to create a *better* D culture.


We do have a significantly better D culture than the C++ one. 
For example, C++ relies heavily and unapologetically on 
convention for writing correct, robust code. D eschews that, 
and instead is very biased towards mechanical verification.




I call bullshit. This is an half hearted intention at best.
@safe has holes in it, integers has no overflow checks, ref also 
has holes, Not only D has null pointer bugs but they also cause 
segfaults.





In fact there are many such not c++
features in D and which is why I find other languages such as 
rust a *much*
better design and it evolves much faster because it is 
designed in terms of -

what we want to achieve, how best to implement that.


How does rust handle this particular issue?

Re: Are there any default dmd optimizations

2013-02-26 Thread foobar


On Tuesday, 26 February 2013 at 10:59:41 UTC, Dicebot wrote:
I agree with all but small comment on unit tests : current 
approach makes it really easy to start adding tests for 
projects that do not have them and this is huge. So having 
unittest blocks themselves is really a success feature. 
Tightly coupling handling of this blocks to compiler is an 
issue though.


Again, this is a completely superfluous feature. D already has 
annotations (took only several years to convince Walter to add 
them) which are more flexible and much better suited for this.


@unittest // - this is a unit-test function
void mySuperDuperTestFunction(...);

There is no benefit in having all those special case features in 
the language which have all sorts of integration issues yet deny 
the usefulness of a more general solution generally accepted in 
the programming world, successfully used in many languages and 
thus also familiar to programmers coming from those languages.

Re: Are there any default dmd optimizations

2013-02-26 Thread foobar

On Tuesday, 26 February 2013 at 18:41:24 UTC, Andrej Mitrovic 
wrote:

On 2/26/13, foobar f...@bar.com wrote:

Rust on the other hand already
integrated an ownership system and is already far ahead of D's
design.


Far ahead? It allows things like local variables shadowing 
earlier declarations:


let monster_size = monster_factor * 10.0;
...
let monster_size: int = 50;

That's straight from the tutorial. When has anyone thought to
themselves I need a new variable to store some result to, but 
damn, I
wish I could use an existing name but use it to store a 
completely

different type. That is an incentive to write unreadable code.

And then there are things like this:

Note that, if applied to an integer value, ! flips all the 
bits (like ~ in C).


So (!2 == true)?

There are plenty of complaints for both languages (it's only 
natural),
but saying that Rust is somehow far ahead, I don't buy that one 
bit.
It's all too easy to cherrypick features which are in one 
language and

not in the other.


I don't get what fault you find in the binary NOT operation.
Regardless, my post wasn't really about specific features, 
(Walter actually mentioned those) but rather about the general 
design philosophy of D which I find lacking. Yes, it is obviously 
true that Rust has it own share of faults, The difference is what 
*principals* they use to address those faults and evolve the 
language.
Rust is written in Rust, thus the developers themselves feel all 
the shortcomings, they also listen to their users and they strive 
to find the best way to express the semantics they want in the 
possibly simplest yet readable syntax possible. They think 
positive and build on their vision, whereas D thinks negatively 
based on C++'s vision.
D exists for more than a decade and all it provides is slightly 
less hackish C++.
At first, I dismissed Rust for having poor syntax (ret really? 
Are we back to assembly?) but lo and behold, in a very short time 
they considerably improved the syntax. D still argues about the 
exact same issues from several years ago, as if it's stuck in a 
time loop. This to me shows a lack of direction. I expected thing 
to improve lately with all those newly minted release process 
discussions and such, but alas the attitude hasn't shifted at all.

Re: Are there any default dmd optimizations

2013-02-26 Thread foobar


On Tuesday, 26 February 2013 at 19:53:11 UTC, Walter Bright wrote:

On 2/25/2013 11:56 PM, foobar wrote:
DDoc isn't part of the language but rather part of the 
compiler, nevertheless it

has its downsides.  [...]
unittest is worse,


I think you're missing something gigantic. Before D had ddoc, 
the documentation for Phobos was TERRIBLE - it was mostly 
missing, and the rest would describe something that had no 
resemblance to what the code did. Adding Ddoc completely 
revolutionized this. It's like night and day. Sure, you can 
pick at Ddoc's flaws all day, but without Ddoc, the Phobos 
documentation would have remained utter s**t.


Yes, one could use Doxygen. One could hope an up-to-date 
version exists on all the platforms D is on. One could nag 
people to use it. One could argue with people who wanted to use 
a different doc generator. And one could look at typical C and 
C++ projects, which use no documentation generator at all, and 
pretty much have no documentation or have documentation as bad 
as the pre-Ddoc Phobos docs.


Having Ddoc always there, always installed, always up to date, 
with literally zero effort, tips the balance. It gets used. It 
raised the bar on what is acceptable D code - it looks wrong 
without Ddoc documentation. By tipping the balance I mean it 
*revolutionized* D code.




All of the above describes the benefits of having standardized 
documentation and I agree with that. That has nothing to do with 
DDoc's specific design compared to other similar efforts. A quick 
survey of languages shows that Ruby, Python, Java, C#, and many 
others all have the same benefits but non has the doc generator 
built into the compiler/vm with all the problems this entails.


The same goes for unittest. How many C/C++ projects have you 
run across that have unit tests? Again, yes, you can use 3rd 
party tools (of which there are a plethora). You can try to use 
multiple libraries that use different unit test frameworks. You 
can look at Phobos before unittest and see that it was pretty 
much completely untested.


Unittest in the language, always there, always installed, zero 
effort, completely changed the game. I'm very pleased at the 
depth and breadth of unittests in Phobos. I have no doubt that 
would not have happened without unittest.


Sure, you can pick all day at the flaws of unittest, but you'd 
be missing the point - without builtin unittest, there'd be 
nothing to pick at, because people would not have unit tests.




Same as above. You compare again to C++ and ignore the provably 
successful models of _many_ other languages. Ruby for instance 
really shines in this regard as its community is very much 
oriented towards TDD. Java has such a successful model with its 
JUnit that it inspired a whole bunch of clones for  other 
languges and you completely ignore this. Instead you discuss the 
design of a new car based on experiences of horseback riders.




Additional such problems - the AA issue which has been going 
own for years now.

The endless discussions regarding tuples.
It seems that D strives to bloat the language with needless 
features that really
should have been standardized in the library and on the other 
hand tries to put
in the library things that really ought to be built into the 
language to benefit

from proper integration and syntax.


A little history is in order here. AA's were built in to the 
language from the beginning, a result of my experience with how 
incredibly useful they were in javascript. This was many years 
before D had templates. There was no other way at the time to 
implement them in a nice manner (try doing it in C, for 
example).


D's improving generics has enabled them to be redone as library 
features.




I'm familiar with the history of AAs in D and how they came to be 
this horrible mess. Yet, templates in D are ancient news by now 
and the problem hadn't been fixed and not due to lack of effort. 
The problem is again - applying common c++ wisdom and trying to 
maintain inconsistent semantics.





The latest case was the huge properties debate and its 
offshoots regarding ref
semantics which I didn't even bother participate in. Bartosz 
developed an
ownership system for D to address all the safety issues raised 
by ref *years
ago* and it was rejected due to complexity. Now, Andrei tries 
to achieve similar
safety guaranties by giving ref the semantics of borrowed 
pointers. It all seems
to me like trying to build an airplane without wings cause 
they are too complex.
Rust on the other hand already integrated an ownership system 
and is already far
ahead of D's design. D had talked about macros *years ago* and 
rust already

implemented them.


Bartosz' ownership system was intended to support multithreaded 
programming. It was and still is too complicated. I've been 
working on another design which should serve the purpose and 
will need nearly zero effort from the programmer and it won't 
break anything. There was some

Re: Are there any default dmd optimizations

2013-02-25 Thread foobar


On Sunday, 24 February 2013 at 22:28:46 UTC, Walter Bright wrote:

On 2/24/2013 12:57 PM, Andrej Mitrovic wrote:

On 2/24/13, Jonathan M Davis jmdavisp...@gmx.com wrote:
Yeah, which just adds the confusion, because all it does is 
enable debug

bocks.


The feature almost doesn't pay its weight. I mean technically 
you can
use -version=Debug and then use version(Debug) blocks. All 
`debug`

does is saves a little bit of typing.


I should explain the reasoning for this.

I've talked to many C/C++ programming managers. They lament 
that every C/C++ coding group feels compelled to reinvent their 
own debug macro scheme. This makes it pointlessly difficult to 
share code between groups.


It's not that unlike how pre-C++98 code bases all had their own 
string class.


By baking one scheme into the language, people will rarely feel 
a need to reinvent the wheel, and will go on to more productive 
uses of their time.


This is a fallacy caused by the culture of c++ programmers - 
there is exactly *zero* benefit in baking this into the language.
Yes, I agree with the sentiment that there should be a standard 
way to save programmers the hassle and all that. The correct 
solution to that is a culture of cultivating standard conventions 
and convention over configuration. E.g. Java has many such 
convections followed to a level of religious zeal, such as using 
camelCase everywhere and using PascalCase for types, etc, etc. 
None of which is _enforced by the language_.
On the other hand, many major c++ libraries re-invent string 
even though there exists already std::string and there are even 
libraries that advocate _avoiding_ the use of stl entirely, all 
for the perceived benefit of efficiency which is a prime example 
of premature optimization. Even if there is efficiency gain in a 
specific implementation, ideally it should have been used to 
improve the standard stl::string but trying to change anything in 
the c++ standard is futile - you can't just send a pull request, 
you need to pass boat loads of red tape and wait a decade or two 
for the next version, thus causeing this major NIH attitude.
All of this is to say, that instead of trying to fix the c++ 
culture in D, we should try to create a *better* D culture. When 
you're buying an airplane ticket, what do you say to the travel 
agent? The human reflex of I don't want to go to ___ doesn't 
get you a ticket anywhere. This feature is analogous - it's 
designed to not allow c++ misbehavior, instead of actually 
thinking what we do want and how best to achieve that. In fact 
there are many such not c++ features in D and which is why I 
find other languages such as rust a *much* better design and it 
evolves much faster because it is designed in terms of - what we 
want to achieve, how best to implement that.

Re: Transitioning to the new Release Process

2013-01-15 Thread foobar


On Saturday, 12 January 2013 at 12:20:21 UTC, Johannes Pfau wrote:

Am Sat, 12 Jan 2013 09:22:27 +0100
schrieb foobar f...@bar.com:


[...]

Regarding pull requests targeting master, the current model 
*is* geared around that. Most contributions _should_ go to 
master (aka devel) and go through the full process. 
pull-requests for staging are meant for fixing regressions and 
critical bugs only, where there is _higher urgency_ for the 
fix that justifies the short-cut. Regular bug fixes should 
simply go through the regular process and will be released in 
the _next_ release.


I also think targeting staging for some pull requests is not 
that bad.
In the end it's not that bad if a pull request was accidentally 
merged
into master instead of staging. It just means that it'll take 
more time
for the fix to appear in a release (It'll be delayed by one 
release),

but it won't mess anything up.

Regarding where most requests go: This also depends on the 
project. I
guess for phobos most requests are enhancements/new features 
and would
go to master. For druntime it's mostly bugfixes, so probably 
more
requests target staging. And for the dmd almost everything is a 
bug fix

and could target staging.

The wiki currently says all bug fixes should go to staging. 
This is a
concession to D's rapid development. But again, it's not that 
important
where the pull requests go. We should try to make breaking 
changes in
master and have only harmless changes in staging, but the 
exact

decision is always up to the contributor  maintainers.

But those 'minor' tweaks such as defining what exactly is 
merged to

master and what to staging can always be made later on.


Yea, I agree with the above. I'll just add two additional points:
1. Perhaps it makes sense to have more strict rules for new 
contributors. So Walter, Don, etc could merge straight to 
/staging/ but someone new will need to have a few pull requests 
accepted to master before they are allowed the same privilege.
2. Regarding DMD - it depends on the definition of what a bug 
fix is. There are many bugs regarding conflicts with the spec 
or unimplemented features. Even though these are listed as bugs 
on bugzilla they are really enhancements or new features and 
probably should go through an extra cycle via merging to /master/.
For example, An implementation of auto ref for regular 
functions should really be treated as a new feature (and have a 
full design cycle) even though it's formally listed as a bug.

Re: Transitioning to the new Release Process

2013-01-15 Thread foobar


On Monday, 14 January 2013 at 10:33:56 UTC, mist wrote:
On Saturday, 12 January 2013 at 12:30:05 UTC, Johannes Pfau 
wrote:

Am Fri, 11 Jan 2013 18:54:12 +0100
schrieb mist n...@none.none:

Short comment about cherry pick - it is only bad in sense 
that it
creates separate untrackable commit with same content, which 
may

easily result in merging issues. If there is only one-way
direction for commit transitioning ( stuff goes from master to
staging and LTS and never goes back ) there is nothing 
inherently

bad about cherry pick.


Having multiple commit ids for the same commit is also 
annoying. For
example if someone bisected a regression and you want to 
revert a commit
you have to figure out the commit id of the cherry picked 
commits.




AFAIK reverts are content-based, so knowing any one commit id 
is enough. It is annoying mostly when comparison happens 
between two branches with those commits.



Much more important point is that
it complicates development process for newcomers without any
reasonable benefit. And if we still gonna push for success as 
an
open-source project, being easy understandable by an outsider 
is

as important as a clear release process.

The rule is quite simple and easy to understand though:
regression fix - version branch
bug fix - staging
enhancement - master


Ye, it is easy.. except you need to actually check out wiki 
page to be aware about it. At the very least we need relevant 
excerpts for outer devs separated to one small wiki page and 
set links to this page in github marked with big NB:.


I don't have a reason to argue about the rest.


The default is /master/ so any new dev unfamiliar with the 
process will just get his stuff delayed by one release which 
provides extra safety if you think about it. There is no _need_ 
to read the wiki as the process will work just fine without it. 
it'll just default too the longer, safer option.
I really see no point in arguing this it complicates the 
process point any further.

Re: Transitioning to the new Release Process

2013-01-12 Thread foobar


On Friday, 11 January 2013 at 18:03:33 UTC, mist wrote:
My understanding is that your understanding is somewhat 
different from initial proposal but that is where discussion 
has flow to since then and that makes me sad :)


They very reason to have staging is to have better replacement 
to beta process which simply does not work good enough 
currently. Is good to have a single branch all the time, which 
some obscure project maintainer can check from time to time to 
make sure his stuff still compiles and fire regression bug 
reports if needed. He may even have add this test to own 
continuous integration suite (I'd do this if I had a serious D 
project) to be notified when stuff goes wrong without paying 
any constant attention.


Attention is a key here. How many D projects are out there? How 
many of their maintainers pay close attention to newsgroup and 
read beta mail list? Compare this to being able to check your 
stuff on very next release at any moment you have time and want 
to.


I stand at the point that for open source projects release and 
development processes should care most about end users and 
developers and least - about maintainers. Maintainers should 
have perfect git and process knowledge anyway, or at some 
scales thing are doomed to be crewed (2.061 anyone?).


Thus I vote for a persistent staging branch.



My understanding was that staging is worked on only during the 
(short) time span from initiating a new release and finalizing 
that release.


Andrei


I don't understand the problem you seem to see in the process.

I've been away from the PC so couldn't respond earlier but I did 
manage to read most of the wiki page and I think Johnathan did a 
very good job explaining the various concepts. The only thing 
missing IMO is CI:
It's already agreed that master is the development channel in the 
proposed process. The next logical step would be to generate 
nightly builds off of that branch. The staging branch is the 
beta channel - and also makes sense to have a periodical beta 
build. This depends on the release time span but something like 
fortnight or monthly beta builds makes sense to me.
the additional manual builds described on the wiki on staging or 
even before an official release on the version branch will be 
something like RCs.


Regarding pull requests targeting master, the current model *is* 
geared around that. Most contributions _should_ go to master (aka 
devel) and go through the full process. pull-requests for staging 
are meant for fixing regressions and critical bugs only, where 
there is _higher urgency_ for the fix that justifies the 
short-cut. Regular bug fixes should simply go through the 
regular process and will be released in the _next_ release.

Re: github release procedure

2013-01-03 Thread foobar

On Thursday, 3 January 2013 at 20:42:39 UTC, Johannes Pfau wrote:

Am Thu, 03 Jan 2013 21:17:08 +0100
schrieb Rob T r...@ucora.com:

On Thursday, 3 January 2013 at 19:19:49 UTC, Andrei
Alexandrescu wrote:

On 1/3/13 1:58 PM, Walter Bright wrote:
As I suggested to Jacob, if the wiki lists git command
sequences, it
should be complete (like a script), and not full of
assumptions about

other commands that need to be inserted.

I think this is a pertinent point - the process proposed at
github is incomplete and scantily motivated. Can the experts
make one more pass through it?

Thanks,

Andrei

I'm rather concerned when I see comments that suggest that the
purpose of the staging branch was not understood in the
slightest. There's a lot of discussion on the issue here
http://forum.dlang.org/thread/ka5rv5$2k60$1...@digitalmars.com

Sorry, but I'm not sure if we have a consensus on some things
discussed

there:
This is probably the best summary:
http://forum.dlang.org/thread/ka5rv5$2k60$1...@digitalmars.com?page=16#post-woyboqigqbkqjxmshppn:40forum.dlang.org

4. Feature can than be further refined and _integration bugs_
can

be fixed by the general dev team.

What's the overhead for many small feature branches? DMD work is
probably 90% small bug fixes and 10% bigger features. So most
of the

time there are no integration bugs and we just waste man power
reviewing commits again and copying those into staging?

When the dev branch is considered stable enough by the team
(exact criteria to be defined later), the changes are merged to
the _2nd level of integration_ - the staging branch. This
allows for a wider audience to test and provide real-world
feedback.

The exact criteria would be kinda important. But as we have
many small
bugfixes which are merged every day I don't see how the master
branch

would suddenly get more stable.

What I am most concerned about are the timespans discussed:
I propose to go for a yearly release of the
stable branches with one year support (In the beginning).

The wiki discussion page even mentions I don't think 4 months
are a
ridiculously long time for staging if the release is made every
3

years.

Let's clarify a bunch of things here:
1. There is no overhead with maintaining many feature brunches.
2. Feature branches can be safely removed after their contents
have been merged. This is useful for avoiding clutter.
3. There is no need to re-review the _same_ code on each branch
it is merged to. That's just plain stupid.
4. Chery picking is a HORRIBLE idea for managing releases and
should only be used on development. Chery-picking COPIES commits
and thus loses the connections in the history graph.
5. There is no problem developing bug_fixes on separate topic
branches.

6. There is no problem merging back to master.
7. Let me say this again. Merges are cheap and easy in git. So
are re-merges. Avoiding merges is an artifact of client-server
designs such as SVN and is NOT compatible with Git's conceptual
model.

I suggest to read about how git works and how best to utilize its
features, and NOT apply common wisdom from CVS/SVN/RCS which are
based on a _completely different_ conceptual model.

Re: github release procedure

2013-01-03 Thread foobar

On Thursday, 3 January 2013 at 22:04:28 UTC, Jonathan M Davis 
wrote:

On Thursday, January 03, 2013 21:42:37 Johannes Pfau wrote:

What I am most concerned about are the timespans discussed:
I propose to go for a yearly release of the
stable branches with one year support (In the beginning).

The wiki discussion page even mentions I don't think 4 months 
are a
ridiculously long time for staging if the release is made 
every 3

years.


That makes it sound like they want the current stuff to be 
marked as staging
and then have some other release that sits around for a very 
long time being
treated as somehow more stable than the staging branch. In 
general, there's
nothing about bug fixing which is stable, and separating out 
bug fixes between a
more stable branch and a less stable one doesn't make all that 
much sense.
Separating out new features and not putting them in the 
stable branch makes

sense, but that really doesn't make sense for bugs.

Also, the name staging implies that it's purely for preparing 
a release, in
which case keeping it around makes _no_ sense. Not to mention, 
as already
mentioned, it would make more sense to simply create a new 
branch for each
release to begin with than have a staging branch if that's what 
it's for. And

if that's not what it's for, then it's a horrible name.

- Jonathan M Davis


As I explained several times before, this is a HORRIBLE idea. If 
each release has its own branch than a bug fix needs to be 
applied to _all_ such branches _manually_ and it is easy to get a 
situation where a fix on say version 3.1 was accidentally not 
merged to version 4.0 (forgotten) and suddenly the bug was 
unfixed.
Whatever the name of this branch is, the semantics/purpose of it 
is to provide integration.

Re: moving away from changelog.dd?

2012-12-26 Thread foobar


On Tuesday, 25 December 2012 at 19:44:41 UTC, Walter Bright wrote:

On 12/25/2012 11:19 AM, Jonathan M Davis wrote:

On Tuesday, December 25, 2012 04:18:10 Walter Bright wrote:

On 12/25/2012 3:41 AM, Jonathan M Davis wrote:
I think that that's what most of us are agreed upon at this 
point. What is
currently the WHATSNEW section will continue to be done by 
hand, but the

LIBBUGSFIXED section will be autogenerated.


WHATSNEW is a list of new features, which are (or should be) 
in bugzilla as

enhancement requests.


So, if we put a new module through the review process, we're 
going to go and
create an ehancement request for it after the fact just so 
that it's in

bugzilla and shows up in the automatically generated changelog?


Yes. Recall that there are a pretty small number of these, so 
it's fair to compromise on this.



That seems off
to me. Bugzilla is for reporting bugs or requesting that 
things be added to
the language or library, not for reporting everything that we 
do.

The SCM log is for that.


That log is pretty useless for anyone who wants a list of bug 
fixes and new features, as it is full of commits that are 
irrelevant to users.



Also, some of those sorts of changes should probably get more 
prominence than
they're likely to get in the middle of a list of bugzilla 
issues, or they may

require further explanation.


Full explanations were never what the changelog was for, that's 
why it is a list of clickable links.


And it's not like it takes much time or effort to maintain the 
the WHATSNEW

section, as it's much smaller than the bug fix section.


Nor does it take much time or effort to add 3 enhancement 
requests to Bugzilla for new modules.



Various musings, rationales, future changes, etc., should go 
in a separate

document called releasenotes.

I don't think it's viable to have a document half-generated 
automatically

and half-editted by humans.


I really don't see why not. The section with new stuff gets 
written by hand and
the bug fix section gets created with a bugzilla query. What's 
so hard about

that?


Sure it's possible, but I prefer to keep the complexity down of 
generating the site. Also, releasenotes and changelog serve 
different purposes, it makes sense to have them be separate 
documents. (A future change is NOT a change to the current 
release.)



I don't think that we've been having any problems whatsoever 
dealing

with the WHATSNEW section.


Yes, we have. Things have frequently been omitted.


It seems everyone agrees there need to be an automated changelog 
and a hand written release-notes. I don't see a point to continue 
bikeshading whether they belong in a single document or two 
separate ones. Just pick the one that is easiest to implement! We 
can always add a link to the changelog from the release-notes to 
satisfy those that want a single document.


The more important issue is whether to add bugzilla entries after 
the fact and whether the changelog should be geberated from Git 
or bugzilla.
In the _current_ state of affairs yor (walter) are correct that 
relying on git log messages will be useless. BUT, this is only 
another symptom of the current broken process.
The CORRECT way to implement this would be to take the actual 
changes from the SCM (git) on the RELEASE branch (as opposed to 
the development branch) and filter it to only use MERGE commits. 
What that does is, it ignores all the intermediate development 
commits that are irrelevant.


Filling up bugzilla with entries that do not belong there 
shouldn't be the long term solution.

Re: dlang.org Library Reference

2012-12-23 Thread foobar

On Saturday, 22 December 2012 at 23:04:47 UTC, Andrei 
Alexandrescu wrote:

On 12/22/12 5:10 PM, foobar wrote:
On Friday, 21 December 2012 at 21:58:34 UTC, Jacob Carlborg 
wrote:

On 2012-12-21 18:05, Andrei Alexandrescu wrote:


s/remove/integrate/
s/ugly/awesome/


It's ugly that they are manually created. Over 300 lines of 
comments
that the doc generator should be doing automatically. I would 
say that

is far from awesome.


I would add to that that duplicating both the FS and the D 
module system
by yet another method of grouping symbols is a *horrible* 
notion reeks

of poor design.


What is FS? File system?

Andrei


Yes, FS is the file system. sorry if it wasn't clear.

Any categorization IMO must be made *within* the language and not 
in comments/documentation just as other attributes such as purity 
and constancy are also better served being *within* the language. 
D has plenty of means to accomplish this: code can be organized 
into packages and modules and within a module, free functions can 
be organized within stateless structs for additional namespace 
categorization.


Using an all encompassing algorithms module is also unhelpful 
as all code is essentially an algorithm to accomplish some task. 
This is akin to opening a store called - A store or perhaps A 
place to sell you stuff.
As a client of said shop, I want a better description if I to buy 
at the shop. Even a general Clothes shop is already much 
better. For 3rd party it also often makes sense to have a brand 
name - e.g we all know what vibe.d is all about.

Re: dlang.org Library Reference

2012-12-23 Thread foobar

On Sunday, 23 December 2012 at 13:21:16 UTC, Andrei Alexandrescu 
wrote:

On 12/23/12 6:44 AM, foobar wrote:
Using an all encompassing algorithms module is also 
unhelpful as all
code is essentially an algorithm to accomplish some task. This 
is akin
to opening a store called - A store or perhaps A place to 
sell you

stuff.


That I disagree with a bit. I think it's rather clear that 
std.algorithm includes classic, consecrated algorithms the kind 
you'll find in a book entitled Algorithms. By your argument a 
book called Algorithms would not make sense because it would 
need to describe the entire computing world.


So if I'm looking for sort, I'd open algorithm. If I'm 
looking for parsing program options, I wouldn't expect it to be 
in the same place.


As a client of said shop, I want a better description if I to 
buy at the
shop. Even a general Clothes shop is already much better. 
For 3rd
party it also often makes sense to have a brand name - e.g we 
all know

what vibe.d is all about.


Such differentiation is also useful.


Andrei


Does it mean you agree with the rest? :)

Regarding std.algorithm, the module isn't called - 'classic, 
consecrated algorithms the kind you'll find in a book entitled 
Algorithms'. It is simply called 'std.algorithm' and there are 
many, *many* books on algorithms. Should this module include 
concurrent algorithms? Should it include distributed algorithms? 
Should it include statistic algorithms? Should it include natural 
language processing algorithms? Should it include genetic 
algorithms? I think it's clear by now that the name does not 
convey what you intend it to convey.


A much better and more user friendly scheme would be to classify 
the algorithms by their *functionality* and not by some undefined 
belongs to classical algorithms books relation.

e.g. Sorting algorithms, Set operations, etc.
Now, if I want to sort something I know to shop at the sorting 
algorithms outlet and don't need to spend time going over a 
potentially infinite list of algorithms.

Re: dlang.org Library Reference

2012-12-22 Thread foobar


On Friday, 21 December 2012 at 18:31:48 UTC, Sönke Ludwig wrote:

Am 21.12.2012 18:05, schrieb Andrei Alexandrescu:

(...)

The cheat sheet in std.algorithm is unnecessary (though I 
liked the brief examples), but there's a
lot of value in the symbols grouped by category (searching, 
comparison, ...) at the top. So we need

to have a means to group things in the new interface.


Ideally, we would invent some standard DDOC syntax to specify 
groups then. But generally an
ungrouped list also has its advantages when you try to look 
something up _by name_. I've found
myself in the past, skimming over the category table multiple 
times, looking for a certain function,
until deciding that I had to guess the category first, which 
may not always be obvious.


So maybe keeping the manual category quick index table (and 
maybe putting it in a separate
Categories: section) is a viable option for the time being? 
Most modules probably wouldn't need

one anyway.

What also would be nice is to have the methods inline, 
expandable.


Would that mean the Classes/Structs/... tables as f.ex. in 
std.datetime?
So there would be a small clickable thing and all members would 
fly out below it as direct links?

and possibly with the short description?
What about different kinds of members? Only methods, all 
grouped by type or all in one list?


I'm just asking because I don't have any preferences for how 
such a thing should look like.


Other docs systems provide a sorted index of symbols and also the 
module tree can be further expanded to see the contained symbols. 
Both very handy features.

Re: dlang.org Library Reference

2012-12-22 Thread foobar


On Friday, 21 December 2012 at 21:58:34 UTC, Jacob Carlborg wrote:

On 2012-12-21 18:05, Andrei Alexandrescu wrote:


s/remove/integrate/
s/ugly/awesome/


It's ugly that they are manually created. Over 300 lines of 
comments that the doc generator should be doing automatically. 
I would say that is far from awesome.


I would add to that that duplicating both the FS and the D module 
system by yet another method of grouping symbols is a *horrible* 
notion reeks of poor design.

1 2 3 4 >

1 - 100 of 359 matches

Mail list logo