www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dmd 2.065 - Agenda

reply Martin Nowak <code dawg.eu> writes:
I made a wiki page for that.
Please discuss, improve and prioritize.
http://wiki.dlang.org/Agenda
Nov 08 2013
next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
09-Nov-2013 00:09, Martin Nowak пишет:

 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


Added few goals for Phobos (hopefully describing a general consensus).

1. Fight the dependency hell & split up huge modules.

As seen during private exchanges during beta period this has been under 
the radar for far too long. Can also be read as "shrink the size of  a 
hello-world app".

2. Get  safe write(f)(ln) at least for basic types.

There has been some great improvement on getting more  safe-ty in 
Phobos. Correct me I'm wrong but but we seem to be very close to 
achieving this symbolic goal and then it's well worth prioritizing.

More to come I hope.

-- 
Dmitry Olshansky
Nov 08 2013
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
 More safety -  safe writeln ?


I think this is good, but also the kind of thing we don't want to
rush. Making things useable in safe code usually means marking
things trusted. Do this too fast, and you end up trusting code
that is actually totally unsafe :/ It's a delicate process.
Nov 08 2013
parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
09-Nov-2013 00:50, monarch_dodra пишет:

 More safety -  safe writeln ?


 I think this is good, but also the kind of thing we don't want to
 rush. Making things useable in safe code usually means marking
 things trusted. Do this too fast, and you end up trusting code
 that is actually totally unsafe :/ It's a delicate process.


Well if it's indeed Mar 2014 I think there is no rush :)

-- 
Dmitry Olshansky
Nov 08 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/8/2013 12:53 PM, Dmitry Olshansky wrote:

 Well if it's indeed Mar 2014 I think there is no rush :)


Except that the more disruptive a change is, the earlier in the cycle it should 
be done, so it can bake properly.
Nov 08 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-08 21:09, Martin Nowak wrote:

 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


I think one of the most important issue for this release is the actual 
process. Basically what you wrote for "Other".

-- 
/Jacob Carlborg
Nov 08 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Martin Nowak:


 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


"scope"?

Bye,
bearophile
Nov 08 2013
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 11/8/13 12:09 PM, Martin Nowak wrote:

 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


I strongly urge the release timing to be a max of 2 months from now, not 5. 
I'd prefer getting back 
to monthly if we can, but that's probably overly optimistic based on the way
we've been doing things.
Nov 08 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/8/2013 3:01 PM, Brad Roberts wrote:

 I strongly urge the release timing to be a max of 2 months from now, not 5. 
I'd
 prefer getting back to monthly if we can, but that's probably overly optimistic
 based on the way we've been doing things.


It can be done if we get an automated release process (hint, hint!).
Nov 08 2013
parent reply "Martin Nowak" <code dawg.eu> writes:
On Saturday, 9 November 2013 at 00:31:59 UTC, Walter Bright wrote:

 On 11/8/2013 3:01 PM, Brad Roberts wrote:

 I strongly urge the release timing to be a max of 2 months 
 from now, not 5.  I'd
 prefer getting back to monthly if we can, but that's probably 
 overly optimistic
 based on the way we've been doing things.




I choose march because ~4 month is already an improvement.
Anything below 3 month seems unrealistically ambitious to me atm.


 It can be done if we get an automated release process (hint, 
 hint!).


Indeed this is an important topic. We need a few discussions and 
some coordinated effort to get there.
Nov 08 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-09 07:47, Martin Nowak wrote:


 I choose march because ~4 month is already an improvement.
 Anything below 3 month seems unrealistically ambitious to me atm.


It depends on what we want to achieve. Either we set the agenda after a 
release schedule. Or we do it the other way around. I know Iain has been 
complaining when releases are taking longer time.

BTW, do people in general have more or less time working on D during the 
Christmas? I know I will have more time.

