www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Vision for the first semester of 2016

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
Jan 24
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 3:37 PM, Andrei Alexandrescu wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
There is a couple of things I want on there. 1. scope to be fixed and fully implemented (I'll bring some use cases to the table) 2. assumenogc or something similar. That way IAllocator can be nogc. Which to me is a requirement before it is out of experimental. Number 1 is the most important for me. Otherwise there will be no review/PR for image library this year.
Jan 24
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/24/2016 10:07 PM, Rikki Cattermole wrote:
 1. scope to be fixed and fully implemented
     (I'll bring some use cases to the table)
 2.  assumenogc or something similar.
     That way IAllocator can be  nogc. Which to me is a requirement
 before it is out of experimental.
Both are under the larger headline "Memory Management." -- Andrei
Jan 24
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 4:13 PM, Andrei Alexandrescu wrote:
 On 01/24/2016 10:07 PM, Rikki Cattermole wrote:
 1. scope to be fixed and fully implemented
     (I'll bring some use cases to the table)
 2.  assumenogc or something similar.
     That way IAllocator can be  nogc. Which to me is a requirement
 before it is out of experimental.
Both are under the larger headline "Memory Management." -- Andrei
Okay, I like specifics since then you can tick it off for next round ;)
Jan 24
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
Something went wrong here:
 We fell short of our 2000 pull requests goal in H2 2015. We 
 have had only 1 1378 pull requests.
In addition to the extraneous "1", the link is bad: "No results matched your search."
Jan 24
prev sibling next sibling parent reply Puming <zhaopuming gmail.com> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
For PRs, I suggest the goal to be number of PRs MERGED instead of created. That may provide the core team a subconsious incentive to look at long pending PRs and hit a good cycle. For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide seems a good candidate(native D, crossplatform). A good official supported GUI library will attract many people.
Jan 24
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 4:21 PM, Puming wrote:
 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
For PRs, I suggest the goal to be number of PRs MERGED instead of created. That may provide the core team a subconsious incentive to look at long pending PRs and hit a good cycle. For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide seems a good candidate(native D, crossplatform). A good official supported GUI library will attract many people.
That won't be happening anytime soon. Until we have image and windowing in Phobos (I'm working on both) there is no way a GUI toolkit is going in. And from what I know there will be a LOT of work to update it.
Jan 24
next sibling parent reply Puming <zhaopuming gmail.com> writes:
On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole 
wrote:
 On 25/01/16 4:21 PM, Puming wrote:
 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei 
 Alexandrescu wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei
For PRs, I suggest the goal to be number of PRs MERGED instead of created. That may provide the core team a subconsious incentive to look at long pending PRs and hit a good cycle. For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide seems a good candidate(native D, crossplatform). A good official supported GUI library will attract many people.
That won't be happening anytime soon. Until we have image and windowing in Phobos (I'm working on both) there is no way a GUI toolkit is going in. And from what I know there will be a LOT of work to update it.
Well I'm not saying that a GUI toolkit should go into Phobos. I'd rather it stand alone, while taking some official support, say, link in D frontpage(like visualD).
Jan 24
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 6:47 PM, Puming wrote:
 On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole wrote:
 On 25/01/16 4:21 PM, Puming wrote:
 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
For PRs, I suggest the goal to be number of PRs MERGED instead of created. That may provide the core team a subconsious incentive to look at long pending PRs and hit a good cycle. For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide seems a good candidate(native D, crossplatform). A good official supported GUI library will attract many people.
That won't be happening anytime soon. Until we have image and windowing in Phobos (I'm working on both) there is no way a GUI toolkit is going in. And from what I know there will be a LOT of work to update it.
Well I'm not saying that a GUI toolkit should go into Phobos. I'd rather it stand alone, while taking some official support, say, link in D frontpage(like visualD).
I want us to hold off on that as well. I want people to really have a go with making GUI toolkits in D without the worry about how to do the cross platformy technical things. We just don't know what could be done yet and I'm looking forward to finding out.
Jan 24
parent reply Puming <zhaopuming gmail.com> writes:
On Monday, 25 January 2016 at 05:50:34 UTC, Rikki Cattermole 
wrote:
 I want us to hold off on that as well.
I agree that we need a more solid base.
 I want people to really have a go with making GUI toolkits in D 
 without the worry about how to do the cross platformy technical 
 things.
Is dlangui a good start on this?
 We just don't know what could be done yet and I'm looking 
 forward to finding out.
I think improving dlangide will give us many opportunities for what a good D native GUI library needs.
Jan 24
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 7:18 PM, Puming wrote:
 On Monday, 25 January 2016 at 05:50:34 UTC, Rikki Cattermole wrote:
 I want us to hold off on that as well.
I agree that we need a more solid base.
 I want people to really have a go with making GUI toolkits in D
 without the worry about how to do the cross platformy technical things.
Is dlangui a good start on this?
No, too much code for what the base needs. For windowing you want it just above what the OS does in a cross platform abstracted way. So no controls support or any other gruff that a GUI toolkit provides.
 We just don't know what could be done yet and I'm looking forward to
 finding out.
I think improving dlangide will give us many opportunities for what a good D native GUI library needs.
No, it already has its core code. By in large what you want to innovate is the core code, not what a specific control does. I'm not saying dlangui is the wrong way to go. We just don't know which way is right just yet and that is ok.
Jan 24
prev sibling parent Andre Polykanine via Digitalmars-d-announce writes:
PvDda> I think improving dlangide will give us many opportunities for
PvDda> what a good D native GUI library needs.

Right   you   are.   However,   it  would  be  great  if  such  a  GUI
library/framework  could  be able to produce GUIs accessible to screen
readers.  And  it  would be more than great if the IDE itself could be
accessible.  However,  with  Dlangui  it's  not  the  case,  namely on
Windows.

