Re: Vision document for H2 2016

[rikki cattermole via Digitalmars-d-announce]

On 09/07/2016 5:08 AM, Andrei Alexandrescu wrote:

On 07/08/2016 12:00 AM, rikki cattermole wrote:

On 08/07/2016 7:55 AM, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


We really need opRef* implemented in dmd.


What is that? -- Andrei


As in your solution to ref counting.
We have already discussed this :)

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 7/8/16 6:36 PM, Carl Vogel wrote:

On Thursday, 7 July 2016 at 19:56:29 UTC, Andrei Alexandrescu wrote:

On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


Please provide feedback. We'll make a couple more passes before this
is complete. Thanks! -- Andrei


This list is full of good and worthy stuff, but is very long.


It's the right length. It includes things we actively work on along with 
a few items we keep an eye on and others we believe are important and 
count on other folks to be on. -- Andrei

Re: BulletD needs your help!

[BLM768 via Digitalmars-d-announce]

On Friday, 8 July 2016 at 07:59:42 UTC, Dechcaudron wrote:

Hey there,

I'm sad this post hasn't called anyone's attention so far. 
While I am defintely interested to have BulletD become a thing, 
I sadly can't collaborate with it so far. It's been on my mind 
to give Bullet as a physics engine a try for videogame 
development for a good year now, and I've only been using D for 
the last two months. Reality is I don't have any actual 
experience working with Bullet itself, so I don't really see 
how my input in the project could be valuable.


Aside from the issues I mentioned, the only major issue left is 
to fill in the many "holes" in the bindings, so if you end up 
using BulletD at some point (assuming I can get it back off the 
ground), just file an issue on the GitHub page for anything 
that's missing. That makes it easier to focus development efforts.


Still, I believe that for D to be taken into consideration by 
the general programming community we defintely need to have as 
many libraries as possible, covering as many topics as we can. 
I don't know if we have any other general-purpose physics 
library though.


Derelict includes a binding to the Open Dynamics Engine, which is 
a fairly capable engine. Last time I checked, though, Bullet was 
somewhat better.


You have my +1 for trying, and I really hope the community 
notices this project.


Thanks!

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Friday, 8 July 2016 at 12:17:29 UTC, Rene Zwanenburg wrote:

On Friday, 8 July 2016 at 11:32:10 UTC, Stefan Koch wrote:
I forgot to mention I posted a short article about the CTFE 
design on my blog.

https://codesoldier.blogspot.com

Feel free to comment or give suggestions.


Thanks! Posts like these are always interesting to read. I 
noticed a few mistakes:


I have been working a rewrite -> I have been working on a 
rewrite

complicated corer-case -> complicated corner-case
that have to handled correctly -> that have to be handled 
correctly

a cononical from -> a canonical from


I addressed the spelling mistakes.
Thanks for pointed them out.
Also more complex SwitchStatements work now.

Re: Vision document for H2 2016

[Carl Vogel via Digitalmars-d-announce]

On Thursday, 7 July 2016 at 19:56:29 UTC, Andrei Alexandrescu 
wrote:

On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


Please provide feedback. We'll make a couple more passes before 
this is complete. Thanks! -- Andrei


This list is full of good and worthy stuff, but is very long. 
Most of this won't be done in 2H16, so calling these "2H16 
priorities" is misleading, and doesn't give a good impression. 
For someone who really know where the language is headed, there's 
no sense of what will really be done in the next six months, what 
is in progress and might be done, and what stuff is just wishful 
thinking. The fact that so much is just copied over from last 
half says it all.


Some of these, especially the marketing, are evergreen tasks. 
("Promote books and articles"). If there's something concrete you 
have in mind for 2H16 say it, otherwise, it belongs somewhere 
else.


This is a really good long-term vision list, and it might be 
better labeled that, with different items slated for expected 
realization (2H16, 1H17, "Who knows?"), etc. (Links to associated 
bug reports would be useful too, so we know what's being worked 
on.)


In general, I feel like a list like this should actually be 
achievable. There's a silly, but still useful, business thing 
called "S.M.A.R.T." goals: Specific, Measurable, Attainable, 
Realistic, and Timely. This ain't that.

Re: Vision document for H2 2016

[Karabuta via Digitalmars-d-announce]

On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu 
wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


Promote video tutorials? :)

Re: First dmd nightly shipping with dub

[Martin Nowak via Digitalmars-d-announce]