-- 
/Jacob Carlborg
Nov 09 2013
parent Timothee Cour <thelastmammoth gmail.com> writes:
Release early and often should be the way to go (cf chrome release cycle)
Less pain upgrading from release to release, less pain merging pull
requests. All this requires is automated release tool.


On Sat, Nov 9, 2013 at 5:24 AM, Jacob Carlborg <doob me.com> wrote:


 On 2013-11-09 07:47, Martin Nowak wrote:

  I choose march because ~4 month is already an improvement.

 Anything below 3 month seems unrealistically ambitious to me atm.


 It depends on what we want to achieve. Either we set the agenda after a
 release schedule. Or we do it the other way around. I know Iain has been
 complaining when releases are taking longer time.

 BTW, do people in general have more or less time working on D during the
 Christmas? I know I will have more time.

 --
 /Jacob Carlborg
Nov 09 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 8 November 2013 at 20:09:57 UTC, Martin Nowak wrote:

 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


Getting a build master :D
Nov 08 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/8/2013 3:33 PM, deadalnix wrote:

 Getting a build master :D


We clearly need a better title!
Nov 08 2013
parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Saturday, 9 November 2013 at 00:32:56 UTC, Walter Bright wrote:

 On 11/8/2013 3:33 PM, deadalnix wrote:

 Getting a build master :D


 We clearly need a better title!


There is a title for that already in the IT world: RELEASE 
MANAGER.

However, D project is chaos without any kind of management... 
Moving to GitHub improved little bit, but from a software 
engineering point of view it is far from a serious thing.

This "Agenda" is what agile world typically calls a 
SPRINT/ITERATION BACKLOG. As far as I know, nobody grooms the 
DMD/Phobos backlog, people take items they like, or feel 
challenged by.

I know many people have bad opinion about agile process tools 
such as Scrum, Kanban, XP, etc, but any organised way of doing 
things is better than chaos, unless you prefer the anarchy as 
seen in the Fred George's presentation (which I recommend - 
http://www.youtube.com/watch?v=uk-CF7klLdA). Do not get me wrong, 
I actually agree with Fred, but we do not have the environment 
that is clearly needed for his kind of "software anarchy".

Are bugzilla votes respected btw?
Nov 14 2013
parent reply "qznc" <qznc web.de> writes:
On Thursday, 14 November 2013 at 12:00:26 UTC, Dejan Lekic wrote:

 On Saturday, 9 November 2013 at 00:32:56 UTC, Walter Bright 
 wrote:

 On 11/8/2013 3:33 PM, deadalnix wrote:

 Getting a build master :D


 We clearly need a better title!


 There is a title for that already in the IT world: RELEASE 
 MANAGER.

 However, D project is chaos without any kind of management... 
 Moving to GitHub improved little bit, but from a software 
 engineering point of view it is far from a serious thing.

 This "Agenda" is what agile world typically calls a 
 SPRINT/ITERATION BACKLOG. As far as I know, nobody grooms the 
 DMD/Phobos backlog, people take items they like, or feel 
 challenged by.

 I know many people have bad opinion about agile process tools 
 such as Scrum, Kanban, XP, etc, but any organised way of doing 
 things is better than chaos, unless you prefer the anarchy as 
 seen in the Fred George's presentation (which I recommend - 
 http://www.youtube.com/watch?v=uk-CF7klLdA). Do not get me 
 wrong, I actually agree with Fred, but we do not have the 
 environment that is clearly needed for his kind of "software 
 anarchy".

 Are bugzilla votes respected btw?


Scrum etc is for commercial software development. It does not 
really work for Open Source development, because people will 
always work on what they personally consider most important and 
most interesting. In the agile world there is a customer, who 
prioritizes work items. This cannot be applied here.

Bugzilla votes and stuff are nice to let devs know about bugs, 
but not necessarily motivates to fix them.
Nov 14 2013
parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
 Scrum etc is for commercial software development. It does not 
 really work for Open Source development, because people will 
 always work on what they personally consider most important and 
 most interesting. In the agile world there is a customer, who 
 prioritizes work items. This cannot be applied here.

 Bugzilla votes and stuff are nice to let devs know about bugs, 
 but not necessarily motivates to fix them.


