Re: D versionning

[Walter Bright]

On 7/15/2012 11:48 PM, RivenTheMage wrote:

On Monday, 16 July 2012 at 06:07:21 UTC, Walter Bright wrote:


Changing names is minute progress, and is too costly in terms of annoying
existing users and breaking their code.


Cost can be lowered - by introducing (semi-)automatic refactoring/upgrade mode.

dmd -upgrade zzz.d

Compiler can do renames (clear() -> destroy()), insert
workarounds (if needed), and so on. Easy, fast, no risk of human
error.

Of course, in certain cituations no automatic upgrade is
possible...


It is a good idea, but I'd be nervous myself about allowing the compiler to edit 
my code :-)

Re: D versionning

[RivenTheMage]

On Monday, 16 July 2012 at 06:07:21 UTC, Walter Bright wrote:

Changing names is minute progress, and is too costly in terms 
of annoying existing users and breaking their code.


Cost can be lowered - by introducing (semi-)automatic 
refactoring/upgrade mode.


dmd -upgrade zzz.d

Compiler can do renames (clear() -> destroy()), insert
workarounds (if needed), and so on. Easy, fast, no risk of human
error.

Of course, in certain cituations no automatic upgrade is
possible...

Re: D versionning

[Walter Bright]

On 7/15/2012 11:06 PM, Jonathan M Davis wrote:

And maybe it _was_ worth adding SIMD support now rather than
later, but it goes against what we said we were doing.


It was a leap of faith on my part, but I think events have shown that it was 
indeed worth it.

Re: opApply not called for foeach(container)

[Mehrdad]

On Sunday, 15 July 2012 at 20:01:35 UTC, Jonathan M Davis wrote:

Ideally, we wouldn't even need opApply anymore


AFAIT, that's impossible.

Not because of D, but because of other stuff.

Lots of functions require callbacks for enumeration (e.g. 
EnumChildWindows in Windows); it's simply impossible to wrap them 
through something that doesn't take control away from the caller.

Re: D versionning

[Jonathan M Davis]

On Sunday, July 15, 2012 22:55:40 Walter Bright wrote:
> On 7/15/2012 5:36 PM, Jonathan M Davis wrote:
> > Arguably, we've been adding too many new features (e.g. new lambda syntax
> > and SIMD support), given that we're supposed to be making everything that
> > we already  have work properly, but those features haven't been breaking
> > changes, and presumably forcing Walter to just fix bugs wouldn't be all
> > that pleasant for him.
> 
> SIMD support is critical for D's mission as a systems programming language,
> and has been important in attracting some significant adoption of D.

Oh, I'm not saying that the feature isn't valuable. I'm just pointing out that 
it's adding something new rather than actually finishing all of the features 
that we're already supposed to have, and in theory, after TDPL's release, we 
were supposed to be avoiding adding new features which we didn't need to make 
all of the existing features work until we'd finished all of the features 
outlined in TDPL. And maybe it _was_ worth adding SIMD support now rather than 
later, but it goes against what we said we were doing.

- Jonathan M Davis

Re: D versionning

[Walter Bright]

On 7/15/2012 4:53 PM, deadalnix wrote:

On 16/07/2012 01:07, Walter Bright wrote:

It needs to stop completely.



No. It hasn't been made for no reasons.

But yes, some code is broken in the process. This is exactly why we need a more
sophisticated versionning process (note the recurring pattern in my posts :D ).

The fact that some people have legacy code shouldn't stop D progress. But with
the current system, D must either break code or make no progress.


Changing names is minute progress, and is too costly in terms of annoying 
existing users and breaking their code.

Re: D versionning

[Walter Bright]

On 7/15/2012 4:34 PM, Jonathan M Davis wrote:

It needs to stop completely.


Most of the renaming of functions which has gone on has been because Phobos
has been inconsistent with its naming, which makes it harder to use and learn.
As that's sorted out (as has mostly been done), those changes will stop. But
do you honestly expect that everything in the standard library is going to be
frozen at some point? Is that what you're suggesting?


I've had a lot of my own working D code break because of name changes in Phobos. 
This is extremely annoying. I can fully understand that it drives people away. 
It's got to stop.


We could bikeshed forever about what exact spelling and casing a name should 
have. That's fine for new names. Old names should stay.


Breaking things should have a very high bar. Merely a name change is not good 
enough.

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 23:00:01 -0700, Walter Bright  
 wrote:



On 7/15/2012 5:45 PM, Adam Wilson wrote:
I think the problem is that in the real world, that state is somewhat  
unlikely.
For example, Walter is currently working on COFF support, this is  
arguably a new
feature (we already can make programs work on Windows). Programmers  
aren't
machines and fixing bugs all day is boring, we want to do the fun  
stuff, in this
case, new features. It just so happens that it's the fun stuff that  
makes fixing
bugs bearable. I don't think it's fair of us to demand that Walter only  
fix
bugs, besides, COFF support is a HIGHLY requested new feature, he is  
just

supposed to ignore them?


Supporting Win64 is absolutely critical for the future of D, and the  
sooner we get it, the better. The COFF route is the shortest route to  
doing it, and the most practical for attracting devs, which is why it's  
the way we're going.


32 bit code is dead on OSX, is dying rapidly on Linux and Windows.


I absolutely agree with this, but you already know that. I've been  
lobbying for COFF ever since I first showed up here. :-)


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Walter Bright]

On 7/15/2012 5:45 PM, Adam Wilson wrote:

I think the problem is that in the real world, that state is somewhat unlikely.
For example, Walter is currently working on COFF support, this is arguably a new
feature (we already can make programs work on Windows). Programmers aren't
machines and fixing bugs all day is boring, we want to do the fun stuff, in this
case, new features. It just so happens that it's the fun stuff that makes fixing
bugs bearable. I don't think it's fair of us to demand that Walter only fix
bugs, besides, COFF support is a HIGHLY requested new feature, he is just
supposed to ignore them?


Supporting Win64 is absolutely critical for the future of D, and the sooner we 
get it, the better. The COFF route is the shortest route to doing it, and the 
most practical for attracting devs, which is why it's the way we're going.


32 bit code is dead on OSX, is dying rapidly on Linux and Windows.

Re: D versionning

[Walter Bright]

On 7/15/2012 5:36 PM, Jonathan M Davis wrote:

Arguably, we've been adding too many new features (e.g. new lambda syntax and
SIMD support), given that we're supposed to be making everything that we
already  have work properly, but those features haven't been breaking changes,
and presumably forcing Walter to just fix bugs wouldn't be all that pleasant
for him.


SIMD support is critical for D's mission as a systems programming language, and 
has been important in attracting some significant adoption of D.

Re: D versionning

[captaindet]

On 2012-07-15 17:35, Walter Bright wrote:

On 7/15/2012 10:25 AM, captaindet wrote:

pls make a fresh build available on a weekly or at least biweekly basis, just
with regressions fixed.


2.059 had only 3 outstanding regressions.


my bad. i got the impression regressions were a bigger issue.

just want to add that i am really happy 64bit for windows is about to happen. i 
should not whinge if this means other things have to slow down a bit for the 
time being. after all, i am not helping but just enjoying the free beer...

/det

Re: Some guidance on writing a Deimos C library interface

[Jens Mueller]

Jacob Carlborg wrote:
> On 2012-07-14 05:24, Jens Mueller wrote:
> >Hi,
> >
> >there is some documentation on writing a Deimos interface.
> >E.g.
> >http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP12
> >http://dlang.org/interfaceToC.html
> >
> >I'd like to get a list of rules that one has to follow.
> >
> >First you have to convert the name of the header file to a valid D
> >module name. Therefore, I found/came up with the following rules:
> >* a slash (/) has to be replaced by a dot (.)
> >* a dash (-) has to be replaced by a dot (.)
> >* a D keyword gets a underscore (_) appended
> >
> >Maybe someone can commented on them. I suppose there are even more.
> >These are just the ones I encountered.
> >
> >Some questions on module names I could not find a definite answer for:
> >1. The D page says they should be lower case. Should Deimos module names
> >also be made lower case?
> >2. Should all interfaces be put in a common package, say deimos?
> >
> >Translating the header file itself is pretty straightforward following
> >http://dlang.org/interfaceToC.html. Though some cases are not covered:
> >* E.g. use core.stdc.stdint for standard C types.
> 
> I would say that when a C typedef has a corresponding type in D, use
> that instead of an alias. For example:
> 
> int8_t -> use byte
> int32_t -> use int
> 
> But one need to make sure that the typedef resolves to the same D
> type on all platforms.

By using core.stdc.stdint I'm safe, right? I mean int8_t is just an
alias in core.stdc.stdint. I'd like to change the header file as little
as possible.

> >* const T* should be replaced with const(T)*
> >* How to deal with macros?
> >
> >Can we write a recipe like guide for writing a Deimos interface?
> 
> You can have a look at dstep for automatically translate
> C/Objective-C headers: https://github.com/jacob-carlborg/dstep

Usually, the changes are straightforward. It's just these little things
where is no clear rule that cost time.

Jens

Re: Some guidance on writing a Deimos C library interface

[Jens Mueller]

Johannes Pfau wrote:
> Am Sat, 14 Jul 2012 05:24:50 +0200
> schrieb Jens Mueller :
> 
> > * const T* should be replaced with const(T)*
> 
> When it's a function parameter you could even make it const(T*):
> void hello(const char *name);
> --> extern(C) void hello(const(char*) name);
> 
> as the pointer itself is passed by value, there's no way it could be
> modified by hello. DMD should be able to figure that out and treat
> const(char)* exactly the same, but last time I checked it didn't.

Very true. But just to be on the safe side I think replacing it with
const(T)* is better.

> > * How to deal with macros?
> There are different solutions. Some people prefer to make those
> templates, so the binding can be used as a .di file and doesn't need to
> be compiled. Others just use functions and hope the optimizer will
> inline it ;-)

I see.

Jens

Re: Some guidance on writing a Deimos C library interface

[Jens Mueller]

Jonathan M Davis wrote:
> On Sunday, July 15, 2012 08:14:22 Jens Mueller wrote:
> > dnewbie wrote:
> > > >2. Should all interfaces be put in a common package, say deimos?
> > > 
> > > Yes.
> > 
> > Why is this? What is the rational behind it?
> > Because some Deimos projects seem not to follow it.
> 
> It thought that it was decided that that it was _bad_ idea to have any kind 
> of 
> deimos package when it was discussed previously, but I don't remember what 
> all 
> was discussed about it or when. Presumably, it's in the newsgroup archives 
> somewhere though.

I found
http://www.digitalmars.com/d/archives/digitalmars/D/Deimos_Consistent_structure_149602.html#N149602

But there is no consensus.

Jens

Re: D versionning

[Andrei Alexandrescu]

On 7/15/12 9:21 PM, deadalnix wrote:

What would be the difference betwwen dmd head and unstable ?

Isn't it more simple to merge in unstable only or both unstable and
bugfix at first ?


I think you're right, we only need the "stable/bugfix" branch.

Andrei

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 18:28:36 -0700, Adam Wilson  wrote:

On Sun, 15 Jul 2012 18:11:12 -0700, Andrei Alexandrescu  
 wrote:



On 7/15/12 7:44 PM, Adam Wilson wrote:

I should note that we use this exact model for every project we have
where I work and that it is been highly successful at keeping those  
five

points of tension moderated. And our users can actually get work done
without waiting for weeks and months because thing X is just plain
broken, which in turn makes us look good. (Improving Loyalty)


Allow me to propose something.

Right now all dmd changes get merged in the head. Suppose we find a  
volunteer in the community who is:


1. Highly motivated

2. With a good understanding of D

3. Expert with git

4. Reliable

I wonder if it's possible that that person cherry-picks commits from  
HEAD into two separate branches: bugfixes and unstable. It should be  
easy to create installers etc. for those.


If we see this works well and gathers steady interest, we can improve  
it and make it the practice of the entire team.


Would this be possible?


Andrei


I like this, A LOT! This is a nice twist on the proposed model and I  
think it improves on the process. It certainly means that no release is  
predicated on the state of HEAD, which is a fantastic achievement. And  
this process certainly wasn't possible prior to git.


It also achieves to goal of separate branches for unstable work and  
stable bugfixes.


I may just co-opt this for my projects at work!

However, this is all predicated on finding such a person, of which few  
exist. But I would argue that it should NOT fall on to someone in the  
core team (Walter, Kenji, Braddr, Don, etc.), they should be working on  
the compiler HEAD.


There must be someone out there with decent knowledge of the internals  
and yet doesn't consider themselves core team, but the biggest them I  
think is going to be the time, which is why I think it shouldn't be a  
core team member.


Actually, here is another idea. How about we train someone who maybe has  
some experience with the compiler but might not know what to do in all  
situations. If they had direct access to Walter and the Core Team, they  
could be quickly brought up to speed on the job so to speak. And it  
would widen our potential volunteer poll.
Plus it would widen the number of team members who are deeply involved  
with the compiler. Reducing our bus-factor is always a very good thing.


If the core team was willing to accept an apprentice, then I would be  
willing to learn. As far as git goes, the only thing I don't have much  
experience with is reversions, the rest I can handle, we use git  
internally at work so it's very familiar to me. But I'd want to see if  
anyone else more qualified than I was willing to volunteer first!




