www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Under 1000 opened bugs for Phobos

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
https://goo.gl/r24Izw

Some of them are D1 only; I'll make an executive decision about those 
soon. Some of them have been fixed or obviated by recent improvements. 
And finally the bulk of them need a little work each to get them fixed.

I'm thinking this has crowdsourcing written all over it. It would be 
great if many of us made one pass through the list and take a look at 
bugs with an eye for cleaning up the list.


Andrei
Nov 03 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/03/2015 09:35 AM, Andrei Alexandrescu wrote:
 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about those soon.
After speaking to Don I am closing D1-only Phobos bugs with "wontfix". If anyone wants to work on specific bugs, please reopen. Thanks! -- Andrei
Nov 03 2015
prev sibling next sibling parent reply Jeffery <Jeffery gmail.com> writes:
On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu 
wrote:
 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about 
 those soon. Some of them have been fixed or obviated by recent 
 improvements. And finally the bulk of them need a little work 
 each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It 
 would be great if many of us made one pass through the list and 
 take a look at bugs with an eye for cleaning up the list.


 Andrei
It would be nice if there was a very good tutorial that shows exactly how to contribute to D. I don't have the time to spend days figuring out how to get it all to work, etc but I could spend a few mins a day contributing to bugs and such. Would it be beneficial for someone to create an official video and documentation to help get people to contribute easily and correctly? e.g., I'm thinking of something like this: 1. Watch video, without too much nonsense, that explains the process 2. Download the distribution. 3. Apply what was in video(e.g., a simple example of fixing a bug) 4. Contribute FTW. Anything getting in the way is a downer. I don't want to spend 4 hours trying to figure out why the source won't compile. I've got better things to do with my time. If I'm reasonably confident that I can follow a simple and exact procedure that almost surely would work, then I'm more likely to go down that path. I think it would benefit D to have such things. But only those "in the know" can accomplish the task. (also, these captchas suck!!, every time I post, it says I have to wait 15 sec to repost: "Your last post was less than 15 seconds ago. Please wait a few seconds before trying again."... and that's after I answer the captcha correctly, which I then have to answer again!)
Nov 03 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/03/2015 02:36 PM, Jeffery wrote:
 On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu wrote:
 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about those
 soon. Some of them have been fixed or obviated by recent improvements.
 And finally the bulk of them need a little work each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It would be
 great if many of us made one pass through the list and take a look at
 bugs with an eye for cleaning up the list.


 Andrei
It would be nice if there was a very good tutorial that shows exactly how to contribute to D.
I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, is it what you need it to be? -- Andrei
Nov 03 2015
next sibling parent NVolcz <niklas.volcz gmail.com> writes:
On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu 
wrote:
 On 11/03/2015 02:36 PM, Jeffery wrote:
 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei
Windows instructions (We exclude quite many possible contributors because of this) (same for the building instructions)
Nov 03 2015
prev sibling next sibling parent Gary Willoughby <dev nomad.so> writes:
On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu 
wrote:
 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei
There's also these: http://wiki.dlang.org/Building_DMD http://wiki.dlang.org/Pull_Requests
Nov 03 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu 
wrote:

 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei
"Then, github detects the new code and offers assistance to create a pull request with just a couple of clicks." The problem is when your own branch is a few weeks/months old. Then you have to do some upstream/update etc. magic. It happened to me once or twice. It put me off a bit, although I only fixed typos and trivial stuff like that. It's not D, it's git(hub) that makes things complicated. It'd be good if you could just update your own branch on github (refork it or whatever) and then clone it onto your own machine. But it's not that straight forward. PS Jeffery, the first steps are really easy. It doesn't take long to have a repo up and running on your own machine.
Nov 03 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Nov 03, 2015 at 11:06:57PM +0000, Chris via Digitalmars-d wrote:
 On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu wrote:
 
I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, is it
what you need it to be? -- Andrei
"Then, github detects the new code and offers assistance to create a pull request with just a couple of clicks." The problem is when your own branch is a few weeks/months old. Then you have to do some upstream/update etc. magic. It happened to me once or twice. It put me off a bit, although I only fixed typos and trivial stuff like that.
It's not that hard. The thing is, the best way is to ALWAYS make changes in a topic branch, never on master. That way, you just pull upstream into master and rebase your topic branch: git checkout -b my_bugfix ... # make edits here git commit git checkout master git pull upstream master git checkout my_bugfix git rebase master # Now your fixes are updated. git push -f origin
 It's not D, it's git(hub) that makes things complicated. It'd be good
 if you could just update your own branch on github (refork it or
 whatever) and then clone it onto your own machine. But it's not that
 straight forward.
