Re: What are the worst parts of D?

[Atila Neves via Digitalmars-d]

On Thursday, 25 September 2014 at 17:45:56 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 10:26 AM, Atila Neves wrote:
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg 
wrote:

On 25/09/14 09:38, Atila Neves wrote:

Here's one: having to manually generate the custom main file 
for
unittest builds. There's no current way (or at least there 
wasn't when I
brought it up in the dub forum) to tell it to autogenerate a 
D file from
a dub package and list it as a dependency of the unittest 
build.


Hmm, I haven't used Dub to run unit tests. Although, DMD has 
a "-main"

flag that adds an empty main function.


I don't want an empty main function. I want the main function 
and the

file it's in to be generated by the build system.


Why would be the focus on the mechanism instead of the needed 
outcome? -- Andrei


Because I don't use unittest blocks, I use my own library. The 
one thing it can't use the compiler for is discover what files 
are in a directory, so I need to generate the main function that 
calls into unit-threaded with a list of compile-time strings. 
What I need/want is that every time I add a new source file to 
the project, it gets auto-generated automatically and is a 
dependency of the unittest build in dub.


Atila

Re: What are the worst parts of D?

[Jacob Carlborg via Digitalmars-d]

On 25/09/14 13:08, Don wrote:


C-style declarations. Builtin sort and reverse. NCEG operators. Built-in
complex types. float.min. @property.


Let me add: base class protection. It's deprecated but not completely 
removed. I have never seen base class protection being used in practice.


--
/Jacob Carlborg

Re: D mention on developer.apple.com

[Jacob Carlborg via Digitalmars-d]

On 26/09/14 03:31, Michel Fortin wrote:

Maybe this will be of interest to someone. D was mentioned on the
official Swift Blog today:


Swift borrows a clever feature from the D language: these identifiers
expand to the location of the caller when evaluated in a default
argument list.


-- Building assert() in Swift, Part 2: __FILE__ and __LINE__



Cool, I didn't know that.

--
/Jacob Carlborg

Re: [Semi OT] Language for Game Development talk

[Jacob Carlborg via Digitalmars-d]

On 25/09/14 21:59, Walter Bright wrote:


But I think it's a waste of time to develop a new language that has 98%
overlap with existing ones, like if I proposed a language just like C
but with member functions.


It seems that people won't switch language, or rather create a new 
language, even though an existing would fit them, just because the 
existing one lacks one feature. It's like "Yeah, D is great it has 9 of 
the features I need, but it lacks the 10th. Therefore I can't switch, 
even though the language I use now doesn't have any of these 10 features."


--
/Jacob Carlborg

Re: What are the worst parts of D?

[Vladimir Panteleev via Digitalmars-d]

On Friday, 26 September 2014 at 05:02:08 UTC, Andrei Alexandrescu 
wrote:

On 9/25/14, 9:05 PM, Vladimir Panteleev wrote:

On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via
Digitalmars-d wrote:

It's not just about performance.


Something I recently realized: because of auto-decoding,
std.algorithm.find("foo", 'o') cannot be implemented using 
memchr.


Why not? -- Andrei


Sorry, got mixed up. countUntil can't, find can (but because 
one's counting code points, they can't be implemented on top of 
each other, even for arrays).

Re: What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 9/25/14, 9:05 PM, Vladimir Panteleev wrote:

On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via
Digitalmars-d wrote:

It's not just about performance.


Something I recently realized: because of auto-decoding,
std.algorithm.find("foo", 'o') cannot be implemented using memchr.


Why not? -- Andrei

Re: What are the worst parts of D?

[Walter Bright via Digitalmars-d]

On 9/25/2014 9:04 PM, H. S. Teoh via Digitalmars-d wrote:

On Thu, Sep 25, 2014 at 08:11:02PM -0700, Walter Bright via Digitalmars-d wrote:

Consider this PR:

https://github.com/D-Programming-Language/phobos/pull/2423

which is blocked because several people do not agree with using
byCodeunit.


Actually, several committers have already agreed that this particular PR
shouldn't be blocked pending the decision whether to autodecode or not.
What's actually blocking it right now, is that it calls stripExtension,
which only works with arrays, not general ranges.  (Speaking of which,
thanks for reminding me that I need to work on that.  :-P)



It's blocked because of the autodecode issue. Don't want to need a THIRD 
setExtension algorithm because this one isn't done correctly.

Re: What are the worst parts of D?

[Ola Fosheim Grostad via Digitalmars-d]

On Friday, 26 September 2014 at 03:44:23 UTC, Andrei Alexandrescu 
wrote:
I think the way to break that stalemate is to add RC strings 
and reference counted exceptions. -- Andrei


I dont want gc, exceptions or rc strings. You really need to make 
sure rc is optional throughout. RC inc/dec abort 
read-transactions. That's a bad long term strategy.

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 09:34:30PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/25/2014 9:12 PM, Daniel Murphy wrote:
> >"Walter Bright"  wrote in message news:m02lt5$2hg4$1...@digitalmars.com...
> >
> >>I should add that this impasse has COMPLETELY stalled changes to
> >>Phobos to remove dependency on the GC.
> >
> >Maybe it would be more successful if it didn't try to do both at
> >once.
> 
> What would the 3rd version of setExtension be named, then?

I think that PR, and the others slated to follow it, should just merge
with autodecoding in conformance to the rest of Phobos right now,
independently of however the decision on the autodecoding issue will
turn out. If we do decide eventually to get rid of autodecoding, we're
gonna have to rewrite much of Phobos anyway, so it's not as though
merging PRs now is going to make it significantly worse. I don't see why
the entire burden of deciding upon autodecoding should rest upon a PR
that merely introduces a new string function.


T

-- 
Unix was not designed to stop people from doing stupid things, because that 
would also stop them from doing clever things. -- Doug Gwyn

Re: What are the worst parts of D?

[Daniel Murphy via Digitalmars-d]

"Walter Bright"  wrote in message news:m02qcm$2mmn$1...@digitalmars.com...


On 9/25/2014 9:12 PM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:m02lt5$2hg4$1...@digitalmars.com...
>
>> I should add that this impasse has COMPLETELY stalled changes to Phobos
to
>> remove dependency on the GC.
>
> Maybe it would be more successful if it didn't try to do both at once.

What would the 3rd version of setExtension be named, then?


setExtension.  Making up new clever names for functions that do the same 
thing with different types is a burden for the users. 

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Fri, Sep 26, 2014 at 04:05:18AM +, Vladimir Panteleev via Digitalmars-d 
wrote:
> On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >It's not just about performance.
> 
> Something I recently realized: because of auto-decoding,
> std.algorithm.find("foo", 'o') cannot be implemented using memchr. I
> think this points to a huge design fail, performance-wise.

Well, if you really want to talk performance, we've already failed. Any
string operation that starts from a narrow string and ends with a narrow
string (of the same width) will incur the overhead of decoding /
reencoding *every single character*, even if it's mostly redundant.

What bugs me even more is the fact that every single Phobos algorithm
that might conceivably deal with characters has to be special-cased for
narrow string in order to be performant. That's a mighty high price to
pay for what's a relatively small benefit -- note that autodecoding does
*not* guarantee Unicode correctness, even if, according to the argument
of some, it helps. So we're paying a high price in terms of performance
and code maintainability in Phobos, for the dubious benefit of only
partial Unicode conformance.


> There are also subtle correctness problems:
> haystack[0..haystack.countUntil(needle)] is wrong, even if it works
> right on ASCII input.
> 
> For once I agree with Walter Bright - regarding the chair throwing :)

Not to mention that autodecoding *still* doesn't fix the following
problem:

assert("á".canFind("á")); // fails

(Note: you may need to save this message verbatim and edit it into a D
source file to see this effect; cut-n-paste on some systems may erase
the effect.)

And the only way to fix this would be so prohibitively expensive, I
don't think even Andrei would agree to it. :-P

So basically, we're paying (1) lower performance, (2) non-random access
for strings, (3) subtle distinction between index and count and other
such gotchas, and (4) tons of special-cased Phobos code with the
associated maintenance costs, all for incomplete Unicode correctness.
Doesn't seem like the benefit measures up to the cost. :-(


T

-- 
We've all heard that a million monkeys banging on a million typewriters will 
eventually reproduce the entire works of Shakespeare.  Now, thanks to the 
Internet, we know this is not true. -- Robert Wilensk

Re: What are the worst parts of D?

[Walter Bright via Digitalmars-d]

On 9/25/2014 9:12 PM, Daniel Murphy wrote:

"Walter Bright"  wrote in message news:m02lt5$2hg4$1...@digitalmars.com...


I should add that this impasse has COMPLETELY stalled changes to Phobos to
remove dependency on the GC.


Maybe it would be more successful if it didn't try to do both at once.


What would the 3rd version of setExtension be named, then?

Re: What are the worst parts of D?

[Daniel Murphy via Digitalmars-d]

"Iain Buclaw"  wrote in message news:dqgkcmdmxekzqpvfb...@forum.dlang.org...

On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:


What do you think are the worst parts of D?




1) D Inline Assembler.


Relying on the system assembler sucks too.


7) Interfacing with C++
- A new set of features that is danger of falling into the same "let's get 
it working" pit.  First warning sign was C++ template mangling, then DMD 
gave up on mangling D 'long' in any predictable way.  It's all been 
downhill from there.


C++ template mangling is fine.  'long' mangling is messy, but it's better 
than what was there before.



8) Real
- What a pain.


Oh yeah.  D's one variable-sized type. 

Re: Crazy code by Adam on SO

[Shammah Chancellor via Digitalmars-d]

On 2014-08-29 16:48:51 +, Andrei Alexandrescu said:


Worth a look:

http://stackoverflow.com/questions/2329/d-finding-all-functions-with-certain-attribute 



Andrei