As an addition to my training proposal, I submit that we make it two  
people, to account for vacations and other times when one person may not  
be available. Although I imagine that anything beyond two people might be  
a little more than the core team can handle, and I can't see it being that  
much work that we'd need three people.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 18:38:37 -0700, Alex Rønne Petersen   
wrote:



On 16-07-2012 03:11, Andrei Alexandrescu wrote:

On 7/15/12 7:44 PM, Adam Wilson wrote:

I should note that we use this exact model for every project we have
where I work and that it is been highly successful at keeping those  
five

points of tension moderated. And our users can actually get work done
without waiting for weeks and months because thing X is just plain
broken, which in turn makes us look good. (Improving Loyalty)


Allow me to propose something.

Right now all dmd changes get merged in the head. Suppose we find a
volunteer in the community who is:

1. Highly motivated

2. With a good understanding of D

3. Expert with git

4. Reliable

I wonder if it's possible that that person cherry-picks commits from
HEAD into two separate branches: bugfixes and unstable. It should be
easy to create installers etc. for those.

If we see this works well and gathers steady interest, we can improve it
and make it the practice of the entire team.

Would this be possible?


Andrei



I propose a slight variation:

* master: This is the 'incoming' branch. Unstable, in-dev, etc. It's  
easier this way since pull requests will usually target this branch and  
build bots will test this.
* stable: This branch contains only bug fixes to existing language  
features, and enhancements that do not in any way impact existing  
features (or break code). Should be manually maintained based on master.


That's it. I don't see a need for any added complexity to this simple  
model. Feel free to destroy as you see fit, though!


I think this would work very well. When it comes time to roll out new  
features, you could just merge master into stable and you've got a brand  
new stable release, tag it, build an installer, and you're done.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Jonathan M Davis]

On Monday, July 16, 2012 03:38:37 Alex Rønne Petersen wrote:
> I propose a slight variation:
> 
> * master: This is the 'incoming' branch. Unstable, in-dev, etc. It's
> easier this way since pull requests will usually target this branch and
> build bots will test this.
> * stable: This branch contains only bug fixes to existing language
> features, and enhancements that do not in any way impact existing
> features (or break code). Should be manually maintained based on master.
> 
> That's it. I don't see a need for any added complexity to this simple
> model. Feel free to destroy as you see fit, though!

I agree that that's probably better, since I don't see much point in 
separating unstable from master either, but the main problem is still having 
someone who is able and willing to do the merging into the bug fix branch.

- Jonathan M Davis

Re: D versionning

[Alex Rønne Petersen]

On 16-07-2012 03:11, Andrei Alexandrescu wrote:

On 7/15/12 7:44 PM, Adam Wilson wrote:

I should note that we use this exact model for every project we have
where I work and that it is been highly successful at keeping those five
points of tension moderated. And our users can actually get work done
without waiting for weeks and months because thing X is just plain
broken, which in turn makes us look good. (Improving Loyalty)


Allow me to propose something.

Right now all dmd changes get merged in the head. Suppose we find a
volunteer in the community who is:

1. Highly motivated

2. With a good understanding of D

3. Expert with git

4. Reliable

I wonder if it's possible that that person cherry-picks commits from
HEAD into two separate branches: bugfixes and unstable. It should be
easy to create installers etc. for those.

If we see this works well and gathers steady interest, we can improve it
and make it the practice of the entire team.

Would this be possible?


Andrei



I propose a slight variation:

* master: This is the 'incoming' branch. Unstable, in-dev, etc. It's 
easier this way since pull requests will usually target this branch and 
build bots will test this.
* stable: This branch contains only bug fixes to existing language 
features, and enhancements that do not in any way impact existing 
features (or break code). Should be manually maintained based on master.


That's it. I don't see a need for any added complexity to this simple 
model. Feel free to destroy as you see fit, though!


--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 18:11:12 -0700, Andrei Alexandrescu  
 wrote:



On 7/15/12 7:44 PM, Adam Wilson wrote:

I should note that we use this exact model for every project we have
where I work and that it is been highly successful at keeping those five
points of tension moderated. And our users can actually get work done
without waiting for weeks and months because thing X is just plain
broken, which in turn makes us look good. (Improving Loyalty)


Allow me to propose something.

Right now all dmd changes get merged in the head. Suppose we find a  
volunteer in the community who is:


1. Highly motivated

2. With a good understanding of D

3. Expert with git

4. Reliable

I wonder if it's possible that that person cherry-picks commits from  
HEAD into two separate branches: bugfixes and unstable. It should be  
easy to create installers etc. for those.


If we see this works well and gathers steady interest, we can improve it  
and make it the practice of the entire team.


Would this be possible?


Andrei


I like this, A LOT! This is a nice twist on the proposed model and I think  
it improves on the process. It certainly means that no release is  
predicated on the state of HEAD, which is a fantastic achievement. And  
this process certainly wasn't possible prior to git.


It also achieves to goal of separate branches for unstable work and stable  
bugfixes.


I may just co-opt this for my projects at work!

However, this is all predicated on finding such a person, of which few  
exist. But I would argue that it should NOT fall on to someone in the core  
team (Walter, Kenji, Braddr, Don, etc.), they should be working on the  
compiler HEAD.


There must be someone out there with decent knowledge of the internals and  
yet doesn't consider themselves core team, but the biggest them I think is  
going to be the time, which is why I think it shouldn't be a core team  
member.


Actually, here is another idea. How about we train someone who maybe has  
some experience with the compiler but might not know what to do in all  
situations. If they had direct access to Walter and the Core Team, they  
could be quickly brought up to speed on the job so to speak. And it would  
widen our potential volunteer poll.
Plus it would widen the number of team members who are deeply involved  
with the compiler. Reducing our bus-factor is always a very good thing.


If the core team was willing to accept an apprentice, then I would be  
willing to learn. As far as git goes, the only thing I don't have much  
experience with is reversions, the rest I can handle, we use git  
internally at work so it's very familiar to me. But I'd want to see if  
anyone else more qualified than I was willing to volunteer first!


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[deadalnix]

On 16/07/2012 03:11, Andrei Alexandrescu wrote:

On 7/15/12 7:44 PM, Adam Wilson wrote:

I should note that we use this exact model for every project we have
where I work and that it is been highly successful at keeping those five
points of tension moderated. And our users can actually get work done
without waiting for weeks and months because thing X is just plain
broken, which in turn makes us look good. (Improving Loyalty)


Allow me to propose something.

Right now all dmd changes get merged in the head. Suppose we find a
volunteer in the community who is:

1. Highly motivated

2. With a good understanding of D

3. Expert with git

4. Reliable

I wonder if it's possible that that person cherry-picks commits from
HEAD into two separate branches: bugfixes and unstable. It should be
easy to create installers etc. for those.

If we see this works well and gathers steady interest, we can improve it
and make it the practice of the entire team.

Would this be possible?


Andrei



What would be the difference betwwen dmd head and unstable ?

Isn't it more simple to merge in unstable only or both unstable and 
bugfix at first ?

Re: D versionning

[Jonathan M Davis]

On Sunday, July 15, 2012 21:11:12 Andrei Alexandrescu wrote:
> On 7/15/12 7:44 PM, Adam Wilson wrote:
> > I should note that we use this exact model for every project we have
> > where I work and that it is been highly successful at keeping those five
> > points of tension moderated. And our users can actually get work done
> > without waiting for weeks and months because thing X is just plain
> > broken, which in turn makes us look good. (Improving Loyalty)
> 
> Allow me to propose something.
> 
> Right now all dmd changes get merged in the head. Suppose we find a
> volunteer in the community who is:
> 
> 1. Highly motivated
> 
> 2. With a good understanding of D
> 
> 3. Expert with git
> 
> 4. Reliable
> 
> I wonder if it's possible that that person cherry-picks commits from
> HEAD into two separate branches: bugfixes and unstable. It should be
> easy to create installers etc. for those.
> 
> If we see this works well and gathers steady interest, we can improve it
> and make it the practice of the entire team.
> 
> Would this be possible?

I'm sure it's possible. The problem is that it requires someone who 
understands the compiler well enough to do it and is willing to take the time 
to do it. Such a person could be very hard to find. It would probably require 
that one of our primary contributors to the compiler use some of the time that 
they've been using for that to maintain the new bug fix-only branch. It may 
very well be worth it to do so, but we'll need a volunteer.

- Jonathan M Davis

Re: D versionning

[Andrei Alexandrescu]

On 7/15/12 7:44 PM, Adam Wilson wrote:

I should note that we use this exact model for every project we have
where I work and that it is been highly successful at keeping those five
points of tension moderated. And our users can actually get work done
without waiting for weeks and months because thing X is just plain
broken, which in turn makes us look good. (Improving Loyalty)


Allow me to propose something.

Right now all dmd changes get merged in the head. Suppose we find a 
volunteer in the community who is:


1. Highly motivated

2. With a good understanding of D

3. Expert with git

4. Reliable

I wonder if it's possible that that person cherry-picks commits from 
HEAD into two separate branches: bugfixes and unstable. It should be 
easy to create installers etc. for those.


If we see this works well and gathers steady interest, we can improve it 
and make it the practice of the entire team.


Would this be possible?


Andrei

Re: D versionning

[nazriel]

On Monday, 16 July 2012 at 01:06:16 UTC, Adam Wilson wrote:
On Sun, 15 Jul 2012 18:01:41 -0700, Andrei Alexandrescu 
 wrote:



On 7/15/12 7:15 PM, Patrick Stewart wrote:
We are coming back to dsource&  Tango graveyard story. D had 
equally
capable and large community to. Its resources got wasted. 
People

left. Huge amount of work just wasted for nothing.


Actually a couple of weeks ago I was curious and collected a 
few statistics about the frequency of posts, number of 
posters, and such. The numbers are not yet in shape to be 
published, but from what I gathered so far there was no 
visible glitch around the D1/D2 divergence. There's a strong 
increase since 2011, but I couldn't yet gather an exponential 
trend.



On the other hand,
Python has one of the largest *operational* standard library 
and tons
of 3rd party ones. Why? Because with stable language, all 
those

libraries stayed in the game.


Agreed, we have much to learn from Python and other successful 
languages.


I assume those procedures and protocols materialized together 
with strong growth of the community, and may be difficult to 
transplant to our team. Right now my main focus as an 
organizer is to make sure people's cycles are spent on 
productive, high-impact work. Right now Walter is working on 
Win64, which is of very high impact. A change of procedure 
right now would simply mean time taken away from that task.


Finally, since you are interested in effecting durable 
positive change in D's development, I'll venture that perhaps 
you're not going the best way about it. Your posts attempt 
almost with no exception to inflame, and there's no 
contribution I know of in your name. That all reduces the 
credibility of your points, however merit there may be in them.



Thanks,

Andrei


I would like to state that I am all for waiting onr Win64; it's 
a huge project and trying to do this change in the middle of it 
would be the height of stupidity. However, directly after Win64 
goes live I move that we make the dual branch model the default 
going forward as it solves too many long-standing community 
complaints to reasonably dismiss.


+1

I think that model proposed by deadalnix would drastically 
increase productivity  of D development cycle and would cover 
needs of those who like to feel "stable" with their software.


Lets learn from bigger, successful projects :)

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 18:01:41 -0700, Andrei Alexandrescu  
 wrote:



On 7/15/12 7:15 PM, Patrick Stewart wrote:

We are coming back to dsource&  Tango graveyard story. D had equally
capable and large community to. Its resources got wasted. People
left. Huge amount of work just wasted for nothing.


Actually a couple of weeks ago I was curious and collected a few  
statistics about the frequency of posts, number of posters, and such.  
The numbers are not yet in shape to be published, but from what I  
gathered so far there was no visible glitch around the D1/D2 divergence.  
There's a strong increase since 2011, but I couldn't yet gather an  
exponential trend.



On the other hand,
Python has one of the largest *operational* standard library and tons
of 3rd party ones. Why? Because with stable language, all those
libraries stayed in the game.


Agreed, we have much to learn from Python and other successful languages.

I assume those procedures and protocols materialized together with  
strong growth of the community, and may be difficult to transplant to  
our team. Right now my main focus as an organizer is to make sure  
people's cycles are spent on productive, high-impact work. Right now  
Walter is working on Win64, which is of very high impact. A change of  
procedure right now would simply mean time taken away from that task.


Finally, since you are interested in effecting durable positive change  
in D's development, I'll venture that perhaps you're not going the best  
way about it. Your posts attempt almost with no exception to inflame,  
and there's no contribution I know of in your name. That all reduces the  
credibility of your points, however merit there may be in them.



Thanks,

Andrei


I would like to state that I am all for waiting onr Win64; it's a huge  
project and trying to do this change in the middle of it would be the  
height of stupidity. However, directly after Win64 goes live I move that  
we make the dual branch model the default going forward as it solves too  
many long-standing community complaints to reasonably dismiss.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Andrei Alexandrescu]

On 7/15/12 7:15 PM, Patrick Stewart wrote:

We are coming back to dsource&  Tango graveyard story. D had equally
capable and large community to. Its resources got wasted. People
left. Huge amount of work just wasted for nothing.


