Re: usable @nogc Exceptions with Mir Runtime

[Uknown via Digitalmars-d-announce]

On Wednesday, 31 October 2018 at 08:34:08 UTC, 9il wrote:
The C++ format style is simpler to implement and it is much 
faster to run.
D's style came from C and Boost's format. Also, the C++ style 
is more low level then format strings, so they can be built on 
top of it.


I think they meant why use the `<<` operator instead of the `~` 
operator?

Re: Add D front-end, libphobos library, and D2 testsuite... to GCC

[Uknown via Digitalmars-d-announce]

Congrats to the GDC team! Phoronix on the same: 
https://www.phoronix.com/scan.php?page=news_item=GCC-9-Merges-D-Language

Re: Parallelizing factorial computation

[Uknown via Digitalmars-d-learn]

On Friday, 24 August 2018 at 20:43:46 UTC, Peter Alexander wrote:

On Friday, 24 August 2018 at 13:04:47 UTC, Uknown wrote:
I was quite surprised by the fact that parallel ran so much 
slower than recursive and loop implementations. Does anyone 
know why?


n = 100 is too small to see parallelism gains.

Try n = 1

https://run.dlang.io/is/XDZTSd


I was using n = 1 originally, I reduced it because that 
wasn't running on run.dlang. Tried this again on my machine and 
you were right.

Parallelizing factorial computation

[Uknown via Digitalmars-d-learn]

I was messing and tried comparing the performance of different 
ways to compute the factorial of a number. Here's the benchmark 
results:


recursive:  244 ms, 283 μs, and 2 hnsecs
loop:   241 ms, 412 μs, and 3 hnsecs
parallel:   1 sec, 784 ms, 829 μs, and 5 hnsecs


https://run.dlang.io/is/uyVlqu

I was quite surprised by the fact that parallel ran so much 
slower than recursive and loop implementations. Does anyone know 
why?

Re: LDC 1.11.0

[Uknown via Digitalmars-d-announce]

On Tuesday, 21 August 2018 at 15:31:16 UTC, Joakim wrote:

On Sunday, 19 August 2018 at 10:11:42 UTC, 鲜卑拓跋枫 wrote:

[...]
I tried looking for a RISC-V VPS or dev board recently and 
found basically nothing, just two boards from SiFive that are 
too small or too expensive.


There is the SHAKTI Program by IIT Madras : 
http://shakti.org.in/about.html

Re: RFC: initial release of dtoh

[Uknown via Digitalmars-d-announce]

On Wednesday, 22 August 2018 at 11:01:02 UTC, Mihails wrote:

https://gitlab.com/mihails.strasuns/dtoh

Tool to grab all `extern(C)` declarations in a D module and 
generate C header file based on it. Partially addresses 
https://issues.dlang.org/show_bug.cgi?id=9285 but is intended 
to be much more simple (no C++, no human-readable emphasis).

[...]


This is all very nice. I agree that this kind of thing should be 
a part of the compiler, but I think it should be a compiler 
plugin. If dmd had compiler plugins, I think stuff like this and 
`dpp` would be much nicer to use.

Re: DIP 1017--Add Bottom Type--Community Review Round 1

[Uknown via Digitalmars-d]

I would like to point out that C++ does this with attributes 
instead[0]. If this was an attribute instead (like `@noreturn`), 
it would simplify interfacing with C++. It would also avoid the 
breaking change.


[0]: eel.is/c++draft/DCL.attral.noreturn

Re: Kaspersky Endpoint Security 10 flags the DMD installer as malicious!

[Uknown via Digitalmars-d]

On Wednesday, 25 July 2018 at 14:30:57 UTC, FeepingCreature wrote:

On Wednesday, 25 July 2018 at 09:13:27 UTC, Mike Franklin wrote:

On Wednesday, 25 July 2018 at 08:27:25 UTC, Rel wrote:
Possibly because anything that says "pay money or we'll flag 
your binary and scare our users about it!" sounds like a scam. 
Also, nowadays virus scanners arguably cause more problems than 
they prevent - viruses have already exploited vulns in virus 
scanners, which usually run as root. And if somebody breaks 
into Github or dlang.org and replaces the binary with a 
backdoored one, they won't use a backdoor that'll be detected 
by common scanners because why would they?


To add to this, I've had issues with kaspersky tagging any 50 
line program I wrote as a virus, as long as it had a do{} while() 
loop in main. Very annoying. At some point people need to realize 
that anti-viruses are not simply never going to improve computer 
security.

Re: Copy Constructor DIP

[Uknown via Digitalmars-d]

On Tuesday, 10 July 2018 at 14:28:09 UTC, FeepingCreature wrote:
On Tuesday, 10 July 2018 at 13:38:33 UTC, Jonathan M Davis 
wrote:

[...]
Using types with an invalid T.init feels like playing musical 
chairs with a crash. You can shuffle things around, and make 
some parts work, but *something* is always left crashing at the 
end.


This is where I feel being able to redefine T.init would be 
useful, but as Andrei said, that is beyond the scope of this DIP

Re: Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length

[Uknown via Digitalmars-d-learn]

On Wednesday, 27 June 2018 at 15:18:05 UTC, Alex wrote:

On Wednesday, 27 June 2018 at 15:07:57 UTC, Uknown wrote:

On Wednesday, 27 June 2018 at 14:50:25 UTC, Alex wrote:

On Wednesday, 27 June 2018 at 14:29:33 UTC, Uknown wrote:

On Wednesday, 27 June 2018 at 14:21:39 UTC, Alex wrote:

On Wednesday, 27 June 2018 at 13:27:46 UTC, Uknown wrote:

[...]

This would:

["123".byCodeUnit.permutations].joiner.writeln;


Thanks. This works, but it still seems silly that permutations 
doesn't just return a range with front returning the original type

Re: Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length

[Uknown via Digitalmars-d-learn]

On Wednesday, 27 June 2018 at 14:50:25 UTC, Alex wrote:

On Wednesday, 27 June 2018 at 14:29:33 UTC, Uknown wrote:

On Wednesday, 27 June 2018 at 14:21:39 UTC, Alex wrote:

On Wednesday, 27 June 2018 at 13:27:46 UTC, Uknown wrote:

[...]


I see. Ok, one possibility is

source = indexed(source, indices).array;

but I assume you want something without extra allocation, right?


This doesn't work for some reason.

"123".byCodeUnit.permutations.array.writeln //[123, 123, 123, 
123, 123, 123]

Re: Preferred Alias Declaration Style

[Uknown via Digitalmars-d-learn]

On Wednesday, 27 June 2018 at 14:29:18 UTC, Basile B. wrote:

On Wednesday, 27 June 2018 at 14:23:25 UTC, Uknown wrote:

On Wednesday, 27 June 2018 at 14:01:06 UTC, Basile B. wrote:

On Wednesday, 27 June 2018 at 12:25:26 UTC, Uknown wrote:
On Wednesday, 27 June 2018 at 10:22:38 UTC, Vijay Nayar 
wrote:

[...]

Nah it's not the same thing ;)


void main()
{
alias void proto_identifier_old();
alias proto_identifier_new = void function();
assert(!is(proto_identifier_old == proto_identifier_new)); 
// passes

}


- proto_identifier_new is a function type (stuff)
- proto_identifier_new is a function **pointer** type (e.g 
)


Actually my answer was more informative because i reported this 
limitation years ago, see 
https://issues.dlang.org/show_bug.cgi?id=16020.


Didn't know that, I assumed that the old style also declared a 
function pointer

Re: Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length

[Uknown via Digitalmars-d-learn]

On Wednesday, 27 June 2018 at 14:21:39 UTC, Alex wrote:

On Wednesday, 27 June 2018 at 13:27:46 UTC, Uknown wrote:

Title says it all. Is there a trivial way to do this?


There are
https://dlang.org/library/std/algorithm/mutation/reverse.html
and
https://dlang.org/library/std/range/retro.html

both require a bidirectional range, which Indexed, luckily is.


I wasn't clear enough. I meant getting back the underlying 
`Source` range with _its_ elements in the order that the indices 
specify. This wouldn't be possible in the generic case, but the 
special case when indices.length == source.length, it should be 
possible. So indexed(myRange, [2, 3, 5, 1, 
4]).sourceWithSwappedElements should return a typeof(myRange) 
with the elements swapped in that order.

Re: Preferred Alias Declaration Style

[Uknown via Digitalmars-d-learn]

On Wednesday, 27 June 2018 at 14:01:06 UTC, Basile B. wrote:

On Wednesday, 27 June 2018 at 12:25:26 UTC, Uknown wrote:

On Wednesday, 27 June 2018 at 10:22:38 UTC, Vijay Nayar wrote:

[...]


aliasing a function type only works with the old syntax too:

alias void proto_identifier();

Very unfriendly syntax. Impossible to express with 
AliasDeclarationY (aka "the new alias syntax").


You can use this syntax for functions :

`alias proto_identifier = void function();`

Getting the underlying range from std.range.indexed, with elements in swapped order, when Indexed.source.length == Indexed.indices.length

[Uknown via Digitalmars-d-learn]

Title says it all. Is there a trivial way to do this?

Re: Preferred Alias Declaration Style

[Uknown via Digitalmars-d-learn]

On Wednesday, 27 June 2018 at 10:22:38 UTC, Vijay Nayar wrote:
Most of the documentation at 
https://dlang.org/spec/declaration.html#alias uses examples of 
the form:  `alias aliasName = other;`, where `aliasName` 
becomes the new name to reference `other`.  Alternatively, one 
may write `alias other aliasName;`.  My understanding is that 
the syntax with `=` is the preferred one stylistically.


However, when it comes to `alias this` declarations, the only 
syntax supported is `alias other this;`, and one cannot write 
`alias this = other;`.


Does this mean that the `alias other aliasName;` syntax is 
preferred, or does it simply mean that this is a low priority 
issue that hasn't been addressed yet?


`alias Alias = SomeType;` is preferred. It is the new style, and 
is more clear on what is the alias and what is the new type, 
especially when complex types come into play. For `alias this` 
though, there is only one syntax, `alias other this;`, since it 
does something conceptually different from regular aliases.

Re: IOS support status

[Uknown via Digitalmars-d]

On Saturday, 16 June 2018 at 12:59:48 UTC, makedgreatagain wrote:

On Saturday, 16 June 2018 at 10:40:44 UTC, Joakim wrote:
On Saturday, 16 June 2018 at 08:10:35 UTC, makedgreatagain 
wrote:

On Friday, 15 June 2018 at 14:50:08 UTC, Joakim wrote:

[...]
I dont know what to deal with 
global.params.targetTriple.isOSDarwin and 
global.params.targetTriple.isMacOSX when I try merge it into 
ldc/master.  should I keep both or just one ?


Darwin can generally imply either macOS, tvOS or iOS, as far as I 
can tell.

Re: Encouraging preliminary results implementing memcpy in D

[Uknown via Digitalmars-d-announce]

On Thursday, 14 June 2018 at 07:54:20 UTC, Jonathan M Davis wrote:
On Wednesday, June 13, 2018 14:34:28 Uknown via 
Digitalmars-d-announce wrote:
Looks very promising. One question though, why not use 
std.datetime.stopwatch.benchmark? I think it has some 
protection against optimizing compilers (I may be wrong 
though). Also, LDC has attributes to control optimizations on 
a per function basis.see : 
https://wiki.dlang.org/LDC-specific_language_changes


