date:20170524

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

Martin Nowak  changed:

   What|Removed |Added

Summary|each scope class references |[scope] each scope class
   |adds another delete call|references adds another
   ||delete call

--

[Issue 17429] each scope class references adds another delete call

2017-05-24 Thread Jack Stouffer via Digitalmars-d-announce

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

Martin Nowak  changed:

   What|Removed |Added

Summary|scope class references  |each scope class references
   |inject additional delete|adds another delete call
   |calls   |

--

Re: Faster Command Line Tools in D


On Wednesday, 24 May 2017 at 21:46:10 UTC, cym13 wrote:
I am disappointed because there are so many good things to say 
about this, so many good questions or remarks to make when not 
familiar with the language, and yet all we get is "Meh, this 
benchmark shows nothing of D's speed against Python".


Wouldn't be the first time 
https://news.ycombinator.com/item?id=10828450

Re: DIP 1008 Preliminary Review Round 1

2017-05-24 Thread Walter Bright via Digitalmars-d


On 5/23/2017 3:40 PM, Martin Nowak wrote:
Why does it have to be refcounted? Seems like there is only ever one reference 
to the current exception (the catch variable).


Rethrowing the catch variable makes for 2 references.


Has staticError been considered? It has a potential issue with multiple nested 
exceptions, but otherwise works fine.
https://github.com/dlang/druntime/blob/bc832b18430ce1c85bf2dded07bbcfe348ff0813/src/core/exception.d#L683 


Doesn't work for chained exceptions.

Re: Faster Command Line Tools in D

2017-05-24 Thread Walter Bright via Digitalmars-d-announce


On 5/24/2017 3:56 PM, Jon Degenhardt wrote:
Its not easy writing an article that doesn't draw some form of criticism. FWIW, 
the reason I gave a Python example is because it is very commonly used for this 
type of problem and the language is well suited to it. A second reason is that 
I've seen several posts where someone has tried to rewrite a Python program like 
this in D, start with `split`, and wonder how to make it faster. My hope is that 
this will clarify how to achieve this.


Another goal of the article was to describe how performance in the TSV Utilities 
had been achieved. The article is not about the TSV Utilities, but discussing 
both the benchmark results and how they had been achieved would be a very long 
article.


Any time one writes an article comparing speed between languages X and Y, 
someone gets their ox gored and will bitterly complain about how unfair the 
article is (though I noticed that none of the complainers wrote a faster Python 
version). Even if you tried to optimize the Python program, you'll be inevitably 
accused of deliberately not doing it right.


The nadir of this for me was when I compared Digital Mars C++ code with DMD. 
Both share the same optimizer and back end, yet I was accused of "sabotaging" my 
own C++ compiler in order to make D look better !! Me, I just don't do public 
comparison benchmarking anymore. It's a waste of time arguing with people about it.


I thought you wrote a fine article, and the criticism about the Python code was 
unwarranted (especially since nobody suggested better code), because the article 
was about optimizing D code, not optimizing Python.

Re: Value closures (no GC allocation)

2017-05-24 Thread Stanislav Blinov via Digitalmars-d


On Thursday, 25 May 2017 at 04:53:14 UTC, Mike Parker wrote:
On Thursday, 25 May 2017 at 03:14:14 UTC, Stanislav Blinov 
wrote:




Mike, I've read that README several times over. Yes, a mistake 
was made, a number self-assigned. Yes, that is not how it's 
done. Yes, we know. Yes. Thanks for the reminder. All is fixed.


Thanks. I wasn't criticizing. It wasn't fixed when I clicked 
the link, so I just wanted to make sure everyone's on the same 
page. I can't assume everyone has gone over the README.


Sigh... You're right. We should've renamed the file at the same 
time as removing the number from the contents, because 
"internets". And I shouldn't have snapped like that. I apologize.

[Issue 17429] New: scope class references inject additional delete calls

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

  Issue ID: 17429
   Summary: scope class references inject additional delete calls
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
class Klazz
{
__gshared size_t count;
~this()
{
++count;
}
}

void main()
{
auto s = new Klazz;
{
scope s2 = s; // calls delete even though it does not own s
}
assert(Klazz.count == 0);
}
CODE
dmd -run bug

--

Re: Value closures (no GC allocation)

2017-05-24 Thread Mike Parker via Digitalmars-d


On Thursday, 25 May 2017 at 03:14:14 UTC, Stanislav Blinov wrote:



Mike, I've read that README several times over. Yes, a mistake 
was made, a number self-assigned. Yes, that is not how it's 
done. Yes, we know. Yes. Thanks for the reminder. All is fixed.


Thanks. I wasn't criticizing. It wasn't fixed when I clicked the 
link, so I just wanted to make sure everyone's on the same page. 
I can't assume everyone has gone over the README.

update list of organisations using D to refer to blog posts and talks

2017-05-24 Thread Laeeth Isharc via Digitalmars-d

Could we try to keep the list of organisations using D updated to 
include links to talks given since the list was made?  Eg Weka, 
Remedy Games.


Similarly could we add blog posts (eg recent one on eBay) to the 
list as we do for talks.


Maybe we could add some more concise quotes as well to this page. 
 Eg Tamedia say "D is not only a highly productive language, but 
also a great hiring filter."  But nothing for Weka.


If we could contact Netflix to get their confirmation and 
approval to mention their use of D for machine learning, I think 
their name would carry some weight.


Bear in mind that this page may be visited by people that have 
influence on decisions by their organisations, and who are just 
taking a quick look and won't dig deeper unless their interest is 
piqued.


Then also, on the front page under Community there should be a 
"Notable Projects" page for non-commercial open-source projects 
like Tilix (nee Terminix).


Finally - I think having a "channels" or domains page that gives 
a primer on domain-specific resources available would make it a 
bit easier for people looking into the language.  Eg 
bioinformatics, numerical computing, automated translation from 
other languages, web services, etc.  The knowledge is there, but 
it's a bit fragmented.


I would do myself, but don't have so much time unfortunately.

Thanks.


Laeeth.

[Issue 17422] [scope] class reference not initialized as scope variable

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

--- Comment #1 from Walter Bright  ---
https://github.com/dlang/dmd/pull/6826

--

Re: std.functional.memoize : thread local or __gshared memoization?

2017-05-24 Thread Stanislav Blinov via Digitalmars-d


On Thursday, 25 May 2017 at 01:17:41 UTC, Timothee Cour wrote:

thanks; i think docs for this should still make that clear.

How about adding memoizeShared for shared variables?
There definitely are use cases for this.



Perhaps we should first actually properly document and implement 
what shared *is*.

Re: Value closures (no GC allocation)

2017-05-24 Thread Stanislav Blinov via Digitalmars-d


On Thursday, 25 May 2017 at 03:42:11 UTC, Adam D. Ruppe wrote:
On Thursday, 25 May 2017 at 03:30:38 UTC, Stanislav Blinov 
wrote:

Captures, if any, should be explicit. That is all :)


The current behavior is fine in most cases. The explicit 
by-value capture handles the remaining cases.


In my opinion, it is not, because it's utterly silent unless you 
either stumble upon it via @nogc or a compiler switch.


By inference, adding capture syntax at all will also 
complicate the whole thing.


Yeah, there's some complication in adding it but it is worth it 
because it gives something new without breaking anything old.



P.S. have you seen the TODO at the bottom of that section?


Yeah, I'm EXTREMELY against removing the current behavior. I'd 
kill the whole thing just to avoid that.


I understand perfectly, wasn't exactly easy contemplating that 
"maybe" either. In any case, we should not get ahead of 
ourselves. I'm not insisting on that particular change, I've 
brought it up for consideration, opened a discussion, and it 
looks like it worked :)

Re: Value closures (no GC allocation)


