[Issue 15606] core.exception.rangeerror@pipedmd(285) range violation

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||r.sagita...@gmx.de
 Resolution|--- |FIXED

--- Comment #4 from Rainer Schuetze  ---
There was a problem with lines with exact length 2048 (or a little less).

Should be fixed in https://github.com/dlang/visuald/releases/tag/v0.44-beta2

--

[Issue 15506] VS2015 crash while debugging

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #2 from Rainer Schuetze  ---
Do you still have this issue with the new debugger integration? If it persists,
an example for reproduction would be nice.

--

[Issue 15099] C++ projects depend on D projects?

[via Digitalmars-d-bugs]

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

--- Comment #5 from Rainer Schuetze  ---
This should work when building the library using a VC project. Implementing
this for Visual D projects would mean patching VC *.target files, not sure if
it is worth it...

--

[Issue 14558] Attempts to link with DMD when using MSVC LDC under VisualD

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Rainer Schuetze  ---
> I'm not sure the best approach. MS do it completely differently to VisualD
> I often wonder if an MSBuild style solution would be more idiomatic?

This is available now in
https://github.com/dlang/visuald/releases/tag/v0.44-beta2. LDC no longer
supports MinGW, so no path confusions to that respect. So I'm closing this...

--

[Issue 13915] Mago doesn't handle C code very well

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Rainer Schuetze  ---
Mago treats "->" as "." now. With the new Concord integration C/C++ and D
should no longer interfere, so work on supporting C in mago is futile.

--

[Issue 13888] VisualD project settings use the same property grid as C/C++ projects?

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Rainer Schuetze  ---
I guess you got the requested grid with the new VC project integration.

--

[Issue 12565] IDE cannot launch Mago debugger starting from v0.3.38-beta3

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Rainer Schuetze  ---
Finally released as part of
https://github.com/dlang/visuald/releases/tag/v0.44-beta2 (must heve been in
beta1, too)

--

Re: auto ref escaping local variable

[Stefan Koch via Digitalmars-d]

On Tuesday, 24 January 2017 at 00:52:34 UTC, Robert burner 
Schadek wrote:
I have this program that used to compile with 72 but with 73 
dmd is complaining that

"Error: escaping reference to local variable t"

auto ref f2(T)(auto ref T t, auto ref T s) {
return t;
}

auto ref f1(T)(auto ref T t, auto ref T s) {
return f2(t, s);
}

unittest {
int a = f1(1,2);
}

I'm not sure why, or how to fix that.

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


Seems to work as expected.
The literals 1,2 cannot be ref.
Therefore it's a normal parameter.
A function parameter is the same as a local
hence retuning a ref to it will cause this to happen.

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

The blacklisted functions are now down to only two.

Those are the bitswap function in druntime.
Because the interpreter does handle all values as 64bit 
internally it tends to miscompile code that uses xor on 32bit 
values.


And the second one is the "to" template from std.conv;
Because of the aforementioned UTF issues.

NOTE: that the blacklist is by nature transitive meaning a 
function that calls a blacklisted function will also not be 
interpreted by newCTFE

[Issue 17114] DMD 2.073.0 Error: undefined identifier '_arrayExpComSliceAndass_k' in module 'app'

[via Digitalmars-d-bugs]

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

Paul Crane  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Paul Crane  ---
I'm still not sure what changed in the new DMD but I'ved fixed that problem. It
had to deal with a library publically importing another library as far as I
could see. Disregard this.

--

Re: Safely moving structs in D

[bitwise via Digitalmars-d-learn]

On Monday, 23 January 2017 at 23:04:45 UTC, Ali Çehreli wrote:

On 01/23/2017 02:58 PM, bitwise wrote:

I'm confused about what the rules would be here.

It would make sense to call the postblit if present, but 
std.Array

currently does not:
https://github.com/dlang/phobos/blob/04cca5c85ddf2be25381fc63c3e941498b17541b/std/container/array.d#L884



Post-blit is for copying though. Moving should not call 
post-blit. You may want to look at the implementation of 
std.algorithm.move to see how it plays with post-blit:


  https://dlang.org/phobos/std_algorithm_mutation.html#.move

Ali


That's a good point.

It didn't click at first, but checking for postblit is done with 
'hasElaborateCopyConstructor(T)'.


I had thought that what memmove was doing would be considered 
"blitting", and hence require a postblit afterwards.


I did look at std.move, but was mistaken about which code path 
was being taken.
It seemed like structs that defined only a postblit would have 
been moved by assignment:


https://github.com/dlang/phobos/blob/366f6e4e66abe96bca9fd69d03042e08f787d040/std/algorithm/mutation.d#L1310

But in actuality, the memcpy branch fires because 
hasElaborateAssign(T) returns true for structs with a postblit - 
which was unexpected. I don't really understand why, but this 
makes things clearer.


  Thanks

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Monday, 23 January 2017 at 22:09:27 UTC, David Nadlinger wrote:

On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:

interpret3.d passes!!!

The only remaining issues that cause miscompiled code are 
UTF(8/16/32) encoding and decoding issues.


Is that without bailing out?

 — David


No I still bail a lot :).
And I will be for some time, until I have written a 
memory-manager and various other runtime-libarary equivalents 
which are required for CTFE.


As well as my own soft-floating point library to ensure proper 
output during cross-compilation.


However this is an important milestone because it can now 
magically speed up a subset of ctfe without breaking things...

modulo bugs not covered by the unittests.

Re: auto ref escaping local variable

[Robert burner Schadek via Digitalmars-d]

Nice idea, but didn't work either. Just got more errors. And my 
eyes hurt now.

[Issue 11320] std.math.fmod, round, trunc are not yet pure

[via Digitalmars-d-bugs]

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

Ryan  changed:

   What|Removed |Added

 CC||clumsycodemon...@gmail.com

--- Comment #1 from Ryan  ---
I can confirm this is still an issue in 2.071.2.

--

Re: auto ref escaping local variable

[Manu via Digitalmars-d]

On 24 January 2017 at 10:52, Robert burner Schadek via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> I have this program that used to compile with 72 but with 73 dmd is
> complaining that
> "Error: escaping reference to local variable t"
>
> auto ref f2(T)(auto ref T t, auto ref T s) {
> return t;
> }
>

Maybe:

auto ref f2(T)(return auto ref T t, auto ref T s) {
return t;
}

??

auto ref escaping local variable

[Robert burner Schadek via Digitalmars-d]

I have this program that used to compile with 72 but with 73 dmd 
is complaining that

"Error: escaping reference to local variable t"

auto ref f2(T)(auto ref T t, auto ref T s) {
return t;
}

auto ref f1(T)(auto ref T t, auto ref T s) {
return f2(t, s);
}

unittest {
int a = f1(1,2);
}

I'm not sure why, or how to fix that.

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

[Issue 17117] New: auto ref "escaping reference to local variable"

[via Digitalmars-d-bugs]

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

  Issue ID: 17117
   Summary: auto ref "escaping reference to local variable"
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: rburn...@gmail.com

auto ref f2(T)(auto ref T t, auto ref T s) {
return t;
}

auto ref f1(T)(auto ref T t, auto ref T s) {
return f2(t, s);
}

unittest {
int a = f1(1,2);
}

This used to work with 2.072. I'm not sure why 2.073 is complaining that.
"escaping reference to local variable t"

--

Re: General performance tips