That's some pretty neat code, I did something similar awhile ago for 
deserializing classes.  Here's a reduced case of it:


http://dpaste.dzfl.pl/4fffa339368f

The facility to be able to create such a factory through compile time 
reflection is absolutely awesome.  However, it "feels" as though the 
ability to do this is making use of undefined behavior rather than 
actual language features.


First:

I consider it sort of a language wart that alias hack(alias T) = T; is 
necessary for aliasing to the particular symbol, and that the 
__traits(getMember) expression can't be substituted in to the same 
places as the alias to it without compiler errors.   It's very 
non-intuitive.  I would have never figured that out on my own with out 
some other D wizards helping me about a year ago.  I still don't 
understand why I can't simply do :

alias member = __traits(getMember, ...);

Also:

The way that the foreach works in the pasted example is very 
surprising.   I would be nice if this was a "static foreach" instead of 
just a foreach which happens to run at compile time over a TypeTuple.   
Normally doing a switch inside a foreach like that would not work at 
all, but near as I can tell the compiler unrolls the whole thing since 
it's inputs are known at compile time.


Finally:

If you actually want to have something that returns a TypeTuple!() of 
only subclasses which you can foreach over in other places -- you have 
to make a *very* ugly recursive template:


	(Line 208 thru Line 235 returns a TypeTuple of all subclasses of the 
Message class)



https://github.com/schancel/gameserver/blob/master/source/messages/core.d#L208

Making these awesome feature more intuitive and easy to use would go a 
long way.  I feel like this should be on your short list along with the 
GC and C++ compatibility.


-S.

Re: What are the worst parts of D?

[Daniel Murphy via Digitalmars-d]

"Walter Bright"  wrote in message news:m02lt5$2hg4$1...@digitalmars.com...

I should add that this impasse has COMPLETELY stalled changes to Phobos to 
remove dependency on the GC.


Maybe it would be more successful if it didn't try to do both at once. 

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 08:44:23PM -0700, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 9/25/14, 8:17 PM, Walter Bright wrote:
> >On 9/25/2014 8:11 PM, Walter Bright wrote:
> >>Consider this PR:
> >>
> >>https://github.com/D-Programming-Language/phobos/pull/2423
> >>
> >>which is blocked because several people do not agree with using
> >>byCodeunit.
> >>
> >
> >I should add that this impasse has COMPLETELY stalled changes to
> >Phobos to remove dependency on the GC.
> 
> I think the way to break that stalemate is to add RC strings and
> reference counted exceptions. -- Andrei

But it does nothing to bring us closer to a decision about the
autodecoding issue.


T

-- 
Heads I win, tails you lose.

Re: What are the worst parts of D?

[Vladimir Panteleev via Digitalmars-d]

On Thursday, 25 September 2014 at 21:49:43 UTC, H. S. Teoh via 
Digitalmars-d wrote:

It's not just about performance.


Something I recently realized: because of auto-decoding, 
std.algorithm.find("foo", 'o') cannot be implemented using 
memchr. I think this points to a huge design fail, 
performance-wise.


There are also subtle correctness problems: 
haystack[0..haystack.countUntil(needle)] is wrong, even if it 
works right on ASCII input.


For once I agree with Walter Bright - regarding the chair 
throwing :)

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 08:11:02PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/25/2014 2:47 PM, H. S. Teoh via Digitalmars-d wrote:
> >Not a bad idea. If we do it right, we could (mostly) avoid user
> >outrage.  E.g., start with a "soft deprecation" (a compile-time
> >message, but not an actual warning, to the effect that byCodeUnit /
> >byCodePoint should be used with strings from now on), then a warning,
> >then an actual deprecation, then remove autodecoding code from Phobos
> >algorithms (leaving only byCodePoint for those who still want
> >autodecoding).
> 
> Consider this PR:
> 
> https://github.com/D-Programming-Language/phobos/pull/2423
> 
> which is blocked because several people do not agree with using
> byCodeunit.

Actually, several committers have already agreed that this particular PR
shouldn't be blocked pending the decision whether to autodecode or not.
What's actually blocking it right now, is that it calls stripExtension,
which only works with arrays, not general ranges.  (Speaking of which,
thanks for reminding me that I need to work on that.  :-P)


T

-- 
The fact that anyone still uses AOL shows that even the presence of options 
doesn't stop some people from picking the pessimal one. - Mike Ellis

Re: What's blocking DDMD?

[Daniel Murphy via Digitalmars-d]

"Tourist"  wrote in message news:ekvdxwosqarmsnkhk...@forum.dlang.org... 


> Of the failing platforms:
> OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is 
> crazy)

...

So, this is fixed now, right?


Yep.

https://auto-tester.puremagic.com/?projectid=10

Just windows left now.

Re: Marrying bugzilla issues with git pull requests

[Daniel Murphy via Digitalmars-d]

"Andrew Edwards"  wrote in message news:m019d3$1tuj$1...@digitalmars.com...

Understood, but there is no way for me to actually identify THE pull 
request(s) that fix(es) an issue among the comments, even if pulls are 
placed in their own comments. There is always a chance that a linked 
comment is incorrect or that the pull didn't actually address the issue 
and was closed in favor of a better implemented solution (or simply closed 
with no alternative provided). At those times there are multiple links, 
and only some (or one) of them may actually apply.


Does the query have to be fast?  Once you have the potential pull request 
url, you could query github and look for the "fixes issue " etc in the 
commit messages that github greps for.  If they link back to the same 
bugzilla issue, chances are the link was correct.  Most pull requests will 
also have a link to the bugzilla issue in the description. 

Re: What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 9/25/14, 8:17 PM, Walter Bright wrote:

On 9/25/2014 8:11 PM, Walter Bright wrote:

Consider this PR:

https://github.com/D-Programming-Language/phobos/pull/2423

which is blocked because several people do not agree with using
byCodeunit.



I should add that this impasse has COMPLETELY stalled changes to Phobos
to remove dependency on the GC.


I think the way to break that stalemate is to add RC strings and 
reference counted exceptions. -- Andrei

Re: What are the worst parts of D?

[Walter Bright via Digitalmars-d]

On 9/25/2014 8:11 PM, Walter Bright wrote:

Consider this PR:

https://github.com/D-Programming-Language/phobos/pull/2423

which is blocked because several people do not agree with using byCodeunit.



I should add that this impasse has COMPLETELY stalled changes to Phobos to 
remove dependency on the GC.

Re: What are the worst parts of D?

[Walter Bright via Digitalmars-d]

On 9/25/2014 2:47 PM, H. S. Teoh via Digitalmars-d wrote:

Not a bad idea. If we do it right, we could (mostly) avoid user outrage.
E.g., start with a "soft deprecation" (a compile-time message, but not
an actual warning, to the effect that byCodeUnit / byCodePoint should be
used with strings from now on), then a warning, then an actual
deprecation, then remove autodecoding code from Phobos algorithms
(leaving only byCodePoint for those who still want autodecoding).


Consider this PR:

https://github.com/D-Programming-Language/phobos/pull/2423

which is blocked because several people do not agree with using byCodeunit.

Re: DMD 2.066 druntime looks broken...

[Walter Bright via Digitalmars-d]

On 9/24/2014 2:35 PM, Iain Buclaw via Digitalmars-d wrote:

delegate parameter 'fn' is not nothrow!


Not nohow? No way!

Re: Escaping the Tyranny of the GC: std.rcstring, first blood

[Ola Fosheim Grostad via Digitalmars-d]

Analysis of Go growth / usage.

http://redmonk.com/dberkholz/2014/03/18/go-the-emerging-language-of-cloud-infrastructure/

Re: bugzilla refusing to reset my password

[ketmar via Digitalmars-d]

On Fri, 26 Sep 2014 05:02:37 +0300
ketmar via Digitalmars-d  wrote:

sorry again, i finally received password reset mail.


signature.asc
Description: PGP signature

Re: Announcing libasync, a cross-platform D event loop

[Etienne Cimon via Digitalmars-d]

On 2014-09-25 19:34, Martin Nowak wrote:

One thing that always bothers me with async libraries is that now every
IO class has it async cousin, so there is Socket and AsyncSocket,
resolveDNS and asyncResolveDNS.
With Fibers and a Scheduler it's actually possible to present the same
API to asynchronous and synchronous code. I'd really like to see this at
some point, but a cross-platform event loop in phobos is a great first
step.


Exactly, though I'm pretty sure this could be solved by moving vibe core 
to std.vibe, and then adding it as a dependency for std.socket and 
std.concurrency. It doesn't feel right having the future/promise aside 
of fibers with a scheduler, it needs to be done correctly from the start.

Re: Escaping the Tyranny of the GC: std.rcstring, first blood

[Ola Fosheim Grostad via Digitalmars-d]

On Tuesday, 23 September 2014 at 06:19:58 UTC, deadalnix wrote:
On Tuesday, 23 September 2014 at 03:03:49 UTC, Manu via 
Digitalmars-d wrote:
I still think most of those users would accept RC instead of 
GC. Why not
support RC in the language, and make all of this library noise 
redundant?
Library RC can't really optimise well, RC requires language 
support to

elide ref fiddling.


I think a library solution + intrinsic for increment/decrement 
(so they can be better optimized) would be the best option.


Yes, inc/dec intrinsic is needed to support TSX. I.e. You dont 
have to inc/dec to keep the object alive within a transaction, 
you only need to read something on the same cacheline as the ref 
count. Essentially zero overhead in many cases afaik.

bugzilla refusing to reset my password

[ketmar via Digitalmars-d]

Hello.

sorry for the noise, but i accidentally ;-) logged out of bugzilla and
i don't remember my password. and "forgot password" feature says that
is sends me a letter, but nothing arrives. i tried many times, but
withous success. what else can i do to get new password?


signature.asc
Description: PGP signature