On Thursday, 25 May 2017 at 03:30:38 UTC, Stanislav Blinov wrote:

Captures, if any, should be explicit. That is all :)


The current behavior is fine in most cases. The explicit by-value 
capture handles the remaining cases.


By inference, adding capture syntax at all will also complicate 
the whole thing.


Yeah, there's some complication in adding it but it is worth it 
because it gives something new without breaking anything old.



P.S. have you seen the TODO at the bottom of that section?


Yeah, I'm EXTREMELY against removing the current behavior. I'd 
kill the whole thing just to avoid that.

Re: Value closures (no GC allocation)

2017-05-24 Thread Stanislav Blinov via Digitalmars-d


On Thursday, 25 May 2017 at 03:10:04 UTC, Adam D. Ruppe wrote:



"Currently FunctionLiterals that capture their outer context 
(i.e. closures/delegates) require an allocation and the garbage 
collector. "



Not necessarily true, make sure you actually mention `scope 
delegate` and `alias` params that do not return it. Those 
capture but do not allocate.


It's an infant document, wording is out there somewhere...

"We will be proposing a syntax redundant w.r.t. current 
behavior (i.e. capture by reference), so maybe we should 
consider proposing deprecation?"


Don't do that.


Why not? I, personally, have a simple, but solid, justification:

Captures, if any, should be explicit. That is all :)

That is solely my opinion, hence the cautious "maybe"...


"Capture by reference"

I'm against that, no need adding it and it complicates the 
whole thing. For example, "ref int _i;" as a struct member; 
there's no such thing in D. (the compiler could do it but 
still). And you'd have to explain the lifetime. Just no point 
doing this, the current behavior is completely fine for this.


By inference, adding capture syntax at all will also complicate 
the whole thing. IMHO, we either should have one, or the other, 
but not both. P.S. have you seen the TODO at the bottom of that 
section?

Re: Value closures (no GC allocation)

2017-05-24 Thread Stanislav Blinov via Digitalmars-d


On Thursday, 25 May 2017 at 01:18:22 UTC, Mike Parker wrote:

label:
if (self.bored) goto disclaimer;


We're well aware. The file name is not indicative of anything.



The README outlines the procedure for DIP submission, including 
the format of the filename. The concern is that if you include 
number in the filename, it opens the door to people referring 
to it by that number. We want to avoid that.


[1] https://github.com/dlang/DIPs/blob/master/README.md


// warning, loops until self.bored is true
goto label;

disclaimer:

Mike, I've read that README several times over. Yes, a mistake 
was made, a number self-assigned. Yes, that is not how it's done. 
Yes, we know. Yes. Thanks for the reminder. All is fixed.

Re: Value closures (no GC allocation)


On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:
If you're interested in contributing, please let me know and 
I'll add you as a collaborator.


can i just edit it on the site?

but a few comments:

"Currently FunctionLiterals that capture their outer context 
(i.e. closures/delegates) require an allocation and the garbage 
collector. "



Not necessarily true, make sure you actually mention `scope 
delegate` and `alias` params that do not return it. Those capture 
but do not allocate.



"We will be proposing a syntax redundant w.r.t. current behavior 
(i.e. capture by reference), so maybe we should consider 
proposing deprecation?"


Don't do that.

"// or simply, using existing syntax:
//auto l = () => writeln("hello!");"

That existing one will actually make a function, not a delegate, 
since it doesn't access any locals.


"struct anonymous_l"

That should be `static struct`.

"Capture by reference"

I'm against that, no need adding it and it complicates the whole 
thing. For example, "ref int _i;" as a struct member; there's no 
such thing in D. (the compiler could do it but still). And you'd 
have to explain the lifetime. Just no point doing this, the 
current behavior is completely fine for this.

Re: how to define a struct without padding

2017-05-24 Thread aki via Digitalmars-d-learn


On Thursday, 25 May 2017 at 01:34:35 UTC, Adam D. Ruppe wrote:

align(1) struct NAME {
   align(1):
  members
}


My problem is resolved. Thank you for the quick reply.

Thanks,
Aki

Re: how to define a struct without padding

2017-05-24 Thread Adam D. Ruppe via Digitalmars-d-learn


On Thursday, 25 May 2017 at 01:25:44 UTC, aki wrote:

align(1) struct WAVEFORMATEX {


align(1) on the outside removes padding from the end.

You also need `align(1):` on the inside to move all the padding 
to the end.



align(1) struct NAME {
   align(1):
  members
}

how to define a struct without padding

2017-05-24 Thread aki via Digitalmars-d-learn


Hi,

This is a code ported from some windows C program.
It is the Windows WAVE file header definition.
The field layout is the same with C,
but it has extra 2 bytes at the end,
sizeof(WAVEHEADER) in C is 46 while WAVEHEADER.sizeof in D is 48.
Why it still have padding in spite of "align(1)" ?
How can I remove extra padding bytes?

module main;
import std.stdio;
alias ushort WORD;
alias uint DWORD;

align(1) struct WAVEFORMATEX {
WORDwFormatTag; /* format type */
WORDnChannels;  /* number of channels (i.e. 
mono, stereo...) */

DWORD   nSamplesPerSec; /* sample rate */
DWORD   nAvgBytesPerSec;/* for buffer estimation */
WORDnBlockAlign;/* block size of data */
WORDwBitsPerSample; /* number of bits per sample 
of mono data */
WORDcbSize; /* the count in bytes of the 
size of */

/* extra information (after cbSize) */
};

align(1) struct WAVEHEADER {
char[4] szRIFF;
int lRIFFSize;
char[4] szWave;
char[4] szFmt;
int lFmtSize;
WAVEFORMATEXwfex;
char[4] szData;
int lDataSize;
};

void main() {
writeln(WAVEHEADER.sizeof); // 48; but it must be 46
}

Thanks,
Aki

Re: Value closures (no GC allocation)

2017-05-24 Thread Mike Parker via Digitalmars-d


On Thursday, 25 May 2017 at 01:13:08 UTC, Stanislav Blinov wrote:

On Thursday, 25 May 2017 at 00:34:45 UTC, MysticZach wrote:


As a matter of procedure, you don't want to assign a DIP 
number to it yourself. I'm pretty sure that is for the DIP 
manager.


We're well aware. The file name is not indicative of anything.


The README outlines the procedure for DIP submission, including 
the format of the filename. The concern is that if you include 
number in the filename, it opens the door to people referring to 
it by that number. We want to avoid that.


[1] https://github.com/dlang/DIPs/blob/master/README.md

Re: std.functional.memoize : thread local or __gshared memoization?

2017-05-24 Thread Timothee Cour via Digitalmars-d

thanks; i think docs for this should still make that clear.

How about adding memoizeShared for shared variables?
There definitely are use cases for this.


On Wed, May 24, 2017 at 5:19 PM, Jonathan M Davis via Digitalmars-d
 wrote:
> On Wednesday, May 24, 2017 16:56:49 Timothee Cour via Digitalmars-d wrote:
>> I could look at source to figure it out but others might wonder and I
>> couldn't find it in the docs in
>> https://dlang.org/library/std/functional/memoize.html whether memoize
>> works per thread (thread local) or globally (__gshared)
>
> Definitely thread-local, and there would be problems if it were shared,
> since for that to work properly, it would really need to be given either
> shared data or data that implicitly converted to shared. And while __gshared
> might skirt the compiler yelling at you, it would have the same issues; it's
> just that the compiler wouldn't be yelling at you about them, so it would be
> harder to catch them and more likely that you'd get weird,
> hard-to-track-down bugs.
>
> - Jonathan M Davis
>

Re: Value closures (no GC allocation)

2017-05-24 Thread Stanislav Blinov via Digitalmars-d


On Thursday, 25 May 2017 at 00:34:45 UTC, MysticZach wrote:


I've created a very WIP draft here:
https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md

If you're interested in contributing, please let me know and 
I'll add you as a collaborator.


As a matter of procedure, you don't want to assign a DIP number 
to it yourself. I'm pretty sure that is for the DIP manager.


We're well aware. The file name is not indicative of anything.

Re: Value closures (no GC allocation)

2017-05-24 Thread MysticZach via Digitalmars-d


On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:

On Monday, 22 May 2017 at 15:17:24 UTC, Stanislav Blinov wrote:

On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote:

On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
Blah. Well, let's go ahead and formally propose the C++ 
syntax, our library solutions are all fat.


Are you going to create a DIP for this? I would be happy to 
contribute, but I don't feel confident enough to create a DIP 
on my own (I just started learning the language) :)


