www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.internals - 15th Planning (national congress edition)

reply Martin Nowak <code dawg.eu> writes:
Let's just have a short planning for the upcoming 3 weeks.

Agenda:
- fix remaining 2.072 regressions
- finish scope story
- schedule for 2.073
- more CI testing
- public calendar
- <plese add your own>

Personal note, I don't have much time left over until 17th of 
Nov. Currently working fairly intensively in China (hence the 
reference in the title ;)).

====================



2.072.0 was quite bumpy and we need to fixup a few more 
regressions that showed up. One reason for this is still the long 
2.071 release period, but there have been some discussions about 
fixing some underlying causes and improving on testing (see CI 
testing below).
We should get this done within the next 3 weeks, so we can polish 
2.072.



Obviously I want to get back to sane release cycles and smaller 
releases.
We can discuss whether 2 months are too frequent, but let's get 
back to that for now.
So let's target 2.073 to be released for mid december (2 month 
after the targeted 2.072 release). If we miss that we'd have to 
delay the beta until beg of Jan after the holiday season.



We (shortly) reviewed and merged the major part of the scope 
story into the feature branch 
(https://github.com/dlang/dmd/pull/5972) after a clearing 
discussion about the scope of that feature and it's 
implementation.
The major 3 parts of scope are fairly straightforward:
- fix any escaping of scoped symbols
- add return scope to allow returning of scoped parameters
- add lots of scope inference to make it palatable

The biggest difficulty was that you can get named aliases 
(pointers or references) to scoped variables. Hence we needed all 
this (relatively simple) lifetime algebra to handle derived 
expressions.

   scope ubyte[3] buf;
   ubyte[] a = buf[]; // pointer to scoped data

In any case we should make the scope feature releasable within 
the next 4-5 weeks.
Including documentation, changelog, an introductionary article, 
and at best an RC/Unique/WeakRef prototype library on dub.



I hardly have time for this myself, and we don't necessarily have 
to target 2.073, but we seem to have a good proposal to fix the 
long manglings thanks to Rainer Schütze.
https://github.com/dlang/dmd/pull/5855
I'd would still require some tool support for demangling I guess 
(what about gdb?).



The last release showed that we're still not testing enough, b/c 
we're still breaking too many projects.
That might be partly b/c of missing test coverage, and negligent 
when changing phobos before adding a breaking change to dmd.
To throttle the amount of introducing issues we got another 
server to test all dlang PRs with a couple of D projects.

   https://ci.dawg.eu/

All projects in their do pass their test suite with 2.071.2.



I created a public google calendar for anything dlang.
https://calendar.google.com/calendar/embed?src=ut29n9vq9vu3ad4kbaabeed1d8%40group.calendar.google.com
Let's please get a few more admins on this, despite me and 
Mihail, and have all D dates in their.
For now it contains the planning meetings and my proposed next 
beta/release date.

We should prolly sync all the local D meetups into this, could 
even be automated https://zapier.com/app/editor/template/4701.

====================

That's about it from my side
Nov 09 2016
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2016 4:01 PM, Martin Nowak wrote:

 - finish scope story


The only thing left on that is allowing this to work:

    safe void foo() {
     int i;
     int* pi = &i;
   }

With the other improvements to scope, this no longer needs to be disallowed.
Nov 09 2016
parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 10 November 2016 at 00:26:59 UTC, Walter Bright 
wrote:

 On 11/9/2016 4:01 PM, Martin Nowak wrote:

 - finish scope story


 The only thing left on that is allowing this to work:


+bugfixes, docs, changelog, and article


    safe void foo() {
     int i;
     int* pi = &i;
   }

 With the other improvements to scope, this no longer needs to 
 be disallowed.


Which is great and make  safe much more useful, but only one 
aspect of DIP1000.
I think being able to tie the lifetime of a return value to the 
arguments of a function is the more fundamental and important 
change.
Nov 09 2016
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/9/2016 8:13 PM, Martin Nowak wrote:

 On Thursday, 10 November 2016 at 00:26:59 UTC, Walter Bright wrote:

 On 11/9/2016 4:01 PM, Martin Nowak wrote:

 - finish scope story


 The only thing left on that is allowing this to work:


 +bugfixes, docs, changelog, and article


No unfixed bugs reported on it. I agree with the latter 3. Also, I am going to 
deliver a presentation on it next Wednesday at nwcpp.org.



    safe void foo() {
     int i;
     int* pi = &i;
   }

 With the other improvements to scope, this no longer needs to be disallowed.


 Which is great and make  safe much more useful, but only one aspect of DIP1000.
 I think being able to tie the lifetime of a return value to the arguments of a
 function is the more fundamental and important change.


I agree. This is just fixing a loose end.
Nov 09 2016
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,i,n,t,e,r,n,a,l,s
Subject: Re: 15th Planning (national congress edition)
References: <rsxfyebqlrryoblhylml forum.dlang.org>
In-Reply-To: <rsxfyebqlrryoblhylml forum.dlang.org>

--RefJvR3IFt3AQAc1oncFfTKhFJAKWlLcV
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 11/10/2016 02:01 AM, Martin Nowak wrote:


=20
 2.072.0 was quite bumpy and we need to fixup a few more regressions tha=


t

 showed up. One reason for this is still the long 2.071 release period,
 but there have been some discussions about fixing some underlying cause=


s

 and improving on testing (see CI testing below).
 We should get this done within the next 3 weeks, so we can polish 2.072=


=2E

This is my current main priority and I am aiming for 2.072.1 beta in 1
week, unless you have any objections. Currently reducing and making
bugzilla issues for all found regressions, will give a go at fixing them
after.






 In any case we should make the scope feature releasable within the next=



 4-5 weeks.
 Including documentation, changelog, an introductionary article, and at
 best an RC/Unique/WeakRef prototype library on dub.


On my own TODO list for scope:

- enhance exiting test cases to include more real-world examples based
on our discussions
- rewrite DIP1000 to reflect actual implementation
- enable DIP25 by default in master (aiming 2.073)

I'd also like to discuss enhancement for the proposal which would remove
the different between ref and pointer handling in lifetime analysis and
would allow to merge `return ref` and `return scope` into one entity (at
cost of loosing some features that I consider of no practical use). This
is not necessary but would be nice to consider before design get set in
stone.

As I have already mentioned before, would be really useful to get a
dedicated trello board (or at least a column in existing one) to track
all small todo points regarding scope implementation. Ongoing problem in
new D features is that last 20% of any implementation gets forgotten in
process of development and when it released, it heavily lacks polish
required to make good impression.

(I don't have admin access to trello board btw, don't know if it is
intentional or accidental)

---------------------------------------------------

On a DIP status - final judgement for DIP1001 and DIP1002 will be
published as soon as Andrei finds time to write a formal response. There
were no new changes in their respective documents since last mention.

There are two new unmerged proposal PRs that are in pretty close to
getting into queue. I will only merge them after response to previous
ones is published to ensure no new requirements appear.


--RefJvR3IFt3AQAc1oncFfTKhFJAKWlLcV--
Nov 10 2016
parent reply Martin Nowak <code dawg.eu> writes:
On Thursday, 10 November 2016 at 13:17:35 UTC, Dicebot wrote:

 This is my current main priority and I am aiming for 2.072.1 
 beta in 1 week, unless you have any objections. Currently 
 reducing and making bugzilla issues for all found regressions, 
 will give a go at fixing them after.


Yes, one week (let's say Nov 19-20th) sounds good for me as well.
I hope I can do the regression fix for 
https://trello.com/c/rWhNcvLt/246-issue-16574-reg-2-072-0-b1-unexplained-errors-about-functions-tha
-overridde-anything until then. Not sure about the others on the Trello heap.


 I'd also like to discuss enhancement for the proposal which 
 would remove the different between ref and pointer handling in 
 lifetime analysis and would allow to merge `return ref` and 
 `return scope` into one entity (at cost of loosing some 
 features that I consider of no practical use). This is not 
 necessary but would be nice to consider before design get set 
 in stone.


Yes it also seems to me we only need "return scope", "return 
scope ref", and "scope ref". Because "return ref" seems useless 
if you can escape the reference inside of the function.
Would like to have more than a gut feeling for that 
argument/decision.


 Ongoing problem in new D features is that last 20% of any 
 implementation gets forgotten in process of development and 
 when it released, it heavily lacks polish required to make good 
 impression.


You might want to try adding a scope card to the backlog that has 
a checklist for all the small stuff, though you'd need to have 
the examples as an attachment, gist, or so.


 (I don't have admin access to trello board btw, don't know if 
 it is
 intentional or accidental)


Done
Nov 10 2016
parent Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D,.,i,n,t,e,r,n,a,l,s
Subject: Re: 15th Planning (national congress edition)
References: <rsxfyebqlrryoblhylml forum.dlang.org>
 <o01s1g$2g54$1 digitalmars.com> <vztsybforwehsflurezp forum.dlang.org>
In-Reply-To: <vztsybforwehsflurezp forum.dlang.org>

--xnPUXAPPhx4uOmOdi5dXUq85g3vWucLNn
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


 I'd also like to discuss enhancement for the proposal which would
 remove the different between ref and pointer handling in lifetime
 analysis and would allow to merge `return ref` and `return scope` into=





 one entity (at cost of loosing some features that I consider of no
 practical use). This is not necessary but would be nice to consider
 before design get set in stone.


=20
 Yes it also seems to me we only need "return scope", "return scope ref"=


,

 and "scope ref". Because "return ref" seems useless if you can escape
 the reference inside of the function.
 Would like to have more than a gut feeling for that argument/decision.


I will look into it after updating existing DIP1000 document to match
implementation.


 Ongoing problem in new D features is that last 20% of any
 implementation gets forgotten in process of development and when it
 released, it heavily lacks polish required to make good impression.


=20
 You might want to try adding a scope card to the backlog that has a
 checklist for all the small stuff, though you'd need to have the
 examples as an attachment, gist, or so.


Sure: https://trello.com/c/JOxCazeF/263-dip1000-scope-implementation

I don't think such approach (packing everything into one board) scales
well but it is not important now so let's use whatever you are
comfortable with.


--xnPUXAPPhx4uOmOdi5dXUq85g3vWucLNn--
Nov 17 2016
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Thursday, 10 November 2016 at 00:01:54 UTC, Martin Nowak wrote:



 I created a public google calendar for anything dlang.
 https://calendar.google.com/calendar/embed?src=ut29n9vq9vu3ad4kbaabeed1d8%40group.calendar.google.com
 Let's please get a few more admins on this, despite me and 
 Mihail, and have all D dates in their.
 For now it contains the planning meetings and my proposed next 
 beta/release date.

 We should prolly sync all the local D meetups into this, could 
 even be automated https://zapier.com/app/editor/template/4701.


Done :)
Nov 10 2016
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On Thursday, 10 November 2016 at 00:01:54 UTC, Martin Nowak wrote:

 Let's just have a short planning for the upcoming 3 weeks.

 Agenda:
 - fix remaining 2.072 regressions
 - finish scope story
 - schedule for 2.073
 - more CI testing
 - public calendar
 - <plese add your own>


Sorry to be late to the party, I'm on the road. Things I want to 
get to:

* Push checkedint into Phobos
* Push RCBuffer into Phobos, which is the first safe refcounted 
buffer that works with qualifiers. That should open the road for 
the next item, which is
* Get going on a DIP on creating safe reference counted types. 
The loose end that needs attention is making sure that methods 
that return "ref" to reference-counted stuff don't leave said 
references dangling upon assignment.
* Connect students to the project


Andrei
Nov 10 2016
parent Martin Nowak <code dawg.eu> writes:
On Friday, 11 November 2016 at 07:47:02 UTC, Andrei Alexandrescu 
wrote:

 Sorry to be late to the party, I'm on the road.


No hurries, this is an async meeting and can go on for a few 
days. We'd hardly ever find synchronous time for all of us.
You can subscribe to the dlang calendar linked in the OP for the 
dates.


 * Push RCBuffer into Phobos, which is the first safe refcounted 
 buffer that works with qualifiers. That should open the road 
 for the next item, which is


Missed that discussion, what's the difference between an RCBuffer 
and RC!(ubyte[16])?


 * Get going on a DIP on creating safe reference counted types.


Why we need a full DIP for that? It's the main goal for DIP1000 
and almost fully reached by that, except for that small hole 
mentioned below.


 The loose end that needs attention is making sure that methods 
 that return "ref" to reference-counted stuff don't leave said 
 references dangling upon assignment.


One idea for that is to disallow passing 2 arguments (call side) 
by ref, if their lifetime isn't the same. We could do more fancy 
stuff, e.g. check whether one argument could actually be an alias 
to the other, but that would require some exceptions, e.g. for 
`void[16] buf`.
I'm not a fan of the auto-increment approach, b/c it fails for 
Unique.
Anyhow this is not the right place to discuss, but the use-case 
seems rather rare to me, so we might move on with 
RC/Unique/WeakRef in a dub library, before fixing that and moving 
it to phobos.
Nov 11 2016
prev sibling parent Martin Nowak <code dawg.eu> writes:
On Thursday, 10 November 2016 at 00:01:54 UTC, Martin Nowak wrote:


Forgot to mention that, I'll be offline from now until about 18th 
of Nov.



 Nov 11 2016