Actually a couple of weeks ago I was curious and collected a few 
statistics about the frequency of posts, number of posters, and such. 
The numbers are not yet in shape to be published, but from what I 
gathered so far there was no visible glitch around the D1/D2 divergence. 
There's a strong increase since 2011, but I couldn't yet gather an 
exponential trend.



On the other hand,
Python has one of the largest *operational* standard library and tons
of 3rd party ones. Why? Because with stable language, all those
libraries stayed in the game.


Agreed, we have much to learn from Python and other successful languages.

I assume those procedures and protocols materialized together with 
strong growth of the community, and may be difficult to transplant to 
our team. Right now my main focus as an organizer is to make sure 
people's cycles are spent on productive, high-impact work. Right now 
Walter is working on Win64, which is of very high impact. A change of 
procedure right now would simply mean time taken away from that task.


Finally, since you are interested in effecting durable positive change 
in D's development, I'll venture that perhaps you're not going the best 
way about it. Your posts attempt almost with no exception to inflame, 
and there's no contribution I know of in your name. That all reduces the 
credibility of your points, however merit there may be in them.



Thanks,

Andrei

Re: D versionning

[Jonathan M Davis]

On Sunday, July 15, 2012 20:43:52 Andrei Alexandrescu wrote:
> The key is that the branches are merged once a more risky branch is
> stable enough, and the essential ingredient is that git makes branch
> merging easy.

Yes. This is a huge advantage to using git. It's actually reasonably sane to 
maintain multiple branches.

- Jonathan M Davis

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 17:36:28 -0700, Jonathan M Davis   
wrote:



On Sunday, July 15, 2012 17:23:44 Adam Wilson wrote:

I guess I just see it as differing definitions of "stable". For example,
dsimcha was here not twenty hours ago praising D for how stable it's
become.

I think this is a pretty good summation of stable in the community  
project

context:
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html

Note: We meet all criteria for stable.


What I want to see is dmd having fully implemented all of the features  
in TDPL

(e.g. multiple alias thises) and sorted out all of the major design or
implementation issues (e.g. the issues with const and Object). After  
that, D2
has been fully implemented, and we can look at adding new features if we  
want
to and restricting those as well as any breaking changes that we need to  
make
to a different branch which only gets merged into the main branch in  
certain

releases.

Arguably, we've been adding too many new features (e.g. new lambda  
syntax and

SIMD support), given that we're supposed to be making everything that we
already  have work properly, but those features haven't been breaking  
changes,
and presumably forcing Walter to just fix bugs wouldn't be all that  
pleasant
for him. But until we've fully implemented what we have, I think that  
it's
just going to slow us down to little benefit to change the release  
model. Once
we have, _then_ I'd love to see a release model which promotes major vs  
minor
releases and the like, because then we can evolve the language and  
library as
appropriate while still maintaining stable releases which programmers  
can rely

on for long periods of time without worrying about breaking changes and
whatnot.

- Jonathan M Davis


I think the problem is that in the real world, that state is somewhat  
unlikely. For example, Walter is currently working on COFF support, this  
is arguably a new feature (we already can make programs work on Windows).  
Programmers aren't machines and fixing bugs all day is boring, we want to  
do the fun stuff, in this case, new features. It just so happens that it's  
the fun stuff that makes fixing bugs bearable. I don't think it's fair of  
us to demand that Walter only fix bugs, besides, COFF support is a HIGHLY  
requested new feature, he is just supposed to ignore them?


It is never easy deciding which new features to add versus which bugs to  
fix, but that's the beauty of this model, you don't have to. You just do  
both.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Andrei Alexandrescu]

On 7/15/12 7:06 PM, Walter Bright wrote:

Frankly, I don't know how to do what you're asking for. D users, every
single day, clamor for:

1. more bug fixes
2. more new features
3. why aren't deprecated features removed more quickly?
4. why don't we add this breaking feature?
5. why did you add that breaking feature which broke my code?

Often, these are the same people! Sometimes, even in the same post!

And, to reiterate, we did release D1. Since its release, it has only
received bug fixes. No breaking changes, no regressions. This,
inevitably, has made many D1 users unhappy - they wanted new features
folded in.

So that was not satisfactory, either.

Yes, I do feel a bit put upon by this, as I see no way to satisfy all
these mutually contradictory requests.


I think you're conflating two different trends. One is the annoying one 
you mentioned, and the other is a very reasonable request - that D has 
one branch containing only bug fixes, and another branch with new 
features and other potentially disruptive things.


The key is that the branches are merged once a more risky branch is 
stable enough, and the essential ingredient is that git makes branch 
merging easy.


This is not something you could have done essentially at any pre-github 
time in D's history, and is not to be confused with D1 vs D2 or with the 
known contradictory requests.



Andrei

Re: D versionning

[Jonathan M Davis]

On Sunday, July 15, 2012 17:23:44 Adam Wilson wrote:
> I guess I just see it as differing definitions of "stable". For example,
> dsimcha was here not twenty hours ago praising D for how stable it's
> become.
> 
> I think this is a pretty good summation of stable in the community project
> context:
> http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
> 
> Note: We meet all criteria for stable.

What I want to see is dmd having fully implemented all of the features in TDPL 
(e.g. multiple alias thises) and sorted out all of the major design or 
implementation issues (e.g. the issues with const and Object). After that, D2 
has been fully implemented, and we can look at adding new features if we want 
to and restricting those as well as any breaking changes that we need to make 
to a different branch which only gets merged into the main branch in certain 
releases.

Arguably, we've been adding too many new features (e.g. new lambda syntax and 
SIMD support), given that we're supposed to be making everything that we 
already  have work properly, but those features haven't been breaking changes, 
and presumably forcing Walter to just fix bugs wouldn't be all that pleasant 
for him. But until we've fully implemented what we have, I think that it's 
just going to slow us down to little benefit to change the release model. Once 
we have, _then_ I'd love to see a release model which promotes major vs minor 
releases and the like, because then we can evolve the language and library as 
appropriate while still maintaining stable releases which programmers can rely 
on for long periods of time without worrying about breaking changes and 
whatnot.

- Jonathan M Davis

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 17:20:33 -0700, Jonathan M Davis   
wrote:



On Monday, July 16, 2012 02:07:13 deadalnix wrote:

On 16/07/2012 01:42, Jonathan M Davis wrote:
> On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:
>> Sigh. Half say we release too often, the other half not often enough.
>
> Which is actually one argument for going to a model where you have
> frequent
> minor releases which only contain bug fixes and less frequent major
> releases with the larger changes. You can never make everyone happy,  
but
> by doing so, you get the bug fixes faster for the folks complaining  
about
> the lack of frequent releases, and you get increased stability as far  
as

> the new stuff goes, because it doesn't come with every release.
>
> I'm only against the proposed versioning scheme because I think that  
we
> need to stabilize things better (e.g. actually have all of the  
features

> that TDPL lists fully implemented) before we move to it. But I fully
> support moving to this sort of scheme in the long run. It manages  
change

> much better, and I think that many, many existing projects have shown
> that it promotes stable code bases while still allowing for them to
> evolve as necessary.
>
> - Jonathan M Davis

The proposed scheme is only a proposed scheme. Other solutions exist
that solve the problem, and if they better fit, why not ?


If someone has a better proposal, they should make it (though probably  
in a
separate thread - this one's long enough as it is). I think that the  
basics of
this proposal are good, and a lot of projects work that way. I just  
think that

D needs to be more stable before we worry about having major and minor
releases or stable and unstable branches.

- Jonathan M Davis


I guess I just see it as differing definitions of "stable". For example,  
dsimcha was here not twenty hours ago praising D for how stable it's  
become.


I think this is a pretty good summation of stable in the community project  
context:

http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html

Note: We meet all criteria for stable.

--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Jonathan M Davis]

On Monday, July 16, 2012 02:07:13 deadalnix wrote:
> On 16/07/2012 01:42, Jonathan M Davis wrote:
> > On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:
> >> Sigh. Half say we release too often, the other half not often enough.
> > 
> > Which is actually one argument for going to a model where you have
> > frequent
> > minor releases which only contain bug fixes and less frequent major
> > releases with the larger changes. You can never make everyone happy, but
> > by doing so, you get the bug fixes faster for the folks complaining about
> > the lack of frequent releases, and you get increased stability as far as
> > the new stuff goes, because it doesn't come with every release.
> > 
> > I'm only against the proposed versioning scheme because I think that we
> > need to stabilize things better (e.g. actually have all of the features
> > that TDPL lists fully implemented) before we move to it. But I fully
> > support moving to this sort of scheme in the long run. It manages change
> > much better, and I think that many, many existing projects have shown
> > that it promotes stable code bases while still allowing for them to
> > evolve as necessary.
> > 
> > - Jonathan M Davis
> 
> The proposed scheme is only a proposed scheme. Other solutions exist
> that solve the problem, and if they better fit, why not ?

If someone has a better proposal, they should make it (though probably in a 
separate thread - this one's long enough as it is). I think that the basics of 
this proposal are good, and a lot of projects work that way. I just think that 
D needs to be more stable before we worry about having major and minor 
releases or stable and unstable branches.

- Jonathan M Davis

Re: D versionning

[deadalnix]

On 16/07/2012 01:42, Jonathan M Davis wrote:

On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:

Sigh. Half say we release too often, the other half not often enough.


Which is actually one argument for going to a model where you have frequent
minor releases which only contain bug fixes and less frequent major releases
with the larger changes. You can never make everyone happy, but by doing so,
you get the bug fixes faster for the folks complaining about the lack of
frequent releases, and you get increased stability as far as the new stuff
goes, because it doesn't come with every release.

I'm only against the proposed versioning scheme because I think that we need
to stabilize things better (e.g. actually have all of the features that TDPL
lists fully implemented) before we move to it. But I fully support moving to
this sort of scheme in the long run. It manages change much better, and I
think that many, many existing projects have shown that it promotes stable
code bases while still allowing for them to evolve as necessary.

- Jonathan M Davis


The proposed scheme is only a proposed scheme. Other solutions exist 
that solve the problem, and if they better fit, why not ?

Re: Why is std.algorithm so complicated to use?

[Jonathan M Davis]

On Monday, July 16, 2012 01:47:15 Mehrdad wrote:
> On Sunday, 15 July 2012 at 22:39:47 UTC, Jonathan M Davis wrote:
> > On Sunday, July 15, 2012 18:24:47 Andrei Alexandrescu wrote:
> >> On 7/15/12 6:22 PM, Mehrdad wrote:
> >> > On Sunday, 15 July 2012 at 22:03:33 UTC, Jonathan M Davis
> >> > 
> >> > wrote:
> >> >> auto arr = [10, 22, 19, 4, 6];
> >> >> arr = remove(arr, 3);
> >> >> assert(arr == [10, 22, 19, 6]);
> >> > 
> >> > Yeah, the problem is that this reallocates...
> >> 
> >> doesn't
> > 
> > Yeah. It just slices.
> 
> Ooh, I misunderstood what was happening. Thanks to both you &
> Andrei!

std.algorithm.remove does pretty much exactly what the STL's erase function 
does, only it operates on ranges rather than iterators.

- Jonathan M Davis

Re: D versionning

[Jonathan M Davis]

On Sunday, July 15, 2012 19:43:44 Patrick Stewart wrote:
> Completely not relevant. Number of developers have nothing to do with
> project organization. There is a lot of software there equal or more
> complex that are product of just a few or even single programmer.

Actually, it's _very_ relevant. If release model A takes up more time and 
resources than release model B, then release model A will slow down 
development. For projects with more developers, it may be possible to mitigate 
those costs such that the benefits outweigh them, but for projects with fewer 
developers, a slower release model may be completely unacceptable. It all 
depends on what the various pros and cons are and how they will affect the 
project.

It may very well be that the proposed release model is well worth going to, 
but it could also be that its benefits aren't worth its costs, and the number 
of developers involved has a definite effect on that calculation.

- Jonathan M Davis

Re: D versionning

[deadalnix]

On 16/07/2012 01:07, Walter Bright wrote:

On 7/15/2012 3:43 PM, Jonathan M Davis wrote:

On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:

On 7/15/2012 3:27 PM, Jonathan M Davis wrote:

The problem is that we're still ironing out too much, and most of the
breakage relates to bug fixes, not new features.


There's been a lot of non-bug-fixing breakage, for example, renaming
library
functions.


Yeah, but those are always done through a deprecation path, so there's no
immediate breakage. And we've done most of that already, so that
should be
happening less and less.


It needs to stop completely.



No. It hasn't been made for no reasons.

But yes, some code is broken in the process. This is exactly why we need 
a more sophisticated versionning process (note the recurring pattern in 
my posts :D ).


The fact that some people have legacy code shouldn't stop D progress. 
But with the current system, D must either break code or make no progress.

Re: Why is std.algorithm so complicated to use?

[Mehrdad]

On Sunday, 15 July 2012 at 22:39:47 UTC, Jonathan M Davis wrote:

On Sunday, July 15, 2012 18:24:47 Andrei Alexandrescu wrote:

On 7/15/12 6:22 PM, Mehrdad wrote:
> On Sunday, 15 July 2012 at 22:03:33 UTC, Jonathan M Davis 
> wrote:

>> auto arr = [10, 22, 19, 4, 6];
>> arr = remove(arr, 3);
>> assert(arr == [10, 22, 19, 6]);
> 
> Yeah, the problem is that this reallocates...


doesn't


Yeah. It just slices.


Ooh, I misunderstood what was happening. Thanks to both you & 
Andrei!

Re: D versionning

[deadalnix]

On 16/07/2012 01:06, Walter Bright wrote:

Frankly, I don't know how to do what you're asking for. D users, every
single day, clamor for:

1. more bug fixes
2. more new features
3. why aren't deprecated features removed more quickly?
4. why don't we add this breaking feature?
5. why did you add that breaking feature which broke my code?

Often, these are the same people! Sometimes, even in the same post!



I understand that this may seems messed up. It isn't as much as it 
seems. It simply show the need for a more elaborate versionning and 
releasing system for D.


Theses needs do all exists. But not all at the same time or all in the 
same situation.


When dealing with code, as in all engineering fields, you always make 
tradeoffs. And changing things in a codebase have a cost. Presumably, 
every feature which are included into D has also a benefit.


The larger your codebase, the more interesting it is to slow down 
inclusion of new feature in your work. The smaller, the quicker you want 
to do it because the cost of doing so isn't the same, and you can 
benefit from the news feature at a very little cost.


Different situations, different needs. The same person can have both 
need at the same time, because it have experienced both situations with 
different codebases.



And, to reiterate, we did release D1. Since its release, it has only
received bug fixes. No breaking changes, no regressions. This,
inevitably, has made many D1 users unhappy - they wanted new features
folded in.

So that was not satisfactory, either.

Yes, I do feel a bit put upon by this, as I see no way to satisfy all
these mutually contradictory requests.


As of D1, the problem is different.

I'll use again the example of PHP, because it has proven to manage the 
issue quite well, and because I discussed that quite a lot with Ramsus 
recently, so I know the topic quite well.


PHP release PHP 5.2 . Then it released PHP6 . PHP introduced breaking 
changes, just like D2 does. We can compare D1 as PHP5.2 and D2 as PHP6 .


It happened that some new feature of PHP6 weren't breaking features (GC, 
closures, namespaces) and some other were (introducing unicode into 
source code).