The three of us could do it together through the magics of 
github.


I've created a very WIP draft here:
https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md

If you're interested in contributing, please let me know and 
I'll add you as a collaborator.


As a matter of procedure, you don't want to assign a DIP number 
to it yourself. I'm pretty sure that is for the DIP manager.

[Issue 17424] Add optional errors/static analysis

2017-05-24 Thread Stefan Koch via Digitalmars-d-announce

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

--- Comment #5 from Jonathan M Davis  ---
I would point out that optional errors would actually be extremely bad in D
because of compile-time introspection. What code worked and compiled would
change based on the compiler flags, effectively meaning that the language
definition changed via the compiler flags. We already have problems with that
thanks to -w (we really should just be made to do the same as -wi and then
phase one of them out). To get the diagnostics that you're looking for without
creating problems with compile-time introspection, there would need to be some
sort of option that caused compilation to fail (as occurs with an error) when
they occurred but which would be ignored for the purposes of compile-time
introspection.

--

Re: std.functional.memoize : thread local or __gshared memoization?

2017-05-24 Thread Jonathan M Davis via Digitalmars-d

On Wednesday, May 24, 2017 16:56:49 Timothee Cour via Digitalmars-d wrote:
> I could look at source to figure it out but others might wonder and I
> couldn't find it in the docs in
> https://dlang.org/library/std/functional/memoize.html whether memoize
> works per thread (thread local) or globally (__gshared)

Definitely thread-local, and there would be problems if it were shared,
since for that to work properly, it would really need to be given either
shared data or data that implicitly converted to shared. And while __gshared
might skirt the compiler yelling at you, it would have the same issues; it's
just that the compiler wouldn't be yelling at you about them, so it would be
harder to catch them and more likely that you'd get weird,
hard-to-track-down bugs.

- Jonathan M Davis

std.functional.memoize : thread local or __gshared memoization?

2017-05-24 Thread Timothee Cour via Digitalmars-d

I could look at source to figure it out but others might wonder and I
couldn't find it in the docs in
https://dlang.org/library/std/functional/memoize.html whether memoize
works per thread (thread local) or globally (__gshared)

Re: DIP 1008 Preliminary Review Round 1

2017-05-24 Thread MysticZach via Digitalmars-d

On Tuesday, 23 May 2017 at 22:40:43 UTC, Martin Nowak wrote:
The proposal is a very mechanical fix, throwing several special
cases at one specific problem.
Why does it have to be refcounted? Seems like there is only
ever one reference to the current exception (the catch
variable).
The only thing that seems necessary is to require scope on
catch variable declarations, so that people do not escape the
class reference, then this info might be used by the runtime to
free exception objects after the catch handler is done.

Amaury put a bit more words into that.
http://forum.dlang.org/post/gtqsojgqqaorubcsn...@forum.dlang.org

Has staticError been considered? It has a potential issue with
multiple nested exceptions, but otherwise works fine.

https://github.com/dlang/druntime/blob/bc832b18430ce1c85bf2dded07bbcfe348ff0813/src/core/exception.d#L683

I'm trying to understand your and Amaury's point. Normally, when
you say `new` you get memory from the GC allocator. The @nogc
attribute is supposed to prevent this, if I understand it
correctly. Are you saying that `@nogc` as such is misconceived,
because what a good language feature should really be doing is
identifying and preventing new memory that _can't_ be
deterministically destroyed? Is the problem here with the @nogc
attribute? Because I think Walter's goal with this DIP is to make
it so that you can put @nogc on _called_ functions that throw
using `new`. Whereas your solution is to ignore that `new
Exception` allocation, on account of the fact that you can
deterministically destroy the Exception, provided you use `scope`
catch blocks at, or above, the call site. Your solution might
actually have its priorities straight, and `@nogc` may be
designed badly because it clumps all GC allocations into one big
basket. However, getting new memory from the GC still could
trigger a collection cycle, which is what @nogc was created for,
and simply knowing that you can reliably destroy the allocated
memory doesn't change that.

Thus, if I understand correctly, you and Amaury are arguing that
`@nogc` as currently designed is a false goal to be chasing, that
the more important goal is memory that can be deterministically
destroyed, and therefore it distresses you that the language may
be altered to chase the false prize of `@nogc` everywhere,
instead of focusing on a real prize worth attaining?

Bultins .reverse and .sort are likely going to be removed soon.


Hi guys,

I just finished the PR to remove the builtin array properties 
.sort and .reverse.


while the dmd changes were trivial fixing all the broken tests 
were not.
Even tests that were supposed to call std.algorithm.sort turned 
out to use the property by accident; (because of a small error 
which caused the sort template not to instantiate).


If you do have code which still relays on this, please update.

Cheers,
Stefan

Re: Faster Command Line Tools in D

2017-05-24 Thread Jon Degenhardt via Digitalmars-d-announce


On Wednesday, 24 May 2017 at 21:46:10 UTC, cym13 wrote:

On Wednesday, 24 May 2017 at 21:34:08 UTC, Walter Bright wrote:

It's now #4 on the front page of Hacker News:

https://news.ycombinator.com/news


The comments on HN are useless though, everybody went for the 
"D versus Python" thing and seem to complain that it's doing a 
D/Python benchmark while only talking about D 
optimization...even though optimizing D is the whole point of 
the article. In the same way they rant against the fact that 
many iterations on the D script are shown while it is obviously 
to give different tricks while being clear on what trick gives 
what.


I am disappointed because there are so many good things to say 
about this, so many good questions or remarks to make when not 
familiar with the language, and yet all we get is "Meh, this 
benchmark shows nothing of D's speed against Python".


Its not easy writing an article that doesn't draw some form of 
criticism. FWIW, the reason I gave a Python example is because it 
is very commonly used for this type of problem and the language 
is well suited to it. A second reason is that I've seen several 
posts where someone has tried to rewrite a Python program like 
this in D, start with `split`, and wonder how to make it faster. 
My hope is that this will clarify how to achieve this.


Another goal of the article was to describe how performance in 
the TSV Utilities had been achieved. The article is not about the 
TSV Utilities, but discussing both the benchmark results and how 
they had been achieved would be a very long article.


--Jon

Re: Faster Command Line Tools in D

2017-05-24 Thread cym13 via Digitalmars-d-announce


On Wednesday, 24 May 2017 at 21:34:08 UTC, Walter Bright wrote:

It's now #4 on the front page of Hacker News:

https://news.ycombinator.com/news


The comments on HN are useless though, everybody went for the 
"D versus Python" thing and seem to complain that it's doing a 
D/Python benchmark while only talking about D optimization...even 
though optimizing D is the whole point of the article. In the 
same way they rant against the fact that many iterations on the D 
script are shown while it is obviously to give different tricks 
while being clear on what trick gives what.


I am disappointed because there are so many good things to say 
about this, so many good questions or remarks to make when not 
familiar with the language, and yet all we get is "Meh, this 
benchmark shows nothing of D's speed against Python".