Andre.
Jan 25
prev sibling next sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-01-25 at 16:49 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:
=20
[=E2=80=A6]
 That won't be happening anytime soon.
 Until we have image and windowing in Phobos (I'm working on both)
 there=C2=A0
 is no way a GUI toolkit is going in. And from what I know there will
 be=C2=A0
 a LOT of work to update it.
How about we have a D library infrastructure such that Phobos gets smaller and smaller providing only absolutely necessary core things over druntime. If the Python, Rust, Go, etc. stories tell us anything, it is that the days of "batteries included" distributions is long, long dead. DVCS changes the game. Phobos the library needs to go to be replaced by a library search and use system. Oh we already have one, Dub. The strategy should be "get rid of anything in Phobos that can be put out as a separate library". =C2=A0 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 24
next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:
 The strategy should be "get rid of anything in Phobos that can 
 be put
 out as a separate library".
This makes no sense as a standard: since neither DMD nor druntime is allowed to depend upon Phobos, everything in Phobos *could* be put into a separate library.
Jan 24
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 8:16 PM, tsbockman wrote:
 On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:
 The strategy should be "get rid of anything in Phobos that can be put
 out as a separate library".
This makes no sense as a standard: since neither DMD nor druntime is allowed to depend upon Phobos, everything in Phobos *could* be put into a separate library.
I had a long post replying to Russel and to put it bluntly, its just wrong. We are most definitely losing people simply because they expect certain code in the standard library. Like windowing and image. Things like sockets are lower on their priority list. In their mind we are not even a 'programming language'. Phobos does need to be bigger, but not fully inclusive. If most people won't use something, don't add it. Sure there is arguments against this, but there is a certain amount we must standardize and agree upon as a community. Phobos most certainly is the place to do this. Otherwise we will be going round in circles for a much longer period then we should and not growing much.
Jan 24
next sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On 25/01/16 8:16 PM, tsbockman wrote:

 On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:

 The strategy should be "get rid of anything in Phobos that can be put
 out as a separate library".
This makes no sense as a standard: since neither DMD nor druntime is allowed to depend upon Phobos, everything in Phobos *could* be put into a separate library.
I had a long post replying to Russel and to put it bluntly, its just wrong. We are most definitely losing people simply because they expect certain code in the standard library. Like windowing and image. Things like sockets are lower on their priority list. In their mind we are not even a 'programming language'. Phobos does need to be bigger, but not fully inclusive. If most people won't use something, don't add it. Sure there is arguments against this, but there is a certain amount we must standardize and agree upon as a community. Phobos most certainly is the place to do this. Otherwise we will be going round in circles for a much longer period then we should and not growing much.
I'm going to quote you there: to put it bluntly you are plain wrong. We do not, and no one does, need a kitchen sink standard library. Look at python, look at Go, these are two of the fastest growing languages out there. They are: - Extremely easy to pick up and use. - Have excellent documentation and simple naming conventions - Have fantastic 3rd party open source libraries How does one find the "right" library for a task? - The community refers devs to their preferred / popular libs - There are excellent tutorials / how-tos that show case the library If we spent less time fussing of what gets into phobos and more time making good libraries for code.dlang.org and let the best ones win out we'd get much better stuff much quicker.
Jan 25
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 9:21 PM, Rory McGuire via Digitalmars-d-announce wrote:
 On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com
 <mailto:digitalmars-d-announce puremagic.com>> wrote:

     On 25/01/16 8:16 PM, tsbockman wrote:

         On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:

             The strategy should be "get rid of anything in Phobos that
             can be put
             out as a separate library".


         This makes no sense as a standard: since neither DMD nor druntime is
         allowed to depend upon Phobos, everything in Phobos *could* be
         put into
         a separate library.


     I had a long post replying to Russel and to put it bluntly, its just
     wrong.
     We are most definitely losing people simply because they expect
     certain code in the standard library. Like windowing and image.
     Things like sockets are lower on their priority list.

     In their mind we are not even a 'programming language'.

     Phobos does need to be bigger, but not fully inclusive.
     If most people won't use something, don't add it.

     Sure there is arguments against this, but there is a certain amount
     we must standardize and agree upon as a community. Phobos most
     certainly is the place to do this. Otherwise we will be going round
     in circles for a much longer period then we should and not growing much.


 I'm going to quote you there: to put it bluntly you are plain wrong.

 We do not, and no one does, need a kitchen sink standard library. Look
 at python, look at Go, these are two of the fastest growing languages
 out there. They are:
 - Extremely easy to pick up and use.
 - Have excellent documentation and simple naming conventions
 - Have fantastic 3rd party open source libraries
Nope just no. I am only talking about newbies here. They will pick distributions of Python that are all encompassing. http://winpython.github.io/#overview When it comes to newbies who come into programming seeing from all of their previous experience that things like GUI toolkit just comes with the language they just don't care if it was provided "extra" by a distribution or by the language itself. Only that they did exactly 0 beyond importing and using it. During my degree, the final programming class was Python. Everyone used WinPython except me. At the time pip didn't even work in it. Yes you heard me correct. When they had to use other code, they had no way or will to even try what wasn't part of it and so in their eyes what they had downloaded was Python. Because it really does appear to be Python. Especially with the IDE and QT being part of it... And right here is the problem. They expected and there it was. You will see this in every language. From Java to PHP. The community in general misses the point here time and time again. It wasn't until recently that Adam saw how bad things were just to add some context.
 How does one find the "right" library for a task?
 - The community refers devs to their preferred / popular libs
 - There are excellent tutorials / how-tos that show case the library

 If we spent less time fussing of what gets into phobos and more time
 making good libraries for code.dlang.org <http://code.dlang.org> and let
 the best ones win out we'd get much better stuff much quicker.
And I agree with you. As long as we have the bare bones in Phobos such as windowing and image library we can actually fight over GUI toolkits. Instead of repeatedly doing the same code over and over poorly.
Jan 25
next sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
On Mon, Jan 25, 2016 at 10:31 AM, Rikki Cattermole via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On 25/01/16 9:21 PM, Rory McGuire via Digitalmars-d-announce wrote:

 On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com
 <mailto:digitalmars-d-announce puremagic.com>> wrote:

     On 25/01/16 8:16 PM, tsbockman wrote:

         On Monday, 25 January 2016 at 07:03:35 UTC, Russel Winder wrote:

             The strategy should be "get rid of anything in Phobos that
             can be put
             out as a separate library".


         This makes no sense as a standard: since neither DMD nor druntime
 is
         allowed to depend upon Phobos, everything in Phobos *could* be
         put into
         a separate library.


     I had a long post replying to Russel and to put it bluntly, its just
     wrong.
     We are most definitely losing people simply because they expect
     certain code in the standard library. Like windowing and image.
     Things like sockets are lower on their priority list.

     In their mind we are not even a 'programming language'.

     Phobos does need to be bigger, but not fully inclusive.
     If most people won't use something, don't add it.

     Sure there is arguments against this, but there is a certain amount
     we must standardize and agree upon as a community. Phobos most
     certainly is the place to do this. Otherwise we will be going round
     in circles for a much longer period then we should and not growing
 much.


 I'm going to quote you there: to put it bluntly you are plain wrong.

 We do not, and no one does, need a kitchen sink standard library. Look
 at python, look at Go, these are two of the fastest growing languages
 out there. They are:
 - Extremely easy to pick up and use.
 - Have excellent documentation and simple naming conventions
 - Have fantastic 3rd party open source libraries
Nope just no. I am only talking about newbies here. They will pick distributions of Python that are all encompassing. http://winpython.github.io/#overview When it comes to newbies who come into programming seeing from all of their previous experience that things like GUI toolkit just comes with the language they just don't care if it was provided "extra" by a distribution or by the language itself. Only that they did exactly 0 beyond importing and using it. During my degree, the final programming class was Python. Everyone used WinPython except me. At the time pip didn't even work in it. Yes you heard me correct. When they had to use other code, they had no way or will to even try what wasn't part of it and so in their eyes what they had downloaded was Python. Because it really does appear to be Python. Especially with the IDE and QT being part of it... And right here is the problem. They expected and there it was. You will see this in every language. From Java to PHP. The community in general misses the point here time and time again. It wasn't until recently that Adam saw how bad things were just to add some context. How does one find the "right" library for a task?
 - The community refers devs to their preferred / popular libs
 - There are excellent tutorials / how-tos that show case the library

 If we spent less time fussing of what gets into phobos and more time
 making good libraries for code.dlang.org <http://code.dlang.org> and let
 the best ones win out we'd get much better stuff much quicker.
And I agree with you. As long as we have the bare bones in Phobos such as windowing and image library we can actually fight over GUI toolkits. Instead of repeatedly doing the same code over and over poorly.
Ouch yes, seen that before. I just would prefer the base library to be exactly that a base. In fact if dub came with dmd, or if you downloaded dub and it could install dmd/gdc/ldc I would be much happier, phobos could be just another library on code.dlang.org. That why the one app to rule them all could just be dub and newbies and veterans alike could be happy that their needed libraries were just there. Something like: - download dub - double click installer - present with options to install, defaults to dmd and phobos must be installed (if not found) - other option to create blank project - opens project with a basic ide that uses dcd etc and allows compile and run with a simple example that outputs to a console and opens a window with the D logo. (Just thinking out loud) :D PS: Can you make sure its easy to do transparent shaped windows in your bare bones windowing implementation?
Jan 25
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 9:57 PM, Rory McGuire via Digitalmars-d-announce wrote:
 On Mon, Jan 25, 2016 at 10:31 AM, Rikki Cattermole via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com
 <mailto:digitalmars-d-announce puremagic.com>> wrote:

     On 25/01/16 9:21 PM, Rory McGuire via Digitalmars-d-announce wrote:


         On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
         Digitalmars-d-announce <digitalmars-d-announce puremagic.com
         <mailto:digitalmars-d-announce puremagic.com>
         <mailto:digitalmars-d-announce puremagic.com
         <mailto:digitalmars-d-announce puremagic.com>>> wrote:

              On 25/01/16 8:16 PM, tsbockman wrote:

                  On Monday, 25 January 2016 at 07:03:35 UTC, Russel
         Winder wrote:

                      The strategy should be "get rid of anything in
         Phobos that
                      can be put
                      out as a separate library".


                  This makes no sense as a standard: since neither DMD
         nor druntime is
                  allowed to depend upon Phobos, everything in Phobos
         *could* be
                  put into
                  a separate library.


              I had a long post replying to Russel and to put it bluntly,
         its just
              wrong.
              We are most definitely losing people simply because they expect
              certain code in the standard library. Like windowing and image.
              Things like sockets are lower on their priority list.

              In their mind we are not even a 'programming language'.

              Phobos does need to be bigger, but not fully inclusive.
              If most people won't use something, don't add it.

              Sure there is arguments against this, but there is a
         certain amount
              we must standardize and agree upon as a community. Phobos most
              certainly is the place to do this. Otherwise we will be
         going round
              in circles for a much longer period then we should and not
         growing much.


         I'm going to quote you there: to put it bluntly you are plain wrong.

         We do not, and no one does, need a kitchen sink standard
         library. Look
         at python, look at Go, these are two of the fastest growing
         languages
         out there. They are:
         - Extremely easy to pick up and use.
         - Have excellent documentation and simple naming conventions
         - Have fantastic 3rd party open source libraries


     Nope just no.
     I am only talking about newbies here.
     They will pick distributions of Python that are all encompassing.

     http://winpython.github.io/#overview
     When it comes to newbies who come into programming seeing from all
     of their previous experience that things like GUI toolkit just comes
     with the language they just don't care if it was provided "extra" by
     a distribution or by the language itself. Only that they did exactly
     0 beyond importing and using it.

     During my degree, the final programming class was Python.
     Everyone used WinPython except me. At the time pip didn't even work
     in it. Yes you heard me correct.

     When they had to use other code, they had no way or will to even try
     what wasn't part of it and so in their eyes what they had downloaded
     was Python. Because it really does appear to be Python.

     Especially with the IDE and QT being part of it...
     And right here is the problem. They expected and there it was.
     You will see this in every language. From Java to PHP.

     The community in general misses the point here time and time again.
     It wasn't until recently that Adam saw how bad things were just to
     add some context.

         How does one find the "right" library for a task?
         - The community refers devs to their preferred / popular libs
         - There are excellent tutorials / how-tos that show case the library

         If we spent less time fussing of what gets into phobos and more time
         making good libraries for code.dlang.org <http://code.dlang.org>
         <http://code.dlang.org> and let
         the best ones win out we'd get much better stuff much quicker.


     And I agree with you. As long as we have the bare bones in Phobos
     such as windowing and image library we can actually fight over GUI
     toolkits.
     Instead of repeatedly doing the same code over and over poorly.



 Ouch yes, seen that before. I just would prefer the base library to be
 exactly that a base. In fact if dub came with dmd, or if you downloaded
 dub and it could install dmd/gdc/ldc I would be much happier, phobos
 could be just another library on code.dlang.org <http://code.dlang.org>.
 That why the one app to rule them all could just be dub and newbies and
 veterans alike could be happy that their needed libraries were just
 there. Something like:
 - download dub
 - double click installer
 - present with options to install, defaults to dmd and phobos must be
 installed (if not found)
    - other option to create blank project
    - opens project with a basic ide that uses dcd etc and allows compile
 and run with a simple example that outputs to a console and opens a
 window with the D logo.

 (Just thinking out loud) :D
Can't argue with that as long as there is a good list of set recommend libs for doing stuff like windowing on dlang.org. But that comes back to the same problem of standardization. Really at the minimum we need Phobos broken up into dub sub packages. Preferably I'd like we to go all the way into separate repositories and let people own their own code. But I can understand why not.
 PS: Can you make sure its easy to do transparent shaped windows in your
 bare bones windowing implementation?
Transparent shaped windows? Nope. That is a very hard and difficult thing to do especially cross platform. But if people really really want it, I can add a window mode for no border + transparent I suppose. Although based upon what I'm seeing I would be surprised if at least for Windows it can't be just one free function when using VRAM context to make it happen.
Jan 25
next sibling parent reply Rory McGuire via Digitalmars-d-announce writes:
On Mon, Jan 25, 2016 at 11:05 AM, Rikki Cattermole via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:
[snip]
 Really at the minimum we need Phobos broken up into dub sub packages.
 Preferably I'd like we to go all the way into separate repositories and let
 people own their own code. But I can understand why not.
[snip] ha, I had typed a similar response: Looking at the way we have things now, it would actually be quite simple to make two downloads, one with everything and one with the bare minimum. If we changed phobos to compile like the recent vibe.d version does then we can even pick and choose sections of phobos. I suppose "he who has the vision" can do either type of release with our current tools.
Jan 25
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/25/2016 04:17 AM, Rory McGuire via Digitalmars-d-announce wrote:
 Looking at the way we have things now, it would actually be quite simple
 to make two downloads, one with everything and one with the bare minimum.

 If we changed phobos to compile like the recent vibe.d version does then
 we can even pick and choose sections of phobos. I suppose "he who has
 the vision" can do either type of release with our current tools.
What would be the benefits of this? My knee-jerk reaction is this is a large and disruptive project with no palpable benefits. -- Andrei
Jan 25
parent reply Rory McGuire via Digitalmars-d-announce writes:
On Mon, Jan 25, 2016 at 2:46 PM, Andrei Alexandrescu via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On 01/25/2016 04:17 AM, Rory McGuire via Digitalmars-d-announce wrote:

 Looking at the way we have things now, it would actually be quite simple
 to make two downloads, one with everything and one with the bare minimum.

 If we changed phobos to compile like the recent vibe.d version does then
 we can even pick and choose sections of phobos. I suppose "he who has
 the vision" can do either type of release with our current tools.
What would be the benefits of this? My knee-jerk reaction is this is a large and disruptive project with no palpable benefits. -- Andrei
Yep, thats kind of what I was saying in the end. If someone wanted to they could make such a release independently. I'm trying to hack on the compiler, personally I wish all those with the know how would put their efforts into documenting how the compiler works and what the different parts do, that way we could have more contributors.
Jan 25
parent maik klein <maikklein googlemail.com> writes:
On Monday, 25 January 2016 at 13:08:18 UTC, Rory McGuire wrote:
 On Mon, Jan 25, 2016 at 2:46 PM, Andrei Alexandrescu via 
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> 
 wrote:

 On 01/25/2016 04:17 AM, Rory McGuire via 
 Digitalmars-d-announce wrote:

 Looking at the way we have things now, it would actually be 
 quite simple to make two downloads, one with everything and 
 one with the bare minimum.

 If we changed phobos to compile like the recent vibe.d 
 version does then we can even pick and choose sections of 
 phobos. I suppose "he who has the vision" can do either type 
 of release with our current tools.
What would be the benefits of this? My knee-jerk reaction is this is a large and disruptive project with no palpable benefits. -- Andrei
Yep, thats kind of what I was saying in the end. If someone wanted to they could make such a release independently. I'm trying to hack on the compiler, personally I wish all those with the know how would put their efforts into documenting how the compiler works and what the different parts do, that way we could have more contributors.
+1 On lifetime management and tooling. I would like to see a lot of improvements for DCD also tools for refactoring would also be extremely useful. As for splitting up everything into small packages, I don't think D is there yet. I am still new but I already found several libraries that I wanted to use that not follow the "official" D Style guide. I would not want to include N different libraries that use N different coding styles. Look at Rust for example, you will find that pretty much every library uses the "official" style guide. I think that is because it is mostly "enforced" by the compiler as a warning. I really don't care how I write my code, but I care deeply about consistency. Another point is that I couldn't find any metaprogramming library for D yet. Yes there is std.meta but it is extremely lacking, this is quite obvious if you look into the std. For example in "zip" return mixin (q{ElementType(%(.moveAt(ranges[%s], n)%|, %))}.format(iota(0, R.length))); This could be easily expressed as a general metafunction. Also std.meta mostly focusses on compile time stuff but I don't think there is anything for a "Tuple". Some inspiration could be found here https://github.com/boostorg/hana
Jan 25
prev sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
I've had a bit more of a looksie into splash screens and I think I would 
prefer if it was completely separate actually.
Its not too hard, but its has semi incompatible features as to a window.
Jan 25
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote:
 Ouch yes, seen that before. I just would prefer the base 
 library to be exactly that a base.
I agree. Imagine if all the effort put into Phobos' extras was put into the compiler and tooling...
Jan 26
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 12:46:23 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 25 January 2016 at 08:57:44 UTC, Rory McGuire wrote:
 Ouch yes, seen that before. I just would prefer the base 
 library to be exactly that a base.
I agree. Imagine if all the effort put into Phobos' extras was put into the compiler and tooling...
It's not like you could just reallocate all the effort that goes into Phobos towards the compiler and stuff. Especially with the compiler itself, most people are unqualified or uninterested in working on it. If it were suddenly announced that Phobos was "finished", I guarantee a lot of volunteers would just walk away (likely including myself).
Jan 26
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 20:38:16 UTC, tsbockman wrote:
 It's not like you could just reallocate all the effort that 
 goes into Phobos towards the compiler and stuff.
My impression is that the majority of the contributors to Phobos are capable D programmers. DMD is implemented in D now, no longer C++, so with refactoring and documentation I think a lot more programmers are qualified to hack on the compiler.
Jan 26
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 20:43:29 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 20:38:16 UTC, tsbockman wrote:
 It's not like you could just reallocate all the effort that 
 goes into Phobos towards the compiler and stuff.
My impression is that the majority of the contributors to Phobos are capable D programmers. DMD is implemented in D now, no longer C++, so with refactoring and documentation I think a lot more programmers are qualified to hack on the compiler.
The language in which DMD is written has never been the main barrier to working on it. The real issue is that DMD is a huge, poorly documented code base in which most of the various components are tightly coupled to everything else. This makes it both intimidating and time consuming to get started hacking on it. In contrast, Phobos (although still very large) is fairly well documented, and has much less coupling between most of its components. Moreover, what coupling there is, is easily understood because the average (experienced) D programmer already knows his way around the standard library, from the outside. Also, you skipped past the "uninterested" part - this is a volunteer project, remember?
Jan 26
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote:
 Also, you skipped past the "uninterested" part - this is a 
 volunteer project, remember?
I didn't think it was a relevant argument as you can still write libraries for distribution. Keep in mind that the standard library has to be maintained and API's cannot easily be redesigned because of backwards compatibility. Even if C/C++ have small standard libraries they provide a depressing amount of low quality functionality that one should avoid. But it is kept in for backwards compatibility and sometimes even updated and extended... That not a good thing.
Jan 26
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 21:47:41 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 21:03:01 UTC, tsbockman wrote:
 Also, you skipped past the "uninterested" part - this is a 
 volunteer project, remember?
I didn't think it was a relevant argument as you can still write libraries for distribution. Keep in mind that the standard library has to be maintained and API's cannot easily be redesigned because of backwards compatibility. Even if C/C++ have small standard libraries they provide a depressing amount of low quality functionality that one should avoid. But it is kept in for backwards compatibility and sometimes even updated and extended... That not a good thing.
There are certainly disadvantages to the standard library model of distribution and maintenance. On the other hand: 1) The prospect of getting something into the standard library is a huge motivator for (at least some) potential contributors. Why? Because building a library that no one knows about/trusts is wasted effort. Getting something into `std` is among the most effective forms of marketing available, and requires little non-programming-related skill or effort on the part of the contributor. 2) Standard libraries don't enforce backwards compatibility (and high code quality in general) just for the sake of bureaucracy - they do so because these are highly desirable characteristics for basic infrastructure. People shouldn't have to rewrite their entire stack every 6 months just because someone thought of a better API for some low-level component. Making it through D's formal review process typically raises code quality quite a lot, and the knowledge that backwards compatibility is a high priority makes outsiders much more likely to invest in actually using a library module. In short, while you make some valid points, your analysis seems very lopsided; it completely glosses over all of the positives associated with the status quo.
Jan 26
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:
 1) The prospect of getting something into the standard library 
 is a huge motivator for (at least some) potential contributors.
I am not sure if that is the right motivation. Sounds like recipe for bloat. Good libraries evolve from being used in real applications. Many applications.
 characteristics for basic infrastructure. People shouldn't have 
 to rewrite their entire stack every 6 months just because 
 someone thought of a better API for some low-level component.
Then don't use libraries from unreliable teams.
 Making it through D's formal review process typically raises 
 code quality quite a lot, and the knowledge that backwards 
 compatibility is a high priority makes outsiders much more 
 likely to invest in actually using a library module.
Code quality is one thing, but if it has not been used in many applications, how can you then know if the abstraction is particularly useful? There is nothing wrong with having a set of recommended libraries, e.g. a DSP library with FFT. But having things like FFT in the standard library is just crap. Even Apple does not do that, they have a separate library called Accelerate for such things. There is no way you can have the same interface for FFT across platforms. The structure of the data is different, the accuracy is different, all for max performance. In general the standard library should just be the most basic things, even file system support is tricky for a system level programming language. For instance, on some cloud platforms you don't get to read/write parts of a file. You do it as one big atomic write/read.
Jan 26
next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:
 characteristics for basic infrastructure. People shouldn't 
 have to rewrite their entire stack every 6 months just because 
 someone thought of a better API for some low-level component.
Then don't use libraries from unreliable teams.
Just using the standard library whenever possible is a simple and efficient way of accomplishing this - if the standard library actually has anything in it...
 Making it through D's formal review process typically raises 
 code quality quite a lot, and the knowledge that backwards 
 compatibility is a high priority makes outsiders much more 
 likely to invest in actually using a library module.
Code quality is one thing, but if it has not been used in many applications, how can you then know if the abstraction is particularly useful?
This is why requiring modules to spend some time on DUB and/or in `std.experimental` before freezing the API is important.
 In general the standard library should just be the most basic 
 things, even file system support is tricky for a system level 
 programming language. For instance, on some cloud platforms you 
 don't get to read/write parts of a file. You do it as one big 
 atomic write/read.
Targeting 100% generality with APIs is pretty much always a bad idea. Standard libary modules should endeavor to meet the needs of at least, say, 80% of potential users; they're not supposed to completely eliminate the need for specialized third-party libraries entirely. This is OK, because if you don't use a module, the compiler won't include it in the final executable.
Jan 26
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 23:04:57 UTC, tsbockman wrote:
 This is why requiring modules to spend some time on DUB and/or 
 in `std.experimental` before freezing the API is important.
Well, there aren't enough D applications written to ensure the usefulness of the API. Just take a look at widely adopted frameworks, they are "the one true thing" for a few years with 100s or 1000s of applications using them. However as applications grow problems emerge. What happens? The entire framework is scrapped and replaced with something else.
 Targeting 100% generality with APIs is pretty much always a bad 
 idea.
Making a system level programming library based on what a current PC operating systems offers is also a bad idea. On Apple systems you are supposed to no longer use paths, but switch to URLs for files. Ok, you can do that by requiring URLs on all platforms, but what if you designed the API 10 years ago? Operating systems changes, hardware changes. System level programming languages shouldn't provide an abstract machine, unlike the JVM. I'm not at all convinced that D isn't tied too heavily to x86/POSIX/Windows. It isn't obvious that future systems will bother with POSIX.
Jan 26
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
Or let me put it this way. If the standard library requires 
POSIX, then it isn't really a standard library, but a POSIX 
abstraction library...
Jan 26
prev sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 26 January 2016 at 22:33:32 UTC, tsbockman wrote:
 1) The prospect of getting something into the standard library 
 is a huge motivator for (at least some) potential contributors.
I am not sure if that is the right motivation. Sounds like recipe for bloat. Good libraries evolve from being used in real applications. Many applications.
sayeth a low-level guy (if I understand correctly), which will certainly create a distinct perspective about what you would like to see in the standard library, and yet this may not be the right thing for the language as a whole. fwiw, people that do use D on a serious scale have remarked that the richness of the standard library (even as it stands today) was a major advantage - in bioinformatics, at a London hedge fund, and I think AdRoll.
Jan 26
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc 
wrote:
 On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim 
 Grøstad wrote:
 I am not sure if that is the right motivation. Sounds like 
 recipe for bloat. Good libraries evolve from being used in 
 real applications. Many applications.
sayeth a low-level guy (if I understand correctly), which will certainly create a distinct perspective about what you would like to see in the standard library, and yet this may not be the right thing for the language as a whole.
I am both low-level and high level, but D's primary advantage is that it allows low level programming.
 fwiw, people that do use D on a serious scale have remarked 
 that the richness of the standard library (even as it stands 
 today) was a major advantage - in bioinformatics, at a London 
 hedge fund, and I think AdRoll.
Do you consider Angular to be low level? It was used in 100s if not 1000s of applications, but was considered inadequate and scrapped in favour of Angular2. This is the typical pattern for libraries and frameworks.
Jan 27
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 27 January 2016 at 09:15:27 UTC, Ola Fosheim 
Grøstad wrote:
 On Wednesday, 27 January 2016 at 06:17:44 UTC, Laeeth Isharc 
 wrote:
 On Tuesday, 26 January 2016 at 22:48:23 UTC, Ola Fosheim 
 Grøstad wrote:
 I am not sure if that is the right motivation. Sounds like 
 recipe for bloat. Good libraries evolve from being used in 
 real applications. Many applications.