And here is what is done then, and here what we should learn from PHP. 
After PHP6, PHP relased PHP5.3 . PHP5.3 was basically PHP5.2 with all 
new feature of PHP6, except the one that was breaking.


PHP5.2 continued to live for very conservative users, 5.3 for user that 
want to use new features, and 6 for users that feel like beta testers.


(note 6 was then canceled, but for reasons completely unrelated to what 
we are talking here. I may talk about that, but this is really off topic 
here, so let's not epilogue on that).

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 16:06:58 -0700, Walter Bright  
 wrote:



On 7/15/2012 3:52 PM, Adam Wilson wrote:
So the problem is semantics then? Because I dredge up another word to  
describe
what we are asking for if that's all it takes. But I don't think that  
anyone
else is going to read "stable" as "unchanging". Software is by  
definition
changing, or it's dead. It appears to my parsing of your sentence that  
you are
asserting that stable == static. By that definition of stable, Windows  
ME is
"stable" and ... ehrm, not a soul in the tech world would agree with  
that

summation of WinME.

As I said earlier, no one else in FOSS or Commercial equates stable  
with "has no
bugs", it means no new features and no regressions. Not a single  
solitary person

I've talked too expects their software to be bug free.

THIS is what we mean when we say "stable":
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
It's also how pretty much everyone else will read "stable".


D does have a test suite, and it is a (almost always achieved) goal to  
keep it always passing, even on the dev branch. In fact, most of my work  
is running the test suite and making sure each change doesn't regress.  
(Regressions that do slip through were not in the test suite.)


Frankly, I don't know how to do what you're asking for. D users, every  
single day, clamor for:


1. more bug fixes


Branch A. Rebase into Branch B as needed.


2. more new features


Branch B.


3. why aren't deprecated features removed more quickly?


Branch A, marked for deprecation.
Branch B, actually removed. Becomes active when merged into Branch A.
(Assuming Branch B is merged roughly every other month as per current  
processes.)



4. why don't we add this breaking feature?


Add it. Branch B.


5. why did you add that breaking feature which broke my code?


Why are you using Branch B you knucklehead?


Often, these are the same people! Sometimes, even in the same post!


This concept is precisely designed to significantly mitigate all five  
problems.


Not everyone will test against Repo B, but this allows you to put the  
responsibility for not testing against it on them. They know how it works  
here, it's not your problem if you broke something that they had the  
chance to test for but didn't.


And, to reiterate, we did release D1. Since its release, it has only  
received bug fixes. No breaking changes, no regressions. This,  
inevitably, has made many D1 users unhappy - they wanted new features  
folded in.


So that was not satisfactory, either.

Yes, I do feel a bit put upon by this, as I see no way to satisfy all  
these mutually contradictory requests.


I do apologize for that. It is not my intention to cause undue stress. I  
am pushing the for the change because I think it will mitigate much of  
your current stress in dealing with us. And I do recognize that we users  
can be pretty demanding as I sit on the other side of this equation at  
work. But because I sit on the other side, I get frustrated when I see  
developers actively resisting the proven concepts that will drastically  
reduce the very problem they are complaining about.


I should note that we use this exact model for every project we have where  
I work and that it is been highly successful at keeping those five points  
of tension moderated. And our users can actually get work done without  
waiting for weeks and months because thing X is just plain broken, which  
in turn makes us look good. (Improving Loyalty)


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Patrick Stewart]

bearophile Wrote:

> Patrick Stewart:
> 
> > Both languages have programming bugs and bad decisions. Python 
> > fix them without disrupting schedule and usability. D says 
> > "suck it up for next X years while we fix it" or "You have some 
> > obscure 4 year old version without that bug".
> 
> Python C interpreter is also far simpler than designing a new 
> system language, and writing its compiler and standard library. 

Simpler - true. But having more complex problem to solve just makes more 
important to have *better* organization. And D community approach is of weekend 
developers that discovered VCS & test suite, but know nothing about branching 
and project planning.

> And behind Python there are far more developers and users.
> 

Completely not relevant. Number of developers have nothing to do with project 
organization. There is a lot of software there equal or more complex that are 
product of just a few or even single programmer.

Re: D versionning

[Jonathan M Davis]

On Sunday, July 15, 2012 16:26:50 Walter Bright wrote:
> Sigh. Half say we release too often, the other half not often enough.

Which is actually one argument for going to a model where you have frequent 
minor releases which only contain bug fixes and less frequent major releases 
with the larger changes. You can never make everyone happy, but by doing so, 
you get the bug fixes faster for the folks complaining about the lack of 
frequent releases, and you get increased stability as far as the new stuff 
goes, because it doesn't come with every release.

I'm only against the proposed versioning scheme because I think that we need 
to stabilize things better (e.g. actually have all of the features that TDPL 
lists fully implemented) before we move to it. But I fully support moving to 
this sort of scheme in the long run. It manages change much better, and I 
think that many, many existing projects have shown that it promotes stable 
code bases while still allowing for them to evolve as necessary.

- Jonathan M Davis

Re: D versionning

[Patrick Stewart]

Walter Bright Wrote:

> On 7/15/2012 4:08 PM, Patrick Stewart wrote:
> > Second biggest flaw with D development is premature optimization opsession 
> > by
> > large number of devs. "We haven't make it work quite yet as specs define, 
> > but
> > lets us optimize it, so it can work incorrectly even faster!"
> 
> All versions pass the D test suite 100%. Any regressions that appeared were 
> not 
> in the test suite, but do get added as they are fixed.
> 
> 

100% passage of test suites do not make me more happy even a bit. Which is my 
business, of course.

What would make me happy is feature list on page describing milestones. And 
each version branched and kept stable, with bugfixes and *no* new features 
introduced.

Real question is where is D going? When will be enough with cramming new 
features down its throat each time a semi-good idea pops up? When will D leave 
beta and reach v1 ? Because D2 is still in beta as far as I see it.

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 16:26:50 -0700, Walter Bright  
 wrote:



On 7/15/2012 2:58 PM, Adam Wilson wrote:
The idea that bugs and new features can and should be rolled into the  
same
release runs counter to every accepted best practice in both FOSS and  
Commercial
wisdom. The two have VERY different velocities, bugs can be fixed in  
days, but
new features take much longer. Consider COFF support for example,  
Walter has
been hammering away at it for weeks now, and he isn't even 50% done,  
how many

bugs have been fixed and confirmed resolved, in the same timespan?


Weeks is an exaggeration. And still, there have been a steady  
accumulation of fixes.



Also,
consider that adding new features makes it significantly harder to  
track down
regressions (is a real regression or did the new feature upset the code  
in an
unexpected way) and the new features themselves create new bugs. If the  
branches
are separate then it becomes trivial to determine if the new feature  
caused the

bug, because it will show up in one and not the other.

How DARE we DEMAND that our users wait 4 MONTHS for regression fixes  
because we
are afraid of a split or a little extra work? How many users could we  
lose if we
significantly slowed down the release cycle (and therefore the bugfix  
cycle)
such that people are waiting many months for their fixes? The language  
would be
perceived as dead/dying and that would be just as bad as the D1/D2  
split. If you
allow your past experiences to paralyze you into inaction, you will  
bring about

the very problem you seek to avoid.


Sigh. Half say we release too often, the other half not often enough.



This would solve both complaints overnight. The half that say "not often  
enough" have critical bugfixes they are waiting on, the "too often" camp  
has new things that they want now (ex. COFF) and see all this bugfixing as  
getting in the way. I agree its a problem, but this makes both happy. The  
new feature camp can use dev and put up with the breakages (what we do  
now), and bugfix camp can get back to work.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Jonathan M Davis]

On Sunday, July 15, 2012 16:07:40 Walter Bright wrote:
> On 7/15/2012 3:43 PM, Jonathan M Davis wrote:
> > On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:
> >> On 7/15/2012 3:27 PM, Jonathan M Davis wrote:
> >>> The problem is that we're still ironing out too much, and most of the
> >>> breakage relates to bug fixes, not new features.
> >> 
> >> There's been a lot of non-bug-fixing breakage, for example, renaming
> >> library functions.
> > 
> > Yeah, but those are always done through a deprecation path, so there's no
> > immediate breakage. And we've done most of that already, so that should be
> > happening less and less.
> 
> It needs to stop completely.

Most of the renaming of functions which has gone on has been because Phobos 
has been inconsistent with its naming, which makes it harder to use and learn. 
As that's sorted out (as has mostly been done), those changes will stop. But 
do you honestly expect that everything in the standard library is going to be 
frozen at some point? Is that what you're suggesting?

If we figure out that function X really should be replaced, we should be able 
to replace it. If we come up with a way better design for a module, we should 
be able to replace it. That may mean leaving the old version around for a long 
period of time, but we shouldn't be stuck for bad design decisions 
permanently. That's actually one area where having major and minor releases 
(in addition to D1 vs D2 vs D3 etc) can really help, because then you restrict 
the larger changes to the major releases. Major libraries do this all the time 
(e.g. Qt).