On 07/08/2016 11:22 AM, Dicebot wrote:
> On Friday, 8 July 2016 at 09:13:08 UTC, Martin Nowak wrote:
>> What would be the use-case for those? Using newer dub versions with an
>> older compiler?
> 
> Or simply using dub with ldc/gdb without also installing dmd.

That actually indicates that shipping dub with dmd isn't that useful.
And I might also need a separate dub binary for the install.sh script
and Travis-Ci.
Not sure if Söhnke still wants to maintain the old release process, but
we could definitely extract the dub binaries from the dmd releases and
upload them to code.dlang.org/download.

-Martin

Re: Vision document for H2 2016

[Walter Bright via Digitalmars-d-announce]

On 7/8/2016 7:01 AM, Eugene wrote:

please add some features from Rust: primitive type aliases, like i8, u8, u32,
and so on


http://dlang.org/phobos/core_stdc_stdint.html

Re: Vision document for H2 2016

[Walter Bright via Digitalmars-d-announce]

On 7/8/2016 6:51 AM, Robert M. Münch wrote:

1. Fixing (all) bugs before doing new things: If I look as a CTO, CIO or CEO on
D I the first thing I ask is: "Are they doing a lot of new stuff? And if, is
this thing / last releasae that bullet proof stable that there are not annoying
open issued?" Any other answer then "yes" would get my "no" to use D.


I have yet to find any engineering product in any field that doesn't have open 
issues. A more practical question is does the product deliver enough value to 
make up for its deficiencies.




3. How about a "D Master" online certificate? scrum.org is doing that. You have
to go through a pretty hard online exam and reach a certain point level to
become a "Certified Scrum Master". Yes, it might be a bit early to think about
his line, but IMO better early then late. It just shows, that D is taking care
about all the non-technical stuff as well, which is a decision point for 
companies.


It's a great idea, do you want to work on it?

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


I have integrated 
https://wiki.dlang.org/Walter_Andrei_Action_List#Walter_and_Andrei.27s_Action_List 
within https://wiki.dlang.org/Vision/2016H2.



Andrei

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/08/2016 01:04 PM, Jack Stouffer wrote:

On Friday, 8 July 2016 at 16:55:54 UTC, Andrei Alexandrescu wrote:

I think the most important concrete step is to find more reviewers,
which is already in the document. As to how to do that, I'm not sure.
-- Andrei


To be blunt, the vision (and goals in general) are kind of useless
without a plan to achieve them.


They are useful in the sense that people may see the goal and come up 
with their own ideas on how to achieve it. -- Andrei

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/08/2016 12:04 PM, Andrew Godfrey wrote:

1) A link to that action list, placing it in context relative to this
doc, and encouraging people to add their ideas like "rust aliases" there
instead of here. (Or maybe you have a better place for this, like a
forum where such requests are discussed first).


I'm all for a community-maintained wishlist linked from the vision 
document. Please initiate one.