My Scrum experience tells me to humbly disagree because Scrum 
like all other agile process tools is all about experimentation. 
Almost all Scrum practices are applicable in open-source world. 
No Scrum team works the same as the other, they all have 
different ways of applying Scrum (that is why it is called a 
"process tool", not a methodology as many people use to call it).

Kanban is (IMHO) even more applicable in the open-source world as 
it has only two prescribed practices, the rest is up to the team 
to apply any agile practice they think will help the project...

Take a look how "big open-source guys" do things. Their core team 
(typically full-time employed) works on whatever is on the sprint 
backlog, while contributors all around the world take whatever 
they like working on (with help of mentors quite often). So, it 
is possible to have a nicely organised open-source project, if 
people are willing to do so.
Nov 14 2013
parent Brad Roberts <braddr puremagic.com> writes:
On 11/14/13 10:23 AM, Dejan Lekic wrote:

 Scrum etc is for commercial software development. It does not really work for
Open Source
 development, because people will always work on what they personally consider
most important and
 most interesting. In the agile world there is a customer, who prioritizes work
items. This cannot
 be applied here.

 Bugzilla votes and stuff are nice to let devs know about bugs, but not
necessarily motivates to
 fix them.


 My Scrum experience tells me to humbly disagree because Scrum like all other
agile process tools is
 all about experimentation. Almost all Scrum practices are applicable in
open-source world. No Scrum
 team works the same as the other, they all have different ways of applying
Scrum (that is why it is
 called a "process tool", not a methodology as many people use to call it).

 Kanban is (IMHO) even more applicable in the open-source world as it has only
two prescribed
 practices, the rest is up to the team to apply any agile practice they think
will help the project...

 Take a look how "big open-source guys" do things. Their core team (typically
full-time employed)
 works on whatever is on the sprint backlog, while contributors all around the
world take whatever
 they like working on (with help of mentors quite often). So, it is possible to
have a nicely
 organised open-source project, if people are willing to do so.


Which is pretty much exactly what we have.  All the paid developers (no one)
follow a core mission, 
and all the volunteers scratch the itch they want to address the most.

More seriously, can you look at the linux kernel, or any of the major browser
projects, or any of 
the major gui tool kits, or... and find a nice clear list of what's going to be
in them before they 
release?  Maybe close to the end of the release, but before or at the beginning
of the cycle?

More organization would be nice, but let's not ascribe too much faith that
we're all _that_ 
different from many other projects.  I think a key difference is that we have
so many more big 
things that aren't near where we want them to be that it's easier to be unhappy.
Nov 14 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Friday, 8 November 2013 at 20:09:57 UTC, Martin Nowak wrote:

 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


Update the processes so that there's a public beta release rather 
than only an "insider" beta release to better smooth things out. 
Right now 2.064 should be tagged as the latest public beta 
version with 2.063 as the current stable release.

--rt
Nov 08 2013
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
runtime loading of shared libraries on OSX, so that it works as on linux
I see b/10440 fixed in changelog, however does that mean it should work as
safely as on linux? (both runtime and nonruntime libs)

Also, IIRC, I thought 2.064 introduced support for loading D shared libs
safely from D, but see no mention of this in changelog?



On Fri, Nov 8, 2013 at 4:36 PM, Rob T <alanb ucora.com> wrote:


 On Friday, 8 November 2013 at 20:09:57 UTC, Martin Nowak wrote:


 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


 Update the processes so that there's a public beta release rather than
 only an "insider" beta release to better smooth things out. Right now 2.064
 should be tagged as the latest public beta version with 2.063 as the
 current stable release.

 --rt