We definitely want to be more stable than we have been, and we want to reach 
the point where there are no longer any minor changes for naming and whatnot 
(and we're getting there), but if you want to freeze the API on Phobos 
permanently, making it so that we can only ever have additive changes, then 
there are going to be a number of people who are going to be very unhappy. In 
the long run, breaking changes should be better managed (e.g. restricted to 
only certain releases) and much rarer, but they still need to be able to 
happen.

- Jonathan M Davis

Re: D versionning

[Walter Bright]

On 7/15/2012 2:58 PM, Adam Wilson wrote:

The idea that bugs and new features can and should be rolled into the same
release runs counter to every accepted best practice in both FOSS and Commercial
wisdom. The two have VERY different velocities, bugs can be fixed in days, but
new features take much longer. Consider COFF support for example, Walter has
been hammering away at it for weeks now, and he isn't even 50% done, how many
bugs have been fixed and confirmed resolved, in the same timespan?


Weeks is an exaggeration. And still, there have been a steady accumulation of 
fixes.


Also,
consider that adding new features makes it significantly harder to track down
regressions (is a real regression or did the new feature upset the code in an
unexpected way) and the new features themselves create new bugs. If the branches
are separate then it becomes trivial to determine if the new feature caused the
bug, because it will show up in one and not the other.

How DARE we DEMAND that our users wait 4 MONTHS for regression fixes because we
are afraid of a split or a little extra work? How many users could we lose if we
significantly slowed down the release cycle (and therefore the bugfix cycle)
such that people are waiting many months for their fixes? The language would be
perceived as dead/dying and that would be just as bad as the D1/D2 split. If you
allow your past experiences to paralyze you into inaction, you will bring about
the very problem you seek to avoid.


Sigh. Half say we release too often, the other half not often enough.

Re: D versionning

[Walter Bright]

On 7/15/2012 4:08 PM, Patrick Stewart wrote:

Second biggest flaw with D development is premature optimization opsession by
large number of devs. "We haven't make it work quite yet as specs define, but
lets us optimize it, so it can work incorrectly even faster!"


All versions pass the D test suite 100%. Any regressions that appeared were not 
in the test suite, but do get added as they are fixed.

Re: D versionning

[Walter Bright]

On 7/15/2012 4:15 PM, Patrick Stewart wrote:

We are coming back to dsource & Tango graveyard story. D had equally capable
and large community to. Its resources got wasted. People left. Huge amount of
work just wasted for nothing. On the other hand, Python has one of the
largest *operational* standard library and tons of 3rd party ones. Why?
Because with stable language, all those libraries stayed in the game.



Quite a bit of Tango has moved into D2, the parts whose authors had the rights 
to change the license and so move it.

Re: D versionning

[Patrick Stewart]

bearophile Wrote:

> Patrick Stewart:
> 
> > Both languages have programming bugs and bad decisions. Python 
> > fix them without disrupting schedule and usability. D says 
> > "suck it up for next X years while we fix it" or "You have some 
> > obscure 4 year old version without that bug".
> 
> Python C interpreter is also far simpler than designing a new 
> system language, and writing its compiler and standard library. 
> And behind Python there are far more developers and users.
> 
> Bye,
> bearophile

We are coming back to dsource & Tango graveyard story. D had equally capable 
and large community to. Its resources got wasted. People left. Huge amount of 
work just wasted for nothing. On the other hand, Python has one of the largest 
*operational* standard library and tons of 3rd party ones. Why? Because with 
stable language, all those libraries stayed in the game.

Re: D versionning

[deadalnix]

On 15/07/2012 23:36, SomeDude wrote:

On Sunday, 15 July 2012 at 20:50:47 UTC, Patrick Stewart wrote:

OTOH, it may break the community yet again, which we certainly don't
want, probably even less than breaking code.
Also, the example of Python with two main stable branches that live
in parallel is not very encouraging.


Also, check Python website: they recommend python v2 for all new users
that don't know what to choose. They are both stable, but v2 has more
libraries, and they do reassure them by saying v2 will be supported
for time to come.

On the other hand, on D website, D1 is pushed to the dark corners as
ugly half child nobody should know about, and D2 is titled as thing to
chose without thinking. And there is no mentioning D1 is relatively
stable, while D2 is still unstable, non conforming to D documentation
and that some things just don't work, while in constant beta flux that
breaks things on regular basis with each release.

So tell me again, which language treats its users with more respect ?
Which one encourages users more to use them?


The problem I raised is not a problem of respect. It's a problem of
community. The D community is a tiny fraction of the Python community.
It has been steadily growing this last year and a half or so, but it's
still fragile. The D1/D2 split basically set it back to near zero for
several years, with many people leaving, only a few staying, and a
number recently coming back.

The project certainly can't afford yet another split, or many key people
will simply throw the towel. I for one would rather see part of the
users quitting than active members.

As for the stability of D2, upir opinion may be different, but it has
largely improved recently due to increased forces, as several people
have noted (David Simcha in a recent thread said something about the
stability of the compiler being good enough that he only rarely
encountered a problem). And considering the rate of bugs correction, it
will continue to improve. You only need to have a look at the changelog
to see that it's growing with each release, and I'm pretty confident
that the 2.060 will contain more bug fixes than any past release.


Well bug will be fixed for sure.

But, as explained, as new feature are also introduced, bug will also be 
introduced.


This is why stable release is never reached.

Re: Creator of ZeroMQ and AMQP comments on error handling

[Jonathan M Davis]

On Sunday, July 15, 2012 15:26:53 José Armando García Sancio wrote:
> On Sun, Jul 15, 2012 at 3:00 PM, Tobias Pankrath  
wrote:
> >> What do you all think?
> > 
> > All his arguments about C++ exceptions hold for plain return values, too.
> 
> Yes but he would said that is not the point of his article. I think
> his point is that if you decide not to use exception in C++, for the
> reason he and others have mentioned, then C++'s classes/structs become
> nothing more than C structs with an uglier/more verbose syntax.
> 
> I am wondering if you can extend his argument to D. Implementing RIIA
> becomes more verbose. The scope keyword is useless. Thoughts?

C++ and D are designed to use exceptions. It's virtually impossible to 
completely escape them. However, because D has nothrow, you can at least 
guarantee that your code doesn't throw them (though you still have to worry 
about Errors)., even if it gets ugly in some cases like constructors, forcing 
you to do nonsense like two-part initialization, and C++ doesn't have that. D 
also has stuff like scope and  std.exception.collectException which can help 
cleanup exception-handling code quite a bit. So, D's better off than C++ is, 
even if the situation is similar.

But I tend to disagree with anyone who argues that error codes are better. 
Exceptions force you to actually deal with the errors that occur, whereas 
error codes can easily be skipped. At least some of that complication is 
intrinsic to the problem, and using error codes instead of exceptions just 
means that you're probably not handling a lot of the errors correctly.

- Jonathan M Davis

Re: D versionning

[bearophile]

Patrick Stewart:

Both languages have programming bugs and bad decisions. Python 
fix them without disrupting schedule and usability. D says 
"suck it up for next X years while we fix it" or "You have some 
obscure 4 year old version without that bug".


Python C interpreter is also far simpler than designing a new 
system language, and writing its compiler and standard library. 
And behind Python there are far more developers and users.


Bye,
bearophile

Re: D versionning

[Walter Bright]

On 7/12/2012 11:52 PM, Adam Wilson wrote:

I hope Walter isn't against this, because I'm not seeing much community
disagreement with this...



Note this: http://d.puremagic.com/test-results/

I don't see how what we're doing is so broken.

Re: D versionning

[Patrick Stewart]

SomeDude Wrote:

> On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
> >> OTOH, it may break the community yet again, which we certainly 
> >> don't want, probably even less than breaking code.
> >> Also, the example of Python with two main stable branches that 
> >> live in parallel is not very encouraging.
> >
> > Are you kidding? Python should be used as example of how 
> > software should be engineered. They keep release schedules, 
> > keep stable versions & never break backward compatibility 
> > without giving their users ways to not be stuck in bad 
> > situation. It is well thought and planned. Its popularity and 
> > widespread is not a coincidence,  and the fact that it became 
> > de facto part of linuxes (shipping with 5 year old versions 
> > without a fear of deprecation) just proves people can count on 
> > it and use it without fear of some random unguided development 
> > that is typical of D with its half thought our new features 
> > that bite it on the ass year later.
> 
> I understand your gripe with breaking changes and bugs, but your 
> painting of the sate of things is caricatural. First Linuxes are 
> not shipping with 5 year old versions of Python, they usually 
> ship with 2.7 which is the last version of the 2 branch. 
> Meanwhile, the 3 branch is having a hard time getting used, 
> several years after its introduction, and some major packages 
> still haven't been ported.
> http://wiki.python.org/moin/Python2orPython3
> That is what I was referring to.
> 

CentOS 6.x (latest) is shiping with 2 year old python version. Most production 
servers I maintain are 4.x - 5.x with Python 2.4+ that are around 5 year old 
releases. Upgrading is not an option for most situations. And we are talking 
here about linux distro that targets stability above all.

> I agree the Python roadmap is better paved than the D roadmap, 
> which hardly exists. It does make a case for a dev and a stable 
> branch, which makes complete sense. OTOH, Python has suffered 

It goes other way around. Stability is achieved by branching development from 
trunk on certain milestones. Whole D development is one constant trunk with 
added bugs and broken backward compatibility with each release.

> from disruptive changes just as much as D, like the fact that 
> incorporating UTF in the language has justified a completely new 
> branch. And talking about half assed features, its reference 
> implementation suffers from *major* issues, like being slow 
> (about 5 times slower than the Pypy JIT implementation) and 
> monothreaded. And that is not going to be fixed any time soon. 
> And you can't use PyPy for most serious web projects as native 
> libraries are not compatible and haven't been ported.

Web projects? Speed? PyPy? You are so far up premature optimization story that 
you miss what we are talking here about.

Second biggest flaw with D development is premature optimization opsession by 
large number of devs. "We haven't make it work quite yet as specs define, but 
lets us optimize it, so it can work incorrectly even faster!"

Re: D versionning

[Walter Bright]

On 7/15/2012 3:43 PM, Jonathan M Davis wrote:

On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:

On 7/15/2012 3:27 PM, Jonathan M Davis wrote:

The problem is that we're still ironing out too much, and most of the
breakage relates to bug fixes, not new features.


There's been a lot of non-bug-fixing breakage, for example, renaming library
functions.


Yeah, but those are always done through a deprecation path, so there's no
immediate breakage. And we've done most of that already, so that should be
happening less and less.


It needs to stop completely.

Re: D versionning

[Walter Bright]

On 7/15/2012 3:52 PM, Adam Wilson wrote:

So the problem is semantics then? Because I dredge up another word to describe
what we are asking for if that's all it takes. But I don't think that anyone
else is going to read "stable" as "unchanging". Software is by definition
changing, or it's dead. It appears to my parsing of your sentence that you are
asserting that stable == static. By that definition of stable, Windows ME is
"stable" and ... ehrm, not a soul in the tech world would agree with that
summation of WinME.

As I said earlier, no one else in FOSS or Commercial equates stable with "has no
bugs", it means no new features and no regressions. Not a single solitary person
I've talked too expects their software to be bug free.

THIS is what we mean when we say "stable":
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
It's also how pretty much everyone else will read "stable".


D does have a test suite, and it is a (almost always achieved) goal to keep it 
always passing, even on the dev branch. In fact, most of my work is running the 
test suite and making sure each change doesn't regress. (Regressions that do 
slip through were not in the test suite.)


Frankly, I don't know how to do what you're asking for. D users, every single 
day, clamor for:


1. more bug fixes
2. more new features
3. why aren't deprecated features removed more quickly?
4. why don't we add this breaking feature?
5. why did you add that breaking feature which broke my code?

Often, these are the same people! Sometimes, even in the same post!

And, to reiterate, we did release D1. Since its release, it has only received 
bug fixes. No breaking changes, no regressions. This, inevitably, has made many 
D1 users unhappy - they wanted new features folded in.


So that was not satisfactory, either.

Yes, I do feel a bit put upon by this, as I see no way to satisfy all these 
mutually contradictory requests.

Re: D versionning

[Patrick Stewart]

Adam Wilson Wrote:

> On Sun, 15 Jul 2012 14:20:14 -0700, SomeDude   
> wrote:
> 
> > On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
> >>> OTOH, it may break the community yet again, which we certainly don't  
> >>> want, probably even less than breaking code.
> >>> Also, the example of Python with two main stable branches that live in  
> >>> parallel is not very encouraging.
> >>
> >> Are you kidding? Python should be used as example of how software  
> >> should be engineered. They keep release schedules, keep stable versions  
> >> & never break backward compatibility without giving their users ways to  
> >> not be stuck in bad situation. It is well thought and planned. Its  
> >> popularity and widespread is not a coincidence,  and the fact that it  
> >> became de facto part of linuxes (shipping with 5 year old versions  
> >> without a fear of deprecation) just proves people can count on it and  
> >> use it without fear of some random unguided development that is typical  
> >> of D with its half thought our new features that bite it on the ass  
> >> year later.
> >
> > I understand your gripe with breaking changes and bugs, but your  
> > painting of the sate of things is caricatural. First Linuxes are not  
> > shipping with 5 year old versions of Python, they usually ship with 2.7  
> > which is the last version of the 2 branch. Meanwhile, the 3 branch is  
> > having a hard time getting used, several years after its introduction,  
> > and some major packages still haven't been ported.
> > http://wiki.python.org/moin/Python2orPython3
> > That is what I was referring to.
> >
> > I agree the Python roadmap is better paved than the D roadmap, which  
> > hardly exists. It does make a case for a dev and a stable branch, which  
> > makes complete sense. OTOH, Python has suffered from disruptive changes  
> > just as much as D, like the fact that incorporating UTF in the language  
> > has justified a completely new branch. And talking about half assed  
> > features, its reference implementation suffers from *major* issues, like  
> > being slow (about 5 times slower than the Pypy JIT implementation) and  
> > monothreaded. And that is not going to be fixed any time soon. And you  
> > can't use PyPy for most serious web projects as native libraries are not  
> > compatible and haven't been ported.
> 
> To be fair, the majority of the problems you listed with Python have  
> nothing to do with their release process but their design process. The two  
> are unrelated. The fact that it suffers disruptive changes is an argument  
> for dev/stable branches, not against.
> 

Point here is how community is handling problems. It is matter of engineering 
skill, not programming. Both languages have programming bugs and bad decisions. 
Python fix them without disrupting schedule and usability. D says "suck it up 
for next X years while we fix it" or "You have some obscure 4 year old version 
without that bug".

> -- 
> Adam Wilson
> IRC: LightBender
> Project Coordinator
> The Horizon Project
> http://www.thehorizonproject.org/

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 15:32:06 -0700, Walter Bright  
 wrote:



On 7/15/2012 3:00 PM, Adam Wilson wrote:
Also, all the released versions of D are available for download. There  
is no

need to constantly download the latest if that disrupts your projects.



And with the comming deprecation of D1, what then?


It'll still be there for download for those that want to use it.



I guess my point is that at that time we only have one operative branch  
per your implication. Great, it's still there, but it's un


Going backwards is almost never the answer with D2, the bugs are almost  
always

still there.


To me, 'stable' means unchanging, not 'has no bugs'.