sayeth a low-level guy (if I understand correctly), which will certainly create a distinct perspective about what you would like to see in the standard library, and yet this may not be the right thing for the language as a whole.
I am both low-level and high level, but D's primary advantage is that it allows low level programming.
Surely, that is C's primary advantage! The whole point of D is that it doesn't just have one primary advantage, and that is why the front page no longer describes it is as a systems language, even though it's approaching suitable as such.
 fwiw, people that do use D on a serious scale have remarked 
 that the richness of the standard library (even as it stands 
 today) was a major advantage - in bioinformatics, at a London 
 hedge fund, and I think AdRoll.
Do you consider Angular to be low level? It was used in 100s if not 1000s of applications, but was considered inadequate and scrapped in favour of Angular2. This is the typical pattern for libraries and frameworks.
I really don't see how this relates to the point at hand. You seemed to suggest that the standard library should be small, and I pointed out that many serious users in industries that are likely to be key markets for D do say that they find what's provided in the standard library to be quite appealing. Nothing lasts forever, and all is change - that's something I agree with. But it doesn't seem to have much bearing on the decision about what to put in the standard library. Your suggestions that because some cloud environments don't have a conventional file system, D perhaps shouldn't even have this in the standard library really seemed to me to be a reductio ad absurdum of your own argument. Of course there will be lots there that one doesn't need and can't use. But over time things that were once cutting edge become bog standard, and it makes sense to have coherence and convenience rather than to have to search out the best library for the purpose each time.
Jan 27
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 16:52:53 UTC, Laeeth Isharc 
wrote:
 your own argument.  Of course there will be lots there that one 
 doesn't need and can't use.  But over time things that were 
 once cutting edge become bog standard, and it makes sense to 
 have coherence and convenience rather than to have to search 
 out the best library for the purpose each time.
I agree about coherence being desirable, but evolution tends to lead to the opposite. Just look at C++ streams vs iterators vs ranges vs ... Coherence is a good reason to have independent libraries that are replaced as a whole. The standard library should primarily cover stable types you need to describe APIs. Then you can have other recommended independent libraries with no mutual dependencies.
Jan 27
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Monday, 25 January 2016 at 08:31:13 UTC, Rikki Cattermole 
wrote:
 Nope just no.
 I am only talking about newbies here.
 They will pick distributions of Python that are all 
 encompassing.

 http://winpython.github.io/#overview
 When it comes to newbies who come into programming seeing from 
 all of their previous experience that things like GUI toolkit 
 just comes with the language they just don't care if it was 
 provided "extra" by a distribution or by the language itself. 
 Only that they did exactly 0 beyond importing and using it.
I'm sympathetic to this. I still just download Anaconda and not bother with much else.
Jan 25
next sibling parent Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-01-25 at 15:47 +0000, jmh530 via Digitalmars-d-announce
wrote:
=20
[=E2=80=A6]
=20
 I'm sympathetic to this. I still just download Anaconda and not=C2=A0
 bother with much else.
But that is the whole point I am trying to make. Anaconda (or Miniconda) is not a single massive monolithic library, it is a package management system for a Python milieu. You have a single command conda that allows you to get the bits you want. It is just pip on steroids, but with proper curation. Sadly they are still on Qt4, but=E2=80=A6 The analogy to Miniconda in Python is Dub in D. The analogy to Anaconda in Python is downloading the whole of the Dub repository before doing anything. Actually Dub is more like Pip. Continuum Analytics put a lot of effort into managing their separate repository. Very little crap, lots of good stuff. But focused on data science. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 25
prev sibling parent Rory McGuire via Digitalmars-d-announce writes:
On 25 Jan 2016 7:16 PM, "Russel Winder via Digitalmars-d-announce" <
digitalmars-d-announce puremagic.com> wrote:
 On Mon, 2016-01-25 at 15:47 +0000, jmh530 via Digitalmars-d-announce
 wrote:

 [=E2=80=A6]
 I'm sympathetic to this. I still just download Anaconda and not
 bother with much else.
But that is the whole point I am trying to make. Anaconda (or Miniconda) is not a single massive monolithic library, it is a package management system for a Python milieu. You have a single command conda that allows you to get the bits you want. It is just pip on steroids, but with proper curation. Sadly they are still on Qt4, but=E2=80=A6 The analogy to Miniconda in Python is Dub in D. The analogy to Anaconda in Python is downloading the whole of the Dub repository before doing anything. Actually Dub is more like Pip. Continuum Analytics put a lot of effort into managing their separate repository. Very little crap, lots of good stuff. But focused on data science. -- Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
 Dr Russel Winder      t: +44 20 7585 2200   voip:
sip:russel.winder ekiga.net
 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
 London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Reading the whole thread here it seems we're all pretty much in agreement about lightweight phobos + dub on steroids. - phobos should be the common glue allowing interoperability between various libraries and apps. - druntime should be OS abstraction? - dub should be first or second thing you download when using D (depends if it can install d itself) Perhaps: 'dub install dmd' installs dmd 'dub install ldc|gdc' ... 'dub init +gui ' could init a gui app with recommended dependencies. 'dub init +web' for Web dev. Etc... ?
Jan 25
prev sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-01-25 at 21:31 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:
=20
[=E2=80=A6]
 Nope just no.
 I am only talking about newbies here.
 They will pick distributions of Python that are all encompassing.
=20
 http://winpython.github.io/#overview
 When it comes to newbies who come into programming seeing from all
 of=C2=A0
 their previous experience that things like GUI toolkit just comes
 with=C2=A0
 the language they just don't care if it was provided "extra" by a=C2=A0
 distribution or by the language itself. Only that they did exactly 0=C2=
=A0
 beyond importing and using it.
I'm afraid this whole view on the Python world is an old and long gone one. Even on Windows. Trust me on this I have been training people in Python since 2006. I have seen the whole scene change. Dramatically. Oh and by the way, noone actually uses the one graphics system that comes as standard in Python. Everyone uses PyQt, wxPython, Phoenix, Gtk, direct bindings to other graphics libraries. Pip is now core to everyone, even beginners use of Python. PyPI =C2=A0may still have elements of crapness about it, but it is there, it is used, from Day 1 by most people learning Python.=C2=A0
 During my degree, the final programming class was Python.
 Everyone used WinPython except me. At the time pip didn't even work
 in=C2=A0
 it. Yes you heard me correct.
True, but how long ago was that? Python distributes pip in the Windows and OSX distributions. Package-based platforms tend to package it themselves. In fact all the commands are just entries into the library. Analogy: Dub is part of Phobos. If tehre is anything to add to Phobos it has to be Dub.=C2=A0
 When they had to use other code, they had no way or will to even try=C2=
=A0
 what wasn't part of it and so in their eyes what they had downloaded
 was=C2=A0
 Python. Because it really does appear to be Python.
Very true until four or five years ago. Now the whole situation is changed. Yes people go first to the standard library, but now people know to look in PyPI before writing their own.
 Especially with the IDE and QT being part of it...
 And right here is the problem. They expected and there it was.
 You will see this in every language. From Java to PHP.
Qt never has been and never will be a part of the Python standard library. Ah you agree with me: The Java folk have a huge library, some if which is good, much of which is dross. But the real treasure of the Java Platform is Bintray and Maven Central. How can anyone contemplate doing Web stuff without Spring Hibernate, JavaEE, all of which are separate libraries not in teh distribution.=C2=A0
 [=E2=80=A6]
=20
 And I agree with you. As long as we have the bare bones in Phobos
 such=C2=A0
 as windowing and image library we can actually fight over GUI
 toolkits.
 Instead of repeatedly doing the same code over and over poorly.
I am afraid this is just displacement reasoning. The problem with graphics and D (other than GtkD, which is a very smooth operation) is that too many people have too many different ideas and assume everyone else will insist on doing their own thing. The problem is not Phobos here, the problem is the people not wanting to collaborate to create one or two things. Oh, that and resources. Whilst there is no money swashing around the D community (compare the Java, C++, Rust, Go, Python ones), there is little or no expectation of change. Given that all activity is volunteer activity, then what is happening will not change. And neither should it be forced to. On the other hand if a consensus could happen=E2=80=A6 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 25
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 26/01/16 6:07 AM, Russel Winder via Digitalmars-d-announce wrote:
 On Mon, 2016-01-25 at 21:31 +1300, Rikki Cattermole via Digitalmars-d-
 announce wrote:

 […]
 Nope just no.
 I am only talking about newbies here.
 They will pick distributions of Python that are all encompassing.

 http://winpython.github.io/#overview
 When it comes to newbies who come into programming seeing from all
 of
 their previous experience that things like GUI toolkit just comes
 with
 the language they just don't care if it was provided "extra" by a
 distribution or by the language itself. Only that they did exactly 0
 beyond importing and using it.
I'm afraid this whole view on the Python world is an old and long gone one. Even on Windows. Trust me on this I have been training people in Python since 2006. I have seen the whole scene change. Dramatically. Oh and by the way, noone actually uses the one graphics system that comes as standard in Python. Everyone uses PyQt, wxPython, Phoenix, Gtk, direct bindings to other graphics libraries. Pip is now core to everyone, even beginners use of Python. PyPI may still have elements of crapness about it, but it is there, it is used, from Day 1 by most people learning Python.
Well whoever these people are, they are most certainly not the people I've seen. They wouldn't care or even want to look at PyPI.
 During my degree, the final programming class was Python.
 Everyone used WinPython except me. At the time pip didn't even work
 in
 it. Yes you heard me correct.
True, but how long ago was that? Python distributes pip in the Windows and OSX distributions. Package-based platforms tend to package it themselves. In fact all the commands are just entries into the library. Analogy: Dub is part of Phobos. If tehre is anything to add to Phobos it has to be Dub.
2 years ago, but I can guarantee for students that go through that course and tutors, it won't be changing anytime soon.
 When they had to use other code, they had no way or will to even try
 what wasn't part of it and so in their eyes what they had downloaded
 was
 Python. Because it really does appear to be Python.
Very true until four or five years ago. Now the whole situation is changed. Yes people go first to the standard library, but now people know to look in PyPI before writing their own.
 Especially with the IDE and QT being part of it...
 And right here is the problem. They expected and there it was.
 You will see this in every language. From Java to PHP.
Qt never has been and never will be a part of the Python standard library. Ah you agree with me: The Java folk have a huge library, some if which is good, much of which is dross. But the real treasure of the Java Platform is Bintray and Maven Central. How can anyone contemplate doing Web stuff without Spring Hibernate, JavaEE, all of which are separate libraries not in teh distribution.
 […]

 And I agree with you. As long as we have the bare bones in Phobos
 such
 as windowing and image library we can actually fight over GUI
 toolkits.
 Instead of repeatedly doing the same code over and over poorly.
I am afraid this is just displacement reasoning. The problem with graphics and D (other than GtkD, which is a very smooth operation) is that too many people have too many different ideas and assume everyone else will insist on doing their own thing. The problem is not Phobos here, the problem is the people not wanting to collaborate to create one or two things. Oh, that and resources. Whilst there is no money swashing around the D community (compare the Java, C++, Rust, Go, Python ones), there is little or no expectation of change. Given that all activity is volunteer activity, then what is happening will not change. And neither should it be forced to. On the other hand if a consensus could happen…
You're 100% right that it is the people problem here. But right now, Phobos is the only way I can emphasize reuse of the core bare-bones libraries.
Jan 25
parent reply Russel Winder via Digitalmars-d-announce writes:
On Tue, 2016-01-26 at 17:06 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:
 [=E2=80=A6]
=20
 Well whoever these people are, they are most certainly not the
 people=C2=A0
 I've seen. They wouldn't care or even want to look at PyPI.
The people you have seen are clearly not Pythonistas. This may be by dint of their teachers/lecturer/tutors/mentors not actually understanding Python and its culture. [=E2=80=A6]
=20
 2 years ago, but I can guarantee for students that go through that=C2=A0
 course and tutors, it won't be changing anytime soon.
OK, in which case I infer the teachers/lecturers/tutors/mentors really do not understand Python, and should learn more themselves as a matter of urgency and professionalism. =C2=A0 [=E2=80=A6]
=20
 You're 100% right that it is the people problem here.
 But right now, Phobos is the only way I can emphasize reuse of the
 core=C2=A0
 bare-bones libraries.
I disagree (hence my comment about displacement). I think we should fix the Dub issues and the relationship between Dub, GDC, LDC, DMD, druntime and Phobos. To use Phobos as a "hack" to solve the problem in the short term will be a disservice to D in the medium to long term. =C2=A0 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 25
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
I wasn't going to reply, until you tweeted.
No just no.

When dealing with tertiary institutions especially New Zealand ones, 
you've got to understand they have massive pressure to get through 
content. Every single class is standardized nationally, by law.

You're all worried about doing things best practice in an eco-system.
That is just not the case here. In these courses they are not meant to 
be teaching a language. But instead use said language to teach with.

The most time a student gets in ANY language is 2 semesters. By the time 
they reach third year (last) they only have 1 per language.
In these classes the concern is teaching some other relevant concept 
such as design patterns.

So you're pushing limited class time for the purpose of teaching actual 
class content instead of non required information for assignments.
Its a balancing act.

But you've got to understand that most of the students going through it, 
are just not interested in going much further then the assignments.
Simple things like trying OpenGL are beyond them and this is ok. They 
have a lot of things to learn and have real life requirements outside of 
study.

The average person learning to program is not spending half the time 
most D developers do on a slow week. Again this is ok. But we need to 
acknowledge that they won't be anywhere near us or our expectations 
normally.

To assume the average person will play around and learn pip ext. is just 
ridiculous. Especially when they have most if not all the code they need 
already available to them via the distribution.

These are the same people who we may barely convince to try D out. If 
they struggle to do basic things or at least perceived basic things then 
they won't bother and just say 'too hard'.
If we can make them happy, most developers over all will be happy. Even 
the average D developer will be glad for it.

At the end of the day, the least amount of steps to do what is perceived 
as basic tasks without any conflicting arguments the better.

I keep saying about perceived basic tasks. Psychology. A fourteen year 
old today was born in 2002. I learned to program when I was 14. In 2001 
XP was just released. The people learning programming now expect GUI's 
and perceive it as basic. We may know better but at the end of the day, 
how can we appeal to them realistically?
Jan 26
parent reply Russel Winder via Digitalmars-d-announce writes:
Some of this apparently off-topic, but I will get back on-topic by the
end.

On Tue, 2016-01-26 at 21:17 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:
 I wasn't going to reply, until you tweeted.
Sorry for wrongly assigning geography.
 No just no.
Yes, oh yes, oh yes.=C2=A0
 When dealing with tertiary institutions especially New Zealand ones,=C2=
=A0
 you've got to understand they have massive pressure to get through=C2=A0
 content. Every single class is standardized nationally, by law.
Sounds like the NZ system is not as good a tertiary education system as it should be. Having guidelines for curriculum and examination is fine, but to stadardize at the class level is definitely too low. =C2=A0UK universities went through this debate in the 1980 and managed to escape from legal enforcement.
 You're all worried about doing things best practice in an eco-system.
 That is just not the case here. In these courses they are not meant
 to=C2=A0
 be teaching a language. But instead use said language to teach with.
There should also be classes in applications construction. Clearly classes on specification, compilers, etc. the language is tool only and workflow and best practice of programming are irrelevant.
 The most time a student gets in ANY language is 2 semesters. By the
 time=C2=A0
 they reach third year (last) they only have 1 per language.
 In these classes the concern is teaching some other relevant concept=C2=
=A0
 such as design patterns.
Design patterns are not language agnostic. GoF patterns are 23 year old and many totally irrelevant with certain programming languages. However that is a different debate for a different place.
 So you're pushing limited class time for the purpose of teaching
 actual=C2=A0
 class content instead of non required information for assignments.
 Its a balancing act.
It sounds like the law makers are getting it wrong then. If there is no time for teaching programming best practice then graduates from the programme are not ready for employment without first doing an apprenticeship of some sort.
 But you've got to understand that most of the students going through
 it,=C2=A0
 are just not interested in going much further then the assignments.
 Simple things like trying OpenGL are beyond them and this is ok.
 They=C2=A0
 have a lot of things to learn and have real life requirements outside
 of=C2=A0
 study.