Unfortunately, std.datetime.stopwatch.benchmark does not yet 
have such protections. It has been discussed, but there were 
issues with it that still need to be sorted out.


In any case, what he has implemented is pretty much what's in 
Phobos except for the fact that he set up his to take 
arguments, whereas Phobos' solution just takes the function(s) 
to call, so anything that it does has to be self-contained.


- Jonathan M Davis


huh. I saw the PR and assumed it was accepted. Anyway, for DMD 
putting `asm` blocks seems to still disable optimizations, and 
for LDC, the pragma is perfect. GDC is the only unknown.

Re: Which character set does D use?

[Uknown via Digitalmars-d-learn]

On Wednesday, 13 June 2018 at 23:34:02 UTC, Murilo wrote:
Does D use ASCII or UNICODE? It seems to use ASCII since it 
causes error whenever I use a non-ASCII character.


Your system might be misconfigured. D can use UTF-8 (Unicode) 
too. See https://dlang.org/spec/lex.html#source_text

Re: Encouraging preliminary results implementing memcpy in D

[Uknown via Digitalmars-d-announce]

On Wednesday, 13 June 2018 at 06:46:43 UTC, Mike Franklin wrote:
I had a little fun today kicking the crap out of C's memcpy 
with a D implementation.


https://github.com/JinShil/memcpyD

Request for help: I don't have a Linux system running on real 
hardware at this time, nor do I have a wide range of platforms 
and machines to test with.  If you'd like to help me with this 
potentially foolish endeavor, please run the program on your 
hardware and send me the results.


Feedback, advise, and pull requests to improve the 
implementation are most welcome.


Mike


I'm glad to see this kind of improvement! I noticed there wasn't 
any macOS testing though, so heres the results on my machine:


size memcpyC memcpyD
1 38613 5185
2 42475 7259
4 54272 3450
8 29391 3457
16 32947 3626
32 33761 7253
64 44152 14510
128 51985 27711
256 65700 58044
512 95315 119977
1024 150726 387021
2048 265975 667858
4096 521565 1113945
8192 965322 2039064
16384 3923818 3997524
32768 15586237 15669232
65536 33195890 31640205

size memcpyC memcpyD
1 40057 5180
1 36664 5226
1 37625 5280
2 36584 5178
2 36956 5252
4 51086 3448
4 49952 3456
8 29497 3455
8 29710 3987
4 51539 3453
8 29715 3449
16 29747 23535

sys info : Intel Core i5 4258u (28w), 8GB DDR3 1600MHz RAM

Looks very promising. One question though, why not use 
std.datetime.stopwatch.benchmark? I think it has some protection 
against optimizing compilers (I may be wrong though). Also, LDC 
has attributes to control optimizations on a per function 
basis.see : https://wiki.dlang.org/LDC-specific_language_changes


My linux install got messed up, but I'll post benchmarks as soon 
as its up

Re: How to sort byCodeUnit.permutations.filter(...)

[Uknown via Digitalmars-d-learn]

On Tuesday, 12 June 2018 at 14:21:48 UTC, Adam D. Ruppe wrote:

On Monday, 11 June 2018 at 04:39:54 UTC, Uknown wrote:

Why are the strings getting modified?


I'm guessing it reuses a buffer as it iterates.

"123".byCodeUnit.permutations.writeln;//[123, 213, 312, 132, 
231, 321]


[...]

"1234567".byCodeUnit
.permutations
.map!(to!int)
.filter!(a => primes.canFind(a))
.maxElement


that should do it too.


I solved the problem by piping the output to `sort`, but your 
workaround is useful. I'll submit a bug report on this ASAP. 
Thanks for your help!

Re: How to sort byCodeUnit.permutations.filter(...)

[Uknown via Digitalmars-d-learn]

On Monday, 11 June 2018 at 04:12:57 UTC, Adam D. Ruppe wrote:

On Monday, 11 June 2018 at 04:06:44 UTC, Uknown wrote:
The problem is this prints a list of numbers. The task 
requires only the largest, so the intuitive fix


I would just pull the max out of it.

http://dpldocs.info/experimental-docs/std.algorithm.searching.maxElement.2.html


Thanks for your reply. I completely forgot about maxElement. I 
used it, but it prints 1234567, not the permutations. The same 
happens when using array. Why are the strings getting modified? 
The same happens with this:


"123".byCodeUnit.permutations.writeln;//[123, 213, 312, 132, 231, 
321]
"123".byCodeUnit.permutations.array.writeln;//[123, 123, 123, 
123, 123, 123]

Seems odd. Is this a bug or expected behaviour?

How to sort byCodeUnit.permutations.filter(...)

[Uknown via Digitalmars-d-learn]