[Issue 17428] [scope] class field assignment allows to escape scope parameters

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

--- Comment #1 from Martin Nowak  ---
Somewhat similar to issue 17370.

--

[Issue 17428] New: [scope] class field assignment allows to escape scope parameters

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

  Issue ID: 17428
   Summary: [scope] class field assignment allows to escape scope
parameters
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Keywords: safe
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

cat > bug.d << CODE
class Klazz
{
void set(scope int* p) @safe
{
_p = p; // should error, works for structs
}

int* _p;
}

Klazz test() @safe
{
int a;
auto p = new Klazz();
p.set();
return p;
}
CODE

dmd -c bug -dip1000

--

[Issue 17388] [scope] no escape analysis for auto return scope members

2017-05-24 Thread Walter Bright via Digitalmars-d-announce

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||safe
 CC||c...@dawg.eu
Summary|[DIP1000] no escape |[scope] no escape analysis
   |analysis for auto return|for auto return scope
   |scope members   |members

--

Re: Faster Command Line Tools in D


It's now #4 on the front page of Hacker News:

https://news.ycombinator.com/news

Re: Value closures (no GC allocation)

2017-05-24 Thread Stanislav Blinov via Digitalmars-d


On Wednesday, 24 May 2017 at 20:15:37 UTC, Vittorio Romeo wrote:


I've created a very WIP draft here:
https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md

If you're interested in contributing, please let me know and 
I'll add you as a collaborator.


Yep, I've made a small PR to make myself visible :)

Re: DMD VS2017 Support

2017-05-24 Thread Jolly James via Digitalmars-d

On Wednesday, 24 May 2017 at 03:21:56 UTC, Vladimir Panteleev 
wrote:

On Tuesday, 23 May 2017 at 23:11:30 UTC, Jolly James wrote:
Come one, let's be ones: If DMD has no x64 linker, VS 
integration is not a bit optional.


Unlike some other operating systems, 64-bit Windows versions 
can run 32-bit software just fine. If you require targeting 
Win64 (or the Microsoft C runtime), that is specific to your 
use case.


That's true. But when D's GC does not trigger early enough, my 
program runs out of memory (due to the 2 GB limit of 32 bit 
process), x64 solves this more or less. As a side note: I am 
talking about allocating huge arrays.



And, again, Visual Studio is not required if you want to target 
Win64 - only the necessary toolchain components (linker and C 
runtime), which you can also obtain from an SDK.


So you are telling me "not working at all" is not worth 
releasing a fix? xD


Again, everything should be already working. We are talking 
about a convenience feature that automatically sets up the D 
compiler's configuration file, nothing more. That's all there 
is to the "integration". You can trivially do the same thing by 
hand, or set up your environment accordingly - all in a 
fraction of the time it took you to write these pointless 
complaints on this forum.


I admit, you are right in some points. Nevertheless, have you 
ever tried letting a novice configuring this stuff? The 'sc.ini' 
is neither easy to read nor logic. In my particular case I am 
overchallenged by this task.

Re: Ali's slides from his C++Now talk

2017-05-24 Thread Jonathan M Davis via Digitalmars-d

On Wednesday, May 24, 2017 13:18:37 Ali Çehreli via Digitalmars-d wrote:
> On 05/24/2017 08:19 AM, Manu via Digitalmars-d wrote:
> > On 24 May 2017 at 09:31, Joakim via Digitalmars-d
> >
> > Hehe, I'm honoured to be quoted... verbatim :)
>
> Sorry for trimming the last part of your quote. ;)

Well, you have to cut it off at some point, or you're just repeating
everything that he's ever said since the start of the quote. :)

- Jonathan M Davis

Re: Ali's slides from his C++Now talk

2017-05-24 Thread Ali Çehreli via Digitalmars-d


On 05/24/2017 08:19 AM, Manu via Digitalmars-d wrote:

On 24 May 2017 at 09:31, Joakim via Digitalmars-d



Hehe, I'm honoured to be quoted... verbatim :)


Sorry for trimming the last part of your quote. ;)

Ali

Re: Value closures (no GC allocation)

2017-05-24 Thread Vittorio Romeo via Digitalmars-d


On Monday, 22 May 2017 at 15:17:24 UTC, Stanislav Blinov wrote:

On Monday, 22 May 2017 at 14:06:54 UTC, Vittorio Romeo wrote:

On Sunday, 21 May 2017 at 20:25:14 UTC, Adam D. Ruppe wrote:
Blah. Well, let's go ahead and formally propose the C++ 
syntax, our library solutions are all fat.


Are you going to create a DIP for this? I would be happy to 
contribute, but I don't feel confident enough to create a DIP 
on my own (I just started learning the language) :)


The three of us could do it together through the magics of 
github.


I've created a very WIP draft here:
https://github.com/SuperV1234/DIPs/blob/master/DIPs/DIP1009.md

If you're interested in contributing, please let me know and I'll 
add you as a collaborator.

Re: Runtime?

2017-05-24 Thread Jon Degenhardt via Digitalmars-d-announce


On Wednesday, 24 May 2017 at 15:22:55 UTC, Stanislav Blinov wrote:

It's a bit of pre-allocation and some internal bookkeeping.

void main()
{
import std.stdio;
import core.memory;
writeln(GC.stats);
}

//   used, free
Stats(256, 1048320)

The remaining .7Mb could probably be attributed to some 
internal data structures.


Thanks, it places D in a better limelight.

I assume that from the 0.7MB, part of it is the executable ( 
0.24MB ) that is loaded into memory.


+1 for the answer. :)

Re: Faster Command Line Tools in D


On Wednesday, 24 May 2017 at 17:36:29 UTC, cym13 wrote:

On Wednesday, 24 May 2017 at 13:39:57 UTC, Mike Parker wrote:
[...snip...]

A bit off topic but I really like that we still get quality 
content such as this post on this blog. Sustained quality is 
hard job and I thank everyone involved for that.


The complement to the community is well deserved, thank you for 
including this post in the company. In this case, the post 
benefited from some really excellent review feedback and Mike 
made the publication side really easy.


--Jon

Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks

2017-05-24 Thread Andrei Alexandrescu via Digitalmars-d

BTW the best outcome of this is a faster initOnce. Steve, take a look at 
it pliz pliz? -- Andrei

Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks

2017-05-24 Thread Steven Schveighoffer via Digitalmars-d


On 5/24/17 12:40 PM, Andrei Alexandrescu wrote:

On 5/24/17 4:49 PM, Steven Schveighoffer wrote:

On 5/23/17 3:47 PM, Andrei Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5421

Looking forward to more in the same vein, please contribute! We have 25
left in phobos and 12 in druntime. A big one will be making the GC
lazily initialize itself. -- Andrei


So every time I do:

writeln(...)

It has to go through a check to see if it's initialized? Using a
delegate?


The delegate is not called in the steady state.


OK, I worry about inlineability as DMD has issues when you are using 
delegates sometimes. Unfortunately, I think the compiler isn't smart 
enough to realize that after one check of the boolean returns true, it 
could just access the File handle directly.





Has the performance of this been tested?


Always a good idea. My test bed:

void main()
{
import std.stdio;
foreach (i; 0 .. 10_000_000) writeln("1234567890");
}

On my laptop using dmd, phobos master, best of 21 runs using "time test

/dev/null": 1.371 seconds.


With initOnce: 1.469 seconds. Yuck!

So I added double checking:
https://github.com/dlang/phobos/pull/5421/commits/6ef3b5a6eacfe82239b7bbc4b0bc9f38adc6fe91


With the double checking: 1.372 seconds. So back to sanity.

Thanks for asking me to measure!


This is pretty decent. I still prefer the static ctor solution, but this 
is workable.


-Steve