j_lacab...@yahoo.com

[j_lacab...@yahoo.com via Digitalmars-d]

On Friday, 26 September 2014 at 01:31:06 UTC, Michel Fortin wrote:
Maybe this will be of interest to someone. D was mentioned on 
the official Swift Blog today:


Swift borrows a clever feature from the D language: these 
identifiers expand to the location of the caller when 
evaluated in a default argument list.


-- Building assert() in Swift, Part 2: __FILE__ and __LINE__

D mention on developer.apple.com

[Michel Fortin via Digitalmars-d]

Maybe this will be of interest to someone. D was mentioned on the 
official Swift Blog today:


Swift borrows a clever feature from the D language: these identifiers 
expand to the location of the caller when evaluated in a default 
argument list.


-- Building assert() in Swift, Part 2: __FILE__ and __LINE__


--
Michel Fortin
michel.for...@michelf.ca
http://michelf.ca

Re: DMD 2.066 druntime looks broken...

[Martin Nowak via Digitalmars-d]

On 09/24/2014 11:35 PM, Iain Buclaw via Digitalmars-d wrote:

callWithStackShell is marked nothrow, yet it's delegate parameter 'fn'
is not nothrow!


https://github.com/D-Programming-Language/druntime/pull/966


Bonus points, D inline assembly in a nothrow function.


Marking asm as throwing by default doesn't make too much sense IMO,
because it's fairly difficult to throw from iasm (never seen it) and the 
main point about iasm is full control.

So why not simply trust the programmer decision here?

Re: What are the worst parts of D?

[ketmar via Digitalmars-d]

On Thu, 25 Sep 2014 15:48:11 -0700
Andrei Alexandrescu via Digitalmars-d 
wrote:

> I'm not sharing that feeling at all. From that perspective all
> languages are in need of a "serious cleanup". -- Andrei
and they *are*. yet many languages can't be fixed due to huge amount of
written code and user resistance. D is in winning position here: "most
of D code yet to be written", yeah. and D users (even corporate users)
are very welcome of breaking changes -- if they will make D more
consistent and clean.

the situation is... weird now. users: "it's ok, we WANT that breaking
changes!" language developers: "no, you don't. it's too late."


signature.asc
Description: PGP signature

Re: What are the worst parts of D?

[ketmar via Digitalmars-d]

On Thu, 25 Sep 2014 16:11:57 -0700
"H. S. Teoh via Digitalmars-d"  wrote:

> Nah, they should be behead() and amputate().
i like it! this makes language much more expressive.


signature.asc
Description: PGP signature

Re: What are the worst parts of D?

[ketmar via Digitalmars-d]

On Thu, 25 Sep 2014 21:37:17 +
eles via Digitalmars-d  wrote:

> I find it too inconsitent. I doubt even Python programmers 
> migrating to D love that...
> 
> And, just: std.uni->std.unicode
> 
> And I cannot believe that the language-defined complex types are 
> still there (since the D1 days...). Either in the library, either 
> in the language, but, please, pick *one* kind.
it's too late to change it. at least that's what i've been told.
imaginary future users will be scared.


signature.asc
Description: PGP signature

Re: Make HTTP request without cURL/other libraries

[Vladimir Panteleev via Digitalmars-d]

On Wednesday, 24 September 2014 at 16:45:57 UTC, BoPoHa_C_CblPoM 
wrote:

I want to make app smaller in size and in a single executable.


If you only need Windows support, you can use the WinINet API, 
this way you will not depend on cURL or OpenSSL:


https://github.com/CyberShadow/ae/blob/master/sys/net/wininet.d

Re: [Semi OT] Language for Game Development talk

[Sean Kelly via Digitalmars-d]

On Thursday, 25 September 2014 at 23:04:08 UTC, Peter Alexander 
wrote:


This is really missing the point. He knows RAII is useful and 
he knows RAII solves freeing free'd memory. Maybe it's time to 
re-watch the video.


I was replying to the comments.  Sorry if I misunderstood.

Re: Announcing libasync, a cross-platform D event loop

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 11:48:29PM +, Sean Kelly via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 03:29:03 UTC, Zhao Puming wrote:
> >Great work Etienne!
> >
> >will libasync make it into phobos?
> 
> I certainly hope so.  We need async functionality if we're to ever
> have a decent socket package in Phobos.

Adam has also written an event loop (arsd.eventloop), which also has
timers and a signals-and-slots subsystem:

https://github.com/adamdruppe/arsd/blob/master/eventloop.d

I'm not sure if it supports multithreading, but its event registration
API is very cool. I think we should pick the best of both projects for
inclusion in Phobos.


T

-- 
Let X be the set not defined by this sentence...

Re: Announcing libasync, a cross-platform D event loop

[Sean Kelly via Digitalmars-d]

On Thursday, 25 September 2014 at 03:29:03 UTC, Zhao Puming wrote:

Great work Etienne!

will libasync make it into phobos?


I certainly hope so.  We need async functionality if we're to 
ever have a decent socket package in Phobos.

Re: What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 9/25/14, 4:07 PM, Brian Rogoff wrote:

On Thursday, 25 September 2014 at 13:49:00 UTC, Andrei Alexandrescu wrote:

I've recently used Rust a bit and the curse of D users as of 6-7 years
ago reached me: most code I download online doesn't compile for
obscure reasons, it's nigh impossible to figure out what the fix is
from the compiler error message, searching online finds outdated
documentation that tells me the code should work, and often it's
random name changes (from_iterator to from_iter and such, or names are
moved from one namespace to another).


That's more than a bit unfair.


This is not about fairness. -- Andrei

Re: [Semi OT] Language for Game Development talk

[Walter Bright via Digitalmars-d]

On 9/25/2014 3:52 PM, Sean Kelly wrote:

Regarding exceptions, they can be used incorrectly, but I think they tend to
provide better error handling than return codes *because no one ever checks
return codes*.  And when you do pathologically handle error codes, the amount of
code duplication can be tremendous, and the chance for errors involving improper
cleanup can be quite high.  Though again, RAII can be of incredible use here.


Yup. A very common source of bugs in C code is all the incorrectly written "if 
(error) goto cleanup;" code. Exceptions and RAII take care of most of that.

Re: Announcing libasync, a cross-platform D event loop

[Martin Nowak via Digitalmars-d]

On 09/24/2014 06:30 PM, Etienne wrote:

 > This is fantastic! We really need something like this in a Facebook
 > project.

That's pleasing to hear, although I'm pretty sure Facebook is far from
being the only organization who will benefit from this ;)


Who doesn't need something like this?


 > Would be appropriate for you to consider making a bid for adding it
to Phobos?

Thanks for the invitation, I'll start working on a phobos fork with this
added into std.async and re-licensed to Boost. Would that be an
appropriate namespace?


I still have to try out the library, but I'd like to see that.

One thing that always bothers me with async libraries is that now every 
IO class has it async cousin, so there is Socket and AsyncSocket, 
resolveDNS and asyncResolveDNS.
With Fibers and a Scheduler it's actually possible to present the same 
API to asynchronous and synchronous code. I'd really like to see this at 
some point, but a cross-platform event loop in phobos is a great first step.

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 03:48:11PM -0700, Andrei Alexandrescu via Digitalmars-d 
wrote:
> On 9/25/14, 2:03 PM, eles wrote:
> >On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:
> >
> >>lack of attention paid to tightening up what we've already got and
> >>deprecating old stuff that no one wants any more.  And inconsistency
> >>in how things work in the language.
> >
> >The feeling that I have is that if D2 does not get a serious cleanup
> >at this stage, then D3 must follow quickly (and such move will be
> >unstoppable), otherwise people will fall back to D1 or C++next.
> 
> I'm not sharing that feeling at all. From that perspective all
> languages are in need of a "serious cleanup". -- Andrei

I've been thinking that it might do us some good if we aren't as
paranoid about breaking old code, as long as (1) it's to fix a language
design flaw, (2) it exposes potentially (or outright) buggy user code,
(3) users are warned well ahead of time, followed by a full deprecation
cycle, and (4) optionally, there's a tool, either fully or partially
automated, that can upgrade old codebases.

I mean, enterprises use deprecation cycles with their products all the
time, and we don't hear of customers quitting just because of that. Some
of the more vocal customers will voice their unhappiness, but as long as
you're willing to work with them and allow them sufficient time to
migrate over nicely and phase out the old stuff, they're generally
accepting of the process.

We've already had offers from D-based organizations asking to please
break their code(!) for the sake of fixing language design flaws -- this
is already far more than what most enterprise customers are generally
willing to put up with, IME. Yet we're doing far less than what
enterprises do in order to keep their product up-to-date. We may need to
use very long deprecation cycles to keep everyone happy (on the order of
2-3 years perhaps), but doing nothing will only result in absolutely
zero improvement even after 10 years.


T

-- 
Кто везде - тот нигде.

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 22:48:12 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 2:03 PM, eles wrote:
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
wrote:


lack of attention paid to tightening up what we've already 
got and
deprecating old stuff that no one wants any more.  And 
inconsistency

in how things work in the language.


The feeling that I have is that if D2 does not get a serious 
cleanup at

this stage, then D3 must follow quickly (and such move will be
unstoppable), otherwise people will fall back to D1 or C++next.


I'm not sharing that feeling at all. From that perspective all 
languages are in need of a "serious cleanup". -- Andrei


The serious question is at what cost does this un-sharing come. 
The cost of the always-niche (aka "nice try") language?

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 22:48:12 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 2:03 PM, eles wrote:
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
wrote:


lack of attention paid to tightening up what we've already 
got and
deprecating old stuff that no one wants any more.  And 
inconsistency

in how things work in the language.


The feeling that I have is that if D2 does not get a serious 
cleanup at

this stage, then D3 must follow quickly (and such move will be
unstoppable), otherwise people will fall back to D1 or C++next.