I wrote a small program for Project Euler problem 41 ( 
https://projecteuler.net/problem=41 ).


--- project_euler_41.d
void main()
{
import math_common : primesLessThan;
import std.stdio : writeln;
import std.conv : parse;
import std.algorithm : permutations, canFind, filter, each, sort;
import std.utf : byCodeUnit;
import std.range : assumeSorted;
import std.array : array;

auto primes = primesLessThan(9_999_999UL).assumeSorted;

"1234567".byCodeUnit
.permutations
.filter!(a => primes.canFind(a.parse!uint))
.each!(a => a.writeln);
}
---

The problem is this prints a list of numbers. The task requires 
only the largest, so the intuitive fix is to add `.array.sort[$ - 
1].writeln` in place of the `each`, but this prints an array of 
`1234567`s instead of the permutations. Does anyone know how to 
sort the filter result without modifying the individual results?

Re: DUB colored output proposal/showcase

[Uknown via Digitalmars-d]

On Friday, 8 June 2018 at 13:51:05 UTC, gdelazzari wrote:
On Friday, 8 June 2018 at 13:38:59 UTC, Steven Schveighoffer 
wrote:

Looks excellent! Two thumbs up from me. Is it cross-platform?

Note on some platforms (ahem, Macos) the background is white, 
so this should be correctly colored for that possibility.


-Steve


At the moment it's "probably" Linux-only, but that's because I 
only wanted a proof of concept and I worked on it on my Linux 
installation. I imported this library/Dub package 
https://github.com/yamadapc/d-colorize and just used it. Which, 
by the way, it's no-good at the moment since I saw that Dub 
doesn't use Dub packages itself - probably because, otherwise, 
you don't have a way to easily compile it without Dub itself, I 
guess :P so I'll need to either write my custom color 
outputting code within Dub's source or just import that library.


Of course making it cross-platform is a mandatory thing to me. 
Windows also needs some specific stuff to output colors, as you 
can see in the library I linked, so there are definitely some 
things to do to support all the platforms. I may even take a 
look at how DMD itself outputs colored output, I guess it will 
be nice to keeps things consistent.


As for MacOS having a different background... I don't really 
own a Mac nor I have ever used one before, so I don't even know 
how tools usually output their colored text on it. At the 
moment it just sets the foreground color to 
green/yellow/blue/whatever, without changing the background, if 
that was your concern. If you meant that yellow-on-white is not 
readable... well... I guess so. Maybe two different color 
palettes should be used? IDK, as I said I never used a Mac 
before so I don't really know how other tools handle this, 
maybe if some Mac user could help on this, it would be great.


Thanks for the appreciation by the way!


I love it! I have very little experience with terminal colours, 
but as far as colourizing text on POSIX its fairly easy. You just 
need to emit the right ANSI escape sequences [0]. This is what 
the colorize-d library does.. For Windows before Windows 10, 
things are more messy. You need to use `handle`s, to get the 
current state and then correctly set the colours. The real hard 
part here is adjusting the colour scheme based on the terminal 
background colour.


[0]: https://en.wikipedia.org/wiki/ANSI_escape_code#Colors

Re: Conditionally set nothrow: for a block of code.

[Uknown via Digitalmars-d-learn]

On Thursday, 24 May 2018 at 18:51:31 UTC, Mike Franklin wrote:
I'm trying to find a way to declare a block of code `nothrow:` 
when compiling with -betterC, but not `nothrow` when not 
compiling with -betterC.


The solution is needed for this PR:  
https://github.com/dlang/druntime/pull/2184/files#r188627707

[...]
Given that the PR above is for object.d, I can't turn the 
entire object.d source file into a string and conditionally mix 
that in.

 Does anyone have a solution to this?

Thanks,
Mike


I think conditional application of attributes would be something 
useful. Something like this:


version (D_BetterC)
enum BetterC = true;
else
enum BetterC = false;

nothrow!(BetterC):
...

Of course that would require a DIP though

Re: Sealed classes - would you want them in D? (v2)

[Uknown via Digitalmars-d]

On Saturday, 19 May 2018 at 09:10:32 UTC, KingJoffrey wrote:

On Saturday, 19 May 2018 at 08:32:28 UTC, Uknown wrote:


I ported your example to Java. Surprisingly, it compiled and 
executed just fine:


All I see, is a class, with static members. How else would it 
work?


This is the equivalent of my D example, in Java:

( it won't even compile.  phew!  )



The point was encapsulation as you defined it was broken. private 
members were directly modified outside their class. In your 
words, everyone was a friend.

Re: Sealed classes - would you want them in D? (v2)

[Uknown via Digitalmars-d]

On Saturday, 19 May 2018 at 07:57:39 UTC, KingJoffrey wrote:

On Saturday, 19 May 2018 at 04:01:18 UTC, KingJoffrey wrote:

[...]


module test;

@safeinterface class Dog
{
private string noiseType = "woof";

public string makeNoise()
{
return this.noiseType;
}
}

void main()
{
import std.stdio;

auto dog = new Dog;
dog.noiseType = "meow"; // no way jose - requires use of 
the safe interface!

writeln(dog.makeNoise()); // phew! cause dogs can only bark.
}
---


I ported your example to Java. Surprisingly, it compiled and 
executed just fine:


--- test.java
class test
{
static class Dog
{
private String noiseType = "woof";

public String makeNoise()
{
return this.noiseType;
}
}

public static void main(String[] args)
{
Dog dog = new Dog();
		dog.noiseType = "meow"; // no way jose - requires use of the 
safe interface!

System.out.println(dog.makeNoise()); // phew! cause dogs meow.
}
}
---

Re: is ==

[Uknown via Digitalmars-d-learn]

On Friday, 18 May 2018 at 23:53:12 UTC, IntegratedDimensions 
wrote:
Why does D complain when using == to compare with null? Is 
there really any technical reason? if one just defines == null 
to is null then there should be no problem. It seems like a 
pedantic move by who ever implemented it and I'm hoping there 
is actually a good technical reason for it.


D only complains of this when you use ref types (classes or AAs). 
For e.g:

--- test.d
void main()
{
int * p;
assert (p == null && p is null);
class C
{
int x;
}
C c;
assert (c is null);
assert (c == null); //error, c is a reference, so there is 
confusion between opEquals and null check

}
---

Re: Temporary file creation for unittests

[Uknown via Digitalmars-d-learn]

On Friday, 18 May 2018 at 15:16:52 UTC, Russel Winder wrote:

Hi,

What's the current official position on how to create temporary 
files for use during a unittest. I found


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

but it seems to be languishing in the "we have discussed all 
the issues that no-one will ever have a problem with" phase.


What to do between now and when there is an LDC release that 
has the result of

the merge?


You could use libc's tmpfile with std.stdio.File until a D 
alternative pops up.


http://en.cppreference.com/w/c/io/tmpfile

Re: Sealed classes - would you want them in D? (v2)

[Uknown via Digitalmars-d]

On Thursday, 17 May 2018 at 11:18:52 UTC, KingJoffrey wrote:

On Thursday, 17 May 2018 at 10:34:18 UTC, Zoadian wrote:

On Thursday, 17 May 2018 at 02:32:07 UTC, KingJoffrey wrote:

[...]
People from c++ might be suprised by 'private' already. We do 
not have to confuse those c#ies too.


Interesting.

If only D had applied that same criteria to use of the word 
'private'.


Have you considered the keyword `module`?

--- kings.d
class King
{
private string _name;
module string __name;
public string getName()
{
return __name;
}
public void setName(string name)
{
__name = name;
}
}

void main()
{
scope king = new King();
king._name = "me"; //ok: _name is private
king.__name = "me"; //error: __name is of `module` scope
king.setName("me"); //ok
}

I do wonder what word could possibly suffice, to please 
everyone.


`module`

/s

[...]
Again, DIP before discussion, and we all know what will happed 
to the DIP.


I won't oppose such an addition since it will be purely opt-in, 
but you will have to consider that this would add more specifiers:

`private`, `protected`, `package`, `public` and `export`.
You might also want to read these [0] past discussions on this 
feature. I'm not sure how up to date that doc is, but it should 
be a good starting point.


[0]: 
https://wiki.dlang.org/Access_specifiers_and_visibility#Current_state_of_affairs_in_C.2B.2B

Re: Sealed classes - would you want them in D?

[Uknown via Digitalmars-d]

On Wednesday, 16 May 2018 at 07:53:36 UTC, aliak wrote:

On Wednesday, 16 May 2018 at 06:34:35 UTC, KingJoffrey wrote:

On Wednesday, 16 May 2018 at 06:17:51 UTC, Uknown wrote:
Also, if you want the rust style `private`, D offers 
`package`, which means private to the modules contained by a 
package.


Thanks for clarifying this.


I did not read the rust spec :p, but from the conversations 
above I believe rust private is not D package. Rust private is 
private in the module, package in D is all modules in a 
package. D would be:


module mod;
private: // put this at top of file and everything below it is 
not private



public void f () {} // explicitly request this one to be public


Just checked the rust spec [0]. private in rust => accessible 
from that module and its descendants, which is what package in D 
is. private in D would be to that module only.


[0]: 
https://doc.rust-lang.org/beta/reference/visibility-and-privacy.html

Re: Sealed classes - would you want them in D?

[Uknown via Digitalmars-d]

On Wednesday, 16 May 2018 at 06:05:31 UTC, KingJoffrey wrote:

On Wednesday, 16 May 2018 at 05:59:17 UTC, Tobias Müller wrote:

KingJoffrey  wrote:
The problem is not so much D, but that C++/Java/C# 
programmers, and many from other languages (Go, Rust) 
will expect private to mean private...not private..depending 
on


Well, that's not entirely true.
Visibility in Rust is similar to D.
There's no one true language semantics that holds for all 
languages. That's

the point of having different languages.


actually, private is default in Rust.

public is default in D.

also, in Rust, private is private within the module, *and* its 
descendants.


I don't believe that is the case in D (someone correct me if 
I'm wrong)


`public` by default is again not a problem. Just apply `private` 
as necessary. Also, if you want the rust style `private`, D 
offers `package`, which means private to the modules contained by 
a package.

Re: Sealed classes - would you want them in D?

[Uknown via Digitalmars-d]

On Wednesday, 16 May 2018 at 03:36:39 UTC, KingJoffrey wrote:
On Wednesday, 16 May 2018 at 03:12:03 UTC, Jonathan M Davis 
wrote:


[...]
- Jonathan M Davis


To suggest that "Symbols with private visibility can only be 
accessed from within the same module" - is all you need to know 
(if you're lucky to find the needle in the haystack), is kinda 
elitist.


One is expected to know the tool they are using. There is nothing 
elitist about that.



People expect norms to be the norm. That's entirely reasonable.

If I see a STOP sign while I'm driving, I expect it means STOP, 
not 'STOP..if.."


If I see private, I expect it means private, not 'private..if'.


There is no if. You know what the stop sign means because someone 
told you what it means. private means it is only available to the 
module. It is entirely the fault of the user for not reading the 
docs.



The language reference could, and should do better.


Its actively being improved, but in this case it was more than 
adequate. The spec was pretty clear that private applies to 
modules.

Re: Is D releasing too often?

[Uknown via Digitalmars-d]

On Monday, 14 May 2018 at 08:29:30 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 05/14/2018 03:20 AM, Joakim wrote:

[..]
Summary (That's "TL:DR" in hipster parlance): **Available** 
updates are always a good thing, as long as they're checked for 
regressions. Any issues keeping up with updates only indicate 
we have a *good* problem: That the ecosystem has room for 
"process" improvements and isn't currently being constrained by 
lack of progress in dependencies.


Agree, but I think LTS releases are worth considering. A yearly 
release that gets only bug fixes would be useful for stability.

Re: Is D releasing too often?

[Uknown via Digitalmars-d]

On Monday, 14 May 2018 at 07:46:35 UTC, Mike Franklin wrote:

On Monday, 14 May 2018 at 07:20:48 UTC, Joakim wrote:


[...]


The post is here: 
https://forum.dlang.org/post/ingkexhebiaqdzkni...@forum.dlang.org

[...]
Mike


I agree with you. I think the best way is to make it one release 
every 3 months or so and have a yearly LTS release that people 
can rely on for stability. On the plus side, I really like the 
predictable realeases.

Re: Exceptions without GC/Dynamic allocation. New proposal from Herb Sutter for C++

[Uknown via Digitalmars-d]

On Sunday, 13 May 2018 at 17:21:28 UTC, Ben Jones wrote:
I think similar ideas have been discussed around here before 
(https://forum.dlang.org/thread/stlslhjndgugecvmb...@forum.dlang.org) but here's a new C++ proposal for overhauling their exception system to avoid dynamic allocation for exceptions.  I guess it's not surprising that they're dealing with similar issues for exception handing as the D community.

[...]


Worth mentioning that DIP 1008 makes exceptions Ref-counted 
instead of GC managed, so exceptions can now be @nogc in D

Re: Bug?: Presence of "init()" Method Causes std.array.appender to Fail to Compile

[Uknown via Digitalmars-d]

On Sunday, 13 May 2018 at 23:53:58 UTC, Vijay Nayar wrote:
I encountered a very unexpected error when working on a 
project.  It seems that the Appender and RefAppender structs 
created from the std.array.appender() method are sensitive to 
the mere presence of a method called "init()" on the element 
type of the array.


[...]


init is a reserved function. T.init is the initial value for a 
type. int.init is 0 and float.init is NaN. Try changing your 
function name to initialise or something like that.

Re: Sealed classes - would you want them in D?

[Uknown via Digitalmars-d]

On Sunday, 13 May 2018 at 01:52:20 UTC, KingJoffrey wrote:

On Saturday, 12 May 2018 at 18:36:59 UTC, Walter Bright wrote:

On 5/12/2018 9:42 AM, Mike Parker wrote:

Thank goodness we don't have to do this silliness.


[...]


module test;

import std.stdio : writeln;

void main()
{
Person p = new Person("King Joffrey");

writeln(p.getName); // I designed my class to present this 
interface.
writeln(p._name); // The module couldn't care less about 
your interface.


p._name = "King Walter"; // even worse, the module can 
de-throne the king!!

writeln(p._name);
}

class Person
{
private string _name;

public void setName(string name)
{
this._name = name;
}

public string getName()
{
return ProperName(this._name);
}

public this(string name)
{
_name = name;
}

private static string ProperName(string name)
{
return name ~ " : The one true king!";
}
}

===


Again, all you have to do is put class Person in a separate 
module. Its not that hard. Why is main in the same module if it 
isn't logically related to Person? It should be in its own 
module. Its uses Person. main does not extend person, it needs 
only the public bits. So it goes in its own module. And please, 
if this bothers you so much, start a new thread. You're spamming 
someone else's feature request by going off topic.

Re: iopipe v0.0.4 - RingBuffers!

[Uknown via Digitalmars-d-announce]

On Friday, 11 May 2018 at 23:46:16 UTC, Dmitry Olshansky wrote:
On Friday, 11 May 2018 at 13:28:58 UTC, Steven Schveighoffer 
wrote:

On 5/11/18 1:30 AM, Dmitry Olshansky wrote:
On Thursday, 10 May 2018 at 23:22:02 UTC, Steven 
Schveighoffer wrote:
grep on Mac is a piece of sheat, sadly and I don’t know why 
exactly (too old?). Use some 3-rd party thing like ‘sift’ 
written in Go.


You can always use GNU grep. The one that comes with macOS is 
pretty old and slow. If you have macports, its just `port install 
grep`. I'm sure brew will have a similar package for GNU grep.

Re: Extend the call site default argument expansion mechanism?

[Uknown via Digitalmars-d]

On Friday, 11 May 2018 at 14:26:21 UTC, Jonathan M Davis wrote:
On Thursday, May 10, 2018 14:15:18 Yuxuan Shui via 
Digitalmars-d wrote:

So in D I can use default argument like this:
[...]
Is this a good idea?


It seems like really risky move, honestly, because it means 
that the function is then affected by what is and isn't 
declared within the scope where it's called. __FILE__ and 
__LINE__ are well-defined as to what they mean. No can declare 
them to mean something else. You don't have symbol resolution 
issues or naming conflicts. And they're solving a problem that 
can't actually be solved without compiler help. However, if you 
just want to change what arguments get passed to foo within 
your module, all you have to do is define another foo inside 
the module and have it forward to the original one with 
whatever arguments you want. What you're suggesting here seems 
to introduce name pollution issues without solving anything 
that can't easily be solved with the language as-is.


- Jonathan M Davis


I see what you're saying and I agree with you. I think a better 
way would be to try and extend the `with` syntax to work with 
arbitrary functions, rather than only objects. That would make it 
more useful. So something like:


---
void f1(allocator alloc, ...){}
void f2(allocator alloc, ...){}
...
void fn(allocator alloc, ...){}

void main()
{
with(MyAllocator) {
f1(...);
f2(...);
...
fn(...);
}
}
---

Re: iopipe v0.0.4 - RingBuffers!

[Uknown via Digitalmars-d-announce]

On Friday, 11 May 2018 at 13:28:58 UTC, Steven Schveighoffer 
wrote:

[...]
I do get the point of having to go outside the cache. I'll look 
and see if maybe specifying a 1000 line context helps ;)


Update: nope, still pretty much the same.



I'm sure someone will find some good show off program.

The amount of work done per byte though has to be minimal to 
actually see anything.


Right, this is another part of the problem -- if copying is so 
rare compared to the other operations, then the difference is 
going to be lost in the noise.


What I have learned here is:

1. Ring buffers are really cool (I still love how it works) and 
perform as well as normal buffers

2. The use cases are much smaller than I thought
3. In most real-world applications, they are a wash, and not 
worth the OS tricks needed to use it.


Now I need to learn all about ring-buffers. Do you have any good 
starting points?


4. iopipe makes testing with a different kind of buffer really 
easy, which was one of my original goals. So I'm glad that 
works!


That satisfying feeling when the code works exactly the way you 
wanted it to!


I'm going to (obviously) leave them there, hoping that someone 
finds a good use case, but I can say that my extreme excitement 
at getting it to work was depressed quite a bit when I found it 
didn't really gain much in terms of performance for the use 
cases I have been doing.


I'm sure someone will find a place where its useful.


However, this example *does* show the power of iopipe -- it 
handles all flavors of unicode with one template function, is 
quite straightforward (though I want to abstract the line 
tracking code, that stuff is really tricky to get right). Oh, 
and it's roughly 10x faster than grep, and a bunch faster 
than fgrep, at least on my machine ;) I'm tempted to add 
regex processing to see if it still beats grep.


Should be mostly trivial in fact. I mean our first designs for 
IOpipe is where I wanted regex to work with it.


Basically - if we started a match, extend window until we get 
it or lose it. Then release up to the next point of potential 
start.


I'm thinking it's even simpler than that. All matches are dead 
on a line break (it's how grep normally works), so you simply 
have to parse the lines and run each one via regex. What I 
don't know is how much it costs regex to startup and run on an 
individual line.


One thing I could do to amortize is keep 2N lines in the 
buffer, and run the regex on a whole context's worth of lines, 
then dump them all.


iopipe is looking like a great library!

I don't get why grep is so bad at this, since it is supposedly 
doing the matching without line boundaries. I was actually 
quite shocked when iopipe was that much faster -- even when I'm 
not asking grep to print out line numbers (so it doesn't 
actually ever really have to keep track of lines).


-Steve


That reminds me of this great blog post detailing grep's 
performance:

http://ridiculousfish.com/blog/posts/old-age-and-treachery.html

Also, one of the original authors of grep wrote about its 
performance optimizations, for anyone interested:

https://lists.freebsd.org/pipermail/freebsd-current/2010-August/019310.html

Re: errno is not nothrow

[Uknown via Digitalmars-d]

On Friday, 11 May 2018 at 09:10:48 UTC, Cym13 wrote:

On Friday, 11 May 2018 at 07:05:12 UTC, Shachar Shemesh wrote:
At least under Linux, you cannot get or set the value of errno 
from a nothrow function.


Is this on purpose, or is this a bug?

Shachar


It seems I can't reproduce with core.stdc.errno, could you 
please share some code?


Can confirm:

https://run.dlang.io/is/ptkpz0

Re: Sealed classes - would you want them in D?

[Uknown via Digitalmars-d]

On Friday, 11 May 2018 at 04:43:09 UTC, KingJoffrey wrote:

On Friday, 11 May 2018 at 03:32:25 UTC, Uknown wrote:


`private` is for outside the module. Within the module, 
private is not applied because D wanted to avoid C++'s 
`friend` functions.


'private' is "meant" to be part of the implementation of 'the 
class'.


Whereas D makes it part of the implementation of 'the module' ( 
which is an even higher level of abstraction).


This is an abomination!

A class should have the capacity to protect its 
attributes/methods - even from the module.


Let's not start this discussion again
https://forum.dlang.org/post/tksnoqntxtpgqbwsl...@forum.dlang.org

Re: Sealed classes - would you want them in D?

[Uknown via Digitalmars-d]

On Friday, 11 May 2018 at 03:11:48 UTC, KingJoffrey wrote:
On Thursday, 10 May 2018 at 21:26:12 UTC, Jonathan M Davis 
wrote:

Idiomatic D tends to use classes rarely...


What is the basis for this assertion?


D tends to prefer structs with UFCS member functions rather than 
classes, because one rarely needs the reference semantics or 
inheritance. Also, classes are pretty inconvenient because they 
are hard to use without the GC.




On a separate issue, 'private' should mean private! (not 
kinda-private).


Let's not make D classes even more of joke.


`private` is for outside the module. Within the module, private 
is not applied because D wanted to avoid C++'s `friend` functions.

Re: Extend the call site default argument expansion mechanism?

[Uknown via Digitalmars-d]

On Thursday, 10 May 2018 at 14:37:00 UTC, rikki cattermole wrote:

On 11/05/2018 2:33 AM, Yuxuan Shui wrote:

On Thursday, 10 May 2018 at 14:28:39 UTC, JN wrote:

On Thursday, 10 May 2018 at 14:15:18 UTC, Yuxuan Shui wrote:

[...]


But doing it with default argument expansion saves you 1 
allocation, has 1 less type, while being just as readable. I 
think that's a win.


class -> struct, now it is back to 1 allocation.


Alternatively `scope`d classes would also work with dip1000

Re: Extra .tupleof field in structs with disabled postblit blocks non-GC-allocation trait

[Uknown via Digitalmars-d-learn]

On Thursday, 10 May 2018 at 11:06:06 UTC, Per Nordlöw wrote:

On Wednesday, 9 May 2018 at 21:09:12 UTC, Meta wrote:
It's a context pointer to the enclosing 
function/object/struct. Mark the struct as static to get rid 
of it.


Ok, but why an extra void* for `S.tupleof` and not for 
`T.tupleof` which is also scoped inside a unittest?


I'm guessing T is a POD, so it doesn't need a context pointer, 
whereas S is not counted as a POD since a member function was 
@disabled.

Re: dmd testsuite's runner is now in D

[Uknown via Digitalmars-d]

On Tuesday, 8 May 2018 at 12:51:42 UTC, Seb wrote:
Just a quick heads-up for all the people using Windows and who 
have previously complained about the usage of GNUmake for DMD's 
testsuite.


[...]


This is great news! Any chance at a slightly more detailed write 
up on the blog or announce?

Re: C++ / const class pointer signature / unable to find correct D syntax

[Uknown via Digitalmars-d-learn]

On Friday, 4 May 2018 at 07:49:02 UTC, Robert M. Münch wrote:
I have a static C++ and can't make it to get a correct binding 
for one function:


DMD: public: unsigned int __cdecl b2d::Context2D::_begin(class 
b2d::Image & __ptr64,class b2d::Context2D::InitParams const * 
__ptr64 const) __ptr64
LIB: public: unsigned int __cdecl b2d::Context2D::_begin(class 
b2d::Image & __ptr64,class b2d::Context2D::InitParams const * 
__ptr64) __ptr64


So I somehow get some more const from D. This is the code I 
used:


   final uint _begin(ref Image image, const(InitParams) 
initParams);


Which creates a const pointer to a const class signature. But 
it should only be a const pointer. Any idea how to solve this?


The problem is that const in D is transitive. That means T * 
const from C++ is not expressible in D. Any reference through a 
const becomes const. To use it, IMO your best bet is to make a 
wrapper function on the C++ side like this:


unsigned int __cdecl b2d::Context2D::_begin(class b2d::Image & 
im,class b2d::Context2D::InitParams const * const InitParams)

{
return //the call to the original c++ function
}

Alternatively you can use dpp, or dstep or some similar tool to 
try and let the tool create bindings. As a last ditch, you can 
force the mangle to match by using pragma(mangle, ...) like this:


pragma(mangle, _ZactualMangleFromC++Compiler)
final uint _begin(ref Image image, const(InitParams) initParams);

Re: Is build a 64 bit version worth if I'm looking for better perfomance?

[Uknown via Digitalmars-d-learn]

On Tuesday, 1 May 2018 at 22:48:08 UTC, Dr.No wrote:
Looking for make application run fast as possible, aside 
optimization in the source code, is using 64 bit over 32 really 
worth?


With the GC yes, since false pointers become less of an issue. 
Also you get to take full advantage of the target CPU. The vast 
majority of home computers today use 64 bit. You'll also be able 
to take advantage of more optimizations since the compiler can 
assume more features are available. But you will *probably* get 
better performance from profiling + optimizing than 32 bit -> 64 
bit.

Re: Passing to c++ std::string and vector

[Uknown via Digitalmars-d-learn]

On Monday, 30 April 2018 at 01:07:35 UTC, NewUser wrote:

Hi,

How do I pass a d string to a c++ std::string?

NewUser


There is no trivial way to do this as far as I'm aware, mostly 
due to C++ mangling issues in DMD. You can try calypso [0] or dpp 
[1], which might work. You can also see this PR[2]


[0]: https://wiki.dlang.org/Calypso
[1]: 
https://forum.dlang.org/post/kbcdppawjtcdkdtdz...@forum.dlang.org

[2]: https://github.com/dlang/druntime/pull/1316

Re: Places to hang out in Munich the day before the conference

[Uknown via Digitalmars-d]

On Wednesday, 25 April 2018 at 06:59:37 UTC, Shachar Shemesh 
wrote:

Hello everybody,

I'll be arriving in Munich on the morning of May 1st. I was 
wondering whether anyone has any recommendations as to how to 
spend that day?


Thanks,
Shachar


I'm not comming myself, but there were a few posts outlining what 
you could do there. You seem to be just in time for some 
traditional Maypole Erection


https://forum.dlang.org/post/rvawuhskjoyvcuzfr...@forum.dlang.org

There seems to be a little bit of info on what you can do in this 
thread:

https://forum.dlang.org/thread/qkfwiejjggfaahhzm...@forum.dlang.org?page=1

There was another thread that was started by a local resident 
detailing tourist attractions, but I can't seem to find it right 
now. You can also always check wikipedia, which has some good info

Re: Favorite GUI library?

[Uknown via Digitalmars-d]

On Tuesday, 24 April 2018 at 11:15:43 UTC, Uknown wrote:

On Tuesday, 24 April 2018 at 10:30:21 UTC, Chris wrote:

On Monday, 23 April 2018 at 14:38:44 UTC, TheGag96 wrote:



That's definitely what I'm trying to avoid... I feel those 
kinds of interfaces are 99% of the time mega bloated for what 
they are. Discord is the only one that seemed big enough for 
the britches of an entire browser instance. Absolutely not a 
fan of Electron and the like.


I have never tried dwt! I should give that a shot. And I was 
trying gtkd once, and I should probably try again. Back then, 
I had to compile with --build=plain due to some weird linker 
issues.


The advantage of using web technologies for UI:

- high re-usability: use the same or similar 
layout+functionality for desktop, Android/iPhone apps and web 
based UIs.
- freedom as to layout and theming with CSS (highly 
customizable for users too)
- cross platform: no need to deploy libs (e.g. Gtk on Mac and 
Windows)
- maintenance: older JS code / CSS will still be ok in _most_ 
cases, whereas Gtk and other frameworks introduce depractaions 
and breaking changes so that you have to a) rewrite parts of 
your code and b) maintain older (outdated) versions of the 
program until you can be sure that the older libs are no 
longer used / distributed
- distribution: While users don't care about your maintenance 
costs, they do care about having an app available on their 
smart phones/desktops/online. So multiply various versions of 
say a Gtk app by platform (_at least_ you have to maintain 
2Gtk*3Platform = 6 apps). Users hate being told that it only 
works on Linux desktop. Thus, web technologies can be a real 
gain.
- progress: web technologies have made huge progress JS and 
CSS are much better now. Layout and js engines are much 
smarter as well. So you benefit from this and get it more or 
less for free on every platform.


These are nice points, but the fact remains that running a web 
browser torun something as simple as a text editor is extremely 
inefficient. I personally don't use atom, VS-code or anything 
else, because they are all very slow. I tried VC-code once. It 
was nice in terms of UI, but was borderline unusable because it 
would take almost half a second to register keys, and the 
laptop fans would always spin up.

Using it on a laptop means:
- You will be using far more memory. This means its harder to 
open multiple tabs or programs (profiler + editor or docs in 
Firefox)
- Mobile device battery life takes a hit. This is non 
negligible. Battery life on my old mac using just vim (with a 
few plugins) is 6 hrs. With vs-code it was 2-3 hrs
- Way more on disk memory. With disk space becoming cheap, this 
is less of a concern for most modern devices, but why be 
wasteful? Besides, in developing countries, its still pretty 
hard to get lots of storage, which means users are forced to 
decide which apps are more important.
- If the mobile device's CPU is under less load, in general it 
will remain cooler and thus less likely to throttle. Putting 
pressure on the thermal cap by running CPU intensive programs 
like a browser, when it can be done more efficiently is bad


We should be getting more efficient with time, especially 
considering Moore's law is on its last legs, not less efficient


I forgot to mention consistency. This is the biggest reason I 
don't use non native apps. I'm not talking about your app being 
consistent across operating systems. I'm referring to being 
consistent with programs on the current system. E.g a native 
macOS app has a certain way it looks and behaves. I can expect 
cmd+w to close a window, cmd+q to quit and the the "traffic 
lights" to be on the top left. Non native apps mess things up, 
making them harder to use. Keyboard shortcuts _generally_ work, 
but when they don't they are a pain. Even messing with buttons, 
making them smaller, or placing them weirdly, or using custom 
tabs and menus makes it harder to work with a program.
For e.g. look at the divide between "modern" and "native" apps on 
Windows. Even on linux, back in the day, GTK apps looked out of 
place on QT systems and vice versa.

Re: Who says we can't call C++ constructors?

[Uknown via Digitalmars-d-announce]

On Tuesday, 24 April 2018 at 11:19:59 UTC, Atila Neves wrote:

On Monday, 23 April 2018 at 20:40:47 UTC, Manu wrote:
On 23 April 2018 at 07:27, Atila Neves via 
Digitalmars-d-announce  
wrote:

On Saturday, 21 April 2018 at 18:11:09 UTC, Manu wrote:


On 21 April 2018 at 05:41, Atila Neves via 
Digitalmars-d-announce 
 wrote:


[...]

Sure.

I thought about generating D wrappers for everything, but in 
TDD fashion I tried slapping a pragma(mangle) on the copy 
constructor and things just worked. Odd then that dmd doesn't 
try to correctly mangle constructors and destructors since 
they're perfectly callable.


[...]


This is very cool. Is it possible to fix the mangling issues in 
DMD for Copy constructors and destructors? It seems like it would 
be less code for dpp, and better C++ interop for D in general.

Re: Favorite GUI library?

[Uknown via Digitalmars-d]

On Tuesday, 24 April 2018 at 10:30:21 UTC, Chris wrote:

On Monday, 23 April 2018 at 14:38:44 UTC, TheGag96 wrote:



That's definitely what I'm trying to avoid... I feel those 
kinds of interfaces are 99% of the time mega bloated for what 
they are. Discord is the only one that seemed big enough for 
the britches of an entire browser instance. Absolutely not a 
fan of Electron and the like.


I have never tried dwt! I should give that a shot. And I was 
trying gtkd once, and I should probably try again. Back then, 
I had to compile with --build=plain due to some weird linker 
issues.


The advantage of using web technologies for UI:

- high re-usability: use the same or similar 
layout+functionality for desktop, Android/iPhone apps and web 
based UIs.
- freedom as to layout and theming with CSS (highly 
customizable for users too)
- cross platform: no need to deploy libs (e.g. Gtk on Mac and 
Windows)
- maintenance: older JS code / CSS will still be ok in _most_ 
cases, whereas Gtk and other frameworks introduce depractaions 
and breaking changes so that you have to a) rewrite parts of 
your code and b) maintain older (outdated) versions of the 
program until you can be sure that the older libs are no longer 
used / distributed
- distribution: While users don't care about your maintenance 
costs, they do care about having an app available on their 
smart phones/desktops/online. So multiply various versions of 
say a Gtk app by platform (_at least_ you have to maintain 
2Gtk*3Platform = 6 apps). Users hate being told that it only 
works on Linux desktop. Thus, web technologies can be a real 
gain.
- progress: web technologies have made huge progress JS and CSS 
are much better now. Layout and js engines are much smarter as 
well. So you benefit from this and get it more or less for free 
on every platform.