Re: Anyone tried to emscripten a D/SDL game?

2017-05-24 Thread Suliman via Digitalmars-d


On Wednesday, 24 May 2017 at 17:06:55 UTC, Guillaume Piolat wrote:
On Wednesday, 24 May 2017 at 17:00:51 UTC, Nick Sabalausky 
"Abscissa" wrote:
Anyone have any experience (successful or unsuccessful) 
attempting this? Any info on the current state of it, or 
pitfalls, or pointers for getting started?


http://code.alaiwan.org/wp/?p=103


It's seems that Dart can be compiled to WASM 
https://medium.com/dartlang/dart-on-llvm-b82e83f99a70


It's it's possible to do same with D?

[Issue 17427] New: std.concurrency internal errors on uninitialised mailbox

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

  Issue ID: 17427
   Summary: std.concurrency internal errors on uninitialised
mailbox
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: john.loughran.col...@gmail.com

there are a bunch of functions in std.concurrency that take Tid as a parameter,
none(?) of which check the validity of that Tid (specifically the Mailbox
inside), resulting in mysterious segfaults in private functions if a user
accidentally calls those functions with an uninitialised Tid.

assert(tid.mbox !is null);

in the implementation (or ideally contracts) of these public API functions
would help.

--

[Issue 16108] `to!string` fails on struct with disabled postblit

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

--- Comment #5 from Jack Stouffer  ---
https://github.com/dlang/phobos/pull/5425

--

Re: Faster Command Line Tools in D

2017-05-24 Thread cym13 via Digitalmars-d-announce


On Wednesday, 24 May 2017 at 13:39:57 UTC, Mike Parker wrote:
Some of you may remember Jon Degenhardt's talk from one of the 
Silicon Valley D meetups, where he described the performance 
improvements he saw when he rewrote some of eBay's command line 
tools in D. He has now put the effort into crafting a blog post 
on the same topic, where he takes D version of a command-line 
tool written in Python and incrementally improves its 
performance.


The blog:
https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/

Reddit:
https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/


A bit off topic but I really like that we still get quality 
content such as this post on this blog. Sustained quality is hard 
job and I thank everyone involved for that.

[Issue 16108] `to!string` fails on struct with disabled postblit

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

--- Comment #4 from Jack Stouffer  ---
(In reply to Jack Stouffer from comment #3)
> Hmm, fixing this has me down a rabbit hole.
> 
> to!string relies on std.format for all conversions of aggregate types, and
> all of std.format copies as well. This is going to be a very ugly PR.

Scratch that. Someone thought ahead and there's a function in std.format for
this. Fix soon

--

[Issue 16108] `to!string` fails on struct with disabled postblit

2017-05-24 Thread Nick Sabalausky Abscissa via Digitalmars-d

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

--- Comment #3 from Jack Stouffer  ---
Hmm, fixing this has me down a rabbit hole.

to!string relies on std.format for all conversions of aggregate types, and all
of std.format copies as well. This is going to be a very ugly PR.

--

Re: Anyone tried to emscripten a D/SDL game?


On Wednesday, 24 May 2017 at 17:06:55 UTC, Guillaume Piolat wrote:


http://code.alaiwan.org/wp/?p=103


Awesome, thanks!

Re: Anyone tried to emscripten a D/SDL game?

2017-05-24 Thread Guillaume Piolat via Digitalmars-d

On Wednesday, 24 May 2017 at 17:00:51 UTC, Nick Sabalausky 
"Abscissa" wrote:
Anyone have any experience (successful or unsuccessful) 
attempting this? Any info on the current state of it, or 
pitfalls, or pointers for getting started?


http://code.alaiwan.org/wp/?p=103

Anyone tried to emscripten a D/SDL game?

2017-05-24 Thread Nick Sabalausky Abscissa via Digitalmars-d

Anyone have any experience (successful or unsuccessful) 
attempting this? Any info on the current state of it, or 
pitfalls, or pointers for getting started?

Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks

2017-05-24 Thread Andrei Alexandrescu via Digitalmars-d


On 5/24/17 4:49 PM, Steven Schveighoffer wrote:

On 5/23/17 3:47 PM, Andrei Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5421

Looking forward to more in the same vein, please contribute! We have 25
left in phobos and 12 in druntime. A big one will be making the GC
lazily initialize itself. -- Andrei


So every time I do:

writeln(...)

It has to go through a check to see if it's initialized? Using a delegate?


The delegate is not called in the steady state.


Has the performance of this been tested?


Always a good idea. My test bed:

void main()
{
import std.stdio;
foreach (i; 0 .. 10_000_000) writeln("1234567890");
}

On my laptop using dmd, phobos master, best of 21 runs using "time test 
>/dev/null": 1.371 seconds.


With initOnce: 1.469 seconds. Yuck!

So I added double checking: 
https://github.com/dlang/phobos/pull/5421/commits/6ef3b5a6eacfe82239b7bbc4b0bc9f38adc6fe91


With the double checking: 1.372 seconds. So back to sanity.

Thanks for asking me to measure!


Andrei

Re: 101 LINQ examples in D

2017-05-24 Thread Seb via Digitalmars-d-announce


On Wednesday, 24 May 2017 at 16:06:01 UTC, Pradeep Gowda wrote:
Inspired by Demis Bellot's "Kotlin LINQ examples" [1], I have 
started a github repo to port the 101 LINQ examples to D - 
https://github.com/btbytes/dlang-linq-examples


So far, I've completed one section on "Restriction Operators". 
It has been a fun exercise. More examples to come!



[1] https://github.com/mythz/kotlin-linq-examples


Have a look at my summary: https://github.com/wilzbach/linq

(I never published it, because it's not perfect and I ran out of 
time because for some functions there isn't an equivalent match 
in Phobos)

Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks

2017-05-24 Thread Stanislav Blinov via Digitalmars-d

On Wednesday, 24 May 2017 at 15:49:58 UTC, Steven Schveighoffer 
wrote:

On 5/23/17 3:47 PM, Andrei Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5421

Looking forward to more in the same vein, please contribute! 
We have 25
left in phobos and 12 in druntime. A big one will be making 
the GC

lazily initialize itself. -- Andrei


So every time I do:

writeln(...)

It has to go through a check to see if it's initialized? Using 
a delegate?


It also copies every argument four times.

Re: Weak Eco System?

2017-05-24 Thread Manu via Digitalmars-d

On 22 May 2017 at 18:56, qznc via Digitalmars-d  wrote:

> On Thursday, 18 May 2017 at 05:43:48 UTC, Manu wrote:
>
>> On 17 May 2017 at 00:51, Benro via Digitalmars-d <
>> digitalmars-d@puremagic.com> wrote:
>>
>> [...]
>>>
>>> 4 Hours work. Discouraged and gave up after this.
>>>
>>>
>> Visual Studio proper is the only IDE that 'just works' well, VisualD is
>> very good.
>> MonoDevelop also has good 'just works' support last I checked, but
>> debugging is much better in Visual Studio.
>>
>
> We could use a more precise statement than "just works".
>

I said: "'just works' well"...
It's a deliberately imprecise statement. For me, it means, it didn't
require ANY action from me to make it work, and it 'just works' well enough
that I rarely think about it; it tends to do what I expect, when I expect
it to, as compared to other industry standard tooling. Since this is a
Visual Studio plugin, it is being measured against the VC++ and C#
experiences.

Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks

2017-05-24 Thread Steven Schveighoffer via Digitalmars-d


On 5/23/17 4:42 PM, Andrei Alexandrescu wrote:

On 05/23/2017 03:47 PM, Andrei Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5421

Looking forward to more in the same vein, please contribute! We have
25 left in phobos and 12 in druntime. A big one will be making the GC
lazily initialize itself. -- Andrei


In the same vein: https://github.com/dlang/phobos/pull/5423 -- Andrei


This one I 100% agree with!

-Steve

Re: Simplifying druntime and phobos by getting rid of "shared static this()" blocks

2017-05-24 Thread Steven Schveighoffer via Digitalmars-d


On 5/23/17 3:47 PM, Andrei Alexandrescu wrote:

https://github.com/dlang/phobos/pull/5421

Looking forward to more in the same vein, please contribute! We have 25
left in phobos and 12 in druntime. A big one will be making the GC
lazily initialize itself. -- Andrei


So every time I do:

writeln(...)

It has to go through a check to see if it's initialized? Using a delegate?

Has the performance of this been tested?

I agree the stdiobase thing is ugly. We could also fix this by improving 
the cycle detection mechanism (e.g. you could tag the static ctor that 
initializes the handles to say it doesn't depend on any other static 
ctors, and just put it in stdio).


-Steve

Re: Off-topic discussions (WAS: OT: Re: My two cents on what D needs to be more successful...)

2017-05-24 Thread Steven Schveighoffer via Digitalmars-d


On 5/22/17 8:21 PM, Mike Parker wrote:

On Monday, 22 May 2017 at 20:49:22 UTC, Ecstatic Coder wrote:


Then, with all due respect, please remove these posts...

IMHO, they are so incredibly off-topic that I don't see why they
should remain here to pollute the pages of a D language forum.


The forum is a web frontend for a newsgroup server, which also has a
mailing list interface. I think the NG server does support message
deletion, and that may cause it to disappear from the web frontend, but
it will still be in NG readers and inboxes.


It does support that. When I used Opera for my NNTP client, I could 
actually remove my own posts (I would do this if I made a huge typo, or 
postd by accident). I don't think Thunderbird supports that (and Opera 
discontinued their client).