[...] I'm not sure I understand what's so non-straightforward about it. If you always work in a topic branch, as I suggested above, it should be relatively painless. It's when you make changes on master and then try to sync with upstream, that things become very messy, very quickly. Unless you're complaining about git itself, in which case my only suggestion is that you have to take the time to learn the "concept" behind git. It's very likely *not* what most people imagine when they think of "version control", and it's pretty important that you understand that when working with git, you have to think in terms of "directed acyclic graph" rather than "version control" in the traditional sense of the word. Trying to work with git with the wrong mental model of what it actually does will inevitably land you in a situation where you feel like you don't know how to fix it. T -- Life is complex. It consists of real and imaginary parts. -- YHL
Nov 03 2015
parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 4 November 2015 at 00:06:34 UTC, H. S. Teoh wrote:
 It's not that hard. The thing is, the best way is to ALWAYS 
 make changes in a topic branch, never on master. That way, you 
 just pull upstream into master and rebase your topic branch:

 	git checkout -b my_bugfix
 	... # make edits here
 	git commit
 	git checkout master
 	git pull upstream master
 	git checkout my_bugfix
 	git rebase master
 	# Now your fixes are updated.
 	git push -f origin


 It's not D, it's git(hub) that makes things complicated. It'd 
 be good if you could just update your own branch on github 
 (refork it or whatever) and then clone it onto your own 
 machine. But it's not that straight forward.