Nov 08 2013
next sibling parent "Martin Nowak" <code dawg.eu> writes:
On Saturday, 9 November 2013 at 04:43:24 UTC, Timothee Cour wrote:

 runtime loading of shared libraries on OSX, so that it works as 
 on linux
 I see b/10440 fixed in changelog, however does that mean it 
 should work as
 safely as on linux? (both runtime and nonruntime libs)


I'm focusing on full linux support for now. Other platforms will 
follow.
Anything that currently works (Windows DLLs) is fairly broken.


 Also, IIRC, I thought 2.064 introduced support for loading D 
 shared libs
 safely from D, but see no mention of this in changelog?


We added the necessary low-level bits to support this, but quite 
a lot is still missing.
https://github.com/D-Programming-Language/druntime/pull/617
https://github.com/D-Programming-Language/druntime/pull/658
Nov 08 2013
prev sibling parent reply "Jacob Carlborg" <doob me.com> writes:
On Saturday, 9 November 2013 at 04:43:24 UTC, Timothee Cour wrote:


 runtime loading of shared libraries on OSX, so that it works as 
 on linux
 I see b/10440 fixed in changelog, however does that mean it 
 should work as
 safely as on linux? (both runtime and nonruntime libs)


Unfortunately no. I think the biggest obstacle is TLS. DMD 
emulates TLS on Mac OS X, which doesn't really work with dynamic 
libraries. It didn't exist natively on Mac OS X when DMD for D2 
was ported to Mac OS X. I guess that best option is that DMD 
start to use native TLS. That would mean we need to drop support 
for Mac OS X Snow Leopard (10.6). Unless we move the part of the 
dynamic linker that handles TLS to druntime, which I think is 
technially possible.

Except from that I think it might be easier to implement support 
for dynamic libraries on Mac OS X. The dynamic linker on Mac OS X 
has a much broader API than on Linux. We can use more of the 
existing functions there.

--
/Jacob Carlborg
Nov 09 2013
parent reply Timothee Cour <thelastmammoth gmail.com> writes:
On Sat, Nov 9, 2013 at 3:33 AM, Jacob Carlborg <doob me.com> wrote:


 On Saturday, 9 November 2013 at 04:43:24 UTC, Timothee Cour wrote:

  runtime loading of shared libraries on OSX, so that it works as on linux

 I see b/10440 fixed in changelog, however does that mean it should work as
 safely as on linux? (both runtime and nonruntime libs)


 Unfortunately no. I think the biggest obstacle is TLS. DMD emulates TLS on
 Mac OS X, which doesn't really work with dynamic libraries. It didn't exist
 natively on Mac OS X when DMD for D2 was ported to Mac OS X. I guess that
 best option is that DMD start to use native TLS. That would mean we need to
 drop support for Mac OS X Snow Leopard (10.6). Unless we move the part of
 the dynamic linker that handles TLS to druntime, which I think is
 technially possible.