=46rom my time in academia (20 years) I can pretty much agree that most computing students didn't actually give a shit about computing. Certainly 40% of them couldn't program. But because of the curriculum they get degrees, get jobs as programmers and we end up with the mass of crap code we currently have in the world.=C2=A0
 The average person learning to program is not spending half the time=C2=
=A0
 most D developers do on a slow week. Again this is ok. But we need
 to=C2=A0
 acknowledge that they won't be anywhere near us or our expectations=C2=A0
 normally.
Which gets on to a huge hobby horse of mine. If degrees are about knowledge then there has to be a follow on before people are employed. Medics do this: three year degree, two or three years on the job training. Effectively an apprenticeship. Sadly in computing, most employers assume graduates have the knowledge and the work practice skills. Clearly they do not. It seems NZ is enshrining this in law. UK it is jsut what happens. Of course most university computing academic staff cannot program either.
 To assume the average person will play around and learn pip ext. is
 just=C2=A0
 ridiculous. Especially when they have most if not all the code they
 need=C2=A0
 already available to them via the distribution.
Ridiculous is the wrong word to use here. All Python programmers should know about pip and PyPI. You are talking about students using Python to code up answers to exercises. If the academic ensures there is no need of anything other than the standard distribution, then that is a fine compromise, in that situation. But a person off that course should never claim they can program in Python, nor should tehy be considered for Python programming jobs without further training.=C2=A0
 These are the same people who we may barely convince to try D out.
 If=C2=A0
 they struggle to do basic things or at least perceived basic things
 then=C2=A0
 they won't bother and just say 'too hard'.
 If we can make them happy, most developers over all will be happy.
 Even=C2=A0
 the average D developer will be glad for it.
Mostly because they cannot be arsed. Academic's have a responsibility here to configure things for the students. We did this with C++, Scheme, Miranda, Java, etc. Part of the initial pack for each course were detailed tested instructions for students to set up. They didn't have to think, they just had to follow the recipe.
 At the end of the day, the least amount of steps to do what is
 perceived=C2=A0
 as basic tasks without any conflicting arguments the better.
True. 1. Download Dub. 2. Dub install standard-distribution should do it.
 I keep saying about perceived basic tasks. Psychology. A fourteen
 year=C2=A0
 old today was born in 2002. I learned to program when I was 14. In
 2001=C2=A0
 XP was just released. The people learning programming now expect
 GUI's=C2=A0
 and perceive it as basic. We may know better but at the end of the
 day,=C2=A0
 how can we appeal to them realistically?
In the university context most of the problems you are pointing out land squarely at teh feet of the academic, and law makers, not the students. Students are clearly input and output being treated as cannon fodder, not as individuals wishing to learn things. But to get back on topic. Yes modern development is about IDEs. VIM and Emacs do not count even though a lot of programmers use them. IntelliJ IDEA (CLion, PyCharm,=E2=80= =A6), NetBeans, Visual Studio, Xcode, even Eclipse, are what people mean by IDEs. In various Scala, Java, Python, Clojure, workshops I have forced people to use IDEs who would otherwise have used VIM or Emacs.It is amazing how much further people get in learning a language and how to use it with all the extras over and above editing that a good IDE provides. As a confirmed believer in "Emacs is the One True Editor, VIM is a scouring agent" I have been converted to good IDEs =E2=80=93 bad IDEs get m= e back to Emacs very quickly. So we need a really good, preferably lightweight, but=E2=80=A6 IDEs that re= ally make programming, D in this context, easier and fun. The IDE should be editor, manual, guide, mentor. The single incident that really brought this home to me was at a DevoxxUK workshop a couple of years ago, people new to Java were coding up full on good quality RxJava applications in two hours. Without the IntelliJ IDEA environment, they would have been nowhere. So as well as DDT in Eclipse, there should be solid support for Kingsley and the IntelliJ IDEA D plugin. If we get more people using D, we will have more people willing to contribute to D development, in terms of packages on Dub and otherwise. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 26
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 10:52:17 UTC, Russel Winder wrote:
 Design patterns are not language agnostic. GoF patterns are 23 
 year old and many totally irrelevant with certain programming 
 languages. However that is a different debate for a different 
 place.
I found GoF underwhelming when I first read it as I had discovered many/most of those patterns on my own, but then someone said that the usefulness was in giving the pattern names. And that made sense.
Jan 26
prev sibling parent reply Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-01-25 at 20:34 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:
=20
[=E2=80=A6]
 I had a long post replying to Russel and to put it bluntly, its just
 wrong.
 We are most definitely losing people simply because they expect
 certain=C2=A0
 code in the standard library. Like windowing and image.
 Things like sockets are lower on their priority list.
It sounds like we will just have to disagree. Either than or agree that you are wrong. ;-) Most languages benefit from libraries that wrap and abstract OS APIs, everything else can be handled by libraries (many of them) as long as there is a single central resource that enables people to find and trivially use. This message comes from Rust, Ceylon, other JDK languages, and Python. Go is weird. The counter example is C++. D just needs to get it's Dub act together properly.=C2=A0
 In their mind we are not even a 'programming language'.
Actually I think the core problem is that there is fashion and hype around D. By simple observation Go and Rust got huge impetus via hype. This led to a huge amount of activity most of which died a death, but left a huge acceleration of real traction. Whilst usage figures are dwarfed by Java, C, C++, and Python, Go and Rust have huge distributed activity bases. By sheer volume of activity some good stuff appears. Especially the stuff that gets funded, because some company is taking a punt.=C2=A0 Consider the one obvious case of Cloudflare. Originally a PHP company, Go was introduced by guerilla processes, and now Go is central to their operation. Such they they fund meetings and conferences. There are many other companies using Go who put money into meetings, conferences, general marketing, etc. because they want the best programmers. I suspect the same will happen with Rust in a couple of years. It is already the case with Python. This is the core of the issue with D for me: there isn't enough corporate activity and will to put money into the D milieu.
 Phobos does need to be bigger, but not fully inclusive.
 If most people won't use something, don't add it.
Wouldn't it be better to be explicit about what has to be in Phobos and what can be separate? Let me start a list: Data structures that are not in the language. Phobos more or less has most of the core ones. The job here is to define an architecture, which is has in ranges. OS APIs. The point here is to abstract away from Windows, OSX, Linux, UNIX,=E2=80=A6 I am not sure Linux DVB API should be in here, it is more threads, input/output, networking, memory management. Phobos host most stuff here already doesn't it? Signals and slots systems so as to be able to write asynchronous systems. Concurrency and Parallelism libraries. Not a lot else.
 Sure there is arguments against this, but there is a certain amount
 we=C2=A0
 must standardize and agree upon as a community. Phobos most certainly
 is=C2=A0
 the place to do this. Otherwise we will be going round in circles for
 a=C2=A0
 much longer period then we should and not growing much.
What needs to be standardized? Data structure architecture. Already in Phobos. Cross platform Input/Output. Already in Phobos. Why isn't Dub the way forward on this? Why a centralized massive library that is hard to change and evolve, why not a far more lightweight management of contributions via a centralized mechanism, i.e. Dub. In so many ways vibe.d shows what can be right about D, and graphics all that is wrong. Of course in the end D just does not have the corporate backing that Go, Rust, Python, Java, etc. are getting. Until that happens plus =C3=A7a change,=C2=A0plus c'est la m=C3=AAme chose. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 25
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 26/01/16 5:49 AM, Russel Winder via Digitalmars-d-announce wrote:
 On Mon, 2016-01-25 at 20:34 +1300, Rikki Cattermole via Digitalmars-d-
 announce wrote:

 […]
 I had a long post replying to Russel and to put it bluntly, its just
 wrong.
 We are most definitely losing people simply because they expect
 certain
 code in the standard library. Like windowing and image.
 Things like sockets are lower on their priority list.
It sounds like we will just have to disagree. Either than or agree that you are wrong. ;-) Most languages benefit from libraries that wrap and abstract OS APIs, everything else can be handled by libraries (many of them) as long as there is a single central resource that enables people to find and trivially use. This message comes from Rust, Ceylon, other JDK languages, and Python. Go is weird. The counter example is C++. D just needs to get it's Dub act together properly.
 In their mind we are not even a 'programming language'.
Actually I think the core problem is that there is fashion and hype around D. By simple observation Go and Rust got huge impetus via hype. This led to a huge amount of activity most of which died a death, but left a huge acceleration of real traction. Whilst usage figures are dwarfed by Java, C, C++, and Python, Go and Rust have huge distributed activity bases. By sheer volume of activity some good stuff appears. Especially the stuff that gets funded, because some company is taking a punt. Consider the one obvious case of Cloudflare. Originally a PHP company, Go was introduced by guerilla processes, and now Go is central to their operation. Such they they fund meetings and conferences. There are many other companies using Go who put money into meetings, conferences, general marketing, etc. because they want the best programmers. I suspect the same will happen with Rust in a couple of years. It is already the case with Python. This is the core of the issue with D for me: there isn't enough corporate activity and will to put money into the D milieu.
 Phobos does need to be bigger, but not fully inclusive.
 If most people won't use something, don't add it.
Wouldn't it be better to be explicit about what has to be in Phobos and what can be separate? Let me start a list: Data structures that are not in the language. Phobos more or less has most of the core ones. The job here is to define an architecture, which is has in ranges. OS APIs. The point here is to abstract away from Windows, OSX, Linux, UNIX,… I am not sure Linux DVB API should be in here, it is more threads, input/output, networking, memory management. Phobos host most stuff here already doesn't it?
So windowing, image library and audio handling. They are core to any modern OS. It wasn't until very recently that Windows Server ripped out all of the GUI aspects of its sdk for core edition.
 Signals and slots systems so as to be able to write asynchronous
 systems.

 Concurrency and Parallelism libraries.

 Not a lot else.

 Sure there is arguments against this, but there is a certain amount
 we
 must standardize and agree upon as a community. Phobos most certainly
 is
 the place to do this. Otherwise we will be going round in circles for
 a
 much longer period then we should and not growing much.
What needs to be standardized? Data structure architecture. Already in Phobos. Cross platform Input/Output. Already in Phobos. Why isn't Dub the way forward on this? Why a centralized massive library that is hard to change and evolve, why not a far more lightweight management of contributions via a centralized mechanism, i.e. Dub. In so many ways vibe.d shows what can be right about D, and graphics all that is wrong. Of course in the end D just does not have the corporate backing that Go, Rust, Python, Java, etc. are getting. Until that happens plus ça change, plus c'est la même chose.
Jan 25
prev sibling parent Dicebot <public dicebot.lv> writes:
On Monday, 25 January 2016 at 16:49:36 UTC, Russel Winder wrote:
 What needs to be standardized? Data structure architecture. 
 Already in Phobos. Cross platform Input/Output. Already in 
 Phobos.
On Monday, 25 January 2016 at 16:49:36 UTC, Russel Winder wrote:
 Why isn't Dub the way forward on this? Why a centralized 
 massive library that is hard to change and evolve, why not a 
 far more lightweight management of contributions via a 
 centralized mechanism, i.e. Dub.
I completely agree with Russel here. Kitchen-sink standard libraries are becoming legacy of old days and luxury of enterprise languages. It is the concept rather harmful to decentralized development nature of modern languages and very limited in flexibility. With a largely uncontrolled contribution flow D simply can't afford such approach. There is quite a lot of missing in how dub works, how registry is organized and how it is featured from the dlang.org - in other words, in highlighting and endorsing valuable community projects. But that has nothing to do with Phobos. Most important thing Phobos can do is to standardizes API's of various widespread concepts so that different independent libraries can work together cleanly. Good example would be std.experimental.logger - it doesn't provide much of "smart" logging functionality (like syslog or cyclic buffer) but allows to build one on top of Phobos bits in a way that you can be sure that any 2 loggers fetched from dub will be compatible with each other. This is the main deal.
Jan 25
prev sibling next sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2016-01-25 07:03:35 +0000, Russel Winder via Digitalmars-d-announce said:

 Phobos the library needs to go to be replaced by a library search and
 use system. Oh we already have one, Dub.
 
 The strategy should be "get rid of anything in Phobos that can be put
 out as a separate library".
I see it exactly the other way: I want phobos to provide 90% of everything I need out-of-the-box. The linker will only bring in stuff I use and the rest is left out. So, what's the problem? I just don't want to walk around until I find out, which parts (external libs) fit together just to cover the common 90%. That's wasting time. Make it as simple as possible to get things done. Install, code, compile, deliver. That's it. One EXE, done. -- Robert M. Mnch http://www.saphirion.com smarter | better | faster
Jan 25
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/25/2016 02:03 AM, Russel Winder via Digitalmars-d-announce wrote:
 If the Python, Rust, Go, etc. stories tell us anything, it is that the
 days of "batteries included" distributions is long, long dead. DVCS
 changes the game.
Could you please back up that assertion a little bit? From all I see, standard libraries of most languages grow very fast with each release. What are your facts? -- Andrei
Jan 25
parent reply Russel Winder via Digitalmars-d-announce writes:
On Mon, 2016-01-25 at 07:44 -0500, Andrei Alexandrescu via Digitalmars-
d-announce wrote:

 Could you please back up that assertion a little bit? From all I
 see,=C2=A0
 standard libraries of most languages grow very fast with each
 release.=C2=A0
 What are your facts? -- Andrei
Go has a very small core, if you want anything else you write a library and publish it. There is a massive and vibrant activity writing many versions of stuff most of which wither by lack of use. Some, usually one or two, in each domain thrive and become the de facto standard. Everything depends on Git, Mercurial, Bazaar, and go get. Rust threw out large tracts of what was in the original library, including all concurrency and parallelism things, in favour of separate crates. There is a massive and vibrant activity writing many versions of stuff most of which wither by lack of use. Some, usually one or two, in each domain thrive and become the de facto standard. Everything depends on crates.io and Cargo. Python used to be batteries included, then they moved to having a core to which only Python committers have access. =C2=A0There is a massive and vibrant activity writing many versions of stuff most of which wither by lack of use. Some, usually one or two, in each domain thrive and become the de facto standard. Everything depends on PyPI, pip, and virtualenv. Or Anaconda. There are many facts out there favouring distributed over centralized for everything except the language itself and the runtime system, you just have to look. Calling for an explicit, detailed catalogue is not a way forward in this debate. Consider Java Platform, the system where lots gets deprecated and nothing is removed. Ever. The library is big, and grows, but with JDK9 it will, finally be split up into modules, most of which will be ignored since they are from the mid-1990s. There is a massive and vibrant activity writing many versions of stuff most of which wither by lack of use. Some, usually one or two, in each domain thrive and become the de facto standard. Everything depends on Gradle or Maven, and Bintray and Maven Central. Distributed means duplicated effort, yes. It means many projects die. Some will gain a following that leads to traction. Centralized systems lead to stagnation and lack of contribution from all but the inner circle, which often means a lack of energy and new idea (but sometimes not). The energy in the Go, Rust, Python, and indeed JVM-based communities creating new libraries throwing them away, contributing a bit to the core library, but generally leaving it to the core team, is actually something missing from D except for the energy around vibe.d. Just looking at the threads about DMD, druntime, Phobos, it is almost all about angst rather than genuine progress. The whole "graphics library" thing is an interesting case in point. Lots of individual projects, very little consensus, no contribution in the main playing fields of Windows, OSX, Wx, and Qt. I've got GtkD for all my needs, so I don't actually care much, but as we see others care about a cross platform GUI system, but it just isn't happening. There is point at which small one person projects have to be pushed together by management and made to work. Either than or one gets funded because some organization does that. cf. PyQt, JavaFX, Qt.=C2=A0 Even if you do not rate this as facts it all is. The moral of the story is, for me, very simple: Dub needs to be front and centre, it represents D, not DMD, LDC, GDC, druntime, Phobos. The core of a D distribution is Dub. In this D is like Rust, Ceylon, Python, and JVM. And unlike Go. Go is too libertarian in my view. Rust, Ceylon, Python, JVM have the right view for me: centralized repository and management of distributed projects. What Rust and Ceylon are missing that PyPI has is an highly opinionated metric that helps you decide what is good and what is dross. Of course Dub needs a better story around executables rather than library packages. Go (go install) and Rust (Cargo build) do this so much better. But then Go has a project structure model, and Rust uses TOML. =C2=A0 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 25
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/25/2016 11:26 AM, Russel Winder via Digitalmars-d-announce wrote:
 On Mon, 2016-01-25 at 07:44 -0500, Andrei Alexandrescu via Digitalmars-
 d-announce wrote:

 Could you please back up that assertion a little bit? From all I
 see,
 standard libraries of most languages grow very fast with each
 release.
 What are your facts? -- Andrei