2) A link to a longer-term vision doc. The question I posted recently in
"general", about the evolution of the language, is the kind of thing I
would want to see answered there. Another kind of thing is anything
"long term strategic" that isn't a priority right now - e.g. pain points
for new adopters that "we can't work on yet" (e.g. "there are 3
compilers, and many practitioners end up installing at least 2 of
them"). And generally, I'd like a place that sets long term
expectations, e.g. the rate of future deprecation of existing features
in the language and in Phobos.


I'm not sure what a longer term vision document would be. For me that's 
by definition http://dlang.org :o). -- Andrei

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/08/2016 09:51 AM, Robert M. Münch wrote:

1. Fixing (all) bugs before doing new things: If I look as a CTO, CIO or
CEO on D I the first thing I ask is: "Are they doing a lot of new stuff?
And if, is this thing / last releasae that bullet proof stable that
there are not annoying open issued?" Any other answer then "yes" would
get my "no" to use D.


This needs to be balanced with the zeroth thing you ask, which is: "how 
does it help us with our work better than the competition?" We're not 
working on many new things, but we do work on things that impact that 
question.



2. Case-Studies: Yes, we have a lot of projects and things going on etc.
However, beside the "audio plug-in" I'm not so much aware of any D
products. This even becomes harder to market if there are backend
use-case / success stories. I thin it makes sense to show, what D has
been used for, what the advantages are (faster, less cost, better
maintainability) and how to adopt it.


There are some. I'd love to see such.


3. How about a "D Master" online certificate? scrum.org is doing that.
You have to go through a pretty hard online exam and reach a certain
point level to become a "Certified Scrum Master". Yes, it might be a bit
early to think about his line, but IMO better early then late. It just
shows, that D is taking care about all the non-technical stuff as well,
which is a decision point for companies.


Will keep that in mind, although there's some stigma associated with this.


Andrei

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/08/2016 10:01 AM, Eugene wrote:

On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


please add some features from Rust: primitive type aliases, like i8, u8,
u32, and so on


No need. -- Andrei

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/08/2016 05:17 AM, Robert burner Schadek wrote:

On Thursday, 7 July 2016 at 20:44:05 UTC, Andrei Alexandrescu wrote:

On 7/7/16 3:55 PM, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


In the next pass I will integrate Walter_Andrei_Action_List


I'm quite underwhelmed by the Vision Document (VD). I think that is
because it is a biyearly VD, and IMO in half a year nothing really
visionary can be done for D (because D is already pretty awesome and
pushing the envelope takes a lot of time).


It seems to me six months is a sweet spot. Large companies such as 
Google and Facebook also use a six-months horizon because it's long 
enough to avoid micromanagement hysteria and short enough to be 
verifiable and accountable. Yes, I do have a vision for a longer 
horizon, but it's too vague to be useful - "D will be a major 
programming language by 2020".



Also I think, that you treat the Action_List as competition to the VD.


I consider it competition with other things that Walter and I need to 
worry about. Walter put it cleverly: you can't add more administration 
without administrators.


A semestrial vision document summarizing our outlook and intentions is 
about as much as we can bear. A very nice collaborator offered to help 
with the vision doc but got busy with other things. He had a good quip 
about us being always late with the vision updates: "If we worked at a 
company we'd be all fired."


My days in the past few months were as follows:

"I think I can do containers as well as I can do ranges, let me work on 
that."


"Container nomenclature is exploding! Cool, there's this great Big-O 
attributes idea on the forum, let me write a library for it"


"Crap, DConf stuff DConf stuff DConf stuff"

"Hey, let's start with a simple container so how about RCStr"

"Urgh, more conferences and gigs but hey it's for the sake of D and the 
Foundation coffers"


"Argh, Foundation taxes are due"

"Oops, can't let checkedint happen but I can't criticize without 
proposing an alternative so forget RCStr and let me work on that"


"Argh, I need to work on the nonprofit application"

"Uhm, here's the lawyer review with questions about the nonprofit 
application"


"Ehm, here's the accountant review with more questions about the 
nonprofit application"


"Yowzers, it's July 5th and we're late with the vision document"

And so it goes. (Don't even get me started about email.) There are days 
at the end of which I realize I've been spinning my wheels but got not 
one line of code written. I'm not complaining, it comes with the 
territory! Administering one more document? I'd rather avoid it.



If you don't, even better but consider this:

You create a VD roughly twice a year. You have to compare it with the
last VD and see what was done. That is a lot of overhead IMO.


Tracking of past performance in comparison with the plan is probably the 
best and single most important thing about the Vision documents. If we 
just issued some thoughts every six months and then let them flap in the 
wind, no tracking no care no nothing - how would that be any better?



Why not create "THE VISION DOCUMENT" and update it when needed.


It seems the kind of document you're thinking of is a webpage.


You
would be able to add long term visions like "Awesome Container Library
using Allocators", then add subpoints to it like "Create
Allocator library" (strikethrough because it is already
done). We could then link the relevant forum threads to the points and
subpoints, discussing the work item.


Would trello help with that kind of stuff?


People would have a go to place
looking for pre-approved work. Leading to no more gatekeeper rejection
frustration.


I don't think preapproved work would lead to less rejection. Rejection 
is of work of insufficient quality, not of work that has not been 
preapproved. Conversely, preapproval does not guarantee any work will be 
actually approaved.



Additionally, I think that the vision for phobos is really weak, no
mentions of containers, xml, (si)-units, unit-testing (framework),
benchmarking, blas, json ... .


Added.


I'm not the much in the DMD process, but what about making the frontend
a library and being able to select the backend at the time of
compilation, as shortly mentioned at DConf. I bet there are a lot of
subpoints to that as well.


Added.


Thanks!

Andrei

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/08/2016 12:00 AM, rikki cattermole wrote:

On 08/07/2016 7:55 AM, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


We really need opRef* implemented in dmd.


What is that? -- Andrei

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/08/2016 02:54 AM, Johannes Pfau wrote:

Am Thu, 7 Jul 2016 15:55:51 -0400
schrieb Andrei Alexandrescu :


https://wiki.dlang.org/Vision/2016H2 -- Andrei




Safety and Memory Management


Btw: You said #15951 (Inefficiencies in struct initialization) is a
blocker for RCStr. I've started some basic optimizations in GDC, but we
can't merge this code as long as the spec doesn't even mention = void
initialized fields.

Would be great if you and or Walter could take the time to add 3-4
sentences to the spec answering these questions
https://issues.dlang.org/show_bug.cgi?id=15951#c4


We can address that but probably not part of the vision. -- Andrei

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/07/2016 06:06 PM, qznc wrote:

On Thursday, 7 July 2016 at 19:56:29 UTC, Andrei Alexandrescu wrote:

On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


Please provide feedback. We'll make a couple more passes before this
is complete. Thanks! -- Andrei


Wrt "Improve organization": I see a lot of potential in automating more
stuff.

* Have a bot for pinging reviewers like Facebook's mention-bot or Rust's
highfive

* Check various Phobos guidelines like "every function must have an
example"

* Use dfmt on Phobos (I know this is much bigger than it sounds)

* Compile all dub packages for testing

* Track performance and memory use

* Have a blog post about the automation we already have (autotester
deserves some applause once in while)

The nice thing about automating stuff is that it usually pays off the
investment in the long run. ;)