[...] I'm not sure I understand what's so non-straightforward about it. If you always work in a topic branch, as I suggested above, it should be relatively painless. It's when you make changes on master and then try to sync with upstream, that things become very messy, very quickly.
What I tried to do was to update my branch to the latest version of master and then send my humble fix back to my (updated) branch and up to master. The whole thing about "topic branch" and the array of commands that follow shows (me) that it is not straight forward. I have to look up/ask every time "Sorry, how do I do that again" - "rebase, upstream blah". Thing is, I expected github (not git) to be easier, like clicking on "Update branch", then git update git commit mychange.d and then go to github and just click on "make PR". IMO, it's a waste of time to deal with all those commands (upstream blah) when you have a homepage like github. They should handle it. But that's just my opinion. The base line is, it makes me think twice about changing something, especially when I could do it on the fly as in "Uh, there's something I could fix, wait ... Ah, no how do I do that again, uh, wait git upstream, no stop rebase ah f*ck! I'll do it tomorrow ..." (I won't)
 Unless you're complaining about git itself, in which case my 
 only suggestion is that you have to take the time to learn the 
 "concept" behind git. It's very likely *not* what most people 
 imagine when they think of "version control", and it's pretty 
 important that you understand that when working with git, you 
 have to think in terms of "directed acyclic graph" rather than 
 "version control" in the traditional sense of the word. Trying 
 to work with git with the wrong mental model of what it 
 actually does will inevitably land you in a situation where you 
 feel like you don't know how to fix it.


 T
Nov 03 2015
parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Wednesday, 4 November 2015 at 00:34:08 UTC, Chris wrote:
 What I tried to do was to update my branch to the latest 
 version of master and then send my humble fix back to my 
 (updated) branch and up to master. The whole thing about "topic 
 branch" and the array of commands that follow shows (me) that 
 it is not straight forward. I have to look up/ask every time 
 "Sorry, how do I do that again" - "rebase, upstream blah". 
 Thing is, I expected github (not git) to be easier, like 
 clicking on "Update branch", then
Keeping changes updated with master is not easy whether it is github or some other tool. If your branch and master both have changes you risk conflicts and those conflicts must be resolved. If you have a fix for your branch, then fix it. These are two separate operations and can be done independently of the other. If your branch can be merged cleanly then a rebase is not necessary; if it can't be merged cleanly you'll need to be in your dev environment. Having a UI do a rebase when it is clean for you might be nice, but it won't do you any good when real work is necessary (unless you want GitHub to be a full development environment).
Nov 05 2015
prev sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Tuesday, 3 November 2015 at 23:06:58 UTC, Chris wrote:
 On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei 
 Alexandrescu wrote:

 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei
"Then, github detects the new code and offers assistance to create a pull request with just a couple of clicks." The problem is when your own branch is a few weeks/months old. Then you have to do some upstream/update etc. magic. It happened to me once or twice. It put me off a bit, although I only fixed typos and trivial stuff like that. It's not D, it's git(hub) that makes things complicated. It'd be good if you could just update your own branch on github (refork it or whatever) and then clone it onto your own machine. But it's not that straight forward. PS Jeffery, the first steps are really easy. It doesn't take long to have a repo up and running on your own machine.
I might have missed a few details in the push command (writing from my phone), but iirc git will explain what to do: git clone <address of upstream> cd <dest. folder> git remote add <e.g. personal> <address of your fork> git checkout -b <branch name for feature> <your changes here> git push <e.g. personal> Then make a pull request on github To get master up to date: git checkout master git pull Then make a new branch as before. Using your own master doesn't really make sense unless your actually trying to publically fork the project. Just treat your github fork as a collection of personal branches that live at a different URL, which is easily managed with git remotes.
Nov 04 2015
prev sibling parent reply Gerald Jansen <gjansen ownmail.net> writes:
On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei Alexandrescu 
wrote:
 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei
Okay, so we have slight variations that cause confusion for newcomers like me: Model A: - directly clone upstream (becomes origin) - create topic-branch; work; commit - switch to master branch; pull --ff-only origin master - switch to topic-branch; rebase from master branch - create my fork in github and add remote myfork - push to myfork Model B: (recommended if you are planning to create PRs from the outset?) - first create my fork in github - clone my fork (becomes origin) - create topic-branch; work; commit - add remote upstream - switch to master branch; pull --ff-only upstream master - switch to topic-branch; rebase from master branch - push to origin Of course there are many possible workflows with git and github, but it would be helpful to beginners if the various D wiki pages (and advice on the forums) followed a consistent model.
Nov 06 2015
next sibling parent reply krzaq <dlangmailinglist krzaq.cc> writes:
On Friday, 6 November 2015 at 11:07:10 UTC, Gerald Jansen wrote:
 On Tuesday, 3 November 2015 at 19:42:58 UTC, Andrei 
 Alexandrescu wrote:
 I wrote this: http://wiki.dlang.org/Starting_as_a_Contributor, 
 is it what you need it to be? -- Andrei
Okay, so we have slight variations that cause confusion for newcomers like me: Model A: - directly clone upstream (becomes origin) - create topic-branch; work; commit - switch to master branch; pull --ff-only origin master - switch to topic-branch; rebase from master branch - create my fork in github and add remote myfork - push to myfork Model B: (recommended if you are planning to create PRs from the outset?) - first create my fork in github - clone my fork (becomes origin) - create topic-branch; work; commit - add remote upstream - switch to master branch; pull --ff-only upstream master - switch to topic-branch; rebase from master branch - push to origin Of course there are many possible workflows with git and github, but it would be helpful to beginners if the various D wiki pages (and advice on the forums) followed a consistent model.
Either way, just take a look how much of red tape is needed around >work<, when the opposite should be true: >work< should be the major part of any bugfixing. Visually it is staggering - the first time I read your post, I thought you'd simply forgotten to mention actual coding: http://i.imgur.com/fuiSxwj.png
Nov 06 2015
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2015 4:26 AM, krzaq wrote:
 Either way, just take a look how much of red tape is needed around >work<, when
 the opposite should be true: >work< should be the major part of any bugfixing.
Most of that is just setting things up initially. Once that is done, the incremental work for each PR is just a couple minutes.
 Visually it is staggering - the first time I read your post, I thought you'd
 simply forgotten to mention actual coding: http://i.imgur.com/fuiSxwj.png
It'd be nice if we could just fix code, but the project has too many people working on it and is too complex for that anymore.
Nov 06 2015
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/6/15 7:26 AM, krzaq wrote:
 Either way, just take a look how much of red tape is needed around
  >work<, when the opposite should be true: >work< should be the major
 part of any bugfixing.

 Visually it is staggering - the first time I read your post, I thought
 you'd simply forgotten to mention actual coding:
 http://i.imgur.com/fuiSxwj.png
It doesn't seem that bad to me. They are things you do once, and quite simple and common. We have a script called tools/update.sh that automates these steps, but teaching how to use and babysit that script would end up about as long winded. That said, if you have idea just let us know! Andrei
Nov 07 2015
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 6 November 2015 at 11:07:10 UTC, Gerald Jansen wrote:
 Okay, so we have slight variations that cause confusion for 
 newcomers like me:

 Model A:
 - directly clone upstream (becomes origin)
 - create topic-branch; work; commit
 - switch to master branch; pull --ff-only origin master
 - switch to topic-branch; rebase from master branch
 - create my fork in github and add remote myfork
 - push to myfork

 Model B: (recommended if you are planning to create PRs from 
 the outset?)
 - first create my fork in github
 - clone my fork (becomes origin)
 - create topic-branch; work; commit
 - add remote upstream
 - switch to master branch; pull --ff-only upstream master
 - switch to topic-branch; rebase from master branch
 - push to origin

 Of course there are many possible workflows with git and 
 github, but it would be helpful to beginners if the various D 
 wiki pages (and advice on the forums) followed a consistent 
 model.
Thanks for this post. There is some confusion, which makes people say "Naw, I dunno, maybe tomorrow." At least me!
Nov 06 2015
next sibling parent reply Gary Willoughby <dev nomad.so> writes:
On Friday, 6 November 2015 at 12:46:16 UTC, Chris wrote:
 Thanks for this post. There is some confusion, which makes 
 people say "Naw, I dunno, maybe tomorrow." At least me!
It's all in the wiki: http://wiki.dlang.org/Pull_Requests
Nov 06 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/6/15 11:01 AM, Gary Willoughby wrote:
 On Friday, 6 November 2015 at 12:46:16 UTC, Chris wrote:
 Thanks for this post. There is some confusion, which makes people say
 "Naw, I dunno, maybe tomorrow." At least me!
It's all in the wiki: http://wiki.dlang.org/Pull_Requests
I linked http://wiki.dlang.org/Pull_Requests and http://wiki.dlang.org/Starting_as_a_Contributor to one another. -- Andrei
Nov 07 2015
parent Chris <wendlec tcd.ie> writes:
On Saturday, 7 November 2015 at 17:45:52 UTC, Andrei Alexandrescu 
wrote:
 On 11/6/15 11:01 AM, Gary Willoughby wrote:
 On Friday, 6 November 2015 at 12:46:16 UTC, Chris wrote:
 Thanks for this post. There is some confusion, which makes 
 people say
 "Naw, I dunno, maybe tomorrow." At least me!
It's all in the wiki: http://wiki.dlang.org/Pull_Requests
I linked http://wiki.dlang.org/Pull_Requests and http://wiki.dlang.org/Starting_as_a_Contributor to one another. -- Andrei
Ok, so I will delete my current branch and start from scratch following the recommendations. Maybe it'll be easier for me to keep up to date with phobos and make more PRs. In my case it's just typos and easy stuff like that, but every little helps :)
Nov 07 2015
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/6/2015 4:46 AM, Chris wrote:
 Thanks for this post. There is some confusion, which makes people say "Naw, I
 dunno, maybe tomorrow." At least me!