So the problem is semantics then? Because I dredge up another word to  
describe what we are asking for if that's all it takes. But I don't think  
that anyone else is going to read "stable" as "unchanging". Software is by  
definition changing, or it's dead. It appears to my parsing of your  
sentence that you are asserting that stable == static. By that definition  
of stable, Windows ME is "stable" and ... ehrm, not a soul in the tech  
world would agree with that summation of WinME.


As I said earlier, no one else in FOSS or Commercial equates stable with  
"has no bugs", it means no new features and no regressions. Not a single  
solitary person I've talked too expects their software to be bug free.


THIS is what we mean when we say "stable":  
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html

It's also how pretty much everyone else will read "stable".

--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Jonathan M Davis]

On Sunday, July 15, 2012 15:30:57 Walter Bright wrote:
> On 7/15/2012 3:27 PM, Jonathan M Davis wrote:
> > The problem is that we're still ironing out too much, and most of the
> > breakage relates to bug fixes, not new features.
> 
> There's been a lot of non-bug-fixing breakage, for example, renaming library
> functions.

Yeah, but those are always done through a deprecation path, so there's no 
immediate breakage. And we've done most of that already, so that should be 
happening less and less.

However, if we did move to a model where we had major and minor releases, then 
deprecating and removing functions would presumably be restricted to major 
releases.

- Jonathan M Davis

Re: D versionning

[Walter Bright]

On 7/15/2012 10:25 AM, captaindet wrote:

pls make a fresh build available on a weekly or at least biweekly basis, just
with regressions fixed.


2.059 had only 3 outstanding regressions.

Re: Why is std.algorithm so complicated to use?

[Jonathan M Davis]

On Sunday, July 15, 2012 18:24:47 Andrei Alexandrescu wrote:
> On 7/15/12 6:22 PM, Mehrdad wrote:
> > On Sunday, 15 July 2012 at 22:03:33 UTC, Jonathan M Davis wrote:
> >> auto arr = [10, 22, 19, 4, 6];
> >> arr = remove(arr, 3);
> >> assert(arr == [10, 22, 19, 6]);
> > 
> > Yeah, the problem is that this reallocates...
> 
> doesn't

Yeah. It just slices. remove moves the elements over by one, and returns a 
slice of the range which is shorter by the number of elements removed. And 
since assigning one array is just assigning the ptr and length properties, 
there's no copying of the elements there, and no reallocations are required 
anywhere.

Now, if you want to append to the array afterwards, then you're going to get a 
reallocation (unless you know that there are no other arrays referring to 
anything after the returned slice, in which case, you can use assumeSafeAppend 
make it so that it doesn't reallocate). But the removal involves no 
reallocations at all.

- Jonathan M Davis

Re: D versionning

[Walter Bright]

On 7/14/2012 6:42 PM, Adam Wilson wrote:

I believe that there IS a problem here. There are people who, for various
reasons, cannot use Git HEAD, and they have open problems. They are stuck. I
believe that is the unstated impetus for this thread.


There is no answer to:

"Do not change things, but change everything."

Re: D versionning

[Walter Bright]

On 7/15/2012 3:27 PM, Jonathan M Davis wrote:

The problem is that we're still ironing out too much, and most of the breakage
relates to bug fixes, not new features.


There's been a lot of non-bug-fixing breakage, for example, renaming library 
functions.

Re: D versionning

[Walter Bright]

On 7/15/2012 3:00 PM, Adam Wilson wrote:

Also, all the released versions of D are available for download. There is no
need to constantly download the latest if that disrupts your projects.



And with the comming deprecation of D1, what then?


It'll still be there for download for those that want to use it.



Going backwards is almost never the answer with D2, the bugs are almost always
still there.


To me, 'stable' means unchanging, not 'has no bugs'.

Re: D versionning

[Jonathan M Davis]

On Sunday, July 15, 2012 14:58:14 Walter Bright wrote:
> On 7/12/2012 3:40 PM, Patrick Stewart wrote:
> > Most ridiculous thing about D is that it breaks so much backward
> > compatibility that people just give up using it. Decent versioning like
> > this might help people stick to something.
> > 
> > Wake up, guys, it is 10+ years and *still* it haven't reached some form of
> > stable release.
> > 
> > Like I sad, engineering failure.
> 
> We did do a stable release, D1, and there were plenty of complaints that D1
> did not get new features.

Well, if we were to move to a model where we had 2.x.y, we only put new 
features on changes to x, and bug fixes when in changes to y, and we did x 
releases every few months and y releases monthly (or something along those 
lines), then people would theoretically get a more stable release to work off 
of with the new features still coming semi-frequently. You get a better 
balance between stability and new stuff than we've had. And I think that in the 
long run, that's probably what we should do. Instead, what we've had is either 
stability without any new features or at all or a new features but a lack of 
stabliity.

The problem is that we're still ironing out too much, and most of the breakage 
relates to bug fixes, not new features. I think that we need to reach the point 
where D is more or less at where TDPL says it should be before we go to a 
model we're splitting out the new stuff from the bug fixes. In theory, the only 
new stuff that we're doing right now relates to matching TDPL and ironing out 
issues with existing stuff rather than outright adding new features anyway 
(though some outright new stuff _has_ been added - e.g. the new lambda syntax). 
So, in that sense, pretty much everything is supposed to be bug fixing right 
now.

- Jonathan M Davis

Re: Creator of ZeroMQ and AMQP comments on error handling

[José Armando García Sancio]

On Sun, Jul 15, 2012 at 3:00 PM, Tobias Pankrath  wrote:
>> What do you all think?
>
>
> All his arguments about C++ exceptions hold for plain return values, too.
>

Yes but he would said that is not the point of his article. I think
his point is that if you decide not to use exception in C++, for the
reason he and others have mentioned, then C++'s classes/structs become
nothing more than C structs with an uglier/more verbose syntax.

I am wondering if you can extend his argument to D. Implementing RIIA
becomes more verbose. The scope keyword is useless. Thoughts?

Thanks,
-Jose

Re: Why is std.algorithm so complicated to use?

[Andrei Alexandrescu]

On 7/15/12 6:22 PM, Mehrdad wrote:

On Sunday, 15 July 2012 at 22:03:33 UTC, Jonathan M Davis wrote:

auto arr = [10, 22, 19, 4, 6];
arr = remove(arr, 3);
assert(arr == [10, 22, 19, 6]);


Yeah, the problem is that this reallocates...


doesn't

Re: Why is std.algorithm so complicated to use?

[Andrei Alexandrescu]

On 7/15/12 5:42 PM, Mehrdad wrote:

Another example of how std.algorithm is so hard to use (it's almost
tempting me to start swearing...):

How do you remove an item from an array in place?

It seems so darn simple, and yet it's not in std.algorithm (or
std.range). It makes something so easy so tedious.


Look for "remove" here:

http://dlang.org/phobos/std_algorithm.html

Unfortunately the anchor called "remove" is swallowed by an unrelated 
enum value (we should fix that in ddoc).


From the example:

int[] a = [ 3, 5, 7, 8 ];
assert(remove(a, 1) == [ 3, 7, 8 ]);
assert(a == [ 3, 7, 8, 8 ]);

Therefore, to remove an element in place:

int[] a = [ 3, 5, 7, 8 ];
a = remove(a, 1);

You also have a less stable but faster version:

a = remove!(SwapStrategy.unstable)(a, 1);


Andrei

Re: Why is std.algorithm so complicated to use?

[Mehrdad]

On Sunday, 15 July 2012 at 22:03:33 UTC, Jonathan M Davis wrote:

auto arr = [10, 22, 19, 4, 6];
arr = remove(arr, 3);
assert(arr == [10, 22, 19, 6]);


Yeah, the problem is that this reallocates... (not claiming 
remove() itself is supposed to be efficient, but this is making 
it even worse)



The main problem is understanding why remove (or erase in C++) 
works this way, which seems to throw off a bunch of people in 
both D and C++, but it's something that we're pretty much stuck 
with. You need the actual container (not an iterator or range) 
if you want to actually remove the element.


Well, for arrays, the "actual container" is the array, so that 
doesn't work either. :\ On the other hand, even C++ has 
vector::erase()!

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 14:58:14 -0700, Walter Bright  
 wrote:



On 7/12/2012 3:40 PM, Patrick Stewart wrote:
Most ridiculous thing about D is that it breaks so much backward  
compatibility that people just give up using it. Decent versioning like  
this might help people stick to something.


Wake up, guys, it is 10+ years and *still* it haven't reached some form  
of stable release.


Like I sad, engineering failure.



We did do a stable release, D1, and there were plenty of complaints that  
D1 did not get new features.


Also, all the released versions of D are available for download. There  
is no need to constantly download the latest if that disrupts your  
projects.




And with the comming deprecation of D1, what then?

Going backwards is almost never the answer with D2, the bugs are almost  
always still there.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: Creator of ZeroMQ and AMQP comments on error handling

[Tobias Pankrath]

What do you all think?


All his arguments about C++ exceptions hold for plain return 
values, too.

Re: Why is std.algorithm so complicated to use?

[Jonathan M Davis]

On Sunday, July 15, 2012 23:42:29 Mehrdad wrote:
> Another example of how std.algorithm is so hard to use (it's
> almost tempting me to start swearing...):
> 
> How do you remove an item from an array in place?
> 
> It seems so darn simple, and yet it's not in std.algorithm (or
> std.range). It makes something so easy so tedious.

Iterators have exactly the same problem for exactly the same reasons as 
std.algorithm.remove (e.g. take a look at C++'s erase function). The only way 
to do this in place would be to create a separate removeInPlace function 
specifically for arrays. But since all it takes is reassigning the result of 
std.algorithm.remove to the array that you passed in and an 
std.array.replaceInPlace would be doing exactly that, I don't think that 
adding such a function buys us much:

auto arr = [10, 22, 19, 4, 6];
arr = remove(arr, 3);
assert(arr == [10, 22, 19, 6]);

The main problem is understanding why remove (or erase in C++) works this way, 
which seems to throw off a bunch of people in both D and C++, but it's 
something that we're pretty much stuck with. You need the actual container 
(not an iterator or range) if you want to actually remove the element.

- Jonathan M Davis

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 14:36:06 -0700, SomeDude   
wrote:



On Sunday, 15 July 2012 at 20:50:47 UTC, Patrick Stewart wrote:
OTOH, it may break the community yet again, which we certainly don't  
want, probably even less than breaking code.
Also, the example of Python with two main stable branches that live in  
parallel is not very encouraging.


Also, check Python website: they recommend python v2 for all new users  
that don't know what to choose. They are both stable, but v2 has more  
libraries, and they do reassure them by saying v2 will be supported for  
time to come.


On the other hand, on D website, D1 is pushed to the dark corners as  
ugly half child nobody should know about, and D2 is titled as thing to  
chose without thinking. And there is no mentioning D1 is relatively  
stable, while D2 is still unstable, non conforming to D documentation  
and that some things just don't work, while in constant beta flux that  
breaks things on regular basis with each release.


So tell me again, which language treats its users with more respect ?  
Which one encourages users more to use them?


The problem I raised is not a problem of respect. It's a problem of  
community. The D community is a tiny fraction of the Python community.  
It has been steadily growing this last year and a half or so, but it's  
still fragile. The D1/D2 split basically set it back to near zero for  
several years, with many people leaving, only a few staying, and a  
number recently coming back.


The project certainly can't afford yet another split, or many key people  
will simply throw the towel. I for one would rather see part of the  
users quitting than active members.


As for the stability of D2, upir opinion may be different, but it has  
largely improved recently due to increased forces, as several people  
have noted (David Simcha in a recent thread said something about the  
stability of the compiler being good enough that he only rarely  
encountered a problem). And considering the rate of bugs correction, it  
will continue to improve. You only need to have a look at the changelog  
to see that it's growing with each release, and I'm pretty confident  
that the 2.060 will contain more bug fixes than any past release.


You are concerned that adopting an OSS best-practice is going to split the  
community ... seriously? I find that a very hard argument to swallow with  
a straight face. We aren't splitting D2 into a D3, are simply arguing for  
a bugfix branch (stable) and a new feature branch (dev). How, pray tell,  
is this a split? We are merely seeking to make two things that are  
logically unrelated, bugs and new features, and make them physically  
unrelated as well.


The idea that bugs and new features can and should be rolled into the same  
release runs counter to every accepted best practice in both FOSS and  
Commercial wisdom. The two have VERY different velocities, bugs can be  
fixed in days, but new features take much longer. Consider COFF support  
for example, Walter has been hammering away at it for weeks now, and he  
isn't even 50% done, how many bugs have been fixed and confirmed resolved,  
in the same timespan? Also, consider that adding new features makes it  
significantly harder to track down regressions (is a real regression or  
did the new feature upset the code in an unexpected way) and the new  
features themselves create new bugs. If the branches are separate then it  
becomes trivial to determine if the new feature caused the bug, because it  
will show up in one and not the other.


How DARE we DEMAND that our users wait 4 MONTHS for regression fixes  
because we are afraid of a split or a little extra work? How many users  
could we lose if we significantly slowed down the release cycle (and  
therefore the bugfix cycle) such that people are waiting many months for  
their fixes? The language would be perceived as dead/dying and that would  
be just as bad as the D1/D2 split. If you allow your past experiences to  
paralyze you into inaction, you will bring about the very problem you seek  
to avoid.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: D versionning

[Walter Bright]

On 7/12/2012 3:40 PM, Patrick Stewart wrote:

Most ridiculous thing about D is that it breaks so much backward compatibility 
that people just give up using it. Decent versioning like this might help 
people stick to something.

Wake up, guys, it is 10+ years and *still* it haven't reached some form of 
stable release.

Like I sad, engineering failure.



We did do a stable release, D1, and there were plenty of complaints that D1 did 
not get new features.


Also, all the released versions of D are available for download. There is no 
need to constantly download the latest if that disrupts your projects.

Re: D versionning

[Adam Wilson]

On Sun, 15 Jul 2012 14:20:14 -0700, SomeDude   
wrote:



On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
OTOH, it may break the community yet again, which we certainly don't  
want, probably even less than breaking code.
Also, the example of Python with two main stable branches that live in  
parallel is not very encouraging.


Are you kidding? Python should be used as example of how software  
should be engineered. They keep release schedules, keep stable versions  
& never break backward compatibility without giving their users ways to  
not be stuck in bad situation. It is well thought and planned. Its  
popularity and widespread is not a coincidence,  and the fact that it  
became de facto part of linuxes (shipping with 5 year old versions  
without a fear of deprecation) just proves people can count on it and  
use it without fear of some random unguided development that is typical  
of D with its half thought our new features that bite it on the ass  
year later.


I understand your gripe with breaking changes and bugs, but your  
painting of the sate of things is caricatural. First Linuxes are not  
shipping with 5 year old versions of Python, they usually ship with 2.7  
which is the last version of the 2 branch. Meanwhile, the 3 branch is  
having a hard time getting used, several years after its introduction,  
and some major packages still haven't been ported.

http://wiki.python.org/moin/Python2orPython3
That is what I was referring to.

I agree the Python roadmap is better paved than the D roadmap, which  
hardly exists. It does make a case for a dev and a stable branch, which  
makes complete sense. OTOH, Python has suffered from disruptive changes  
just as much as D, like the fact that incorporating UTF in the language  
has justified a completely new branch. And talking about half assed  
features, its reference implementation suffers from *major* issues, like  
being slow (about 5 times slower than the Pypy JIT implementation) and  
monothreaded. And that is not going to be fixed any time soon. And you  
can't use PyPy for most serious web projects as native libraries are not  
compatible and haven't been ported.


To be fair, the majority of the problems you listed with Python have  
nothing to do with their release process but their design process. The two  
are unrelated. The fact that it suffers disruptive changes is an argument  
for dev/stable branches, not against.


--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

Re: Why is std.algorithm so complicated to use?

[Mehrdad]

Another example of how std.algorithm is so hard to use (it's 
almost tempting me to start swearing...):


How do you remove an item from an array in place?

It seems so darn simple, and yet it's not in std.algorithm (or 
std.range). It makes something so easy so tedious.