10.6 is 3 releases old, it would be acceptable. Should we use a quick poll (
https://www.surveymonkey.com/) to vote for it?



 Except from that I think it might be easier to implement support for
 dynamic libraries on Mac OS X. The dynamic linker on Mac OS X has a much
 broader API than on Linux. We can use more of the existing functions there.

 --
 /Jacob Carlborg
Nov 09 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-11-10 00:32, Timothee Cour wrote:


 10.6 is 3 releases old, it would be acceptable. Should we use a quick
 poll (https://www.surveymonkey.com/) to vote for it?


Yes, it might be time to rethink that, now when Maverick has been released.

-- 
/Jacob Carlborg
Nov 10 2013
prev sibling next sibling parent "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Friday, 8 November 2013 at 20:09:57 UTC, Martin Nowak wrote:

 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


Can we add this page to the wiki homepage, for example in "Core 
Development" section? Probably, more people will see it.
Nov 09 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
Added language enhancements from my working list.

Kenji Hara


2013/11/9 Martin Nowak <code dawg.eu>


 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda
Nov 09 2013
prev sibling next sibling parent reply "Kelet" <kelethunter gmail.com> writes:
Are there any plans for adding compile-time checking or recursive
data types to std.variant's Algebraic? I think algebraic data
types are important and the current implementation is not
suitable to solve a good portion of problems that the intended
implementation could.

Could this be a possible goal for 2.065? If not, are we lacking
demand? Lacking someone willing to work on it?
Nov 09 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/9/13 9:10 AM, Kelet wrote:

 Are there any plans for adding compile-time checking or recursive
 data types to std.variant's Algebraic? I think algebraic data
 types are important and the current implementation is not
 suitable to solve a good portion of problems that the intended
 implementation could.

 Could this be a possible goal for 2.065? If not, are we lacking
 demand? Lacking someone willing to work on it?


Yah, I think we should add that. Please add it to the wiki.

Andrei
Nov 09 2013
parent Timothee Cour <thelastmammoth gmail.com> writes:
On Sat, Nov 9, 2013 at 9:46 AM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 On 11/9/13 9:10 AM, Kelet wrote:


 Are there any plans for adding compile-time checking or recursive
 data types to std.variant's Algebraic? I think algebraic data
 types are important and the current implementation is not
 suitable to solve a good portion of problems that the intended
 implementation could.

 Could this be a possible goal for 2.065? If not, are we lacking
 demand? Lacking someone willing to work on it?


 Yah, I think we should add that. Please add it to the wiki.

 Andrei


Regarding recursive/nested variants I posted code back in June:
thread:
http://forum.dlang.org/thread/xaganckgcdkfcmjamogh forum.dlang.org#post-mailman.1054.1371029915.13711.digitalmars-d:40puremagic.com
code:
https://github.com/timotheecour/dtools/blob/master/dtools/util/variant_nested.d
Nov 09 2013
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 11/8/13 12:09 PM, Martin Nowak wrote:

 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


IMHO, this shouldn't become a wish list of what individuals want the.  It
should be a list of what 
is actually being worked on.  Don't add to this list unless you yourself are
doing the work.
Nov 09 2013
next sibling parent Martin Nowak <code dawg.eu> writes:
On 11/09/2013 08:41 PM, Brad Roberts wrote:

 IMHO, this shouldn't become a wish list of what individuals want the.
 It should be a list of what is actually being worked on.  Don't add to
 this list unless you yourself are doing the work.


Yep, but seems to work out.
Nov 09 2013
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Brad Roberts:


 IMHO, this shouldn't become a wish list of what individuals 
 want the.  It should be a list of what is actually being worked 
 on.  Don't add to this list unless you yourself are doing the 
 work.


I think dmd 2.065 should focus on (some of) the unfinished parts 
of the language, and the eventually needed small breaking changes 
caused by that implementation. (So I don't like dmd 2.065 to 
focus on ICEs).

Bye,
bearophile
Nov 12 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/8/2013 12:09 PM, Martin Nowak wrote:

 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


My agenda for 2.065 is to cut down the size of the outstanding bug list.
Nov 11 2013
parent reply Manu <turkeyman gmail.com> writes:
On 12 November 2013 12:51, Walter Bright <newshound2 digitalmars.com> wrote:


 On 11/8/2013 12:09 PM, Martin Nowak wrote:


 I made a wiki page for that.
 Please discuss, improve and prioritize.
 http://wiki.dlang.org/Agenda


 My agenda for 2.065 is to cut down the size of the outstanding bug list.


How about the rvalue-temp -> ref thing? That's getting REALLY tired.
Nov 13 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2013 4:38 PM, Manu wrote:

 How about the rvalue-temp -> ref thing? That's getting REALLY tired.


I know, I know :-(
Nov 14 2013
parent Manu <turkeyman gmail.com> writes:
On 14 November 2013 20:51, Walter Bright <newshound2 digitalmars.com> wrote:


 On 11/13/2013 4:38 PM, Manu wrote:


 How about the rvalue-temp -> ref thing? That's getting REALLY tired.


 I know, I know :-(


So, 2.065 then :P
Nov 14 2013