However, I think the web forum software doesn't obey those deletions. 
And it's so darned fast, I'm sure it picks the erroneous message up 
before deletion ;)


-Steve

Re: Runtime?

2017-05-24 Thread Stanislav Blinov via Digitalmars-d

On Wednesday, 24 May 2017 at 15:07:42 UTC, Steven Schveighoffer 
wrote:


However, I don't know the true answer. It may actually be 1.7MB 
of "bookeeping", but I doubt that...


It's a bit of pre-allocation and some internal bookkeeping.

void main()
{
import std.stdio;
import core.memory;
writeln(GC.stats);
}

//   used, free
Stats(256, 1048320)

The remaining .7Mb could probably be attributed to some internal 
data structures.

Re: My two cents on what D needs to be more successful...

2017-05-24 Thread jmh530 via Digitalmars-d


On Wednesday, 24 May 2017 at 14:49:28 UTC, Adam D. Ruppe wrote:

On Wednesday, 24 May 2017 at 12:09:02 UTC, jmh530 wrote:
Just wanted to say that I was glad you did this. It makes it 
that much easier to play around with your stuff.


So you use the subpackages or try to use the top level thing? 
Also have you had trouble with the ~master vs tag thing?


dub just doesn't agree with my dev method at all.


I had only noticed it was on dub recently so haven't had a chance 
to play around with it that way. I had only used it the 
old-fashioned way.

Re: Ali's slides from his C++Now talk

2017-05-24 Thread Manu via Digitalmars-d

On 24 May 2017 at 09:31, Joakim via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> Enjoying going through these:
>
> http://ddili.org/AliCehreli_CppNow_2017_Competitive_Advantag
> e_with_D.no_pause.pdf
>
> Ali really has a gift for explaining stuff, we're lucky to have him.
>

Hehe, I'm honoured to be quoted... verbatim :)

Re: Runtime?

2017-05-24 Thread Steven Schveighoffer via Digitalmars-d


On 5/24/17 6:34 AM, Moritz Maxeiner wrote:

On Wednesday, 24 May 2017 at 07:54:04 UTC, Wulfklaue wrote:

Great ... accidentally pressed send.

So my question was:

Why does even a simple empty empty statement like this, compiled with
DMD, show under windows a almost 1.7MB memory usage?


Because the garbage collector (GC) allocates a sizable chunk of memory
from the operating system at program startup, from which it then in turn
allocates memory for you when you use things like dynamic closures, `new
XYZ`, etc.


Note, you can usually allocate close to the entire address space, but if 
you never access it, it's not actually used in the RAM of your computer. 
So it's possible D is pre-allocating a bunch of space from the OS, but 
it's not actually consuming RAM.


However, I don't know the true answer. It may actually be 1.7MB of 
"bookeeping", but I doubt that. The GC structures aren't *that* large, 
I'd expect at most 10 pages for the small-chunk bins, and a few more for 
bits. Possibly the static segment is large, but 1.7 MB is around 400+ 
pages. It's likely that most of that is just a pre-allocation of a large 
continuous space "just in case", but it's not actually wired to RAM yet.


-Steve

Re: Idea: Reverse Type Inference

2017-05-24 Thread Steven Schveighoffer via Digitalmars-d


On 5/24/17 10:58 AM, Steven Schveighoffer wrote:

On 5/24/17 10:28 AM, Ola Fosheim Grøstad wrote:

Ok, well, I see templates in this context as a variation of overloading,
just with the template parametric type being a set of types i.e. all
types that the program provides, minus the ones prevented by
contraints.  I guess it is a matter of vantage point.

It would be odd to allow this for templates only and not provide it for
functions...



I believe that IFTI would be much more straightforward than overloading,
because there is no concern about implicit conversion.


In fact, you could simulate overloading of return values based on IFTI 
instantiation:


void fooImpl(ref int retval, int x) { ... }
void fooImpl(ref string retval, int x) { ... }

T foo(T)(int x) { T t; fooImpl(t, x); return t; }
int x = foo(1);
string y = foo(2);

-Steve

Re: Runtime?

2017-05-24 Thread Moritz Maxeiner via Digitalmars-d


On Wednesday, 24 May 2017 at 14:26:42 UTC, Wulfklaue wrote:
On Wednesday, 24 May 2017 at 10:34:02 UTC, Moritz Maxeiner 
wrote:
Because the garbage collector (GC) allocates a sizable chunk 
of memory from the operating system at program startup, from 
which it then in turn allocates memory for you when you use 
things like dynamic closures, `new XYZ`, etc.



Well, that sounds just silly.


Before making such judgement you may want to consider the cost of 
system calls, how memory fragmentation affects a conservative GC, 
and why we cannot have a different kind of GC without 
unacceptable trade offs.




Yes, it is. It is the price we have to pay for having a GC. If 
the overhead bothers you, you might want to compare it with 
other garbage collected languages (such as Go).




Go is a different animal because of the concurrent GC.


Not the point.

Re: Idea: Reverse Type Inference

2017-05-24 Thread Steven Schveighoffer via Digitalmars-d


On 5/24/17 10:28 AM, Ola Fosheim Grøstad wrote:

On Wednesday, 24 May 2017 at 13:03:37 UTC, Steven Schveighoffer wrote:

This is different. It's IFTI based on return type.


Well, the way I see it it is a special case of top-down type inference.
Yes, you also have to instantiate the template, but I assume that
happens after type inference is complete?

So my point was more: why not cover the general case, if you are going
to add it as a feature?


auto p = Point(row.get("x"), row.get("y")); // with better IFTI


Ok, well, I see templates in this context as a variation of overloading,
just with the template parametric type being a set of types i.e. all
types that the program provides, minus the ones prevented by
contraints.  I guess it is a matter of vantage point.

It would be odd to allow this for templates only and not provide it for
functions...



I believe that IFTI would be much more straightforward than overloading, 
because there is no concern about implicit conversion.


-Steve

Re: My two cents on what D needs to be more successful...