[kinke via Digitalmars-d-learn]

On Monday, 23 January 2017 at 12:13:30 UTC, albert-j wrote:
There's not much object creation going on there, mostly loops 
over arrays, so I assume GC is not an issue.


When passing arrays around, beware that static arrays are value 
types in D and are copied unless passed by reference.

Re: Output range and writeln style functions

[Jon Degenhardt via Digitalmars-d-learn]

On Monday, 23 January 2017 at 22:20:59 UTC, Ali Çehreli wrote:

On 01/23/2017 12:48 PM, Jon Degenhardt wrote:
[snip]
> So, what I'm really wondering is if there is built-in  way

 to get closer to:

  outputStream.writefln(...);



If it's about formatted output then perhaps formattedWrite?

  https://dlang.org/phobos/std_format.html#.formattedWrite

The same function is used with stdout and an Appender:

[snip]

Ali


Oh, that is better, thanks!

--Jon

Re: Writing a JFlex lexer for D - have an issue with cycles

[Profile Anaysis via Digitalmars-d]

On Monday, 23 January 2017 at 01:46:58 UTC, FatalCatharsis wrote:
On Monday, 23 January 2017 at 00:46:30 UTC, Profile Anaysis 
wrote:
The real issue is ambiguity. Any time you have a cycle you 
must be able to get out of it and so your rules must be 
organized so that one always checks to see if termination has 
occurred before checking for nesting. If you allow, say } as 
an element of a stringliteral then it will be ambiguous as the 
grammar will try to match it, when it is meant to be a literal.


This brings up another question for me. Isn't the token string 
production ambiguous by itself?


q{ tokens }

How does it know whether the input "}" is another token or the 
terminator on a token string?


You know how an if statement in many languages has the feature of 
Short-circuit evaluation?


if (X | Y)

X is first tested, and if it is true, there is no need to test Y.

Now lets say that X is true at some point but Y is "recursive" in 
some sense, while X is false, Y is evaluated but once X becomes 
true there is no need for Y to be evaluated.


This "analogy" is basically what is happening in the grammar for 
nested rules.


As long as we have a terminating rule that is checked first and 
bypasses the non-recursive rules, we will terminate.


So, to understand this easily we think about this way for any 
type of nested things.


1. Create the terminating instance(e.g., the X above) that has no 
recursive properties/non-terminating behavior.


2. Create the recursive instance(the Y).

Then effectively do the if(X | Y). This generally can be directly 
mapped in to a grammar because the if statements are implicit in 
the rules(since it is a decision tree).


So, to "create X", which is simply a string literal, it has the 
structure q{...}.


This structure must be unambiguous for  This means that ... 
must not have q{ or } in it unless they are escaped in some 
way(which essentially just changes them in to something else. 
e.g., \n is not \ and n but a completely different character as 
far as the grammar is concerned.


Now, that is the terminal rule. It can't recurse because ... will 
be parsed as "whatever" and that whatever can't be, by design(we 
hope), be re-parsed as itself(in any way).



Once we have that, we create the non-terminal recursive rule:

