Re: GDC Explorer Site Update

[Iain Buclaw via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 02:44:56 UTC, maik klein wrote:

On Monday, 25 January 2016 at 23:08:32 UTC, Iain Buclaw wrote:

Hi,

After a much needed rebuild of the server running various 
GDC-related hosted services 
[http://forum.dlang.org/post/zrnqcfhvyhlfjajtq...@forum.dlang.org] - I've gotten round to updating the compiler disassembler.


http://explore.dgnu.org/

Now supports 12 different architectures from ARM to SystemZ! 
(not including -m32 or any -march options)


Enjoy.
Iain.


This is awesome, I think I am going to use this to finally 
learn some assembly. But I am not quite sure though what the 
output is, is it x86 or x64?


The first is x64. You can switch to x86 using -m32.  However I 
could just add an extra compiler to do this automatically.


Iain.

Re: DlangIDE update

[Kapps via Digitalmars-d-announce]

On Monday, 25 January 2016 at 20:00:57 UTC, Basile B. wrote:
On Tuesday, 8 December 2015 at 15:58:43 UTC, Vadim Lopatin 
wrote:

- integration of DML GUI builder (Delphi like)


Can you explain me how do you think it can be done while there 
is even no official object streaming for D ?


Just one thing: "@widget" is not enough.

I don't know how to explain you the problem. But let's say you 
have an object inspector that displays the properties of an 
object. The D way doesn't work (templates). You won't be able 
to assign an untyped Object to an inspector if your object 
doesn't store runtime informations. It's just impossible. 
Furthemore properties are not just for the visual things...


You won't be able to make a good run-time designer "à la 
Delphi" until the D standard library gets a serialization 
library. And when this will happen, you won't be able to use 
this serialization library because it won't work at run-time 
(object inspectors, property bindings, etc.).


It won't work.

Just register the metadata for the control types.
I use 
https://shardsoft.com/stash/projects/SHARD/repos/shardtools/browse/source/ShardTools/Reflection.d and it seems to work fine, with the caveat that you have to do createMetadata!MyControl at some point (I generally do it in a mixin that all, in my case content processors, are supposed to include). Theoretically one could use rtInfo to make this automatic.

Re: Vision for the first semester of 2016

[Russel Winder via Digitalmars-d-announce]

On Tue, 2016-01-26 at 17:06 +1300, Rikki Cattermole via Digitalmars-d-
announce wrote:
> […]
> 
> 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.

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.

[…]
> 
> 2 years ago, but I can guarantee for students that go through that 
> 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.
 
[…]
> 
> 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.

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.
 
-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

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.

Re: GDC Explorer Site Update

[Iain Buclaw via Digitalmars-d-announce]

On Tuesday, 26 January 2016 at 06:01:52 UTC, Rory McGuire wrote:
On Tue, Jan 26, 2016 at 1:08 AM, Iain Buclaw via 
Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> 
wrote:



Hi,

After a much needed rebuild of the server running various 
GDC-related hosted services [ 
http://forum.dlang.org/post/zrnqcfhvyhlfjajtq...@forum.dlang.org] - I've gotten round to updating the compiler disassembler.


http://explore.dgnu.org/

Now supports 12 different architectures from ARM to SystemZ! 
(not including -m32 or any -march options)


Enjoy.
Iain.



Nice, is there a _best_ resource to understand the parameters, 
e.g. what is (%rip) after a symbol name?


Not sure of any precise resource.  However this explains the need 
for %rip 
https://www.technovelty.org/c/position-independent-code-and-x86-64-libraries.html

Re: GDC Explorer Site Update

[Rory McGuire via Digitalmars-d-announce]

On Tue, Jan 26, 2016 at 1:08 AM, Iain Buclaw via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> Hi,
>
> After a much needed rebuild of the server running various GDC-related
> hosted services [
> http://forum.dlang.org/post/zrnqcfhvyhlfjajtq...@forum.dlang.org] - I've
> gotten round to updating the compiler disassembler.
>
> http://explore.dgnu.org/
>
> Now supports 12 different architectures from ARM to SystemZ! (not
> including -m32 or any -march options)
>
> Enjoy.
> Iain.
>

Nice, is there a _best_ resource to understand the parameters, e.g. what is
(%rip) after a symbol name?

Re: Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[maik klein via Digitalmars-d-announce]

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  
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

Re: Vision for the first semester of 2016

[Andrew Edwards via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Rory McGuire via Digitalmars-d-announce]

On Mon, Jan 25, 2016 at 2:46 PM, Andrei Alexandrescu via
Digitalmars-d-announce  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.

Re: Vision for the first semester of 2016

[JohnCK via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Joakim via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[JohnCK via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Russel Winder via Digitalmars-d-announce]

On Mon, 2016-01-25 at 15:47 +, jmh530 via Digitalmars-d-announce
wrote:
> 
[…]
> 
> 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…

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.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Russel Winder via Digitalmars-d-announce]

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?

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.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Vision for the first semester of 2016

[Dicebot via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Rory McGuire via Digitalmars-d-announce]

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 +, jmh530 via Digitalmars-d-announce
> wrote:
> >
> […]
> >
> > 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…
>
> 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.
>
=
> Dr Russel Winder  t: +44 20 7585 2200   voip:
sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@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...

?

Re: Vision for the first semester of 2016

[Dibyendu Majumdar via Digitalmars-d-announce]

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

Re: Vision for the first semester of 2016

[Iain Buclaw via Digitalmars-d-announce]

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 :-)

Re: Vision for the first semester of 2016

[Andrew Edwards via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Jacob Carlborg via Digitalmars-d-announce]

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

Re: Ever want to compile D on your Android phone? Well, now you can!

[Sebastiaan Koppe via Digitalmars-d-announce]

Wow! Keep up the good work.

GDC Explorer Site Update

[Iain Buclaw via Digitalmars-d-announce]

Hi,

After a much needed rebuild of the server running various 
GDC-related hosted services 
[http://forum.dlang.org/post/zrnqcfhvyhlfjajtq...@forum.dlang.org] - I've gotten round to updating the compiler disassembler.


http://explore.dgnu.org/

Now supports 12 different architectures from ARM to SystemZ! (not 
including -m32 or any -march options)


Enjoy.
Iain.

Re: Vision for the first semester of 2016

[Rory McGuire via Digitalmars-d-announce]

On Mon, Jan 25, 2016 at 9:34 AM, Rikki Cattermole via
Digitalmars-d-announce  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.

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

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 > 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  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.

Re: Vision for the first semester of 2016

[Robert M. Münch via Digitalmars-d-announce]

On 2016-01-25 07:03:35 +, 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. Münch
http://www.saphirion.com
smarter | better | faster

Re: Vision for the first semester of 2016

[Rory McGuire via Digitalmars-d-announce]

On Mon, Jan 25, 2016 at 10:31 AM, Rikki Cattermole via
Digitalmars-d-announce  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 > > 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  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?

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

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 > 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 
>> 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 
 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

Re: Vision for the first semester of 2016

[Rikki Cattermole via Digitalmars-d-announce]

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.

Re: Vision for the first semester of 2016

[Jacob Carlborg via Digitalmars-d-announce]

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

Re: Beta D 2.070.0-b2

[John Colvin via Digitalmars-d-announce]

On Sunday, 17 January 2016 at 20:52:20 UTC, Martin Nowak wrote:

Second and last beta for the 2.070.0 release.

http://dlang.org/download.html#dmd_beta 
http://dlang.org/changelog/2.070.0.html


Please report any bugs at https://issues.dlang.org

-Martin


% dmd --version
DMD64 D Compiler v2.069
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

should be

DMD64 D Compiler v2.070
Copyright (c) 1999-2016 by Digital Mars written by Walter Bright

New DCD and dfmt betas

[Brian Schott via Digitalmars-d-announce]

https://github.com/Hackerpilot/dfmt/releases/tag/v0.5.0-beta2

This version of dfmt includes several whitespace and indentation 
fixes. There is also some fine-tuning in the line wrap 
calculation algorithm and a new option to control the formatting 
of template constraints. Bash-completion scripts are also new in 
this release.


https://github.com/Hackerpilot/DCD/releases/tag/v0.8.0-beta1

This version of DCD adds support for UNIX domain sockets to 
Mac/Linux/BSD builds. I also included some bash-completion 
scripts for the client and server commands.


A reminder: the announce mailing list is not a bug tracker, 
please file problems you encounter on Github.

Re: GDC Explorer Site Update

[maik klein via Digitalmars-d-announce]

On Monday, 25 January 2016 at 23:08:32 UTC, Iain Buclaw wrote:

Hi,

After a much needed rebuild of the server running various 
GDC-related hosted services 
[http://forum.dlang.org/post/zrnqcfhvyhlfjajtq...@forum.dlang.org] - I've gotten round to updating the compiler disassembler.


http://explore.dgnu.org/

Now supports 12 different architectures from ARM to SystemZ! 
(not including -m32 or any -march options)


Enjoy.
Iain.


This is awesome, I think I am going to use this to finally learn 
some assembly. But I am not quite sure though what the output is, 
is it x86 or x64?