On Wednesday, 24 May 2017 at 12:09:02 UTC, jmh530 wrote:
Just wanted to say that I was glad you did this. It makes it 
that much easier to play around with your stuff.


So you use the subpackages or try to use the top level thing? 
Also have you had trouble with the ~master vs tag thing?


dub just doesn't agree with my dev method at all.

Re: My two cents on what D needs to be more successful...


On Wednesday, 24 May 2017 at 04:14:39 UTC, rikki cattermole wrote:
They can be removed, but that means projects stop being built 
hence not wanting to remove them.


That old one hasn't actually even compiled for over a year - I 
still sometimes get bug reports that things don't build cuz of 
deprecation errors and it is because of that old package. There's 
nothing gained and some lost.


I think all packages without a push for over two years should be 
removed or reassigned to a new owner (make the dub name refer to 
a newer fork of the original git repo)

Re: Runtime?

2017-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d


On Wednesday, 24 May 2017 at 14:26:42 UTC, Wulfklaue wrote:

Well, that sounds just silly.


You can bypass it by doing an `extern(C)` main in D... but 
really, the 1 MB preallocation isn't much for small programs and 
for larger programs it will be used anyway, so you aren't 
actually losing anything.

Re: Idea: Reverse Type Inference

On Wednesday, 24 May 2017 at 13:03:37 UTC, Steven Schveighoffer 
wrote:

This is different. It's IFTI based on return type.


Well, the way I see it it is a special case of top-down type 
inference. Yes, you also have to instantiate the template, but I 
assume that happens after type inference is complete?


So my point was more: why not cover the general case, if you are 
going to add it as a feature?



auto p = Point(row.get("x"), row.get("y")); // with better IFTI


Ok, well, I see templates in this context as a variation of 
overloading, just with the template parametric type being a set 
of types i.e. all types that the program provides, minus the ones 
prevented by contraints.  I guess it is a matter of vantage point.


It would be odd to allow this for templates only and not provide 
it for functions...

Re: Runtime?

2017-05-24 Thread Mike Parker via Digitalmars-d-announce


On Wednesday, 24 May 2017 at 10:34:02 UTC, Moritz Maxeiner wrote:
Because the garbage collector (GC) allocates a sizable chunk of 
memory from the operating system at program startup, from which 
it then in turn allocates memory for you when you use things 
like dynamic closures, `new XYZ`, etc.



Well, that sounds just silly.

Yes, it is. It is the price we have to pay for having a GC. If 
the overhead bothers you, you might want to compare it with 
other garbage collected languages (such as Go).




Go is a different animal because of the concurrent GC.

Re: Ali's slides from his C++Now talk

2017-05-24 Thread Ali Çehreli via Digitalmars-d


On 05/24/2017 01:34 AM, Wulfklaue wrote:


Page 68: "CTFE is being wastly improved by Stefan Koch.". Wastly? ;)


I was paging through quickly so nobody would notice. And of course I 
must have meant CTFE perforwance... :o)


Ali

Faster Command Line Tools in D

Some of you may remember Jon Degenhardt's talk from one of the 
Silicon Valley D meetups, where he described the performance 
improvements he saw when he rewrote some of eBay's command line 
tools in D. He has now put the effort into crafting a blog post 
on the same topic, where he takes D version of a command-line 
tool written in Python and incrementally improves its performance.


The blog:
https://dlang.org/blog/2017/05/24/faster-command-line-tools-in-d/

Reddit:
https://www.reddit.com/r/programming/comments/6d25mg/faster_command_line_tools_in_d/

Re: My two cents on what D needs to be more successful...

2017-05-24 Thread aberba via Digitalmars-d


On Wednesday, 24 May 2017 at 04:04:53 UTC, Adam D. Ruppe wrote:

On Tuesday, 23 May 2017 at 21:21:45 UTC, Guillaume Piolat wrote:

[...]


So actually, the dub thing for mine is

http://code.dlang.org/packages/arsd-official/~master

the other was a third party thing that is now obsolete (and imo 
this shows one of the weaknesses of dub right now... the list 
order is just most recent explicit update and old things can't 
be removed afaik)



[...]