I'm not sharing that feeling at all. From that perspective all 
languages are in need of a "serious cleanup". -- Andrei


BTW, I already have somebody who's sharing my feelings, not 
looking further.

Re: What are the worst parts of D?

[Cliff via Digitalmars-d]

On Thursday, 25 September 2014 at 23:04:55 UTC, eles wrote:
On Thursday, 25 September 2014 at 22:56:56 UTC, Sean Kelly 
wrote:
On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 2:10 PM, eles wrote:


Why not, for God's sake, stripFront and stripBack?


Because they are called stripLeft and stripRight. -- Andrei


Psh, they should be called stripHead and stripFoot.  Or 
alternately, unHat and unShoe.


stripLady and stripGentleman?...


Ah, now this thread is going to interesting places! :P

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 2:10 PM, eles wrote:

On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
wrote:




BTW, am I the only one whose eyes/ears are suffering when 
reading this:


std.algrithm

"he stripLeft function will strip the front of the range, the 
stripRight
function will strip the back of the range, while the strip 
function will

strip both the front and back of the range. "

Why not, for God's sake, stripFront and stripBack?


Because they are called stripLeft and stripRight. -- Andrei


One day you will need to call this guy here:

http://dconf.org/2014/talks/meyers.html

He will say: "I told you so. At DConf."

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 10:56:55PM +, Sean Kelly via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei Alexandrescu wrote:
> >On 9/25/14, 2:10 PM, eles wrote:
> >>
> >>Why not, for God's sake, stripFront and stripBack?
> >
> >Because they are called stripLeft and stripRight. -- Andrei
> 
> Psh, they should be called stripHead and stripFoot.  Or alternately, unHat
> and unShoe.

Nah, they should be behead() and amputate().


T

-- 
People who are more than casually interested in computers should have at least 
some idea of what the underlying hardware is like. Otherwise the programs they 
write will be pretty weird. -- D. Knuth

Re: What are the worst parts of D?

[Brian Rogoff via Digitalmars-d]

On Thursday, 25 September 2014 at 13:49:00 UTC, Andrei 
Alexandrescu wrote:
I've recently used Rust a bit and the curse of D users as of 
6-7 years ago reached me: most code I download online doesn't 
compile for obscure reasons, it's nigh impossible to figure out 
what the fix is from the compiler error message, searching 
online finds outdated documentation that tells me the code 
should work, and often it's random name changes (from_iterator 
to from_iter and such, or names are moved from one namespace to 
another).


That's more than a bit unfair. Rust's developers have made it 
abundantly clear that things will keep changing until version 
1.0. If you want to play with some Rust that's guaranteed to 
work, go to


http://www.rust-ci.org

and find a bit code that interests you which isn't failing, and 
then download the nightly. The docs on the Rust home page are 
either for a fixed version (0.11.0) or the nightly. Let's wait 
for a bit of time after 1.0 is out before you critique the 
annoying changes; they deliberately are developing in the open to 
get community input and avoid getting stuck with too many 
mistakes (though it looks like they are stuck with C++ template 
syntax, ugh!). So far, I haven't found it too hard to update 
code, and they've been good at marking breaking changes as 
breaking changes, which can be searched for with git.


In the case of D, the main D2 book was published 4 years ago and 
that should correspond to Rust 1.0 or even later, since D already 
had a D1 to  shake out the mistakes and bad namings. That's gone 
perfectly, with no code breakage between releases during those 
four years, right?

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 22:48:12 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 2:03 PM, eles wrote:
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
wrote:


lack of attention paid to tightening up what we've already 
got and
deprecating old stuff that no one wants any more.  And 
inconsistency

in how things work in the language.


The feeling that I have is that if D2 does not get a serious 
cleanup at

this stage, then D3 must follow quickly (and such move will be
unstoppable), otherwise people will fall back to D1 or C++next.


I'm not sharing that feeling at all. From that perspective all 
languages are in need of a "serious cleanup". -- Andrei


Those *all* languages, at least some of them, have good excuses 
(C++'s roots in C and the great advantage that is able to compile 
C code too, to some extent - history is on his side) and powerful 
driving factors (the whole might of Oracle and Microsoft). And, 
most of all, they already have a fair share of the market.


And they served a lot of users quite well and those users aren't 
ready to drop them quite easily for what happens to be the cool 
kid of the day in the programming language world.


D has to provide quality in order to compensate for the( lack of 
the)se factors.

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 22:56:56 UTC, Sean Kelly wrote:
On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 2:10 PM, eles wrote:


Why not, for God's sake, stripFront and stripBack?


Because they are called stripLeft and stripRight. -- Andrei


Psh, they should be called stripHead and stripFoot.  Or 
alternately, unHat and unShoe.


stripLady and stripGentleman?...

Re: [Semi OT] Language for Game Development talk

[Peter Alexander via Digitalmars-d]

On Thursday, 25 September 2014 at 22:52:39 UTC, Sean Kelly wrote:

On Saturday, 20 September 2014 at 02:25:31 UTC, po wrote:


As a fellow game dev:

I don't agree with him about RAII, I find it useful

He kind of has a point about exceptions, I'm not big on them

...
He goes on about "freeing free'd memory", this is never 
something that would happen in modern C++, so he is basically 
proposing an inferior language design.


It happens when you don't use RAII.  Sounds like he should 
review his concepts.


This is really missing the point. He knows RAII is useful and he 
knows RAII solves freeing free'd memory. Maybe it's time to 
re-watch the video.

Re: What are the worst parts of D?

[Sean Kelly via Digitalmars-d]

On Thursday, 25 September 2014 at 22:49:06 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 2:10 PM, eles wrote:


Why not, for God's sake, stripFront and stripBack?


Because they are called stripLeft and stripRight. -- Andrei


Psh, they should be called stripHead and stripFoot.  Or 
alternately, unHat and unShoe.

Re: [Semi OT] Language for Game Development talk

[Sean Kelly via Digitalmars-d]

On Saturday, 20 September 2014 at 02:25:31 UTC, po wrote:


As a fellow game dev:

I don't agree with him about RAII, I find it useful

He kind of has a point about exceptions, I'm not big on them

...
He goes on about "freeing free'd memory", this is never 
something that would happen in modern C++, so he is basically 
proposing an inferior language design.


It happens when you don't use RAII.  Sounds like he should review 
his concepts.


Regarding exceptions, they can be used incorrectly, but I think 
they tend to provide better error handling than return codes 
*because no one ever checks return codes*.  And when you do 
pathologically handle error codes, the amount of code duplication 
can be tremendous, and the chance for errors involving improper 
cleanup can be quite high.  Though again, RAII can be of 
incredible use here.


 At one point he says you can't see the contents of std::vector 
in a debugger. What? This is trivial and has worked in every 
version of Visual Studio for the last 5+ years.


std::string tends to be more complicated because of the small 
string optimization.  Most debuggers I've used don't handle that 
correctly out of the box, even if sorting it out really isn't 
difficult.

Re: What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 9/25/14, 2:03 PM, eles wrote:

On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:


lack of attention paid to tightening up what we've already got and
deprecating old stuff that no one wants any more.  And inconsistency
in how things work in the language.


The feeling that I have is that if D2 does not get a serious cleanup at
this stage, then D3 must follow quickly (and such move will be
unstoppable), otherwise people will fall back to D1 or C++next.


I'm not sharing that feeling at all. From that perspective all languages 
are in need of a "serious cleanup". -- Andrei

Re: What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 9/25/14, 2:10 PM, eles wrote:

On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:

On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:



BTW, am I the only one whose eyes/ears are suffering when reading this:

std.algrithm

"he stripLeft function will strip the front of the range, the stripRight
function will strip the back of the range, while the strip function will
strip both the front and back of the range. "

Why not, for God's sake, stripFront and stripBack?


Because they are called stripLeft and stripRight. -- Andrei

Re: Thread GC non "stop-the-world"

[Sean Kelly via Digitalmars-d]

On Thursday, 25 September 2014 at 13:55:42 UTC, Wyatt wrote:


The caveat for D being this design requires read and write 
barriers and I'm pretty sure I recall correctly that those have 
been vetoed several times for complexity.


Pretty much for reasons of being able to call C functions and 
inline asm code.  Memory barriers may still be possible in these 
scenarios, but they would be extremely expensive.

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 08:40:50PM +, eles via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 15:58:11 UTC, eles wrote:
> >On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:
> >>On 25/09/14 09:38, Atila Neves wrote:
> >>
> 
> >Andrei spoke about an idiom that they constantly use at Facebok,
> >because there aparrently nobody runs *main and unittests*. So they
> >keep a special empty main for the -unittest version.
> 
> This idiom here:
> 
> http://forum.dlang.org/post/ljr5n7$1leb$1...@digitalmars.com
> 
> "Last but not least, virtually nobody I know runs unittests and then
> main. This is quickly becoming an idiom:
> 
> version(unittest) void main() {}
> else void main()
> {
>...
> }
> 
> I think it's time to change that. We could do it the
> non-backward-compatible way by redefining -unittest to instruct the
> compiler to not run main. Or we could define another flag such as
> -unittest-only and then deprecate the existing one.