Thanks for answering. I want to be convinced, and even if not, to gather a more precise view. The rhetoric is appreciated. What would be helpful here in addition to it are a few links to evidence. You make lofty claims either of status quo in different languages, or major shifts in strategy. They definitely must have left a trail on the Internet. Any chance you'd substantiate these specific claims below with evidence?
 Go has a very small core, if you want anything else you write a library
 and publish it. There is a massive and vibrant activity writing many
 versions of stuff most of which wither by lack of use. Some, usually
 one or two, in each domain thrive and become the de facto standard.
 Everything depends on Git, Mercurial, Bazaar, and go get.
I look at https://golang.org/pkg/ and see a quite substantial standard library, including things that some people argue shouldn't be part of a standard library: archives and compression, cryptography, databases, character encodings (including json and xml!), html templating, image processing, suffix arrays (sic), logging, networking, regexp, testing, tokenization. This list is _after_ I eliminated topics that I believe should be part of a standard library, such as I/O, time, and even unicode, etc. I'd like to believe our stdlib covers a few areas that Go's doesn't, but it is obvious to me Go's stdlib does (and reportedly very well) cover a bunch of areas that we haven't set foot in yet. This doesn't quite align quite at all with your view that Go is barebones and anyone who wants anything builds it. From what I can tell, Go comes with plenty. (It is of course relative; Go's stdlib may be small compared to externally available libraries, owing to its popularity which the Go team deserves due credit for.)
 Rust threw out large tracts of what was in the original library,
 including all concurrency and parallelism things, in favour of separate
 crates. There is a massive and vibrant activity writing many versions
 of stuff most of which wither by lack of use. Some, usually one or two,
 in each domain thrive and become the de facto standard. Everything
 depends on crates.io and Cargo.
Do you have reference to relevant material (core team blog posts, forum discussions, articles) documenting the shift, boundaries, strategy, motivation etc? A look at https://doc.rust-lang.org/std/ does support your view that Rust's stdlib is minimal.
 Python used to be batteries included, then they moved to having a core
 to which only Python committers have access.  There is a massive and
 vibrant activity writing many versions of stuff most of which wither by
 lack of use. Some, usually one or two, in each domain thrive and become
 the de facto standard. Everything depends on PyPI, pip, and virtualenv.
 Or Anaconda.
Again, a few links to evidence supporting these statements would be awesome. I am sorry for my being incult; I know of pip and used it a couple of times but know nothing about all else. At the same time you'll appreciate I can't just form an opinion on your authority.
 There are many facts out there favouring distributed over centralized
 for everything except the language itself and the runtime system, you
 just have to look. Calling for an explicit, detailed catalogue is not a
 way forward in this debate.
I am truly sorry but is appealing to your own authority a better alternative?
 Dub needs to be front and centre, it represents D, not DMD, LDC, GDC,
 druntime, Phobos. The core of a D distribution is Dub. In this D is
 like Rust, Ceylon, Python, and JVM. And unlike Go. Go is too
 libertarian in my view. Rust, Ceylon, Python, JVM have the right view
 for me: centralized repository and management of distributed projects.
 What Rust and Ceylon are missing that PyPI has is an highly opinionated
 metric that helps you decide what is good and what is dross.

 Of course Dub needs a better story around executables rather than
 library packages. Go (go install) and Rust (Cargo build) do this so
 much better. But then Go has a project structure model, and Rust uses
 TOML.
I do agree with Dub's importance. What's unclear to me is what are reasonable criteria for including some given functionality within the stdlib vs. an external one. Andrei
Jan 26
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-01-26 13:38, Andrei Alexandrescu wrote:

 Thanks for answering. I want to be convinced, and even if not, to gather
 a more precise view.

 The rhetoric is appreciated. What would be helpful here in addition to
 it are a few links to evidence. You make lofty claims either of status
 quo in different languages, or major shifts in strategy. They definitely
 must have left a trail on the Internet. Any chance you'd substantiate
 these specific claims below with evidence?
I don't really have an opinion but I found this [1] for Ruby. [1] https://redmine.ruby-lang.org/projects/ruby/wiki/StdlibGem -- /Jacob Carlborg
Jan 26
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Tuesday, 26 January 2016 at 12:38:09 UTC, Andrei Alexandrescu 
wrote:
 including things that some people argue shouldn't be part of a 
 standard library: archives and compression, cryptography, 
 databases, character encodings (including json and xml!), html 
 templating, image processing, suffix arrays (sic), logging, 
 networking, regexp, testing, tokenization.
See my answer below, most of these are standard solutions that you need on a daily basis (except for the suffix array).
 I do agree with Dub's importance. What's unclear to me is what 
 are reasonable criteria for including some given functionality 
 within the stdlib vs. an external one.
A good criteria is whether some area has an established and hard to debate solution, then it can go into the standard library. But if there are many different ways around the same topic you should leave the decision to the users. So for example there are 3 established ways to parse something, dom, stax and event based parsers. So you can add those parsers as sth. like std.xml or std.json. There are about 500 different configuration file formats, so anything that isn't as established as xml or json should be left for libraries. Likewise there are plenty of different GUI toolkits (taking imperative or declarative approaches). Leave it to people to pick one that suites their need. You could discuss endlessly about the syntax of html templating, but how such a library should work is clear. This is at the edge of standardizable, b/c by putting it into std, you're making a decision for all language users. It's albeit possible, just like declaring a particular code style as standard. Anything that is highly innovative or experimental should never go into standard libraries.
Jan 27
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Wednesday, 27 January 2016 at 21:00:41 UTC, Martin Nowak wrote:
 A good criteria is whether some area has an established and 
 hard to debate solution, then it can go into the standard 
 library. But if there are many different ways around the same 
 topic you should leave the decision to the users.
I don't think this is the right criteria. Take a good hard look at the C++ standard library. Plenty of things in there that nobody use, but which one would hope that almost everyone would use. Like for numerics. When a good external numerics library emerge it will displace whatever numerics functionality the standard library provides. D has too few users to see high quality external libraries, but that is not a good reason to bloat the standard library. The argument that some functionality is needed on a daily basis is also misguided. Different applications have different needs. What the standard library should support is essential interfacing with the system and what you need to interface with libraries, like basic types/iterators. Once you have something in the standard library you have to maintain it forever. If something is in the standard library and it turns out to be impossible to implement it efficiently on a specific hardware platform then all libraries using that functionality will be dog slow on that platform.
 So for example there are 3 established ways to parse something, 
 dom, stax and event based parsers. So you can add those parsers 
 as sth. like std.xml or std.json.
There is no reason for xml or json to be in the standard library. You can have a set of recommended libraries, allowing for more efficient APIs to emerge over time. Only functionality where you get unbreakable interdependencies between standard modules need to be in standard library. Parsers and compressors have low levels of inter-library dependencies. DSP functionality has only internal dependencies. No need for such things in the standard library. Scripting languages like Python is a horrible example to follow. Scripting languages require all C-implemented functionality to be in the standard library for the sake of being able to deploy pure python code on machines where you don't get to install binaries.
Jan 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
This is what a good system programming standard library should 
provide:

1. Types needed to specify library APIs.

2. Functionality for accessing hardware in a non-emulated fashion.

3. Functionality that most _libraries_ need to build on (like 
arrays/iterators/ranges).

4. Functionality that is tied to the individual compiler (like 
intrinsics).

5. Memory management.


The primary goal of the standard library should not be to support 
building applications, but to enable building frameworks and 
libraries and the interaction between them.


So if one user says "My app needs to read WAV which is RIFF, 
therefore RIFF should be in the standard library" then the 
sensible response is: "Do most _libraries_ need RIFF? Why don't 
you use the recommended audio library which has optimized WAV 
support.".

Surely everyone uses string processing on a daily basis?

No. I personally almost never do string processing in system 
level programming languages, what I need is binary serializing 
support. Or Collada support. Or audio file format support.

I'd be happy to use a recommended string procesessing library 
when or if I need it.

But a standard library MUST have great support for SIMD 
intrinsics, i.e. interfacing the hardware,  that is much more 
critical for system level programming and is tied to the specific 
compiler.
Jan 28
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Thursday, 28 January 2016 at 10:00:59 UTC, Ola Fosheim Grøstad 
wrote:
 This is what a good system programming standard library should 
 provide:

 1. Types needed to specify library APIs.

 2. Functionality for accessing hardware in a non-emulated 
 fashion.

 3. Functionality that most _libraries_ need to build on (like 
 arrays/iterators/ranges).

 4. Functionality that is tied to the individual compiler (like 
 intrinsics).

 5. Memory management.


 The primary goal of the standard library should not be to 
 support building applications, but to enable building 
 frameworks and libraries and the interaction between them.


 So if one user says "My app needs to read WAV which is RIFF, 
 therefore RIFF should be in the standard library" then the 
 sensible response is: "Do most _libraries_ need RIFF? Why don't 
 you use the recommended audio library which has optimized WAV 
 support.".

 Surely everyone uses string processing on a daily basis?

 No. I personally almost never do string processing in system 
 level programming languages, what I need is binary serializing 
 support. Or Collada support. Or audio file format support.

 I'd be happy to use a recommended string procesessing library 
 when or if I need it.

 But a standard library MUST have great support for SIMD 
 intrinsics, i.e. interfacing the hardware,  that is much more 
 critical for system level programming and is tied to the 
 specific compiler.
I do like the building-block idea you suggest, but one must think about the deeper reasons for why things are owned by which people. (I have found the Coase theorem and work on industrial organisation to be quite stimulating in thinking about this question). In theory it's completely irrelevant as to whether is something is in the standard library or can just be imported via dub or a git clone, but in practice that's not the case. As you yourself have mentioned, the size of the D community as it stands today presents some impediment to the possible maintenance and stability of alternative libraries. If something is in Phobos you know that you can depend on it, that bugs will get fixed, and that changes to the language won't stop the code from compiling (since it will be fixed). Being in Phobos is a focal point, whereas there simply isn't for now any kind of focal point for external libraries. The bus factor is high for external libraries - people get sick, divorced, change interest, and so on. There are also benefits from coherence, since the code will tend to converge on a similar style. I appreciate that your own interests are quite different, but perhaps you can see that they are only part of what's important for the community as a whole. It would be nice to have SIMD intrinsics, and in the time you have spent arguing over the years perhaps it would have been possible to help the process of having a high quality and consistent implementation along. People would also be much more inclined to listen to what you say because then it comes from someone with serious skin in the game. (Walter himself has spoken about the importance of listening to people who like your stuff and use it already over those who say if only you did X we could use it on a large scale - and that's also plain good business sense). The gadfly can play a useful role in a community, but not if he continually diminishes the worth of what people are working hard trying to do (in inevitably imperfect human ways). It really doesn't do any good to worry about what the crowd says and the applause you receive. If you focus on doing good work (and have some reinforcement along the way because people are using your work to do serious things) then recognition will come. The work that dlangscience is doing (and one could see ndslice as a part of that) opens up new possibilities that I am quite excited about. I should say that John Colvin is a contractor for me, but I am not talking up dlangscience because he is helping me, but rather I asked him to help me because I was impressed by what he is doing. It strikes me as a bit silly to get hung up over language specifications as some kind of mystical talisman. C was used for years in a serious way before the ANSI spec. Same for Ruby. I couldn't immediately see what the situation was for Python. There isn't the manpower to go that route yet, and nor would it be constructive when certain aspects are not yet as polished as they will eventually be. Ultimately the test of a language is in whether people can use it to do good work. Compound growth can be very powerful, and more complex things take time to mature to the point where they are useful in certain domains. I couldn't have used D for work five years ago, but I can now. There are these threshold effects, just as Christensen described in the Innovator's Dilemma. D continues to grow and isn't going to disappear any time soon. It would be much better to put one's energy into actually writing code that can improve things (even as a proof of concept) than debating what might or might not happen if things don't change (when they always do). Kingsley hadn't been using D long, liked his IDE, so wrote a D module for it. It's not perfect yet, but it's a beginning and will mature in time. That kind of thing will get us much further than debating about what people should do, when there is no army of troops that can be commanded to implement things they are not interested in doing anyway. Walter clearly doesn't decide everything, any more than a prince does in a monarchy of old. But we are lucky that he does have such an important influence because he has good taste and a rare skill set. One gets a higher quality design that way than if you have something that is the pure creation of a committee. At some point maybe there'll be a need for a committee and a language spec. That's a higher quality problem to have, but it surely isn't the main concern today.
Jan 28
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
 I do like the building-block idea you suggest, but one must 
 think about the deeper reasons for why things are owned by 
 which people.
It is much easier to get motivated if you have a certain level autonomy. Clearly, the "D foundation" should have criterions for making a recommendation, like API guidelines, Boost license and commitment to maintaining it for a period of time. For instance, Ponce has made some efforts on audio. You and others have made some effort on economic modelling (?). I am interested in audio. Then we have an opportunity to form a team that builds a shared numerics library, with some input from some Phobos coordinator so that ranges are supported in a consistent matter. But here is the key point: we don't have to get input from all D programmers. We can form consensus and take ownership and make faster decisions. And we can scrap it in two years, learn from our mistakes and create a much better API. I think that Sonke received too much "negative motivation" for his contributions recently, if I had been in his shoes I'd probably found working on vibe.d more fun. IRRC Ruppe also have voiced that he want to work on libraries which he has more freedom with. An frankly, as APIs have to be vetted on large applications in maintenance mode a lot of the effort put into arguing the design "perfect Phobos libraries" most likely will be in vain.
  (I have found the Coase theorem and work on industrial 
 organisation to be quite stimulating in thinking about this 
 question).
I noticed you and the other economic theory guys in the thread mentioning some interesting models. I'd like to look at those later when I have more time :-). Always nice to find some shared language for expressing system dynamics.
 In theory it's completely irrelevant as to whether is something 
 is in the standard library or can just be imported via dub or a 
 git clone, but in practice that's not the case.
Well, but if something is in the standard library, other libraries will build upon it and add dependencies to it even if they don't really have to. Meaning, they will pull in dependencies and bloat and make Phobos costly to maintain as you will end up with std.json, std.json2, std.json3 etc.
 As you yourself have mentioned, the size of the D community as 
 it stands today presents some impediment to the possible 
 maintenance and stability of alternative libraries.
No, I don't think so. I think that D has nurtured the idea that Phobos should provide everything and therefore the modus operandi is to complain that Phobos does not provide it.
 The bus factor is high for external libraries - people get 
 sick, divorced, change interest, and so on.
Recommended libraries should have at least 3-6 people behind them
 It would be nice to have SIMD intrinsics, and in the time you 
 have spent arguing over the years perhaps it would have been 
 possible to help the process of having a high quality and 
 consistent implementation along.
SIMD isn't critical to me at this point in time. I am currently using C++ for what I would have liked to use D for. D needs more compiler developers, a strategy to get there and someone to take D there with focused leadership. The main challenge is not code, it is process.
 It really doesn't do any good to worry about what the crowd 
 says and the applause you receive.  If you focus on doing good
I don't worry about applause. Describe the key issues and explain it from various angels whenever it comes up and people start to develop a shared understanding of what needs to be done. Without a timeline, why invest? The vision for 2016 looks pretty good, but there it lacks the details of what and when. What are the estimates. What are the explicit goals? How many man hours (min/max) are needed. Goals and estimates.
 excited about.  I should say that John Colvin is a contractor 
 for me, but I am not talking up dlangscience because he is 
 helping me, but rather I asked him to help me because I was 
 impressed by what he is doing.
That's great! :-)
 It strikes me as a bit silly to get hung up over language 
 specifications as some kind of mystical talisman.
It brings unfortunate inconsistencies and implementation effects to the foreground so that they can be addressed. It is near impossible to discuss the design without one.
 debating about what people should do, when there is no army of 
 troops that can be commanded to implement things they are not 
 interested in doing anyway.
Attract more developers. 1. Find out why they don't come. 2. Find out why they leave. 3. Address the issues they have with D. In my case and for many others the reason go along the lines of: memory management, language inconsistencies, a refusal to add builtin tuples and platform support.
Jan 28
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 28 January 2016 at 12:40:56 UTC, Ola Fosheim Grøstad 
wrote:
 I think that Sonke received too much "negative motivation" for 
 his contributions recently, if I had been in his shoes I'd 
 probably found working on vibe.d more fun. IRRC Ruppe also have 
 voiced that he want to work on libraries which he has more 
 freedom with.