Re: D versionning

[SomeDude]

On Sunday, 15 July 2012 at 20:50:47 UTC, Patrick Stewart wrote:
OTOH, it may break the community yet again, which we certainly 
don't want, probably even less than breaking code.
Also, the example of Python with two main stable branches that 
live in parallel is not very encouraging.


Also, check Python website: they recommend python v2 for all 
new users that don't know what to choose. They are both stable, 
but v2 has more libraries, and they do reassure them by saying 
v2 will be supported for time to come.


On the other hand, on D website, D1 is pushed to the dark 
corners as ugly half child nobody should know about, and D2 is 
titled as thing to chose without thinking. And there is no 
mentioning D1 is relatively stable, while D2 is still unstable, 
non conforming to D documentation and that some things just 
don't work, while in constant beta flux that breaks things on 
regular basis with each release.


So tell me again, which language treats its users with more 
respect ? Which one encourages users more to use them?


The problem I raised is not a problem of respect. It's a problem 
of community. The D community is a tiny fraction of the Python 
community. It has been steadily growing this last year and a half 
or so, but it's still fragile. The D1/D2 split basically set it 
back to near zero for several years, with many people leaving, 
only a few staying, and a number recently coming back.


The project certainly can't afford yet another split, or many key 
people will simply throw the towel. I for one would rather see 
part of the users quitting than active members.


As for the stability of D2, upir opinion may be different, but it 
has largely improved recently due to increased forces, as several 
people have noted (David Simcha in a recent thread said something 
about the stability of the compiler being good enough that he 
only rarely encountered a problem). And considering the rate of 
bugs correction, it will continue to improve. You only need to 
have a look at the changelog to see that it's growing with each 
release, and I'm pretty confident that the 2.060 will contain 
more bug fixes than any past release.

Re: D versionning

[SomeDude]

On Sunday, 15 July 2012 at 20:44:01 UTC, Patrick Stewart wrote:
OTOH, it may break the community yet again, which we certainly 
don't want, probably even less than breaking code.
Also, the example of Python with two main stable branches that 
live in parallel is not very encouraging.


Are you kidding? Python should be used as example of how 
software should be engineered. They keep release schedules, 
keep stable versions & never break backward compatibility 
without giving their users ways to not be stuck in bad 
situation. It is well thought and planned. Its popularity and 
widespread is not a coincidence,  and the fact that it became 
de facto part of linuxes (shipping with 5 year old versions 
without a fear of deprecation) just proves people can count on 
it and use it without fear of some random unguided development 
that is typical of D with its half thought our new features 
that bite it on the ass year later.


I understand your gripe with breaking changes and bugs, but your 
painting of the sate of things is caricatural. First Linuxes are 
not shipping with 5 year old versions of Python, they usually 
ship with 2.7 which is the last version of the 2 branch. 
Meanwhile, the 3 branch is having a hard time getting used, 
several years after its introduction, and some major packages 
still haven't been ported.

http://wiki.python.org/moin/Python2orPython3
That is what I was referring to.

I agree the Python roadmap is better paved than the D roadmap, 
which hardly exists. It does make a case for a dev and a stable 
branch, which makes complete sense. OTOH, Python has suffered 
from disruptive changes just as much as D, like the fact that 
incorporating UTF in the language has justified a completely new 
branch. And talking about half assed features, its reference 
implementation suffers from *major* issues, like being slow 
(about 5 times slower than the Pypy JIT implementation) and 
monothreaded. And that is not going to be fixed any time soon. 
And you can't use PyPy for most serious web projects as native 
libraries are not compatible and haven't been ported.

Re: D versionning

[Patrick Stewart]

> OTOH, it may break the community yet again, which we certainly 
> don't want, probably even less than breaking code.
> Also, the example of Python with two main stable branches that 
> live in parallel is not very encouraging.

Also, check Python website: they recommend python v2 for all new users that 
don't know what to choose. They are both stable, but v2 has more libraries, and 
they do reassure them by saying v2 will be supported for time to come.

On the other hand, on D website, D1 is pushed to the dark corners as ugly half 
child nobody should know about, and D2 is titled as thing to chose without 
thinking. And there is no mentioning D1 is relatively stable, while D2 is still 
unstable, non conforming to D documentation and that some things just don't 
work, while in constant beta flux that breaks things on regular basis with each 
release.

So tell me again, which language treats its users with more respect ? Which one 
encourages users more to use them?

Re: D versionning

[Patrick Stewart]

> OTOH, it may break the community yet again, which we certainly 
> don't want, probably even less than breaking code.
> Also, the example of Python with two main stable branches that 
> live in parallel is not very encouraging.

Are you kidding? Python should be used as example of how software should be 
engineered. They keep release schedules, keep stable versions & never break 
backward compatibility without giving their users ways to not be stuck in bad 
situation. It is well thought and planned. Its popularity and widespread is not 
a coincidence,  and the fact that it became de facto part of linuxes (shipping 
with 5 year old versions without a fear of deprecation) just proves people can 
count on it and use it without fear of some random unguided development that is 
typical of D with its half thought our new features that bite it on the ass 
year later.

Re: Creator of ZeroMQ and AMQP comments on error handling

[José Armando García Sancio]

On Sun, Jul 15, 2012 at 1:31 PM, José Armando García Sancio
 wrote:
> Why should I have written ZeroMQ in C, not C++ - http://www.250bpm.com/blog:4

Reddit thread if you are interested:
http://www.reddit.com/r/programming/comments/tggnn/why_should_i_have_written_zeromq_in_c_not_c/

Creator of ZeroMQ and AMQP comments on error handling

[José Armando García Sancio]

Hey everyone,

Apologies for sending this to the D mailing list but I just read a
very interesting article on error handling and was interested in your
opinion.

I just read an article by Martin Sústrik, one of the creators of AMQP
and ZeroMQ, on using C++ for writing infrastructure/system software.
At first glance most of his objects seem to apply to D. What do you
all think?

Why should I have written ZeroMQ in C, not C++ - http://www.250bpm.com/blog:4

Thanks,
-Jose

Re: opApply not called for foeach(container)

[Jonathan M Davis]

On Thursday, July 12, 2012 16:50:22 monarch_dodra wrote:
> On Wednesday, 11 July 2012 at 20:24:42 UTC, Jonathan M Davis
> 
> wrote:
> > The problem is that it's essentially spread out across 3
> > places: the online
> > spec, TDPL, and the compiler.
> > 
> > ...
> > 
> > - Jonathan M Davis
> 
> The problem is not only the documentation, it's getting
> authoritative answers. I see some strange behaviors, and I can't
> for the life of find out if it is a bug in the
> documentation/compiler, or a pitfall/misunderstanding.
> 
> What is your take on the issue at hand? Bug or Pitfall?

My take on it is that you should either go with ranges or opApply and try to 
avoid mixing them. Ideally, we wouldn't even need opApply anymore, but ranges 
can't quite do everything that it can.

- Jonathan m Davis

Re: Inherited const when you need to mutate

[SomeDude]

On Wednesday, 11 July 2012 at 00:20:32 UTC, Timon Gehr wrote:
I for one would be satisfied if inheriting from object became 
optional:


// object.di
class RawObject /+ this is the root of the class hierarchy +/{ }
class SynchronizableObject : RawObject { void* monitor; }
class Object : SynchronizableObject {
 const { stuff }
}

// user code
class NoCruft : RawObject {
// ...
}


At first sight, I think this is an interesting idea. Maybe the 
class hierarchy needs to be rethought for more flexibility ?

Re: D versionning

[SomeDude]

On Thursday, 12 July 2012 at 17:20:32 UTC, deadalnix wrote:

On 12/07/2012 19:10, Tobias Pankrath wrote:
The system adopted in PHP works with a 3 number version. The 
first
number is used for major languages changes (for instance 4 > 
5 imply
passing object by reference when it was by copy before, 5 > 6 
switched

the whole thing to unicode).

The second number imply language changes, but either non 
breaking or

very specific, rarely used stuff. For instance 5.2
> 5.3 added GC, closures and namespace which does not break
code.



We can also learn from the python community, whose from 
__future__
import  facility is a great success and we should 
adopt a

similar scheme.

Consider the -property switch or a future introduction of 
tuple syntax.
If you start a new project, it's no problem. Just use the 
switch and don't
introduce things that will not work without. But if you have 
an old

codebase
but want to use a new feature you can either

a) fix the hole codebase at one
b) fix and configure your build systems to build some files 
with and

some files without the switch.

Both options are PITA. An alternative is to introduce 
#pragma(future,

tuplesyntax);

Now you can insert the pragma in those sourcefiles that are 
new or
already fixed and you can immediately benefit from the feature 
and you

can upgrade your code file by file or even scope by scope.

Later versions could even introduce #pragma(past, 
notuplesyntax) before

dropping the old syntax completely.



This scheme don't allow for breaking change to be made. It also 
require the compiler to handle a mess of features that can be 
activated or not. This is way more work, and I don't really see 
the benefice.


As non breaking change are introduced in a different process 
than breaking one, it is easy to migrate to new version that 
will not break legacy code and provide new features.


OTOH, it may break the community yet again, which we certainly 
don't want, probably even less than breaking code.
Also, the example of Python with two main stable branches that 
live in parallel is not very encouraging.

Re: Why not all statement are expressions ?

[bearophile]

David Piepgrass:


Or how about:

auto area = {
auto tmp = foo.bar(baz);
tmp.width * tmp.height;
}


Rust is like that, but I don't see it as a significant 
improvement.



I also wish "void" were a first-class type with sizeof==0 for 
maximum efficiency:


int[void] intSet = [2:(), 3:(), 4:()]


I prefer:

auto intSet = hashSet([2, 3, 4]);



Ditto for size of empty structs.


There are reasons for D empty structs to be of 1 byte.



D code should never need abominations like the C++ EBCO.


In D classes are never really empty (2 words is their minimum 
size, not counting GC bookkeeping), and there is no normal struct 
inheritance.


Bye,
bearophile

Re: D versionning

[Patrick Stewart]

There is one thing missing from developers perspective as far D is concerned: 
Not all D users want to be beta testers. But they are all treated in such a way.

That is reason #1 I migrate away from D all my software. It is long process and 
tough decision, but after 5 years of tracking D story I am fed up and I see 
nothing has changed and it will probably stay like that in foreseeable future.

Re: Why not all statement are expressions ?

[Stewart Gordon]

On 07/05/2012 21:27, Nick Sabalausky wrote:


I'm usually fairly ambivalent about the idea of statements being
expressions, but I would *love* for switch to be usable as an expression.