Please don't deprecate the current -unittest. I regularly find it very
useful when in the code-compile-test cycle. I'm OK with introducing
-unittest-only for people who want it, but I still like using the
current -unittest.


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- 
Walter Bright

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 09:19:29PM +, via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 21:03:53 UTC, Walter Bright wrote:
[...]
> >I have yet to completely convince Andrei that autodecoding is a bad
> >idea :-(

It certainly represents a runtime overhead, which may be non-negligible
depending on your particular use case, and despite oft stated benefits
of being Unicode-aware by default (well, not 100%), I think the cost of
maintaining special-casing for narrow strings is starting to show up in
the uglification of Phobos range-based code. Ranges were supposed to
help with writing cleaner, more generic code, but I've been observing a
trend of special-casing in order to reduce the autodecoding overhead in
string handling, which somewhat reduces the cleanness of otherwise
fully-generic code.  This complexity has led to string-related bugs, and
definitely has a cost on the readability (and, consequently,
maintainability) of Phobos code. Special cases hurt generic code. It's
not just about performance.


> I think it should just refuse to work on char[], wchar[] and dchar[].
> Instead, byCodeUnit, byCodePoint (which already exist) would be
> required.  This way, users would need to make a conscious decision,
> and there would be no surprises and no negative performance impact.

Not a bad idea. If we do it right, we could (mostly) avoid user outrage.
E.g., start with a "soft deprecation" (a compile-time message, but not
an actual warning, to the effect that byCodeUnit / byCodePoint should be
used with strings from now on), then a warning, then an actual
deprecation, then remove autodecoding code from Phobos algorithms
(leaving only byCodePoint for those who still want autodecoding).


T

-- 
Two wrongs don't make a right; but three rights do make a left...

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 21:22:38 UTC, bearophile wrote:

eles:

"he stripLeft function will strip the front of the range, the 
stripRight function will strip the back of the range, while 
the strip function will strip both the front and back of the 
range. "


Why not, for God's sake, stripFront and stripBack?


Perhaps those names come from extending the names of "lstrip" 
and "rsplit" of Python string functions.


Bye,
bearophile


I find it too inconsitent. I doubt even Python programmers 
migrating to D love that...


And, just: std.uni->std.unicode

And I cannot believe that the language-defined complex types are 
still there (since the D1 days...). Either in the library, either 
in the language, but, please, pick *one* kind.

Re: What are the worst parts of D?

[bearophile via Digitalmars-d]

eles:

"he stripLeft function will strip the front of the range, the 
stripRight function will strip the back of the range, while the 
strip function will strip both the front and back of the range. 
"


Why not, for God's sake, stripFront and stripBack?


Perhaps those names come from extending the names of "lstrip" and 
"rsplit" of Python string functions.


Bye,
bearophile

Re: Thread GC non "stop-the-world"

[Oscar Martin via Digitalmars-d]

On Thursday, 25 September 2014 at 13:55:42 UTC, Wyatt wrote:
On Wednesday, 24 September 2014 at 20:15:52 UTC, Oscar Martin 
wrote:
On Wednesday, 24 September 2014 at 08:13:15 UTC, Marc Schütz 
wrote:


There can also be a shared _and_ a local GC at the same time, 
and a thread could opt from the shared GC (or choose not to 
opt in by not allocating from the shared heap).


Yes, a shared GC should be a possibility, but how you avoid 
the "stop-the-world" phase for that GC?


Obviously this pause can be minimized by performing the most 
work out of that phase, but after seeing the test of other 
people on internet about advanced GCs (java, .net) I do not 
think it's enough for some programs


But hey, I guess it's enough to cover the greatest number of 
cases. My goal is to start implementing the thread GC. Then I 
will do testing of performance and pauses (my program requires 
managing audio every 10 ms) and then I might dare to implement 
the shared GC, which is obviously more complex if desired to 
minimize the pauses. We'll see what the outcome


This thread reminds me again of a paper I read a few months ago 
with a clever way of dealing with the sharing problem while 
maintaining performance: 
https://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/local-gc.pdf


The caveat for D being this design requires read and write 
barriers and I'm pretty sure I recall correctly that those have 
been vetoed several times for complexity.


-Wyatt


An interesting paper. Thank you very much

Re: What are the worst parts of D?

[via Digitalmars-d]

On Thursday, 25 September 2014 at 21:03:53 UTC, Walter Bright 
wrote:

On 9/25/2014 12:58 PM, H. S. Teoh via Digitalmars-d wrote:
On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via 
Digitalmars-d wrote:

On 9/25/2014 4:08 AM, Don wrote:

[...]
Ask yourself, if D had no users other than you, so that you 
break
*anything*, what would you remove? Make a wishlist, and then 
find out
what's possible.  Remember, when you did that before, we 
successfully

got rid of 'bit', and there was practically no complaint.


Top of my list would be the auto-decoding behavior of
std.array.front() on character arrays. Every time I'm faced 
with that

I want to throw a chair through the window.


LOL... now I'm genuinely curious what's Andrei's comment on 
this. :-P

Last I heard, Andrei was against removing autodecoding.


I have yet to completely convince Andrei that autodecoding is a 
bad idea :-(


I think it should just refuse to work on char[], wchar[] and 
dchar[]. Instead, byCodeUnit, byCodePoint (which already exist) 
would be required. This way, users would need to make a conscious 
decision, and there would be no surprises and no negative 
performance impact.

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 21:10:51 UTC, eles wrote:

On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:
On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly 
wrote:




BTW, am I the only one whose eyes/ears are suffering when 
reading this:


std.algrithm

"he stripLeft function will strip the front of the range, the 
stripRight function will strip the back of the range, while the 
strip function will strip both the front and back of the range. 
"


Why not, for God's sake, stripFront and stripBack?

In std.string too. What about the R2L languages?


OTOH, there is bringToFront()

Really...

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 21:03:24 UTC, eles wrote:

On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:



BTW, am I the only one whose eyes/ears are suffering when reading 
this:


std.algrithm

"he stripLeft function will strip the front of the range, the 
stripRight function will strip the back of the range, while the 
strip function will strip both the front and back of the range. "


Why not, for God's sake, stripFront and stripBack?

In std.string too. What about the R2L languages?

Re: What are the worst parts of D?

[Walter Bright via Digitalmars-d]

On 9/25/2014 12:58 PM, H. S. Teoh via Digitalmars-d wrote:

On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via Digitalmars-d wrote:

On 9/25/2014 4:08 AM, Don wrote:

[...]

Ask yourself, if D had no users other than you, so that you break
*anything*, what would you remove? Make a wishlist, and then find out
what's possible.  Remember, when you did that before, we successfully
got rid of 'bit', and there was practically no complaint.


Top of my list would be the auto-decoding behavior of
std.array.front() on character arrays. Every time I'm faced with that
I want to throw a chair through the window.


LOL... now I'm genuinely curious what's Andrei's comment on this. :-P
Last I heard, Andrei was against removing autodecoding.


I have yet to completely convince Andrei that autodecoding is a bad idea :-(

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Tuesday, 23 September 2014 at 14:29:06 UTC, Sean Kelly wrote:

lack of attention paid to tightening up what we've already got 
and deprecating old stuff that no one wants any more.  And 
inconsistency in how things work in the language.


The feeling that I have is that if D2 does not get a serious 
cleanup at this stage, then D3 must follow quickly (and such move 
will be unstoppable), otherwise people will fall back to D1 or 
C++next.

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 15:58:11 UTC, eles wrote:
On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg 
wrote:

On 25/09/14 09:38, Atila Neves wrote:



Andrei spoke about an idiom that they constantly use at 
Facebok, because there aparrently nobody runs *main and 
unittests*. So they keep a special empty main for the -unittest 
version.


This idiom here:

http://forum.dlang.org/post/ljr5n7$1leb$1...@digitalmars.com

"Last but not least, virtually nobody I know runs unittests and 
then

main. This is quickly becoming an idiom:

version(unittest) void main() {}
else void main()
{
   ...
}

I think it's time to change that. We could do it the
non-backward-compatible way by redefining -unittest to instruct 
the

compiler to not run main. Or we could define another flag such as
-unittest-only and then deprecate the existing one.
"

Re: [Semi OT] Language for Game Development talk

[deadalnix via Digitalmars-d]

On Thursday, 25 September 2014 at 15:34:31 UTC, Andrei
Alexandrescu wrote:

On 9/25/14, 8:12 AM, Kagamin wrote:
On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 4:33 AM, Kagamin wrote:
On Thursday, 25 September 2014 at 09:16:27 UTC, Walter 
Bright wrote:

So how do you tell it to call myfree(p) instead of free(p) ?


Maybe stock malloc/free is enough for him?


That kind of commitment shouldn't be baked into the language. 
That's

why RAII and scope are better than his notation.


Allocation is orthogonal to RAII and scope. Allocation creates 
resource,

RAII tracks it.


Affirmative. -- Andrei


And in many cases scope statements are simpler, better, harder,
stronger !

Re: [Semi OT] Language for Game Development talk

[deadalnix via Digitalmars-d]

On Thursday, 25 September 2014 at 09:27:16 UTC, Walter Bright
wrote:

On 9/19/2014 4:47 PM, Max Klyga wrote:
Jonathan Blow just recorded a talk about the needs and ideas 
for a programming

language for game developer.

https://www.youtube.com/watch?v=TH9VCN6UkyQ

This talk mentions D quite a lot of times.
D is mentioned as the most probable to be adopted if it were 
possible for

frictionless interaction with existing codebase.
An interesting talk if you want to look at language design 
from game developer

perspective.



Looks like he reinvented D dynamic arrays at 1:02. Sigh.


Yes the only thing that seems to be an issue between him and D is
the lack of ownership (his ! concept).

Re: What are the worst parts of D?

[Jacob Carlborg via Digitalmars-d]

On 2014-09-25 19:26, Atila Neves wrote:


I don't want an empty main function. I want the main function and the
file it's in to be generated by the build system.


What do you want the main function to contain?

--
/Jacob Carlborg

Re: What are the worst parts of D?

[Jacob Carlborg via Digitalmars-d]

On 2014-09-25 20:49, H. S. Teoh via Digitalmars-d wrote:


The compiler and compile flags are inputs to the build rules in SCons.

In my SCons projects, when I change compile flags (possibly for a subset
of source files), it correctly figures out which subset (or the entire
set) of files needs to be recompiled with the new flags. Make fails, and
you end up with an inconsistent executable.

In my SCons projects, when I upgrade the compiler, it recompiles
everything with the new compiler. Make doesn't detect a difference, and
if you make a change and recompile, suddenly you got an executable 80%
compiled with the old compiler and 20% compiled with the new compiler.
Most of the time it doesn't make a difference... but when it does, have
fun figuring out where the problem lies. (Or just make clean; make yet
again... the equivalent of which is basically what SCons would have done
5 hours ago.)

In my SCons projects, when I upgrade the system C libraries, it
recompiles everything that depends on the updated header files *and*
library files. In make, it often fails to detect that the .so's have
changed, so it fails to relink your program. Result: your executable
behaves strangely at runtime due to wrong .so being linked, but the
problem vanishes once you do a make clean; make.


I see, thanks for the explanation.

--
/Jacob Carlborg

Re: What are the worst parts of D?

[Jacob Carlborg via Digitalmars-d]

On 2014-09-25 21:02, Ary Borenszweig wrote:


Maybe Facebook needs D to interface with C++?


But I only see Andrei working on that. Don't know how much coding he 
does in practice for C++ compatibility.


--
/Jacob Carlborg

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 12:51:45PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> I've found:
> 
>-main -unittest -cov
> 
> to be terribly convenient when developing modules. Should have added
> -main much sooner.

Yeah, I do that all the time nowadays when locally testing Phobos fixes.
In the past I'd have to write yet another empty main() in yet another
temporary source file, just to be able to avoid having to wait for the
entire Phobos testsuite to run after a 1-line code change.


T

-- 
"How are you doing?" "Doing what?"

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 12:40:28PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/25/2014 4:08 AM, Don wrote:
[...]
> >Ask yourself, if D had no users other than you, so that you break
> >*anything*, what would you remove? Make a wishlist, and then find out
> >what's possible.  Remember, when you did that before, we successfully
> >got rid of 'bit', and there was practically no complaint.
> 
> Top of my list would be the auto-decoding behavior of
> std.array.front() on character arrays. Every time I'm faced with that
> I want to throw a chair through the window.

LOL... now I'm genuinely curious what's Andrei's comment on this. :-P
Last I heard, Andrei was against removing autodecoding.


> Probably second would be having const and purity by default.

Some of this could be mitigated if we expanded the sphere of attribute
inference. I know people hated the idea of auto == infer attributes, but
I personally support it.

Perhaps an alternate route to that is to introduce a @auto (or whatever
you wanna call it, @infer, or whatever) and promote its use in D code,
then slowly phase out functions not marked with @infer. After a certain
point, @infer will become the default, and explicit @infer's will become
no-op, and then subsequently dropped. This is very ugly, though. I much
prefer extending auto to mean infer.


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system 
vulnerabilities cannot touch Linux---is priceless. -- Frustrated system 
administrator.

Re: [Semi OT] Language for Game Development talk

[Walter Bright via Digitalmars-d]

On 9/25/2014 3:46 AM, currysoup wrote:

Would just like to remind you all that he's trying to foster conversation rather
than declare "this is the most perfect language ever". A lot of his ideas don't
hold water in their current form but I'm sure D wasn't designed in a 2 hour live
stream :). I'm personally really excited at the prospect of some momentum in a
language designed specifically for games engineers.


It is great to have a conversation. It's good to revisit assumptions about what 
a good language should be. Although I don't agree with him, I thought that it 
was great that he questioned the value of RAII.


But I think it's a waste of time to develop a new language that has 98% overlap 
with existing ones, like if I proposed a language just like C but with member 
functions.

Re: [Semi OT] Language for Game Development talk

[Walter Bright via Digitalmars-d]

On 9/25/2014 3:46 AM, currysoup wrote:

I quite like the idea of "simple by default" and you enable features with
annotations (@usegc, @throws, @pure).


I think simple by default doesn't have those annotations - by default meaning 
"the code works". Those annotations all work to restrict what the code can do.

Re: What are the worst parts of D?

[Walter Bright via Digitalmars-d]

On 9/25/2014 10:45 AM, Andrei Alexandrescu wrote:

On 9/25/14, 10:26 AM, Atila Neves wrote:

On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:

On 25/09/14 09:38, Atila Neves wrote:


Here's one: having to manually generate the custom main file for
unittest builds. There's no current way (or at least there wasn't when I
brought it up in the dub forum) to tell it to autogenerate a D file from
a dub package and list it as a dependency of the unittest build.


Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main"
flag that adds an empty main function.


I don't want an empty main function. I want the main function and the
file it's in to be generated by the build system.


Why would be the focus on the mechanism instead of the needed outcome? -- Andrei



I've found:

   -main -unittest -cov

to be terribly convenient when developing modules. Should have added -main much 
sooner.

Re: What are the worst parts of D?

[Walter Bright via Digitalmars-d]

On 9/25/2014 4:08 AM, Don wrote:

[...]


I agree with Andrei, it's a good list. I'll move these issues to the next step 
in the removal process.




I'd also like to see us getting rid of those warts like assert(float.nan) being
true.


See discussion:

https://issues.dlang.org/show_bug.cgi?id=13489



Ask yourself, if D had no users other than you, so that you break *anything*,
what would you remove? Make a wishlist, and then find out what's possible.
Remember, when you did that before, we successfully got rid of 'bit', and there
was practically no complaint.


Top of my list would be the auto-decoding behavior of std.array.front() on 
character arrays. Every time I'm faced with that I want to throw a chair through 
the window.


Probably second would be having const and purity by default.

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 07:19:14PM +, Cliff via Digitalmars-d wrote:
> On Thursday, 25 September 2014 at 18:51:13 UTC, H. S. Teoh via
> Digitalmars-d wrote:
> >You don't know if recompiling after checking out a previous release
> >of your code will actually give you the same binaries that you
> >shipped 2 months ago.
> 
> To be clear, even if nothing changed, re-running the build may
> produce different output.  This is actually a really hard problem
> - some build tools actually use entropy when producing their
> outputs, and as a result running the exact same tool with the
> same parameters in the same [apparent] environment will produce a
> subtly different output.  This may be intended (address
> randomization) or semi-unintentional (generating a unique GUID
> inside a PDB so the debugger can validate the symbols match the
> binaries.)  Virtually no build system in use can guarantee the
> above in all cases, so you end up making trade-offs - and if you
> don't really understand those tradeoffs, you won't trust your
> build system.

Good point.


> What else may mess up the perfection of repeatability of your
> builds?  Environment variables, the registry (on Windows), any
> source of entropy (the PRNG, the system clock/counters, any
> network access), etc.

Well, obviously if your build process involves input from output, then
it's impossible to have 100% repeatable builds. But at least we can do
it (and arguably *should* do it) when there are no outside outputs.

I actually have some experience in this area, because part of the
website project I described in another post involves running gnuplot to
plot statistics of a certain file by connecting to an SVN repository and
parsing its history log. Since the SVN repo is not part of the website
repo, obviously the build of a previous revision of the website will
never be 100% repeatable -- it will always generate the plot for the
latest history rather than what it would've looked like at the time of
the previous revision. But for the most part, this doesn't matter.

I *did* find that imagemagick was messing up my SCons scripts because it
would always insert timestamped metadata into the generated image files,
which caused SCons to always see the files as changed and trigger
redundant rebuilds. This is also an example of where sometimes you do
need to override the build system's default mechanisms to tell it to
chill out and not rebuild that target every time. I believe SCons lets
you do this, though I solved the problem another way -- by passing
options to imagemagick to suppress said metadata.

Nevertheless, I'd say that overall, builds should be reproducible by
default, and the user should tell the build system when it doesn't have
to be -- rather than the other way round. Just like D's motto of safety
first, unsafe if you ask for it.


[...]
> Different people will make different tradeoffs, and I am not here
> to tell Andrei or Walter that they *need* a new build system for
> D to get their work done - they don't right now.  I'm more
> interested in figuring out how to provide a platform to realize
> the benefits for build like we have for our modern languages, and
> then leveraging that in new ways (like better sharing between the
> compiler, debugger, IDEs, test and packaging.)

Agreed. I'm not saying we *must* replace the makefiles in dmd / druntime
/ phobos... I'm speaking more categorically, that build systems in
general have advanced beyond the days of make, and it's high time people
started learning about them. While you *could* write an entire
application in assembly language (I did), times have moved on, and we
now have far more suitable tools for the job.


T

-- 
"Computer Science is no more about computers than astronomy is about 
telescopes." -- E.W. Dijkstra

Re: What are the worst parts of D?

[Walter Bright via Digitalmars-d]

On 9/25/2014 6:49 AM, Andrei Alexandrescu wrote:

FWIW I'm glad no random name changes. I've
recently used Rust a bit and the curse of D users as of 6-7 years ago reached
me: most code I download online doesn't compile for obscure reasons, it's nigh
impossible to figure out what the fix is from the compiler error message,
searching online finds outdated documentation that tells me the code should
work, and often it's random name changes (from_iterator to from_iter and such,
or names are moved from one namespace to another).