Yeah, I think getting in Phobos is a waste of time and likely a net negative on the library due to how much harder it is to change phobos vs changing your own file. In my perfect world, quality third party apps - as determined just by usage stats or something - would be automatically downloadable and their documentation searchable as if it was standard. When you do `import std.string;` you expect it to just work, and you find std.string's docs easily from dmd. I'd love it if you could do `import thirdparty.independent;` and it magically works too - without even need for a configuration file or an install command. And the docs are right there and tutorials are written however the author feels like writing them. Then the line between "standard library" and other library basically disappears. While that isn't likely to happen, we could at least start promoting third party stuff more equally.
 An frankly, as APIs have to be vetted on large applications in 
 maintenance mode a lot of the effort put into arguing the 
 design "perfect Phobos libraries" most likely will be in vain.
This is a reason why I tend to only write libs that I actually use myself - at least then I know every function has one happy user.
Jan 29
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:
 In my perfect world, quality third party apps - as determined 
 just by usage stats or something - would be automatically 
 downloadable and their documentation searchable as if it was 
 standard.
I've noticed that curated lists of libraries are popping up on github for various languages: https://github.com/search?utf8=%E2%9C%93&q=awesome If D gets more users maybe there would be a market for a commercial IDE with a reviewed repository with globally searchable reference documentation and cookbook recipes. For popular languages stack overflow is pretty ok, but over time it is getting more chaotic. Imagine an intelligent IDE that looks at the probability of a match between a cookbook recipe and what you type. A.I. templating of sorts.
 Then the line between "standard library" and other library 
 basically disappears.
I usually prefer to download from github for commercial code and put it in my project archive. I want to check out if the library programmers are maintaining it and have enough people as well. Then I lock that version until I find a reason to upgrade. For me automatic downloading (dub etc) fits more with hobby projects and experiments.
 While that isn't likely to happen, we could at least start 
 promoting third party stuff more equally.
Yep, a curated list like those awesome-lists found on github would be a start. Then write tutorials that only use libraries from that list.
 This is a reason why I tend to only write libs that I actually 
 use myself - at least then I know every function has one happy 
 user.
Yeah, I find myself constantly wanting to improve on even the simplest libraries for better interaction with the kind of code the functions/objects seem to be most used with. More of a discovery process of usability than "mathematical deduction".
Jan 29
parent Puming <zhaopuming gmail.com> writes:
On Friday, 29 January 2016 at 23:41:47 UTC, Ola Fosheim Grøstad 
wrote:

 Yep, a curated list like those awesome-lists found on github 
 would be a start.
I've got one before there were many awesome-lists: https://github.com/zhaopuming/awesome-d
Jan 29
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/29/16 11:07 AM, Adam D. Ruppe wrote:
 I'd love it if you could do `import thirdparty.independent;` and it
 magically works too - without even need for a configuration file or an
 install command. And the docs are right there and tutorials are written
 however the author feels like writing them.
I suggested that at a point, it was destroyed. -- Andrei
Feb 02
prev sibling next sibling parent reply earthfront <earthfront safetymail.info> writes:
On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:
 When you do `import std.string;` you expect it to just work, 
 and you find std.string's docs easily from dmd.

 I'd love it if you could do `import thirdparty.independent;` 
 and it magically works too - without even need for a 
 configuration file or an install command. And the docs are 
 right there and tutorials are written however the author feels 
 like writing them.
OMG I would love this. Often I write short scripts and use rdmd for rapid prototyping. Having to dub initialize and pull in libraries is a pain for this. Python got it right with their package manager(s)
Feb 02
parent reply Tofu Ninja <emmons0 purdue.edu> writes:
On Wednesday, 3 February 2016 at 03:19:57 UTC, earthfront wrote:
 On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe wrote:
 When you do `import std.string;` you expect it to just work, 
 and you find std.string's docs easily from dmd.

 I'd love it if you could do `import thirdparty.independent;` 
 and it magically works too - without even need for a 
 configuration file or an install command. And the docs are 
 right there and tutorials are written however the author feels 
 like writing them.
OMG I would love this. Often I write short scripts and use rdmd for rapid prototyping. Having to dub initialize and pull in libraries is a pain for this. Python got it right with their package manager(s)
I suggested this once but there seems to be a group of people the viscerally oppose this. See: http://forum.dlang.org/post/bdhmdbhyoirmwcbbxvln forum.dlang.org
Feb 02
parent reply =?UTF-8?B?TcOhcmNpbw==?= Martins <marcioapm gmail.com> writes:
On Wednesday, 3 February 2016 at 05:41:52 UTC, Tofu Ninja wrote:
 On Wednesday, 3 February 2016 at 03:19:57 UTC, earthfront wrote:
 On Friday, 29 January 2016 at 16:07:48 UTC, Adam D. Ruppe 
 wrote:
 When you do `import std.string;` you expect it to just work, 
 and you find std.string's docs easily from dmd.

 I'd love it if you could do `import thirdparty.independent;` 
 and it magically works too - without even need for a 
 configuration file or an install command. And the docs are 
 right there and tutorials are written however the author 
 feels like writing them.
OMG I would love this. Often I write short scripts and use rdmd for rapid prototyping. Having to dub initialize and pull in libraries is a pain for this. Python got it right with their package manager(s)
I suggested this once but there seems to be a group of people the viscerally oppose this. See: http://forum.dlang.org/post/bdhmdbhyoirmwcbbxvln forum.dlang.org
How would you select the package version you want to use. Obviously it would be fine for small scripts to pick the latest version, but no so much for non-trivial projects. Somewhat related: I would love to be able to install packages with dub "globally", and then have them automatically added to the compiler's search paths and working with import with rdmd and dmd. I install version 0.1 of package X globally and now all my programs pick that up with import. If the package is a library, dub would (re)compile then upon installation and put the resulting libs in the correct places so that all my programs can simply link to them. I should also be able to override the global import with a different version at the project level if I which to do so. Similar to what dub.selections.json currently does. Having dub fully integrated with the compiler and it's configuration would be a major quality of life improvement, and a nice step towards the "it just works" state. Much like C/C++ libraries get installed by Linux's package managers and just work, but for D. Right now the easiest way to boot up a new project is to copy one that already exists, rename it, and edit the dub.json file to add/remove any dependencies. This gets old really quickly and is the only reason why D doesn't really feel like a scripting language for small projects, because setting up the environment and frequently used dependencies takes longer than writing the script, and you need a project directory instead of a single .d file that just uses all your common imports.
Feb 03
parent reply Tofu Ninja <emmons0 purdue.edu> writes:
On Wednesday, 3 February 2016 at 11:22:50 UTC, Márcio Martins 
wrote:
 How would you select the package version you want to use. 
 Obviously it would be fine for small scripts to pick the latest 
 version, but no so much for non-trivial projects.

 Somewhat related: I would love to be able to install packages 
 with dub "globally", and then have them automatically added to 
 the compiler's search paths and working with import with rdmd 
 and dmd.

 I install version 0.1 of package X globally and now all my 
 programs pick that up with import. If the package is a library, 
 dub would (re)compile then upon installation and put the 
 resulting libs in the correct places so that all my programs 
 can simply link to them.
 I should also be able to override the global import with a 
 different version at the project level if I which to do so. 
 Similar to what dub.selections.json currently does.

 Having dub fully integrated with the compiler and it's 
 configuration would be a major quality of life improvement, and 
 a nice step towards the "it just works" state. Much like C/C++ 
 libraries get installed by Linux's package managers and just 
 work, but for D.

 Right now the easiest way to boot up a new project is to copy 
 one that already exists, rename it, and edit the dub.json file 
 to add/remove any dependencies. This gets old really quickly 
 and is the only reason why D doesn't really feel like a 
 scripting language for small projects, because setting up the 
 environment and frequently used dependencies takes longer than 
 writing the script, and you need a project directory instead of 
 a single .d file that just uses all your common imports.
There are a few problems with it. For instance dub packages have no information about the files in them, you can't ask dub for derelict.opengl3.gl3.d, you ask it for the package derelict-gl3. So for something like this to work, there would need to be some type of syntax to import the package. Probably something simple could be done like pragma(dub, "derelict-gl3", "==1.0.12");. As far as I can tell a dub pragma could be 100% ignored by the compiler unless a flag gets passed to print the dub dependencies. Then a tool like rdmd that gets all the imports for a file could also get all the dub dependencies and call out to dub to download them and pass the import paths for the dub dependencies to the final invocation of dmd. Otherwise the dub pragma would really do nothing other than be a signifier to outside tools. Tools like dcd could even use the pragmas to automatically call out to dub to find the paths of the dependencies and start indexing them for auto completion. Really would be a great day to have that all automatically work. Also dub could be packaged with dmd and make all this more simple. Right now the easiest way to use dub is to make a .json for your own project and build with dub, but honestly that sucks a lot because really the only thing people want to use dub for is the dependencies, the rest of it kinda gets in the way and is annoying as hell to use. Like trying to figure out how to build projects for x64 or unittests or whatever with dub is a pain. Its not really what people want to use dub for, but it tries to pass itself off as a build system which it sucks at.
Feb 03
parent reply Tofu Ninja <emmons0 purdue.edu> writes:
On Wednesday, 3 February 2016 at 23:35:21 UTC, Tofu Ninja wrote:
 ...