These are nice points, but the fact remains that running a web 
browser torun something as simple as a text editor is extremely 
inefficient. I personally don't use atom, VS-code or anything 
else, because they are all very slow. I tried VC-code once. It 
was nice in terms of UI, but was borderline unusable because it 
would take almost half a second to register keys, and the laptop 
fans would always spin up.

Using it on a laptop means:
- You will be using far more memory. This means its harder to 
open multiple tabs or programs (profiler + editor or docs in 
Firefox)
- Mobile device battery life takes a hit. This is non negligible. 
Battery life on my old mac using just vim (with a few plugins) is 
6 hrs. With vs-code it was 2-3 hrs
- Way more on disk memory. With disk space becoming cheap, this 
is less of a concern for most modern devices, but why be 
wasteful? Besides, in developing countries, its still pretty hard 
to get lots of storage, which means users are forced to decide 
which apps are more important.
- If the mobile device's CPU is under less load, in general it 
will remain cooler and thus less likely to throttle. Putting 
pressure on the thermal cap by running CPU intensive programs 
like a browser, when it can be done more efficiently is bad


We should be getting more efficient with time, especially 
considering Moore's law is on its last legs, not less efficient

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Uknown via Digitalmars-d]

On Tuesday, 24 April 2018 at 07:15:38 UTC, Dave wrote:
On Sunday, 28 January 2018 at 16:02:36 UTC, Jonathan M Davis 
wrote:
> The problem is Teoh that learning a language in Vim or a 
> IDE are two totally different things.