The name changes cause much disruption and are ultimately pointless changes.



For the stuff we eliminate we should provide good error messages that recommend
the respective idiomatic solutions.


That's normal practice already.

Re: What are the worst parts of D?

[Cliff via Digitalmars-d]

On Thursday, 25 September 2014 at 18:51:13 UTC, H. S. Teoh via
Digitalmars-d wrote:

You don't know if
recompiling after checking out a previous release of your code 
will
actually give you the same binaries that you shipped 2 months 
ago.


To be clear, even if nothing changed, re-running the build may
produce different output.  This is actually a really hard problem
- some build tools actually use entropy when producing their
outputs, and as a result running the exact same tool with the
same parameters in the same [apparent] environment will produce a
subtly different output.  This may be intended (address
randomization) or semi-unintentional (generating a unique GUID
inside a PDB so the debugger can validate the symbols match the
binaries.)  Virtually no build system in use can guarantee the
above in all cases, so you end up making trade-offs - and if you
don't really understand those tradeoffs, you won't trust your
build system.

What else may mess up the perfection of repeatability of your
builds?  Environment variables, the registry (on Windows), any
source of entropy (the PRNG, the system clock/counters, any
network access), etc.

Build engineers themselves don't trust the build tooling because
for as long as we have had the tooling, no one has invested
enough into knowing what is trustworthy or how to make it that
way.  It's like always coding without a typesafe language, but
which "gets the job done."  Until you've spent some time in the
typesafe environment, maybe you can't realize the benefit.
You'll say "well, now I have to type a bunch more crap, and in
most cases it wouldn't have helped me anyway" right up until you
are sitting there at 3AM the night before shipping the product
trying to track down why your Javascript program - I mean build
process - isn't doing what you thought it did.  Just because you
CAN build a massive software system in Javascript doesn't mean
the language is per-se good - it may just mean you are sufficient
motivated to suffer through the pain.  I'd rather make the whole
experience *enjoyable* (hello TypeScript?)