q{...} in which ... can be itself(or something else which then is 
this, or whatever.


You basically have this stuff(you might have to make sure the 
first case actually is a terminal and can't recurse on itself.


Once you have that, it is easy to create a terminating grammar:

Y = q{X | Y}

First X is checked, if it is found then Y terminates, else we try 
Y.


Such a rule as the above can be expanded.

Y = q{X | q{X | q{X | q{X | q{X | q{X | q{X | q{X | q{X | ... Y}

so, this only allows strings like

q{X}
q{q{X}}
q{q{q{X}}}
q{q{q{q{X
q{q{q{q{q{X}

etc...

But they always terminate as long as X terminates.

The compilers logic is this:

Check if the tokens look like q{ then some form of X, if no X 
then check if they match Y, which requires reapplying the whole 
check, then a }.


Suppose our rule is

Y = q{1X | 2Y}

q{1X}
q{2q{1X}}
q{2q{2q{1X}}}
q{2q{2q{2q{1X
q{2q{2q{2q{2q{1X}

would be the valid matches.


If we allows other alternates like

Y = q{X | (A | B) }
A = l{Y}
B = ($|%)A

then things like

q{X}

q{l{q{X}}
q{l{q{l{q{X} (basically A is Y as before but with an l
q{l{q{l{X <- not valid because l{X} is not in the rule above, 
it must be of type l{Y} and Y always starts with a q{. The rule 
actually fails at the inner most l{l{X}} because the l{X} is not 
matched(no rule)


q{l{q{$l{X is valid, This is the rules applied in this form 
Y->A->B->Y.



You can see, with the proper rules we can generate just about any 
form we want.


The things to keep track of is that:

X must never contain tokens/matches that allow the other 
non-terminals to fail, unless that is the goal and X must be a 
terminal. In the above example, if X could contain l, {, }, $, 
and/or % then we have no way of knowing if our tokens are really 
X or Y. e.g., with q{l{q{l{q{X}, X could just be 
l{q{l{q{X and we would terminate immediately. This would make 
our ability to parse the nesting impossible. We can say that X 
must be "disjoint" from Y for Y the grammar to function as 
intended.


Second, you must list your rules in the short circuit order so 
that the terminate is always checked first. This is because the Y 
rules may actually contain X(they do in fact, and must if it is 
recursive).


Hence, if we check the Y rules first, we will end up in a cycle 
because we will never be able to determine that the Y rule is 
really an X and X is what allows us to terminate the cycle in the 
first place.


It is not really difficult as it seems. It is just a way of 
thinking and expressing things that makes the difference. 
Remember that a grammar is effectively just a giant "if statement 
machine" and so similar logic holds. Just as 

Re: Safely moving structs in D

[Ali Çehreli via Digitalmars-d-learn]

On 01/23/2017 02:58 PM, bitwise wrote:

I'm confused about what the rules would be here.

It would make sense to call the postblit if present, but std.Array
currently does not:
https://github.com/dlang/phobos/blob/04cca5c85ddf2be25381fc63c3e941498b17541b/std/container/array.d#L884



Post-blit is for copying though. Moving should not call post-blit. You 
may want to look at the implementation of std.algorithm.move to see how 
it plays with post-blit:


  https://dlang.org/phobos/std_algorithm_mutation.html#.move

Ali

Re: Safely moving structs in D

[sarn via Digitalmars-d-learn]

On Monday, 23 January 2017 at 22:26:58 UTC, bitwise wrote:

Is it ok to memcpy/memmove a struct in D?

Quote from here:
https://dlang.org/spec/garbage.html

"Do not have pointers in a struct instance that point back to 
the same instance. The trouble with this is if the instance 
gets moved in memory, the pointer will point back to where it 
came from, with likely disastrous results."


This seems to suggests it's ok to move structs around in memory 
without calling their postblit...but if this is the case, why 
does postblit even exist, if it's not strictly guaranteed to be 
called after the struct has been blitted?


You may need the postblit for a *copying* blit.  For example, if 
a struct does reference counting, the postblit will need to 
increment the count for the new copy.  It's a slightly different 
solution to what C++ solves with copy constructors, assignment 
operators, etc.  Compared to C++, the D approach is a bit simpler 
and trades off a little flexibility for more opportunities for 
the compiler to generate efficient code.


Here's the situation in C++, BTW:
http://en.cppreference.com/w/cpp/language/rule_of_three

Re: Safely moving structs in D

[bitwise via Digitalmars-d-learn]

I'm confused about what the rules would be here.

It would make sense to call the postblit if present, but 
std.Array currently does not:

https://github.com/dlang/phobos/blob/04cca5c85ddf2be25381fc63c3e941498b17541b/std/container/array.d#L884

[Issue 5467] library-based typedef

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |FIXED

--- Comment #5 from b2.t...@gmx.com ---
this should have been closed for a while (std.typecons.TypeDef)

--

Re: General performance tips

[sarn via Digitalmars-d-learn]

On Monday, 23 January 2017 at 12:13:30 UTC, albert-j wrote:
Well it is actually ODE solver from Numerical recipes 
(originally in C++) that I am trying to do in D. Code 
translation seems very straightforward. Maybe there's someone 
around who has done that already? There's not much object 
creation going on there, mostly loops over arrays, so I assume 
GC is not an issue.


It really is hard without seeing the code.  When you said "from 
Java", my first thought was that you'd want to convert a lot of 
classes to structs, but you say there's not much object creation 
going on.


"mostly loops over arrays" makes me think of bounds checking.  
Try benchmarking after compiling with -boundscheck=off to see if 
this is responsible for your speed difference.


By the way, the original C++ code is probably closer to good D 
code than the Java code.


If you really want fast numerical D code, take a look at Mir and 
ndslice.

Re: High-level wrapper for GNU MP (GMP)

[Nordlöw via Digitalmars-d-announce]

On Monday, 23 January 2017 at 22:37:50 UTC, Nordlöw wrote:

See README.md for more details.


Moved todo-list to TODO.md and cleaned up README.md at

https://github.com/nordlow/gmp-d

High-level wrapper for GNU MP (GMP)

[Nordlöw via Digitalmars-d-announce]

Version 0.0.1 is out

http://code.dlang.org/packages/gmp-d

Only mpz_t is currently wrapped (in MpZ).

See README.md for more details.

Safely moving structs in D

[bitwise via Digitalmars-d-learn]

Is it ok to memcpy/memmove a struct in D?

Quote from here:
https://dlang.org/spec/garbage.html

"Do not have pointers in a struct instance that point back to the 
same instance. The trouble with this is if the instance gets 
moved in memory, the pointer will point back to where it came 
from, with likely disastrous results."


This seems to suggests it's ok to move structs around in memory 
without calling their postblit...but if this is the case, why 
does postblit even exist, if it's not strictly guaranteed to be 
called after the struct has been blitted?

[Issue 10666] Appender does not work with a RefCounted type

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |FIXED

--

Re: Output range and writeln style functions

[Ali Çehreli via Digitalmars-d-learn]

On 01/23/2017 12:48 PM, Jon Degenhardt wrote:

On Monday, 23 January 2017 at 08:03:14 UTC, Ali Çehreli wrote:

On 01/22/2017 01:54 PM, Jon Degenhardt wrote:

I've been increasingly using output ranges in my code (the "component
programming" model described in several articles on the D site). It
works very well, except that it would often be more convenient to use
writeln style functions rather than 'put'. Especially when you start by
drafting a sketch of code using writeln functions, then convert it an
output range.

Seems an obvious thing, I'm wondering if I missed something. Are there
ways to use writeln style functions with output ranges?

--Jon


I don't think I understand the question. :)

If you need a variadic put(), then I've come up with the following
mildly tested AllAppender. Just as a reminder, I've also used
std.range.tee that allows tapping into the stream to see what's flying
through:

[snip]

Ali


So I guess the is answer is "no" :)

It's mainly about consistency of the output primitives. Includes
variadic args, formatting, and names of the primitives. I keep finding
myself starting with something like:

void writeLuckyNumber(string name, int luckyNumber)
   {
   writefln("Hello %s, your lucky number is %d", name, luckyNumber);
   }

and then re-factoring it as:

   void writeLuckyNumber(OutputRange)
   (OutputRange outputStream, string name, int luckyNumber)
   if (isOutputRange!(OutputRange, char))
   {
   import std.format;
   outputStream.put(
   format("Hello %s, your lucky number is %d\n", name,
luckyNumber));
   }

Not bad, but the actual output statements are a bit harder to read,
especially if people reading your code are not familiar with output
ranges. So, what I'm really wondering is if there is built-in way to get
closer to:

  outputStream.writefln(...);

 that I've overlooked.


--Jon


If it's about formatted output then perhaps formattedWrite?

  https://dlang.org/phobos/std_format.html#.formattedWrite

The same function is used with stdout and an Appender:

import std.stdio;
import std.range;

void writeLuckyNumber(OutputRange)
(OutputRange outputStream, string name, int luckyNumber)
if (isOutputRange!(OutputRange, char))
{
import std.format : formattedWrite;
formattedWrite(outputStream, "Hello %s, your lucky number is %d\n", 
name, luckyNumber);

}

void main() {
writeLuckyNumber(stdout.lockingTextWriter, "Jon", 42);

auto app = appender!string();
writeLuckyNumber(app, "Jon", 42);

writeln(app.data);
}

Ali

Re: LDC talk @ FOSDEM'17

[David Nadlinger via Digitalmars-d-announce]

On Monday, 23 January 2017 at 19:56:33 UTC, Johan Engelen wrote:

Great! :-)

Keep me in the loop when preparing your slides! ;-)


Glad to help out in any way as well. I might also make it to 
FOSDEM myself this year, but that's not quite sure yet.


 — David

Re: CTFE Status

[David Nadlinger via Digitalmars-d]

On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:

interpret3.d passes!!!

The only remaining issues that cause miscompiled code are 
UTF(8/16/32) encoding and decoding issues.


Is that without bailing out?

 — David

[Issue 8812] functionAttributes doesn't returns const/immutable/shraed/inout attributs

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||b2.t...@gmx.com
 Resolution|--- |FIXED

--

Re: CTFE Status

[Daniel Kozák via Digitalmars-d]

V Mon, 23 Jan 2017 17:42:00 +
Stefan Koch via Digitalmars-d  napsáno:

> interpret3.d passes!!!
> 
> The only remaining issues that cause miscompiled code are 
> UTF(8/16/32) encoding and decoding issues.

WOW

[Issue 17116] std.typecons.ReplaceType is not able to process const delegate

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Severity|minor   |normal

--- Comment #1 from b2.t...@gmx.com ---
void main()
{
import std.typecons;
alias ConstDg = void delegate(float) const;
alias B = void delegate(int) const;
alias A = ReplaceType!(float, int, ConstDg);
static assert(is(B == A));
}


/opt/compilers/dmd2/include/std/typecons.d-mixin-7364(7364): Error: @identifier
or @(ArgumentList) expected, not @const
/opt/compilers/dmd2/include/std/typecons.d-mixin-7364(7364): Error: valid
attributes are @property, @safe, @trusted, @system, @disable, @nogc
/opt/compilers/dmd2/include/std/typecons.d(7229): Error: template instance
std.typecons.replaceTypeInFunctionType!(float, int, void delegate(float) const)
error instantiating
/d296/f412.d(6):instantiated from here: ReplaceType!(float, int, void
delegate(float) const)
/d296/f412.d(7): Error: static assert  (is(void delegate(int) const ==
_error_)) is false

--

Re: Output range and writeln style functions

[Jon Degenhardt via Digitalmars-d-learn]

On Monday, 23 January 2017 at 08:03:14 UTC, Ali Çehreli wrote:

On 01/22/2017 01:54 PM, Jon Degenhardt wrote:
I've been increasingly using output ranges in my code (the 
"component
programming" model described in several articles on the D 
site). It
works very well, except that it would often be more convenient 
to use
writeln style functions rather than 'put'. Especially when you 
start by
drafting a sketch of code using writeln functions, then 
convert it an

output range.

Seems an obvious thing, I'm wondering if I missed something. 
Are there

ways to use writeln style functions with output ranges?

--Jon


I don't think I understand the question. :)

If you need a variadic put(), then I've come up with the 
following mildly tested AllAppender. Just as a reminder, I've 
also used std.range.tee that allows tapping into the stream to 
see what's flying through:


[snip]

Ali


So I guess the is answer is "no" :)

It's mainly about consistency of the output primitives. Includes 
variadic args, formatting, and names of the primitives. I keep 
finding myself starting with something like:


void writeLuckyNumber(string name, int luckyNumber)
   {
   writefln("Hello %s, your lucky number is %d", name, 
luckyNumber);

   }

and then re-factoring it as:

   void writeLuckyNumber(OutputRange)
   (OutputRange outputStream, string name, int luckyNumber)
   if (isOutputRange!(OutputRange, char))
   {
   import std.format;
   outputStream.put(
   format("Hello %s, your lucky number is %d\n", name, 
luckyNumber));

   }

Not bad, but the actual output statements are a bit harder to 
read, especially if people reading your code are not familiar 
with output ranges. So, what I'm really wondering is if there is 
built-in way to get closer to:


  outputStream.writefln(...);

 that I've overlooked.


--Jon

Re: CTFE Status

[Dmitry Olshansky via Digitalmars-d]

On 1/23/17 6:42 PM, Stefan Koch wrote:

interpret3.d passes!!!



Now that's something!


The only remaining issues that cause miscompiled code are UTF(8/16/32)
encoding and decoding issues.


---
Dmitry Olshansky

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Monday, 23 January 2017 at 17:42:00 UTC, Stefan Koch wrote:

interpret3.d passes!!!

The only remaining issues that cause miscompiled code are 
UTF(8/16/32) encoding and decoding issues.


Wow! Getting close know!

[Issue 17116] New: std.typecons.ReplaceType is not able to process const delegate

[via Digitalmars-d-bugs]

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

  Issue ID: 17116
   Summary: std.typecons.ReplaceType  is not able to process const
delegate
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

--

Re: LDC talk @ FOSDEM'17

[Johan Engelen via Digitalmars-d-announce]

On Saturday, 21 January 2017 at 12:37:26 UTC, Kai Nacke wrote:

Hi everybody!

Last year turned out to be difficult for D development for me. 
I try to come back this year.


Great! :-)

Keep me in the loop when preparing your slides! ;-)

cheers,
  Johan

[Issue 14964] __traits(isAlias, foo)

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com

--- Comment #5 from b2.t...@gmx.com ---
(In reply to Mike Parker from comment #4)
> (In reply to Mike Parker from comment #3)
> > Not at all. allMembers returns FuncPtr and funcPtr as distinct symbols. What
> > I'm looking for is a generic way to know that one is an alias declaration
> > and the other is not.
> 
> And to be clear, I'm talking about at compile time. I realize it's not
> possible at runtime, but surely the compiler knows the difference.

Imagine a text-based serializer (like JSON, in opposite to a binary serializer)
- The serializer writes a size_t under a x86_64 OS and send it over the network
- An x86 machine reads it in a size_t
=> overflow...

In this case I wish to use __traits(isAlias) in a template constraint or in a
static assert to reject the value (e.g "cannot write an aliased type"). The
serializer, without type info, really doesn't want any platform specific type.

To get the info at CT or at RT doesn't make any difference. Any custom type
info structure would use __traits(isAlias) to generate a static instance for an
aggregate field of whatever.

--

Re: Gui in D: I miss this project

[Nick Sabalausky via Digitalmars-d]

On 01/16/2017 02:39 AM, Jacob Carlborg wrote:

On 2017-01-09 22:41, aberba wrote:

This seemed to be an effort (among others) to bring GUI cross platform
to standard D but some language/compiler/Phobos/Deimos/manpower issues
were the drag.

https://github.com/Devisualization


We now have DLangUI.

I wonder what the current drag is.



There's DWT [1] as well. Works on Windows and Linux, uses native drawing.

[1] https://github.com/d-widget-toolkit/dwt



There's also QtE5 https://github.com/MGWL/QtE5

Looks pretty good, from what I can see.

Re: module std.stream is deprecated - Will be removed by phobos version 2.070

[jmh530 via Digitalmars-d]

On Monday, 23 January 2017 at 17:39:00 UTC, ixid wrote:


Speaking of killing things with fire (OT) - what's happening 
with the comma operator? I want delicious tuples like Go.


They were deprecated in 2.072.0.

http://dlang.org/changelog/2.072.0.html#deprecated_commaexp

Re: module std.stream is deprecated - Will be removed by phobos version 2.070

[Suliman via Digitalmars-d]

On Monday, 23 January 2017 at 17:39:00 UTC, ixid wrote:
On Friday, 11 September 2015 at 21:16:06 UTC, Brian Schott 
wrote:
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir 
Panteleev wrote:
Apparently it was decided at DConf 2015 to remove std.stream 
and friends from Phobos.


Kill it with fire.


Speaking of killing things with fire (OT) - what's happening 
with the comma operator? I want delicious tuples like Go.


I have seen thread about improving tuples, but now I can't find 
it, could you remember me what people decided about how they 
could look in D?

Re: Multiple return type or callback function

[Basile B. via Digitalmars-d-learn]

On Monday, 23 January 2017 at 15:15:35 UTC, aberba wrote:
I'm creating a function to authenticate user login. I want to 
determine login failure (Boolean) and error message (will be 
sent to frontend) but D does have multiple return type

[...]


Yes, MRV can be done with a tuple

auto foo()
{
import std.typecons;
return tuple(true, "123456");
}

void main(string[] args)
{
auto auth = foo;
if (auth[0])
auth[1].writeln;
}

It's more or less like returning a Voldemort struct.

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

interpret3.d passes!!!

The only remaining issues that cause miscompiled code are 
UTF(8/16/32) encoding and decoding issues.

Re: module std.stream is deprecated - Will be removed by phobos version 2.070

[ixid via Digitalmars-d]

On Friday, 11 September 2015 at 21:16:06 UTC, Brian Schott wrote:
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir 
Panteleev wrote:
Apparently it was decided at DConf 2015 to remove std.stream 
and friends from Phobos.


Kill it with fire.


Speaking of killing things with fire (OT) - what's happening with 
the comma operator? I want delicious tuples like Go.

Re: module std.stream is deprecated - Will be removed by phobos version 2.070

[Patrick Schluter via Digitalmars-d]

On Sunday, 1 May 2016 at 17:06:19 UTC, Seb wrote:

On Sunday, 1 May 2016 at 14:31:10 UTC, Bauss wrote:
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir 
Panteleev wrote:

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

Apparently it was decided at DConf 2015 to remove std.stream 
and friends from Phobos. But these modules have been left 
untouched (i.e. they're "stable") for a long time, and 
there's a lot of D code using them. This decision seems to go 
in an opposite direction to other recent decisions (i.e. that 
we stop breaking code). Is everyone (incl. Walter AND Andrei) 
on board with this?


Please yes. Why people still use it is beyond me.


Baus: I posted to this issue because Andrei suggested to move 
undead to dlang and it didn't happen yet. std.stream is already 
set to deprecation in October 2016. This thread is from last 
year. I should have opened a new thread - sorry about that.



Please yes. Why people still use it is beyond me.


Because they have an existing codebase and don't want to change 
it, see the following issue as an disucssion:


https://github.com/biod/BioD/issues/19


It would also give a better impression if the sample D programs 
packaged with the dmd compiler didn't use it: d2html.d, htmlget.d 
and wc2.d do not compile because of that (they also have several 
deprecation messages). I just installed 2.73.0 on our Linux 
server at work and to test if everything was ok (I have to 
install by hand because of strange restrictive policies e have 
here) and discovered that the sample programs are completely 
outdated.

If I get the time this week I will try to contribute and fix it.

Re: SmartRef： The Smart Pointer In D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Saturday, 14 January 2017 at 15:41:01 UTC, Dmitry Olshansky 
wrote:
That is C++ smart_ptr has to be atomic, while its D counter 
part may safely be non-atomic because everything is TLS be 
default.


I assume you mean std::shared_ptr. The reference counting 
semantics are atomic, but the I don't think the compiler is 
required to if it provably isn't shared. There are also ways to 
get around it if needed (you only need atomic count when you 
enter or leave a context, e.g. thread).


Of course, there are C++ single threaded alternatives with 
intrusive ref counting, which I believe is what D is going for. 
shared_ptr is non-intrusive (doesn't affect allocation or object 
types).

Re: Multiple return type or callback function

[pineapple via Digitalmars-d-learn]

On Monday, 23 January 2017 at 15:15:35 UTC, aberba wrote:
I'm creating a function to authenticate user login. I want to 
determine login failure (Boolean) and error message (will be 
sent to frontend) but D does have multiple return type (IMO 
could use struct but will make code dirty with too much custom 
types).


struct Result
{
bool success = false
string message;
}
Result authen(){}
auto r = authen()
if (r.success) writeln(r.message);


I use structs like this quite frequently, myself. It works well 
and I don't think it's particularly ugly. And if you don't want 
to pollute the namespace with one-off structs, you can also place 
them inside the function that's returning them (making them 
voledmort types).

Re: Gui in D: I miss this project

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 19 January 2017 at 07:39:10 UTC, Jacob Carlborg 
wrote:
If I'm looking for a new type of application I'll dismiss those 
that don't look native very quickly. Unless I know beforehand 
that the application is very good, then I'll give it some more 
time.


I think it has more to do with looking well-designed for the 
purpose. 3D and audio editors often use non-native custom UI 
toolkits. VS Code is also non-native.


But on OSX you have to use the OSX-menu and put extra effort into 
the design if you use non-native widgets IMO.


Also, make sure it isn't sluggish. Java apps often has that extra 
GC sluggishness to them, even the polished JetBrains IDEs feel a 
bit sluggish.

Re: Compile to C?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Monday, 23 January 2017 at 15:24:09 UTC, aberba wrote:
Unless you will be limited by tge limitations of C. Vala 
programming language has that issue even though they utilize 
GObject


What limitations? C/C++ programs go around "limitations" by using 
compiler extensions and runtime libraries.


Vala is trying to keep code simple, like Go. Apples and oranges.

Re: Compile to C?

[aberba via Digitalmars-d-learn]

On Monday, 23 January 2017 at 14:40:18 UTC, Ola Fosheim Grøstad 
wrote:
On Saturday, 21 January 2017 at 19:30:31 UTC, Jack Stouffer 
wrote:

On Saturday, 21 January 2017 at 18:38:22 UTC, Nestor wrote:

Hi friends,

Is there a way to "compile" d code to C, similar to what nim 
does?


That would be cool for greater portability.


No, and this is actually a terrible idea. See 
https://forum.dlang.org/post/n1vbos$11ov$1...@digitalmars.com


No valid arguments for it being a terrible idea in that thread.

Being able to translate code to other languages is a very 
useful feature and makes a language much more interesting in 
production.


Unless you will be limited by tge limitations of C. Vala 
programming language has that issue even though they utilize 
GObject

Multiple return type or callback function

[aberba via Digitalmars-d-learn]

I'm creating a function to authenticate user login. I want to 
determine login failure (Boolean) and error message (will be sent 
to frontend) but D does have multiple return type (IMO could use 
struct but will make code dirty with too much custom types).


struct Result
{
bool success = false
string message;
}
Result authen(){}
auto r = authen()
if (r.success) writeln(r.message);



 In such use case, would you use a callback delegates function or 
will use a string (str == "ok", str == "no") or go with a struct?


string authen(){}
string r = authen();
//check if string contains success message to take action.


Or
void authen(void delegate callback(bool success, string message) )
{
//authenticate
callback (resultBoolean, message);
}

//use
authen( (success, msg) {
   req.writeBody(msg); // to frontend
});

Re: Compile to C?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Monday, 23 January 2017 at 14:53:54 UTC, Bauss wrote:
I'd guess the code generation you'd get from doing so with D 
would be absolute horrific to read, because you'll get rid of 
CTFE, templates, proper class structure, globals properly 
stored, since everything in D is TLS and C doesn't then you'll 
see weird constructs everywhere.


TLS is a nonissue. You can wrap the TLS declarations in macros.

Re: Compile to C?

[Bauss via Digitalmars-d-learn]

On Saturday, 21 January 2017 at 18:38:22 UTC, Nestor wrote:

Hi friends,

Is there a way to "compile" d code to C, similar to what nim 
does?


That would be cool for greater portability.


Nim is able to, because Nim doesn't really compile. The Nim 
compiler just translates Nim code to C code and then compiles the 
C code.


It's much harder to do properly in D, because D doesn't use C as 
a backend, but compiles directly to native.


I'd guess the code generation you'd get from doing so with D 
would be absolute horrific to read, because you'll get rid of 
CTFE, templates, proper class structure, globals properly stored, 
since everything in D is TLS and C doesn't then you'll see weird 
constructs everywhere.


If you ask me, it's probably not something you want to do and 
there really isn't a reason to do it with D either. D has an 
almost 100% compatibility with C already.

Re: Compile to C?

[Ola Fosheim Grøstad via Digitalmars-d-learn]

On Saturday, 21 January 2017 at 19:30:31 UTC, Jack Stouffer wrote:

On Saturday, 21 January 2017 at 18:38:22 UTC, Nestor wrote:

Hi friends,

Is there a way to "compile" d code to C, similar to what nim 
does?


That would be cool for greater portability.


No, and this is actually a terrible idea. See 
https://forum.dlang.org/post/n1vbos$11ov$1...@digitalmars.com


No valid arguments for it being a terrible idea in that thread.

Being able to translate code to other languages is a very useful 
feature and makes a language much more interesting in production.

[Issue 9290] Ability to modify immutable struct members in static array assignment

[via Digitalmars-d-bugs]

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

Martin Krejcirik  changed:

   What|Removed |Added

 CC||m...@krej.cz

--

Re: A safer File.readln

[Shachar Shemesh via Digitalmars-d]

On 23/01/17 15:18, Andrei Alexandrescu wrote:

On 1/23/17 5:44 AM, Shachar Shemesh wrote:

If, instead of increasing its size by 100%, we increase it by a smaller
percentage of its previous size, we still maintain the amortized O(1)
cost (with a multiplier that might be a little higher, but see the trade
off). On the other hand, we can now reuse memory.


Heh, I have a talk about it. The limit is the golden cut,
1.6180339887498948482... The proof is fun. Anything larger prevents you
from reusing previously used space. -- Andrei



I was going to ask for the proof, but I first went to refresh my memory 
a little about the golden ratio, at which point the proof became 
somewhat trivial.


Shachar

Re: Confirming and uninstantiated struct

[Mike Parker via Digitalmars-d-learn]

On Monday, 23 January 2017 at 13:57:23 UTC, aberba wrote:


if (stu is Student.init) //will confirm when i get to my pc


That works, as does this:

if(stu == Student.init)

Re: A safer File.readln

[Shachar Shemesh via Digitalmars-d]

On 23/01/17 15:18, Andrei Alexandrescu wrote:

On 1/23/17 5:44 AM, Shachar Shemesh wrote:

If, instead of increasing its size by 100%, we increase it by a smaller
percentage of its previous size, we still maintain the amortized O(1)
cost (with a multiplier that might be a little higher, but see the trade
off). On the other hand, we can now reuse memory.


Heh, I have a talk about it. The limit is the golden cut,
1.6180339887498948482... The proof is fun. Anything larger prevents you
from reusing previously used space. -- Andrei



What does D use when we keep appending?

Shachar

Re: Confirming and uninstantiated struct

[rikki cattermole via Digitalmars-d-learn]

Structs are a value type and will always have a type that won't be null.
If you want it to be nullable you will have to use pointers or classes
(there is also Nullable in std.typecons but it won't work with is null).


s/have a type that won't be null/have a value that won't be null/

My bad.

Re: Confirming and uninstantiated struct

[rikki cattermole via Digitalmars-d-learn]

On 24/01/2017 2:57 AM, aberba wrote:

How do I verify this struct has no value

Student getStudent()
{
...
Student s;
if(condition) s = Student;
return s;
}

auto stu = getStudent();

//which will work and is best?
if (stu is null) //doesn't wrk.
if (stu is Student.init) //will confirm when i get to my pc

Or how would you do it? Will you make it null first? (I'm not used to
statically typed languages internals)

Another issue. I'm creating a function to authenticate user login. I
want to determine login failure (Boolean) and error message but D does
have multiple return type (could use struct but will make code dirty).

in such case, would you use a callback delegates function or will use a
string (str == "ok", str == "no") or go with a struct?


Structs are a value type and will always have a type that won't be null.
If you want it to be nullable you will have to use pointers or classes 
(there is also Nullable in std.typecons but it won't work with is null).

Confirming and uninstantiated struct

[aberba via Digitalmars-d-learn]

How do I verify this struct has no value

Student getStudent()
{
...
Student s;
if(condition) s = Student;
return s;
}

auto stu = getStudent();

//which will work and is best?
if (stu is null) //doesn't wrk.
if (stu is Student.init) //will confirm when i get to my pc

Or how would you do it? Will you make it null first? (I'm not 
used to statically typed languages internals)


Another issue. I'm creating a function to authenticate user 
login. I want to determine login failure (Boolean) and error 
message but D does have multiple return type (could use struct 
but will make code dirty).


in such case, would you use a callback delegates function or will 
use a string (str == "ok", str == "no") or go with a struct?

[Issue 17115] New: [404 Not Found] std.concurrencybase

[via Digitalmars-d-bugs]

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

  Issue ID: 17115
   Summary: [404 Not Found] std.concurrencybase
   Product: D
   Version: D2
  Hardware: x86_64
   URL: http://dlang.org/
OS: Linux
Status: NEW
  Severity: minor
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: lasssa...@gmail.com

https://dlang.org/phobos/std_concurrencybase.html does not exist but is still
shown as a valid module in https://dlang.org/phobos/.
https://dlang.org/library/std/concurrencybase.html *does* exist and has a
description of its purpose.

Two solutions (though there are probably more):
Either remove https://dlang.org/library/std/concurrencybase.html and remove all
references to concurrencybase
Or add https://dlang.org/phobos/std_concurrencybase.html

--

Re: Lets talk about fibers

[Ola Fosheim Grøstad via Digitalmars-d]

On Sunday, 8 January 2017 at 09:18:19 UTC, Suliman wrote:
Simply picking a worker thread + worker fiber when task is 
assigned and sticking to it until finished should work good 
enough. It is also important to note though that "fiber" is 
not the same as "task". Former is execution context primitive, 
latter is scheduling abstraction. In fact, heavy load systems 
are likely to have many more tasks than fibers at certain 
spike points.


Could you explain difference between fibers and tasks. I read a 
lot, but still can't understand the difference.


The meaning of the word "task" is contextual:

https://en.wikipedia.org/wiki/Task_(computing)

So, yes, it is a confusing term that one should avoid using 
without defining it.


Ola.

Re: A safer File.readln

[Andrei Alexandrescu via Digitalmars-d]

On 1/23/17 5:44 AM, Shachar Shemesh wrote:

If, instead of increasing its size by 100%, we increase it by a smaller
percentage of its previous size, we still maintain the amortized O(1)
cost (with a multiplier that might be a little higher, but see the trade
off). On the other hand, we can now reuse memory.


Heh, I have a talk about it. The limit is the golden cut, 
1.6180339887498948482... The proof is fun. Anything larger prevents you 
from reusing previously used space. -- Andrei

Re: General performance tips

[albert-j via Digitalmars-d-learn]

Without seeing the source there is nothing we can do.
Usually performant d-code looks quite diffrent from java code.
For example to avoid the gc :)


Well it is actually ODE solver from Numerical recipes (originally 
in C++) that I am trying to do in D. Code translation seems very 
straightforward. Maybe there's someone around who has done that 
already? There's not much object creation going on there, mostly 
loops over arrays, so I assume GC is not an issue.

Re: A safer File.readln

[Markus Laker via Digitalmars-d]

On Monday, 23 January 2017 at 11:30:35 UTC, Shachar Shemesh wrote:
It is possible to tweak the numbers based on the overall use. 
For example, add 100% for arrays smaller than 1MB, 50% for 1MB 
- 100MB, and 20% for arrays above 100MB big. This would 
eliminate the performance degradation for almost all users.


I'm going to bow out of the discussion about array-expansion, 
because I think it's a separate topic from readln and I don't 
know enough about D's internals to contribute meaningfully.  It 
might be worth raising your proposal in a separate thread in 
order to ensure visibility.


Cheers,

Markus

Re: A safer File.readln

[Shachar Shemesh via Digitalmars-d]

One more thing.

It is possible to tweak the numbers based on the overall use. For 
example, add 100% for arrays smaller than 1MB, 50% for 1MB - 100MB, and 
20% for arrays above 100MB big. This would eliminate the performance 
degradation for almost all users.


Shachar

On 23/01/17 12:44, Shachar Shemesh wrote:

On 23/01/17 11:15, Markus Laker wrote:


A 2GiB disk file caused tinycat.d to use over 4GiB of memory.



When extending arrays, a common approach is to double the size every
time you run out of space. This guarantees an amortized O(1) cost of
append.

Unfortunately, this also guarantees that we will never have enough space
freed by previous copies to reuse existing memory:

100 byte array

increase

100 bytes free
200 bytes array

increase

300 free
400 array

etc. The array will always be bigger than the total amount of space we
freed.

If, instead of increasing its size by 100%, we increase it by a smaller
percentage of its previous size, we still maintain the amortized O(1)
cost (with a multiplier that might be a little higher, but see the trade
off). On the other hand, we can now reuse memory. Let's say we increase
by 50% each time:

100 array

increase

100 free
150 array

increase

250 free
225 array

increase

475 free
338 array

813 free
507 array

The next increase will require 761 bytes, but we already have 813 free,
so we can allocate the new array over the memory already freed from
before, reducing the heap size.

Of course, if we integrate the allocating and the move, we could have
reused previously used memory starting from allocation 3, but I'm
assuming that would also be possible when increasing by 100%, so I'm
assuming we can't do that.

Of course, if, instead of 50% we increase by less (say, 20%), we could
reuse previously used memory even sooner.

I am assuming that this is the problem that manifests itself in this use
scenario. I would suggest solving it at the language level, rather than
the library level.

Shachar

Re: A safer File.readln

[Shachar Shemesh via Digitalmars-d]

On 23/01/17 13:05, Markus Laker wrote:

On Monday, 23 January 2017 at 10:44:50 UTC, Shachar Shemesh wrote:

Of course, if, instead of 50% we increase by less (say, 20%), we could
reuse previously used memory even sooner.


Yes, you're right, of course: expansion of strings and other arrays is a
classic time-versus-space trade-off.  However, expanding strings more
slowly is a much bigger change than I have the D experience or
credentials to suggest.  And I don't think it really solves the problem:
it just requires the attacker to wait another few seconds for /dev/zero
to deliver enough data to fill up memory.  A simple length-check in
readln, in contrast, would prevent an attacker from flooding us with
data in the first place.

Markus


It would mean we consume an order of magnitude of the amount of memory 
the "attacker" sends.


There is a huge difference between "I send an unterminated string 2GB 
long, and it takes 2GB of memory, causing trouble", and "I send an 
unterminated string 2GB long, and it takes 4GB of memory, causing trouble".


The second is a problem. The first might be obvious and/or benign, 
depending on the use case.


Shachar

Re: General performance tips

[Stefan Koch via Digitalmars-d-learn]

On Monday, 23 January 2017 at 11:11:21 UTC, albert-j wrote:
I have translated some simulation code from Java into D (a few 
classes, mostly manipulation of double arrays in small 
methods). D version runs 10-30% slower than Java (ldc2, dub 
release build). Profiling did not show any obvious bottlenecks. 
I am wondering whether I missed something, or such performance 
difference can be expected. I read on this forum that marking 
methods final and nothrow can help, but it didn't do much in my 
case. Is there anything else I should be looking for?
In general, something like a wiki page with performance tips 
would be very useful for D newcomers like me! :)


Without seeing the source there is nothing we can do.
Usually performant d-code looks quite diffrent from java code.
For example to avoid the gc :)

General performance tips

[albert-j via Digitalmars-d-learn]

I have translated some simulation code from Java into D (a few 
classes, mostly manipulation of double arrays in small methods). 
D version runs 10-30% slower than Java (ldc2, dub release build). 
Profiling did not show any obvious bottlenecks. I am wondering 
whether I missed something, or such performance difference can be 
expected. I read on this forum that marking methods final and 
nothrow can help, but it didn't do much in my case. Is there 
anything else I should be looking for?
In general, something like a wiki page with performance tips 
would be very useful for D newcomers like me! :)

[Issue 14964] __traits(isAlias, foo)

[via Digitalmars-d-bugs]

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

--- Comment #4 from Mike Parker  ---
(In reply to Mike Parker from comment #3)
> Not at all. allMembers returns FuncPtr and funcPtr as distinct symbols. What
> I'm looking for is a generic way to know that one is an alias declaration
> and the other is not.

And to be clear, I'm talking about at compile time. I realize it's not possible
at runtime, but surely the compiler knows the difference.

--

[Issue 14964] __traits(isAlias, foo)

[via Digitalmars-d-bugs]

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

--- Comment #3 from Mike Parker  ---
Not at all. allMembers returns FuncPtr and funcPtr as distinct symbols. What
I'm looking for is a generic way to know that one is an alias declaration and
the other is not.

--

Re: A safer File.readln

[Markus Laker via Digitalmars-d]

On Monday, 23 January 2017 at 10:44:50 UTC, Shachar Shemesh wrote:
Of course, if, instead of 50% we increase by less (say, 20%), 
we could reuse previously used memory even sooner.


Yes, you're right, of course: expansion of strings and other 
arrays is a classic time-versus-space trade-off.  However, 
expanding strings more slowly is a much bigger change than I have 
the D experience or credentials to suggest.  And I don't think it 
really solves the problem: it just requires the attacker to wait 
another few seconds for /dev/zero to deliver enough data to fill 
up memory.  A simple length-check in readln, in contrast, would 
prevent an attacker from flooding us with data in the first place.


Markus

Re: Need a std::numeric_limits::lowest() equivalent

[Dominikus Dittes Scherkl via Digitalmars-d]

On Saturday, 21 January 2017 at 15:55:35 UTC, Xavier Bigand wrote:
I don't see any other use case than for initialized maths 
struct to an invalid state, and because it is generally in 
template that working with integers and floats it is easier to 
have same properties (when it have the same meaning).


I use

/// consider T.max to be NaN of unsigned types
/// and T.min to be NaN of signed types
@property bool isNaN(T)(const(T) x) pure @safe @nogc nothrow 
if(isIntegral!T)

{
   static if(isSigned!T)
  return x == T.min;
   else // unsigned
  return x == T.max;
}

/// add a property to numeric types that can be used as return 
value if a result is out of bounds

template invalid(T) if(isNumeric!T)
{
   static if(isFloatingPoint!T)
  @property enum invalid = T.init;
   else static if(isSigned!T)
  @property enum invalid = T.min; // 0x80..00
   else // unsigned
  @property enum invalid = T.max; // 0xFF..FF
}

/// returns the save (not invalid) minimum value for the given 
type

template smin(T) if(isNumeric!T)
{
   static if(isFloatingPoint!T)
  @property enum smin = -T.max; // T.min is the smallest 
representable positive value!!

   else static if(isSigned!T)
  @property enum smin = T(T.min+1);
   else // unsigned
  @property enum smin = T.min; // 0
}

/// returns the save (not invalid) maximum value for the given 
type

template smax(T) if(isNumeric!T)
{
   static if(isUnsigned!T)
  @property enum smax = T(T.max-1u);
   else
  @property enum smax = T.max;
}

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

On Monday, 23 January 2017 at 09:06:49 UTC, Nordlöw wrote:


Good job.


There are more good news

uint fn()
{
  uint x = 7;
  modx();
  return x;
}

void modx(uint* x)
{
*x = 12;
}

static assert(fn() == 12);

This code does now compile with newCTFE :)

Re: A safer File.readln

[Shachar Shemesh via Digitalmars-d]

On 23/01/17 11:15, Markus Laker wrote:


A 2GiB disk file caused tinycat.d to use over 4GiB of memory.



When extending arrays, a common approach is to double the size every 
time you run out of space. This guarantees an amortized O(1) cost of append.


Unfortunately, this also guarantees that we will never have enough space 
freed by previous copies to reuse existing memory:


100 byte array

increase

100 bytes free
200 bytes array

increase

300 free
400 array

etc. The array will always be bigger than the total amount of space we 
freed.


If, instead of increasing its size by 100%, we increase it by a smaller 
percentage of its previous size, we still maintain the amortized O(1) 
cost (with a multiplier that might be a little higher, but see the trade 
off). On the other hand, we can now reuse memory. Let's say we increase 
by 50% each time:


100 array

increase

100 free
150 array

increase

250 free
225 array

increase

475 free
338 array

813 free
507 array

The next increase will require 761 bytes, but we already have 813 free, 
so we can allocate the new array over the memory already freed from 
before, reducing the heap size.


Of course, if we integrate the allocating and the move, we could have 
reused previously used memory starting from allocation 3, but I'm 
assuming that would also be possible when increasing by 100%, so I'm 
assuming we can't do that.


Of course, if, instead of 50% we increase by less (say, 20%), we could 
reuse previously used memory even sooner.


I am assuming that this is the problem that manifests itself in this use 
scenario. I would suggest solving it at the language level, rather than 
the library level.


Shachar

[Issue 14964] __traits(isAlias, foo)

[via Digitalmars-d-bugs]

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

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--- Comment #2 from Mathias Lang  ---
I would point to the spec here:
http://dlang.org/spec/declaration.html#AliasDeclaration

> `AliasDeclarations` create a symbol that is an alias for another type, and 
> can be used anywhere that other type may appear.

> Aliased types are semantically identical to the types they are aliased to. 
> The debugger cannot distinguish between them, and there is no difference as 
> far as function overloading is concerned.

To me, it sounds like you are looking to create a subtype, in which case
`Typedef` would be a better approach. `alias` is just not designed for this.
This really sounds like a DIP to me.

--

Re: A safer File.readln

[Markus Laker via Digitalmars-d]

On Monday, 23 January 2017 at 01:55:59 UTC, Andrei Alexandrescu 
wrote:
I recall reported size for special files is zero. We special 
case std.file.read for those. -- Andrei


Special files are a bit of a distraction, in any case, because 
it's easy to create a large disk file full of zeroes:


msl@james:~/d$ dd if=/dev/zero of=zeroes count=2048 bs=1048576
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 11.1792 s, 192 MB/s
msl@james:~/d$ /usr/bin/time ./tinycat.d zeroes > /dev/null
1.67user 3.14system 0:04.83elapsed 99%CPU (0avgtext+0avgdata 
4199944maxresident)k

0inputs+0outputs (0major+1049634minor)pagefaults 0swaps
msl@james:~/d$

A 2GiB disk file caused tinycat.d to use over 4GiB of memory.

Cheers,

Markus

Re: CTFE Status

[Nordlöw via Digitalmars-d]

On Monday, 23 January 2017 at 07:57:35 UTC, Stefan Koch wrote:

It was very hard to find this.


Good job.

Re: Iup4D 1.0 alpha

[Andrea Fontana via Digitalmars-d-announce]

On Friday, 20 January 2017 at 15:23:51 UTC, Heromyth wrote:
Iup4D is a D binding library for IUP with OOP style. Its API is 
similar to WinForms.


This software is licensed under the Boost Software License, 
Version 1.0.


It's still under active development and is only tested on 
Windows X86.


The repository is at https://github.com/Heromyth/Iup4D.


Waiting for a dub package :)

[Issue 11703] Typedef properties should not be of the original type

[via Digitalmars-d-bugs]

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

b2.t...@gmx.com changed:

   What|Removed |Added

 CC||b2.t...@gmx.com
Summary|Typedef!int(1).max is int   |Typedef properties should
   ||not be of the original type

--

[Issue 17114] New: DMD 2.073.0 Error: undefined identifier '_arrayExpComSliceAndass_k' in module 'app'

[via Digitalmars-d-bugs]

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

  Issue ID: 17114
   Summary: DMD 2.073.0 Error: undefined identifier
'_arrayExpComSliceAndass_k' in module 'app'
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: viserion.thr...@gmail.com

With DMD 2.073.0 I am now getting compilation errors when compiling the code
contained in
https://github.com/Soulsbane/ctoptions/blob/develop/source/ctoptions/commander.d

./libs/ctoptions/source/ctoptions/commander.d(187,28): Error: undefined
identifier '_arrayExpComSliceAndass_k' in module 'app'
../libs/ctoptions/source/ctoptions/commander.d(187,28): Error: undefined
identifier '_arrayExpSliceAndass_k' in module 'app'
source/app.d(232,13): Error: template instance
app.main.Commander!"app".Commander.process!() error instantiating

It is failing on this code:
alias member = helper!(__traits(getMember, mod, memberName));

The 'mod' variable comes from:
alias mod = helper!(mixin(modName));

This code is part of a mixin template where 'modName' is defined as
mixin template Commander(string modName = __MODULE__).

I have no idea what the problem is. This code has always worked before now. The
only fix for now is I've done a static if to check for those function names and
skip over them in that case.

Hopefully that's enough info! Thanks!

--

Re: Output range and writeln style functions

[Ali Çehreli via Digitalmars-d-learn]

On 01/22/2017 01:54 PM, Jon Degenhardt wrote:

I've been increasingly using output ranges in my code (the "component
programming" model described in several articles on the D site). It
works very well, except that it would often be more convenient to use
writeln style functions rather than 'put'. Especially when you start by
drafting a sketch of code using writeln functions, then convert it an
output range.

Seems an obvious thing, I'm wondering if I missed something. Are there
ways to use writeln style functions with output ranges?

--Jon


I don't think I understand the question. :)

If you need a variadic put(), then I've come up with the following 
mildly tested AllAppender. Just as a reminder, I've also used 
std.range.tee that allows tapping into the stream to see what's flying 
through:


import std.array : Appender, appender;
import std.stdio : writeln;

struct AllAppender(T) {
Appender!T app;
alias app this;

void put(Args...)(Args args) {
foreach (arg; args) {
static if (__traits(compiles, app.put(arg))) {
app.put(arg);
}
else {
import std.conv : to;
app.put(arg.to!T);
}
}
}
}

import std.range : isOutputRange;
static assert(isOutputRange!(AllAppender!string, int));
static assert(isOutputRange!(AllAppender!string, double));

auto allAppender(T)() {
return AllAppender!T();
}

void main() {
auto a = allAppender!string();
a.put(1, "hello");

import std.range : tee;
import std.algorithm : copy;
[ 10, 20, 30 ]
.tee!(e => writeln("appending ", e))
.copy(a);

writeln(a.data);
}

Ali

Re: CTFE Status

[Stefan Koch via Digitalmars-d]

I just fixed a bug related to the unsupported floating point.
~master phobos compiles again and runs the unit-tests.

I will probably have to spent the rest of the month with fixing 
bugs that function-call support has uncovered.


Since now newCTFE sees much more code before bailing out.

I have also determined the cause of most of the miscompiled code.
The cause is the incorrect treatment of utf8.
(currently the evaluator really just does (dchar c= (_c & 7f))
which leads to corrupted strings in mixins;
and that has pretty crazy effects.

It was very hard to find this.