Actually now that I think about it, you can do with out the pragma and just define something like this... mixin template DubDependency(string dependency, string vers) { // Does nothing but print a dependency version(Dub_Dependency){ pragma(msg, "DubDependency: \"" ~ dependency ~ "\" \"" ~ vers ~ "\""); } } Then whenever you need it you just put: mixin DubDependency!("derelict-gl3", "==1.0.12"); And to get the dependencies for a file you can just do dmd test.d -o- -version=Dub_Dependency
Feb 03
parent reply Tofu Ninja <emmons0 purdue.edu> writes:
On Thursday, 4 February 2016 at 00:50:43 UTC, Tofu Ninja wrote:
 On Wednesday, 3 February 2016 at 23:35:21 UTC, Tofu Ninja wrote:
 ...
Actually now that I think about it, you can do with out the pragma and just define something like this... mixin template DubDependency(string dependency, string vers) { // Does nothing but print a dependency version(Dub_Dependency){ pragma(msg, "DubDependency: \"" ~ dependency ~ "\" \"" ~ vers ~ "\""); } } Then whenever you need it you just put: mixin DubDependency!("derelict-gl3", "==1.0.12"); And to get the dependencies for a file you can just do dmd test.d -o- -version=Dub_Dependency
Actually, nvm, wouldn't actually work because as soon as you add an import derelict.opengl3.gl3; it would error out because it cant find the file and it wouldn't print the dependencies.
Feb 03
parent Chris Wright <dhasenan gmail.com> writes:
On Thu, 04 Feb 2016 01:23:14 +0000, Tofu Ninja wrote:

 Actually, nvm, wouldn't actually work because as soon as you add an
 import derelict.opengl3.gl3; it would error out because it cant find the
 file and it wouldn't print the dependencies.
You could do it with libdparse, since it doesn't do semantic analysis.
Feb 03
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
On Fri, 29 Jan 2016 16:07:48 +0000, Adam D. Ruppe wrote:

 I'd love it if you could do `import thirdparty.independent;` and it
 magically works too - without even need for a configuration file or an
 install command. And the docs are right there and tutorials are written
 however the author feels like writing them.
That's how Go does it. It's not the case that Go doing things one way means that you should do the opposite, but it is an indication that you should look for other examples before following suit. In the case of dependencies, they should always be versioned. The language and standard library should be stable enough that you don't have to specify a version you depend on -- though that isn't always true. So are you going to include a version specifier in import statements now? That would be awkward.
Feb 02
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
 As you yourself have mentioned, the size of the D community as 
 it stands today presents some impediment to the possible 
 maintenance and stability of alternative libraries.  If 
 something is in Phobos you know that you can depend on it, that 
 bugs will get fixed, and that changes to the language won't 
 stop the code from compiling (since it will be fixed).
On the other hand, Phobos is so tightly coupled to dmd that if you want a Phobos bugfix, you might also be stuck with a dmd regression and get nowhere. Moreover, Phobos doesn't really get all that many bug fixes. It lags on the release cycle and a few modules are basically just abandoned. Third party alternatives have been available the whole time though.
 The bus factor is high for external libraries - people get 
 sick, divorced, change interest, and so on.
But there's nothing stopping you from forking it yourself...
Jan 28
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
 I do like the building-block idea you suggest, but one must 
 think about the deeper reasons for why things are owned by 
 which people.  (I have found the Coase theorem and work on 
 industrial organisation to be quite stimulating in thinking 
 about this question).

 In theory it's completely irrelevant as to whether is something 
 is in the standard library or can just be imported via dub or a 
 git clone, but in practice that's not the case.
Sigh... The Coase Theorem is about externalities. The whole point of the Coase theorem is that when one person is causing a nuisance or polluting it is costly to bargain so the efficient allocation may not result. The law/courts should assign property rights in such a way to maximize efficiency. This does not seem relevant. Based on the second paragraph, I think you meant Ronald Coase's work in the paper The Nature of the Firm. This paper asks the question why things are made in a firm or contracted to other firms. This clearly parallels your discussion of why things are included in phobos or not. However, the whole point of the Nature of the Firm is that transaction costs exist in the real world. Firms trade-off the transaction costs of contracting business outside the firm with the benefits of doing things in house. These pressures lead to constraints on the maximum size of a firm. Coming back to phobos and the fact that there are transaction costs in the real world (discussions on the forum about the future of D are clearly transaction costs), this implies that "in theory" it is not irrelevant as to whether something is in the standard library or not. As discussed elsewhere, there are clearly benefits to putting some things in phobos (if only for providing a framework for others), and there are costs as it gets too large.
Jan 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Thursday, 28 January 2016 at 16:12:44 UTC, jmh530 wrote:
 the standard library or not. As discussed elsewhere, there are 
 clearly benefits to putting some things in phobos (if only for 
 providing a framework for others), and there are costs as it 
 gets too large.
That's the maintenance costs, but there are other related costs: 1. It takes a lot of work to get it in, you have to negotiate with non-domain experts to get in improvements. 2. The presence of sub-optimal standard functionality discourage development of slightly better functionality as a third party solution. So you loose evolutionary advantages. 3. You cannot easily modify it as it is distributed with the compiler. A standard library is essentially an API with a reference implementation, but compilers can do whatever they want in terms of implementation. Changes can therefore lead to incompatibilities between compilers. 4. You cannot easily fix bugs, because applications depends on the old behaviour. So a bug fix is a breaking change. You have to deprecate and provide the same functionality under a new name instead. External libraries can avoid a lot of these issues by versioning. Selecting between many different versions of submodules of a standard library is way too complicated.
Jan 28
parent Rory McGuire via Digitalmars-d-announce writes:
On 28 Jan 2016 6:30 PM, "Ola Fosheim Gr=C3=B8stad via Digitalmars-d-announc=
e" <
digitalmars-d-announce puremagic.com> wrote:

[snip]
 4. You cannot easily fix bugs, because applications depends on the old
behaviour. So a bug fix is a breaking change. You have to deprecate and provide the same functionality under a new name instead.
 External libraries can avoid a lot of these issues by versioning.
Selecting between many different versions of submodules of a standard library is way too complicated.

This is the main problem with "batteries included".
While just providing default libraries for specific domains through dub
solves the 3rd party Isis purple have mentioned there is no way a batteries
included standard library can keep backwards compatibility and be a
pleasure to work with, for those working on it and those using it.
Jan 31
prev sibling parent Matt Elkins <notreal fake.com> writes:
On Thursday, 28 January 2016 at 11:25:08 UTC, Laeeth Isharc wrote:
 In theory it's completely irrelevant as to whether is something 
 is in the standard library or can just be imported via dub or a 
 git clone, but in practice that's not the case.
In support of this statement in particular I'd like to point out that there are many environments which, for various reasons of security and policy, often require that any 3rd-party libraries not included as a language's standard be explicitly vetted by teams of very slow-moving people who seem to actively enjoy paperwork. In practice this means that non-standard libraries simply don't get used in those environments. That said, if a library gets popular enough (Boost, parts of Apache), they might manage to get pre-vetted and still used in these situations. I'm not really offering a good solution to the debate, I just wanted to make a note of this.
Feb 03
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Monday, 25 January 2016 at 16:26:36 UTC, Russel Winder wrote:
 PyPI has is an highly opinionated metric that helps you decide 
 what is good and what is dross.
Could you help us on designing one for code.dlang.org as well?
Jan 27
parent reply Chris Wright <dhasenan gmail.com> writes:
On Wed, 27 Jan 2016 21:01:47 +0000, Martin Nowak wrote:

 On Monday, 25 January 2016 at 16:26:36 UTC, Russel Winder wrote:
 PyPI has is an highly opinionated metric that helps you decide what is
 good and what is dross.
Could you help us on designing one for code.dlang.org as well?
I'd want to use the number of releases, how recent the most recent release was, the longevity of the project, and the number of other projects that depend on it. If people are willing to let dub submit anonymous usage information, the number of builds depending on a project is also an indicator of its value. Longevity is an awkward one. If I create a project, do nothing with it for four years, then make a release, will that count as well as making a release once a month for four years? But the other metrics should account for that. If possible, I'd include when the project last compiled and whether it passes its unittests. This requires setting up a continuous integration service for untrusted code. I've seen other people's designs for that, and I think I could replicate it without too much trouble.
Jan 27
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Wednesday, 27 January 2016 at 22:36:37 UTC, Chris Wright wrote:
 Longevity is an awkward one. If I create a project, do nothing 
 with it for four years, then make a release, will that count as 
 well as making a release once a month for four years? But the 
 other metrics should account for that.
Code I wrote below incorporates some of what you're talking about. For simplicity, I represented the date of each release as a dynamic array of doubles. I applied a weighting function to each and then calculated the entropy. The score is 1 if you only have one release. The score is higher, the more releases you have. If you have one release five years ago and one release recently, then your score is only marginally higher than 1. But if you have lots of recent releases, then the score is much more favorable. You could probably adjust this in a number of ways. For instance, adjusting the denominator in return weight.map!(a => a / weight.sum()); you could make it so that a release today is better than a release five years ago. auto weight(double[] x, double lambda) { import std.algorithm : sum, map; import std.math : exp; import std.array : array; auto weight = x.map!(a => lambda * exp(-lambda * a)); // weights given by // exponential // distribution return weight.map!(a => a / weight.sum()); } double entropy(T)(T x) { import std.algorithm : sum, map; import std.math : exp, log; auto e = x.map!(a => a * log(a)); return exp(-sum(e)); } double calc_score(double[] x, double lambda) { return x.weight(lambda).entropy(); } void main() { import std.stdio : writeln; double lambda = 0.5; // controls decay in weighting function double[] x; // represents years since last update x = [0.1, 0.25, 1, 2, 5]; auto score = calc_score(x, lambda); writeln(score); }
Jan 27
prev sibling parent reply Twenty Two <sdffgfsd sgsd.com> writes:
Parkinson's Law: work expands so as to fill the time available 
for its completion.

Having a set of vague tasks to finish within 6 months is great, 
but having a weekly more specific priority list to go along with 
it would be better. If, in addition, there was some 
accountability (not with negative implications, just a 
designation of responsibility) that would further narrow focus 
and ramp up productivity.

As a draft proposal, something like a weekly sticky TODO thread 
with clear goals could work. You'd list a few high priority items 
and ask for a volunteers for each and list them as they come in. 
You'd have bigger medium priority item list and ask for 
volunteers but only half of them need to be assigned to someone 
and completed. Then you'd have a much longer lower priority list 
that can be a bit more vague that people are encouraged to work 
on but that they don't need to volunteer for, just submit their 
pull requests (but they can flag an item and have it ticked off 
if they want). On top of that have a weekly pull request goal 
that updates daily (with a time stamp) and an overview of pull 
request numbers from previous weeks.

If an item isn't completed it gets rolled over to the next week 
with an asterisk (if it's medium or high priority) for each time 
it's been rolled over and the previous volunteer listed as such 
(and they can volunteer for the same item the next week giving 
them the perfect opportunity to say where they're at, what needs 
to be done, if the task should be broken down further, etc). 
It'll make it clear if whoever volunteered for a task needs some 
help or encouragement, or if certain high priority tasks need a 
volunteer or to be broken down into more manageable chunks even 
if someone drops off the face of the earth. With a one item at a 
time rule you're going to cut down on stagnation.

I'm sure there are lots of people who'd like to help out but 
they're not really sure what needs to be done or who else is 
doing it or if they'll step on toes, etc. Anyone wondering what's 
being worked on can take a look and help out themselves rather 
than getting upset in the forums about feature x never seeing the 
light of day. If they want feature x done they can take a look at 
the priority list and pick where it should go in the scheme of 
things, maybe even break it down - turn negative energy into 
productive energy :)
Jan 27
parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 28 January 2016 at 00:28:26 UTC, Twenty Two wrote:
 Parkinson's Law: work expands so as to fill the time available 
 for its completion.

 [...]
I agree. Some of the core team uses trello for this: https://trello.com/b/XoFjxiqG/active However, that's not really meant for noobs and a lot of the core team, including Walter, doesn't really use it.
Jan 27
parent Twenty Two <sdffgfsd sgsd.com> writes:
On Thursday, 28 January 2016 at 02:36:55 UTC, Joakim wrote:
 On Thursday, 28 January 2016 at 00:28:26 UTC, Twenty Two wrote:
 Parkinson's Law: work expands so as to fill the time available 
 for its completion.

 [...]
I agree. Some of the core team uses trello for this: https://trello.com/b/XoFjxiqG/active However, that's not really meant for noobs and a lot of the core team, including Walter, doesn't really use it.
Judging by the activity log, it's mostly just Martin... poor dawg. Putting something together people will actually use is pretty hard, almost as hard as keeping the momentum to get people to keep using whatever you've put in place. Trello's not a bad tool but it's useless if there's no traction and no one's being reminded to use it. It's hard to attract contributors if you don't spell out who/what/when/where/how and funnel them all to the one place. Maybe the core team could discuss among themselves what kind of workflow they think would really bring out their potential productivity and attract more hands to lighten the load. It seems unfair that some people get lumped with doing big jobs purely because there isn't really a good way to ask someone else to do pieces of it for them. I'm certain there are lots more people who would get involved if only there was a lower barrier to entry. Something not over complicated and visible would really move things along, I think.
Jan 28
prev sibling parent reply Piotrek <nodata nodata.pl> writes:
On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole 
wrote:
 That won't be happening anytime soon.
 Until we have image and windowing in Phobos (I'm working on 
 both) there is no way a GUI toolkit is going in. And from what 
 I know there will be a LOT of work to update it.
I've read this thread partially and I agree with you. In my opinion the key to the success is a good standard library with batteries included. The opinion that this approach is outdated is very subjective. I hope D GUI will be usable some day for me and other people not wanting to fight with tools (and external libraries). If there is something from your project ready for test drive let me know. Piotrek
Jan 28
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 29/01/16 6:40 AM, Piotrek wrote:
 On Monday, 25 January 2016 at 03:49:56 UTC, Rikki Cattermole wrote:
 That won't be happening anytime soon.
 Until we have image and windowing in Phobos (I'm working on both)
 there is no way a GUI toolkit is going in. And from what I know there
 will be a LOT of work to update it.
I've read this thread partially and I agree with you. In my opinion the key to the success is a good standard library with batteries included. The opinion that this approach is outdated is very subjective. I hope D GUI will be usable some day for me and other people not wanting to fight with tools (and external libraries). If there is something from your project ready for test drive let me know. Piotrek
Right now, image library is more or less ready for next feedback. Windowing is almost there, really just needs a bit of testing and its done. So in other words, the hold up, is me.
Jan 28
parent reply Piotrek <nodata nodata.pl> writes:
On Friday, 29 January 2016 at 02:18:38 UTC, Rikki Cattermole 
wrote:
 Right now, image library is more or less ready for next 
 feedback.
 Windowing is almost there, really just needs a bit of testing 
 and its done.

 So in other words, the hold up, is me.
Where can I find the code to be tested? You have too many projects on github :) Piotrek
Feb 06
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 07/02/16 4:23 AM, Piotrek wrote:
 On Friday, 29 January 2016 at 02:18:38 UTC, Rikki Cattermole wrote:
 Right now, image library is more or less ready for next feedback.
 Windowing is almost there, really just needs a bit of testing and its
 done.

 So in other words, the hold up, is me.
Where can I find the code to be tested? You have too many projects on github :) Piotrek
https://github.com/rikkimax/alphaPhobos
Feb 06
prev sibling parent Andre Polykanine via Digitalmars-d-announce writes:
PvDda> I hope D GUI will be usable some day for me and other people not
PvDda> wanting to fight with tools (and external libraries).

Oh  yeah!  I  find  this  library  the  most  adequate  (and  the most
accessible, btw). But unfortunately it seems abandoned :(.


Andre
Feb 02
prev sibling parent reply Andrew Edwards <edwards.ac gmail.com> writes:
On Monday, 25 January 2016 at 03:21:51 UTC, Puming wrote:
 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
 wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei
[snip]
 For tooling, I suggest a look at GUI/IDEs, now that 
 dlangui/dlangide seems a good candidate(native D, 
 crossplatform). A good official supported GUI library will 
 attract many people.
I truly doubt that. It would be truly amazing if that were to occur but history has proven otherwise. The sentiment was expressed so many times that Walter was finally moved to sanction DWT as the official GUI for D in 2006. Even a newsgroup was made for it. It's ten years later. DWT anyone? Aurora was a recent attempt that was shelved for the sole author's personal reasons. Result? Sadly, dlangui/dlangide is no different. It has one developer. If that individual gets discouraged, like so many others have so far, what becomes of it? Until members of the community starts combining efforts and working together to improve the situation, it will not improve. You have Adam working on working on simpledisplay, Mike working on Derelict, Felix working on three-d, Vladimir working on ae-graphics, Martin on freeimage, Vadim on dlangui/dlangide and who knows what else is out there in the wood works. All of this is admirable and appreciated but imagine what would be possible if these minds teamed up, mapped out a graphic solution for the language and united efforts in implementing it! I'm convinced that without such a deliberate effort, this situation will not change for years to come. Even if a particular library is dubbed "The One." Like I've said earlier, that was already done ten years ago.
Jan 24
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 25/01/16 7:39 PM, Andrew Edwards wrote:
 On Monday, 25 January 2016 at 03:21:51 UTC, Puming wrote:
 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
[snip]
 For tooling, I suggest a look at GUI/IDEs, now that dlangui/dlangide
 seems a good candidate(native D, crossplatform). A good official
 supported GUI library will attract many people.
I truly doubt that. It would be truly amazing if that were to occur but history has proven otherwise. The sentiment was expressed so many times that Walter was finally moved to sanction DWT as the official GUI for D in 2006. Even a newsgroup was made for it. It's ten years later. DWT anyone? Aurora was a recent attempt that was shelved for the sole author's personal reasons. Result? Sadly, dlangui/dlangide is no different. It has one developer. If that individual gets discouraged, like so many others have so far, what becomes of it? Until members of the community starts combining efforts and working together to improve the situation, it will not improve. You have Adam working on working on simpledisplay, Mike working on Derelict, Felix working on three-d, Vladimir working on ae-graphics, Martin on freeimage, Vadim on dlangui/dlangide and who knows what else is out there in the wood works. All of this is admirable and appreciated but imagine what would be possible if these minds teamed up, mapped out a graphic solution for the language and united efforts in implementing it! I'm convinced that without such a deliberate effort, this situation will not change for years to come. Even if a particular library is dubbed "The One." Like I've said earlier, that was already done ten years ago.
I agree. This is why everything I'm doing right now for windowing and image library builds upon what has come before but in a Phobos quality way. Unless it is in Phobos, its not good enough as a base IMO.
Jan 24
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-25 07:39, Andrew Edwards wrote:

 I truly doubt that. It would be truly amazing if that were to occur but
 history has proven otherwise. The sentiment was expressed so many times
 that Walter was finally moved to sanction DWT as the official GUI for D
 in 2006. Even a newsgroup was made for it. It's ten years later. DWT
 anyone?
DWT is still working perfectly fine. Just compiled it recently with the latest beta, 2.070. -- /Jacob Carlborg
Jan 25
parent reply Andrew Edwards <edwards.ac gmail.com> writes:
On Monday, 25 January 2016 at 10:53:29 UTC, Jacob Carlborg wrote:
 On 2016-01-25 07:39, Andrew Edwards wrote:

 I truly doubt that. It would be truly amazing if that were to 
 occur but
 history has proven otherwise. The sentiment was expressed so 
 many times
 that Walter was finally moved to sanction DWT as the official 
 GUI for D
 in 2006. Even a newsgroup was made for it. It's ten years 
 later. DWT
 anyone?
DWT is still working perfectly fine. Just compiled it recently with the latest beta, 2.070.
Glad to see your spirit is not easily broken. That, however, does not invalidate my statement. One would think that 10 years after being dubbed the official graphics library for the language, it would be simple to install DMD and DWT side by side on all DMD supported platforms and the two just work well together. Especially since people that advocated it claimed that by making it official, it would legitimize their contributions to help improve make improvements. It is not even usable on what appears to be the platform you develop on/for, MAC OS X, and you are the main maintainer/contributer.
Jan 25
parent reply Jacob Carlborg <doob me.com> writes:
On 2016-01-25 14:22, Andrew Edwards wrote:

 Glad to see your spirit is not easily broken. That, however, does not
 invalidate my statement.  One would think that 10 years after being
 dubbed the official graphics library for the language, it would be
 simple to install DMD and DWT side by side on all DMD supported
 platforms and the two just work well together. Especially since people
 that advocated it claimed that by making it official, it would
 legitimize their contributions to help improve make improvements. It is
 not even usable on what appears to be the platform you develop on/for,
 MAC OS X, and you are the main maintainer/contributer.
The only thing that happened, as far as I know, in terms of official was that Walter announced it to be the official GUI and it got its own dedicated newsgroup. It's not on the web site, there's been no coordinated releases, no contribution from the core team, nothing. I don't see how anyone could expect progress to increase at all. -- /Jacob Carlborg
Jan 25
next sibling parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 25 January 2016 at 21:44, Jacob Carlborg via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On 2016-01-25 14:22, Andrew Edwards wrote:

 Glad to see your spirit is not easily broken. That, however, does not
 invalidate my statement.  One would think that 10 years after being
 dubbed the official graphics library for the language, it would be
 simple to install DMD and DWT side by side on all DMD supported
 platforms and the two just work well together. Especially since people
 that advocated it claimed that by making it official, it would
 legitimize their contributions to help improve make improvements. It is
 not even usable on what appears to be the platform you develop on/for,
 MAC OS X, and you are the main maintainer/contributer.
The only thing that happened, as far as I know, in terms of official was that Walter announced it to be the official GUI and it got its own dedicated newsgroup. It's not on the web site, there's been no coordinated releases, no contribution from the core team, nothing. I don't see how anyone could expect progress to increase at all.
With respect, I'm not sure whether anyone in core would have the slightless hint of knowing how UI works. (Not that I speak for anyone but myself :-)
Jan 25
parent Jacob Carlborg <doob me.com> writes:
On 2016-01-25 22:15, Iain Buclaw via Digitalmars-d-announce wrote:

 With respect, I'm not sure whether anyone in core would have the
 slightless hint of knowing how UI works. (Not that I speak for anyone
 but myself :-)
And you think that I have the slightest idea of what I'm doing ;) -- /Jacob Carlborg
Jan 26
prev sibling parent Andrew Edwards <edwards.ac gmail.com> writes:
On Monday, 25 January 2016 at 20:44:10 UTC, Jacob Carlborg wrote:
 On 2016-01-25 14:22, Andrew Edwards wrote:

 Glad to see your spirit is not easily broken. That, however, 
 does not
 invalidate my statement.  One would think that 10 years after 
 being
 dubbed the official graphics library for the language, it 
 would be
 simple to install DMD and DWT side by side on all DMD supported
 platforms and the two just work well together. Especially 
 since people
 that advocated it claimed that by making it official, it would
 legitimize their contributions to help improve make 
 improvements. It is
 not even usable on what appears to be the platform you develop 
 on/for,
 MAC OS X, and you are the main maintainer/contributer.
The only thing that happened, as far as I know, in terms of official was that Walter announced it to be the official GUI and it got its own dedicated newsgroup. It's not on the web site, there's been no coordinated releases, no contribution from the core team, nothing. I don't see how anyone could expect progress to increase at all.
My point exactly. Simply naming something official does not improve it's status or send contributors clamoring to assist in its improvement. It takes a deliberate effort and dedication of resources to accomplish that.
Jan 25
prev sibling parent reply JohnCK <j j.com> writes:
On Monday, 25 January 2016 at 06:39:54 UTC, Andrew Edwards wrote:
 On Monday, 25 January 2016 at 03:21:51 UTC, Puming wrote:
 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei 
 Alexandrescu wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei
[snip]
 For tooling, I suggest a look at GUI/IDEs, now that 
 dlangui/dlangide seems a good candidate(native D, 
 crossplatform). A good official supported GUI library will 
 attract many people.
I truly doubt that. It would be truly amazing if that were to occur but history has proven otherwise. The sentiment was expressed so many times that Walter was finally moved to sanction DWT as the official GUI for D in 2006. Even a newsgroup was made for it. It's ten years later. DWT anyone? Aurora was a recent attempt that was shelved for the sole author's personal reasons. Result? Sadly, dlangui/dlangide is no different. It has one developer. If that individual gets discouraged, like so many others have so far, what becomes of it? Until members of the community starts combining efforts and working together to improve the situation, it will not improve. You have Adam working on working on simpledisplay, Mike working on Derelict, Felix working on three-d, Vladimir working on ae-graphics, Martin on freeimage, Vadim on dlangui/dlangide and who knows what else is out there in the wood works ... I'm convinced that without such a deliberate effort, this situation will not change for years to come. Even if a particular library is dubbed "The One." Like I've said earlier, that was already done ten years ago.
Well, I think the question is: IDE is a main thing today? If you take the languages that emerged along the years, some of them are backed most on web toolkit/Internet. Please don't get me wrong and I'm not saying this is NOT important. But today I think perhaps this kind of thing is turning into a niche. I think vibe.d or whatever web toolkit should get more attention. JohnCK.
Jan 25
parent reply Daniel Kozak via Digitalmars-d-announce writes:
V Mon, 25 Jan 2016 16:25:02 +0000
JohnCK via Digitalmars-d-announce
<digitalmars-d-announce puremagic.com> napsáno:

 On Monday, 25 January 2016 at 06:39:54 UTC, Andrew Edwards wrote:
 ...
 Well, I think the question is: IDE is a main thing today? If you 
 take the languages that emerged along the years, some of them are 
 backed most on web toolkit/Internet.
 
 Please don't get me wrong and I'm not saying this is NOT 
 important. But today I think perhaps this kind of thing is 
 turning into a niche.
 
 I think vibe.d or whatever web toolkit should get more attention.
 
 JohnCK.
I guess you mean GUI not IDE?
Jan 25
parent JohnCK <j j.com> writes:
On Monday, 25 January 2016 at 16:34:15 UTC, Daniel Kozak wrote:
 I guess you mean GUI not IDE?
Yes GUI... my fault, thanks! JohnCK.
Jan 25
prev sibling next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
Re: "Safety" and "Library additions", I anticipate that my `checkedint` module (a refinement and extension of Robert Schadek's `SafeInt` work) will be ready to start formal review within the next 1-2 months. I uploaded it to DUB yesterday: http://code.dlang.org/packages/checkedint TODO: Mostly documentation (coming this week, probably) and unit tests (it has tests, but they're too slow to stick directly in Phobos), but also miscellaneous small things.
Jan 24
prev sibling next sibling parent Chris Wright <dhasenan gmail.com> writes:
On Sun, 24 Jan 2016 21:37:40 -0500, Andrei Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
I'm not fond of the militaristic terminology for participants. Novice, adept, master, maybe? The section on safety is pretty short. I'd like to see in it: * Guidelines for what should be made trusted in Phobos (should we trust Win/Posix API functions? should we only trust wrappers that take D arrays rather than pointers? can we, for instance, create a trusted wrapper around curl?) * Efficiency / safety tradeoff guidelines (should Phobos provide a slightly faster implementations of things that aren't safe? In those cases, should it provide both safe and fast alternatives?) * safe / trusted IO as a goal As is, there are a smattering of things in Phobos that aren't safe but seem like they could or should be, with no explanation and no safe alternatives. I think almost all IO is system. This makes it hard and sometimes confusing to try to write safe code.
Jan 24
prev sibling next sibling parent Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
My biggest issue with these documents is that they have good ideas but rarely have plans to achieve them. As a consequence, most of these documents say how half or more of the previous goals were not achieved. I believe the best way to fix this is to simply have more focus. Have one large goal that can be broken down into smaller subsets, e.g. "2016 will be the year of a GC free Phobos". Something that has a very clear way of quantifying its success and a clear path to that goal. Not that that the other things are not important, but if you constantly find yourself failing to meet your goals, the only rational option is to become more realistic in your plans.
Jan 24
prev sibling next sibling parent rsw0x <anonymous anonymous.com> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
Would be great if shared finally got the love it needs, and you're one of the few people qualified to do it(in my humble opinion), Andrei. It was part of the 2015H1 vision, IIRC.
Jan 24
prev sibling next sibling parent reply Dibyendu Majumdar <d.majumdar gmail.com> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
Hi, I am new to D, and having my own language implementation (based off Lua) - therefore I think I can appreciate some of the difficulties around getting more contributors to D. For what its worth below are some thoughts on the H1 2016 priorities. I am a would be D user - D is a tool that should help me get my job done. I guess the vast majority of potential users are in this bracket. To become a contributor requires one of the following - a) it must be your day job, i.e. someone paying you to work on the language, or b) you happen to have lots of free time and deeply interested in D's development, plus have the skills needed to contribute to D. I think that getting contributors to the core of D is going to be difficult. Most other languages/compilers that have big list of contributors usually have one or more large organisations funding the people working on the language. Rust, Go, Gcc, Clang, Java, C#, all fall into this category. I am not sure about Python, but I suspect companies like Google sponsored a lot of the work done in Python. Assuming that above is correct and that you will only have a handful of people who can contribute to core D - then it seems to me that the effort needs to be a) least wasteful, and b) highly focused. Right now, there are multiple implementations of D compiler - DMD, GDC, LDC, SDC - here you have a bunch of people who obviously have the time, the knowledge and the desire to develop D. Yet the effort is spread out into several different implementations, and therefore wasteful. Why not form a core group and settle on one implementation and everyone focus on that? I know this is very hard as no one would be willing to give up their creation, but for the greater good of D? Perhaps you could assess each implementation and settle on the one that has the most technical merit and future proofing? As a D user who wishes to use D as a better C / C++ - my personal needs are following: a) D should work on the three major platforms - Windows, Linux and OSX. b) It should be possible to write code in D that one would have written in C / C++ - i.e. let the programmer have full control. c) A good debugger on all supported platforms is essential for any complex language. d) A good IDE is essential to attract users accustomed to Eclipse, IntelliJ, Visual Studio. e) A core library that handles the most basic stuff. f) Ability to easily import C libraries. I struggled with htod - haven't tried dstep yet - but implementing tooling based on Clang seems sensible. The need to have a good standard GUI toolkit is not so great these days as users are moving away from Desktop applications. I realise that interfacing with C++ seems like a big goal - but to be honest this isn't important to me. C++ isn't the standard for cross language interfacing ... C is. Regards Dibyendu
Jan 25
parent Joakim <dlang joakim.fea.st> writes:
On Monday, 25 January 2016 at 18:11:24 UTC, Dibyendu Majumdar 
wrote:
 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
 wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei
Hi, I am new to D, and having my own language implementation (based off Lua) - therefore I think I can appreciate some of the difficulties around getting more contributors to D. For what its worth below are some thoughts on the H1 2016 priorities. I am a would be D user - D is a tool that should help me get my job done. I guess the vast majority of potential users are in this bracket. To become a contributor requires one of the following - a) it must be your day job, i.e. someone paying you to work on the language, or b) you happen to have lots of free time and deeply interested in D's development, plus have the skills needed to contribute to D. I think that getting contributors to the core of D is going to be difficult. Most other languages/compilers that have big list of contributors usually have one or more large organisations funding the people working on the language. Rust, Go, Gcc, Clang, Java, C#, all fall into this category. I am not sure about Python, but I suspect companies like Google sponsored a lot of the work done in Python. Assuming that above is correct and that you will only have a handful of people who can contribute to core D - then it seems to me that the effort needs to be a) least wasteful, and b) highly focused. Right now, there are multiple implementations of D compiler - DMD, GDC, LDC, SDC - here you have a bunch of people who obviously have the time, the knowledge and the desire to develop D. Yet the effort is spread out into several different implementations, and therefore wasteful. Why not form a core group and settle on one implementation and everyone focus on that? I know this is very hard as no one would be willing to give up their creation, but for the greater good of D? Perhaps you could assess each implementation and settle on the one that has the most technical merit and future proofing?
dmd, gdc, and ldc already share a common frontend. Walter, the main dmd developer, will never look at the llvm or gcc backends for legal reasons; the gcc devs likely won't touch anything that's not GPL; and the ldc devs likely prefer the license or implementation of llvm. I'm not sure what motivates the sdc devs, but it's likely having a frontend written in D itself that is focused on being easily used as a library, which dmd's recently translated D frontend isn't. Other than sdc, I doubt there's actually much code duplication going on, so I don't think this redundancy hurts.
 As a D user who wishes to use D as a better C / C++ - my 
 personal needs are following:

 a) D should work on the three major platforms - Windows, Linux 
 and OSX.
 b) It should be possible to write code in D that one would have 
 written in C / C++ - i.e. let the programmer have full control.
 c) A good debugger on all supported platforms is essential for 
 any complex language.
 d) A good IDE is essential to attract users accustomed to 
 Eclipse, IntelliJ, Visual Studio.
 e) A core library that handles the most basic stuff.
 f) Ability to easily import C libraries. I struggled with htod 
 - haven't tried dstep yet - but implementing tooling based on 
 Clang seems sensible.