Different people will make different tradeoffs, and I am not here
to tell Andrei or Walter that they *need* a new build system for
D to get their work done - they don't right now.  I'm more
interested in figuring out how to provide a platform to realize
the benefits for build like we have for our modern languages, and
then leveraging that in new ways (like better sharing between the
compiler, debugger, IDEs, test and packaging.)

Re: What are the worst parts of D?

[Ary Borenszweig via Digitalmars-d]

On 9/24/14, 3:20 AM, Jacob Carlborg wrote:

On 24/09/14 07:37, Walter Bright wrote:


So help out!


You always say we should help out instead of complaining. But where are
all the users that want C++ support. Let them implement it instead and
lets us focus on actual D users we have now.



Maybe Facebook needs D to interface with C++?

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 07:42:08PM +0200, Jacob Carlborg via Digitalmars-d 
wrote:
> On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:
> 
> >That's the hallmark of make-based projects.
> 
> This was Ninja actually. But how would the build system know I've
> updated the compiler?
[...]

The compiler and compile flags are inputs to the build rules in SCons.

In my SCons projects, when I change compile flags (possibly for a subset
of source files), it correctly figures out which subset (or the entire
set) of files needs to be recompiled with the new flags. Make fails, and
you end up with an inconsistent executable.

In my SCons projects, when I upgrade the compiler, it recompiles
everything with the new compiler. Make doesn't detect a difference, and
if you make a change and recompile, suddenly you got an executable 80%
compiled with the old compiler and 20% compiled with the new compiler.
Most of the time it doesn't make a difference... but when it does, have
fun figuring out where the problem lies. (Or just make clean; make yet
again... the equivalent of which is basically what SCons would have done
5 hours ago.)

In my SCons projects, when I upgrade the system C libraries, it
recompiles everything that depends on the updated header files *and*
library files. In make, it often fails to detect that the .so's have
changed, so it fails to relink your program. Result: your executable
behaves strangely at runtime due to wrong .so being linked, but the
problem vanishes once you do a make clean; make.

Basically, when you use make, you have to constantly do make clean; make
just to be sure everything is consistent. In SCons, the build system
does it for you -- and usually more efficiently than make clean; make
because it knows exactly what needs recompilation and what doesn't.

In my SCons projects, when I checkout a different version of the sources
to examine some old code and then switch back to the latest workspace,
SCons detects that file contents haven't changed since the last build,
so it doesn't rebuild anything. In make, it thinks the entire workspace
has changed, and you have to wait another half hour while it rebuilds
everything. It doesn't even detect that all intermediate products like
.o's are identical to the last time, so it will painstakingly relink
everything again. SCons will detect when a .o file hasn't changed from
the last build (e.g., you only changed a comment in the source file),
and it won't bother relinking your binaries or trigger any of the
downstream dependencies' rebuilds.

Make-heads find the idea of the compiler being part of the input to a
build rule "strange"; to me, it's common sense. What's strange is the
fact that make doesn't (and can't) guarantee anything about the build --
you don't know for sure whether an incremental build gives you the same
executable as a build from a clean workspace. You don't know if
recompiling after checking out a previous release of your code will
actually give you the same binaries that you shipped 2 months ago. You
don't know if the latest build linked with the latest system libraries.
You don't know if the linked libraries are consistent with each other.
You basically have no assurance of *anything*, except if you make clean;
make. But wait a minute, I thought the whole point of make is
incremental building. If you have to make clean; make *every* *single*
*time*, that completely defeats the purpose, and you might as well just
put your compile commands in a bash script instead, and run that to
rebuild everything from scratch every time. Yeah it's slow, but at least
you know for sure your executables are always what you think they are!
(And in practice, the bash script might actually be faster -- I lost
track of how much time I wasted trying to debug something, only to go
back and make clean; make and discover that the bug vanished. Had I used
the shell script every single time, I could've saved how many hours
spent tracking down these heisenbugs.)


T

-- 
Gone Chopin. Bach in a minuet.

Re: [Semi OT] Language for Game Development talk

[Peter Alexander via Digitalmars-d]

On Thursday, 25 September 2014 at 13:57:17 UTC, Andrei 
Alexandrescu wrote:

On 9/25/14, 4:33 AM, Kagamin wrote:
On Thursday, 25 September 2014 at 09:16:27 UTC, Walter Bright 
wrote:

So how do you tell it to call myfree(p) instead of free(p) ?


Maybe stock malloc/free is enough for him?


That kind of commitment shouldn't be baked into the language. 
That's why RAII and scope are better than his notation. -- 
Andrei


Only if you accept "The Right Way" philosophy. A "Worse is 
Better" person may disagree. There is no "better", it's all 
tradeoffs.

Re: What's blocking DDMD?

[Joakim via Digitalmars-d]

On Thursday, 25 September 2014 at 17:06:48 UTC, Tourist wrote:

Of the failing platforms:
OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is 
crazy)

...

So, this is fixed now, right?


Yep.

https://github.com/D-Programming-Language/dmd/pull/3970

Re: What are the worst parts of D?

[H. S. Teoh via Digitalmars-d]

On Thu, Sep 25, 2014 at 09:18:26PM +0400, Dmitry Olshansky via Digitalmars-d 
wrote:
[...]
> I had an "insanely" complicated one could handle 2 platforms, 3
> emulators and a few custom build steps (including signing binaries),
> cleaning, tracking dependencies with minimal rebuilds. For instance,
> binary need not to be signed again if it's bit for bit the same.
> All of the above was done in about 50 lines, never braking as the
> project progressed, I think it changed only 2-3 times over a year.
>
> I was never able to make a good makefile that wouldn't shit on me in
> some way, like not properly cleaning something or handling errors .
> I'm not even talking about the 10+ LOCs for anything barely useful.

+1. Jives with my experience with SCons as well.


> 25-Sep-2014 01:12, Andrei Alexandrescu пишет:
> >(2) any build system for a project of nontrivial size needs a
> >person/team minding it - never saw such a thing as it's just all
> >automated and it works;
> 
> The question is amount of work, size of file and frequency of changes.
> For instance, Scons easily allows not to change a makefile on every
> single added module, I can't say if make could pull it off.

It can. Except that you can expect things will go horribly wrong if you
so much as breathe in the wrong direction. And when you're dealing with
a multi-person project (i.e., 99% of non-trivial software projects),
expect that people will do stupid things that either breaks the
makefile, or they will make breaking changes to the makefile that will
screw everything up for everyone else.


> >(3) especially if the build system is not that familiar, the role of
> >the build czar is all the more important.
> 
> Somebody (Russel?) was working on D Scons support, how about start to
> capitalize on this work? I'd gladly try to make a scons script for
> phobos/druntime if there is even a tiny chance of apporval.

D support has been merged into mainline SCons, thanks to Russel's
efforts. I've been using his D module for a while now, and find it
generally very C/C++-like, which is perfect for projects that need heavy
interfacing between C/C++ and D. For D-only projects, it's a bit klunky
because it defaults to separate compilation, whereas dmd tends to work
better with whole-program compilation (or at least per-module rather
than per-source-file compilation).

SCons does hit performance barriers when you get into very large
projects (on the magnitude of Mozilla Firefox, or the GTK desktop suite,
for example), but for something the size of dmd/druntime/phobos, you
won't notice the difference at all. In fact, you'd save a lot of time by
not needing to make clean; make every single time you do anything
non-trivial.


> >So the reality is quite a bit more complicated than the shiny city on
> >a hill you describe.
> 
> Most people using make/autotools say build systems are hard, it need
> not to be true but I'm obviously biased.
[...]

I'm biased too, but I'm inclined to think that those people say it's
hard because it *is* hard when the best you got is make and autotools.
:-P


T

-- 
Leather is waterproof.  Ever see a cow with an umbrella?

Re: What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 9/25/14, 10:47 AM, Cliff wrote:

On Thursday, 25 September 2014 at 17:42:09 UTC, Jacob Carlborg
wrote:

On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:


That's the hallmark of make-based projects.


This was Ninja actually. But how would the build system know I've
updated the compiler?


The compiler is an input to the build rule.  Consider the rule:

build: $(CC) my.c -o my.o

what are the dependencies for the rule "build"?

my.c obviously.  Anything the compiler accesses during the
compilation of my.c.  And *the compiler itself*, referenced here
as $(CC).  From a dependency management standpoint, executables
are not special except as running them leads to the discovery of
more dependencies than may be statically specified.


Yah, it only gets odder from there. E.g. all stuff being build must also 
list the rule file itself as a dependency.