vim is a fantastic tool but it can be time consuming to 
configure. So I am wondering if some vim-D users would kindly 
share their vim setup for D and maybe even give some insights 
into their vim-D work-flow?


Thx Dave


You can checkout [0], [1] which have some nice info on setting up 
various IDEs and text editors for D. vim in specific already had 
syntax highlighting support by default. Just do `syntax on`. You 
can enable other features like standard library highlighting, 
util snips, etc, by looking at [2].


[0]:https://wiki.dlang.org/Editors
[1]:https://wiki.dlang.org/IDEs
[2]:https://wiki.dlang.org/D_in_Vim

Re: Beta 2.080.0

[Uknown via Digitalmars-d-announce]

On Tuesday, 17 April 2018 at 17:53:22 UTC, Martin Nowak wrote:
Glad to announce the first beta for the 2.080.0 release, ♥ to 
the 65 contributors for this release.


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


As usual please report any bugs at https://issues.dlang.org

- 

Highlights:

https://dlang.org/changelog/2.080.0.html#fix5227 
https://dlang.org/changelog/2.080.0.html#isReturnOnStack 
https://dlang.org/changelog/2.080.0.html#objc_class_methods 
https://dlang.org/changelog/2.080.0.html#std-typecons-nullable-apply


- -Martin


Nice! Seems like a good amount of work was done.

Just thought I'd mention that the link to std.typecons.BitFlags 
in its desciption was broken

Re: How to use std.meta.Filter?

[Uknown via Digitalmars-d-learn]

On Saturday, 21 April 2018 at 17:46:05 UTC, Dr.No wrote:
On Saturday, 21 April 2018 at 17:15:47 UTC, Jonathan M Davis 
wrote:
On Saturday, April 21, 2018 16:05:22 Dr.No via 
Digitalmars-d-learn wrote:

import std.meta : Filter;
enum isNotReservedSymbol(string name) = name != "none" && 
name !=