If you want, you can simply post a patch to bugzilla, which will then wait for someone to turn it into a PR.
Nov 06 2015
prev sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Friday, 6 November 2015 at 11:07:10 UTC, Gerald Jansen wrote:
 Model A:

 Model B: (recommended if you are planning to create PRs from 
 the outset?)
Go with Model B, it gets the origin/upstream naming right. Besides that, potatoes potatoes.
 Of course there are many possible workflows with git and 
 github, but it would be helpful to beginners if the various D 
 wiki pages (and advice on the forums) followed a consistent 
 model.
If its open source its on github, if its on github people use pull-requests. How many ways are there to do pull request?
Nov 06 2015
prev sibling next sibling parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu 
wrote:
 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about 
 those soon. Some of them have been fixed or obviated by recent 
 improvements. And finally the bulk of them need a little work 
 each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It 
 would be great if many of us made one pass through the list and 
 take a look at bugs with an eye for cleaning up the list.


 Andrei
I skimmed through the list, looking for easy starters. This is what in the end held me back: - comment saying how a bug-fix will break code - unfinished discussion about how its not a bug, (or how to solve it, e.g. https://issues.dlang.org/show_bug.cgi?id=14485) - halfway fixes and no clear path how to fix the other half (e.g. https://issues.dlang.org/show_bug.cgi?id=4391, curry was renamed to partial to avoid confusion. Now do we still want curry?) - unclear goals (e.g. https://issues.dlang.org/show_bug.cgi?id=4656 `Let's keep it opened until the error message is fixed.`) I do not know what to do with that stuff. In most cases I figure they require an executive decision. What I can do is go through the list and recommend bugs to be closed/wontfix.
Nov 05 2015
prev sibling parent reply BBaz <2b.temp gmx.com> writes:
On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu 
wrote:
 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about 
 those soon. Some of them have been fixed or obviated by recent 
 improvements. And finally the bulk of them need a little work 
 each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It 
 would be great if many of us made one pass through the list and 
 take a look at bugs with an eye for cleaning up the list.


 Andrei
Hello, I've reviewed the list and found a subset of 30 bugs that I've closed because whatever is my position it was clear that they are fixed now or invalid. However, I've spotted "bearophile". He has opened a lot of issues just because he wanted this or that in std.range. I think that most of his issues could be closed because he should rather discuss on the NG or even propose an implementation on GH... So I don't know...and I ask, should the garbages from bearophile be closed ?
Dec 01 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 12/1/15 9:17 AM, BBaz wrote:
 On Tuesday, 3 November 2015 at 14:35:08 UTC, Andrei Alexandrescu wrote:
 https://goo.gl/r24Izw

 Some of them are D1 only; I'll make an executive decision about those
 soon. Some of them have been fixed or obviated by recent improvements.
 And finally the bulk of them need a little work each to get them fixed.

 I'm thinking this has crowdsourcing written all over it. It would be
 great if many of us made one pass through the list and take a look at
 bugs with an eye for cleaning up the list.


 Andrei
Hello, I've reviewed the list and found a subset of 30 bugs that I've closed because whatever is my position it was clear that they are fixed now or invalid. However, I've spotted "bearophile". He has opened a lot of issues just because he wanted this or that in std.range. I think that most of his issues could be closed because he should rather discuss on the NG or even propose an implementation on GH... So I don't know...and I ask, should the garbages from bearophile be closed ?
Please list links to those here, and thanks for all your work! -- Andrei
Dec 01 2015
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/1/15 9:17 AM, BBaz wrote:

 However, I've spotted "bearophile". He has opened a lot of issues just
 because he wanted this or that in std.range. I think that most of his
 issues could be closed because he should rather discuss on the NG or
 even propose an implementation on GH...
Open enhancements should be left alone IMO. Unless it has been decided that there is zero possibility for them being implemented, they are just waiting for someone to do it. Enhancements also shouldn't count towards any open "bug" count. -Steve
Dec 01 2015
parent reply BBaz <2b.temp gmx.com> writes:
On Tuesday, 1 December 2015 at 14:50:24 UTC, Steven Schveighoffer 
wrote:
 On 12/1/15 9:17 AM, BBaz wrote:

 However, I've spotted "bearophile". He has opened a lot of 
 issues just
 because he wanted this or that in std.range. I think that most 
 of his
 issues could be closed because he should rather discuss on the 
 NG or
 even propose an implementation on GH...
Open enhancements should be left alone IMO. Unless it has been decided that there is zero possibility for them being implemented, they are just waiting for someone to do it. Enhancements also shouldn't count towards any open "bug" count. -Steve
I understand, but there are much...not 3 or 4 , more something like 20... Anyway, message get, i'll post the list tomorrow.
Dec 01 2015
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 12/1/15 9:56 AM, BBaz wrote:
 On Tuesday, 1 December 2015 at 14:50:24 UTC, Steven Schveighoffer wrote:
 On 12/1/15 9:17 AM, BBaz wrote:

 However, I've spotted "bearophile". He has opened a lot of issues just
 because he wanted this or that in std.range. I think that most of his
 issues could be closed because he should rather discuss on the NG or
 even propose an implementation on GH...
Open enhancements should be left alone IMO. Unless it has been decided that there is zero possibility for them being implemented, they are just waiting for someone to do it. Enhancements also shouldn't count towards any open "bug" count.
I understand, but there are much...not 3 or 4 , more something like 20... Anyway, message get, i'll post the list tomorrow.
Yeah, bearophile is like that, he has a lot of ideas ;) Some of them have been implemented, after sitting for a long time. So I don't think it's correct to close them. I'm all for closing ones that absolutely won't be implemented though. -Steve
Dec 01 2015
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
BBaz:

 So I don't know...and I ask, should the garbages from 
 bearophile be closed ?
Hello, I use D every day, and there are several functions that I'd like in Phobos. I think all/most of them can be of general usefulness. While I am often wrong, those ERs come from plenty of experience coding in D and other languages, so throwing them away *en masse* is unwise. They should be judged singularly. Bye, bearophile
Dec 02 2015
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 12/01/2015 03:17 PM, BBaz wrote:
 So I don't know...and I ask, should the garbages from bearophile be
 closed ?
This is a loaded question.
Dec 03 2015