Done. Thanks! -- Andrei

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/07/2016 05:48 PM, Seb wrote:

On Thursday, 7 July 2016 at 19:56:29 UTC, Andrei Alexandrescu wrote:

On 07/07/2016 03:55 PM, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


Please provide feedback. We'll make a couple more passes before this
is complete. Thanks! -- Andrei


I agree that you should explain how it is planned to achieve "Raising
participation". Here's an idea:

[snip]

Added. Thanks! -- Andrei

Re: Vision document for H2 2016

[Jack Stouffer via Digitalmars-d-announce]

On Friday, 8 July 2016 at 16:55:54 UTC, Andrei Alexandrescu wrote:
I think the most important concrete step is to find more 
reviewers, which is already in the document. As to how to do 
that, I'm not sure. -- Andrei


To be blunt, the vision (and goals in general) are kind of 
useless without a plan to achieve them.

Re: Vision document for H2 2016

[Andrei Alexandrescu via Digitalmars-d-announce]

On 07/07/2016 04:39 PM, H. S. Teoh via Digitalmars-d-announce wrote:

On Thu, Jul 07, 2016 at 03:55:51PM -0400, Andrei Alexandrescu via 
Digitalmars-d-announce wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


Under "raising participation", are there any concrete steps that can be
taken to realize this goal? Given that last quarter we failed to achieve
the target number of PRs, it seems that specifying more concrete steps
would be a first step to actually reaching the goal, instead of merely
hoping things would somehow just come together.


I think the most important concrete step is to find more reviewers, 
which is already in the document. As to how to do that, I'm not sure. -- 
Andrei

Re: Vision document for H2 2016

[H. S. Teoh via Digitalmars-d-announce]

On Fri, Jul 08, 2016 at 09:17:14AM +, Robert burner Schadek via 
Digitalmars-d-announce wrote:
[...]
> I'm not the much in the DMD process, but what about making the
> frontend a library and being able to select the backend at the time of
> compilation, as shortly mentioned at DConf. I bet there are a lot of
> subpoints to that as well.

AFAICT this one is going to take a long time. The current DMD code is
quite volatile and internal APIs do change over time. Making it a
library would be great but if internals are exposed, it would become a
barrier to further development. I don't think we're at the point where
we're ready to actually work on this just yet.


T

-- 
Those who don't understand Unix are condemned to reinvent it, poorly.

Re: Vision document for H2 2016

[Andrew Godfrey via Digitalmars-d-announce]

On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu 
wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


I see that this thread has sparked a lot of "ideas for the 
future". That's a great outcome but many of them don't belong in 
this vision document, and in fact some probably deserve mention 
in the vision doc as "great ideas the leadership won't be funding 
yet - but feel free to drive it yourself if you feel passionate 
about it".


I think this is important because it would greatly raise 
satisfaction with the vision doc, if it was more clear "what it 
is not".


So I'm wondering if there are ways to improve the structure.