I don't think there has ever been a language that would fulfill all these requirements, let alone an OSS one that was available free of charge. D gets you some of the way, but it cannot grant you all your wishes.
 The need to have a good standard GUI toolkit is not so great 
 these days as users are moving away from Desktop applications.
Yeah, a couple toolkits in dub is fine.
 I realise that interfacing with C++ seems like a big goal - but 
 to be honest this isn't important to me. C++ isn't the standard 
 for cross language interfacing ... C is.
Which is why D long didn't support interfacing with C++. But the leadership feels there is some untapped market out there that will warm to D once it can interface with C++ better, and I avoid C++ like the plague so I can't say if that's true or not. I know that I personally don't care for such C++ integration- nor do many in the D community, or they wouldn't be using D already- but those who do seem to have their ear for now.
Jan 25
prev sibling next sibling parent reply Tofu Ninja <emmons0 purdue.edu> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
Just out of curiosity, is getting the different compilers in sync still a priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066.
Jan 29
parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" <
digitalmars-d-announce puremagic.com> wrote:
 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
Just out of curiosity, is getting the different compilers in sync still a
priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066. If anyone wants to help out... I have to also juggle working on GCC and GDB. :-) When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect it to stay there for a while...
Jan 29
parent reply Tofu Ninja <emmons0 purdue.edu> writes:
On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote:
 On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" 
 < digitalmars-d-announce puremagic.com> wrote:
 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei 
 Alexandrescu wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- 
 Andrei
Just out of curiosity, is getting the different compilers in sync still a
priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066. If anyone wants to help out... I have to also juggle working on GCC and GDB. :-) When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect it to stay there for a while...
It would be nice if keeping them in sync was a priority, I would love to use GDC so I could use GDB, but not having the latest fixes is simply not worth it. Even simple things dont work when you go back just a few versions, like in 2.066 isForwardRange is not correct and does not work properly, something as simple as that does not work. Not to mention using the new stuff like allocators.
Jan 29
parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 29 January 2016 at 21:14, Tofu Ninja via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Friday, 29 January 2016 at 18:13:21 UTC, Iain Buclaw wrote:

 On 29 Jan 2016 6:55 pm, "Tofu Ninja via Digitalmars-d-announce" <
 digitalmars-d-announce puremagic.com> wrote:

 On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu wrote:

 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
Just out of curiosity, is getting the different compilers in sync still a
priority? Right now we have dmd at 2.070, ldc at 2.068. and gdc at 2.066. If anyone wants to help out... I have to also juggle working on GCC and GDB. :-) When gdc reaches 2.068 (GCC 7.1 is the target release next year) - expect it to stay there for a while...
It would be nice if keeping them in sync was a priority, I would love to use GDC so I could use GDB, but not having the latest fixes is simply not worth it. Even simple things dont work when you go back just a few versions, like in 2.066 isForwardRange is not correct and does not work properly, something as simple as that does not work. Not to mention using the new stuff like allocators.
How much of it actually depends on the compiler though? I'd be a little surprised if we couldn't backport at least 80% of phobos to 2.067/2.068 with zero changes.
Jan 29
parent reply Tofu Ninja <emmons0 purdue.edu> writes:
On Friday, 29 January 2016 at 20:30:35 UTC, Iain Buclaw wrote:
 How much of it actually depends on the compiler though?  I'd be 
 a little surprised if we couldn't backport at least 80% of 
 phobos to 2.067/2.068 with zero changes.
I have no idea, I think you are probably right. But having a compiler and phobos out of sync sounds even worse than the way it is now. A better solution for me would be to just stick with a version and wait for gdc to catch up but honestly it seems like as soon as a new version comes out I hit some bug that is only fixed in the latest version, forcing me to upgrade. For example this literally happened days ago, I am currently at 2.069 and the other day I needed to call some winapi stuff, only to realize the winapi bindings are way outdated, well guess what they are updated in 2.070. Its amazing how often I hit a problem and then find out its fixed in the next version.
Jan 29
parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 29 January 2016 at 22:29, Tofu Ninja via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Friday, 29 January 2016 at 20:30:35 UTC, Iain Buclaw wrote:

 How much of it actually depends on the compiler though?  I'd be a little
 surprised if we couldn't backport at least 80% of phobos to 2.067/2.068
 with zero changes.
I have no idea, I think you are probably right. But having a compiler and phobos out of sync sounds even worse than the way it is now. A better solution for me would be to just stick with a version and wait for gdc to catch up but honestly it seems like as soon as a new version comes out I hit some bug that is only fixed in the latest version, forcing me to upgrade. For example this literally happened days ago, I am currently at 2.069 and the other day I needed to call some winapi stuff, only to realize the winapi bindings are way outdated, well guess what they are updated in 2.070. Its amazing how often I hit a problem and then find out its fixed in the next version.
I know, I've been hitting bug after bug in 2.067, and the answer has always been to backport from 2.068. I already have backported druntime's object.d from 2.068 because 2.067's object module has drifted so far out of sync with it's hidden implementation, I couldn't build anything! So I might as well backport the rest of the druntime library. Nothing much has changed as it was a "bugfix" release. Iain.
Jan 31
parent reply Daniel Murphy <yebbliesnospam gmail.com> writes:
On 1/02/2016 8:46 AM, Iain Buclaw via Digitalmars-d-announce wrote:
 I know, I've been hitting bug after bug in 2.067, and the answer has always
 been to backport from 2.068.  I already have backported druntime's object.d
 from 2.068 because 2.067's object module has drifted so far out of sync
 with it's hidden implementation, I couldn't build anything!  So I might as
 well backport the rest of the druntime library.  Nothing much has changed
 as it was a "bugfix" release.
The process will be complete when you've backported the entirety of 2.068.
Feb 01
parent David Nadlinger <code klickverbot.at> writes:
On Monday, 1 February 2016 at 11:42:54 UTC, Daniel Murphy wrote:
 The process will be complete when you've backported the 
 entirety of 2.068.
From what I recall, 2.068 was fairly painless to merge anyway compared to other releases. — David
Feb 01
prev sibling parent Jon D <jond noreply.com> writes:
On Monday, 25 January 2016 at 02:37:40 UTC, Andrei Alexandrescu 
wrote:
 Hot off the press! http://wiki.dlang.org/Vision/2016H1 -- Andrei
A couple comments: a) No mention of targeting increased organizational participation (academic, corporate, etc). Not trying to suggest it should or shouldn't be a goal. Just that if it is goal meaningful effort will be directed toward in H1 then it'd be worth including in the writeup. b) More specificity in the roadmap and priorities, to the extent they are known - As a potential D adopter, it'd be useful to have better insight into where the language might be a year or two out. For example, what forms of C++ integration might be available, or if the major components of the standard library are likely to be available nogc. However, it's hard to discern this from the writeup. Perhaps in many cases it would be premature to establish such goals, but to the extent there has been concrete thought it'd be useful to write it up. This comment is similar to a number of others suggesting a preference for more concrete goals. --Jon
Jan 29