oh my simpledisplay does that too! and 2d/3d drawing. and 
combined with minigui does user interface (though minigui still 
isn't quite done)



I am tempted to package my stuff with dmd as a one-stop 
download... but idk if it is really beneficial since my stuff 
is so easy to download and use anyway with my policy of 
independent files.


Actually the dub version is much easier/convenient for me. Ha ha

[Issue 17420] std.format.formatObject doesn't work with @safe toString specialization

2017-05-24 Thread Steven Schveighoffer via Digitalmars-d

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

--- Comment #2 from Jack Stouffer  ---
(In reply to Nick Treleaven from comment #1)
> I think you mean formatValue rather than formatObject:
> 
> https://dlang.org/phobos/std_format.html#.formatValue.10

No, I meant formatObject
https://github.com/dlang/phobos/blob/9a66a6a0647c17d61f551581967abb63aae02545/std/format.d#L3345

--

Re: Idea: Reverse Type Inference


On 5/23/17 5:20 AM, Ola Fosheim Grøstad wrote:

On Monday, 22 May 2017 at 10:13:02 UTC, Sebastiaan Koppe wrote:

Over the past weeks I have been noticing a specific case where it
happens. I call it reverse type inference, simply because it goes
against the normal evaluation order.


I think what you want, in the general sense, is basically overloading
based on return-type. Which I think is a very useful and cool feature.


This is different. It's IFTI based on return type.

BTW, swift does this too, and I have to say it's useful in a lot of cases.

For example, any time you have a variant-like interface, and an already 
existing type, something like this looks so much cleaner.


struct Point
{
  int x;
  int y;
}

auto row = getRowFromDB();
auto p = Point(row.get!int("x"), row.get!int("y")); // currently required
auto p = Point(row.get!(typeof(Point.x))("x"), 
row.get!(typeof(Point.y))("y")); // more generic, but horribly ugly.

auto p = Point(row.get("x"), row.get("y")); // with better IFTI

-Steve

Re: Tilix 1.5.8 released

2017-05-24 Thread Gerald via Digitalmars-d-announce


On Wednesday, 24 May 2017 at 07:25:56 UTC, Andrea Fontana wrote:

It seems that package on webupd8 is still on 1.5.4


Unfortunately I do not maintain the packages, best course of 
action would be to drop them a line asking them to update it.

[Issue 17426] "version(none):" cant be overwritten by its counterpart

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||thecybersha...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #1 from Vladimir Panteleev  ---
The rule being followed here is:

{
version(x):
...code...
}

is equivalent to

{
version(x)
{...code...}
}

i.e. everything is wrapped until the end of the current scope, or file if at
the top level.

Thus, your code is equivalent to:

version(none)
{
  unittest {assert(false);}
  version(all)
  {
unittest {assert(false);} // not compiled
version(none)
{
  unittest {assert(false);}
}
  }
}

Making your code work as intuitively expected would mean breaking consistency
with the rule (though adding a warning for this to either DMD or DScanner might
not be a bad idea).

--

[Issue 17424] Add optional errors/static analysis

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic

--

[Issue 17423] @safe code seg faults

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid, safe

--

[Issue 17423] @safe code seg faults

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Linux   |All

--

[Issue 17423] @safe code seg faults

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #2 from Vladimir Panteleev  ---
Wow, that's pretty evil :)

opApply is showing its age here.

--

[Issue 17424] Add optional errors/static analysis

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

Eyal  changed:

   What|Removed |Added

Summary|Add useful warnings |Add optional errors/static
   ||analysis

--

[Issue 17424] Add useful warnings

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

--- Comment #4 from Eyal  ---
(In reply to Jonathan M Davis from comment #2)
> (In reply to greenify from comment #1)
> > Great idea. This is one of the areas where D is definitely behind other
> > languages.
> > IIRC Walter believes that the compiler isn't a linter, so if I am not
> > mistaken only warnings with minimal or zero overhead will be merged.
> 
> His take on it is that warnings are a sign that folks couldn't agree on what
> was right or wrong in the language. He tends to think that something should
> either be an error or not (and I agree with him). But the issue of warnings
> has been discussed many times in the newsgroup, and I really don't think
> that many are going to be added to the compiler. And the fact that dmd
> stupidly has -w makes them that much worse because of how that affects
> compile-time introspection.

And folks indeed can't agree, and for good reason! Different people assign
different importance to correctness vs. convenience.

I agree that "warnings" should always actually be errors (-Werror) - but we
will never reach consensus on what the set of warnings should actually be. And
of course, they shouldn't affect __traits(compiles, ...) and is(typeof(..)).

If someone uses D for small <3-5KLOC projects, where a build-test-debug-cycle
is 10 seconds and a bug is a minor nuisance, of course he wants convenience.
Emphasis on correctness is not worth the hassle.

We use D for a large project, with a much much slower build-test-debug-cycle.
Bugs easily cost us hours. Detected late, they can cost us days. Undetected,
they can be disastrous.

Our trade-offs are different, so there is no one-size-fits-all. And this is why
a language that wants to cater to both of these audiences should have flags.

> Ultimately though, the big problem with warnings is that if you're doing
> your job right, you fix them all (if you don't, you just end up with a big
> pile of warnings that get ignored and so you miss whatever value they do
> provide), and so you might as well either make them errors or not warn about
> them at all. And it gets _very_ annoying when the compiler warns about
> something that shouldn't need to be changed. Really, anything that's going
> to be optional makes far more sense in a linter.

I don't want multiple tools to spend time CTFE'ing my code and increase an
already long debug cycle.

Perhaps reframing the discussion from "warnings" to "optional errors" is
better.

> _Best_ case,
> you're stuck "fixing" all kinds of stuff that isn't actually wrong so that
> you don't have any warnings, 

This is the case for me everywhere I had the ability to set the warnings policy
(-W -Werror). This is a *cheap* price to pay, compared to a
single unexpected week lost to a completely unnecessary bug.

> but more often, you end up with tons of
> warnings that no one pays attention to. Having at tool that can warn about
> potential problems has real value, but I don't think that it's appropriate
> for the compiler to be doing it.

Agreed. That's why "optional errors" is how I should have framed it, and not
"warnings".

> Walter is also very much against additional compiler flags. So, I think that
> you're going to have a hard time convincing him that this is a good idea.
> Having the compiler as a library as has been discussed would make it easier
> to write a linter, but based on past discussions on this topic, I think that
> it's pretty clear that the vast majority of these suggestions will never be
> compiler warnings even if they make a lot of good sense for a linter.

One-size fits all is going to be bad for one group or the other. Compiler flags
are bad for the compiler's manpage.

--

[Issue 13255] static imports should be done lazily

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

anonymous4  changed:

   What|Removed |Added

   Keywords||performance
   Hardware|x86_64  |All
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13242
 OS|Linux   |All

--- Comment #1 from anonymous4  ---
Renamed import should be done lazily too, if issue 13242 didn't get it.

--

Re: My two cents on what D needs to be more successful...

2017-05-24 Thread jmh530 via Digitalmars-d


On Wednesday, 24 May 2017 at 04:04:53 UTC, Adam D. Ruppe wrote:

On Tuesday, 23 May 2017 at 21:21:45 UTC, Guillaume Piolat wrote:

http://code.dlang.org/packages/arsd


So actually, the dub thing for mine is

http://code.dlang.org/packages/arsd-official/~master



Just wanted to say that I was glad you did this. It makes it that 
much easier to play around with your stuff.

Re: Ali's slides from his C++Now talk

2017-05-24 Thread jmh530 via Digitalmars-d


On Wednesday, 24 May 2017 at 08:34:14 UTC, Wulfklaue wrote:


Page 68: "CTFE is being wastly improved by Stefan Koch.". 
Wastly? ;)


I assume they meant vastly

[Issue 13242] imported aliases should be analyzed lazily

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

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=13255

--

[Issue 17417] Deprecate signed integer promotions in bitwise operations

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

--- Comment #7 from anonymous4  ---
VRP can't do anything here because promotion works according to spec.

--

[Issue 17417] Deprecate signed integer promotions in bitwise operations

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

anonymous4  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |---

--- Comment #6 from anonymous4  ---
The issue is not about VRP. Integer promotions don't require casts and happen
without casts (basically inadvertently).
Example: if we have two 16-bit values and want to combine them into a 32-bit
value:
uint v=(s1<<16)|s2;

VRP has nothing to do here.

--

Re: Runtime?

2017-05-24 Thread Moritz Maxeiner via Digitalmars-d


On Wednesday, 24 May 2017 at 07:54:04 UTC, Wulfklaue wrote:

Great ... accidentally pressed send.

So my question was:

Why does even a simple empty empty statement like this, 
compiled with DMD, show under windows a almost 1.7MB memory 
usage?


Because the garbage collector (GC) allocates a sizable chunk of 
memory from the operating system at program startup, from which 
it then in turn allocates memory for you when you use things like 
dynamic closures, `new XYZ`, etc.




void main()
{
  while(true){}
}

The same in C/C++ is simply 0.1MB. This is why i asked the 
question if the runtime is somehow responsible?


Yes, it is. It is the price we have to pay for having a GC. If 
the overhead bothers you, you might want to compare it with other 
garbage collected languages (such as Go).


PS: This might belong in Learn, instead of General.

Re: Any video editing folks n da house?

On Wednesday, 24 May 2017 at 09:27:59 UTC, Andrei Alexandrescu 
wrote:
I'm thinking publicly available videos so the footage is 
already out there.


Public available videos are already compressed. Rikki needs the 
original source video and audio.


Working on a compressed video to create another compressed video, 
simply result in lower quality video ( and less professional 
looking ).

Re: Any video editing folks n da house?

2017-05-24 Thread Andrei Alexandrescu via Digitalmars-d

rikki cattermole  wrote:
> On 23/05/2017 9:23 PM, Andrei Alexandrescu wrote:
>> Would be great to have a video intro of D featuring a mix of testimonies
>> from a few folks, fragments from the existing DConf materials, etc. Some
>> of that cool ukulele upbeat music, too. Anyone would enjoy taking up
>> such a project? -- Andrei
> 
> If you can provide the raw footage, I'm sure a few of us will give it a 
> go (I have licenses for music which I can use for this stuff).
> 

I'm thinking publicly available videos so the footage is already out there.

Re: Ali's slides from his C++Now talk


On Wednesday, 24 May 2017 at 03:57:07 UTC, Ali Çehreli wrote:

Not yet but I heard the videos will be posted here:

  https://www.youtube.com/user/BoostCon

Ali


Page 68: "CTFE is being wastly improved by Stefan Koch.". Wastly? 
;)

[Issue 17420] std.format.formatObject doesn't work with @safe toString specialization

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

Nick Treleaven  changed:

   What|Removed |Added

 CC||n...@geany.org

--- Comment #1 from Nick Treleaven  ---
I think you mean formatValue rather than formatObject:

https://dlang.org/phobos/std_format.html#.formatValue.10

--

Re: Runtime?


Great ... accidentally pressed send.

So my question was:

Why does even a simple empty empty statement like this, compiled 
with DMD, show under windows a almost 1.7MB memory usage?


void main()
{
  while(true){}
}

The same in C/C++ is simply 0.1MB. This is why i asked the 
question if the runtime is somehow responsible?

Re: Runtime?