"lastToken";
enum string[] members = staticMembers!Token;
static foreach(member; Filter!(isNotReservedSymbol, members))
{{


This return the error:

  Error: template instance `pred!(["none", "word", "n", 
"digits",

"name", /* my whole array here */ ])  does not match template
declaration isNotReservedSymbol(string name)

how should have isNotReservedSymbol be defined?


std.meta.Filter operates on an AliasSeq, not a dynamic array. 
If you have an array, then you can just use 
std.algorithm.iteration.filter with a normal lambda.


- Jonathan M Davis


I've tried use normal filter - albeit i'm willing to do all 
that at runtin, but I got f cannot be read at compile time.


static foreach(member; staticMembers!Token.filter!(f => 
isNotReservedSymbol!(member))


If you are confused by why some things work during compilation 
and others don't, I would encourage you to read 
https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
Its a nice article explaining how there are two "compile-time" 
steps where code can be executed.

Re: dynamically allocating on the stack

[Uknown via Digitalmars-d-learn]

On Sunday, 22 April 2018 at 01:07:44 UTC, Giles Bathgate wrote:
On Saturday, 21 April 2018 at 19:06:52 UTC, Steven 
Schveighoffer wrote:
alloca is an intrinsic, and part of the language technically 
-- it has to be.


Why does:

scope c = new C();   // allocate c on stack
scope a = new char[len]; // allocate a via gc?


Its a special case for classes. Makes them usable without the GC.

Re: dynamically allocating on the stack

[Uknown via Digitalmars-d-learn]

On Saturday, 21 April 2018 at 07:37:50 UTC, Mike Franklin wrote:
Does D have some way to dynamically allocate on the stack?  I'm 
looking for something roughly equivalent to the following C 
code.


int doSomething(size_t len)
{
char stackBuffer[len + 1];
doSomethingElse(stackBuffer);
}

Thanks,
Mike


The language itself doesn't have something, but you could use 
`alloca`:


---
void doSomething(size_t len)
{
import core.stdc.stdlib, core.stdc.stdio;

auto stackBuffer = (cast(char*) alloca(char.sizeof * len + 
1))[0 .. len + 1];

stackBuffer[0] = 'H';
stackBuffer[1] = '\0';
printf("%.*s", stackBuffer.ptr);
}

void main()
{
doSomething(2);
}
---

Re: Feature to get or add value to an associative array.

[Uknown via Digitalmars-d]

On Friday, 20 April 2018 at 15:00:39 UTC, Steven Schveighoffer 
wrote:

On 4/20/18 10:34 AM, Uknown wrote:
On Friday, 20 April 2018 at 14:02:17 UTC, Steven Schveighoffer 
wrote:

On 4/20/18 4:24 AM, Nick Treleaven wrote:

On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:

[...]


Sorry, it was a typo. In my real code I have:

xp = &(foo(x));

That's what I get for hand-typing instead of copy-pasting :)

-Steve


It seems like a bug. Changing foo to take and return an `int *` 
works as expected

https://run.dlang.io/is/3NYXYv

Re: Feature to get or add value to an associative array.

[Uknown via Digitalmars-d]

On Friday, 20 April 2018 at 14:02:17 UTC, Steven Schveighoffer 
wrote:

On 4/20/18 4:24 AM, Nick Treleaven wrote:

On Wednesday, 18 April 2018 at 16:47:50 UTC, ag0aep6g wrote:

You can get a pointer from the ref return:

    Value* p = ("key", { inserted = true; return 
Value.init; });


This is not @safe, even with -dip1000:

Error: cannot take address of ref return of f() in @safe 
function main


Hm... I would have expected it to work in dip1000.

Hard for me to understand what dip1000 is doing, but it seems 
like an omission:


@safe ref int foo(return ref int x) { return x; }

void main() @safe
{
   int x;
   scope int *xp =  // OK with dip1000
   xp = foo(x); // Error, even though it's exactly the same
}

And in this case, it doesn't even need to be scope, as it's GC 
data. How does one communicate that the ref return is of GC 
data and can be escaped as much as you want?


-Steve


The error seems to be about type mismatching, it works if you use 
auto. I don't see how you could convert the `ref int` to `int *`

https://run.dlang.io/is/eIJMIK

Re: Using iteration / method chaining / etc on multi-dimensional arrays

[Uknown via Digitalmars-d-learn]

On Thursday, 12 April 2018 at 15:38:34 UTC, Chris Katko wrote:

I googled but couldn't find any clear solution.

I've got a 2-D array of strings read from a text file I parsed. 
So it's like


0 1 15 0 0
2 12 1 0 0
...
0 1 0 10 0

They come in with spaces, so I join into an array between them. 
But then the last ones have a newline \n on the end, which 
explodes the to! type conversion.


If it was a single array, I could simply do:

string [25] test;

  test.each((ref n) => n.stripRight());

But how do you do that when it's a 2-D array?

I'm looking not just for this case, but the generate case of 
iterating / applying filters to 2-D arrays.


Thanks.


I think something like this would work:

test.each((ref s) => s.each((ref n) => n.stripRight()));

Essentially, get each 1D array from the 2D array, and then apply 
the algorithms on that. There's probably a better way though

Re: NoCopy for overriding @disable this(this)

[Uknown via Digitalmars-d]

On Thursday, 12 April 2018 at 12:16:53 UTC, Shachar Shemesh wrote:

[...]
test.d(19): Error: cannot convert  to const(ubyte*) at 
compile time

[...]
Thank you,
Shachar


The problem seems to be that cast is happening at compile time, 
as opposed to run time, as you might have already figured out. Do 
you need to really do this cast at compile time? I tried running 
the snippet you gave here: https://run.dlang.io/is/im19nL


Is this how you intend for it to be used? Then there's no need 
for compile time casts. If not, could you give an example of how 
`NoCopy` would be used?

Re: Escaping address of

[Uknown via Digitalmars-d-learn]

On Wednesday, 11 April 2018 at 16:25:20 UTC, Jonathan M Davis 
wrote:

[...]


Adding a destructor makes the compiler return an error about 
lifetimes, with or without -dip1000


https://run.dlang.io/is/ddXqNu

Re: [OT] gdc status

[Uknown via Digitalmars-d-announce]

On Wednesday, 11 April 2018 at 13:17:23 UTC, drug wrote:

11.04.2018 15:22, bachmeier пишет:
On Wednesday, 11 April 2018 at 09:45:07 UTC, Jonathan M Davis 
wrote:

... Given that GDC has been added to GCC...
Is it true? I don't see anything like that here 
https://gcc.gnu.org/gcc-8/changes.html


Here's relevant news from Phoronix:

https://www.phoronix.com/scan.php?page=news_item=D-Frontend-For-GCC

Here's the relevant announcement:
https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html

Re: Mission impossible

[Uknown via Digitalmars-d]

On Wednesday, 11 April 2018 at 08:59:36 UTC, Shachar Shemesh 
wrote:

On 11/04/18 11:51, Uknown wrote:

On Wednesday, 11 April 2018 at 08:47:12 UTC, Basile B. wrote:
On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh 
[...]

What else is it?

Shachar


I thought there was a relevant rule about member templates, but 
there isn't any such thing. My bad

Re: Mission impossible

[Uknown via Digitalmars-d]

On Wednesday, 11 April 2018 at 08:47:12 UTC, Basile B. wrote:
On Wednesday, 11 April 2018 at 08:36:41 UTC, Shachar Shemesh 
wrote:

struct S {
static void func(T)(uint a, T t) {
}

static void func() {
}
}

Your mission, Jim, should you choose to accept it, is this:

Get a pointer to the version of the function that accepts no 
arguments.


As always, should you or any of your Force be caught or 
killed, the Secretary will disavow any knowledge of your 
actions. This disc will self-destruct in ten seconds.


Good luck, Jim.


I suppose __traits(getOverloads) doesn't work because of a bug ?


The template hides any other overloads that func() has:

https://run.dlang.io/is/yMJXRz

I'm not sure if its a bug though

Re: that is bug?

[Uknown via Digitalmars-d]

On Monday, 9 April 2018 at 14:28:54 UTC, MattCoder wrote:

On Monday, 9 April 2018 at 03:35:07 UTC, Ali Çehreli wrote:

...
I don't have any problem with that part either. The following 
makes sense to me. I may have even used it in the past (likely 
in C++):


(cond ? a : b) = foo;
...


For me as a C programmer this is different. What happens in 
this case? It will be assign foo to either a or b?


Matt.


Depending on the condition, foo will be assigned to either a or b

Re: Checking if a function pointer is set or null

[Uknown via Digitalmars-d-learn]

On Monday, 9 April 2018 at 00:25:08 UTC, solidstate1991 wrote:
Would the if(!(myFunctionPointer is null)){} work is I 
intended?


Yes, that works as you expect

https://run.dlang.io/is/ZTtm0P

Re: Function template argument deduction

[Uknown via Digitalmars-d-learn]

On Saturday, 7 April 2018 at 05:58:10 UTC, Paul Backus wrote:

On Saturday, 7 April 2018 at 05:46:07 UTC, Uknown wrote:
I don't see the error you are talking about: 
https://run.dlang.io/is/XWPIc1


Are you using the latest compiler?


Compile with -unittest.

And yes; I'm using DMD 2.079.0.


Now I feel silly. Anyway, I played around with your code. One 
thing I found was `cons.head` returns a `T`, which can't be 
appended to a string. You can fix this with 
`cons.head.to!string`, where `to` is from std.conv. I'm not sure 
why IFTI isn't deducing `T` to be `int` though. Hopefully some 
one else can help out here.


What I did notice though is that when
`string list2string(T)(List!T list)` was changed to
`string list2string(T)(VariantN!(16LU, Nil, Tuple!(T, "head", 
This*, "tail")) list)`

The compiler correctly deduce `T` to be `int`

Re: Function template argument deduction

[Uknown via Digitalmars-d-learn]

On Saturday, 7 April 2018 at 05:10:05 UTC, Paul Backus wrote:
I'm playing around with functional programming in D, and have 
run into a problem with the following code:


[...]


I don't see the error you are talking about: 
https://run.dlang.io/is/XWPIc1


Are you using the latest compiler?

Re: c2 classes

[Uknown via Digitalmars-d-learn]

On Friday, 6 April 2018 at 14:43:25 UTC, Ali wrote:

On Friday, 6 April 2018 at 14:31:49 UTC, Alex wrote:

On Friday, 6 April 2018 at 13:41:50 UTC, aerto wrote:

[...]

A question from me, since I am also still learning D
what is the difference between those following two declarations

UUsers[int] uid; UUsers[] uid;


T[U] declares an Associative Array but T[] declares a Dynamic 
Array. Some examples will help:


---
void main()
{
char[int] s1;
char[] s2;
s1[1] = 'c'; //allowed, it is an Associative array. key 1 
stores value 'c'

s2[0] = 1; //error: out of bounds of array s2
}
---

You can check out the spec[0] and the tour[1]

[0]: https://dlang.org/spec/hash-map.html
[1]: https://tour.dlang.org/tour/en/basics/associative-arrays

Re: DIP in making: ProtoObject

[Uknown via Digitalmars-d]

On Wednesday, 4 April 2018 at 15:18:30 UTC, Andrei Alexandrescu 
wrote:

On 04/04/2018 09:18 AM, 12345swordy wrote:
On Wednesday, 4 April 2018 at 04:49:10 UTC, Andrei 
Alexandrescu wrote:

[...]


No attempts to make class deallocation @nogc attribute 
friendly? This is a major PIA for me. The current attempts at 
this involve various workarounds (See automem library for 
example), which even then does not solve all the problems it 
currently have.


Can you please give more detail on that? You mean the 
destructor of Object is automatically generated with a bad 
signature?


I'm not them, but I think they were referring to the fact that 
destructors can't be @nogc for classes.


Relevant forum thread:
https://forum.dlang.org/post/pnswjnosrlfazgscu...@forum.dlang.org

Re: Taming templates and mixin magic: type inpector helper in D/Phobos?

[Uknown via Digitalmars-d-learn]

On Wednesday, 4 April 2018 at 05:28:57 UTC, Carlos Navarro wrote:
As a newbie in D (and making a lots of mistakes), I've found 
myself relying heavily in the use of a rudimentary type 
inspector to visualize my templated code instantiations.
It's simple and incomplete as hell but good enough to see what 
happens under the hood quickly.


QUESTION: Is there a function like that already in D?


//real-life example
goodEnoughTypeInspector!Human;
goodEnoughTypeInspector!(Database!Human);

//compile-time output
Inspecting type: Human
 - public string name
 - public string address
 - public bool active

Inspecting type: Database!(Human)
 - private string[] name
 - private string[] address
 - private bool[] active
 - public pure nothrow @nogc @safe ulong() count
 - public void insert


you might want to check std.traits [0] and __traits [1]. They 
both contain functions that may be useful. To get members you 
could use

__traits(allMembers, MyTemplate!SomeType);

Just check through the docs for relevant functions. You can then 
compose the relevant function. I wrote a basic version you can 
play with [2].



[0]: https://dlang.org/phobos/std_traits.html
[1]: https://dlang.org/spec/traits.html
[2]: https://run.dlang.io/is/COZ89T

Re: Why toUTF8 not accept wchar[] as argument?

[Uknown via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 02:31:15 UTC, Uknown wrote:

On Tuesday, 3 April 2018 at 02:24:08 UTC, Domain wrote:

wchar[10] buffer;
toUTF8(buffer);

Error: template `std.utf.toUTF8` cannot deduce function from 
argument types `!()(wchar[10])`, candidates are:

/dlang/dmd/linux/bin64/../../src/phobos/std/utf.d(2713):
 `std.utf.toUTF8(S)(S s) if (isInputRange!S && !isInfinite!S 
&& isSomeChar!(ElementEncodingType!S))`



I know buffer.idup is OK. But why? That's very inconvenient.


What you need to do is slice your buffer. So your call will 
become like this:


---
toUTF8(buffer[]);
---

Now it will work as expected.


I should mention that you need to slice any static array when 
passing to functions that expect ranges

Re: Why toUTF8 not accept wchar[] as argument?

[Uknown via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 02:24:08 UTC, Domain wrote:

wchar[10] buffer;
toUTF8(buffer);

Error: template `std.utf.toUTF8` cannot deduce function from 
argument types `!()(wchar[10])`, candidates are:
/dlang/dmd/linux/bin64/../../src/phobos/std/utf.d(2713):
`std.utf.toUTF8(S)(S s) if (isInputRange!S && !isInfinite!S && 
isSomeChar!(ElementEncodingType!S))`



I know buffer.idup is OK. But why? That's very inconvenient.


What you need to do is slice your buffer. So your call will 
become like this:


---
toUTF8(buffer[]);
---

Now it will work as expected.

Re: What is the equivalent of C++'s std::optional and std::nullopt in D?

[Uknown via Digitalmars-d-learn]

On Tuesday, 3 April 2018 at 02:10:09 UTC, helxi wrote:
For reference: 
https://en.cppreference.com/w/cpp/utility/optional


Nullable!T would be the closest thing:
https://dlang.org/phobos/std_typecons.html#Nullable

I'm not sure how comparable they are though.

Garbage Collection in D

[Uknown via Digitalmars-d]

The Garbage Collection page of the spec 
(https://dlang.org/spec/garbage.html) mentions that it is 
undefined behaviour to store pointers to GC memory in non pointer 
types. Is this a relic of the past? I've seen a lot of people 
here on the forum saying that the GC needs to be conservative 
because D is a systems programming language. Wouldn't it be legal 
to make a Garbage Collector that uses type info, since the 
language allows it?


I think it should be noted though that druntime states that 
memory is always conservatively scanned: 
https://dlang.org/phobos/core_memory.html

Re: __has_side_effects

[Uknown via Digitalmars-d]

On Sunday, 1 April 2018 at 14:33:14 UTC, Andrei Alexandrescu 
wrote:

On 4/1/18 9:39 AM, Uknown wrote:
On Sunday, 1 April 2018 at 10:23:40 UTC, Andrei Alexandrescu 
wrote:

On 4/1/18 2:22 AM, Uknown wrote:

[...]

Terrific, thanks!!


Created the PR: https://github.com/dlang/phobos/pull/6403

Re: __has_side_effects

[Uknown via Digitalmars-d]

On Sunday, 1 April 2018 at 10:23:40 UTC, Andrei Alexandrescu 
wrote:

On 4/1/18 2:22 AM, Uknown wrote:

[...]


That's a great initiative, and a worthy trait for the stdlib. I 
think you'd have an easier time if you reasoned from the other 
end. A function is strongly pure if all of the following are 
true:


[...]


I got a working implementation that satisfies your requirements 
in about 60 lines.
I will make a Pull Request as soon as I write the Docs and 
unittests.


Here's the implementation: https://run.dlang.io/is/kVpv36

Re: __has_side_effects

[Uknown via Digitalmars-d]

On Sunday, 1 April 2018 at 05:27:38 UTC, Uknown wrote:

[...]

I knew I was missing something. Fixed it, thanks

https://run.dlang.io/is/tZeZrP


Sorry for the spam, but I also managed to miss `immutable`, 
`const` and when T has mutable indirections


Final version that I'm sure covers all the cases:

https://run.dlang.io/is/kGoU4X

Re: __has_side_effects

[Uknown via Digitalmars-d]

On Sunday, 1 April 2018 at 04:30:03 UTC, Nicholas Wilson wrote:

On Sunday, 1 April 2018 at 04:11:37 UTC, Uknown wrote:
On Friday, 30 March 2018 at 20:28:27 UTC, Andrei Alexandrescu 
wrote:

[...]


Just for the fun of it, I implemented this as a template:

https://run.dlang.io/is/pXLndG


You're missing classes, AAs, and pointers (possibly function 
pointers and delegates as well).


I knew I was missing something. Fixed it, thanks

https://run.dlang.io/is/tZeZrP

Re: __has_side_effects

[Uknown via Digitalmars-d]

On Friday, 30 March 2018 at 20:28:27 UTC, Andrei Alexandrescu 
wrote:

https://www.reddit.com/r/programming/comments/88aqsf/the_joy_of_max/

Discussion aside, I notice with pleasant surprise gcc has an 
introspection primitive we didn't think of: __is_constant that 
(I assume) yields true if the given expression has no side 
effects.


In D the primitive would be called e.g. __has_side_effects to 
avoid confusion with the "const" qualifier.


I wonder how difficult it would be to define __has_side_effects 
(it would apply to an alias) and how it can be put to good use.



Andrei


Just for the fun of it, I implemented this as a template:

https://run.dlang.io/is/pXLndG

Re: auto-decoding

[Uknown via Digitalmars-d-learn]

On Sunday, 1 April 2018 at 01:19:08 UTC, auto wrote:

What is auto decoding and why it is a problem?


Auto-decoding is essentially related to UTF representation of 
Unicode strings. In D, `char[]` and `string` represent UTF8 
strings, `wchar[]` and `wstring` represent UTF16 strings and 
`dchar[]` and `dstring` represent UTF32 strings. You need to know 
how UFT works in order to understand auto-decoding. Since in 
practice most code deals with UTF8 I'll explain wrt that. 
Essentially, the problem comes down to the fact that not all the 
Unicode characters are representable by 8 bit `char`s (for UTF8). 
Only the ASCII stuff is represented by the "normal" way. UTF8 
uses the fact that the first few buts in a char are never used in 
ASCII, to tell how many more `char`s ahead that character is 
encoded in. You can watch this video for a better 
understanding[0]. By default though, if one were to traverse a 
`char` looking for characters, they would get unexpected results 
with Unicode data


Auto-decoding tries to solve this by automatically applying the 
algorithm to decode the characters to Unicode "Code-Points". This 
is where my knowledge ends though. I'll give you pros and cons of 
auto-decoding.


Pros:
 * It makes Unicode string handeling much more easier for 
beginners.

 * Much less effort in general, it seems to "just work™"

Cons:
 * It makes string handling slow by default
 * It may be the wrong thing, since you may not want Unicode 
code-points, but graphemes instead.
 * Auto-decoding throws exceptions on reaching invalid 
code-points, so all string

handling code in general throws exceptions.

If you want to stop auto-decoding, you can use 
std.string.representation like this:


import std.string : representation;
auto no_decode = some_string.representation;

Now no_decode wont be auto-decoded, and you can use it in place 
of some_string. You can also use std.utf to decode by graphemes 
instead.


You should also read this blog post: 
https://jackstouffer.com/blog/d_auto_decoding_and_you.html


And this forum post: 
https://forum.dlang.org/post/eozguhavggchzzruz...@forum.dlang.org


[0]: https://www.youtube.com/watch?v=MijmeoH9LT4

Re: D_vs_nim: git repo to compare features of D vs nim and help migrating code bw them. PRs welcome

[Uknown via Digitalmars-d-announce]

On Tuesday, 27 March 2018 at 14:51:30 UTC, bachmeier wrote:

On Tuesday, 27 March 2018 at 01:25:42 UTC, timotheecour wrote:

D and nim are both very promising.
I created this git repo to compare them:

https://github.com/timotheecour/D_vs_nim/

Goal: up to date and objective comparison of features between 
D and nim (to help deciding what language to use), and 1:1 map 
of features and libraries to help D users learn nim and vice 
versa.


PRs are welcome and merged fast


Named parameter arguments is an advantage? I would not consider 
using a language with named parameter arguments. At best, 
claiming it's an advantage is arbitrary.


You might have better luck comparing the languages if you got 
rid of the +1/-1 thing.


I agree with you. A lot of the parameters selected seem 
arbitrary. A lot of the advantages and disadvantages aren't 
absolute, but rather things that depend on the exact situation at 
hand

OT: Behaviour of Experienced Programmers Towards Newcomers

[Uknown via Digitalmars-d]

https://opensource.com/article/18/3/avoid-humiliating-newcomers

Its a blog post about how sometimes expert programmers treat 
newcomers badly. I haven't really noticed  any of what he 
mentions in the D community, as most of the regular members are 
very polite and friendly, but I thought it was an important read 
nonetheless.

Re: Why does struct initializer works for arrays but not for associative arrays?

[Uknown via Digitalmars-d-learn]

On Wednesday, 14 March 2018 at 13:36:51 UTC, Andre Pany wrote:

Hi,

I do not understand why struct initializer works for arrays but 
not for

associative arrays:

struct Bar
{
string s;
}

struct Foo
{
Bar[string] asso;
Bar[] arr;
}

void main()
{
Foo foo = {
arr: [{s: "123"}],
asso: ["0": {s: "123"}] // does not work
};
}

The coding for both types of arrays looks very similiar:
https://github.com/dlang/dmd/blob/9ed779a7d68d2ac489338cc4758c10d0cb169b39/src/dmd/initsem.d#L634

I cannot spot the difference.

Kind regards
André


This might just be a bug. Changing the initializer to an explicit 
call to Bar constructor compiles just fine


https://run.dlang.io/is/nuuolx

Even just doing

Foo foo = {
arr: [{s: "123"}],
asso: ["0": {"123"}] // does not work
};

Re: Added Wiki page Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

[Uknown via Digitalmars-d-announce]

On Wednesday, 14 March 2018 at 09:29:26 UTC, dangbinghoo wrote:

hello there,

Just added a paper for cross compiling D on arm linux devices.

https://wiki.dlang.org/Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

As my english is not that good, every body who find mistakes 
just try to fix it.


Thanks!


Just a little tip, but I would recommend avoiding giving install 
instructions that vary from platform to platform. The problem is 
that 2 years down the line, when someone discovers this tutorial, 
they may discover that the instructions are no longer applicable. 
That makes the entire tutorial seem outdated. Also, the 
instructions are hard to verify for contributors, since they 
probably already installed the programs, so they can't tell if 
the instructions are outdated or wrong.
Instead, I would recommend giving relevant links to install 
instructions provided by the program/package creator. That way 
the instructions are always up to date

Re: Added Wiki page Programming_in_D_tutorial_on_Embedded_Linux_ARM_devices

[Uknown via Digitalmars-d-announce]

On Wednesday, 14 March 2018 at 10:25:04 UTC, Seb wrote:

On Wednesday, 14 March 2018 at 09:29:26 UTC, dangbinghoo wrote:
[snip]
As my english is not that good, every body who find mistakes 
just try to fix it.


The MediaWiki notation for links is [link title] - not Markdown.
Pandoc can convert between markdown and MediaWiki.


I'm not OP, but I changed some of the language and fixed the 
links.



[snip]
The recommended way is to use the official install script 
(https://dlang.org/install.html)


curl https://dlang.org/install.sh | bash -s ldc


I changed the LDC install instructions to the curl method

I think this reads better now. This was a great idea for a 
tutorial! Now all we need is a blog post...

Re: LDC / BetterC / _d_run_main

[Uknown via Digitalmars-d-learn]

On Saturday, 10 March 2018 at 12:00:12 UTC, Richard wrote:

On Saturday, 10 March 2018 at 07:54:33 UTC, Mike Franklin wrote:

On Saturday, 10 March 2018 at 02:25:38 UTC, Richard wrote:

[snip]
Based on the above this seems to work fine so I'll use this 
since it's the simplest option.

```
extern(C) int main(int argc, char** argv) {
return d_main();
}

int d_main() {
  // Do stuff
}
```


You can simplify it further:

```
extern(C) int main(int argc, char** argv {
//Do stuff
}
```


This compiles but main() is never called btw
```
import core.stdc.stdio;

private alias extern(C) int function(char[][] args) 
MainFuncType;
extern (C) int _d_run_main(int argc, char **argv, void* 
mainFunc)

{
MainFuncType mFunc = cast(MainFuncType) mainFunc;
return mFunc(null);
}

int main() {
  // Do stuff
}
```
I tried compiling with
ldc2 -defaultlib= -debuglib= -mtriple=thumb-none-linux-eabi 
-mcpu=cortex-m3 --od=. -c -betterC main.d


I think you should not put `-betterC` since you are trying to use 
_d_run_main, which is only called when in regular mode.

Re: See docs compiler message

[Uknown via Digitalmars-d-learn]

On Tuesday, 6 March 2018 at 14:28:52 UTC, ixid wrote:
/opt/compilers/dmd2/include/std/algorithm/iteration.d(663): 
Deprecation: function `std.range.Transposed!(string[], 
cast(TransverseOptions)0).Transposed.save` is deprecated - This 
function is incorrect and will be removed November 2018. See 
the docs for more details.


If it's going to say 'See the docs' how about linking the docs 
or even just specifying which docs it's referring to?


I agree that compiler error messages should be improved. If you 
are still wondering though, 
https://dlang.org/phobos/std_range.html#transposed is the 
relevant documentation

Re: Speed of math function atan: comparison D and C++

[Uknown via Digitalmars-d-learn]

On Tuesday, 6 March 2018 at 08:20:05 UTC, J-S Caux wrote:

On Tuesday, 6 March 2018 at 07:12:57 UTC, Robert M. Münch wrote:

On 2018-03-05 20:11:06 +, H. S. Teoh said:

[snip]
Now, with Uknown's trick of using the C math functions, I can 
reconsider. It's a bit of a "patch" but at least it works.


I'm glad I could help!


In an ideal world, I'd like the language I use to:
- have double-precision arithmetic with equal performance to 
C/C++
- have all basic mathematical functions implemented, including 
for complex types
- *big bonus*: have the ability to do extended-precision 
arithmetic (integer, but most importantly (complex) 
floating-point) on-the-fly if I so wish, without having to rely 
on external libraries.


D has std.complex and inbuilt complex types, just like C [0][1]. 
I modified the mandelbrot generator on Wikipedia, using D's 
std.complex and didn't have too much of an issue with 
performance.[2]

Also, std.bigint and mir might be of interest to you.[3]

C++ was always fine, with external libraries for extended 
precision, but D is so much more pleasant to use. Many of my 
colleagues are switching to e.g. Julia despite the performance 
costs, because it is by design a very maths/science-friendly 
language. D is however much closer to a whole stack of existing 
codebases, so switching to it would involve much less extensive 
refactoring.


Theres a good chance D can interface with those libraries you 
mentioned...


[0]: https://dlang.org/phobos/std_complex.html
[1]: https://dlang.org/phobos/core_stdc_complex.html
[2]: 
https://github.com/Sirsireesh/Khoj-2017/blob/master/Mandelbrot-set/mandelbrot.d

[3]: https://github.com/libmir

Re: Speed of math function atan: comparison D and C++

[Uknown via Digitalmars-d-learn]

On Monday, 5 March 2018 at 06:01:27 UTC, J-S Caux wrote:

On Monday, 5 March 2018 at 05:40:09 UTC, rikki cattermole wrote:

On 05/03/2018 6:35 PM, J-S Caux wrote:
I'm considering shifting a large existing C++ codebase into D 
(it's a scientific code making much use of functions like 
atan, log etc).


I've compared the raw speed of atan between C++ (Apple LLVM 
version 7.3.0 (clang-703.0.29)) and D (dmd v2.079.0, also 
ldc2 1.7.0) by doing long loops of such functions.


I can't get the D to run faster than about half the speed of 
C++.


Are there benchmarks for such scientific functions published 
somewhere


Gonna need to disassemble and compare them.

atan should work out to only be a few instructions (inline 
assembly) from what I've looked at in the source.


Also you should post the code you used for each.


So the codes are trivial, simply some check of raw speed:

  double x = 0.0;
  for (int a = 0; a < 10; ++a) x += atan(1.0/(1.0 + 
sqrt(1.0 + a)));


for C++ and

  double x = 0.0;
  for (int a = 0; a < 1_000_000_000; ++a) x += atan(1.0/(1.0 + 
sqrt(1.0 + a)));


for D. C++ exec takes 40 seconds, D exec takes 68 seconds.


Depending on your platform, the size of `double` could be 
different between C++ and D. Could you check that the size and 
precision are indeed the same?
Also, benchmark method is just as important as benchmark code. 
Did you use DMD or LDC as the D compiler? In this case it 
shouldn't matter, but try with LDC if you haven't. Also ensure 
that you've used the right flags:

`-release -inline -O`.

If the D version is still slower, you could try using the C 
version of the function
Simply change `import std.math: atan;` to `core.stdc.math: atan;` 
[0]


[0]: https://dlang.org/phobos/core_stdc_math.html#.atan

Re: iota to array

[Uknown via Digitalmars-d-learn]

On Sunday, 25 February 2018 at 06:22:03 UTC, psychoticRabbit 
wrote:
On Sunday, 25 February 2018 at 05:40:19 UTC, Jonathan M Davis 
wrote:


int[] intArr = iota(1, 11).array();


- Jonathan M Davis


thanks!

oh man.  It's so easy to do stuff in D ;-)

But this leads me to a new problem now.

When I run my code below, I get ints printed instead of 
doubles??


-
module test;

import std.stdio : writeln;
import std.traits : isArray;
import std.array : array;
import std.range : iota;


void main()
{
int[] intArr = iota(1, 11).array(); // 1..10
double[] doubleArr = iota(1.0, 11.0).array(); // 1.0..10.0
char[] charArr = iota('a', '{').array();  // a..z

printArray(intArr);
printArray(doubleArr); // why is it printing ints instead 
of doubles??

printArray(charArr);
}

void printArray(T)(const ref T[] a) if (isArray!(T[]))
{
foreach(t; a)
writeln(t);
}

-


2 Things:
1. You can just use writeln to directly print Arrays. If you want 
a specific format for the array you can use writef/writefln
2. By default, writeln will print [1, 2, 3] when your array 
contains [1.0, 2.0, 3.0], since thats considered neater. You can 
use writefln to address that. You can see this here: 
https://run.dlang.io/is/bNxIsH


You can read more about format strings here:
https://dlang.org/phobos/std_format.html#format-string

Re: Beta 2.079.0

[Uknown via Digitalmars-d-announce]

On Thursday, 22 February 2018 at 09:48:20 UTC, Jonathan M Davis 
wrote:
On Thursday, February 22, 2018 09:42:47 Atila Neves via 
Digitalmars-d- announce wrote:

On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote:
> On Tue, Feb 20, 2018 at 10:19:03PM +, John Gabriele via 
> Digitalmars-d-announce wrote: [...]

>
>> [snip]
Once a feature is in the language, it affects you even if you 
never use it. :|


Which is why we should not let it pass. Why didn't this feature 
go through the usual DIP process?

Re: Beta 2.079.0

[Uknown via Digitalmars-d-announce]

On Wednesday, 21 February 2018 at 18:10:51 UTC, rjframe wrote:

On Wed, 21 Feb 2018 14:46:56 +, psychoticRabbit wrote:
[snip]

But it likely shouldn't be used in "real" applications; in 
particular, I think it would be nice for the Phobos style guide 
to restrict/disallow its use.


But whats the point of introducing a new feature and then 
restricting its use?

Seems like feature itself is buggy or incorrectly implemented then

Re: Manually allocating a File

[Uknown via Digitalmars-d-learn]

On Tuesday, 20 February 2018 at 14:56:54 UTC, Chris M. wrote:
I'm doing this mainly for experimentation, but the following 
piece of code gives all sorts of errors. Hangs, segfaults or 
prints nothing and exits


import std.stdio;
import core.stdc.stdlib;

void main()
{
auto f = cast(File *) malloc(File.sizeof);
*f = File("test.txt", "r");
(*f).readln.writeln;
// freeing is for chumps
}

I could have sworn I've done something similar recently and it 
worked, unfortunately I can't remember what the case was.


This is what gdb gave me on a segfault

Program received signal SIGSEGV, Segmentation fault.
0x77a56c32 in 
_D2rt5minfo__T17runModuleFuncsRevSQBgQBg11ModuleGroup8runDtorsMFZ9__lambda1ZQCkMFAxPyS6object10ModuleInfoZv ()

   from /usr/lib64/libphobos2.so.0.78

So it looks like it's reaching the end of main. Past that I 
can't tell what's going on. Ideas?


File * is a C standard library type. You mixed the C standard 
library and D standard library in a way that would not work.


The correct way to initialize a File*:

void main()
{
import core.stdc.stdlib;
auto F = fopen("test.txt", "r");
scope_exit(fclose(f));

//Reading from the file:

char[100] str;
fgets([0], s.length, f);
}

Honestly speaking though you should avoid using the C library 
when you can use th D standard library.


You can read more on the C standard library and how to use it 
here:

http://en.cppreference.com/w/c/io

Re: Manually allocating a File

[Uknown via Digitalmars-d-learn]

On Tuesday, 20 February 2018 at 15:21:59 UTC, Uknown wrote:

On Tuesday, 20 February 2018 at 14:56:54 UTC, Chris M. wrote:
void main()
[snip]


Never mind, I confused FILE* with File...

Re: OT: Evidence of A Intel Virtual Memory Vulnerability

[Uknown via Digitalmars-d]

On Thursday, 4 January 2018 at 00:55:45 UTC, Jack Stouffer wrote:
On Wednesday, 3 January 2018 at 15:51:35 UTC, Jack Stouffer 
wrote:
The gist of the story is that an Intel vulnerability is 
requiring OS vendors to institute Page Table Isolation in 
their kernels. This fix has an _across the board_ 5-7% 
slowdown on Intel chips.


Worse yet, programs which do lots of syscalls will see around 
a 30% slowdown or more, including compilation.


AMD is not effected.

Details and discussion:
Reddit: 
https://www.reddit.com/r/sysadmin/comments/7nl8r0/intel_bug_incoming/

HN: https://news.ycombinator.com/item?id=16046636


Attack details published by Google Project Zero with official 
names https://meltdownattack.com


https://www.phoronix.com/scan.php?page=news_item=x86-PTI-EPYC-Linux-4.15-Test

The linux kernel is not trusting even AMD chips. Supposedly even 
ARM is affected

Re: Help optimizing code?

[Uknown via Digitalmars-d-learn]

On Tuesday, 2 January 2018 at 07:17:23 UTC, Uknown wrote:

[snip]
0. Use LDC. It is significantly faster.
1. Utilize the fact that the Mandelbrot  set is symmetric about 
the X axis.You can half the time taken.

2. Use std.parallelism for using multiple cores on the CPU
3. Use @fastmath of LDC
4. imageData.reserve(width * height * 3) before the loop
5. [1] is a great article on this specific topic
[snip]


Forgot to mention that since you already know some of the edges, 
you can avoid unnecessarily looping through some regions. That 
saves a lot of time