1) A link to that action list, placing it in context relative to 
this doc, and encouraging people to add their ideas like "rust 
aliases" there instead of here. (Or maybe you have a better place 
for this, like a forum where such requests are discussed first).


2) A link to a longer-term vision doc. The question I posted 
recently in "general", about the evolution of the language, is 
the kind of thing I would want to see answered there. Another 
kind of thing is anything "long term strategic" that isn't a 
priority right now - e.g. pain points for new adopters that "we 
can't work on yet" (e.g. "there are 3 compilers, and many 
practitioners end up installing at least 2 of them"). And 
generally, I'd like a place that sets long term expectations, 
e.g. the rate of future deprecation of existing features in the 
language and in Phobos.

Re: Vision document for H2 2016

[jmh530 via Digitalmars-d-announce]

On Friday, 8 July 2016 at 14:01:14 UTC, Eugene wrote:
On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu 
wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


please add some features from Rust: primitive type aliases, 
like i8, u8, u32, and so on


Not hard:

module stdrust;

alias i8 = byte;
alias u8 = ubyte;
alias i16 = short;
alias u16 = ushort;
alias i32 = int;
alias u32 = uint;
alias i64 = long;
alias u64 = ulong;
alias i128 = cent;
alias u128 = ucent;
alias f32 = float;
alias f64 = double;

Re: Vision document for H2 2016

[Eugene via Digitalmars-d-announce]

On Thursday, 7 July 2016 at 19:55:51 UTC, Andrei Alexandrescu 
wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


please add some features from Rust: primitive type aliases, like 
i8, u8, u32, and so on

Re: Vision document for H2 2016

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

On 2016-07-07 19:55:51 +, Andrei Alexandrescu said:


https://wiki.dlang.org/Vision/2016H2 -- Andrei



A more "business / managment" view:

If we want to achieve hihger adoption rate of D, which IMO should be 
the first priority as it's an enabler for a lot of the other things 
posted, the non-technical aspects are much more important.



1. Fixing (all) bugs before doing new things: If I look as a CTO, CIO 
or CEO on D I the first thing I ask is: "Are they doing a lot of new 
stuff? And if, is this thing / last releasae that bullet proof stable 
that there are not annoying open issued?" Any other answer then "yes" 
would get my "no" to use D.



2. Case-Studies: Yes, we have a lot of projects and things going on 
etc. However, beside the "audio plug-in" I'm not so much aware of any D 
products. This even becomes harder to market if there are backend 
use-case / success stories. I thin it makes sense to show, what D has 
been used for, what the advantages are (faster, less cost, better 
maintainability) and how to adopt it.



3. How about a "D Master" online certificate? scrum.org is doing that. 
You have to go through a pretty hard online exam and reach a certain 
point level to become a "Certified Scrum Master". Yes, it might be a 
bit early to think about his line, but IMO better early then late. It 
just shows, that D is taking care about all the non-technical stuff as 
well, which is a decision point for companies.



Just my 2c here...

--
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

Re: Vision document for H2 2016

[jmh530 via Digitalmars-d-announce]

On Friday, 8 July 2016 at 09:17:14 UTC, Robert burner Schadek 
wrote:


You create a VD roughly twice a year. You have to compare it 
with the last VD and see what was done. That is a lot of 
overhead IMO.

Why not create "THE VISION DOCUMENT" and update it when needed.


I like to think about it as a process. Even if it's not perfect, 
it forces them to sit down and think about what they've done and 
how they are reaching their goals.

Re: Battle-plan for CTFE

[Rene Zwanenburg via Digitalmars-d-announce]

On Friday, 8 July 2016 at 11:32:10 UTC, Stefan Koch wrote:
I forgot to mention I posted a short article about the CTFE 
design on my blog.

https://codesoldier.blogspot.com

Feel free to comment or give suggestions.


Thanks! Posts like these are always interesting to read. I 
noticed a few mistakes:


I have been working a rewrite -> I have been working on a rewrite
complicated corer-case -> complicated corner-case
that have to handled correctly -> that have to be handled 
correctly

a cononical from -> a canonical from

Re: Battle-plan for CTFE

[Stefan Koch via Digitalmars-d-announce]

On Thursday, 7 July 2016 at 17:47:28 UTC, Stefan Koch wrote:

On Thursday, 7 July 2016 at 13:55:44 UTC, Stefan Koch wrote:


I just made a PR to fix it for ctfe.
It's a hack but then again ...
The whole handling of PowExp is a hack.


Clarification now it works on Literals.
It is still not available at ctfe and the full non-hackish fix 
will take a while.


I forgot to mention I posted a short article about the CTFE 
design on my blog.

https://codesoldier.blogspot.com

Feel free to comment or give suggestions.

Re: First dmd nightly shipping with dub

[Dicebot via Digitalmars-d-announce]

On Friday, 8 July 2016 at 09:13:08 UTC, Martin Nowak wrote:
What would be the use-case for those? Using newer dub versions 
with an older compiler?


Or simply using dub with ldc/gdb without also installing dmd.

Re: Vision document for H2 2016

[Robert burner Schadek via Digitalmars-d-announce]

On Thursday, 7 July 2016 at 20:44:05 UTC, Andrei Alexandrescu 
wrote:

On 7/7/16 3:55 PM, Andrei Alexandrescu wrote:

https://wiki.dlang.org/Vision/2016H2 -- Andrei


In the next pass I will integrate Walter_Andrei_Action_List


I'm quite underwhelmed by the Vision Document (VD). I think that 
is because it is a biyearly VD, and IMO in half a year nothing 
really visionary can be done for D (because D is already pretty 
awesome and pushing the envelope takes a lot of time).


Also I think, that you treat the Action_List as competition to 
the VD. If you don't, even better but consider this:


You create a VD roughly twice a year. You have to compare it with 
the last VD and see what was done. That is a lot of overhead IMO.
Why not create "THE VISION DOCUMENT" and update it when needed. 
You would be able to add long term visions like "Awesome 
Container Library using Allocators", then add subpoints to it 
like "Create Allocator library" 
(strikethrough because it is already done). We could then link 
the relevant forum threads to the points and subpoints, 
discussing the work item. People would have a go to place looking 
for pre-approved work. Leading to no more gatekeeper rejection 
frustration.


Additionally, I think that the vision for phobos is really weak, 
no mentions of containers, xml, (si)-units, unit-testing 
(framework), benchmarking, blas, json ... .
I'm not the much in the DMD process, but what about making the 
frontend a library and being able to select the backend at the 
time of compilation, as shortly mentioned at DConf. I bet there 
are a lot of subpoints to that as well.

Re: First dmd nightly shipping with dub

[Martin Nowak via Digitalmars-d-announce]

On Wednesday, 6 July 2016 at 14:32:45 UTC, Dejan Lekic wrote:

Good work!
I presume the "independent" dub packages will also be 
available, right?


What would be the use-case for those? Using newer dub versions 
with an older compiler?

Re: BulletD needs your help!

[Dechcaudron via Digitalmars-d-announce]

On Monday, 4 July 2016 at 20:03:45 UTC, BLM768 wrote:

Thoughts? Concerns? Tomatoes?


Hey there,

I'm sad this post hasn't called anyone's attention so far. While 
I am defintely interested to have BulletD become a thing, I sadly 
can't collaborate with it so far. It's been on my mind to give 
Bullet as a physics engine a try for videogame development for a 
good year now, and I've only been using D for the last two 
months. Reality is I don't have any actual experience working 
with Bullet itself, so I don't really see how my input in the 
project could be valuable.


Still, I believe that for D to be taken into consideration by the 
general programming community we defintely need to have as many 
libraries as possible, covering as many topics as we can. I don't 
know if we have any other general-purpose physics library though.


I currently don't have the time to get hands down into the 
project, but I might start learning about Bullet pretty soon. 
When that happens, I will let you know to see if I'm of any use 
in the project. Thanks for trying to make it happen, man.


You have my +1 for trying, and I really hope the community 
notices this project.


Cheers!

Re: Vision document for H2 2016

[Johannes Pfau via Digitalmars-d-announce]

Am Thu, 7 Jul 2016 15:55:51 -0400
schrieb Andrei Alexandrescu :

> https://wiki.dlang.org/Vision/2016H2 -- Andrei


> Safety and Memory Management
 
Btw: You said #15951 (Inefficiencies in struct initialization) is a
blocker for RCStr. I've started some basic optimizations in GDC, but we
can't merge this code as long as the spec doesn't even mention = void
initialized fields.

Would be great if you and or Walter could take the time to add 3-4
sentences to the spec answering these questions
https://issues.dlang.org/show_bug.cgi?id=15951#c4