Switch cases are sequences of statements.  Allowing them to alternatively be expressions 
would create ambiguity in the grammar.


If you're designing a language and want switch expressions as well as switch statements, 
then don't try to make one look like the other.  For example, C didn't try to make 
conditional expressions look like if statements - it created a new syntax for conditional 
expressions.


That said, it's possible to design a language to have no distinction between expressions 
and statements.  But you can't really conflate the two syntaxes in an existing language.


Of course, D could have been designed as such a language.  But it wasn't.  It was designed 
to have the same overall look and feel as C.


Stewart.

Re: D versionning

[deadalnix]

On 15/07/2012 01:56, Walter Bright wrote:

On 7/13/2012 9:58 AM, Jonathan M Davis wrote:

All that being the case, I don't know what this proposal actually buys
us.


I tend to agree.



After 10 years of D, nothing stable still exists. We may call 2.059 
stable, but frankly, it isn't.


This have a lot to do with the fact that new feature are included (with 
news bugs) in the same stream of version than bug fixes. In other terms, 
bug are fixed but at the same time, bugs are added with new features.


The natural result is that D is not stable yet, and never will be as 
long as the same process is used.


The proposed versioning system solve that problem. It doesn't matter if 
that very system is chosen in fact, but the current one is certainly not 
the one D needs.

Re: D versionning

[captaindet]

On 2012-07-14 20:42, Adam Wilson wrote:

On Sat, 14 Jul 2012 16:56:50 -0700, Walter Bright  
wrote:


On 7/13/2012 9:58 AM, Jonathan M Davis wrote:

All that being the case, I don't know what this proposal actually buys us.


I tend to agree.



If this was the case; 2.059 would not be three months old with no 2.060 in the 
immediate future.

Not having that situation is what this buys us.

I believe that there IS a problem here. There are people who, for various 
reasons, cannot use Git HEAD, and they have open problems. They are stuck. I 
believe that is the unstated impetus for this thread.


+1

pls make a fresh build available on a weekly or at least biweekly basis, just 
with regressions fixed.

Re: Hiatus, Improving Participation in D Development

[dsimcha]

On Sunday, 15 July 2012 at 15:46:38 UTC, David Nadlinger wrote:

On Sunday, 15 July 2012 at 04:02:48 UTC, dsimcha wrote:
5.  The amount of stuff on this forum and the mailing lists 
has become overwhelming.  I've recently remedied this to a 
small degree by unsubscribing from dmd-internals.  I've never 
been a contributor to the compiler itself and had only 
subscribed to this list to track bug fixes and 64-bit support 
implementation.
Now, the signal-to-noise ratio of my inbox is good enough that 
I actually read the Phobos and druntime stuff again instead of 
just glossing over all my D-related email.


I take it you are referring to the GitHub commit messages which 
are relayed to dmd-internals? Because except for those (which I 
just made a filter rule for), the list is really quite 
low-volume. Maybe we should create a dedicated d-commits list 
to which all the GitHub notifications get sent, similar to what 
other projects have? The occasional post-commit discussion 
could then be continued on one of the repository-specific 
lists, just like they are now.


David


Yeah.  The problem is that for a while, D mailing lists became so 
overwhelming that I got into the habit of reflexively ignoring 
them completely due to poor signal-to-noise ratio w.r.t stuff I 
actually work on and being preoccupied with other things.  Your 
idea may be a good one, since only the core DMD devs care about 
every commit but others might want to participate in higher level 
discussions.

Re: Congratulations to the D Team!

[SomeDude]

On Monday, 9 July 2012 at 08:05:01 UTC, Guillaume Chatelet wrote:


Congrats :)


+1 The D community is awesome, and is getting better everyday.

Re: Hiatus, Improving Participation in D Development

[David Nadlinger]

On Sunday, 15 July 2012 at 04:02:48 UTC, dsimcha wrote:
5.  The amount of stuff on this forum and the mailing lists has 
become overwhelming.  I've recently remedied this to a small 
degree by unsubscribing from dmd-internals.  I've never been a 
contributor to the compiler itself and had only subscribed to 
this list to track bug fixes and 64-bit support implementation.
 Now, the signal-to-noise ratio of my inbox is good enough that 
I actually read the Phobos and druntime stuff again instead of 
just glossing over all my D-related email.


I take it you are referring to the GitHub commit messages which 
are relayed to dmd-internals? Because except for those (which I 
just made a filter rule for), the list is really quite 
low-volume. Maybe we should create a dedicated d-commits list to 
which all the GitHub notifications get sent, similar to what 
other projects have? The occasional post-commit discussion could 
then be continued on one of the repository-specific lists, just 
like they are now.


David

Re: D front-end in D for D

[SomeDude]

On Saturday, 14 July 2012 at 15:18:53 UTC, David Piepgrass wrote:


I think, for multiple reasons including this use case, D should 
have a "lightweight subset" with a smaller standard library and 
a somewhat simpler language definition (that retains most of 
D's power), which could shrink the size of a program that uses 
runtime codegen. For simplicity, the D front-end written in D 
could use the same backend for CTFE as for its output. And one 
hopes that generated code could be garbage-collected.


However, presumably you'd have to include LLVM which I believe 
is around 1MB for a bare-minimum build (with no optimization 
passes included.)


I support this idea. This simpler subset would be targetted at 
embedded devices.


I would imagine a sub-D without generic programming and CTFE, for 
instance. The resulting language would retain much enough 
functionality for rewriting a bootstrapping compiler.

Re: D front-end in D for D

[Gor Gyolchanyan]

On Sun, Jul 15, 2012 at 7:21 PM, SomeDude wrote:

> On Saturday, 14 July 2012 at 13:33:16 UTC, Gor Gyolchanyan wrote:
>
>>
>>> Yes, eval or exec is pretty much outlawed in other languages, I can only
>>> imagine the same would happen in D.
>>>
>>>
>> That's a huge mistake a lot of people make. They outlaw things that they
>> don't understand or don't know how to use. As I said: having something
>> doesn't mean using it. Those who can use it - will use it. Those who can't
>> - won't.
>>
>
> And those who can use it for wrongdoing will. This alone completely
> destroys the feature imho.
>

It doesn't have to be a black/white choice. How about analyzing and caching
the code before executing it at run time? If the code is analyzed and
proved to be safe - then it's executed without hesitation. Yes, it'll
require a lot of work to pull this off.

-- 
Bye,
Gor Gyolchanyan.

Re: Closed source D libraries

[Henning Pohl]

On Sunday, 15 July 2012 at 13:26:19 UTC, Benjamin Thaut wrote:

Am 15.07.2012 15:06, schrieb Gor Gyolchanyan:
On Sun, Jul 15, 2012 at 4:33 PM, Henning Pohl 

> wrote:

   On Sunday, 15 July 2012 at 12:21:23 UTC, Gor Gyolchanyan 
wrote:


   On Sun, Jul 15, 2012 at 4:05 PM, Henning Pohl
   >__wrote:


   Most closed source C and C++ libraries provide 
headers and

   binaries. It
   seems to me that there is no way to do this in D, 
because

   the source files
   always have to be available to import their modules.

   I'm not going to write something proprietary or 
closed

   source, but i
   wonder if others can do so.


   It's quite possible. All you have to do is make a 
module, which

   doesn't
   contain any function bodies. The imported modules aren't
   compiled with the
   code. Most of the time it's easier to have a single 
module to

   have both the
   code to compile and symbols to import. In other cases 
they can

   be separated.


   Okay, so it works just like in C:

   // The "header" file
   module lib;

   void printHelloWorld();


   // The "source" file
   module lib
   import std.stdio;

   void printHelloWorld() {
 writeln("Hello world!");
   }


Exactly. Not defining a function body is perfectly fine for 
precisely
these reasons. And, just like in C, forgetting to link with 
the missing

body will result in a linker error.

--
Bye,
Gor Gyolchanyan.


The compiler can even generate those files for using the -H 
option. It will generate .di files. Although any formatting 
will get lost during that process.


Kind Regards
Benjamin Thaut



All right, thank you for the clarification.

Re: D front-end in D for D

[SomeDude]

On Saturday, 14 July 2012 at 13:33:16 UTC, Gor Gyolchanyan wrote:


Yes, eval or exec is pretty much outlawed in other languages, 
I can only

imagine the same would happen in D.



That's a huge mistake a lot of people make. They outlaw things 
that they
don't understand or don't know how to use. As I said: having 
something
doesn't mean using it. Those who can use it - will use it. 
Those who can't

- won't.


And those who can use it for wrongdoing will. This alone 
completely destroys the feature imho.

Re: Hiatus, Improving Participation in D Development

[Andrei Alexandrescu]

On 7/15/12 9:38 AM, dsimcha wrote:
[about std.xml]

Ok, well I'll at least try to get a better handle on what's involved and
how much time I'm going to have over the next few months. I'm not saying
I definitely want to take it on yet.


FWIW, it would be great if you worked on std.xml.

Andrei

Re: Hiatus, Improving Participation in D Development

[dsimcha]

On 7/15/2012 4:54 AM, Jonathan M Davis wrote:

On Sunday, July 15, 2012 00:02:09 dsimcha wrote:

BTW, if noone is working on a new std.xml anymore, I might want to
start.  I interviewed for a job where they wanted me to do a small
prototype as part of the hiring process that involved parsing XML.  I
was allowed to use any language I wanted.  I think my D projects played
a large role in me getting an offer, but I couldn't use it for the
prototype because std.xml is so bad.  I ended up using Python instead.


Someone was working on it (Tomaz?) and was supposedly making good progress,
but last time I checked, they hadn't posted anything since some time in 2010.
So, as far as I can tell, that project is effectively dead. I have no idea what
state it was in before it stalled or whether the code is available anywhere
online. I expect that anyone who wants to work on it will either have to start
from scratch or grabbing one of the existing xml parsers floating around and
adjust it (though I suspect that if it's going to be range-based like it's
supposed to be that any existing parsers floating around probably would need
quite a bit of work to get the right API, but I don't know). It's the sort of
thing that I'd love to work on given the time, but I have so much else going
on that it would be ridiculous for me to even consider it. If you want to take
up that baton, then I think that's great. Even if you end up taking a while to
do it, that's better than getting nothing and seeing no progress as we have
been for quite some time now.

- Jonathan M Davis




Ok, well I'll at least try to get a better handle on what's involved and 
how much time I'm going to have over the next few months.  I'm not 
saying I definitely want to take it on yet.

Re: Closed source D libraries

[Benjamin Thaut]

Am 15.07.2012 15:06, schrieb Gor Gyolchanyan:

On Sun, Jul 15, 2012 at 4:33 PM, Henning Pohl mailto:henn...@still-hidden.de>> wrote:

On Sunday, 15 July 2012 at 12:21:23 UTC, Gor Gyolchanyan wrote:

On Sun, Jul 15, 2012 at 4:05 PM, Henning Pohl
mailto:henn...@still-hidden.de>>__wrote:

Most closed source C and C++ libraries provide headers and
binaries. It
seems to me that there is no way to do this in D, because
the source files
always have to be available to import their modules.

I'm not going to write something proprietary or closed
source, but i
wonder if others can do so.


It's quite possible. All you have to do is make a module, which
doesn't
contain any function bodies. The imported modules aren't
compiled with the
code. Most of the time it's easier to have a single module to
have both the
code to compile and symbols to import. In other cases they can
be separated.


Okay, so it works just like in C:

// The "header" file
module lib;

void printHelloWorld();


// The "source" file
module lib
import std.stdio;

void printHelloWorld() {
  writeln("Hello world!");
}


Exactly. Not defining a function body is perfectly fine for precisely
these reasons. And, just like in C, forgetting to link with the missing
body will result in a linker error.

--
Bye,
Gor Gyolchanyan.


The compiler can even generate those files for using the -H option. It 
will generate .di files. Although any formatting will get lost during 
that process.


Kind Regards
Benjamin Thaut

Re: Closed source D libraries

[Gor Gyolchanyan]

On Sun, Jul 15, 2012 at 4:33 PM, Henning Pohl wrote:

> On Sunday, 15 July 2012 at 12:21:23 UTC, Gor Gyolchanyan wrote:
>
>> On Sun, Jul 15, 2012 at 4:05 PM, Henning Pohl **
>> wrote:
>>
>>  Most closed source C and C++ libraries provide headers and binaries. It
>>> seems to me that there is no way to do this in D, because the source
>>> files
>>> always have to be available to import their modules.
>>>
>>> I'm not going to write something proprietary or closed source, but i
>>> wonder if others can do so.
>>>
>>>
>> It's quite possible. All you have to do is make a module, which doesn't
>> contain any function bodies. The imported modules aren't compiled with the
>> code. Most of the time it's easier to have a single module to have both
>> the
>> code to compile and symbols to import. In other cases they can be
>> separated.
>>
>
> Okay, so it works just like in C:
>
> // The "header" file
> module lib;
>
> void printHelloWorld();
>
>
> // The "source" file
> module lib
> import std.stdio;
>
> void printHelloWorld() {
>  writeln("Hello world!");
> }
>

Exactly. Not defining a function body is perfectly fine for precisely these
reasons. And, just like in C, forgetting to link with the missing body will
result in a linker error.

-- 
Bye,
Gor Gyolchanyan.