FWIW I've seen implications that a better build tool would improve the 
lot of dlang contributors. My response to that would be: I agree that 
Phobos' posix.mak 
(https://github.com/D-Programming-Language/phobos/blob/master/posix.mak) 
is a tad baroque and uses a couple of the more obscure features of make. 
I also consider a few changes to it could have been effected simpler and 
better. However, as far as I can tell it's not a large issue for dlang 
contributors, and to the extent it is, it's not because of make's faults.



Andrei

Re: What are the worst parts of D?

[Andrei Alexandrescu via Digitalmars-d]

On 9/25/14, 10:26 AM, Atila Neves wrote:

On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg wrote:

On 25/09/14 09:38, Atila Neves wrote:


Here's one: having to manually generate the custom main file for
unittest builds. There's no current way (or at least there wasn't when I
brought it up in the dub forum) to tell it to autogenerate a D file from
a dub package and list it as a dependency of the unittest build.


Hmm, I haven't used Dub to run unit tests. Although, DMD has a "-main"
flag that adds an empty main function.


I don't want an empty main function. I want the main function and the
file it's in to be generated by the build system.


Why would be the focus on the mechanism instead of the needed outcome? 
-- Andrei

Re: What are the worst parts of D?

[Cliff via Digitalmars-d]

On Thursday, 25 September 2014 at 17:42:09 UTC, Jacob Carlborg
wrote:

On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:


That's the hallmark of make-based projects.


This was Ninja actually. But how would the build system know 
I've updated the compiler?


The compiler is an input to the build rule.  Consider the rule:

build: $(CC) my.c -o my.o

what are the dependencies for the rule "build"?

my.c obviously.  Anything the compiler accesses during the
compilation of my.c.  And *the compiler itself*, referenced here
as $(CC).  From a dependency management standpoint, executables
are not special except as running them leads to the discovery of
more dependencies than may be statically specified.

Re: What are the worst parts of D?

[Jacob Carlborg via Digitalmars-d]

On 2014-09-25 16:01, Wyatt wrote:


I might look at the "modern alternative" once it supports debugging
64-bit executables. :/


LLDB supports OS X, Linux and FreeBSD. 32 and 64bit on all of these 
platforms [1]. Are you looking for Windows support?


[1] http://lldb.llvm.org/

--
/Jacob Carlborg

Re: What are the worst parts of D?

[Jacob Carlborg via Digitalmars-d]

On 2014-09-25 16:23, H. S. Teoh via Digitalmars-d wrote:


That's the hallmark of make-based projects.


This was Ninja actually. But how would the build system know I've 
updated the compiler?


--
/Jacob Carlborg

Re: What are the worst parts of D?

[Atila Neves via Digitalmars-d]

On Thursday, 25 September 2014 at 14:25:25 UTC, H. S. Teoh via 
Digitalmars-d wrote:
On Thu, Sep 25, 2014 at 03:47:22PM +0200, Jacob Carlborg via 
Digitalmars-d wrote:

On 25/09/14 08:39, H. S. Teoh via Digitalmars-d wrote:

[...]
>But even then, I *did* run into the problem of 
>non-reproducible
>builds with dmd. So there's still a blemish there. :-P  Makes 
>me want

>to alias `make` to `make clean; make` just for this alone

I don't think the "clean" action can be completely excluded. I
recently tried to build a project, without running "clean", 
and got
some unexpected errors. Then I remembered I had just installed 
a new

version of the compiler.

[...]

That's the hallmark of make-based projects. SCons projects, 
OTOH, almost
never needs to do that (except if you totally screwed up your 
SCons
scripts). The super-complicated SCons script that I described 
in another
post? I don't even remember that last *year* when I had to do 
the
equivalent of a clean. I've been updating, branching, merging 
the
workspace for years now, and it Just Builds -- correctly at 
that.


+1. I remember the days where I dealt with hand-written makefiles 
and running "make clean" just to be sure. I don't miss them.


If you ever _need_ to type "make clean" then the build system is 
broken. Simple as. It's analogous to deleting the object file to 
make sure the compiler does its job properly.


Atila

Re: What are the worst parts of D?

[Atila Neves via Digitalmars-d]

On Thursday, 25 September 2014 at 13:51:17 UTC, Jacob Carlborg 
wrote:

On 25/09/14 09:38, Atila Neves wrote:

Here's one: having to manually generate the custom main file 
for
unittest builds. There's no current way (or at least there 
wasn't when I
brought it up in the dub forum) to tell it to autogenerate a D 
file from
a dub package and list it as a dependency of the unittest 
build.


BTW, I would say that's a minor issue, far from begin enough to 
create a completely new build system.


I agree. That's why I haven't written a build system yet. 
However, larger projects need this kind of thing. If I were 
working on a team of 20+ devs writing D, I'd eventually need it. 
I'd consider SCons, CMake, etc. but I'd still need dub for 
package management.


Atila

Re: What are the worst parts of D?

[Atila Neves via Digitalmars-d]

On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg 
wrote:

On 25/09/14 09:38, Atila Neves wrote:

Here's one: having to manually generate the custom main file 
for
unittest builds. There's no current way (or at least there 
wasn't when I
brought it up in the dub forum) to tell it to autogenerate a D 
file from
a dub package and list it as a dependency of the unittest 
build.


Hmm, I haven't used Dub to run unit tests. Although, DMD has a 
"-main" flag that adds an empty main function.


I don't want an empty main function. I want the main function and 
the file it's in to be generated by the build system.


Atila

Re: What are the worst parts of D?

[Dmitry Olshansky via Digitalmars-d]

25-Sep-2014 01:12, Andrei Alexandrescu пишет:

On 9/24/14, 1:10 PM, H. S. Teoh via Digitalmars-d wrote:

That's unfortunate indeed. I wish I could inspire them as to how cool a
properly-done build system can be.

[snip]

That's all nice. However: (1) the truth is there's no clear modern build
tool that has "won" over make;


Pretty much any of them is better, and will easily handle the size of 
phobos/druntime/dmd projects.



oh there's plenty of them, but each has
its own quirks that makes it tenuous to use;


Somehow must indicate that make doesn't have them (and in incredible 
capacity)?


Most of my Scons scripts are under 10 lines, in fact 2-3 LOCs.

I had an "insanely" complicated one could handle 2 platforms, 3 
emulators and a few custom build steps (including signing binaries), 
cleaning, tracking dependencies with minimal rebuilds. For instance, 
binary need not to be signed again if it's bit for bit the same.
All of the above was done in about 50 lines, never braking as the 
project progressed, I think it changed only 2-3 times over a year.


I was never able to make a good makefile that wouldn't shit on me in 
some way, like not properly cleaning something or handling errors . I'm 
not even talking about the 10+ LOCs for anything barely useful.



(2) any build system for a
project of nontrivial size needs a person/team minding it - never saw
such a thing as it's just all automated and it works;


The question is amount of work, size of file and frequency of changes. 
For instance, Scons easily allows not to change a makefile on every 
single added module, I can't say if make could pull it off.



(3) especially if
the build system is not that familiar, the role of the build czar is all
the more important.


Somebody (Russel?) was working on D Scons support, how about start to 
capitalize on this work? I'd gladly try to make a scons script for 
phobos/druntime if there

is even a tiny chance of apporval.


So the reality is quite a bit more complicated than the shiny city on a
hill you describe.


Most people using make/autotools say build systems are hard, it need not 
to be true but I'm obviously biased.


--
Dmitry Olshansky

Re: What are the worst parts of D?

[Paulo Pinto via Digitalmars-d]

Am 25.09.2014 07:30, schrieb Walter Bright:

On 9/24/2014 9:43 PM, H. S. Teoh via Digitalmars-d wrote:

printf debugging FTW! :-P


There's more than that, but yeah. Most of my types I'll write a "pretty
printer" for, and use that. No conceivable debugger can guess how I want
to view my data.

For example, I can pretty-print an Expression as either a tree or in
infix notation.



In Visual Studio I can define formatters for data structures. Most of 
the STL containers are already configured out of the box.


Additionally, I don't know another IDE that matches Visual Studio 
debugging capabilities for multi-core and graphics programming.


And C++ debugger is still catching with what .NET debugger can do for 
multi-core programming.


--
Paulo

Re: What's blocking DDMD?

[Tourist via Digitalmars-d]

Of the failing platforms:
OSX32: https://github.com/braddr/d-tester/pull/35 (OSX32 is 
crazy)

...

So, this is fixed now, right?

Re: DIP31: compile time paradoxes defined. Requested examples added

[Timon Gehr via Digitalmars-d]

On 09/25/2014 06:53 AM, deadalnix wrote:

http://wiki.dlang.org/DIP31

I've been asked to add examples of resolution for various cases (hint
they all error out).


"This DIP define their behavior properly, "

Not really. For one thing, at the moment, the DIP doesn't really make 
clear when and how a 'dependency' occurs.


"Mixin are resolved in order, which mean the first mixin is resolved first."

What do you mean? There is no order; there is no 'first' mixin.

Re: What are the worst parts of D?

[eles via Digitalmars-d]

On Thursday, 25 September 2014 at 13:50:10 UTC, Jacob Carlborg 
wrote:

On 25/09/14 09:38, Atila Neves wrote:

Here's one: having to manually generate the custom main file 
for
unittest builds. There's no current way (or at least there 
wasn't when I
brought it up in the dub forum) to tell it to autogenerate a D 
file from
a dub package and list it as a dependency of the unittest 
build.


Hmm, I haven't used Dub to run unit tests. Although, DMD has a 
"-main" flag that adds an empty main function.


Andrei spoke about an idiom that they constantly use at Facebok, 
because there aparrently nobody runs *main and unittests*. So 
they keep a special empty main for the -unittest version.


If tha time to clean up D has come, maybe it is the time to make 
that idiom the default behaviour of the flag. He posted that 
thing somewhere in the forum, but cannot find it right now.


Real usage is good for learning.